Разработчик врёт. Что делать?

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

Каждый день мы собираемся с разрабами на утренней планёрке и у них всё хорошо. Все работают над задачами, у всех всё получается, стоперов нет. Заканчивается неделя, подходит время релизиться, я спрашиваю: «Ну что, мы же все запланированные доработки успеваем зарелизить?» А тимлид отвечает: «Нет, мы ни одной не успели сделать».

Занавес. Почему они врут? На ладно, врут не самое удачное слово, почему они вводят в заблуждение, говорят, что нет проблем, когда проблемы есть? Пытаемся разобраться в этой публикации:

Почему разрабы врут

Страх показаться слабым

Если в команде нет декриминализации ошибок и эскалаций, люди очень боятся облажаться, показать, что не разобрались в задаче.

Разрабу может быть так страшно, что он предпочтёт просто тянуть время в надежде, что проблема со временем разрулится сама собой или таск просто отменят.

Непонимание задачи

Ты понял задачу? Не понял, но сейчас сделаю. Такое бывает в командах, где нет культуры нормального прописывания требований. Аналитик или пиэм объяснил разрабу задачу устно, тот до конца не понял, но боится показаться тупым и кивает, что понял. Делает как понял, потом боится признаться, что сделал не то. Детский сад, казалось бы, но всё ещё встречается.

Потеря интереса или энергии

Выгорание. Он, конечно, незаменимый, впахивает уже несколько лет без серьёзного отпуска, ему всё это страшно надоело. Или просто задачи скучные, опять этот бесконечный кровавый государственный дотнет. И поэтому ему тяжко даже открыть IDE, он бесконечно листает твиттер, но пиэму не говорит, говорит: «Работаю над задачей, всё нормально». «Да, в срок успеваю». «Извините, не успел, нужна ещё пара дней».

Отсутствие доверия

Бывает в командах с жёстким менеджментом. Разраб один раз сказал, ему жёстко ответили, начали прессовать. Он решил, что лучше будет врать, косячить и в итоге получать по шапке. Так наказание будет отложенным, так чуть менее мучительно. Бывает у менеджеров, вышедших из реального сектора.

Просто привычка тянуть

Синдром студента. Человек просто привык делать всё в последнюю минуту.

Две работы – привет волкам

Явление появилось с распространением удалённой работы. Разраб устраивается на две-три работы, по факту не успевает делать нормально ни одну. А если уволят, ничего страшного, он за пару дней найдёт ещё одну работу. Беда постепенно уходит вместе с кризисом на рынке труда и ростом конкуренции среди айтишников.

Работа по остаточному принципу

Тихое увольнение. Человек давно решил уходить, но пока не нашёл работу лучше. Поэтому делает просто необходимый минимум, чтобы его не уволили. Сказать об этом прямо не может — не хочет быть уволенным, надо кормить семью. Вот и работает кое-как.

Симптомы

Разберёмся, как диагностировать ложь.

• Примерно одни и те же слова каждый стендап: «работаю над задачей, стопов нет, всё нормально». Может сказать, что доделал, сдать на тестирование, после проверки выясняется, что две трети кейсов не реализовал или они не работают.
• Разраб пытается запудрить вам мозги техническими терминами. У него всё время «WAF смотрит на апач, а бармен им говорит». Если в команде нет сильного техлида, у него это вполне может получиться. Программирование сложное и некоторые лжецы этим пользуются.
• Расплывчатые ответы на уточняющие вопросы, не говорит никакой конкретики. Пока непонятно, надо экспериментировать. Трудно сказать, легаси. Цепочки труднотлавливаемых багов. Всё неопределённо, не знаю, когда будет готово.
• Коммитит маленькие порции кода, стремится всё выкатить в ночь перед завершением итерации. К вопросу о студентах. Код часто низкого качества, без комментариев.
• Одни и те же отмазки: «Не могу доделать задачу, баг мешает. Как именно, объяснить не могу, но мешает». «Легаси, трудно разобраться». «Проблемы с девопс-хозяйством, почему-то не собирается, что делать, пока конкретно не знаю».

В общем, если у вас что-то из этого перечня, самое время задуматься, что проблема есть и начать копать глубже. Хотя, обычно копать особо и не приходится: у команды нет результатов. Вроде, всё нормально, а фичи не сдают.

Что с этим делать

Та девушка, о которой я сказал в начале статьи, решила проблему так. Она сразу после менеджерской планёрки созванивалась с разрабами и этот звонок продолжался до завершения рабочего дня. Просто управляла ими руками. Это, конечно, просто ужасная и выматывающая практика. Давайте разберём, как сделать более smart.

Перевести коммуникацию в честный режим

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

Расскажите, как сами однажды застряли и что из этого вышло, это сближает.

Ввести демо

Скрам предполагает демо в конце каждой итерации. Можно ввести промежуточные демо кусков фич или неготовых фич каждые 2-3 дня. Смысл в том, чтобы люди поняли, что обязательно надо будет «вытащить и показать», поэтому лучше не филонить. Да, будут первое время сопротивляться: «Зачем показывать то, что не готово?»

Я так работал с джуном-бэкендером, когда делал сервис интерактивных презентаций для «Сервье». Он кодил, тут же выкатывал и мне показывал. Это граничный случай, конечно, но идея работала.

Работать с мотивацией

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

Использовать таймбоксинг

Работает, как в описанном выше случае со джуном. Увы, руководить так большим количеством людей у вас не выйдет. Но если команда маленькая, подход: «закодил — закоммитил — выкатил — я посмотрел», работает.

1:1 как точка перехвата

Проводить раз в пару недель с членами команды 1-2-1, дать возможность спокойно выговориться. Человек, который врёт на стендапе, может на 1-2-1 сказать правду. Слушать, не перебивать.

Парное программирование

На критичных задачах можно использовать парное кодирование «пилот-штурман». Один проектирует, другой кодит, потом меняются. Так филонить будет сложнее, кроме того, если один таки уволится, второй будет детально в курсе задачи.

Регулярное ревью кода и процессов

Не формальное, а живое. С разбором решений, обсуждением сложностей, поиском альтернатив. Часто человек тянет, потому что не уверен. А ревью снимает это напряжение и не даёт уйти в глухую оборону.

Резюме

Основная идея заключается в том, чтобы реагировать, когда разрабы говорят одно и то же: «всё хорошо», но фичи не сдают. Они не всегда врут, потому что плохие. Возможно, они вас боятся, устали или просто не хотят показаться тупыми и неквалифицированными.

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