Привет, Хабр! Наши ошибки на старте проекта — самые дорогие из возможных.

Я Мария, аналитик команды обследования проектов. В смысле, работаю с проектами до старта разработки. Это обычно называется «дискавери». Я уже делала 15 этих самых дискавери, и не все были настолько прекрасными, насколько бы этого хотела я или мои заказчики. Когда дискавери проваливаются — это один из обычных вариантов на практике.

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

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

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

Сейчас я и хочу про это рассказать.



Классический процесс дискавери (так называется изучение проекта) состоит из таких шагов:

• Изучение клиента: мы собираем все доступные данные и хотелки.
• Подготовка документации.
• Подготовка расписания встреч и активностей.
• Анализ, работа и формирование решения.

Коротко — да, но нет. Может быть вот так, например:



Начать надо с понимания типа дискавери.

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

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



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

Пример. Однажды нас позвали проводить дискавери по созданию интернет-магазина. Мы были в E-commerce команде. Для нас это была обычная активность. Мы собрали стандартную команду, собрали предварительный план артефактов, уже накидали драфт бэклога. Но когда мы пришли к самому заказчику и стали выяснять цели, оказалось, что ему не нужен интернет-магазин как таковой. Он не хочет продавать, это для него невыгодно. Чего же он хочет? Он хочет собирать пользовательскую аналитику по всем тем пользователям, которые зашли на страницу продукта, но не сделали покупку. Зачем ему это надо? Потому что основная прибыль этого заказчика была на всяких событиях, куда он, собственно, звал и приглашал всех этих некупивших пользователей. Для него это было намного выгоднее. Что же это значило для нас как для команды? Собственно, всё: нам надо было заново перепланироваться, нам надо было заново собирать нашу команду. Мы включили очень много туда веб-аналитиков, которые нам помогли построить грамотные пользовательские метрики. Мы поменяли полностью команду со стороны заказчика. Потому что изначально нам нужны были сотрудники склада, сотрудники маркетинга, сотрудники бухгалтерии. Сейчас же нам нужны были маркетологи, которые и занимались этими мероприятиями, на которые мы активно звали пользователей. Понимание цели резко развернуло проект. И если бы мы сделали то, что было в договоре, недовольны были бы все, а сама разработка, скорее всего, была бы сделана зря.



Ещё пример. Нас позвали на обследование. Цель заключалась в том, чтобы мы проработали стратегии по цифровой трансформации бизнеса заказчика. Для него было важно, чтобы мы предложили ему календарный план с этапами, активностями, предложили бы примерный состав команд, который мог бы ему помочь на каждой конкретной фазе. Но получилось так, что нам как основным контактным лицам выдали архитектора, который был вообще не заинтересован в том, чтобы эта цифровая трансформация случилась. Что было по итогу? Когда мы делали какие-то активности, архитектор спрашивал у нас, к примеру: «А сколько у вас будет фичей в конкретном эпике? А когда вы планируете взять такую или иную задачу в работу? А сколько у вас дефектов вообще намечается?» То есть вопросы были такого уровня, на которые мы, естественно, не могли ответить. И каждая наша встреча отодвигала нас на шаг назад, мы не могли выполнить те цели, ради которых пришли на проект. Из-за того, что заказчик не был заинтересован, из-за того, что превалировал микроменеджмент. И в итоге, естественно, мы сорвали сроки. Естественно, проработка всей нашей документации была не на том уровне, на котором от нас ожидалось.

Поэтому важно правильно планировать время. 8 недель вы проводите ваше дискавери или за 4 часа. Естественно, и коммуникационный план, и заказчики, с которыми вы общаетесь, и качество проработки документов, и предоставление информации заказчику очень сильно отличаются.

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

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

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

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

Так что делать-то?

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

Дальше я заполняю каждый параметр своими характеристиками. Я пишу что-то о нас, я пишу о заказчике. Что-то даёт менеджер заказчика, что-то я узнаю из открытых источников, что-то уже есть по прошлым проектам.

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


Пример шаблона таблички

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

Потом вы выходите на встречу с заказчиком и согласовываете ваш подход. Зачем это надо? Когда вы пришли к заказчику с готовыми документами, планами, можете обосновать каждый ваш шаг, почему это так, что это вам даст, а что будет, если вдруг вы не сможете так сделать, экспертиза ваша как специалиста в глазах заказчика вырастет в геометрической прогрессии, уж поверьте.

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

Бывают ли дискавери без боли? Вероятно, бывают. Но я не видела никогда. Часто ли дисквери совмещается с деливери? В нашей практике, к счастью, редко, но процентов 10 проектов как раз такие.