Home

Автор: Адам Найт (Adam Knight)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Ложная гипотеза

Формат этой конференции был таков: участники предлагали свои темы для открытого или слабо структурированного обсуждения. Самой посещаемой стала тема "Тестирование гипотез". Предварительные разговоры выявили, что эта тема вызывает паранойю среди тех, кто занимается продуктом: все считали, что этим обязательно нужно заниматься. Большая часть тех, с кем я общался, были убеждены, что другие посетители этой сессии куда больше знают о вопросе, и хотели узнать, какими подходами пользуются коллеги.

На самом деле в ходе сессии выяснилось, что об этой технике больше разговоров, чем реального внедрения.

• Мало кто действительно тестирует гипотезы. Как минимум в формальном смысле в ходе рутинной работы. В ответ на вопрос "Кто из вас занимался структурированным тестированием гипотез?" уверенно взметнулось всего три руки – а в помещении было 20-30 человек.
• Техника не прижилась. Лектор сообщил, что внедрил структурированный подход в своей команде, но его экс-коллега сказал, что после ухода лектора команда прекратила пользоваться этой техникой.
• Мало кто четко понимает, как это делается. В ходе дискуссии стало ясно, что мало кто уверенно знает, как проработать структуру для тестирования продуктовых гипотез. Большинство присутствующих хорошо понимали, что такое гипотеза, но были слабо уверены в том, как конкретно прорабатывается формальный подход – и мало кто вообще это пробовал.

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

Нужна ли вам структура?

Куда проще писать о том, как хороша какая-то техника, нежели действительно ее демонстрировать – неудивительно, что такие ситуации происходят. Но что же делать тому большинству, у которого нет времени или автономности, чтобы возглавить внедрение новых методов?

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

Обсуждение в конференц-зале было основано на допущении, что внедрение подхода, основанного на гипотезах, требует четкой структуры и процесса, чтобы документировать и обрабатывать гипотезы и результаты тестирования. Люди обсуждали гипотезы, как нечто отдельное от историй, спайков и других элементов бэклога. Много говорилось о том, где нужно хранить документацию по гипотезам – упоминались таблицы и Confluence. Это может быть крайне важным для опытного UX-исследователя, тестирующего влияние изолированных изменений на пользовательский опыт, но для продуктовых ролей вряд ли практично фокусироваться на еще одном списке задач. Им вполне хватает приоритезации прогресса по дорожной карте фич, работы по поддержке, исправления багов и улучшений операций и инфраструктуры – жонглирование списком гипотез для них совершенно лишнее.

Просто делайте это

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

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

Это работает!

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

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

Читать статью полностью