До разработки: зачем нужна концепция IT-решения

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

Presale — процесс оценки задач нового проекта или нового продукта, исходя из вводных данных, которые предоставляет заказчик.

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

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

Виды оценок

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

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

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

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

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

Во втором случае требуется хотя бы концепция MVP (минимальная жизнеспособная версия) IT-продукта. Она помогает формализовать ожидания на этапе presale.

Актуализирующая оценка – самая точная. Используется для стартовавших/действующих проектов, по которым проведен предпроектный анализ или сформировано техническое задание. Точность оценки будет максимальной.

Что такое концепция

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

На этапе presale концепция выполняет две функции: 

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

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

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

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

В отличие от технического задания, составление которого может занять достаточно долгое время, на концепцию тратится в среднем 8 часов.

Как составляется концепция и кому она необходима

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

• Бизнес-цели: какие потребности заказчик хочет закрыть разрабатываемой системой
• Нефункциональные требования и ограничения: каким критериям должна соответствовать система без привязки к конкретным функциям (безопасность, доступность, производительность и т.д.)
• IT-архитектура: из каких основных частей будет состоять архитектура системы.
• Бизнес-процессы и алгоритмы: какие процессы подлежат автоматизации и как они будут выстроены.
• Функциональные требования: что именно система будет делать, какой набор функций в нее нужно заложить.
• Границы MVP или оцениваемого решения: уточнения по функциональным требованиям, которые показывают четкие ограничения, как именно будет реализована функциональность системы в рамках данной концепции.
• Предложения для последующих доработок и то, что можно скорректировать в рамках оценки.

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

  

Составляет концепцию аналитик. В его задачи на этом этапе входят:

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

На основании согласованного документа аналитик может представить развернутую оценку этапа аналитики. Опираясь именно на концепцию и на оценку этапа аналитики, другие члены группы оценки (frontend, backend, дизайнеры, QA) могут сформировать более точную оценку своих этапов. Более подробно об оценке этапа аналитики и ее значении для сроков реализации проекта мы рассказывали в этой статье.

Концепция на этапе presale будет полезна, когда:

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

Когда концепция не нужна

Важно понимать, что концепция на этапе presale делается не для каждого проекта. В частности, она не подходит, когда:

• Вводной информации/документации от заказчика достаточно и на основе этой информации можно сделать оценку, уточнив лишь пару вопросов

• Информации недостаточно, но при интервьюировании заказчика мы понимаем, что объем системы настолько большой, что 8 часов для создания верхнеуровневого файла с описанием будет 100% недостаточно.
  
  Здесь можно предложить заказчику пойти двумя путями в зависимости от ситуации:

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

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

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

Резюме

• Концепция — один из важных элементов, который помогает и заказчику, и команде понять, что именно необходимо сделать и максимально сопоставить понятия ожидания и реальности при формировании оценки новых проектов и продуктов. При этом важно помнить:
• Концепция создается на этапе предварительной оценки, зачастую бесплатно.
• Концепция создается только для новых продуктов и проектов, по которым нужна детализированная оценка.
• Формирование концепции — один из самых оптимальных способов фиксации договоренностей с клиентом, на основе которых делается оценка.
• Концепция имеет структуру схожую с техническим заданием, но описание в ней менее детализированное.
• Содействие и открытость заказчика при сборе информации поможет команде зафиксировать все пожелания и выбрать оптимальное решение.
• При создании концепции аналитик играет роль агрегатора и ответственного за полноту документа. 
• Документ дает заказчику полную картину реализуемой системы.
• Концепция подходит не для всех проектов.