Как мы потеряли год, 30 миллионов и нескольких разработчиков
Меня зовут Антон Мишин, я СЕО и основатель ИТ-компании Proscom. Мы специализируемся на кастомных решениях и сервисах для автоматизации внутренних процессов бизнеса, государственных и общественных организаций. Сегодня я расскажу, как мы взяли один, казалось бы, выгодный проект, который в итоге стоил нам 30 млн рублей.
С чего всё началось
К нам обратилась компания с интересным запросом: сделать приложение для управления роскошной недвижимостью — виллами, огромными апартаментами и так далее. Оно предназначалось для «богатой» англоязычной аудитории и должно было включать процессы найма и контроля за сотрудниками, таск-трекер, календарь.
Проект выглядел перспективным, а команда заказчика — компетентной. Мы основательно подготовились к пресейлу: сделали декомпозицию, проработку, проектировку. Всё это подкрепили примерами экранов сервиса для визуализации.
Важный момент: если потенциальный заказчик не понимает, чего хочет и как создаются сервисы, наши цены его очень удивляют. Поэтому мы подробно объясняем, из чего складывается стоимость проекта, смотрим на продукт глобально и делаем работу качественно, а не «натягиваем» реализацию на ТЗ.
Собственно, с ТЗ и начались проблемы.
Как мы начали работать
Сначала всё шло неплохо. Мы подключили к проекту лид-дизайнера и лид-разработчика, решив, что с ними всё точно будет так, как нужно. Но уже на этом этапе мы совершили три серьезные ошибки:
- Поспешили подписать договор по фиксированной стоимости. Боялись не уложиться в сроки.
- Включили в коммуникацию джуна. Начинающий менеджер был не готов заниматься продуктом такого формата и размера.
- Не сформулировали подробное ТЗ. Оно было сформировано блочно в виде функциональных модулей приложения.
Да, написать качественное ТЗ непросто. Необходимо провести более глубокое интервью со стейкхолдерами, проработать и четко сформулировать требования. На это может уйти один-два месяца. При этом заказчики обычно хотят заключить договор в течение недели, невзирая на объем работ.
В итоге, мы начали проект без подробной карты. Как приложение должно было работать и выглядеть, никто не знал, решения планировались в процессе. В принципе, это жизнеспособная стратегия, но только со старыми клиентами, с которыми уже есть опыт взаимодействия.
Наши ребята были очень рады, когда мы взяли этот проект. Он действительно казался интересным, серьезным и прорывным, отлично ложился на наш технологический стек.
Но уже через месяц-два менеджер стал замечать проблемы: стейкхолдер подолгу не выходил на связь, а потом не согласовывал то, что было оговорено, вместо этого менял и расширял требования. Команда при этом вынуждена была двигаться быстро, чтобы успеть в срок. Поэтому нам приходилось додумывать спорные моменты и делать всё самостоятельно. Дело осложнялось тем, что мы общались со стейкхолдером не напрямую, а через непосредственного заказчика.
Такой испорченный телефон привел к тому, что начали возникать неприятные ситуации. Например, мы показывали заказчику дизайн, он принимал его со словами: «Все отлично, делайте дальше». А стейкхолдер через месяц говорил нечто вроде: «Всё совсем не то». На вопрос «что именно “не то”?» ответа мы или не получали или получали, но через месяц.
Были сложности и с менеджментом процессов. Мы поставили не очень опытного специалиста на достаточно сложный проект. В целом, было много «звоночков», но мы в силу загруженности не придавали этому столько значения, сколько было необходимо. Со временем мы поняли свою ошибку и закрепили за проектом лида. С тех пор, кстати, это стало нашей обычной практикой, но было поздно.
Когда всё пошло совсем не так
Через полгода мы поняли, что уходим в минус и наши разработчики уже не справляются. Мы начали анализировать процессы, менеджмент, разработку. И получили два варианта развития событий:
- Опираться только на ТЗ, на то, как мы его видим. Сделать всё по договору и закрыть проект.
- Получить больше фидбэка от заказчика, начать переработку. Это сохранит нормальную коммуникацию с заказчиком и поможет сделать то, что он хочет, пусть и ценой значительных финансовых потерь.
Мы попробовали оба подхода.
На первый, разумеется, пришел очень негативный фидбэк: заказчик потребовал доделать всё так, как ему хотелось. Менеджер настоять на своем не смог.
В эту коммуникацию включился я. Я был за стратегию переговоров.
В итоге, мы договорились, что заказчик купит у нас дополнительные версии, мы будем развивать продукт, и все нашли экстрарасходы окупятся. Сразу спойлер: нет, они не окупились.
Что было дальше
Мы начали стягивать в этот проект всю нашу экспертизу. Лид-менеджер взял его на себя, да и я серьезно погрузился в работу.
Последние 3–4 месяца работы мы пересматривали решения, шли навстречу заказчику, но воплотить все пожелания всё равно не смогли. Набрали огромный аутстаф, чтобы за неделю ускорить разработку и не подвести заказчика. А это дополнительные расходы, учитывая, что брали мы специалистов высокого ранга: не джунов и фрилансеров за 2 доллара в час, а крепких мидлов и сеньоров.
Сотрудники выгорали, некоторые увольнялись. В команде начались внутренние конфликты. Из-за этого проекта тормозились остальные. И примерно через год проект зашел в тупик.
Мы доработали задачу до максимально возможной финальной точки и закрыли ее с убытком 30 млн рублей. Наша команда с заказчиком не смогла защититься перед стейкхолдером, так что затраты не окупились.
Что мы вынесли из всего этого
Эта история привела нас к перестройке внутренних и внешних процессов. Теперь мы за каждым менеджером закрепляем лида. Используем новый подход к оценке стоимости проектов. За основу мы взяли методику из Scrum Джеффа Сазерленда:
- Отказались от оценки фичей, функционала, экранов и стали оценивать пользовательские истории.
- Отказались от оценки в часах — оцениваем сложность.
- Используем шаблонные пользовательские истории из нашей базы.
- Тщательно описываем рамки, если заказчик выбирает модель Fixed Price: никаких иносказаний и вторых смыслов. Это защищает нас от «а мы передумали», «мы решили по-другому» или «а мы не так себе это представляли».
- Еще более скрупулезно рассказываем заказчикам о стоимости и сложности проекта. Предлагаем ему выделить MVP и выбрать разработку по T&M.
От ошибок никто не застрахован, но при таком подходе, даже если мы сделаем что-то не так, то потеряем 2 миллиона, а не 30, и сэкономим время. Потерянный месяц разработки не так страшен, как потерянный год.
Добиваться успеха — вполне естественное желание для человека. Все мы ...
Личные границы — это рамки дозволенности для другого человека, это ...
Вовлечённость — это эмоциональное и интеллектуальное состояние сотрудников, которое позволяет ...
Клиентские данные — то, что каждый бизнес должен собирать и ...
