Перед тем как команда реализует функционал, владелец продукта расставляет приоритеты для историй посетителей. В классическом понимании чем больше функционала, тем больше удовлетворен конечный пользователь. Но существует другая, более точная модель – модель удовлетворения потребностей Кано, названная в честь японского профессора, который предложил ее в 1984 году.
Функции продукта можно разделить на 3 раздела в соответствии с удовлетворенностью юзера и функциональностью продукта.
Обязательные функции (must-be) – без них продукт не может существовать и не нужен потребителю. Например, телевизор должен принимать и воспроизводить изображение и звук.
Линейные функции (one-dimensional) – чем они лучше, тем больше доволен пользователь. К примеру, это качество видео- и аудиотрансляции телевизора.
Привлекательные функции (attractive). Они не обязательны, но дают продукту wow-эффект. Например, трансляция через интернет для Smart TV.
Для того чтобы определить, какой функционал должен присутствовать в продукте, не следует надеяться только на свою интуицию. Лучше провести опрос в небольшой группе (20-30 человек) потенциальных пользователей.
-
Как вы отнесетесь к наличию этой функции в продукте?
-
Как вы отнесетесь к ее отсутствию?
Варианты ответов: нравится, ожидаю, все равно, могу смириться, не нравится.
В результате функции можно будет разбить на 6 категорий:
|
Обязательные функции |
must-be |
M |
|
Линейные функции |
one-dimensional |
O |
|
Привлекательные функции |
attractive |
A |
|
Ненужные (обратные) |
reverse |
R |
|
Противоречивые/сомнительные |
questionable result |
Q |
|
Безразличные |
indifferent |
I |
Ответы заносятся в таблицу и анализируются.
Первые три категории наиболее интересны для разработчиков, они показывают главные требования к продукту. В первую очередь нужно реализовать обязательные требования, но до определенного предела, так как дальнейшая работа над ними не повысит удовлетворенность клиента. Вместо этого необходимо сконцентрироваться на линейных и привлекательных функциях, которые значительно повысят удовлетворенность пользователей.
Умные цели для спринта
Для каждого конкретного спринта ставятся отдельные цели – это помогает команде сфокусироваться на них и исходя из этого принимать решение. Цели формулирует владелец продукта при непосредственном участии команды.
Поставленные цели должны соответствовать аббревиатуре SMART (умный), которая складывается из следующих пунктов (один из вариантов интерпретации):
|
S |
Specific |
Точные и конкретные |
|
M |
Measurable |
Измеримые |
|
A |
Achievable |
Достижимые |
|
R |
Relevant |
Релевантные |
|
T |
Time bound/framed |
Цели со сроком |
Рассмотрим эти критерии подробнее.
Specific – конкретные цели
По закону Мерфи «Если есть несколько способов понять задачу, то кто-то обязательно поймет ее неправильно». Чтобы ни заказчик, ни исполнитель не поняли задачу превратно, ее нужно расписать максимально точно и подробно, например:
|
Неправильно |
Правильно |
|
Сделать кросс-браузерную верстку на сайте example.com |
Сайт example.com должен одинаково отображаться в браузерах Opera6+, IE6+, Firefox2+ |
|
Сделать валидную верстку на сайте example.com |
Сайт example.com должен полностью пройти проверки валидаторами w3c.org ( http://www.w3.org/QA/Tools) |
Measurable – измеримые цели
Цели нужно измерять конкретными цифрами и единицами. Таким образом видно, на каком этапе находится работа, сколько выполнено и сколько еще осталось. По окончании спринта можно четко оценить на сколько % выполнены поставленные цели.
|
Неправильно |
Правильно |
|
Поднять посещаемость сайта |
Посещаемость сайта должна вырасти до 2000 хостов за сутки |
|
Сделать так, чтобы каждый клиент покупал больше |
Поднять сумму среднего чека на 10% |
Achievable – достижимые цели
По степени достижимости существует несколько категорий задач в зависимости от навыков и знаний человека.
Недостижимые. Эти цели заведомо не могут быть выполнены. Например, невозможно за день начертить 1000 хороших макетов для различных площадок. Такие задачи ставить нельзя.
Труднодостижимые. Эти задачи требуют максимума сил, знаний и умений – например, создать 10 качественных макетов за день. Как правило, их ставят опытным, активным и амбициозным исполнителям, это для них своего рода вызов. Но и увлекаться такими задачами не стоит – команда может перегореть.
Достижимые. Эти задачи соответствуют знаниям и умениям исполнителя, например, нарисовать качественный макет сайта по брифу за день. Это задачи-передышки между труднодостижимыми «забегами».
Легкодостижимые. Эти задачи слишком просты и не соответствуют компетенциям исполнителя. Например, такая задача, как нарисовать кнопку для меню за день будет скучна и неинтересна для опытного сотрудника. Зато ее можно дать новичку, чтобы тот влился в коллектив и работу.
Relevant – релевантные цели
Релевантность (значимость) может оцениваться со стороны компании и исполнителя. Для команды релевантность зависит от мотивации. Например, если проект интересный или связан с новыми технологиями, усилий к нему будет приложено намного больше.
Time-bound – цели со сроком
По закону Паркинсона, «любая работа увеличивается в объеме, чтобы заполнить все отпущенное на нее время». При постановке любой задачи нужно устанавливать срок, иначе ее постоянно будут вытеснять другие, более срочные и важные. Чем меньше срок для задачи, тем она более труднодостижима, и это надо учитывать, чтобы не перегружать команду.
|
Неправильно |
Правильно |
|
Разработать сайт |
Разработать сайт к 23.12.2014 |
|
Создать форму регистрации для демонстрации клиенту до завтра |
Создать форму регистрации для демонстрации клиенту до 20.12.2014 к 13.00 |
Фиксированные сроки – это неотъемлемая часть системы Scrum. Итерации имеют конкретный срок, а демонстрация спринта – дату.
Лишняя функциональность
Некоторые разработчики стремятся нашпиговать свой продукт всеми возможными функциями, но это не всегда хорошо. Продукт становится громоздким, сложным для использования и дорогим для разработки и поддержки. И если от разработки новой «фишки» стоимость проекта в целом не очень меняется, то цена поддержки для длительных проектов (с длинным жизненным циклом) значительно вырастет, в отличие от стартапов.
Поэтому чем длиннее проект, тем важнее стоимость поддержки. И именно ее, а не стоимость разработки нужно оценивать в первую очередь. Также чем длительнее проект, тем выгоднее убрать ненужные «фишки», чтобы не возникла ситуация, когда придется переписывать проект с нуля.