Проекты при заказной разработке. Часть 2. Инициация проекта (Discovery/Planning)
Продолжаю цикл статей о процессе разработки проекта в компании аутсорсере для какого-нибудь иностранного заказчика. Вторая часть будет про начало проекта, который в методологиях принято называть Planning/Elaboration и иногда его можно назвать Discovery фазой, если нам повезло и мы продали её клиенту отдельно до подписания основного контракта.
Первая часть — Продажа (presale, RFX)
Если сильно упростить, то это этап подготовки к, собственно, выполнению проекта. Ошибки, допущенные на этом этапе, будут стоить дороже, чем в последующих.
Discovery
Для начала остановлюсь отдельно на случае, когда этот этап у нас называется Discovery.
Это значит что вместо того чтобы брать все затраты на выяснение деталей проекта на себя, мы смогли продать эту работу клиенту, чтобы вместе с ним выяснить все детали планируемого проекта. Часто продать такую фазу удается если проект достаточно крупный и/или клиент слабо представляет что же за функционал он хочет в итоге получить, а имеет только бизнес потребность.
В этом случае мы проводим анализ текущего состояния бизнес домена клиента, бизнес целей, ради которых мы хотим запустить этот проект, его ограничения (что не входит в проект, дедлайны, требования сертификаций и т.д). Если проект не стартует с нуля, а является продолжением или переделкой существующего процесса, то мы обязательно выясняем и описываем как это работает сейчас. Как известно, любое изменение системы начинается с анализа текущего состояния системы, только тогда мы сможем построить план перевода системы в другое состояние. В случае когда мы создаем что-то с нуля, то возможно стоит задуматься о том, как сейчас решается эта проблема в бизнесе клиента.
Исследуем альтернативы и решения конкурентов, составляем список рисков, которые могут помешать нам выполнить проект.
Все это отображаем в документе, который называется Project Vision and Scope.
Собираем сценарии использования (use case) и на их основе собираем прототипы будущего интерфейса (UI), итеративно увеличивая их детальность (от набросков на бумаге, до черно белых, а потом и цветных динамичных электронных прототипов).
Составляем максимально подробное описание функционала будущего проекта в документе SRS (software requirements specification), по которому будут работать разработчики в последующих фазах, и обязательно утверждаем его с клиентом.
Планируем высокоуровневую архитектуру проекта: модули, хранение данных, интеграции, взаимосвязи и так далее, в специальном документе SAD (software architecture document)
Составляем ИСР (иерархическую структуру работ) и календарный план проекта, чтобы определить планируемую дату окончания проекта, исходя из доступных ресурсов и ограничений (дедлайнов) клиента.
Все вышеописанные документы являются выходами Discovery фазы.
Планирование проекта
В случае когда отдельной фазы Discovery нет, то все или, чаще, часть документов выше были созданы на предыдущем этапе продажи (pre-sale/RFX) в общем виде и на этом этапе дорабатываются и уточняются деталями.
Стоит оговориться, что SRS спецификация не всегда создается и, в принципе, не всегда нужна. В основном она необходима на крупных проектах с контрактом по фиксированной цене (FP — fixed price) для того, чтобы избежать споров о работах, входящих в объем работ проекта, в ходе выполнения проекта.
На проектах с более гибким контрактом время и материалы (TM — time and material), функционал проекта описывается в общем виде (on a high level) и после начала работ над проектом детализируется по так называемому методу «набегающей волны».
На этом же этапе выделяется команда, которая будет выполнять проект, в идеале она останется постоянной до конца проекта, если не случится непредвиденных серьезных изменений в его содержании
Я бы включил в этот этап 2 важные встречи.
Первая встреча — внутренний старт проекта (internal kick-off meeting). На этой встрече собирается команда проекта и обсуждает важные детали предстоящего проекта с точки зрения внутренних процессов его исполнения. На этой встрече, при условии что все члены команды ознакомились со всей доступной информацией по проекту заранее, могут быть идентифицированы дополнительные риски, потенциальные проблемы, не обнаруженые ранее. Происходит распределение ролей внутри команды и обсуждения процессов разработки: время и частота встреч команды, процесс взаимодействия разных частей проекта (фронт и бекенд, например), и ещё десятки важных вещей (тестирование, релизы, необходимая инфраструктура, gitflow и так далее)
По итогам этой встречи вся команда должна понимать что, зачем и когда в проекте, для чего сам проект, планы и роли. У каждого члена команды не должно остаться вопросов по внутренней организации выполнения проекта.
Вторая встреча — официальный старт проекта с заказчиком.
На этой встрече обсуждается взаимодействие команды проекта с представителем или командой заказчика (если такая есть). Коммуникации, процесс, контрольные точки, поставки, релизы, отчеты. Подробнее можно посмотреть в моем посте про это — правильный старт проекта
Итог
В конце фазы у команды есть всё необходимое для того, чтобы приступить непосредственно к написанию кода. Каждый член команды знает свою роль на проекте, понимает задачи проекта, его содержание и дедлайны.