Как сдать проект, когда заказчик не согласен на релиз
Приложение уже прошло проверки, лежит в сторах и ждёт лишь нажатия волшебной кнопки «Сделать рабочей версией», но компании-разработчику не дают добро на релиз. С нами так происходило трижды на разных проектах, прежде чем мы поняли, что это не случайность и не совпадение.
Тогда мы придумали этому явлению название — «релизная импотенция», и определили, какие симптомы должны насторожить на старте проекта. Я Лена Гика, менеджер портфеля проектов KODE, и я расскажу, как в такой ситуации помочь команде и заказчику. С этой темой я выступала на конференции Mind Bros Conf и меня завалили вопросами. Готова ответить на ваши в комментариях, но сначала немного проектных историй.
Три случая, между которыми нет ничего общего. Или есть?
Первый кейс с отложенным релизом у нас появился в 2016 году на проекте для крупной авиакомпании. Ещё даже не выпустив приложение, мы начали делать его полный редизайн. При этом заказчик захотел усложнить сценарий регистрации на рейсы с пересадкой. Дизайн тогда рисовал сторонний подрядчик. Наша команда просто иногда сидела и ждала готовые макеты.
Странная ситуация, но клиент этого хотел и платил, поэтому мы пожали плечами, потеряли какое-то время и продолжили работу. Списали всё на случайность.
Вторая похожая ситуация произошла на банковском проекте. Мы не могли выйти в релиз, потому что у заказчика постоянно появлялись новые идеи:
— Сделаем перевод между счетами и сразу зарелизимся.
— Подождите, нам обязательно нужна оплата коммунальных платежей!
Наш аккаунт вместе с проджектом постоянно держали оборону, предлагали заказчику выпустить релиз, а потом выкатывать регулярные обновления. Заказчик был непреклонен: только полноценное приложение — урезанную функциональность выпускать нельзя. В итоге релиз сдвинулся на 4 месяца. Ничего общего с кейсом авиакомпании мы не увидели, просто совпадение.
В третий раз причины отложенного релиза были другими. Приложение для известного банка мы делали совместно с несколькими подрядчиками. Выполнили свою часть и стали ждать масштабного совместного тестирования. Оказалось, что доработка бэк-офиса на стороне банка раньше не тестировалась и с нашим кодом дружить не готова. К тому же в банке был очень долгий релизный цикл: исправления минимальных ошибок приходилось ждать до трёх недель. В итоге цикл тестирования длился 4 месяца. Релиз выпустили спустя 5 месяцев после запланированной даты. После этого случая мы уже не могли отрицать закономерность.
В нашем словаре сначала в шутку, а потом и всерьёз появился термин «релизная импотенция».
На что влияет релизная импотенция
Мы заметили пять факторов, и все они значимы для подрядчика.
- Прибыль. Если вы работаете по договору с постоплатой, то задержка релиза не даёт её получить, тогда растёт дебиторская задолженность.
- Взаимоотношения с заказчиком. Мы предлагаем выйти в релиз, но заказчик против — накал и недовольство обеспечены, возможен даже разрыв договора.
- Репутация подрядчика. Даже если вы всё согласовали и подписали, а заказчик понимает, что есть препятствия к релизу, он всегда будет держать в голове ту самую дату, которую ему обозначили на первой встрече.
- Недовольство команды. Люди не любят работать в стол, они хотят видеть результат. Приложение не выпущено — команда нервничает, расстраивается, выгорает. Потом идёт писать в твиттере, что вы плохой работодатель.
- Рейтинги. Нет приложения в сторах, нет ссылки на веб-сервисах — приложения не было. Для отраслевых рейтингов и конкурсов вы не существуете.
Тревожные симптомы релизной импотенции
Когда мы поняли, что проблема есть, и у неё серьёзные негативные последствия, то стали думать, как отследить негативные сигналы на любом из этапов проекта.
🚩На что обратить внимание подрядчику
- «Сначала разработаем, потом подумаем насчёт релиза». На старте проекта обсуждаем организационные вопросы: кто будет участвовать в созвонах, какие письма будем писать, кого ставить в копию важных писем. В том числе всегда спрашиваем, как будем релизиться. Если ответа нет или он уклончивый, это повод задуматься.
- Несколько подрядчиков, между которыми не выстроена коммуникация. Такой пример у нас был на проекте с авиакомпанией. С подрядчиком, который поддерживал систему бронирования билетов, мы общались только официальными тикетами в саппорт-системе: запрос в техподдержку — ответ в течение двух недель. Нельзя было просто позвонить на ту сторону.Ошибки часто требуют максимального погружения, контекста, общего информационного поля. О какой коммуникации может идти речь, если в цепочке отвечает то Вася, то Люба, то Леонид, и вы каждый раз объясняете, в чём дело. Такой подход существенно осложняет выход в релиз.
- В проекте не участвует ЛПР. Подобный кейс застал нас врасплох. К нам обратилась компания и попросила сделать мобильное приложение для одного банка. Мы общались только с командой партнёра, согласовывали с ними дизайн и требования. В конце проекта, прямо перед релизом, они решили хоть кому-то показать результат на стороне банка. Разумеется, там ответили: «Что это такое? Что за главный экран, что за цвета, что за механика? Для чего нужно приложение? Кто вам это согласовал?». Апелляции к компании-партнёру не дали никакого результата: «Ребята, ну конечный заказчик — банк. Идите с ним и разбирайтесь». Нам пришлось поднимать все договорённости, требования, дизайн и заново пересматривать сценарий всего мобильного приложения.
Может оказаться, что ЛПР — лицо, которое, как вы думаете, принимает решения, на самом деле ЛППР и принимает промежуточное решение. В таком случае итоговое решение вам могут принести прямо перед релизом.
- Смена ключевой фигуры в команде заказчика. Если такое происходит на проекте — это риск, но с ним можно работать. Проблема — когда ключевую фигуру меняют в финале проекта, тогда сдача может осложниться.
🚩На что обратить внимание заказчику
- Излишний перфекционизм. Проект идёт, подписаны документы, есть все артефакты и полная прозрачность в процессах. Вы даже успеваете по срокам, но кажется, чего-то не хватает или недостаточно хорошо сделано. Перфекционизм может быть полезен, но в то же время может помешать релизу. Продукт станет неактуален, появятся новые ограничения или требования. В проекте для европейского банка мы тоже долго ждали решения заказчика. Всё было готово к релизу, но они думали, не нужно ли добавить подписание кредитного договора или другие фичи. В последний момент Евросоюз ввёл новые требования к обработке персональных данных — GDPR. Банку пришлось полностью перетряхивать свою инфраструктуру и вносить изменения во все фичи. Как вы понимаете, релиз был отложен.
- Желание пофиксить абсолютно все баги перед релизом. Этот пункт всегда вызывает вопросы. Бизнес хочет получить работающий продукт, но не готов признать, что в нём могут быть ошибки. Разрабатываемый продукт всегда не статичен. Меняются условия использования, меняются устройства. Компания-разработчик, конечно, старается заранее прогнозировать все ситуации, в которых продукт будут использовать, но только открытое тестирование точно покажет, где нужно укрепить систему.
Какие решения мы придумали
Сейчас в нашем проектном офисе работает 26 менеджеров, у них разный опыт и навыки. Чтобы каждый из них, видя подобную ситуацию, в одиночку не изобретал велосипед, мы взяли выявленные сигналы, продумали решения по ним и зафиксировали их во внутренней wiki нашего отдела.
Что может помочь подрядчику
- Сдавать проект на моковых данных. Если видим, что часть проекта, за которую отвечает другой подрядчик, может пойти не по плану, то предлагаем заказчику симулировать её. На одном из проектов мы разрабатывали только фронтенд. Выполнили свою часть работ и стали ждать, когда с бэкенда начнут приходить данные. Данные так и не пришли, а без них систему не проверить. Из-за сложностей на стороне второго подрядчика дедлайны не отменили, поэтому мы предложили свою часть смоделировать. Для этого завели все данные в StopLight, который фактически выступил сервером для нашего приложения, показали и сдали проект.
- Заключать отдельный договор техподдержки. Это помогает, когда разработка по основному договору завершена, проект сдан или даже выпущен первый релиз. Следом можно заключить новый — на техподдержку с фиксированной стоимостью в месяц. Таким вариантом мы воспользовались на проекте для крупного лоукостера. Первый релиз выпустили по основному договору, но там были определённые риски, поэтому заключили отдельный на техподдержку. В нём прописали условия и стоимость в месяц, которую вычислили исходя из загрузки команды. Договор техподдержки даёт нам независимость от заказчика. Если релиз задерживается — всё равно получаем прибыль, сохраняем взаимоотношения и полную прозрачность. Заказчика этот вариант тоже устроил.
- Заключать отдельные допсоглашения. Придумали какие-то новые работы — заключили допник, закрыли его. Работы по основному договору к этому моменту уже должны быть завершены.
- Операция «Отладочный рывок». Подходит для проектов со множеством интеграций с другими подрядчиками. Договариваемся собраться все вместе, навалиться и сдать проект. Да, у нас не будет соблюдения процессов и установленного релизного цикла, но зато можно сделать много за короткое время.
- Продавать этап отладки и внедрения отдельно. Этот вариант предлагаем, если на стадии подписания договора видим какие-то мелкие признаки. Например, возможные сложности с интеграцией, свежее, не обкатанное API, или длинная цепочка согласований. Мы делаем основную разработку, закрываем документы. Затем тестируем или внедряем новые фичи просто в рамках этого отладочного этапа.
- *Не начинать разработку до приёмки стороннего кода. Решение под звёздочкой, потому что может работать только в идеальном мире. Если у вас были такие примеры, поделитесь в комментариях.
Что может помочь бизнесу
- Мотивированный и опытный менеджер проекта со стороны заказчика. Человек будет владеть всем контекстом приложения, станет связующим звеном. Желательно, чтобы он не совмещал свою роль с основной должностью маркетолога, сейлза или технического специалиста, иначе ему не хватит времени на проект. Многие наши кейсы случились именно потому, что на стороне заказчика не было такого человека. Подрядчик тоже может брать на себя эту роль, но ему нужны полномочия, чтобы настраивать процессы.
- Заранее думать, чем будет наполнен сервис или приложение. Даже маленькое приложение требует пользовательских инструкций, политики конфиденциальности или описаний товара, если речь идёт о каталоге. Подумайте, где будете размещать сервис, в какие сторы хотите релизить приложение, и кто это будет делать: вы сами или подрядчик.
- Создавать общие роадмапы с подрядчиком. Проект — это целая экосистема. Обычно её создают несколько подрядчиков. Заказчику важно понимать, что происходит в каждый момент. Для этого нужны общие роадмапы и та самая прямая коммуникация. Здесь может помочь менеджер на вашей стороне, потому что это его зона ответственности.
- Думать, что будет после релиза. Странно выпустить приложение и забыть про него. Что будет дальше, нужна ли техподдержка, нужно ли подключить колл-центр для обработки обращений — обо всём нужно думать заранее.
- Понимать, для кого вы делаете приложение. Если для себя — окей, мы всё делаем. Если приложение для пользователей, то, пожалуйста, выключите суперэкспертность. Пользователю неважно, в какой категории будет шуруповёрт: электроинструмент, ручной инструмент или инструмент с вращательным моментом согласно товарной номенклатуре. Узкие фичи нужны не всем.
- Доверять исполнителю. Скорее всего, вы его долго выбирали и даже проводили тендер. Чтобы проверить исполнителя, спросите: «Как будем релизиться?» или «Что нам нужно для релиза?». Компания, у которой в портфолио много успешных кейсов по сдаче проектов, всегда расскажет, что нужно, подготовит план и предложит помощь.
- Планировать работу с учётом отпусков. Если вы выпускаете приложение и именно на вашей стороне находится человек, который нажмёт ту самую волшебную кнопку, поинтересуйтесь, когда у него отпуск. Может произойти так, что он вернётся довольным и отдохнувшим, а вы, прождав его месяц, таким не будете. Это, кстати, тоже реальный кейс.
Эти сигналы и решения мы используем на реальных кейсах. В нашей команде каждый менеджер отслеживает, могут ли в конце проекта возникнуть проблемы, и старается их предотвратить. Инструменты, которые мы предлагаем, работают, но, как часто бывает, не на сто процентов. К сожалению, виагры от релизной импотенции ещё не придумали, поэтому грамотно продумывайте процесс сдачи проекта, отслеживайте сигналы недуга и не забывайте про настойчивый релиз-менеджмент.