Роман Римша

Co-founder в Cortlex

Зачем IT компании проходить через Discovery Phase и как провести ее грамотно? Как нужно оформлять сопутствующую документацию?

Рассказывает co-founder Cortlex и Sales-консультант Роман Римша, который также делится реальным планом Discovery Phase для типичного проекта в IT компании.

Обратите внимание и на другие материалы Kraftblick.Media:

Как IT компаниям повысить Win Rate: работаем с пресейл в продажах.

Как построить работу над Proposal на этапе Presale, чтобы заполучить контракт. Кейс с Toyota.

Как получать деньги от клиента круглый год: идеи для Q1-Q4 от Telesphor Software.

Как IT компании заваливают ABM кампании при работе с энтерпрайзами. Топ ошибок.

В этой статье вы прочитате:

• Зачем нужна Discovery Phase
• Из каких этапов состоит Discovery Phase
• План-шаблон для Discovery Phase
• Discovery Phase для продуктовой и аутсорсинговой компании
• Пример Discovery Phase для типичного проекта аутсорсинговой компании

Зачем нужна Discovery Phase

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

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

Это одна из наиболее важных фаз при работе с клиентом, т.к. от ее результата зависит качество продукта или уровень сервиса, который вы предоставите, причем именно в понимании клиента.

Ведь даже если вы сделаете все на высшем уровне, но это будет совершенно не то, что требовалось клиенту, вы по факту провалите проект.

Discovery Phase важна как для самого IT бизнеса, так и для заказчика.

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

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

Для клиента Discovery Phase может снизить финансовые риски из-за прекращения сотрудничества.

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

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

Тогда в случае ошибки потери будут составлять, например, $10k, а не $100k и выше.

Из каких этапов состоит Discovery Phase

Процессы в Discovery Phase зависит от 1,000+1 фактора: как со стороны поставщика, так и со стороны клиента.

Я скорее выделяю здесь то, что должно быть разработано по факту выполнения процессов (в любой последовательности), чем перечень обязательных работ:
 

Это планы финансирования/бюджетирования, матрица взаимодействия между сотрудниками со стороны заказчика и исполнителя, карта компетенций.

Пример матрицы коммуникации.

3. Разработка бизнес-документации.

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

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

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

План-шаблон для Discovery Phase

Этот шаблон я рекомендую адаптировать под проект.

Пример плана Discovery Phase на 4 недели

Затраченное время на Discovery рекомендую рассчитывать в размере 10% от запланированного на весь проект.

Например, если реализация будет длиться 10 месяцев, на такой план Discovery Phase стоит отводить не больше 1 месяца.

Неделя 1

• Обсуждение целей и нужд бизнеса
• Демонстрация текущего продукта
• Совещание по поводу требований as-is (как есть)
• Обсуждение будущего сотрудничества

Работает бизнес-аналитика и проектного менеджера.

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

По сути, тут нужно определить, что сделать/пообещать и в какой формулировке, чтобы получить заказ.

Неделя 2

• Совещание по поводу технической оценки
• Совещание по поводу требований to-be (что должно быть)
• Совещание по поводу требований (функциональные, нефункциональные, переходные)
• Обзор визуального стиля

Это все выполняет технический специалист со стороны исполнителя, в идеале, в связке с техотделом заказчика.

За этот период IT компания должна сформулировать в технической плоскости, как достичь желанного для клиента.

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

Неделя 3

• Ограничения по объемам
• Приоритезация объемов
• Определение объема MVP
• Обзор архитектуры
• Анализ процессов SDLC

Выполняют работы за неделю технический специалист в связке с проектным менеджером.

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

Всячески продемонстрировать, как эффектно это будет выглядеть.

Неделя 4

• Обоснование объемов для релиза 1.0
• Описание требований

Все в рамках рабочей недели выполняет проектный менеджер.

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

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

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

Поэтому 2-3 такие презентации съедят немалую часть бюджета компании.

За просто так подобные шаги не делаются.

