«Дискавери-фаза», или что делать, когда аналитика — это долго, дорого и неэффективно

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

Расскажу, что такое Discovery phase, которую для простоты буду называть «дискавери». Заодно приложу ссылки на нашу документацию.

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

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

Это означает, что сначала заказчика просят заплатить за стадию аналитики. Потом, скорее всего, доплатить ещё — работать в минус мало кто любит, а умеющих определять стоимость сразу и ещё меньше.

Затем, после этапа аналитики, ему сообщают стоимость разработки всего проекта. А дальше по известному сценарию: отрицание → гнев → торг → депрессия → принятие. Кто-то принимает ситуацию и ищет бюджет, а кто-то решал, что лучше вложиться в шиномонтажку.

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

Руководитель проекта, аналитик, дизайнер, технический специалист и, конечно же, заказчик.

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

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

На дизайнере — UX и UI.

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

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

Дискавери — поэтапная работа. Идём от глобальных бизнес-целей и задач до конкретных пользовательских действий в системе. После каждого этапа предоставляем отдельный артефакт с зафиксированными требованиями.

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

Первый артефакт — Mind Map, описывающий общий скоуп выявленных бизнес-целей и задач. Завершающий — оценка на разработку с детальной разбивкой на функции, учитывающая утвержденные нефункциональные требования, и почасовая оценка необходимых трудозатрат.

Подробнее об артефактах.

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

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

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

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

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

К примеру: Как <роль/персона>, я <могу сделать>, <с такой-то целью>.

Пример.

BPMN-диаграмма — это ещё один уровень детализации требований. Формализация требований в таком виде помогает чётко понять взаимодействие пользователей друг с другом и увидеть возможные «белые пятна», которые в другом артефакте мы могли попросту не заметить.

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

Wireframe даёт предварительное понимание будущей UI, UX инфраструктуры. И так как он, как правило, отображает ключевой бизнес-кейс, даёт понять, какие экраны необходимо включить в интерактивный прототип.

Нефункциональные требования — требования, описывающие работу системы, но не являющиеся в явном виде функциональными. Могут сильно повлиять на стоимость разработки, а если их не проработать, то и убить проект.

Например, если клиент говорит, что хочет запускаться в Китае и США, а фиксируется только то, что потребуется локализация на двух языках, то это фиаско, братан.

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

Пример.

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

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

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

Пример.

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

Любая бизнес-цель без изначально ясного решения или однозначного видения технической реализации — «узкое место». Инвестигирование — поиск узких мест и возможных решений.

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

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

Пример.

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

Не путать с Wireframe. Invision-прототип может не выглядеть в точности как конечный продукт, но определённо не наброски в 50 оттенках серого. Взаимодействия аккуратно смоделированы и максимально похожи на то, что будет в конечном продукте.

В зависимости от степени готовности аналитики и дизайна всех экранов приложения, план предоставляется:

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

Пример.

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

Если смотреть на дискавери глазами заказчика, то дискавери помогает:

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

Наши показатели тоже изменились.

Положительные

«Не положительные»

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