Хорошие программисты = Экономия денег, Плохие программисты = Утечка бюджета

Хорошие программисты пишут хорошие программы, а плохие программисты пишут плохие программы (С). Не помню, чье авторство, но эта мудрость родилась в муках вместе с опытом :)

Как это ни банально, но бывают хорошие программисты, а бывают и плохие. Хорошие программисты экономят деньги бизнесу, даже зарабатывая больше финансового директора. Плохие же программисты, пользуясь репутацией хороших, напротив, аккумулируют на себе затраты, создавая видимость движения вперед и новые проблемы, и новые затраты (но никто об этом не знает).

Планку заработной платы вверх двигают хорошие, потому что их мало и они пользуются спросом. А пользуются этой планкой все, включая плохих, выдающих себя за хороших.

Расскажу историю про программиста Петю (имя изменено), которого я однажды взял к себе в команду, а потом с трудом вернул на рынок труда.

В бытность мою руководителем отдела разработки ПО вёл я поиск сильных программистов к себе в отдел. Цель была стратегическая - сформировать костяк новой команды, который будет не только сложные задачи уметь решать, но и вести стратегическую образовательную деятельность по вовлечению и адаптации молодых начинающих специалистов в работу отдела, в его культуру, правила работы, обучать лучшим практикам, прививать полезные привычки, подходы и взгляды. Тем самым формировать кадровый резерв для компании на долгие годы вперед.

И вот попалось мне на глаза резюме Пети. Читаю, и глаза радуются. Человек опытный. Слова в резюме правильные, да еще и работал в компании, из которой я смогу взять рекомендации. Звоню друзьям, которые говорят мне, что сами напрямую с ним не взаимодействовали, но судя по отзывам, человек уважаемый, и компания от его ухода только потеряет. Я, конечно, сразу звоню, приглашаю на собеседование (сначала онлайн). Собеседование проходит шикарно, человек разбирается во всех технических ньюансах платформы разработки, достаточно общителен, приводит примеры своих предыдущих работ. Я уже в процессе собеседования представляю, какую задачу ему отдам, как он ее качественно порешает. Да еще и судя по опыту, любит подтягивать молодежь и обучать. Мечта, в общем, а не сотрудник. Оффлайн часть собеседования проходит в том же духе, мы с ним по рукам и вскоре он выходит на работу в офис.

Первой его задачей стало написать код под заранее придуманный мной и расписанный алгоритм на готовых структурах данных. Петя старался, делал, исследовал, взаимодействовал с пользователями, но постоянно ловил какие-то ошибки. Переделывал, снова проверял, привлекал пользователей и аналитиков, старался, но каждый раз результата не было из-за ошибок. Первый месяц казалось, что это проблема адаптации и владения бизнес-областью. Второй месяц я думал, что мало уделяю внимания новому сотруднику (который был в 1.5 раза старше меня), и старался уделять больше, объяснять и рассказывать, приводить примеры. На третий месяц, когда необходимо уже было воспользоваться результатом его работы, я всерьез задумался о том, что ошибся с сотрудником, но другого уже не было, а задачу надо было к тому моменту решать очень срочно, она держала запуск крупного проекта, затрагивающего всю торговую сеть.

Тут же по истечении 3-х месяцев мучений взвыли аналитики и потребовали заменить Петю на кого-нибудь другого. Они устали постоянно уточнять вводные, и постоянно перепроверять работу алгоритма, находить в нем новые ошибки, описывать их, передавать в разработку, снова ловить ошибки и такой бег по кругу неделя за неделей, месяц за месяцем. Да, кодовая база росла, алгоритм работал на 80% от требуемого функционала, но он никак не мог быть завершен, все время что-то отваливалось, неверно считало, не работало. Мне приходилось постоянно включаться и в коммуникацию, и в тестирование, и в рассмотрение различных комбинаций входящих параметров.

