1. Бизнес-требования

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

1.1 Исходные данные

Они суммируют обоснование и содержание нового продукта или изменения, которые нужно внести в существующий продукт.

Здесь помещают общее описание предыстории или ситуации, в результате чего было принято решение о создании продукта.

1.2 Возможности бизнеса

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

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

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

1.3 Бизнес-цели

Суммирует важные преимущества бизнеса, предоставляемые продуктом, в количественном и измеряемом виде. Банальности («стать компанией мирового класса») и нечетко сформулированные улучшения («обеспечить высокий уровень сервиса для клиентов») нельзя считать ни полезными, ни поддающимися проверке. В табл. 5-1 приведены примеры и финансовых и нефинансовых целей (Wiegers, 2007).

Табл. 5-1. Примеры финансовых и нефинансовых бизнес-целей

Финансовые цели	Нефинансовые цели
Освоить X% рынка за Y месяцев	Достигнуть показателя удовлетворения покупателей, равного по крайней мере X, в течение Y месяцев со времени выпуска продукта
Увеличить долю рынка в стране W с X% до Y% за Z месяцев	Увеличить производительность обработки транзакций на X% и снизить уровень ошибок данных до величины не более Y%
Достигнуть объема продаж X единиц или дохода в Y долларов за Z месяцев	Разработать надежную платформу для семейства связанных продуктов
Получить X% прибыли по инвестициям в течение Y месяцев	Разработать специальную базовую технологическую основу для организации
Достигнуть положительного потока денежных средств по этому продукту в течение Y месяцев	Добиться признания продукта лучшим по на- дежности в опубликованных обзорах продуктов к определенной дате
Сэкономить X долларов в год, которые в настоящий момент расходуются на обслуживание унаследованной системы	Обеспечение выполнения определенных нормативов регулирующих органов
Уменьшить затраты на поддержку с X до Y долларов за Z месяцев	Получить не более X звонков в службу обслуживания по каждой единице товара и Y звонков по гарантии каждой единице товара в течение Z месяцев после выпуска продукта
Увеличить валовую маржу для существующего бизнеса с X до Y% в течение одного года	Уменьшить время выполнения заявки до X часов на Y% звонков в службу поддержки

Организации обычно предпринимают проект для решения задачи или использования имеющейся возможности. Модель бизнес-целей отображает иерархию связанных бизнес-проблем и измеряемых бизнес-целей (Beatty и Chen, 2012). Проблемы описывают, что не позволяет организации достичь требуемых ориентиров в настоящее время, тогда как бизнес-цели определяют способы измерения достижения этих ориентиров. Задачи и цели взаимосвязаны: понимание одной раскрывают суть второй.

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

Разговор между бизнес-аналитиком и куратором, одним из топ-менеджеров компании, с целью определить бизнес-задачи и цели может выглядеть, как показано на рис. 5-4. Это иллюстрация к проекту системы Chemical Tracking System в компании Contoso Pharmaceuticals, описанной в главе 2. На основе ответов топ-менеджера компании бизнес-аналитик может сформулировать бизнес-цели для Chemical Tracking System, как показано на рис. 5-5.

Рис. 5-4. Пример разговора между аналитиком и куратором проекта

1.4 Критерии успеха

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

Рис. 5-5. Пример модели бизнес-целей для системы контроля химикатов

Бизнес-цели иногда невозможно измерить, пока не завершиться проект. В других случаях достижение бизнес-целей может зависеть от других проектов. Но все равно важно оценить успех конкретного проекта. Критерии успеха указывают, находится ли проект на пути достижения бизнес-целей. Эти критерии могут определяться во время тестирования или сразу после выпуска продукта. Для системы контроля химикатов одним из критериев может быть Бизнес-цель 3 на рис. 5-5:

«Сократить время заказа химикатов до 10 минут в 80% заказов», потому что среднее время заказа можно измерить во время тестирования или после выпуска. Другой критерий успеха может быть связан с Бизнес-целью 2 с временем, намного более ранним, чем год после выпуска, например: «Отслеживать 60% контейнеров промышленных химикатов и 50% специализированных химикатов через четыре месяца».

