Сегодня общался с клиентом, который хочет знать, сколько стоит сделать маркетплейс.

Трагедия в том, что предыдущий подрядчик уже взял кучу денег и потратил полгода клиента «на разработку», не задав базовые вопросы о бизнесе. Честно говоря, у него и не было шанса запуститься вовремя.

Пускай это жёсткий пример, но история классическая:
1. заказчик описывает задачу и просит назвать сроки и цены;
2. подрядчики называют сроки и цену и берут проект;
3. начинаются работы по проекту, и что-то идёт не так;
4. к дедлайну нужного результата нет, все недовольны. Но проект надо доделать.

И эта проблема не только у аутсорсеров — такая же динамика есть и во многих продуктовых компаниях.

Почему так происходит?

- 💼 заказчики живут в реальном мире: если продукт не начнет продаваться или решать другие задачи вовремя, то экономика бизнеса не сойдется и можно закрываться — поэтому они требуют четких сроков и смет;
- 🙏 подрядчики вынуждены комититься в сроки и деньги без детальной проработки проекта. Иначе проект возьмет более сговорчивый конкурент, и команда останется без зарплаты;
- 🛠️ разработчики в команде мечтают работать над сложными проектами уровня Яндекса, но вынуждены пилить такие кривые задачи, как будто их ставили некомпетентные дураки.

На самом деле все хотят как лучше.

Одна из причин проблем — устойчивая иллюзия, что разработка — это простой процесс: берешь задачу и составляешь по ней инструкции для машины на подходящем языке программирования. Такая по сути механическая работа.

Почему это иллюзия?
Потому что разработка — это перевод очень нечетких хотелок и смутных желаний заказчика в супер строгий, не допускающий никакого двойственного толкования язык программирования. Это как с мыслями: всё очевидно, пока крутишь их в голове. Но стоит сесть и попытаться записать их, как выходит полная хрень.

(Этот пост я написал с третьей попытки, а потом понял, что потребуется целая серия постов. Так что я знаю, о чём говорю.)

💡 Для того чтобы управлять сроками, качеством и стоимостью разработки, нужно действовать контринтуитивно: уметь находиться в состоянии неопределенности, выдерживать её — и методично её прояснять.

На старте проекта бессмысленно требовать от заказчика четкости: вообще самое плохое, что можно сделать — это заставить его написать техническое задание (если он умеет писать ТЗ — то он и программирует неплохо). Вместо этого мы вначале 70-90% времени работаем исследователями — разбираемся, какую бизнес-задачу заказчика решаем и какие ресурсы и ограничения у нас есть.

Следующим постом хочу поделиться, как мы проясняем задачу. Но для этого важно сначала признать тот факт, что прояснить задачу заказчика сложнее, чем кажется на первый взгляд.