или почему проект может не взлететь

Сейчас с командой веду проект сроком на 3 месяца. Все чётко — понятный бюджет, понятная задача, классный продукт. Мы умеем быстро запускать — на это у нас заточен и стек, и процессы, и команда: каждый разработчик у нас — это микс аналитика, программиста, тестировщика и немного волшебника.

Работаем по принципу: понял, подумал, реализовал, проверил, выкатил. Без лишнего. Не пишем по 30 страниц требований к одному экрану. Не рисуем UML-диаграммы на каждый чих. Мы за скорость и результат.

Но на этом проекте у нас на стороне заказчика — внешний аналитик. Человек с большим опытом в крупных компаниях. И он, как говорится, привык жить по ГОСТу.

Каждую идею надо обложить документацией. Каждую задачу превратить в 5 документов. Каждое решение обсудить так, будто мы строим мост через Амазонку.

И я всё понимаю: процессы, структура, риски... Но, ребят, всего 3 месяца. Пока мы будем рисовать секвенс-диаграммы, писать технические манифесты и устраивать священные обсуждения — рынок уйдёт, тренд изменится, а продукт так и останется в черновиках.

В чем абсурд?

Когда команда умеет думать — не надо объяснять, как зовут поле в таблице. Надо дать суть, цель, историю пользователя. И отпустить. Пусть продукт рождается, а не препарируется на бумаге до потери пульса.

Что в итоге?

📉 Заказчик теряет время. 📉 Теряет деньги. 📉 Теряет конкурентное преимущество.

Я не против аналитиков. Я против избыточности. Против подхода «давайте еще месяц обсудим, как будет называться кнопка».

Иногда меньше — это больше. Особенно в IT. Особенно, когда важна скорость, гибкость и есть ограниченный бюджет и срок