Сначала работающая версия, потом — идеальная

Поговорим о ещё одной ментальной ловушке, которую особенно любят перфекционисты.

Начну с примера. Однажды я потратил несколько месяцев на «идеальную» автоматизацию отчёта. Аналитики долго собирали требования, разработчики сделали всё по ТЗ, но когда пользователи начали работать, оказалось, что:
- Данные выводятся не в тех разрезах
- Нет нужных фильтров
- Интерфейс неудобный, оказалось большинство пользователей смотрят с мобильного, а адаптация под него не была заложена

Пришлось всё переделывать (привет методологии SCRUM).

Вы можете возразить, что проблема была в неверно собранных требованиях. Но у меня другая версия, проверенная 10+ годами личного опыта. Вы никогда не сможете предусмотреть всего на этапе проектирования.

Поэтому главное правило в разработке:
«Сначала работающая версия, потом — идеальная». Модный ныне термин MVP.

Как это работает?

Возьмем ту же автоматизацию отчётов.

❌ Обычный подход:
1. Сбор требований (1 месяц)
2. Разработка «идеального» решения (1 месяц)
3. Внедрение → осознание, что отчёт неудобен, переход к п.1

✅ Мой подход:
1. Создаём ручной прототип в Google-таблицах (1-2 дня)
2. Используем его 2-4 недели, выявляем все проблемы и сразу же вносим корректировки в таблицу, продолжаем использование
3. Как только понимаем, уже неделю мы работаем без замечаний, и отчет всех устраивает, переходим к автоматизации данного прототипа

Таким образом мы не разрабатываем «сферического коня в вакууме», а автоматизируем уже отточенный (пусть и в ручном режиме) процесс. Тем самым экономим время и нервы команды. На этом моменте передаю горячий привет всем перфекционистам ))

P.S. Лучший продукт — не тот, который долго делали, а тот, который уже работает и приносит эффект.