Три ошибки, приводящие к бесконечной разработке проекта

Меня зовут Валерий Комягин, я основатель SVK.Digital.

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

В двух словах — есть огромный e-commerce, технологии и архитектура которого давно устарели. Поддерживать и развивать его больно, дорого и оооочень долго: из-за устаревшей архитектуры каждая новая функция разрабатывается вчетверо дольше обычного и требует тщательного тестирования, которое все равно не защищает на 100% от поломок в уже работающих частях системы.

Было принято, казалось бы, правильное решение - разработать современную архитектуру силами приглашенной команды талантов и переключить клиентский поток со старого проекта на новый.

В результате потрачено несколько лет, космическая сумма денег, по пути сменено три супер-коллектива (реально топовые команды рунета), а воз и ныне там.

Знакомо? Что пошло не так и как, на мой взгляд, такую проблему можно было бы решить более эффективно?

Текущий проект строили не один год. И ожидать, что “девять женщин выносят ребенка за месяц”, как минимум, наивно. Бизнес утверждает: “мы не можем согласиться на выпуск проекта с неполным функционалом — нам нужен весь функционал”. Разработка пожимает плечами и … постепенно закапывается в нюансах, превращая разработку проекта в “вечнострой”.

Более эффективным было бы согласиться на реализацию неполного функционала и запуск обновленной версии проекта в “фоновом режиме”. Да, это удорожило бы разработку: наряду с постепенным вводом в строй новых функций пришлось бы обслуживать уже выпущенные. Но проект стал бы более управляемым и заметить ощутимые отклонения от графика можно было бы гораздо раньше (а значит и минимизировать потери).

При грамотном руководстве проектом, “next-gen версия” постепенно набрала бы функционал, достаточный для “переключения версий”. И даже тут я бы не рекомендовал спешить — новую версию я бы вводил в строй, постепенно переводя на неё трафик (например, сперва переключив только самую лояльную часть аудитории, готовую прощать ошибки).

Со слов моего товарища даты первой демонстрации продукта переносились уже бесчисленное количество раз. За годы разработки руководство видело лишь бесконечные презентации.

Хорошего руководителя продукта (Product Owner) такая ситуация должна была бы, как минимум, насторожить. Чем чаще нарушаются обещания, тем плотнее и чаще осуществляется контроль — для меня это одно из главных правил проектного менеджмента.

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

Насколько я понял из разговора с товарищем — проект давно и кратно вышел за пределы изначально выделенного на него бюджета.

Здесь у меня нет какого-то однозначно верного решения. Действительно бывают ситуации, когда бесконечные инвестиции в проект в конце-концов окупаются (расскажу в одном из последующих своих постов об игровом проекте другого своего знакомого, который сорвал сроки и бюджет в разы, но … при этом в конце-концов вышел в плюс и стал очень успешным игровым проектом).

Но в целом всё-таки у проекта должны быть бюджетные ограничения, которые не могут расширяться бесконечно. Особенно, если динамика проекта не очевидна или отсутствует вовсе (вспоминаем о бесконечных презентациях). В какой-то момент решение остановить проект и зафиксировать убыток может спасти инвестору гораздо бОльшие средства в перспективе, чем выделение очередного транша финансирования в надежде спасти уже вложенные средства.

В нем я делюсь своим честным мнением о продуктовой разработке, развитии стартапов и управлении IT-командами.