Процесс в подробностях

Теперь пройдем последовательно по всем этапам жизненного цикла.

Разберитесь в проблеме:

1. Очередь

Мы закончили Раздел 12 простым алгоритмом, позволяющим быстро отбирать элементы, достойные попадания в очередь на внедрение. Теперь эти элементы размещаются в верхней части столбца «Очередь», поскольку за их обработку еще не принялись. С учетом лимитов на количество обрабатываемых одновременно задач, вам стоит основательно задуматься над расставлением приоритетов в очереди, так чтобы они отражали первостепенные цели вашего проекта.

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

1. Пользовательские запросы

Если новый элемент запрошен пользователями, организуйте встречу или разговор с клиентом. Хотя клиент и просит о конкретном решении, вам необходимо докопаться до корней проблемы. Попытайтесь выяснить причины, по которым он хочет этот новый элемент. Заставьте клиента убедить вас в том, что этот элемент необходимо внедрить.

В конце разговора вы должны быть способны классифицировать рассматриваемый элемент как «обязательный» или «желательный», определить, насколько он достоин внедрения и какой макро-процесс он затронет.

1. Внутренние запросы

Если запрос на добавление элемента появился внутри команды, рассмотрите все те же критерии, что и для пользовательских запросов и ответьте на вопрос – «Достойна ли эта проблема решения?»

Определите решение:

1. Макет

Как только вы выделили для себя элемент, достойный внедрения, займитесь созданием макета решения, руководствуясь подходом, описанным ранее в Разделе 8. Начните с бумажных набросков, но как можно быстрее переходите к HTML/CSS макетам, подключаемым к вашему основному приложению.

1. Демонстрация

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

1. Программирование

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

Проверьте качественно:

1. Частичное внедрение

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

1. Качественная проверка

Проведите тестирование удобства использования с помощью шаблона интервью по МВП. При необходимости внесите требуемые изменения для устранения недостатков.

Подтвердите количественно:

1. Полное внедрение

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

1. Количественное подтверждение

После полноценного запуска нового элемента вы должны иметь возможность сравнить конверсию по недельным когортам до и после внедрения и проанализировать макро-эффект внедрения.

В зависимости от типа элемента вам может дополнительно потребоваться проведение сплит-теста. На этой стадии решение о необходимости сплит-теста необходимо принимать индивидуально.

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

Приведу несколько полезных советов:

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