Артефакт: Концепция, Vision
Это - первый артефакт, который возникает в проекте. Иногда он возникает настолько далеко от собственно проектной команды, что до неё не доживает. А должен.
Общее описание
Одностраничный документ, описывающий слабо формализованные ощущения инициаторов проекта и критерии его успешности.
Концепция - документ выраженно бизнес-ориентированный. Приемлемая замена этому документу - бизнес-план проекта. Фактически, концепция должна быть скетчем бизнес-плана или выжимкой из него. Критически важная часть концепции - финальные метрики качества результата. Я лично, если принимаю участие в обсуждении проекта с заказчиком, всегда спрашиваю его о критериях успешности бизнеса, который мы автоматизируем. Если их нет - проект находится в зоне огромного риска.
Данный документ не содержит в явном виде, но позволяет выяснить ещё один момент: кто является интересантом проекта со стороны заказчика. Если интересанта со стороны заказчика нет, то проект гарантированно мёртв. Целеполагание, зафиксированное в концепции, позволяет выяснить, кто именно получит прямую пользу от осуществления проекта. Этого человека необходимо кооптировать в проект и уж точно включить в число стейкхолдеров - людей, которые должны принимать участие в создании и ревью требований проекта и других проектных документов. Кстати, список этих людей должен попасть в другой проектный документ - устав, но о нём позже.
В терминах фазировки проекта концепция должна появиться на фазе пресейла (если мы говорим про инхауз - то до принятия решения о запуске проекта), и должен оставаться актуальным всё время работы над проектом.
По своей сути этот документ относится к требованиям (описывает не способ реализации, а критерии качества результата), и как таковой может быть написан в режиме написания требований - черновик могут написать и клиент, и исполнитель по итогам интервью. В любом случае хотя бы первую страницу концепции нужно обезводить и привести к набору критериев успеха и неотъемлемых черт проекта.
Ещё один момент стоит оговорить здесь. Если проект имеет консалтинговую составляющую (вы как исполнитель в какой-то мере лучше клиента знаете, что ему нужно), то предполагается, что консалтинговая часть проекта в основном была отработана к данному моменту и проект перешёл в стадию производства. Мы уже знаем, как устроен бизнес, который мы автоматизируем. Мы можем знать не полностью, но неизвестными должны остаться, скорее, детали, а не суть.
Конечно, в реальной жизни степень неполноты знания о проекте бывает разная и, например, в стартапе на этой точке вопросов может быть больше, чем ответов. Это приемлемо, но надо понимать, что точность оценки проекта зависит от степени зафиксированности его бизнесовой сути.
Несколько предвосхищая следующие статьи про требования и проектные документы, выделю три класса объектов, которые надо выраженно различать при работе над проектом:
Бизнес-процессы, бизнес-требования: описание бизнеса вообще, без привязки к софтверным системам. Концепция находится на этом уровне. Здесь нам вообще неинтересно, насколько и как это всё автоматизируемо - нам важно, что бизнес устроен вот так.
Пример: Должна быть реализована оплата товара. Как, где, в онлайне, картой - не знаем. Но бизнесу нужна оплата.
Функциональные требования: описание автоматизируемого процесса, без привязки к методу и технологии автоматизации, критерии проверки качества реализации.
Пример: Должна быть реализована веб-страница для оплата товара картой Виза, Мастер-кард и Мир.
Проектное решение: описание схемы и подхода к реализации.
Пример: Все веб-интерфейсы реализуются на базе технологий JSP и Hibernate.
Я не планирую описывать артефакт "бизнес-требования", он находится категорически за пределами того процесса, о котором я хотел бы писать. Тем не менее, если его возможно получить - это однозначно полезно для проекта.
Содержание
Документ "концепция" должен содержать критерии успешности проекта с точки зрения бизнеса, описывать основные аспекты проекта, неотъемлемые сущности и взаимосвязи. Неотъемлемыми являются те сущности, которые определяют суть проекта, отличают его от типовых проектов такого рода.
Примеры метрик качества результата:
Но цели эти надо понимать и работать на их достижение в рамках вашей части мироздания.
Цель
Основа для проработки требований, ориентир для участников проекта, инструмент для понимания того, движется ли проект к заявленным бизнес-целям.
Концепцию надо использовать при написании требований, это формальная сторона дела.
Неформально концепцию должны прочесть и понимать все члены команды. Дело в том, что концепция позволяет сориентироваться в бизнес-смысле формальных сущностей проекта, чувствовать ценности заказчика и не совершать ошибок неверного балансирования проекта. Понимание концепции позволяет на уровне ощущений каждого члена команды уделять большее внимание тому, что ценно с верхней, бизнесовой точки зрения, и не уходить в "вылизывание" малоценных деталей. Отразить баланс ценностей проекта в документах более низкого уровня и в более детальных, как правило, не получается.
Автор
Аналитик. Черновик может появиться на стороне заказчика.
Источники информации
Это первый документ, опираться не на что. Только интервью.
Общее описание
Одностраничный документ, описывающий слабо формализованные ощущения инициаторов проекта и критерии его успешности.
Концепция - документ выраженно бизнес-ориентированный. Приемлемая замена этому документу - бизнес-план проекта. Фактически, концепция должна быть скетчем бизнес-плана или выжимкой из него. Критически важная часть концепции - финальные метрики качества результата. Я лично, если принимаю участие в обсуждении проекта с заказчиком, всегда спрашиваю его о критериях успешности бизнеса, который мы автоматизируем. Если их нет - проект находится в зоне огромного риска.
Данный документ не содержит в явном виде, но позволяет выяснить ещё один момент: кто является интересантом проекта со стороны заказчика. Если интересанта со стороны заказчика нет, то проект гарантированно мёртв. Целеполагание, зафиксированное в концепции, позволяет выяснить, кто именно получит прямую пользу от осуществления проекта. Этого человека необходимо кооптировать в проект и уж точно включить в число стейкхолдеров - людей, которые должны принимать участие в создании и ревью требований проекта и других проектных документов. Кстати, список этих людей должен попасть в другой проектный документ - устав, но о нём позже.
В терминах фазировки проекта концепция должна появиться на фазе пресейла (если мы говорим про инхауз - то до принятия решения о запуске проекта), и должен оставаться актуальным всё время работы над проектом.
По своей сути этот документ относится к требованиям (описывает не способ реализации, а критерии качества результата), и как таковой может быть написан в режиме написания требований - черновик могут написать и клиент, и исполнитель по итогам интервью. В любом случае хотя бы первую страницу концепции нужно обезводить и привести к набору критериев успеха и неотъемлемых черт проекта.
Ещё один момент стоит оговорить здесь. Если проект имеет консалтинговую составляющую (вы как исполнитель в какой-то мере лучше клиента знаете, что ему нужно), то предполагается, что консалтинговая часть проекта в основном была отработана к данному моменту и проект перешёл в стадию производства. Мы уже знаем, как устроен бизнес, который мы автоматизируем. Мы можем знать не полностью, но неизвестными должны остаться, скорее, детали, а не суть.
Конечно, в реальной жизни степень неполноты знания о проекте бывает разная и, например, в стартапе на этой точке вопросов может быть больше, чем ответов. Это приемлемо, но надо понимать, что точность оценки проекта зависит от степени зафиксированности его бизнесовой сути.
Несколько предвосхищая следующие статьи про требования и проектные документы, выделю три класса объектов, которые надо выраженно различать при работе над проектом:
Бизнес-процессы, бизнес-требования: описание бизнеса вообще, без привязки к софтверным системам. Концепция находится на этом уровне. Здесь нам вообще неинтересно, насколько и как это всё автоматизируемо - нам важно, что бизнес устроен вот так.
Пример: Должна быть реализована оплата товара. Как, где, в онлайне, картой - не знаем. Но бизнесу нужна оплата.
Функциональные требования: описание автоматизируемого процесса, без привязки к методу и технологии автоматизации, критерии проверки качества реализации.
Пример: Должна быть реализована веб-страница для оплата товара картой Виза, Мастер-кард и Мир.
Проектное решение: описание схемы и подхода к реализации.
Пример: Все веб-интерфейсы реализуются на базе технологий JSP и Hibernate.
Я не планирую описывать артефакт "бизнес-требования", он находится категорически за пределами того процесса, о котором я хотел бы писать. Тем не менее, если его возможно получить - это однозначно полезно для проекта.
Содержание
Документ "концепция" должен содержать критерии успешности проекта с точки зрения бизнеса, описывать основные аспекты проекта, неотъемлемые сущности и взаимосвязи. Неотъемлемыми являются те сущности, которые определяют суть проекта, отличают его от типовых проектов такого рода.
Примеры метрик качества результата:
- 1000 посетителей в день
- две продажи квартиры в неделю
- время от аварии до выезда бригады не более получаса
- 0.5 секунды от заказа до назначения исполнителя
- уменьшение времени доставки стройматериалов на объект до полудня
- снижение риска аварии запуска спутника до 0.01%
Но цели эти надо понимать и работать на их достижение в рамках вашей части мироздания.
Цель
Основа для проработки требований, ориентир для участников проекта, инструмент для понимания того, движется ли проект к заявленным бизнес-целям.
Концепцию надо использовать при написании требований, это формальная сторона дела.
Неформально концепцию должны прочесть и понимать все члены команды. Дело в том, что концепция позволяет сориентироваться в бизнес-смысле формальных сущностей проекта, чувствовать ценности заказчика и не совершать ошибок неверного балансирования проекта. Понимание концепции позволяет на уровне ощущений каждого члена команды уделять большее внимание тому, что ценно с верхней, бизнесовой точки зрения, и не уходить в "вылизывание" малоценных деталей. Отразить баланс ценностей проекта в документах более низкого уровня и в более детальных, как правило, не получается.
Автор
Аналитик. Черновик может появиться на стороне заказчика.
Источники информации
Это первый документ, опираться не на что. Только интервью.