Vision scope что это
Оформление документации по проекту
Вопросы семинара 4 «Оформление документации по проекту»:
Документация фазы Envision
К документам фазы выработки концепции относятся:
Разумеется, никто не ограничивает документацию по проекту только предложенными MSF типами документов, это лишь рекомендации, следование которым, должно, по мнению Microsoft, упростить и облегчить процесс создания IT решения.
Рассмотрим типы основных документов фазы выработки концепции.
Документ описания структуры проекта
В данный документ входят: информация об организации проектной группы, участники группы и их роли, персонификация областей ответственности каждого из членов проектной группы.
Также в данном документе должна быть представлена схемы взаимодействия группы разработчиков с заказчиками и заказчиков – с группой разработчиков.
Документ оценки рисков
Следует лишь отметить, что главная таблица рисков (см «Организация работы в команде» ) является частью документа Vision \Scope.
Vision\Scope документ
Формирование видения проекта и специфицирование его рамок – не одно и тоже, хотя для успеха проекта необходимо и то, и другое. Видение ( vision ) – это ничем не ограничиваемое представление о том, каким должно быть решение. Рамки (scope) же дают четкие границы того, что из предложенного этим видением будет реализовано в условиях существующих проектных ограничений.
Шаблон Vision \Scope см в Приложении А.
Документация фазы Planning
Документы фазы планирования:
Утвержденные спецификации, планы и календарные графики образуют базовую версию проекта ( project baseline ). Она включает все соглашения, принятые на основе консенсуса с учетом трех плановых параметров проекта: ресурсов, времени и функциональности решения. После того, как базовая версия проекта создана и утверждена, проектная группа приступает к фазе разработки.
Функциональная спецификация
Функциональные спецификации детально описывают вид и поведение каждой составляющей решения. Также для всех составляющих описывается их архитектура и дизайн.
Цели функциональной спецификации:
План управления рисками
План управления рисками включает в себя описание мероприятий по
Данные мероприятия составляются для каждого из рисков (подробнее см «Организация работы в команде» )
Сводный план и календарный план проекта
Сводный план проекта представляет собой совокупность планов работы каждого из ролевых кластеров, см. рис. 22.1
Каждый из планов детализируется, также составляется календарный график для каждого из планов.
Документация фазы Developing
Документы фазы «Разработка»:
Документация фазы Stabilizing
Документы фазы «Стабилизация»:
Документация фазы Deploying
Документация фазы «Внедрение»:
Заполнение Vision\Scope документа
Шаблон документа Vision \ Scope см в Приложении А
Составление плана – графика проекта
Оформление документации по проекту
Вопросы семинара 4 «Оформление документации по проекту»:
Документация фазы Envision
К документам фазы выработки концепции относятся:
Разумеется, никто не ограничивает документацию по проекту только предложенными MSF типами документов, это лишь рекомендации, следование которым, должно, по мнению Microsoft, упростить и облегчить процесс создания IT решения.
Рассмотрим типы основных документов фазы выработки концепции.
Документ описания структуры проекта
В данный документ входят: информация об организации проектной группы, участники группы и их роли, персонификация областей ответственности каждого из членов проектной группы.
Также в данном документе должна быть представлена схемы взаимодействия группы разработчиков с заказчиками и заказчиков – с группой разработчиков.
Документ оценки рисков
Следует лишь отметить, что главная таблица рисков (см «Организация работы в команде» ) является частью документа Vision \Scope.
Vision\Scope документ
Формирование видения проекта и специфицирование его рамок – не одно и тоже, хотя для успеха проекта необходимо и то, и другое. Видение ( vision ) – это ничем не ограничиваемое представление о том, каким должно быть решение. Рамки (scope) же дают четкие границы того, что из предложенного этим видением будет реализовано в условиях существующих проектных ограничений.
Шаблон Vision \Scope см в Приложении А.
Документация фазы Planning
Документы фазы планирования:
Утвержденные спецификации, планы и календарные графики образуют базовую версию проекта ( project baseline ). Она включает все соглашения, принятые на основе консенсуса с учетом трех плановых параметров проекта: ресурсов, времени и функциональности решения. После того, как базовая версия проекта создана и утверждена, проектная группа приступает к фазе разработки.
Функциональная спецификация
Функциональные спецификации детально описывают вид и поведение каждой составляющей решения. Также для всех составляющих описывается их архитектура и дизайн.
Цели функциональной спецификации:
План управления рисками
План управления рисками включает в себя описание мероприятий по
Данные мероприятия составляются для каждого из рисков (подробнее см «Организация работы в команде» )
Сводный план и календарный план проекта
Сводный план проекта представляет собой совокупность планов работы каждого из ролевых кластеров, см. рис. 22.1
Каждый из планов детализируется, также составляется календарный график для каждого из планов.
Документация фазы Developing
Документы фазы «Разработка»:
Документация фазы Stabilizing
Документы фазы «Стабилизация»:
Документация фазы Deploying
Документация фазы «Внедрение»:
Заполнение Vision\Scope документа
Шаблон документа Vision \ Scope см в Приложении А
Составление плана – графика проекта
ГАЙД ПО СОСТАВЛЕНИЮ VISION & SCOPE
Что такое «концепция и границы» для программного продукта? Как создать документ, который поможет упорядочить бизнес требования, определить цели, риски, ожидания и ограничения к проекту? Сегодня мы опишем, как это правильно делать.
Vision & Scope – это один из важнейших документов при разработке проектов, с которым вам, скорее всего, не раз придётся столкнуться. В нём описаны требования к проекту, видение решения и различные ограничения
Документ о концепции и границах (Vision&Scope, далее – V&S) имеет 4 основных раздела, которые могут немного изменяться в рамках проекта или компании. Единого шаблона для него не существует, но есть базовые элементы, о которых мы и поговорим далее.
ПЕРВЫЙ РАЗДЕЛ: БИЗНЕС-ТРЕБОВАНИЯ (BUSINESS QUIREMENTS)
Раздел Business quirements обычно состоит из 5 пунктов:
— Background. Тут описывается основная идея и цель разработки продукта – зачем вообще он нужен и что он даст потребителю.
— Business Opportunities. Второй пункт описывает, как проект может приносить прибыль. В нём можно описать будущую модель монетизации, на какой рынок ориентируется продукт и является ли он перспективным.
— Business Objectives and Success Criteria. Этот пункт обычно делится на подпункты, где каждый описывает что-то конкретное. Обозначаются они в виде BO-1, BO-2, SC-1 и т.д. Тут стоит описать, каких целей вы собираетесь достичь (Пример: снижение затрат на обслуживание на 30% за год) и что является критерием успеха (Пример: регистрация 100 000 пользователей за год).
— Customerand Market Needs описывает, какая потребность есть у потребителя, что вы разрабатываете этот продукт. Тут можно проанализировать аналоги, описав также своё преимущество над ними. Если нет потребности – нет смысла в продукте.
—Business Risks. Последний пункт так же как и третий делится на подпункты, обозначаясь как BR-1, BR-2 и т.д. В нём стоит описать риски, которые могут помешать развитию проекта (Пример: большая конкуренция на рынке). Помимо этого, стоит описать, что нужно предпринять, чтобы этих рисков избежать.
ВТОРОЙ РАЗДЕЛ: ВИДЕНИЕ РЕШЕНИЯ (VISION OF THE SOLUTION)
Во второй раздел включается три пункта:
— Vision Statment. Этот пункт в целом описывает, каким образом вы собираетесь реализовать проект, и как он будет работать. Будет ли это веб-приложение или мобильное, как пользователи смогут его использовать – всё сюда.
—MajorFeatures. Сюда вы должны по пунктам (списком MF-1, MF-2…) вписать все функции (особенности) вашего проекта, которыми сможет воспользоваться потребитель. Например: контроль активности пользователя.
— Assumptionsand Dependencies. Допущения и зависимости также описываются списком. Они могут касаться пользователей (Пример: пользователь может иметь необновлённую версию системы) или вашей системы (Пример: Выход оборудования из строя может привести к потере важных данных).
ТРЕТИЙ РАЗДЕЛ: ОБЪЕМ И ОГРАНИЧЕНИЯ (SCOPE AND LIMITATIONS)
В этот раздел обычно включают:
— Scopeo Finitial Release включает в себя функционал, который планируется реализовать к первому выпуску продукта. Сюда нужно вписать необходимый минимум, который требуется для успешного запуска проекта. Тут могут описываться такие пункты, как редактирование профиля пользователя, администрирование, возможность смены языка и т.п. Если система будет реализована для разных типов устройств (смартфон и ПК), то это следует описать отдельно.
— Scopeof Subsequen tReleases включает в себя всё, что планируется реализовать в будущем. Этот пункт может быть более абстрактным, но реально выполнимым.
— Limitationsand Exclusions в виде списка описывают необходимые для корректной работы ограничения. Например: доступ к данным имеет только авторизированный пользователь, удалять другие профили имеет право только администратор и т.д..
ЧЕТВЕРТЫЙ РАЗДЕЛ: БИЗНЕС КОНТЕКСТ (BUSINESS CONTEXT)
— Stakeholder Profiles обычно оформляется в виде таблицы с такими полями:
— Project priorities описывает приоритеты среди требований, графика (времени) и бюджета. Пункт может включать в себя ограничения на размер команды, на сколько допустимо превышение бюджета, допустимый процент незавершенности проекта (по количеству MajorFeatures) к времени релиза и т.п.
— Operating Enviroment описывает средства разработки, которые будут использованы. Сюда можно включить СУБД, фреймворки, различные ЯП и т.д.
Часто, допускаются больше не технические ошибки, а именно те, что касаются содержания и наполнения. К таким можно отнести недостаточною обоснованность в необходимости продукта или отсутствие таких элементов как: анализ аналогов; описание того, как продукт будет приносить прибыль; описание особенности и отличия продукта от массы других.
Надеемся, что этот гайд поможет вам составить V&S документ и вы избежите путаницы и неточностей в каждом из пунктов.
Желаем вам продуктивности!
Марк Харланов
Шаблоны и примеры Vision and Scope
В теме 17 ответов, и 7 участников, последнее обновление сделано пользователем 
Snowball 11 г назад.
В этой ветке предлагаю делиться шаблонами и примерами такого важного для каждого аналитика документа, как Vision and Scope. Можно на английском или русском.
Добрый вечер.
Вот еще вопрос… Как я поняла, для документа Vision & Scope нет шаблона, установленного стандартом IEEE? То есть в основном народ пользуется шаблоном Вигерса, ссылка на который, кстати, была опубликована выше одним из участников. Для некоторых наших маленьких проектов этот шаблон слишком амбициозен. Все ли строго следуют ему или все-таки в ваших компаниях позволяется писать данный документ в свободной форме?
Отвечу за себя.
В моей практике мы лишь несколько раз строго следовали этому шаблону. Во всех остальных случаях документ строился индивидуально под каждый конкретный проект. Мы исходили от нужд заказчика и проекта. Из-за этого иногда что-то выбрасывалось, а что-то добавлялось.
шаблон, да— хорош (жаль не видел его раньше). но всё равно было бы интересно, есть ли к примеру отличия между «эталонными» документами, тем что предлагают в качестве примера различные зарубежные ресурсы, и тем что делается сдесь и сейчас, «местными» аналитиками. да и со своими опусами сравнить)
ладно, пардон за любопыство…
Доброго всем дня и трудовых успехов!
У меня тоже острейший интерес к тому, что сделано именно «местными» аналитиками. И слово ОПУС как нельзя более уместно по отношению к плодам моего творчества. К сожалению, работ по коммерческим проектам не могу показать, из соображений конфиденциальности.. Как сказал, ГИП: это все не секретно, конечно, но конфиденциально…
Но сейчас есть у меня помимо основного проекта одна маленькая некоммерческая задачка — вот ее я все равно оформляю совсем как «у больших» 
, благо время терпит… Получается этакий учебно-практический опус. С удовольствием его выложу, если кто-то захочет обсудить и покритиковать его. Это был бы колоссальный и бесценный опыт… Но с другой стороны, понимаю, что вряд ли кому-то это нужно. Особенно в свете последних обсуждений личной эффективности и грамотного тайм-менеджмента. Что же это реально так… Время бесценно.
Как посмотреть на свой продукт со всех сторон и донести идею до команды с помощью Product Vision?
Иногда продакт-менеджеру не удается донести до команды представление о продукте: для кого он создается, какие проблемы решает, каким функционалом обладает, чем отличается от конкурентов и т.п.
Достигнуть поставленные цели без общего понимания невозможно. Поэтому продакты используют Product Vision — понятное представление продукта для всей команды. Из этой статьи вы узнаете, что такое видение продукта, как его можно сделать и внедрить в рабочий процесс.
Что такое Product Vision
До сих пор никто не дал четкого определения для Product Vision. Даже на западных форумах продолжаются споры между предприниматели и продактами. Некоторые вообще путают это понятие с Product Mission. Давайте рассмотрим несколько основных определений, которые чаще всего встречаются в рунете:
Видение продукта — цель и причина создания. Какие боли и проблемы потенциальной аудитории решает продукт. Определение коррелирует с миссией компании.
Видение продукта — краткая концепция. Ее используют в качестве ориентирования и мотивации во время работы. Команда и стейкхолдеры используют Product Vision, чтобы принимать верные решения.
Видение продукта — описание конкретной точки, в которой продукт должен оказаться спустя какое-то время.
Видение продукта — краткое описание текущего положения продукта среди конкурентов, ценностного предложения, рынка, потребителей, конкурентов и т.п.
Это лишь некоторые варианты, самые распространенные. Если посетить популярные форумы продактов, можно еще 5-7 штук найти. И все-таки Product Vision не должен коррелировать с миссией, о которой компании рассказывают везде.
Видение — внутреннее понимание целевого состояния продукта, используемое командой и стейкхолдерами для развития и правильного использования доступных ресурсов. Видение — ориентир, куда нужно прийти по окончанию работы.
Product Vision динамичнее миссии и может меняться вслед за изменениями окружающего мира (что вполне логично). Видение должно быть у каждого продукта, иначе получается ходьба вслепую без ориентира.
Как использовать Product Vision в работе
Product Vision выполняет несколько задач. Во-первых, помогает команде выполнять «полезную» работу и приближаться к намеченной цели. Во-вторых, корректирует маркетинговые стратегии с целью достичь максимальной эффективности (т.е. продаж).
Видение продукта разрабатывают на начальных этапах планирования. В дальнейшем его используют для определения приоритетов бэклога и ежедневного принятия решений. Product Vision можно описать как один из инструментов приоритезации: ориентируясь на него, команда понимает, какие задачи выполнять в первую очередь, а какие оставить на потом.
В эффективном Product Vision четко описывают целевую аудиторию будущего продукта (кто будет потребителем) и отвечают на вопрос, почему вообще решили заняться реализацией.
Не менее важно подробно описать преимущества, почему целевая аудитория должна стать клиентами (или рассказать о болях и проблемах, которые решает продукт). Не зацикливайтесь на характеристиках. Описывайте преимущества так, чтобы потенциальный потребитель почувствовал, что это именно то, что он так давно искал.
Найдите тонкую грань конкретики. Если описать преимущества слишком точно, можно заинтересовать только узкий круг лиц.
И конечно, нельзя забывать про конкурентные преимущества. Вы и вся команда еще до начала фактической разработки должны понимать превосходства над основными конкурентами
Разработка Product Vision — не такой уж и легкий процесс, как может показаться сначала. Но зато видение помогает продакту и команде создать крутой продукт, который решает реальные проблемы целевой аудитории.
Шаблоны и примеры Product Vision
Для упрощения разработки видения продукта специалисты разработали шаблон Product Vision. Он включает в себя необходимые блоки, которые нужно дополнить информацией о своем продукте:
Для (ключевой пользователь)
Который (обозначение проблемы или возможности)
(Название продукта) это (категория продукта)
Который (ключевое преимущество, убедительная причина для покупки)
В отличие от (ключевой прямой конкурент)
Наш продукт (обозначение ключевого отличия)
Это оптимальный вариант для начинающих, кто хочет создать первые видения. Простой пример:
Для индивидуальных предпринимателей, которые хотят сделать недорогую, но привлекательную email-рассылку для своих клиентов. «Современная почта» — это веб-сервис, в котором любой предприниматель без опыта может на основе шаблонов создать современную рассылку с высоким open rate. В отличие от зарубежного конкурента MailChimp, наш продукт ориентирован на российских предпринимателей и обходится гораздо дешевле.
Или еще:
Для начинающих продактов, которые хотят получить базовые знания о профессии. «ProductStar» — современная онлайн-школа менеджеров продукта, в которой актуальные знания может получить любой желающий. В отличие от Школы N мы ориентируемся на предоставление «свежих» знаний от практикующих специалистов по минимальной цене.
Можете использовать структуру Джеффри Мура, которую он предложил в 2006 году в книге «Преодоление пропасти»:
Для (целевого клиента), который (заявление о необходимости или возможности), (название продукта) является (категория продукта), что (ключевая выгода, причина для покупки).
В отличие от (первичной конкурентной альтернативы), наш продукт (утверждение первичной дифференциации).
По такой схеме он писал заявления о позиционировании. Но как показывает практика, формат подходит для создания видения продукта.
Вот пример:
Для начинающего специалиста, который хочет построить хорошую карьеру, ProductStar — отличный вариант получения начального образования и старта карьеры вне зависимости от места проживания.
В отличие от Школы N, ProductStar приглашает практикующих специалистов, дающих актуальные знания о профессии.
На самом деле сегодня в российском интернете есть много шаблонов Product Vision, но эти самые популярные и чаще других используются специалистами. Они просты и удобны, позволяют быстро подготовить хорошее видение продукта.
Но при этом вы загоняете себя в определенные рамки. Сделать лишнее движение в сторону не получится, иначе шаблон сломается и тогда хороший результат не гарантирован. Поэтому решайте сами: составлять Product Vision с нуля или использовать шаблон.
Как создать хороший Product Vision
Использование шаблонов не гарантирует получение хорошего Product Vision. Сначала соберите важные данные, нужные для составления видения продукта:
что нужно вашему клиенту;
какова текущая ситуация на рынке;
какова ваша конкурентоспособность в целевых областях.
Для сбора этой информации проведите исследования рынка и анализ конкурентов.
У начинающих специалистов редко получается подготовить видение продукта с первого раза. Как правило, первый вариант — черновой, второй — отредактированный и только третий — итоговый. Советуем проводить разработку Product Vision на общем совещании команды, чтобы не упустить важные детали.
Вот еще несколько советов от опытных продактов, как сделать видение продукта эффективным:
Мотивируйте команду на достижение целей. Грамотный Product Vision дает четкие ориентиры для команды. Абстрактные цели не подойдут, они должны быть понятными и осязаемыми. Тогда вся команда покажет максимальную эффективность и никто не спросит, почему приходится работать с раннего утра до позднего вечера. Все сотрудники сами будут хотеть этого.
Не усложняйте, делайте видение простым. Четко пропишите в Product Vision, что делать разработчикам, а чего нет. Это должна быть инструкция, по которой команда сможет работать без вас.
Создайте ценность для компании. Видение продукта должно не только удовлетворять ваши потребности, но и создавать дополнительную ценность для организации (особенно если планируете получать финансирование и поддержку). Впоследствии продавать продукт будет проще, если видение направлено на поддержку целей компании.
Как заставить Product Vision работать
Не меняйте видение продукта слишком часто, особенно если рынок и конкуренты существуют без перемен. Тогда оно будет приносить пользу в течение нескольких лет. Но это возможно в случае с Product Vision, основанном на потребностях, которые удовлетворят и порадуют целевую аудиторию.
Иногда прибегают к созданию особенных видений для достижения краткосрочных целей. Как правило, его больше конкретизируют и затачивают под определенную задачу. Важно, чтобы краткосрочный Product Vision был тесно связан с долгосрочным, иначе эффективность будет минимальной.
Есть несколько способов внедрить видение продукта в работу команды:
Сделайте физический вариант Product Vision. Распечатайте большой плакат и передайте команде. Если над созданием продукта трудится несколько коллективов, сделайте по одному экземпляру на каждый.
Включите видение продукта в рабочий процесс. Убедитесь, что оно включено в цели продукта и выпуска.
Взаимодействуйте с документом при составлении краткосрочных спринтов. Со временем видение станет частью вас, всегда будет в голове и станет направлять в работе.
Правильный Product Vision направляет команду, помогает в выполнении задач и достижении целей. Поначалу кажется, что сделать видение продукта несложно. На самом деле требуется немало времени, чтобы получить хороший результат. Используйте шаблоны, данные в статье, для упрощения задачи. Но не бойтесь вносить правки и экспериментировать — только так можно добиться успеха!
Ещё больше о Product Vision вы можете узнать на нашем годовом курсе «Профессия: Продакт (с 0 до PRO)»