PM FAQ
July 29
Чем вреден водопадный подход в гибких командах?
Если совсем просто, водопадный подход — это когда фича делается до готовности и только потом выпускается. Подход не считается гибким.
Слишком часто я видел, как даже «гибкие» команды на деле работают по водопаду: сначала дизайнер рисует без обсуждения с разработкой, потом разраб делает, потом тестировщик без контекста тестит, а в конце — продакт всё презентует. В таком подходе нет итеративности.
- Поздняя обратная связь. Если гипотеза не сработала, мы узнаем это через месяц;
- Теряется контекст. Чем больше этапов между идеей и реализацией, тем хуже результат;
- Изолирование ролей. Люди перестают понимать бизнес-контекст и общие цели.
Вовлекай всю команду в обсуждение задачи. Например, гипотезу по онбордингу обсуждают вместе дизайнер, аналитик, разработчик и ты. Все на одном уровне.
Это снижает риск «функционального перекладывания ответственности». Каждый принял участие и согласовал результат.