Внимание! Внимательно выбирайте критерии успеха. Убедитесь, что они оценивают то, что важно для бизнеса, а не просто то, что легко оценить. Критерий «Сократить затраты на производство продукта на 20%» легко оценить. Его также легко реализовать путем увольнения сотрудников или сокращения инвестиций в инновации. Но это могут быть не те результаты, которые подразумевались в целях.

1.5 Положение о концепции

Составьте сжатое положение о концепции проекта, обобщающее долгосрочные цели и назначение нового продукта. В этом документе следует отразить сбалансированную концепцию, удовлетворяющую различных заинтересованных лиц. Она может быть несколько идеалистичной, но должна основываться на существующих или предполагаемых рыночных факторах, архитектуре предприятия, стратегическом направлении развития корпорации или ограничениях ресурсов. Далее показан шаблон, состоящий из ключевых слов, которые прекрасно подходят для документа о концепции продукта (Moore, 1991):

• Для [целевая аудитория покупателей];
• Который [положение о потребностях или возможностях];
• Эта (этот) [имя продукта];
• Является [категория продукта];
• Который(ая) [основные функции, ключевое преимущество, основная
• причина [для покупки или использования];
• В отличие от [основной конкурирующий продукт, текущая система или текущий бизнес-процесс];
• Наш продукт [положение об основном отличии и преимуществе нового продукта].

Вот как выглядит положение о концепции системы контроля химикатов Chemical Tracking System в Contoso Pharmaceuticals, о которой говорилось в главе 2; ключевые слова выделены полужирным:

Для ученых, которым нужно запрашивать контейнеры с химикатом, данная система Chemical Tracking System является информационной системой, которая обеспечит единую точку доступа к складу химикатов и к поставщикам. Система будет знать местоположение каждого контейнера с химикатом в компании, количество химиката в контейнерах и полную историю перемещения и использования каждого контейнера. Эта система сэкономит компании 25% затрат на химикаты в первый год работы, позволив полностью использовать уже полученные химикаты, утилизировать меньшее количество частично израсходованных или просроченных химикатов и применять единую стандартную систему приобретения химикатов. В отличие от действующих сейчас ручных механизмов заказов химикатов наш продукт будет генерировать все отчеты, необходимые для регулирующих органов, в которых требуются сведения об использовании, хранении и утилизации химикатов.

1.6 Бизнес-риски

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

1.7 Предположения и зависимости

Предположение (assumption) — это утверждение, которое предполагается верным в отсутствие знаний или доказательств иного.

Бизнес-предположения тесно связаны с бизнес-требованиями. Неверные предположения могут не позволить достичь поставленных бизнес-целей. Например, куратор из руководства компании может поставить бизнес-цель увеличить доход на 100 тыс. долларов в месяц. Определяя такую цифру, куратор сделал определенные предположения, например что новый сайт будет привлекать 200 дополнительных уникальных посетителей в день и что каждый посетитель в среднем будет тратить 17 долларов. Если новый сайт не привлечет достаточно посетителей, тратящих достаточное количество денег, проект может не достичь своей бизнес-цели. Если окажется, что те или иные предположения не оправ дались, можете изменить границы или график проекта или запустить другие проекты, чтобы достичь другие цели.

Задокументируйте все предположения, сделанные заинтересованными лицами, когда они обдумывали проект и создавали данный документ о концепции и границах. Часто предположения одних лиц не разделяют другие стороны. Если вы запишите их и просмотрите позже, то избежите возможной путаницы и ухудшения ситуации в будущем.

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

Анализ требований к программному обеспечению

⇐ Предыдущая16171819202122232425Следующая ⇒

Анализ требований — это процесс сбора требований к программному обеспечению (ПО), их систематизации, документирования, анализа, выявления противоречий, неполноты, разрешения конфликтов в процессе разработки программного обеспечения. В англоязычной среде также говорят о дисциплине «инженерия требований» (англ. Requirements Engineering). В процессе сбора требований важно принимать во внимание возможные противоречия требований различных заинтересованных лиц, таких как заказчики, разработчики или пользователи.

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

Анализ требований включает три типа деятельности:

Сбор требований: общение с клиентами и пользователями, чтобы определить, каковы их требования.

Анализ требований: определение, являются ли собранные требования неясными, неполными, неоднозначными, или противоречащими, и затем решение этих проблем.

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

Выделяют следующие типы требований:

· Требования клиентов(эксплутационные);

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

• правильность

• универсальность

• надежность (помехозащищенность)

• проверяемость

• точность результатов

• защищенность

• программная совместимость

• аппаратная совместимость

• эффективность

• адаптируемость

• повторная входимость

• реентерабельность

· Функциональные требования;

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

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

Какие бывают требования?

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

Функциональная спецификация состоит из трех частей:

1. Описание внешней информационной среды, с которой будет взаимодействовать разрабатываемое программное обеспечение. Должны быть определены все используемые каналы ввода и вывода и все информационные объекты, к которым будет применяться разрабатываемое ПС, а также существенные связи между этими информационными объектами.

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

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

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

· Нефункциональные требования;

· Требования производительности;

· Производные требования.

 

---

⇐ Предыдущая16171819202122232425Следующая ⇒

---

Дата добавления: 2016-10-06; просмотров: 1846 | Нарушение авторских прав

---

Похожая информация:

Поиск на сайте:

Советы по составлению хороших бизнес требований

 

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

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

Этап сбора бизнес условий проекта состоит из следующих трёх шагов:

1.

Навигация по записям

Проведение встречи с заинтересованными сторонами и основными игроками;
2. Переработки и оценка информации, которая была получена на собрании;
3. Создание документа.

Этапы проведения собрания. Советы по составлению хороших бизнес требований:

— Главный аналитик собрания должен составить список вопросов, которые будут заданы каждой заинтересованной стороне и таким образом каждый пользователь будет вовлечён в процесс аккумуляции бизнес требований.

— Аналитик должен записать ответы на вопросы и выделить новые мнения, которые до этого не были известны.

Этапы проведения собрания:

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

— Этот процесс должен продолжиться до того момента, когда аналитик сможет подготовить итоговый доклад, с которым согласятся все.

После сбора бизнес требований:

— Аналитик подготавливает официальный документ и представляет его всем заинтересованным сторонам для одобрения и подписания.

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

— Если завершение контроля не завершено, тогда желательно, чтобы проект начался заново с первого этапа для дополнительного сбора бизнес требований и из анализа.

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

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

 

Списки требований

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

Преимущества

• Обеспечивает контрольный список требований.
• Обеспечивает договор между заказчиками и разработчиками.
• Для большой системы может обеспечить описание высокого уровня.

Недостатки

• Такие списки могут занимать сотни страниц. Фактически невозможно прочитать такие документы в целом и получить чёткое понимание системы.
• Такие списки требований перечисляют отдельные требования абстрактно, оторванно друг от друга и от контекста использования
  • Эта абстракция лишает возможности видеть, как требования связываются между собой или работают вместе.
  • Эта абстракция мешает верно, расположить требования по приоритетам; в то время как список, действительно облегчает приоретизацию отдельных пунктов, удаление одного пункта из контекста может сделать весь сценарий использования или деловое требование бесполезным.
  • Эта абстракция увеличивает вероятность неверного трактования требований; поскольку, чем больше число людей будет их читать, тем большее будет число (различных) интерпретаций системы.
  • Эта абстракция означает, что чрезвычайно трудно убедиться, что у вас есть все необходимые требования.
• Эти списки создают ложное чувство взаимопонимания между заинтересованными лицами и разработчиками.
• Эти списки дают заинтересованным лицам ложное чувство защищённости, что разработчики должны достигнуть определённых вещей. Однако, из-за природы этих списков, они неизбежно упускают важные требования, которые будут выявлены позже в процессе.

  Требования к программному обеспечению

  Разработчики могут использовать новые требования для пересмотра сроков и условий в их пользу.

Альтернативы спискам требования

Альтернативами большим, предопределенным спискам требований могут служить пользовательские истории, которые определяют требования обычным языком.

Измеримые цели

Лучшие методы рассматривают составленный список требований просто как подсказки и постоянно спрашивают «почему?», пока не будут выявлены истинные деловые цели. После этого заинтересованные лица и разработчики могут разработать тесты, измеряющие, какой уровень каждой цели был достигнут. Такие цели изменяются медленнее, чем длинный список определённых, но неизмеримых требований. Как только маленький набор критических, измеримых целей установлен, быстрое прототипирование и короткие этапы разработки могут дать заинтересованным лицам реальную ценность ещё до окончания проекта.

Уважаемый пользователь! Реклама помогает поддерживать и развивать наш проект. Просьба отключить блокировку рекламы.

Подробней

Сбор и классификация требований

⇐ Предыдущая1234Следующая ⇒

Что такое требование? За долгие годы уже появилось множество определений требований к программ­ному обеспечению, вполне приемлемым является следующее определение, предложен­ное специалистами в области разработки требований Дорфманом (Dorfman) и Тэйером (Thayer).

• Некое свойство программного обеспечения, необходимое пользователю для ре­шения проблемы при достижении поставленной цели.

• Некое свойство программного обеспечения, которым должна обладать система или ее компонент, чтобы удовлетворить требования контракта, стандарта, спецификации либо иной формальной документации.

Многие наиболее часто встречающиеся серьезные проблемы при разработке программного обеспечения связаны именно с требованиями. Результат опроса орга­низации ESPITI (European Software Process Improvement Training Initiative— Европей­ская инициатива по обучению совершенствованию процесса программирования) показал, что двумя самыми главными проблемами, упоминавшимися почти в половине ответов, оказались следующие:

· спецификации требований

· управление требованиями клиента

К тому же наиболее дорогостоящим является исправление ошибок, допущенных на этапе формирования требований.

 

Проблемы сбора требований

 

Процесс сбора требований весьма сложен по следующим причинам:

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

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

3. Для корректного формирования требований необходимо знать методы их сбора и иметь средства их описания, понятные и пользователям и разработчикам.

Методы сбора требований

Для достижения лучшего понимания потребностей пользователя надо хорошо изучить предметную область.

Для этого используются:

· Интервьюирование и анкетирование

· Мозговой штурм и отбор идей

· Сценарии (прецеденты)

· Прототипирование

· Обыгрывание ролей

Выбор конкретного метода будет зависеть от типа ИС, опыта и уровня под­готовки команды разработчиков, заказчика, масштаба проблемы, используемой технологии и уникальности ИС.

Интервьюирование и анкетирование

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

1)Обычные клиенты банка, пользующихся услугами банкоматов.

