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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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