Что значит определение потребности в проекте
Определение потребностей
Как можно раньше определите все, что вам понадобится для успешного осуществления проекта. Большинство ваших потребностей относятся к ресурсам, например:
• персонал. «Мне необходим технический редактор на 40 часов в августе»;
• бюджет. «Мне требуется 10 тыс. долл. на приобретение компьютерных периферийных устройств»;
• другие ресурсы. «Для тестирования мне нужен доступ в лабораторию на месяц начиная с середины июня».
Старайтесь как можно конкретнее указывать все, что вам необходимо.
Ваши потребности могут, конечно, возрастать по мере разработки детального плана.
Данный текст является ознакомительным фрагментом.
Продолжение на ЛитРес
Читайте также
Пути удовлетворения потребностей
Пути удовлетворения потребностей На основе изучения клиента и издания агенту следует разработать пути удовлетворения имеющихся у компании потребностей.Например, если у рекламодателя есть потребность делать деньги, а газета имеет аудиторию, в которой есть его
Выявление потребностей
Выявление потребностей Важно сразу же определить, что за человек зашел к вам в магазин. В России говорят: «Встречают по одежке». Об этом лучше забыть! Часто люди одеваются скромно, но при этом готовы купить товар на огромную сумму. Если он зашел не в пиджаке, а в футболке, не
Определение места (выбор рынка, определение сегмента)
Определение места (выбор рынка, определение сегмента) План маркетинга предполагает сегментацию рынка, а также изучение нового товара применительно к каждому сегменту или рынку, что позволяет определить круг потребителей, на который следует в первую очередь
Выявление потребностей
Выявление потребностей Принцип выявления потребностей, по сути, один из аспектов маркетингового подхода в продажах.Филип Котлер в своем бестселлере «Основы маркетинга»[11] процитировал Питера Друкера: «Цель маркетинга – сделать усилия по продажам ненужными. Его цель –
ВЫЯВЛЕНИЕ ПОТРЕБНОСТЕЙ КЛИЕНТА
ВЫЯВЛЕНИЕ ПОТРЕБНОСТЕЙ КЛИЕНТА На этом этапе ваша задача – понять, что клиенту надо, что его может заинтересовать в ваших товарах и услугах, в чём именно состоят его потребности. Для этого торговый представитель (агент, менеджер) задаёт вопросы и внимательно слушает.
Выявление потребностей
Выявление потребностей Выявление потребностей – очень серьезный шаг, предваряющий объявление начальных условий. Сейлз-менеджеру необходимо понять, как он должен обозначить цель переговоров для того, чтобы она не выглядела недосягаемой или, наоборот, незначительной. До
Определение потребностей исполнителей
Определение потребностей исполнителей Для надлежащего выполнения делегированного задания человеку, прежде всего, необходимо знать факты и чувствовать поддержку.Чтобы ясно осознавать конкретные требования к поручаемой работе, исполнители должны иметь полную
3. Содержательные теории мотивации: теория иерархии потребностей А. Маслоу; двухфакторная теория Ф. Герцберга; теория приобретенных потребностей МакКлелланда; теория ERG К… Альдерфера
3. Содержательные теории мотивации: теория иерархии потребностей А. Маслоу; двухфакторная теория Ф. Герцберга; теория приобретенных потребностей МакКлелланда; теория ERG К… Альдерфера Содержательные теории мотивации. Одним из первых теоретиков содержательных теорий был
Удовлетворение потребностей гостей
Удовлетворение потребностей гостей По всем показателям удовлетворенности гостей компанией Southwest она превосходит своих конкурентов из года в год в течение вот уже десятилетия согласно Американскому индексу удовлетворенности
1.3. Пути удовлетворения потребностей
1.3. Пути удовлетворения потребностей На основе изучения клиента и издания агенту следует разработать пути удовлетворения имеющихся у компании потребностей.Например, если у рекламодателя есть потребность делать деньги, а газета имеет аудиторию, в которой есть его
Определение полноты потребностей сегментов
Определение полноты потребностей сегментов Развитие любого направления бизнеса происходит на основе изучения потребностей сегментов. Салонный бизнес обладает рядом специфических особенностей. Поэтому сначала рассмотрим общий способ определения полноты
Выявление потребностей
Выявление потребностей Этап не менее важный и вполне логично встраиваемый в беседу. Только давай вспомним, что мы продаем по телефону не карту, а встречу! Вот и потребности мы будем выявлять исходя не из того, зачем человеку карта, а из того, почему ему всенепременно нужно
3. Безошибочное определение потребностей
3. Безошибочное определение потребностей Проделав первые два шага в процессе продаж – определив, кто ваши потенциальные клиенты, и наладив с ними хорошие, доверительные отношения, – вы наконец перейдете к собственно обсуждению предлагаемого вами продукта.
Выявление потребностей клиента: что это, как и зачем
Путь к сердцу покупателя лежит через понимание его болей и нужд. Поэтому выявление потребностей клиента — один из важнейших этапов как в продажах, так и в формировании лояльности.
Если вы будете внимательное относится к потребностям клиентов, они это обязательно оценят, и в итоге такой подход принесет вам не только удовлетворенных клиентов, но и повторные продажи.
Что мы называем выявлением потребностей
Потребность — ощущение нехватки или недостаточности чего-либо. В продажах это нужда, которая закрывается приобретение какого-то товара или услуги. Возникает она из-за естественных причин, например, голод, ощущение дискомфорта, или под влиянием внешних факторов — мода и так далее.
Распространенная ошибка — рассказывать о преимуществах товара, которые вы сами считаете важными. В мире покупателя они могут иметь гораздо меньшую ценность. На первом месте будут те качества, которые закрывают потребность. Например, вы продаете ковры и рассказываете об их износостойкости, красоте, легкости в уходе. А покупатель хочет, чтобы новая вещь дорого смотрелась в его гостиной. Если не переключиться на рассказ об эксклюзивном дизайне и престижности товара, есть риск, что клиент уйдет без покупки.
Чтобы продать товар, специалисту нужно понять, какая потребность привела покупателя в магазин. Узнайте, что на самом деле скрывается за желанием обладать вашим продуктом и поймете, как его продавать. Все, что вы во время этого — и есть выявление потребностей покупателя.
Откройте для себя чат-бота
Выстраивайте автоворонки продаж и отвечайте на вопросы пользователей с помощью чат-бота в Facebook, VK и Telegram.
Какими бывают потребности клиентов
С точки зрения продаж можно выделить потребности клиента в:
Потребность в безопасности, комфорте и надежности можно отнести к группе рациональных потребностей. Это потребности, без которых человек не сможет нормально существовать. Когда оперируют рациональными потребностями, делают акцент на функциональности продукта, например: «Это куртка из холодоотражающего материала — вы не замерзнете на улице и не вспотеете, когда будете ехать в транспорте».
Соответственно, потребность в статусности и новизне — это эмоциональные потребности. Товар, который удовлетворяет их, должен отображать ценности потребителя, его мировоззрение.
Часто играют на эмоциональных потребностях клиента крупные бренды. Например, Apple, который ассоциируется с успешностью. Они транслируют своему покупателю «Если ты обладаешь Apple, ты не такой, как все, ты особенный».
Отдельно выделяют сопряженные и не сопряженные потребности.
Сопряженные потребности похожи на цепочку. Удовлетворение одной влечет за собой появление следующей. Например, покупателю ботинок может понадобится крем для обуви или шнурки. А клиенту, купившему новый автомобиль — надежная охранная система и коврики в салон.
Не сопряженные потребности — это единичные нужды. К примеру, желание выпить чашечку кофе с утра или спонтанная потребность купить понравившиеся часы.
Зачем нужно знать потребности клиента
Задача продавца и маркетолога — нащупать главные боли клиента и предложить их решение. Можно описывать достоинства продукта одинаково для всех покупателей, но такой подход не принесет хорошие продажи. Для каждого покупателя разные его характеристики будут решающими, продавцу нужно понять какие именно.
Например, клиент выбирает велосипед, чтобы вспомнить детство и покататься за городом. Неопытный продавец расскажет про восемь скоростей, подседельную трубу из сверхлегких сплавов и надежную тормозную систему. Грамотный продавец сначала узнает, какую картину нарисовал в голове покупатель. А потом предложит велосипед «как в детстве, только лучше».
Зная, как выявить потребности клиента, вы будете грамотно вести себя во время продажи — не рассказывать клиенту «с порога», какой у вас восхитительный продукт и перечислять все его характеристики, а выясните истинные потребности клиента, и расскажете, как продукт их закроет.
Если вы расскажете о важных для клиента достоинствах товара, но у клиента возникнут возражения, вы все равно будете знать, как себя вести. Скорее всего, дело не в продукте. Покупатель просто не до конца уверен, что сможет закрыть свои потребности с помощью вашего товара. Зная это, вы найдете правильные слова для ответа на возражения.
А если клиент будет сомневается, не сможет сделать выбор. Вы сможете помочь ему — дадите почувствовать свою заботу, покажете, что понимаете его потребности. Это поможет клиенту выбрать и все-таки сделать покупку.
Методы выявления потребностей клиента
Выявить потребности клиента можно благодаря его рассказу. В любом случае покупателя нужно выслушать и задать нужные вопросы. Но от конкретного случая будет зависит, какой из методов выявления потребностей клиента будет преобладать.
Внимательно слушать клиента
Подходит для случаев, когда покупатель знает свои потребности и готов о них рассказать. Задача продавца — выслушать, задать уточняющие вопросы, если нужно, и убедиться, что утверждения клиента не противоречат друг другу. Например, покупатель говорит, что ему нужен фотоаппарат для снимков на отдыхе. Просит показать водонепроницаемые модели с хорошим качеством снимков. Но в процессе выясняется, что самый важный критерий — возможность перевозить технику в небольшой сумке для ручной клади.
Кажется, ничего нет сложного в том, чтобы просто слушать. Но это тоже нужно делать правильно. Не нужно перебивать собеседника — стоит сначала дать клиенту выговориться, а потом только задавать вопросы. Важно и не тратить время попусту. Клиент может заговориться и уйти от темы товара, вы должны уметь аккуратно вернуть разговор в нужное русло.
Поддерживайте зрительный контакт и показывайте, что вы заинтересованы в том, что рассказывает покупатель: поддакивайте, поддержите разговор и потом предложите варианты. Это позволит заинтересовать клиента в продолжении диалога, ведь так вы покажете, что реально хотите ему помочь.
Активно задавать вопросы
Не все покупатели рассказывают, что им нужно. Не все даже это знают. Поэтому продавцу нужно задавать правильные вопросы, чтобы выявить потребности клиента. Но при это важно держать баланс и не переусердствовать, чтобы клиент не чувствовал себя, как на допросе.
В каком порядке проводить выявление потребностей клиента с помощью вопросов:
Типы вопросов для выявления потребностей клиентов
Мало знать, какой вопрос задать покупателю, важно уметь его правильно сформулировать. Для этого изучите типы вопросов.
Старайтесь задавать клиентам больше открытых вопросов. Для этого начинайте со слов «что», «зачем», «для чего». Например, «Для чего вы планируете использовать миксер?». На такой вопрос нельзя ответить односложно, поэтому он хорошо помогает поддерживать разговор и узнавать больше.
Закрытыми вопросами можно уточнить готовность покупателя к разговору или к совершению покупки. Например, «Вы определились?»
Альтернативные вопросы несут в себе оттенок манипуляции. «Вы хотите купить белый шарф или синий?». Их нужно задавать с осторожностью, чтобы не вызвать раздражения у покупателя.
Наводящие вопросы тоже помогают управлять покупательским поведением, но делают это более тонко. «Вам нужна входная дверь? Ищете что-то надежное и качественное?».
Нил Рэкхем, создатель методики SPIN-продаж, основанной на умении правильно задавать вопросы, делит вопросы для выявления потребностей клиентов на:
Это деление не по структуре вопросов, а по их смысловому наполнению.
Ситуационные вопросы задают в начале общения, для выяснения общей ситуации. Например: «Вы ищете конкретную модель?».
Проблемные вопросы — самые важные для выявления потребностей покупателя. Они дают понимание того, зачем он пришел к вам. Задайте проблемный вопрос, и вы узнаете, о каких преимуществах товара стоит рассказать в первую очередь. Пример такого вопроса: «Вам нужна машинка для стрижки, чтобы реже ходить в парикмахерскую?».
Извлекающие и направляющие вопросы похожи на наводящие. Первые работают с опасениями и страхами клиентов. Вторые — с ожиданиями и мечтами. К примеру: «У вас уже были проблемы с двигателем из-за некачественного масла?» и «Вы ищите то, что поможет продлить срок службы автомобиля?».
Неопытному продавцу сложно быстро сориентироваться и задать правильный вопрос. Напишите в помощь ему скрипты. Они подскажут, что говорить в той или иной ситуации.
Ошибки при выявлении потребностей клиента
До этого речь шла о том, как выявление потребностей помогает продавцу, но продажи будут успешными, если до продавца над этой задачей поработал маркетинговый отдел. Самая главная ошибка — отложить выявление потребностей покупательской аудитории до этапа продаж. Выяснить нужды клиентов — задача маркетологов. На основе этих знаний производят продукт, делают для него грамотную упаковку и рекламу. Продавец встает в конце этой цепочки и работает с конкретными потребителями. Вот почему составление основных портретов клиентов — неотъемлемая часть маркетинговой стратегии.
Главная ошибка, которую может допустить продавец — забыть о потребностях клиентов. Бесполезно рассказывать об особенностях товара, о его преимуществах, пока вы не знаете, для чего товар нужен конкретному покупателю.
Пять ошибок, которых необходимо избегать в процессе выявления потребностей клиентов:
Что в итоге
Выявление потребностей покупателя — один из этапов продаж. Сложно делать продажи без четкого понимания, зачем покупателю ваш товар. Понимая истинные нужды клиентов, вы грамотно расскажете, как удовлетворить их с помощью продукта.
Чтобы достичь этого понимания, важно знать, какие типы вопросов используются для выявления потребностей клиента. Вы можете задавать их все или выбрать те, которые больше подходят в данной ситуации.
Для онлайн-торговли тоже важно понимание потребностей покупателей. Выявить их можно с помощью маркетинговых исследований, вопросов службы поддержки и анализа статистики посещений вашего сайта. Используйте полученную информацию при создании контента и рассылок с помощью SendPulse.
Практика формирования требований в ИТ проектах от А до Я. Часть 2. Цели и Потребности
IV ОПРЕДЕЛЯЕМ ЦЕЛИ, ПРОЕКТА
Цель не обязательно должна достигаться. Порой это просто направление двигаться дальше.
Брюс Ли.
Одним из основных признаков системы, отличающим ее от разрозненных компонентов, является подчиненность всей организации системы — некоторой цели. Проектная работа команды, представляет собой тоже некую систему и соответственно должна «идти на поводу» у какой-то цели. Потому, установив коммуникации между участниками проекта, начнем определять цели, которые мы хотим достичь в результате создания нового продукта.
Цель данной группы работ: определить основные задачи, которые ставят перед собой группы заинтересованных лиц, участвующих в проекте.
Сейчас, в литературе доступен целый букет методик определения и формулирования целей. Есть даже такое направление — целеполагание, обучающее правилам постановки целей.
Цитата, приведенная в начале этого раздела, на мой взгляд, как нельзя лучше показывает роль целей в проекте по разработке Программного Обеспечения (ПО). Из моей практики, к целям, сформулированным на стадии инициирования проекта, возвращаются крайне редко. Формулирование целей в данном контексте — это скорее декларативный шаг провозглашения лозунгов, поднимающий командный дух и дающий команде старт для совместного обсуждения их ближайшего будущего. Чтобы предупредить критическую оценку своих высказываний со стороны знатоков целеполагания, сразу оговорюсь, что в дальнейшем мы будем формировать требования, детализирующие наши цели. Эти требования и будут соответствовать всем постулатам технологии SMART. SMART — методика оценки эффективности целеполагания по пяти критериям (конкретность, измеримость, достижимость, ориентация на результат, ограниченность по времени).
С точки зрения руководителя проекта правильно сформулированные цели должны позволить:
Определяя цели, важно учитывать два важных момента:
Еще раз отдельно заострю ваше внимание на том, что при формулировании целей проекта, надо постараться заложить в них и свои собственные (команды реализации) стратегические интересы, которые Вы хотите достичь в результате своей деятельности в проекте.
А вот при определении целей заказчика, совместно с его представителями, аналитик должен в первую очередь оперировать понятием выгоды, которую получит владелец от использования каждой рассматриваемой функции целевой системы. Поэтому, когда заказчик просит реализовать Вас какую-то возможность, приучите его сразу задуматься, а какой профит он с этого получит. Так Вы можете еще на начальном этапе отмести часть излишних требований и сэкономить время на стадии определения границ проекта, но об этом чуть позже.
На рисунке 4.1 изображен процесс формирования целей создания информационной системы.
Рисунок 4.1 — модель процесса формирования целей
Отбросив общие цели процесса разработки требований, попытаемся выделить главные задачи, которые должна решить проектируемая нами учебная система «Управления требованиями», для удовлетворения, существующих потребностей заказчика. Поскольку в учебном проекте я выполняю и функцию аналитика, и имитирую деятельность заказчика, то приведу «наши совместные» размышления по формулированию каждой цели.
Прежде всего, следует обратиться к доступным источникам, описывающим проблемы и решения автоматизируемой предметной области. Согласно SWEBOK (Software Engineering Body of Knowledge), анализ требований Requirement Process состоит из следующих основных составляющих:
Итак, первый процесс, который мы будем выполнять при разработке требований — это сбор информации о задачах, целях и проблемах заказчика, которые он собирается решать при помощи создаваемого (целевого) продукта. На основании этих пожеланий будут сформулированы некие потребности заказчика (требования пользователей), пригодные для выполнения дальнейших работ по их реализации.
Добавим в глоссарий термин:
Эту информацию мы должны зафиксировать и обязательно предоставить для обсуждения всем заинтересованным лицам проекта, с возможностью их дополнения и изменения. Откуда вытекает первая цель нашей системы:
1. Фиксировать перечень потребностей пользователей, которые они желают удовлетворить при помощи целевого продукта.
На основании утвержденных с заказчиком потребностей, подлежащих автоматизации (домен проблем), мы будем формировать спецификации требований к разрабатываемому продукту (домен решений), используя известные приемы, которые будут описаны ниже. Поскольку большая часть процесса разработки программных продуктов строится как раз вокруг спецификаций требований, следующая цель нашей системы:
2. Фиксировать перечень функциональных и системных требований, предъявляемых к разрабатываемому продукту. Добавим небольшое уточнение: в том числе фиксировать покрытие пожеланий пользователей (области проблем) системными требованиями (областью решений).
Согласуем термин требования в Глоссарии:
Спецификации требований станут в нашей системе каркасом, связывающим все части проекта от потребности заказчика (поскольку, они явно связаны со спецификациями) до реализованных функций в целевом продукте. Для этого, на основании спецификаций, мы будем выставлять задания исполнителям на проектирование, разработку, тестирование, развертывание, пилотное внедрение и т.д. Разработчики в коде укажут ссылку на задачу. По задаче можно выяснить требования и т.д. в реверсном направлении к потребностям пользователя. Опираясь на вышеизложенные постулаты, сформулируем следующую цель:
3. На основании спецификации требований выставлять задания исполнителям, направленным на их реализацию в конечном продукте.
Поскольку факт выполнения задания, по сути, выполняет продвижение функциональности продукта к запланированным характеристикам, нам необходимо фиксировать в системе все действия, предпринятые исполнителями, по задачам. Таким образом, мы сможем в разрезе времени и каждого отдельного требования отслеживать приращение функциональности целевого продукта. Следовательно, следующую цель можно сформулировать так:
4. Фиксировать факт выполнения заданий исполнителями.
Практически в каждом проекте, по ходу его реализации, происходят изменения и уточнения требований. Это отдельный раздел в дисциплине «Анализ требований» и не упомянуть этот процесс в нашем проекте мы не можем, а потому еще одна цель:
5. Управлять изменениями требований.
Теперь, когда мы разобрались с основными целями, перейдем к формулированию потребностей заказчика, которые удовлетворят поставленные цели.
V УТОЧНЯЕМ ПОТРЕБНОСТИ ЗАКАЗЧИКА
Из всех возможных способов совершенствования процесса разработки ПО наибольшее преимущество за формулированием требований.
Карл Вигерс
Дисциплина «Системный анализ», для борьбы со сложностью, предлагает использовать такие основные приемы, как абстракция и декомпозиция, позволяющие раскладывать требования по уровням представления. Следуя этим принципам, в основе пирамиды анализа располагаются Цели, например, описанные в предыдущем разделе. Поднимаясь вверх, мы раскладываем их на более мелкие элементы, собирая пожелания заказчика к функциональности разрабатываемого продукта.
Цель данной группы работ: собрать максимально полные и точные сведения о потребностях заказчика, которые они хотят удовлетворить при помощи целевого продукта.
При сборе потребностей заказчика необходимо помнить: если потенциальные пользователи системы излагают Вам какие-то пожелания, которые мы не можем связать ни с одной из целей, то следует уточнить у заказчика, необходимость автоматизации этой потребности, либо пересмотреть еще раз цели.
Еще одно важное предостережение: не пытайтесь описывать потребности пользователей в терминах программного продукта, это плохая практика. Избегайте таких выражений как: «выбор в меню», «нажатие кнопки», «внесение в поле» и т.п., а используйте например такие: «выбор варианта», «выполнение процесса», «определение значения» и т.п.
Рисунок 5.1 — модель процесса формализации потребностей заказчика
Дале мы будем расширять и детализировать эту модель (см. рис. 5.1), продвигаясь от раздела к разделу в процессе формирования спецификайий требований.
1. ЗАДЕЙСТВУЕМ ПОЛЬЗОВАТЕЛЬСКИЕ ИСТОРИИ ДЛЯ ОПРЕДЕЛЕНИЯ ПОТРЕБНОСТЕЙ ЗАКАЗЧИКА
На мой взгляд, с самого начала проекта, очень удобно использовать метод описания «Пользовательских историй». Этот прием хорошо описан в методиках гибкого программирования Scrum, КАНБАН [10]. Суть его состоит в том, что команда, совместно с владельцами процессов, составляет небольшие, в одно-два предложения, сценарии бизнес процессов, подлежащих автоматизации. Для каждой Пользовательской истории (англ. User Story) определяется цель, которая должна быть достигнута в результате ее выполнения. Если цель сформулировать сложно, следует задуматься о целесообразности использования этого сценария в общем процессе.
Важно осознавать, что формирование Пользовательских историй подразумевает непосредственное вовлечение будущих потребителей разрабатываемого продукта в процесс его создания, делая их соавторами (или соучастниками в случае провала). И этот факт нужно обязательно использовать, путем донесения до сознания заказчика, необходимости разделения ответственности за качество создаваемого продукта.
Пользовательские истории удобно писать на стикерах, наклеенных на доску, к которой имеет постоянный доступ вся команда проекта. Эта площадка обычно используется для проведения митингов – совместного обсуждения этапов реализации процесса автоматизации объявленных бизнес сценариев. Оформление Пользовательских историй на стикере, гарантирует, что она не станет слишком большой.
При прохождении Пользовательской историей жизненного цикла: формирования, обсуждения, реализации, тестирования и т.д., стикеры с их описаниями переклеивают на разные «дорожки», соответствующие этапу разработки. Таким образом, в небольших проектах, при помощи описанного приема, управляют не только содержанием проекта верхнего уровня, но и процессом его реализации. Я бы рекомендовал использовать такой подход и в больших проектах, в которых применяются профессиональные инструменты управления требованиями. Этот метод имеет не только практическое, но и большое психологическое значение, влияющее на командный дух проекта. Пример Пользовательской истории показан на рисунке 5.1.
Рис. 5.1. Пользовательская история
Пользовательские истории также эффективно можно использовать и для приемочного тестирования.
Исходя из выявленных выше целей, начнем собирать и публиковать пользовательские истории (Функциональные требования).
Итак, нам необходимо разработать Программный Продукт, который обеспечит поддержку следующих бизнес процессов:
US01. Описать пользовательскую историю на стикере. Сформулировать Цель процесса.
Цель: Зафиксировать бизнес процесс, подлежащий автоматизации, в доступной для обсуждения форме.
«US01» — в данном примере — это идентификатор Пользовательской истории, состоящий из префикса, указывающего на тип артефакта проекта (User Story) и его порядкового номера. Добавим в глоссарий термин:
Как правило, стиль изложения и содержание пользователями своих пожеланий к разрабатываемому продукту, мягко говоря, не идеален. Даже показав эти пожелания другим членам команды, мы сталкиваемся с непониманием ими сути проблемы. Поэтому, каждую пользовательскую историю желательно обсудить с заинтересованными участниками и попытаться сформулировать ее понятно и односложно. Запишем это так:
US02. Обсудить пользовательскую историю с участниками проекта. При необходимости внести изменения.
Цель: Ознакомить команду проекта со сценарием бизнес процесса. Согласовать его.
Для дальнейшего использования Пользовательской истории, нам необходимо зафиксировать ее в системе. Например, связав Пользовательскую историю с соответствующими требованиями, мы сможем трассировать ее реализацию в конечном продукте через цепочку: Пользовательская история → Требование, созданное по ней → Задания, выставленные по требованию и т.д. Формулируем:
US03. Опубликовать в системе, согласованные Пользовательские истории.
Цель: Зафиксировать в системе перечень утвержденных Бизнес-требований, для их учета и обработки.
Поскольку Пользовательские истории формулируются автором или группой авторов и представляют их взгляд на проблемы, входящие в сферу их интересов, нам необходимо фиксировать этих «заинтересованных лиц» в нашей системе. Для развития любого проекта очень важно определить круг лиц, так или иначе заинтересованных в получении целевого продукта. На основании этих данных мы будем согласовывать требования, определять роли пользователей и т.п.
US04. На основании Пользовательских историй, определить основных заинтересованных лиц проекта.
Цель: Зафиксировать в системе перечень участников и заинтересованных лиц проекта.
Пользовательская история не дает нам основания сразу приступать к написанию кода программы, поскольку это всего лишь определенный взгляд на процессы, по сути – декларации или наброски. Сначала потребуется их уточнение, детализация, разработка алгоритмов, четко регламентирующих выполнение процессов, моделирование структуры объектов предметной области и т.п. Поэтому, окончив процесс фиксации основных Пользовательских историй, мы приступаем к моделированию процессов и объектов, реализующих их. Попутно определяем их связи и информационные потоки. Сформулируем это так:
US05. На основании Пользовательских историй, определить основные функциональные требования к разрабатываемой системе.
Цель: Зафиксировать в системе перечень бизнес процессов, подлежащих автоматизации.
После определения полной функциональности разрабатываемого продукта, часто приходит осознание того, что весь этот перечень реализовать в установленные сроки, имеющимися ресурсами — не реально. И тогда, нужно разделить функции на: жизненно необходимые для поддержания процесса и функций, которые нужны, но пока без них можно обойтись. Сжав эти размышления в одно предложение, зафиксируем:
US06. На основании подготовленного перечня автоматизируемых процессов, определить их приоритетность и очередность.
Цель: Определить текущие границы проекта.
Когда все процессы, классы, хранилища и прочие объекты разрабатываемых требований спроектированы, необходимо всю эту информацию «нанизать» на единый стержень, связывающий между собой элементы: в нотациях, документах описаниях и прочих артефактах. Таким стержнем обычно выступают спецификации требований. Они фиксируются в виде структурированных данных, имеют уникальный идентификатор, на который и ссылаются все вышеперечисленные артефакты. Записываем следующую Пользовательскую историю:
US07. На основании процессов, выявленных для автоматизации, сформулировать спецификации требования для реализации их в продукте. Зарегистрировать требования в системе, соотнести с Пользовательскими историями.
Цель: Зарегистрировать в системе: контент, концептуальное наполнение содержания проекта, формулировки сути автоматизируемых сервисов, обеспечивающих базис для разработки продукта, его тестирования и передачи в эксплуатацию.
Когда мы разработаем спецификации, мы получим полный список низкоуровневых требований к системе с подробным описанием их реализации. На основании этого списка мы сможем выставлять задания или цепочки заданий исполнителям на проектирование, разработку, тестирование, развертывание, пилотное внедрение и т.д. При выставлении задания по требованию, его состояние в системе может автоматически меняться. Таким образом, в списке спецификаций мы сможем увидеть, какие требования уже взяты в работу, а какие еще ожидают в очереди. А поскольку спецификации связываются и с Пользовательскими историями, то по цепочки мы сможем отслеживать и их состояние.
US08. На основании спецификации требования, сформировать задания исполнителям. В ходе исполнения заданий изменить состояния требований.
Цель: На основании требования, обеспечить процесс реализации проекта в целевом продукте.
Задание, выставленное исполнителю, становятся доступными ему в системе. Поскольку задание выставлено по требованию, исполнитель может ознакомиться с его спецификацией, а также спецификациями всех связанных с ним требований.
Завершив работы, исполнитель фиксирует отчет о выполнении, «закрывая» свои задачи. Закрытие цепочки задач по требованию автоматически инициирует изменение его состояния.
US09. Зафиксировать факт выполнения задания исполнителем. Изменить состояние требования.
Цель: На основании факта выполнения задания исполнителем, обеспечить актуализацию процесса выполнения проекта.
Часто, после разработки первых прототипов целевого продукта, пользователей, ознакомившихся с его работой, посещает «прозрение». Они начинают отчетливо понимать, что хотели не “это” или не совсем “это”. Возникает необходимость вносить изменения в требования. Несмотря на кажущуюся простоту — это очень кропотливый процесс, требующий проведения изменений сквозь все артефакты проекта. Иногда, приходится вносить изменения от самого начала (фиксации Пользовательской истории) и далее по всем этапам, формирования требования.
US10. Внести изменения в спецификации требования для реализации в продукте. Изменить состояние требования. Синхронизировать с Пользовательской историей при необходимости.
Цель: Изменить содержание контента, обеспечивающего базис для разработки продукта, его тестирования и передачи в эксплуатацию.
Поскольку процесс управления Требованиями связан с постоянным мониторингом степени их выполнения, необходимо иметь удобный инструмент, позволяющий отбирать массивы требований по разным срезам их свойств, включая текущие состояния.
US11. Предоставить полный или ограниченный по разным срезам перечень требований с текущим состоянием.
Цель: Получить данные о текущем состоянии процесса разработки целевого продукта проекта.
В ходе продвижения проекта мы можем: добавлять новые Пользовательские истории; раскладывать утвержденные истории, детализируя их в группе, непосредственно занимающейся ее реализацией.
2. ИСПОЛЬЗУЕМ ВИЗУАЛИЗАЦИЮ ТРЕБОВАНИЙ ДЛЯ ОБСУЖДЕНИЯ ИХ С ЗАКАЗЧИКОМ
Еще один эффективный прием дисциплины «Системный анализ» — моделирование. Эрик Эванс в книге [13] позиционирует модель как: «язык, на котором говорят все члены группы разработчиков, а также могут … общаться со специалистами в предметной области без переводчика». Поэтому чем лучше мы подберем набор моделей для взаимодействия с заказчиком и членами команды проекта, тем более тесным и продуктивным будет наше сотрудничество и, соответственно, тем более полно и качественно мы сможем удовлетворить их потребности.
Для наглядности можно отображать пользовательские истории в виде моделей, представляющих набор связанных функций — сценариев на диаграммах Бизнес коммуникаций. В отличие от канонических диаграмм, здесь можно отобразить объекты разных типов в относительно свободной форме, тем самым, добавив наглядности.
Дадим определение модели, поскольку это один из ключевых элементов проектирования:
Пример модели формирования Пользовательских историй показан на рисунке 5.2.
Рис. 5.2. Сценарий формирования Пользовательской истории
На рисунке мы наглядно видим процессы, их последовательность и место выполнения, а также ресурсы.
С помощью таких рисунков заказчикам легче представлять предметную область и обсуждать требования к разрабатываемому продукту. Но, передавая заинтересованным лицам диаграммы подобного типа, следует сопровождать их устным, а лучше письменным описанием. Например, для презентации, приведенной выше диаграммы, можно использовать такой текст:
В центральной части рисунка изображен бизнес сценарий «Формирование Пользовательской истории». Сценарий состоит из четырех процессов, отображенных в той последовательности, в которой они должны выполняться. В нижней части изображены исполнители процессов, пунктирной линией обозначено их воздействие, а надписью определена роль. В верхней части диаграммы представлены места дислокации процессов, а линиями обозначены потоки данных, которые через них проходят.
3. ПОДВЕДЕМ ИТОГИ ПРОЦЕССА ОПРЕДЕЛЕНИЯ ПОТРЕБНОСТЕЙ ЗАКАЗЧИКА
Пользовательские истории, с одной стороны являются великолепным механизмом для выявления пользовательских требований, а с другой, их можно позиционировать, как основной инструмент влияния заказчика на разработку программного обеспечения. Проговаривание Пользовательских историй с заинтересованными лицами проекта на диспутах, побуждают людей многократно «проигрывать» в уме разные сценарии их работы, и не только те которые используются в настоящее время, но и те которые им хотелось воплотить в будущем.
В методологиях гибкого проектирования — Пользовательская история используется как быстрый способ документировать требования клиента, без необходимости разрабатывать обширные формализованные документы и впоследствии тратить ресурсы на их поддержание. Но такой подход может успешно использоваться только для небольших или несложных проектов, не связанных со «закрученными» бизнес процессами, которые не планируется развивать и поддерживать.
Я предлагаю использовать Пользовательские истории, как первый шаг в процессе сбора и формализации потребностей заказчика, для получения полного перечня бизнес задач, которые могут быть автоматизированы путем создания программного продукта. Дальше эти потребности должны быть детализированы и трансформированы в функции целевой системы.
В следующей части мы будем выявлять функции системы и определять границы проекта ссылка