2)Представители других банков, имеющих взаимные соглашения с данным банком о со­вместном использовании банкоматов.

3)Руководители филиалов банка, получающих информацию из системы управления бан­коматами.

4)Сотрудники филиалов банка, вовлеченные в повседневную работу системы банкома­тов, обрабатывающие рекламации клиентов и т.д.

5)Администраторы баз данных, ответственные за связь банкоматов с базой данных клиентов.

6)Руководители службы безопасности банка, обеспечивающей защиту системы банкоматов.

7)Отдел маркетинга банка, использующий систему банкоматов как средство маркетинга.

8)Разработчики аппаратных и программных средств, ответственные за сопровождение и модернизацию аппаратных и программных средств.

Сценарии

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

Сценарий начинается с общего описания, затем постепенно детализируется для создания полного описания взаимодействия пользователя с системой. В большинстве случаев сценарий включает следующее.

1. Описание состояния системы в начале сценария.

2. Описание нормального протекания событий.

3. Описание исключительных ситуаций и способов их обработки.

4. Информацию относительно других действий, которые можно осуществлять во время выполнения сценария.

5. Описание состояния системы после завершения сценария.

Пример сценария событий

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

Рис. 3 Сценарий обработки банкоматом PIN- кода.

Прототипирование

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

Требования к программным продуктам

