«Слушайте, я тут такое придумал…» Как запустить продукт в бюджет и срок, если ожидания клиента изменились

Итак, вы закончили работу над годовым ИТ-продуктом. За полгода работы изменился рынок, бизнес заказчика и мир. Но все это ерунда в сравнении с изменившимися ожиданиями клиента.

Меня зовут Иван Лощёнов, я комдир компании Nutnet. Мы занимаемся заказной разработкой сайтов, сервисов и приложений, а также поддержкой и развитием уже готовых продуктов.

Беремся за сложные проекты, которые выходят за рамки типовых решений. Например, делали PWA-приложение для Porsche Taycan и огромную медиа-платформу для ИТАР-ТАСС.

Мы столкнулись с изменившимися ожиданиями заказчика на одном из проектов и провели ретроспективу. Рассказываю, почему считаем, что чужие ожидания — наша проблема. А также — как разработать проект в срок, уложиться в бюджет и сохранить отношения с клиентом.

Расскажу на примере двух кейсов: провального и успешного.

К нам обратился ресторанный холдинг из Ижевска «Велком групп», они запускали «статусный» ресторан быстрого питания. В рамках проекта мы взяли на себя 2 задачи.

1. Разработать коннектор — веб-сервис, который состоит из набора интеграций между информационными системами. Он должен был объединить внутренние инструменты вроде сервиса доставки с данными о клиентской базе (R-Keeper CRM) и заказах для кухни (R-Keeper). Этот продукт потребовался, чтобы все системы могли оперативно обмениваться актуальной информацией.

2. Создать сайт и мобильное приложение на базе коннектора. Они предназначались для заказа доставки и блюд в самом ресторане. Через них клиент мог, например, не ходить лишний раз на кассу, а взять позицию из меню в приложении, которое через коннектор связывался с системой R-Keeper.

Забегая вперед, в процессе мы обнаружили много проблем в нашем управлении разработкой. Из-за них многое пошло не по плану.

Проблемы в процессе разработки были как объективными, так и субъективными.

Проблема 1. Псевдоконтур MVP и отсутствие итераций. После этапа проектирования и сбора требований проект расширился. По нашим оценкам, первая версия продукта начала превышать 2 500 часов разработки.

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

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

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

При этом заказчик ежемесячно оплачивал разработку по системе Time & Material. Это значит, что он платил не за конечный результат, а за потраченное нашей командой время. Мы планировали задачи на месяц и в сметах отчитывались о выполнении. Клиент подписывал их, оплачивал и закрывал актами.

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

Проблема 3. Регулярное изменение контура проекта. Границы проекта постоянно менялись со стороны заказчика. Наша команда считала, что клиент при этом учитывает увеличение бюджета и периода разработки. Однако руководитель проекта со стороны заказчика из-за загруженности не мог постоянно отслеживать работу нашей команды. Поэтому ни с нашей стороны, ни со стороны клиента не было достаточного управления новыми требованиями.

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

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

При этом мы не отслеживали эти изменения, не фиксировали и никак не оценивали их. В итоге бюджет и сроки по проекту выросли в 2 раза по сравнению с ожиданиями на старте. Это стало неожиданностью для «Велком групп».

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

Проблема 5. Неорганизованное хранение знаний на проекте. На момент релиза команда не владела всеми артефактами разработки. Во-первых, проект значительно затянулся. В течение этого периода мы дважды меняли руководителя проекта. Во-вторых, разработка шла по T&M, и мы нерегулярно обновляли первичное техзадание. Так проект обрастал новыми знаниями, которые никто не фиксировал и не помнил. К концу работы это сильно осложняло понимание — к чему мы должны были прийти.

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

Проект превзошел зафиксированные сроки и бюджет почти в 2 раза. На старте мы планировали уложиться за 9 месяцев и потратить 3,7 миллиона рублей (бюджеты 2020 года). В результате ушло 15 месяцев и 5,8 миллионов рублей. Безусловно, клиент остался этим недоволен.

Мы проанализировали этот опыт сотрудничества и вывели новые принципы работы. Их мы стали применять в дальнейшем — например, в проекте Kamon!.

Изначально студия танцев пришла с запросом создать онлайн-школу. У клиента было много идей по развитию проекта, но он не представлял себе первую версию продукта. Мы помогли спланировать процесс работы и разбить его на этапы — что войдет в MVP проекта и следующие его версии.

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

Мы внедрили новое управление разработкой, основанное на анализе ошибок из проекта «Велком групп».

Разработали контур MVP и двигались по этапам. Мы не делали все проектирование и дизайн сразу, а закрывали простые задачи. На каждом спринте реализовывали какой-либо этап продукта. Например, сначала разработали и продемонстрировали базовый функционал. После этого создали простую первую версию продукта: сделали дизайн, согласовали, сверстали, реализовали вывод информации.

Привели в соответствие модели разработки и оплаты. Двигались по T&M и намечали спринт, то есть понимали перечень задач на короткий временной промежуток. По его итогу клиент мог попробовать в действии простой функционал, увидеть прогресс и сразу заявить о своих ожиданиях. А наша команда — не выполнять лишних задач, которые не усилят проект.

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

Улучшили планирование и управление рисками. Сложную задачу мы сделали на старте, а не в конце. Самым непонятным в проекте Kamon! оказалась реализация плеера. Наша команда провела анализ и подумала, как будет его делать и сколько времени это займет. Мы согласовали эти моменты с клиентом. Решили, что если не можем реализовать нужный функционал в четкие сроки, то двигаться дальше по проекту не имеет смысла.

Таким образом, мы реализовали MVP на согласованных в начале проекта условиях. Привели его к желаемому виду и запустили в пределах того времени, на которое ориентировались — 4 месяца. А бюджет проекта с таким подходом даже сократился: он стоил клиенту 1,5 миллиона рублей вместо запланированных 2.

В конце апреля Kamon! уже стартовали с этим сервисом на базовом функционале, чтобы протестировать его и собрать обратную связь от аудитории. Дальше у нас в планах еще 2 UVP-этапа проекта — доработать и создать уникальную обучающую платформу, а также увеличить вовлеченность пользователей через социальные сервисы.

Таких результатов невозможно было бы достичь без изменений в управлении разработкой. Если бы мы не перестроились, то работали бы над первой версией для Kamon! до сих пор.

Более подробная информация о кейсе Kamon! в нашем телеграм-канале:

После этих двух проектов мы усилили свою продуктовую экспертизу и управление разработкой. Теперь мы выстраиваем сотрудничество так:

Эти принципы позволяют команде уложиться в сроки и подготовить первую версию продукта, которая ответит запросам пользователей и увеличит шансы окупиться (но это неточно ¯\_(ツ)_/¯, читайте про важность бэк-офиса в продукте).

Если вы не хотите потратить деньги и время ради проекта в «стол» — пишите, мы готовы валидировать вашу идею перед началом разработки.