Если клиент понимает выгоды от такой кропотливой работы с вашей стороны (а вы должны ему это донести на предыдущих этапах прогрева), то он легко оплатит вам всю Discovery Phase.

По образцу расчета времени я предлагаю рассчитывать и стоимость ― 10% от общего прогнозируемого вами бюджета проекта.

Discovery Phase для продуктовой и аутсорсинговой компании

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

Разумней определять подход к Discovery Phase в зависимости от проекта.

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

Если же это сложный продукт, внедрение которого требует изменений во всей IT инфраструктуре компании-заказчика, тут придется потрудиться.

Стоит смотреть на время, бюджет, требования к работе.

Если проект с детализацией в несколько томов документации, процессы наращиваются.

Тем не менее, я работал со многими сервисными компаниями со штатом от 10 до 1,000 человек.

Несмотря на чек, продукт/услугу и географию все они сталкиваются с похожими проблемами:

• Неумение правильно организовать работу в компании
• Ошибки в планировании бюджета или дедлайнов на этапе Discovery Phase
• Недостаточная или неверная выгода для клиента с точки зрения его истинных потребностей

Если верить статистике McKinsey, лишь 1 из 10 компаний так или иначе удовлетворит клиента по всем фронтам.

Опять-таки, с точки зрения самого клиента, ведь бизнес может считать свою работу выполненной на 101%.

Специфика аутсорсинговой работы на Discovery Phase сейчас распространяется практически на весь IT бизнес, так как пандемия перенесла все коммуникации в онлайн.

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

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

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

Грамотно оформляйте каждый документ, который отправляете заказчику

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

Именно поэтому в рабочей команде Discovery Phase всегда должен быть дизайнер.

Учитывайте все затраты, даже наименьшие

Покупка шрифтов, стоковых изображений, развертывание инфраструктуры на тестирование, пусть и на пару часов.

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

Тут поможет грамотный бизнес-аналитик, которого нужно включать в качестве менеджера проекта в команду (в тесной связке с инженером или СТО).

Изучайте заказчика

Профили в соцсетях, прошлое в других компаниях/отраслях.

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

Пример Discovery Phase для типичного проекта аутсорсинговой компании

Вот один из реальных планов, который позволил менее чем за месяц получить заказ от реального клиента на $300k.

1. Выявление нужд бизнеса и определение критериев успеха. Получение запроса “хочу закрыть вот эту проблему”, констатирование результата “закрытие проблемы означает, что было так, а станет вот так”.
2. Анализ состояния As-is (как есть) и конфигурационного потока. Определение базы, с чем работать, а также понимание, какие инструменты не работают.
3. Анализ конфигурации разных доменов. Тут понятно, что это касается специфики отдельного проекта.
4. Создание состояния To-be (как должно быть) для доступа к данным. Создание черновика технической документации и записывание всех “хотелок” клиента.
5. Совещание насчет валидации. Построение матрицы коммуникаций и утверждения результатов работ по окончанию каждого спринта.
6. Анализ GAP. Конспектирование всего, что касается существующего состояния бизнеса и шагов по достижению желанного результата.
7. Определение объема для внедрения ядра Universal DA. Опять-таки, в рамках специфики конкретного проекта.
8. Определение дополнительного объема LVN. Также в рамках технических тонкостей отдельного проекта.
9. Определение приоритетов MVP.
10. Подготовка бэклога продукта. Создание списка рабочих задач в Scrum-модели.
11. Обзор архитектуры. Экспертная оценка реальности реализации проекта на существующей технической базе.
12. Высокоуровневая оценка. Построение бизнес-документации.
13. Создание дорожной карты продукта. Какой член команды что будет выполнять в какой промежуток времени: с обязанностями, правами и итоговыми результатами по каждому шагу.

Но этот план сработал для конкретного заказчика и конкретной IT компании.

Варьирование вправо-влево требует пересмотра любого шаблона.

Материал подготовлен при участии журналиста Kraftblick.Media Юлии Шрамковой.

Узнавайте о новых статьях на Kraftblick.Media!