Очень важна быстрая разработка прототипа системы, чтобы пользователи могли начать экспериментировать с ним как можно раньше. Прототип ПО помогает как при сборе, так и при проверке требований.

Для уменьшения затрат на создание прототипа можно исключить некоторые системные функции. Например, ослабить временные характеристики и требования к использованию памяти.

---

⇐ Предыдущая1234Следующая ⇒

---

Дата добавления: 2016-12-17; просмотров: 105 | Нарушение авторских прав

---

Похожая информация:

Поиск на сайте:

Что делать, если заказчик не знает, чего он хочет?

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

Корень проблемы

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

Когда ситуацию можно спасти?

Если клиент «плавает», не может четко поставить задачу и сформулировать требования к проекту, то с ним можно сотрудничать при выполнении следующих условий:

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

3. Клиент понимает, что ответственность за принимаемые им решения лежит на нем. Есть клиенты, которые говорят: «Я вам полностью доверяю. Делайте, как считаете нужным, а я все оплачу. Разбираться в вашей работе я не имею времени или возможности». Это опасная ситуация, которая может обернуться против вас. Во-первых, в процессе выполнения работы клиент может не принять предлагаемые вами решения, т.е. нарушить договоренности. Во-вторых, проект может сорваться не по вашей вине, но именно вы будете ответственным за все ошибки.

