Дочитал книгу Джейка Кнаппа «Спринт. Как решать сложные проблемы и тестировать новые идеи всего за 5 дней»

Главный вывод: это не книга о мотивации или философии продуктового управления. Это книга-инструкция. Пошаговое руководство, где расписано, что делать в понедельник, во вторник, в среду, четверг и пятницу. С таймингом, ролями, скриптами и чек-листами.

Кнапп (бывший партнер Google Ventures) описывает процесс, который команды Google прошли десятки раз. И после прочтения действительно кажется, что так можно сделать. Но, конечно, надо пробовать на практике - теория без практики здесь ничего не стоит.

—

Почему это применимо в нашей компании: иногда мы идем в реализацию без проверки гипотез.

В итоге:

· Тратим недели и месяцы на разработку. · Получаем результат, который работает «не совсем так». · Дорабатываем, переделываем, теряем ещё время. · А иногда выясняем, что идея в принципе не решает проблему пользователя.

Кнапп предлагает альтернативу: быстрое, дешёвое тестирование идеи до того, как написан первый строчка кода. За 5 дней команда (продакт, дизайнер, разработчик, фасилитатор) может:

1. Сформулировать проблему. 2. Набросать прототип (макет, кликабельный прототип). 3. Протестировать его на реальных пользователях.

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

—

В чём отличие нашего контекста

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

У нас пользователи - внутренние сотрудники компании. Это и плюс, и минус. Отличия:

Доступность В книге (внешние пользователи): Нужно искать, договариваться, платить У нас (внутренние сотрудники): Все внутри, можно пригласить на спринт за 5 минут

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

Обратная связь В книге: Может быть поверхностной У нас: Часто очень глубокая и экспертная

Риски В книге: Пользователь не знаком с контекстом У нас: Пользователь может «защищать» текущие процессы

Главный вызов для нашей ситуации: внутренние сотрудники могут давать «политкорректные» ответы или критиковать, исходя из личных обид, а не реальных проблем. Кнапп про это не пишет - его аудитория другая. Нам придётся адаптировать: задавать больше вопросов «как это работает сейчас?», «что именно мешает?», «как часто вы сталкиваетесь с этой проблемой?».

—

Что я забрал из книги

1. Спринт - это не магия. Это жёсткий, дисциплинированный процесс. Если пропустить шаг - результат будет хуже. 2. Главная цель - не решение, а обучение. За 5 дней команда узнаёт, стоит ли развивать идею, или лучше закрыть её и не тратить ресурсы. 3. Прототип должен быть «достаточно хорошим». Не нужно делать работающий код. Достаточно макета, который имитирует взаимодействие. 4. Тестировать нужно на 5 пользователях. Кнапп утверждает (и я ему верю), что 5 пользователей выявляют 85% проблем с юзабилити. Дальше - убывающая отдача. 5. Пятница - день правды. В пятницу команда смотрит записи тестов и принимает решение: «идём в разработку», «дорабатываем гипотезу» или «убиваем идею».

Итог

Книгу рекомендую всем, кто принимает решения о развитии продуктов. Особенно тем, кто устал от ситуаций: «Мы потратили три месяца, а пользователи не пользуются».

«Спринт» не даст вам ответов на все вопросы. Но он даст процесс, в котором эти ответы появляются быстро и дёшево.

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

Читали? Какие ваши впечатления?