Про концепцию и видение
Первое что рождается в рамках проекта — это его концепция, которая обязательно должна в неизменном виде доноситься до команды-исполнителя. К сожалению, этого порой не происходит, так как участники процесса могут пренебрегать этапом создания скетча будущей системы, надеясь на более формальный документ. Сегодня мы поговорим о важности концепции, ее фиксации и распространении.
Что такое концепция?
Документ, часто одностраничный набросок, описывающий ожидания от проекта и критерии его успешности с точки зрения заказчика. Фактически это некий упрощенный бизнес-план или его краткая суть, где критической частью является финальные метрики оценки результата. Если их нет, то проект никогда не сможет удовлетворить потребности клиента и находится в зоне риска. Концепция позволяет выяснить кто в команде заказчика получит прямую пользу от внедрения, кто является главным драйвером проекта еще на начальном этапе работы. Важно включить этих людей в стейкхолдеров и добавить в проектный устав, к чему мы вернемся позже.
Откуда она берется?
Концепция возникает в голове заказчика на стадии принятия решения о запуске проекта или пресейла. Ее актуальность не должна меняться по мере прохождения этапов развития решения: основные цели формируются один раз и не меняются до тех пор, пока проект не будет сдан в опытную эксплуатацию.
Так как нам, как разработчикам, этот документ важен как описывающий требования, то он может быть сформирован в ходе активного обсуждения KPI и условий контракта. В своей работе мы не допускаем чтобы концепция содержала абстрактные цели и черты, конкретизируем требования еще с берега!
В случае если проект содержит в себе консультационную часть, т.е. клиент заранее не знает что ему нужно, то ее нужно завершить до формирования концепции, чтобы к этапу производства прийти с четким пониманием. Необходимо знать как достичь главной цели, как устроен бизнес заказчика, как его автоматизировать.
Конечно, мы говорим про идеальную ситуацию. В реальной жизни знаний о проекте может не хватать. Например, когда речь идет о стартапе, где нет никаких ответов.Так тоже можно работать, но надо понимать риски, в том числе по неправильной оценке проекта.
Что нужно знать о клиенте?
Бизнес-требования: описание организации без привязки к ИТ-системам. Это как раз уровень концепции. Как устроен бизнес и чем он живет? Без привязки к тому насколько это можно автоматизировать.
Пример: реализация оплаты товара без лишних подробностей.
Функциональные требования: описание процессов без конкретных технологий, фиксация ожидаемого качества реализации.
Пример: создание веб-страницы для оплаты товара пластиковыми картами.
Проектное решение: описание схемы и подхода к реализации.
Пример: веб-интерфейсы создаются на базе JSP и Hibernate.
Содержание концепции
Документ содержит критерии успешности с точки зрения бизнеса, описывает основные аспекты проекта и его особенности. Последние отличают его от типовых решений такого рода.
Примеры метрик качества результата:
- Х-посетителей в день
- Х-продаж в день
- Время реагирования на ту или иную ситуацию
- Уменьшение времени доставки на Х-часов
- Снижение количества аварий
Конечно разработчик — всего лишь технический специалист и не может формально нести ответственность за достигнутые бизнес-показатели. Потому что они завязаны не только на автоматизированных системах, но и на сотрудниках заказчика, их маркетинге и пропускной способности отдела продаж. Но тем не менее цели нужно держать в голове, так как довольство разработкой связано и с ними тоже.
Цель документа
Концепцию надо использовать при написании требований и для общего понимания.
Ее нужно прочесть всем членам команды чтобы сориентироваться в бизнес-смысле проекта, чувствовать ценности заказчика и не совершать ошибок неверного балансирования. Понимание концепции позволяет уделять внимание преимущественно тому, что важно с точки зрения бизнеса. Отразить баланс ценностей проекта в документах более низкого уровня и в более детальных, как правило, не получается.
Автор концепции
Аналитик или заказчик.
Источники информации
Интервью с клиентом.
