Проверка результата и развитие

Проверяемый результат описывает состояние после работы, а не объём выполненных задач.

Лучше:

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

чем:

Разработать новую CMS.

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

Измеряйте показатели, связанные с задачей:

• находит ли человек нужную информацию;
• проходит ли сценарий;
• может ли редакция работать самостоятельно;
• уменьшается ли ручная работа;
• остаются ли данные актуальными.

Pageviews полезны только в контексте.

Использование:

материал открыли 10 000 раз.

Результат:

70% пользователей нашли действующие условия без дополнительного обращения.

Общественный эффект – ещё более высокий уровень и требует отдельной методики.

Не спрашивайте только «вам понравилось?».

Лучше:

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

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

Пересмотр нужен, если:

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

Не сохраняйте функцию только потому, что на неё уже потрачены ресурсы.

Если проблема локальна и исходная модель остаётся правильной, сначала попробуйте минимальное изменение:

• название;
• порядок блоков;
• дополнительный фильтр;
• новое поле;
• улучшение инструкции.

Не запускайте полный редизайн для каждой локальной проблемы.

Серьёзная переработка оправданна, если:

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

Удаление оправдано, если функция:

• не решает подтверждённую задачу;
• почти не используется;
• создаёт непропорциональную сложность;
• вводит в заблуждение;
• имеет более простой заменяющий путь.

Меньше функций может означать более сильный продукт.

Для каждой новой идеи требуйте:

• пользовательскую задачу;
• владельца;
• критерий результата;
• стоимость поддержки;
• приоритет относительно уже запланированного.

Если функция не проходит эту проверку, отправьте её в backlog, а не в текущий релиз.