Проекты при заказной разработке. Часть 1. Продажа (presale, RFX)

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

Продажа и заключение контракта (RFX)

На этом этапе, который часто называют RFX (объединяет аббревиатуры RFI, RFQ, RFP), он сейлов или аккаунта приходит бриф на новый проект, который необходимо проанализировать и выдать заказчику предложение, на основе которого он заключит с нами контракт.

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

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

  1. Contact
  2. Lead / Suspect
  3. Prospect / Opportunity.

На этапах 1-2 работает в основном только сейл и кто-то из топ менеджеров, который принимает решение о том, подходит ли этот потенциальный проект стратегии компании, ее возможностям и стоит ли инвестировать дальше в проработку этой возможности. Он классфицирует проект согласно его размеру используя очень примерную оценку, что называется «на глазок» (ballpark estimate), исходя из своего опыта. Это позволяет отнести проект в одну из классификаций по размеру (маленький, средний, большой), а также иметь грубую оценку для ориентирования клиента, сколько это может стоить. Грубая оценка дается разбросом, например 6-10к часов.

Надо понимать, что почти всегда активности на этом этапе до заключения, собстенно, конракта на разработку, ложатся на затраты компании и не оплачиваются клиентом. В случае, когда клиенту удается продать фазу бизнес-анализа (discovery phase) или тех исследования (proof of concept), только тогда клиент что-то платит на этом этапе.
Воронка может быть как длинее, так и короче, но суть остается примерно одинаковой.
После успешного прохождения 1-2 этапов, переходим к 3му.

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

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

  • Координатор (rfx manager), он может выполнять роль Аналитика или, если проект крупный, дополнительно подключается выделенный бизнес-аналитик.
  • Разработчик с опытом оценки проектов, чаще всего каждую из частей системы свой разработчик, то есть, например, фронтенд оценивает фронт, бекенд — отдельный человек, если планируются мобильные приложения, то их оценивает разработчик мобильных приложений.
  • Тестировщик для прояснения плана тестирования, типов необходимого тестирования, необходимость автоматизации и так далее. От этого будет сильно зависеть время на тестирование, которое надо будет заложить в оценку проекта.
  • Архитектор (Solution Architect) подключается на потенциально крупных, технически сложных (сложная логика данных, высоконагруженные и так далее) и стратегически важных проектах. Специалист дорогой, потому его использование в бесплатных продажных активностях часто ограничено.

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

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

Следующим этапом после утверждения списка высокоуровневого функционала является его декомпозиция тех специалистами и проставление оценок в часах к каждой задачи. Чаще всего для этого используется специальный шаблон, он может различаться визуально от компании к компании, но суть всегда очень близка. Большинство старается использовать формулу PERT, проставляя для каждой задачи как минимум 2 оценки — оптимистичную и пессимистичную.
Также тех специалисты прописывают список допущений проекта (assumptions).

скриншот части документа с оценками из реального проекта

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

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

При анализе полученного документа с оценками, стоить проверить основные потенциально проблемные пункты, такие как:

  • В списке задач обязательно указаны задачи на развертывание и настройку всех необходимых окружений (dev, staging, production)
  • Учтено время команды на коммуникацию. Это как митинги скрама: демо, ретро, планирование, так и время на выкатку/деплой/развертывание кода при релизе, написание инструкций и описаний процесса настройки окружения и релиза
  • Обсуждены с командой и проанализированы все изначальные допущения (assumptions). Все технологические риски должны быть покрыты допущениями, например: «стороннее апи работает согласно документации, доступ предоставлен клиентом до начала работ», «сторонний сервис полностью готов к интеграции с ним в течении 2х месяцев с начала работ над проектом» и так далее
  • указан список поддерживаемых платформ, операционных систем, браузеров (и их версий). В случае веб сервисов — минимальное разрешение, адаптивная или гибкая верстка и т.д
  • указана наличие поддержки языков, кроме основного (английского обычно)
  • в списке нет задач длительностью более 40 часов
  • учтены риски при наличии интеграций со сторонними системами (добавлен буфер или создано соответствующее допущение).
  • Список допущений обоснован и не избыточен. Чрезмерное увлечение допущениями грозит в последствии проблемами с клиентом, поскольку используя их мы, по сути, перекладываем риски на него.
  • В календарном плане проекта заложен адекватный временной буфер

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

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

  • Project Vision/Solution Vision документ — хорошее определение можно почитать тут. Если вкратце, то в документе описываются цели проекта, бизнес потребность, стейкхолдеры и клиенты, предлагаемое нами решение (архитектура, технологии, команда) и потенциальные выгода от реализации нашего решения, объем работ проекта, описанный на высоком уровне (функциональные требования, нефункциональные, допущения, что не входит в объем работ).
    В случае, когда клиенту продается отдельно фаза бизнес-анализа (Discovery phase), то по её итогам создается несколько документов, которые детализируют основные части документа выше: устав проекта (Project Charter), спецификация требований (FRS/SRS, App flow), прототип, SAD (software architecture documents), ИСР (WBS) с подробными оценками и так далее
  • Коммерческое предложение (vendor’s commercial proposal).
    Более краткий документ, чем предыдущий. Содержит краткое описание содержания проекта. Основной частью документа является описание нашего подхода к реализации проекта: методология, команда, технологии, приблизительная стоимость, приблизительные сроки, этапы и контрольные точки.

Финалом стадии RFX является подписание контракта с заказчиком и запрос ресурсов для начала работы над проектом.

В следующей части я опишу начало проекта. В разных компаниях этот этап может называться Discovery, Planning, Elaboration или просто Нулевой спринт (Sprint 0).