Стоит ли разработчику заниматься предварительной проработкой задачи
В проектно-водопадном подходе разработчик ограничивает свою зону ответственности кодом. А код он будет писать по ТЗ, которое ему должен принести аналитик. Нет ТЗ — и результат, как грица, хз. А еще в таком подходе любимая забава разрабов — воевать против бедного системного аналитика.
Такой разраб пишет код в отрыве от понимания бизнес-ценности задачи и вектора развития продукта.
Как следствие, проблемы:
— нет драйва довести задачу до прода;
— склонность к оверинжинирингу;
— всё новые и новые рефакторинги, чтобы запилить новую фичу;
Потом в компании случается Agile-трансформация. Альтернативный вариант — сам разработчик переходит в другую компанию с гибким подходом. Так или иначе, разработчик попадает в среду, где "все должны делать всё". Волей-неволей, он подключается к предварительной проработке задачи. Сначала есть сопротивление, что мол "меня нанимали код писать, а не это вот всё".
Но потом появляется понимание бизнес-ценности задачи и стратегии продукта. Прорабатывая задачу, разработчик начинает чувствовать причастность. Это теперь его задача и его продукт. Из понимания бизнеса и причастности рождается более полезный для бизнеса код, при этом растет мотивация самого разработчика. До какого-то момента это работает прям хорошо.
И вот наступило "светлое будущее": разработчики проводят 90% рабочего времени во встречах по обсуждению задач.
Одна из ценностей Scrum — Фокус. Обычно его преподносят как фокус всех членов команды на цели спринта. Но никто не лимитирует количество задач в предварительной проработке. Владелец продукта, потирая руки, начинает закидывать в разрабов всё новые и новые гипотезы. Собираются встречи со стейкхолдерами, доуточняются требования, бизнес-постановка и критерии приемки задачи.
В итоге я уже который раз вижу ситуацию, что 20 эпиков из бэклога потроганы по чуть-чуть, но ни один не проработан до уровня "можно взять и запилить". А 15 из этих 20 эпиков протухают, так и не будучи проработанными. При этом разработчики сходят с ума от переключения контекстов, и ни о каком фокусе речь не идет.
В проработке и разработке нужен баланс. Привлекать разработчиков к проработке задачи на раннем этапе — отличная идея. Но только до тех пор, пока у них сохраняется способность разрабатывать. Тогда профиты от понимания разрабом бизнес-ценности задачи таки смогут проявиться, когда задача доедет до пользователя.
В проектно-водопадном подходе разработчик ограничивает свою зону ответственности кодом. А код он будет писать по ТЗ, которое ему должен принести аналитик. Нет ТЗ — и результат, как грица, хз. А еще в таком подходе любимая забава разрабов — воевать против бедного системного аналитика.
Такой разраб пишет код в отрыве от понимания бизнес-ценности задачи и вектора развития продукта.
Как следствие, проблемы:
— нет драйва довести задачу до прода;
— склонность к оверинжинирингу;
— всё новые и новые рефакторинги, чтобы запилить новую фичу;
Потом в компании случается Agile-трансформация. Альтернативный вариант — сам разработчик переходит в другую компанию с гибким подходом. Так или иначе, разработчик попадает в среду, где "все должны делать всё". Волей-неволей, он подключается к предварительной проработке задачи. Сначала есть сопротивление, что мол "меня нанимали код писать, а не это вот всё".
Но потом появляется понимание бизнес-ценности задачи и стратегии продукта. Прорабатывая задачу, разработчик начинает чувствовать причастность. Это теперь его задача и его продукт. Из понимания бизнеса и причастности рождается более полезный для бизнеса код, при этом растет мотивация самого разработчика. До какого-то момента это работает прям хорошо.
И вот наступило "светлое будущее": разработчики проводят 90% рабочего времени во встречах по обсуждению задач.
Одна из ценностей Scrum — Фокус. Обычно его преподносят как фокус всех членов команды на цели спринта. Но никто не лимитирует количество задач в предварительной проработке. Владелец продукта, потирая руки, начинает закидывать в разрабов всё новые и новые гипотезы. Собираются встречи со стейкхолдерами, доуточняются требования, бизнес-постановка и критерии приемки задачи.
В итоге я уже который раз вижу ситуацию, что 20 эпиков из бэклога потроганы по чуть-чуть, но ни один не проработан до уровня "можно взять и запилить". А 15 из этих 20 эпиков протухают, так и не будучи проработанными. При этом разработчики сходят с ума от переключения контекстов, и ни о каком фокусе речь не идет.
В проработке и разработке нужен баланс. Привлекать разработчиков к проработке задачи на раннем этапе — отличная идея. Но только до тех пор, пока у них сохраняется способность разрабатывать. Тогда профиты от понимания разрабом бизнес-ценности задачи таки смогут проявиться, когда задача доедет до пользователя.