Ошибки на старте проекта обходятся дороже всего. Как их избежать?

Рассказываем о дискавери — особом этапе в разработке.

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

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

Процесс дискавери по методичке состоит из логичных шагов и выглядит понятно и вдохновляюще. Надо просто:

1. Изучить клиента, собрать все доступные данные и пожелания.

2. Подготовить документацию.

3. Составить график встреч и активностей.

4. Выйти «в поля» и собрать данные.

5. Проанализировать и выдать решение.

Вуаля – всё готово.

И вот выходишь на реальный проект. Нужно получить данные от заказчика, а у него документацию мыши съели, или трубу прорвало, или ответственный сотрудник в отпуск ушёл/заболел/в свадебное путешествие уехал. А этап изучения ужали до недели вместо восьми, потому что сроки поставки оборудования поплыли.

Дедлайны контракта подгорают, струны нервов команды и заказчика выдают вместо слаженного бодрого марша какофонию... Потому что может быть, к примеру, вот так:

Как всё это учесть, чтобы сделать работу на хорошем профессиональном уровне в условиях неопределённости?

В самом начале, когда команда ещё не зашла на проект, важно хорошо продумать, что именно нужно делать в каждом конкретном случае.

Например, требуется разработать решение с нуля. Это Product Discovery. Нужно проработать представление о потребностях пользователей и дать ответы на ключевые вопросы для построения roadmap — дорожной карты проекта: что конкретно надо заказчику, стоит ли решать проблему, как конкретно её решить, будет ли это окупаться. Здесь будет свой набор активностей, инструментов, артефактов.Активности тут ориентированы на понимание того, что должно быть в этом решении, какие функциональности оно должно закрывать.

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

А если наша задача предполагает тип Data Discovery, то есть сбор и объединение данных из нескольких источников, чтобы быстро провести анализ и оценку, и нам требуется работать с информацией, то в этом случае ключевые факторы будут другие: команда другая, артефакты, время на проведение и прочие сопутствующие моменты.

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

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

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

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

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

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

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

А потом оказалось, что не собирался заказчик ничего через этот интернет-магазин продавать. Ему было нужно собрать аналитику по посетителям, которые в магазин зашли, а покупку не совершили. И вот вроде зачем ему это надо было? А всё просто: основная прибыль у него была не на продуктах магазина, а на событиях, он на них как раз и приглашал всех тех, кто не купил ничего. Выгоднее это ему было. То есть цель была вовсе не в стандартных задачах интернет-магазина. Но чтобы это проговорить и выявить, пришлось изрядно постараться.

Для нас как для команды это изменило всё — пришлось и план, и команду менять. Мы добавили классных веб-аналитиков, которые сделали грамотные пользовательские метрики. И со стороны заказчика команду пришлось изменить. На старте были задействованы работники склада, отдела маркетинга, бухгалтерия. А с новой задачей потребовались маркетологи тех ивентов, куда людей приглашали. Новая цель проект развернула. Заказчик остался доволен. А не добейся мы истинных целей и сделай всё по договору, остались бы недовольны примерно все. И работа могла улететь в корзину.

Ещё пример. Пригласили на обследование. Цель состояла в разработке стратегии цифровизации бизнеса заказчика. Ему нужен был календарный план, разбитый на этапы, перечень активностей и примерный состав команд для реализации каждого этапа. А со стороны клиента нам дали архитектора, он был совершенно не заинтересован в том, чтобы этот проект состоялся, это его положение в компании заказчика затронуло бы нежелательным образом. И мы попали в режим микроменеджмента в этой коммуникации, где каждая встреча откатывала нас на шаг назад. Он задавал нам вопросы, которые к целям проекта не приближала, и в результате мы в сроки не уложились. И не только в сроки: документация и глубина её проработки клиента не удовлетворила.

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

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

Ещё риски нужно учесть и альтернативные сценарии продумать, где что может пойти не так. Например, вы онлайн-встречу или воркшоп запланировали в одном инструменте, всё подготовили — а инструмент не запускается. Или демонстрация экрана не сработала — что сделаете? Нужен план «Б», чтобы не потерять время и выполнить плановые шаги.

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

Таблица простая, наглядная и работать с ней удобно:

1. Заполняю характеристики: пишу про свою команду, получаю данные от заказчика, что-то беру из разных доступных источников, что-то знакомо по опыту прошлых проектов.

2. Прописываю зоны влияния: если что-то пойдет не так, что изменится? Как воздействует на артефакты, инструменты, глубину проработки документов и прочее, что нужно учесть.

3. Определяю уровень значимости влияния: например, заказчик документы не предоставил — насколько это будет критично? Надо ли как-то этот риск митигировать, надо ли мне в этом участие принимать, или это будет не настолько критично, и можно просто принять и всё.

4. Для всех активностей прописываю точки контроля и ответственных — себя или кого-то из команды.

Когда таблица заполнена — это уже основа плана, на ней выстраивается подход. Можно перемещать блоки, учитывать риски (например, если кто-то заболел, или в командировку поехал, или что-то ещё).

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

5. И только сейчас можно приступать к исследованию.

Можно ли провести дискавери, ни разу не наступив на грабли непредвиденных ситуаций?

Возможно, это достижимо. Но я не встречала.

Можно ли обойтись без дискавери?

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

Увеличивает ли дискавери стоимость проекта?

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