Классический подход обязывает руководителя проекта, в ускоренном режиме, проводить приоритезацию задач используя для этого категоризацию требований на основе классификации Эйзенхауэра. Результатом всей этой «приоритезации» может стать упущенная выгода, потеря конкурентного преимущества и 100% удовлетворенность процессом руководителя проекта. Другое дело, когда команда реализует требования, которые клиент с восторгом готов принять!
Личностей типа «сноллигостер» хочется предупредить, что они могут этот топик не читать, дабы не травмировать свою психику.
Всем остальным: Добро пожаловать в новый мир!
Для меня абсолютно не ясно, то для чего нужно заниматься «приоритезацией», если клиенту нужна реализация требований, а не то в каком порядке вы их реализуете. Поэтому «приоритезация» в классическом виде, а тем более в ускоренном режиме делает руководителя проекта самым «слабым звеном» в проекте, уменьшая при этом ваше «автобусное число» до единицы.
В результате, в качестве важных и срочных могут появиться такие задачи по реализации требований, которые не интересны клиенту или бессмысленны для него:
1) Мне понравится, если эти требования не будут реализованы, а если команда их все же реализует, то для меня это будет ожидаемый результат.
2) Мне понравится, если эти требования не будут реализованы, и я равнодушно отношусь к тому, что команда все же их реализует.
3) Мне понравится, если эти требования не будут реализованы, и я смирюсь с тем, что команда все же их реализует.
4) Мне понравится, если эти требования не будут реализованы, и мне не понравится, если команда все же их реализует.
5) Для меня будет ожидаемо, если эти требования не будут реализованы, и мне не понравится, если команда все же их реализует.
6) Я равнодушен к тому, что эти требования не будут реализованы, и мне не понравится, если команда все же их реализует.
7) Я смирюсь с тем, что эти требования не будут реализованы, и мне не понравится, если команда все же их реализует.
Другое дело, если клиент будет в восторге, когда команда реализует требования в новом продукте:
1) Для меня будет ожидаемо, если эти требования не будут реализованы, но я буду в восторге, если команда все же их реализует!
2) Я равнодушен, к тому, что эти требования не будут реализованы, но я буду в восторге, если команда все же их реализует!
3) Я смирюсь, с тем, что эти требования не будут реализованы, но я буду в восторге, если команда все же их реализует!
Общие сведения
Главным идеологом анализа основанного на удовлетворенности клиента является Noriaki KANO заслуженный профессор в «Tokyo University of Science». KANO-анализ помогает Agile-команде понять, какие из параметров продукта или его качеств окажутся значительным отличительным преимуществом на IT-рынке, а также позволяет помочь в управлении удовлетворенности клиентов.
Описание технологии
Наибольший эффект от использования KANO-анализа достигается при обеспечении информационной поддержки гибкой разработки коммерческого продукта (изделия).
Данная техника позволяет выявить ключевые особенности, которые будут иметь наибольшее влияние на удовлетворенность клиентов, либо те, которые будут являться исключительно важными, и их отсутствие может привести к полной неудовлетворенности клиента. Все это позволяет команде определить наиболее значимые функции прежде, чем продукт будет выпущен на рынок.
KANO-анализом должны заниматься аналитики, которые с его помощью могут оценить параметры продукции по двум осям:
1) Степень реализации функциональности продукта;
2) Уровень удовлетворенности клиентов от степени реализации той или иной функции в продукте.
Таким образом, получаем 2х2 матрицу в которой профиль продукта должен попасть в одну из трех категорий:
— Типовые требования (основные факторы);
— Требования производительности;
— WOW-требования.
Четвертая нейтральная категория (Indifferent)– это недостаточно совершенная реализация функциональных характеристик, вызывающих у клиентов равнодушие к продукту.
KANO-анализ позволяет определить характеристики, которые придают продукту уникальное положение на рынке.
Типовые требованиями (Threshold):
К типовым требованиям относятся та функциональность, которая абсолютно необходима заинтересованным сторонам для рассмотрения вопроса о принятии продукта. Отсутствие типовых требований вызовет интенсивное недовольство, но т.к. они представляют собой минимальные критерии приемлемости, то их присутствие не позволит увеличить уровень удовлетворенности клиентов за пределы определенного низкого уровня.
Обычно присутствует проблема выявления подобных требований, так как клиент старается не думать о них, и аналитику приходится явно спрашивать о них у клиента.
Требования производительности (Performance):
К требования производительности относятся те, для которых характерен устойчивый линейный рост удовлетворенности клиентов. В основной массе представлены функциями, которые клиенты ожидают увидеть в продукте (скорость, простоту в использовании и т.д.). Эти требования наиболее легко приходят на ум для большинства заинтересованных сторон.
WOW-требования (Exciters):
WOW-требованиями являются те, которые значительно превышают ожидания клиента или представляют то, что для клиента казалось невозможным. Их наличие позволяет значительно повысить уровень удовлетворенности клиентов с течением времени. Поскольку продукты с подобными требованиями не имеют аналогов на рынке, то заинтересованные стороны не склонны думать об описании требований к ним.
Практическая часть.
Для того, чтобы определить категорию, к которой принадлежит требование, описывающее ту или иную характеристику или функцию продукта необходимо уточнить видение клиента в двух формах:
1) В функциональной форме — попросить описать его отношение к тому, что предлагаемое требование будет присутствовать в конечном продукте.
2) В дисфункциональной форме — попросить описать его отношение к тому, что предлагаемое требование будет отсутствовать в конечном продукте.
Свое видение по функциональной и дисфункциональной форме клиент выражает в виде следующих утверждений:
— Мне нравится этот путь;
— Я ожидаю, что это будет именно так;
— Я нейтрально отношусь к подобному требованию;
— Я смирюсь с этим путем;
— Мне не нравится выбранный путь.
Определение категорий основывается на представлении утверждений на обе формы в следующей сетке. В верхней строке представляют ответы на дисфункциональную форму, а в левом столбце представляют ответы на функциональную форму:
Таким образом выявляются требования, которые требуют уточнения (Q — Сомнительный ответ; R – ответ не имеет смысла), а также типовые требования (T), требования производительности (P), а также WOW-требования (E) и нейтральные (I).
Этот подход нацелен на определение требований, которые стимулируют широкое использование или принятие продукта. Категория у требования со временем может поменяться, так как клиенты рассчитывают на рост ожидаемых реализаций новых функций в представляемом продукте, а не уменьшение его функциональности со времени.
Также, WOW-требования в конечном итоге могут стать типовыми требованиями, реализацию которых клиент ждет в обязательном порядке. В качестве примера эволюционирование типовых требований можно привести наличие системы управления солнечными батареями на космическом аппарате:
P.S.: При написании статьи использовались следующие информационные материалы:
1 Agile Extension to the BABOK Guide
2 Вот эти вот картинки для создания коллажа:
2.1 upload.wikimedia.org/wikipedia/ru/f/f0/Kano_mortal_kombat_2013.jpg
2.2 trueimages.ru/img/b4/80/0e7f0f1b48286b6038d84741b05.jpg
2.3 www.federalspace.ru/img/news/resurs_dk.jpg
2.4 upload.wikimedia.org/wikipedia/commons/b/be/Sputnik_asm.jpg
Автор: iPR
