Около 20% проектов терпят провал. От них отказываются или забрасывают еще до старта (по данным Standish Group’s CHAOS study). И только около 30% проектов действительно успешны — укладываются в сроки, бюджеты и оправдывают ожидания.
Это происходит по множеству причин, часто даже по совокупности. Одна из причин — «full-scale» старт, когда на старте проекта мы собираем большую готовую команду, и она начинает потреблять бюджеты как черная дыра.
Давайте разберемся подробнее, почему так происходит.
Неясные границы
Даже если у вас есть готовое техническое задание с подробным описанием функций системы, это не гарантирует, что в процессе разработки они не изменятся. В подавляющем числе случаев очертания системы станут понятны только после первых реальных итераций и обсуждений с бизнесом/пользователями.
То, что казалось «очевидным требованием», через 2-3 месяца превращается в «давайте это исключим совсем» или, наоборот, в критически важную функциональность, которую надо сделать как можно быстрее.
Большая команда на этом этапе не помогает уточнять требования и границы — она их размывает. Потому что люди начинают «делать хоть что-то», пока ждут ясности.
Чем занять команду: начинаем придумывать продукт вместо бизнеса
В условиях неопределенности у команды возникает вопрос: «А что нам сейчас делать?»
Даже без давления сверху команда не может сидеть без дела, и люди начнут придумывать себе работу:
⌨ Вместо простого решения закладывается «продуманная архитектура» на все случаи жизни.
⌨ Команда начинает добавлять клевые фичи и «пасхалки», которые, скорее всего, никому не нужны.
⌨ Тратит кучу времени на обсуждения архитектуры и инструментов, хотя продукт еще не прошел базовую валидацию.
Плюс ко всему стартовые задачи — инициализация проекта, настройка CICD и т. п., как правило, последовательны и зависят от одного человека, остальные просто ждут и мешают.
В результате через несколько месяцев после старта команда написала «много кода», но ценности для бизнеса этот код приносит минимум.
Сначала — видение и минимум людей для его проверки
Правильный путь — начинать с минимально необходимого состава, даже если бюджет позволяет нанять сразу большую команду.
📌 Проверка гипотез: Сначала формируем видение и проверяем самые рискованные предположения минимальными силами (PoC, MVP, MLP).
📌 Фундамент: Дайте возможность техлиду (или синьору-разработчику) и аналитику время «залить бетон» — сформировать границы системы и запустить базовую функциональность.
📌 Постепенное масштабирование: Вводите новых людей только тогда, когда для них готов понятный фронт работ в бэклоге.
Помните: Проект, начатый огромной толпой, чаще всего заканчивается поиском виноватых. Проект, начатый осознанно, заканчивается релизом.
Мой канал в telegram
#management #mvp #poc