Discovery Phase в IT-проектах: что это и зачем нужно?

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

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

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

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

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

Этап Discovery Phase индивидуален для каждого проекта, но есть некоторые общие факторы, определяющие его особенности:

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

• Предоставляемые IT-услуги. Важность Discovery Phase зависит от типа услуг. На этой стадии определяются важнейшие для проекта факторы. Например, разработчики узнают, может ли какое-то изменение или дополнение повлиять на разработку программного и аппаратного обеспечения, алгоритмов на базе машинного обучения, разработку IoT-решений или прошивки. У каждой из этих IT-услуг свои особенности и уровень гибкости. Разработка аппаратного обеспечения, IoT-систем, встроенного программного обеспечения и прошивки отличается меньшей гибкостью, чем разработка прикладного ПО или решений на базе машинного обучения. Это означает, что реализация любых изменений может оказаться слишком сложной и дорогостоящей.

• Бюджет. Это одна из самых больших проблем исследовательского этапа. Discovery Phase – это отдельная стадия разработки продукта, требующая дополнительных затрат. Однако предварительное исследование помогает сэкономить в масштабах всего проекта.

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

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

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

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

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

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

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

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

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

Игнорирование фазы исследования может привести к непредвиденным проблемам на пути создания вашего решения:

• непрекращающееся масштабирование разработки;
  
  
• увеличение затрат;
  
  
• размытые сроки и отсрочивание релиза;
  
  
• неудачи в достижении результатов.
  

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

Давайте разберем, какие преимущества дает проведение исследования:

• Правильно организованный и прозрачный процесс разработки продукта;
  
  
• Команда разработчиков знает обо всех проблемах, с которыми ей предстоит столкнуться, и знает, как их решить;
  
  
• Бюджет на разработку продукта не потребует серьезных изменений, т.к. минимизация рисков помогает избежать дополнительных расходов и сократить время между разработкой продукта и его релизом;
  
  
• Определяются альтернативные способы разработки продукта;
  
  
• Макет или прототип, позволяющие визуализировать будущее изделие. Это поможет определить возможные изменения и понять, соответствует ли идея продукта интересам и ожиданиям целевой аудитории.
  

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

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

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

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

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

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

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

По завершении фазы исследования команда должна получить следующее:

• Макет наиболее подходящего UX-дизайна для программного решения;
  
  
• Макет всего программного решения или той его части, которая исследуется;
  
  
• Подготовленное техническое задание;
  
  
• Варианты использования продукта и пользовательские истории.
  

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

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

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

После исследования команда КЕДР Solutions пришла к выводу, что для реализации этого функционала лучше всего подходит веб-приложение.

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

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

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

Так, мы собираем требования заказчика к UI/UX-дизайну, возможностям и функционалу будущего ПО. Следующий наш шаг – описать алгоритм использования ключевых функций пользователями или любыми другими ролями. Например, мы провели Discovery Phase для программной части проекта по разработке контроллера с поддержкой Wi-Fi для гидромассажных ванн.

На этапе исследования мы разработали UI/UX-дизайн для мобильного приложения под iOS и Android, которое позволяет удаленно управлять датчиками и насосами гидромассажных ванн.

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

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

На исследовательском этапе проекта с машинным обучением важно выяснить следующее:

• Основная цель Discovery Phase;
  
  
• Целевые характеристики: точность алгоритма и скорость его работы, его интеграция и взаимодействие с другим программным обеспечением;
  
  
• Вводные данные и их доступность;
  
  
• Доступность набора данных;
  
  
• Проблема, которую может решить будущий продукт;
  
  
• Возможное улучшение продукта.
  
  

Эти пункты сформулированы специально для проектов машинного обучения. Однако сюда также следует добавить вопросы из Discovery Phase для проектов по разработке ПО. Команда КЕДР Solutions имела подобный опыт при разработке системы камер для пожилых людей на основе алгоритмов компьютерного зрения, способной распознавать падение человека. Это комплексное решение, и мы предложили клиенту начать с исследовательского этапа, т.к. для начала необходимо было оценить реализуемость проекта.

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

Одним из основных результатов Discovery Phase стала возможность разработки системы связи для данного решения. Мы выяснили, что можем создать вычислительный блок для сбора данных со всех камер и/или отправки сигнала в случае фиксации падения лицам, осуществляющим уход. Таким образом, после завершения изысканий мы создали прототип комплексного решения для ухода за пожилыми людьми.

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

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

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

• Какие конструктивные ограничения есть у вашего решения?
  
  
• Какие проблемы решают устройство или прошивка?
  
  
• На какой рынок вы собираетесь ориентироваться?
  
  
• Можно ли создать устройство или прошивку с использованием существующих технологий?
  
  
• Какие технологии и концепции наиболее подходят для разработки продукта?
  
  
• Какие изменения могут повлиять на дальнейшее развитие продукта?
  
  
• Что может повысить производительность вашего решения?
  
  
• Какая часть решения может оказаться самой сложной?
  
  
• С каким программным обеспечением должно взаимодействовать устройство или система?
  
  

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

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

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

Команда КЕДР Solutions изучила различные возможные подходы к измерению емкости и определила, что для данного решения требуется применение высокочастотного сигнала к столбцам один за другим, усиление сигнала каждой строки, а также амплитудная демодуляция и обнаружение пиков.

Мы выяснили, что это можно сделать двумя способами: 1) использовать дискретные компоненты или 2) использовать ИС емкостного датчика.

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

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

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

Как правило, проектирование решений в области Интернета вещей включает в себя разработку прикладного ПО, прошивки и аппаратного обеспечения, т.е. 3 в 1. Это означает, что все части взаимосвязаны друг с другом, и внесение изменений в одну из них повлияет на остальные.

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

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

По завершении Discovery Phase вы получите отчет со следующими результатами:

• Подробное описание назначения, поведения и требований к системе.
  
  
• Список физических и виртуальных единиц, устройств, датчиков и сервисов, необходимых для разработки IoT-решения.
  
  
• Спецификация информации в системе.
  
  
• Список с описанием подходящих вариантов связи и хранения данных.
  
  
• Макет или прототип всего решения или той его части, которая изучается на исследовательском этапе.
  
  
• Возможные решения и подходы к разработке системы.
  

Например, наша команда провела Discovery Phase, работая над проектом IoT-системы для удаленного мониторинга и управления оборудованием.

Заказчик попросил нас подобрать компоненты (микроконтроллер и датчики) для BLE-шлюза, определить совместимые удаленные сервисы для хранения и обработки данных, а также подобрать подходящие варианты электропитания.

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

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

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

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

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

В зависимости от сложности проекта Discovery Phase может потребовать от 40 до 200 человеко-часов. Наша исследовательская команда обычно состоит из менеджера проекта, нескольких разработчиков, технического руководителя и команды заказчика. Однако, если нам нужно изучить сложное решение или инновационный продукт, мы привлекаем больше специалистов.

Наша команда имеет большой опыт в исследовании и разработке программного обеспечения, решений на базе машинного обучения, встроенного программного обеспечения, электроники и IoT-проектов. Мы тщательно изучаем вопрос в самом начале работы, чтобы создать полностью функциональное решение. Если вы хотите проверить свою идею на реализуемость, не стесняйтесь обращаться к КЕДР Solutions.