Как работать с клиентами, которые не знают, чего хотят?

Есть отлаженный алгоритм, который позволяет успешно выполнять подобные проекты:

1. Проведите ликбез для клиента на этапе переговоров.

В процессе переговоров необходимо рассказать клиенту:

• Цели и задачи, которые решает ваша работа. Например, если вы делаете сайты, расскажите, какие бывают сайты, какие задачи они могут решать, какие требования предъявляются к каждому типу сайтов. Важно дать клиенту самую важную информацию, сжато, иначе клиент устанет.

• Как строится рабочий процесс и почему выбрана именно такая последовательность действий. Например, нужно объяснить, почему техническое задание нельзя менять после утверждения.
• Как оценивать и принимать работу. Например, дизайнеры часто переживают, когда клиент оценивает дизайн с позиции «красиво или нет», а не с позиции поставленных задач. Если объяснить клиенту, как работает дизайн и какие задачи он решает, взаимодействовать с заказчиком будет проще.
• Объясняйте все простыми словами, которые может понять не специалист. Если без терминов совсем нельзя, дайте их определение.

• Убедитесь, что клиент все понял, а не сделал вид, что ему все ясно!

2. Помогите клиенту определить цели и задачи проекта.

После проведения ликбеза необходимо уточнить цели и задачи проекта совместно с клиентом. Сформулировать их будет проще, если заказчик уже немного «в теме».

Что такое бизнес требования? На сколько они важны?

Ни в коем случае не навязывайте клиенту свои цели или те цели, которые вы считаете нужными. Ваша задача – чтобы сам клиент определился, что ему требуется сделать.

Сделать это помогают уточняющие вопросы, например:

• Почему вы решили заказать данную услугу?
• Какие изменения вы ожидаете после реализации проекта? Или проще: что должно измениться в вашем бизнесе после реализации данного проекта?

• Опишите, как вы планируете пользоваться сайтом, баннером, приложением и т.д., когда оно будет сделано?

Ваша задача – не придумать за клиента цели и задачи, а помочь заказчику разобраться в себе и сформулировать свои цели.

3. Совместно составьте техническое задание.

Для клиентов, которые не знают, чего хотят, полезно иметь подробный опросник, в котором заказчик сможет увидеть все возможные «опции» продукта и отметить то, что ему нужно. Например, при создании сайта можно дать клиенту список наиболее популярных функций, которые могут быть реализованы на проекте. Заказчику будет проще отметить то, что нужно. Это снизит риски, что клиент что-то забудет сказать.

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

Добейтесь того, чтобы клиент внимательно прочитал ТЗ и уточнил все вопросы, которые у него возникнут.

После согласования ТЗ можно приступать к работе.

4. Делайте проект мелкими этапами, переходя к следующему этапу только после согласования предыдущего.

Разбейте проект на мелкие этапы и договоритесь с клиентом, что:

1. Работа над следующим этапом ведется только после согласования предыдущего этапа.
2. То, что согласовано, меняться не может.

3. В случае нарушения со стороны клиента п. 1 или 2 дальнейшая оплата проекта ведется на почасовой основе, т.е. заказчик будет оплачивать фактически затраченное на работу время по заранее согласованной ставке.

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

Полезные статьи по теме:

Автор: Сергей Антропов(KadrofID: 5)
Добавлено: 20.12.2017 в 18:24