В итоге было принято решение тщательно изучить программный код Пети. Если кто-то сейчас скажет про код-ревью, которое надо было делать постоянно, то это конечно да, верно. Но с таким подходом, мы бы делали ту систему несколько лет. А сделали в итоге за полгода, разделив усилия между сильными разрабами.

Но вернемся. Последующее изучение кода Пети показало отсутствие какой бы то ни было структуры и логики, хаос в коде, хаос в мыслях. Удивительно, но все эти 3 месяца Петя честно генерировал программный код, объем которого рос, как на дрожжах, обеспечивал работой себя и еще команду аналитиков и тестировщиков из 5-ти человек, вовлекал в деятельность меня как руководителя, и еще пару ребят разработчиков на разбор сложных случаев. Но финальный результат все время отодвигался на “вот-вот еще чуть-чуть”, и так раз за разом.

В конечном счете, когда сроки реализации уже сгорели полностью, и заканчивался 4-й месяц работы, у меня не осталось вариантов, кроме как прекратить мучения Пети и сделать все самому. Мы с коллегой посмотрели еще раз код Пети, поняли, что ничего оттуда почерпнуть не сможем, и за 3 дня переписали с нуля весь алгоритм, попутно еще его улучшив новыми фичами. Еще два дня ушло на автоматизацию тестирования. Итого, примерно за неделю был реализован весь цикл программы, которая к тому же еще и стала проводить сложные расчеты без ошибок.

Петю от проекта пришлось отстранить, и переключить на другую задачу, которая казалась проще текущей и более понятной. К сожалению там тоже не задалось. Как и еще на нескольких проектах с разными заказчиками и программами в течение еще двух лет. Но с одним и тем же результатом. В итоге с Петей пришлось расстаться. И расписаться в получении нового управленческого опыта.

Признаюсь, что в этом случае я впервые в жизни столкнулся с такой комбинацией технической подкованности и полной неспособностью писать более или менее сложные работающие алгоритмы. Обычно встречается наоборот, когда разработчик не любит изучать ничего нового, поэтому по десятому разу изобретает велосипед. Но тут случай был уникальный. Ситуацию усложняло еще и то, что человек был очень приятный в общении, коммуникабельный и компанейский, добряк по жизни, который просто не умел программировать.

Я могу привести еще с десяток похожих примеров из своей практики, когда один сотрудник без нужных компетенций превращает в труху труды нескольких человек в течение месяцев. Иногда вовсе не со зла, как в случае с героем этой статьи. Иногда намеренно, чтобы не потерять имеющиеся привилегии или приобрести новые. В любом случае для компании это выливается в миллионные затраты, выброшенные в трубу. И никто кроме компетентных специалистов не сможет определить ключевую причину, если она кроется в компетенциях сотрудника. Поэтому рекомендую вам всегда иметь под рукой эксперта, который сможет помочь вам быстро определить не только факт зависания проекта, но и сможет корректно определить причины, особенно кроющиеся в компетенциях привлеченных сотрудников.

После этого случая я изменил свой подход к собеседованию, и стал делать упор на обсуждение реально решенных кейсов, с постепенным углублением в каждый кейс, чтобы пощупать и техническую грамотность, и вовлеченность в бизнес-процессы, и взаимодействие в команде, и мотивацию специалиста. Это помогло подобных ошибок не совершать. Кстати, могу рассказать про интересный случай на собеседовании, когда ко мне пришел супер специалист, а я его не взял. Если интересно, пиши в комментариях у меня в Telegram канале https://t.me/CIOaaS

Ключевая мысль этой статьи - НИКОГДА вы не сможете понять, кто перед вами, пока не решите с человеком задачу. Как бы красиво он ни говорил. Как бы успешно он не решал кейсы и не отвечал на технические вопросы. Особенно, если вы не его непосредственный руководитель, особенно если вы вообще не айтишник.

Если понравился кейс, и хотите прочитать подобные истории, пишите в комментарии :)