Как мы потеряли год, 30 миллионов и нескольких разработчиков

Меня зовут Антон Мишин, я СЕО и основатель ИТ-компании Proscom. Мы специализируемся на кастомных решениях и сервисах для автоматизации внутренних процессов бизнеса, государственных и общественных организаций. Сегодня я расскажу, как мы взяли один, казалось бы, выгодный проект, который в итоге стоил нам 30 млн рублей.

С чего всё началось К нам обратилась компания с интересным… Читать далее Как мы потеряли год, 30 миллионов и нескольких разработчиков

Меня зовут Антон Мишин, я СЕО и основатель ИТ-компании Proscom. Мы специализируемся на кастомных решениях и сервисах для автоматизации внутренних процессов бизнеса, государственных и общественных организаций. Сегодня я расскажу, как мы взяли один, казалось бы, выгодный проект, который в итоге стоил нам 30 млн рублей.

С чего всё началось

К нам обратилась компания с интересным запросом: сделать приложение для управления роскошной недвижимостью — виллами, огромными апартаментами и так далее. Оно предназначалось для «богатой» англоязычной аудитории и должно было включать процессы найма и контроля за сотрудниками, таск-трекер, календарь.

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

Важный момент: если потенциальный заказчик не понимает, чего хочет и как создаются сервисы, наши цены его очень удивляют. Поэтому мы подробно объясняем, из чего складывается стоимость проекта, смотрим на продукт глобально и делаем работу качественно, а не «натягиваем» реализацию на ТЗ.

Собственно, с ТЗ и начались проблемы.

Как мы начали работать

Сначала всё шло неплохо. Мы подключили к проекту лид-дизайнера и лид-разработчика, решив, что с ними всё точно будет так, как нужно. Но уже на этом этапе мы совершили три серьезные ошибки:

1. Поспешили подписать договор по фиксированной стоимости. Боялись не уложиться в сроки.
2. Включили в коммуникацию джуна. Начинающий менеджер был не готов заниматься продуктом такого формата и размера.
3. Не сформулировали подробное ТЗ. Оно было сформировано блочно в виде функциональных модулей приложения.

Да, написать качественное ТЗ непросто. Необходимо провести более глубокое интервью со стейкхолдерами, проработать и четко сформулировать требования. На это может уйти один-два месяца. При этом заказчики обычно хотят заключить договор в течение недели, невзирая на объем работ.

В итоге, мы начали проект без подробной карты. Как приложение должно было работать и выглядеть, никто не знал, решения планировались в процессе. В принципе, это жизнеспособная стратегия, но только со старыми клиентами, с которыми уже есть опыт взаимодействия.

Наши ребята были очень рады, когда мы взяли этот проект. Он действительно казался интересным, серьезным и прорывным, отлично ложился на наш технологический стек.

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

Такой испорченный телефон привел к тому, что начали возникать неприятные ситуации. Например, мы показывали заказчику дизайн, он принимал его со словами: «Все отлично, делайте дальше». А стейкхолдер через месяц говорил нечто вроде: «Всё совсем не то». На вопрос «что именно “не то”?» ответа мы или не получали или получали, но через месяц.

Были сложности и с менеджментом процессов. Мы поставили не очень опытного специалиста на достаточно сложный проект. В целом, было много «звоночков», но мы в силу загруженности не придавали этому столько значения, сколько было необходимо. Со временем мы поняли свою ошибку и закрепили за проектом лида. С тех пор, кстати, это стало нашей обычной практикой, но было поздно.

Когда всё пошло совсем не так

Через полгода мы поняли, что уходим в минус и наши разработчики уже не справляются. Мы начали анализировать процессы, менеджмент, разработку. И получили два варианта развития событий:

1. Опираться только на ТЗ, на то, как мы его видим. Сделать всё по договору и закрыть проект.
2. Получить больше фидбэка от заказчика, начать переработку. Это сохранит нормальную коммуникацию с заказчиком и поможет сделать то, что он хочет, пусть и ценой значительных финансовых потерь.

Мы попробовали оба подхода.

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

В эту коммуникацию включился я. Я был за стратегию переговоров.

В итоге, мы договорились, что заказчик купит у нас дополнительные версии, мы будем развивать продукт, и все нашли экстрарасходы окупятся. Сразу спойлер: нет, они не окупились.

Что было дальше

Мы начали стягивать в этот проект всю нашу экспертизу. Лид-менеджер взял его на себя, да и я серьезно погрузился в работу.

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

Сотрудники выгорали, некоторые увольнялись. В команде начались внутренние конфликты. Из-за этого проекта тормозились остальные. И примерно через год проект зашел в тупик.

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

Что мы вынесли из всего этого

Эта история привела нас к перестройке внутренних и внешних процессов. Теперь мы за каждым менеджером закрепляем лида. Используем новый подход к оценке стоимости проектов. За основу мы взяли методику из Scrum Джеффа Сазерленда:

• Отказались от оценки фичей, функционала, экранов и стали оценивать пользовательские истории.
• Отказались от оценки в часах — оцениваем сложность.
• Используем шаблонные пользовательские истории из нашей базы.
• Тщательно описываем рамки, если заказчик выбирает модель Fixed Price: никаких иносказаний и вторых смыслов. Это защищает нас от «а мы передумали», «мы решили по-другому» или «а мы не так себе это представляли».
• Еще более скрупулезно рассказываем заказчикам о стоимости и сложности проекта. Предлагаем ему выделить MVP и выбрать разработку по T&M.

От ошибок никто не застрахован, но при таком подходе, даже если мы сделаем что-то не так, то потеряем 2 миллиона, а не 30, и сэкономим время. Потерянный месяц разработки не так страшен, как потерянный год.