Begin /* Демотивация
О правильной мотивации программистов, расчете их материального и эмоционального вознаграждения высказано неимоверное количество мнений. По большей части они сводятся к размышлениям о том, как правильно и наиболее объективно можно измерить производительность труда программиста. Так или иначе они связаны со оценкой производительности отдельного программиста, и с тем как это сложно бывает сделать. К этому я уже ранее, неким образом подбирался. Есть лидирующие точки зрения, есть разные варианты под разные ситуации. Прогрессивные и консервативные, регуляторные и рыночные. Я не собираюсь оспаривать какие-либо из них или топить, скажем, за эджайл с канбаном. Я позволю себе высказать личное мнение, по поводу того, как не следовало поступать со мной или мне с другими в рамках собственного опыта.
Школа
Начну, как водится, издалека. Первые смутные сомнения, о том, что в этом мире что-то пошло не очень правильно начали появляться еще со школьной скамьи. Кто-то, наверное, еще помнит те "стерильные" компьютерные классы с невероятными по тем временам IBM PC/AT-386. Которые всегда держались под замком и под строгим наблюдением лаборанта. Заходить в такие классы положено было чуть ли не в белых тапочках, а уж прикасаться к компьютерам было позволено исключительно на контрольных работах. А во время простого урока программы писались в тетради. Да, да. В обычной тетради в клеточку.
Да, понятно, что время было такое. И блок-схемы к алгоритмам надо сперва учиться составлять в голове. Насколько я понимаю, и по сей день по информатике детей учат сперва составлению абстрактных алгоритмов. Но, извините, конкретный исходный код на бейсике в тетради? Впрочем не об этом. Более порочной в этой ситуации была система оценки. Пятерку за программу без ошибок в тетради? Что это за критерий такой? То есть, будущий программист получал оценку, за безошибочно транслированную блок-схему. Не за то что бы понять как это все устроено и работает, не за то что он пришел к правильному решению путем построения правильной программы через ошибки. А за то что у него, ну, хорошая память наверное.
В нашей конкретной школе помимо пятерки в табеле еще отличникам позволялось после уроков немного поиграть на этих драгоценных девайсах. Разумеется под присмотром строгого лаборанта и строго определенное время. Это был эдакий внеклассный мотивирующий приемчик - личная инициатива учителя. Надо сказать, он в какой-то мере работал: многие, включая меня, именно с этой целью даже больше старались. Но, тут надо понимать, что старались они чаще аккуратнее списать, чем дебажить в тетрадке. С другой стороны остальных, тех кто совсем не понимал информатику и программирование, это наоборот озлобило и настроило против прилежной части состава и напрочь раздружило вообще со всем околокомпьютерным. Сколько из этих ребят имели способности к логическому и алгоритмическому мышлению, мы теперь уже не узнаем.
Студенчество
В вузе ничего радикально не поменялось. Отличие заключалось лишь в том, что за компилирующиеся программы стали ставить не оценки, а зачеты. Можно сказать стало даже чуть хуже. Ты не понимал насколько хорошо ты выполнил задание: на троечку или на отлично - зачет. Тут уже начали в голове крутиться некоторые подозрения где конкретно будет больно в будущем уже на настоящей работе. Вывод был очевидный: делай как-нибудь, делай что-нибудь, делай что бы запускалось, остальное ни кого не беспокоит. Как ты это реализовал, какой из алгоритмов выбрал, какими инструментами воспользовался - абсолютно не важно. Зачет - получи зарплату. Идеалист-перфекционист в голове уже тогда начал отказываться верить в то, что в реальном мире все действительно так плохо. Оказалось не зря.
Понимаете в чем ошибка? Люди, покидающие стены вузов сами по себе никогда не бросят заложенные в них идеи. И точно так же будут работать в реальных производствах. Зарплата - единственный показатель качества кода. Зарплата - единственный показатель квалификации. Платят - не надо напрягаться. Изменить мнение их заставит только суровая действительность, которая покажет им к чему ведет такое отношение к работе. Красные глаза, нервный тик, апатия и депрессия. Когда кто, кто-то возможно и никогда, придет к заключению, что зарплата-то не главное. Ну или не самое главное в жизни программиста. Качество кода, его "красота", технологическое совершенство, "ремонтопригодность" - вот единственное мерило, которое следует мотивировать. Не количество, и не его работоспособность в данный момент.
Преподаватель какой-нибудь дисциплины, типа численных методов решения уравнений математической физики, конечно же возразит. Он учит будущих профессоров, ученых. Ему нет дела до проблем софтверных компаний и айти подразделений фабрик и больниц. С его точки зрения программист это действительно прежде всего математик, который может переложить хорошую математическую модель в "мозги" машины. Это всегда код написанный с нуля и не нужный ни кому кроме соискателя на очередную ученую степень. Даже если кто-нибудь, когда-нибудь решит воспользоваться трудом ученого в производстве, то это будет его статья, а не программа, которую ученый написал, для доказательства собственной ценной теории.
Работа
Однако, программирование, это давно уже отрасль народного хозяйства и вполне реальный сектор экономики, а далеко не только предмет научных изысканий. Соответственно работать в ней придется совсем по другим принципам. Мотивация ученого и промышленного кодера две совершенно разные разницы. Ученому не нужно отвечать за то, что его код невозможно поддерживать и развивать. Он получил "зачет" за свою модель, на этом жизненный цикл его программы успешно закончился. Программа среднего автоматизатора бизнес-процессов должна жить и работать пока существует сам бизнес-процесс. Программа создателя игры - пока в его игрушку играют.
Модель мотивации программиста должна строиться на долгосрочной перспективе, а не на сиюминутном результате. Что же делает работодатель - платит зарплату. За что? Да за что угодно, только не за качество. За сроки, за доход, за удешевление процесса. Но это, скажем так, модель продиктованная капиталистическим строем в целом. Не нужно искать в нем конкретно программистские проблемы. Это так у всех. Что же касается программистов есть ряд проблем относящихся именно разработке софта.
Не менее важно то, что существует часть программистов именно разработчиков, для которых деньги не являются основным фактором мотивации. Для кого-то следующая фраза может прозвучать пафосно, но программисту важнее признание, чем доход. Даже если это вчерашний студент и ему нужно тратить деньги на красавицу жену/мужа и малолетних спиногрызов, то в подсознании более счастлив он будет, если его программой будет пользоваться как можно больше посторонних. Отсюда и это навязчивое желание сделать какую-то обязательно популярную игрушку или разработать прикольный сайт. Не обязательно при этом, что бы стартап мобильного приложения приносил много денег. Программисту важно чувствовать себя не хуже остальных коллег. И это важно помнить работодателю, ну, естественно, при этом не забывая вовремя пополнять кошелек работника.
Инициатива наказуема
Я не хочу сказать, что программисты это такие особенные снежинки, и очень важно их все время гладить по головке. Нет. Но ни в коем случае нельзя наказывать программиста за новые, по его мнению, решения, подходы. Ни что так не расхолаживает и не демотивирует программиста как отсутствие перспектив. Любых. За ошибки и неверные архитектурные решения не следует наказывать разработчика, это нынче зона ответственности совершенно других ребят - архитекторов, аналитиков и тестировщиков. Если таковые, конечно, имеются. Но и при их отсутствии, ошибки это часть опыта разработчика, нельзя их воспринимать однобоко как однозначное зло. Если программист пробует и ошибается, это лучше, чем если бы он не пробовал что-то новое вообще. Программирование - это инженерия - новые идеи. Даже если это элемент интерфейса - кнопочка одноразового сайта - это продукт интеллектуального труда. Трудно набедокурить в поведении кнопки, но ведь всегда можно и улучшить.
Решил программист как-то по-своему, по-новому, просто по-другому, какую-то проблему - флаг в руки. Не должно следовать наказание, за то что это новое решение немного подглючивает в начале. Если решение не нравится, рассмотрите и аргументированно откажитесь. Не надо посылать инициативного программиста каждый раз на три буквы и следовать консервативным "работающим" методам. Надо понимать, что в следующий раз, когда свежее решение действительно понадобится, он больше не попытается. Работающими в конце-концов когда-то были перфокарты и ассемблер.
Работает - не трогай
Еще одна притча во языцех, которая в общем-то не на пустом месте возникла. Разумеется, как-то работающее, лучше чем не работающее никак. Но плох тот программист или любой другой инженер, который не пробует изобрести способ, что бы это нечто работало еще лучше. Другое дело, если это у него не получается. Действительно, может кто-то ранее, тот кто сконструировал и заставил работать предыдущее изделие знал и умел гораздо больше чем все его последователи. Летает же до сих пор экс "V-2", а затем и "Королёвская семерка". Но и нельзя сказать, что не было попыток сделать лучше и надежнее. Я сомневаюсь, что инженеров, которые хотя бы приблизились к улучшению работы ракеты "Союз", ругали бы за то что те посмели замахнуться на бессмертный авторитет Сергея Павловича.
Битье по рукам часто необходимая мера, но есть и те кто этим явно злоупотребляет. Для оправдания собственной безынициативности и заскорузлости в первую очередь. Скажу больше, кредит доверия Сергею Павловичу данный для совершения прорыва в советской космонавтике не ограничивался лишь одобрением. Терпела ли "семерка" неудачи и провалы повлекшие за собой гигантские экономические и человеческие жертвы, перед триумфальным шествием через десятилетия? Да конечно!
Если мы не можем усовершенствовать саму конструкцию, давайте создадим к ней более технологичные материалы и топливо. Так же и здесь, инициатива программиста может заключаться не в переделке программы, а в постепенном её рефакторинге, причесыванию, мелкими незначительными шажками. Если основные алгоритмы уже написаны великими в далекие семидесятые, то мы хотя бы инструменты вокруг них создадим. Не будет поощрения таких действий - не будет и нормальных инженеров.
Излишний консерватизм присущий работодателям в айти отрасли это еще больший вред, чем сравнимый с ним консерватизм в той же космонавтике. Технологии в программировании, аппаратные средства, общество развиваются быстрее чем прогресс в космосе.
- Будем работать на старом языке программирования.
- Почему?
- Да ни почему. Просто у нас так сложилось.
Самый умный да?
Перекликающееся с предыдущими высказывание. Но его часто можно услышать даже в тех прогрессивных конторах, где с предыдущими двумя пунктами усиленно борются. Тут скорее присутствует социальная подоплека. Социум не терпит выскочек. Это, разумеется, не только программистское. И даже объективно, действительно, убегать сильно вперед в одном из звеньев сложного технологического процесса опасно и бессмысленно. Конвейер работает с одинаковой скоростью, независимо от того насколько ловко вы один собираете двигатель. Производство резины на покрышки зависит от поставок нефтепродуктов, от химических процессов, затратных по времени. И, как бы вы не старались, выкатить больше автомобилей у вас не получится.
Тем не менее есть и особенность. Командная уравниловка в процессе построения программных продуктов все-таки это чуть другое. Индивидуализм не должен подавляться во что бы то ни стало. Заставлять программиста заику выступать с ежедневными докладами перед аудиторией, согласимся, глупо. Заставлять пользоваться единым стилем написания исходного кода? Можно. Но, опять же только где это критически важно. Прототип программы написан на языке не знакомом большинству команды? Но ведь на то он и прототип. Извлеките из прототипа главную мысль и перепишите на основном инструменте - нет проблем. Вот если прототипы все-время попадают в продукт, то стоит пересмотреть работу всего конвейера, а не злобно плеваться на того умника.
Если человек умничает без очевидных на то оснований, то может быть действительно нужно осадить его яркий пыл и посоветовать не отбиваться от коллектива. А может быть человек действительно самый умный? И это остальным надо подтянуться, повысить его, назначить его техлидом. Пусть и заика - ничего страшного. А может быть даже стоит всем присмотреться к этому непривычному языку?
Я вижу тебе заняться нечем?
Стиль управления позаимствованный, наверное, из армии. Не занятый боец - источник беспорядка, а порядок в армии - главное. Но то что при этом не позаимствовали из армии - это то что если солдат не воюет, то он готовится к войне. Мотивируют в армии конечно же чуть построже и попроще чем в производстве софта. Но не в этом дело. Такой подход мотивирует не к созиданию, а к имитации бурной деятельности. Более того, чем человек дольше работает на таком производстве, тем искуснее получается у него ИБД. Возможно программист или заказчик переоценили сложность задачи и у человека осталось свободное время. Надо что сделать? Тут же занять его другой задачей!
Категорически неверно. Ну, во-первых, действительно стоило бы обратить внимание на качество оценки задач. Но если даже выяснится, что программист решил задачу легче, чем это по-началу показалось при постановке - то это его заслуга. Ничья больше. Он молодец. Он не дурак, который себе на голову справился с ней быстрее чем от него ожидают. Программист уж кто-кто, а точно не дурак. В следующий раз будьте уверены, задача будет решена ровно в задуманный срок. А потом, возможно, программист потребует еще дополнительного времени. И для этого не потребуется много итераций.
Программист решивший задачу досрочно должен быть поощрен как минимум отсутствием к нему пристального внимания. И уж никак не лишением сэкономленного времени. Другое дело, что как и в армии, программиста можно мотивировать заняться чем-то полезным в это время. Может быть подумать еще над улучшением качества. Сделать задачу вторым или третьим способом. Потратить время на дополнительное обучение. В отличии от солдата учиться программисты умеют, или хотя бы должны уметь, по определению. Их не надо заставлять учиться, просто отойдите в сторону, если нечего предложить взамен кроме следующей задачи.
Можно поспорить, что в ситуациях, когда вознаграждение напрямую зависит от количества этих самых задач, то программист сам будет рад взяться следующую. Но это возврат к самому началу - количество в ущерб качеству - порочный круг. Потому что такой подход со временем перестанет радовать других программистов, вынужденных сопровождать код выполненный на скорость. А возможно это будет он сам некоторое время спустя. Работодатель уже заложил расходы, зачем всеми способами пытаться превращать сэкономленные ресурсы в дополнительный доход? Не надо так делать.
"Практический потолок"
Ну и в конце наверное стоило бы еще раз отметить то, что программисты - это несмотря на совершенно вульгарное и потребительское отношение к ним как некому кадровому ресурсу, все-таки немного уникальные снежинки. В каждом программисте все-равно в глубине души живет "творец". Держать программиста в золотой клетке, только потому что он нам так полезен и все у нас знает - плохая стратегия. Он либо перестанет вообще реагировать на внешние раздражители и уйдет в полную апатию, либо придется когда-то с ним распрощаться. Если вы не суперпрогрессивная софтверная компания, в определенный момент вам просто станет нечего предложить. Ни новых интересных задач, ни новых технологий и методов. В конце-концов так или иначе работа превратится в рутину. А рутина - враг творческой личности.
Со временем, программист будет просто валять дурака за ваши деньги, либо будет развлекаться чем-то совершенно не связанным с выполнением производственных задач. И удерживать его во что бы то ни стало рядом, только потому что он вот такой полезный, затея обреченная на конфликт. Тем более, если он хочет расти дальше, ни какими деньгами его вы не удержите. Разбиваться в лепешку за деньги это не путь хорошего программиста. Если программист готов делать что угодно за еду, то это и не совсем правильный программист у вас. Гештальт всеобщего признания для него превысит в конце концов любые коврижки. Поэтому лучше уж распрощаться с ним по-хорошему, пока это не произошло по его или вашей инициативе, и вы не разошлись врагами.
Лучше уж пусть перекачанный вами же сотрудник обучит вовремя подрастающую замену, пусть тратит время на общую культуру труда, на организационные вопросы. Возможно, после ухода, работодателю в таком случае удастся сохранить приятельские отношения, останется возможность пригласить в аутсорс, на консультацию.
А вам, коллеги, желаю стать именно таким специалистом, которого мало беспокоит месячная получка, и одновременно оставаться человеком, с которым приятно иметь дело.