Если вы хоть раз были на стороне бизнеса, наверняка слышали (или говорили):
Разработчики что-то тормозят…
Сколько можно делать такую простую штуку?
Они что, не понимают, как это важно?
Но тут надо смотреть шире
Проблема может быть не в людях. А в самих задачах.
Возможно, причина не в том, что разработчики не могут, а в том, что им не дали нормальную задачу.
Да-да, даже если вы её долго объясняли. Даже если она вам кажется очевидной. Даже если вы сами бывший разработчик.
Ситуация 1: «Добавьте кнопку. Это же просто!»
Разработчик слышит - "Сделай кнопку"
Что на самом деле стоит за этой кнопкой:
куда она ведёт?
кто ей будет пользоваться?
как она должна вести себя на разных ролях?
куда сохраняются данные?
надо ли логировать действия?
а если что-то "пойдёт не так"?
Задача вроде бы простая, но это iceberg task — видно только вершину, остальное под водой.
Когда таких задач много, разработчик начинает тормозить — не потому что глупый, а потому что не хочет сломать и не хочет потом по тысячи раз переделывать. Или вообще сам себе напридумывал море функционала вокруг этой простой задачи
Ситуация 2: “Надо побыстрее”
Бизнес просит - "Сделайте это как можно быстрее"
Что получает команда:
Задача "написать весь код для марсохода".
Вопросы по архитектуре отодвигаются на потом — “сейчас не до этого”
ТЗ дописывается прямо на ходу. В пятницу вечером прилетает "ещё вот это допилить"
Времени на тесты нет, лишь бы "завелось"
Фича выходит в прод, но быстро начинает сыпаться: баги, падения и откаты.
А потом еще и удивление: "А почему они опять сделали такую фигню?"
Ситуация 3: «Мы хотим MVP, но чтобы всё было качественно»
Самый частый парадокс.
Вы просите сделать быстро, но без факапов.
Вы даёте свободу, но при этом ожидаете "по уму".
Что делает разработчик: либо начинает обрастать страхами и тормозит, либо перебарщивает, и это уже больше, чем MVP, и в сроки никак не укладывается, либо делает "как получится" — а потом вас это не устраивает.
Почему задача может быть "дурацкой"?
По множеству причин задача может быть совершенно неудачной.
Например:
Нет чёткого результата. Выглядит как "переделать, чтобы было лучше".
Нет контекста. Разработчик не понимает, как это повлияет на бизнес. Та и вообще закрыт в вакууме "незнания"
Задача "в воздухе". Непонятно, кто её ставит, зачем и с кем согласовывать.
Много неизвестных. Решение на коленке — потом переделывать вдвойне.
Изменения на ходу. Бриф один, а к релизу — вообще другой запрос.
Как это решается?
Чтобы разработчики "не тупили", им нужно не вдохновение, а структура.
Никакой джедайский менторинг или тимлид не поможет, если задачки в духе "вот тут поковыряй".
Объясните, зачем задача. Не просто "сделать выгрузку", а "чтобы менеджеры быстрее получали отчёт, а не мучились с ручной таблицей".
Никогда не пишите в личку задачи, ведите трекер.
Если задача меняется по ходу, то фиксируйте изменения и обговаривайте изменение сроков.
И просто дайте разработчику подумать, хорошее решение - не всегда быстро. Иногда пара часов на архитектуру в начале сэкономит пару недель потом.
И самое важное
Когда кажется, что разработчики медлят.
А точно ли задача правильно поставлена?
Может быть вы ее сунули на обум?
Небольшой оффтоп
В Telegram-канале Техдир на пальцах я также разбираю подобные проблемы/кейсы/советы. Там все про разработку и управление, но простым языком, понятным бизнесу.
