Если вы хоть раз были на стороне бизнеса, наверняка слышали (или говорили):

Разработчики что-то тормозят…
Сколько можно делать такую простую штуку?
Они что, не понимают, как это важно?

Но тут надо смотреть шире

Проблема может быть не в людях. А в самих задачах.

Возможно, причина не в том, что разработчики не могут, а в том, что им не дали нормальную задачу.
Да-да, даже если вы её долго объясняли. Даже если она вам кажется очевидной. Даже если вы сами бывший разработчик.

Ситуация 1: «Добавьте кнопку. Это же просто!»

Разработчик слышит - "Сделай кнопку"

Что на самом деле стоит за этой кнопкой:

• куда она ведёт?

• кто ей будет пользоваться?

• как она должна вести себя на разных ролях?

• куда сохраняются данные?

• надо ли логировать действия?

• а если что-то "пойдёт не так"?

Задача вроде бы простая, но это iceberg task — видно только вершину, остальное под водой.

Когда таких задач много, разработчик начинает тормозить — не потому что глупый, а потому что не хочет сломать и не хочет потом по тысячи раз переделывать. Или вообще сам себе напридумывал море функционала вокруг этой простой задачи

Ситуация 2: “Надо побыстрее”

Бизнес просит - "Сделайте это как можно быстрее"

Что получает команда:

• Задача "написать весь код для марсохода".

• Вопросы по архитектуре отодвигаются на потом — “сейчас не до этого”

• ТЗ дописывается прямо на ходу. В пятницу вечером прилетает "ещё вот это допилить"

• Времени на тесты нет, лишь бы "завелось"

• Фича выходит в прод, но быстро начинает сыпаться: баги, падения и откаты.

А потом еще и удивление: "А почему они опять сделали такую фигню?"

Ситуация 3: «Мы хотим MVP, но чтобы всё было качественно»

Самый частый парадокс.
Вы просите сделать быстро, но без факапов.
Вы даёте свободу, но при этом ожидаете "по уму".

Что делает разработчик: либо начинает обрастать страхами и тормозит, либо перебарщивает, и это уже больше, чем MVP, и в сроки никак не укладывается, либо делает "как получится" — а потом вас это не устраивает.

Почему задача может быть "дурацкой"?

По множеству причин задача может быть совершенно неудачной.
Например:

• Нет чёткого результата. Выглядит как "переделать, чтобы было лучше".

• Нет контекста. Разработчик не понимает, как это повлияет на бизнес. Та и вообще закрыт в вакууме "незнания"

• Задача "в воздухе". Непонятно, кто её ставит, зачем и с кем согласовывать.

• Много неизвестных. Решение на коленке — потом переделывать вдвойне.

• Изменения на ходу. Бриф один, а к релизу — вообще другой запрос.

Как это решается?

Чтобы разработчики "не тупили", им нужно не вдохновение, а структура.
Никакой джедайский менторинг или тимлид не поможет, если задачки в духе "вот тут поковыряй".

Объясните, зачем задача. Не просто "сделать выгрузку", а "чтобы менеджеры быстрее получали отчёт, а не мучились с ручной таблицей".

Никогда не пишите в личку задачи, ведите трекер.

Если задача меняется по ходу, то фиксируйте изменения и обговаривайте изменение сроков.

И просто дайте разработчику подумать, хорошее решение - не всегда быстро. Иногда пара часов на архитектуру в начале сэкономит пару недель потом.

И самое важное

Когда кажется, что разработчики медлят.
А точно ли задача правильно поставлена?
Может быть вы ее сунули на обум?

Небольшой оффтоп

В Telegram-канале Техдир на пальцах я также разбираю подобные проблемы/кейсы/советы. Там все про разработку и управление, но простым языком, понятным бизнесу.