Как сохранить знания команды на пути от гипотезы к разработке: полезные практики
Рассказываем, почему карточка задачи теряет смысл к моменту разработки и как выстроить процесс иначе
Когда разработчик берет задачу в работу, он опирается на то, что написано в карточке или в техническом задании. Но если по дороге от исследования до постановки задачи часть знаний потерялась — на каждой развилке в процессе специалисту придется додумывать за пользователя вместо того, чтобы опираться на данные. Иногда это ни на что не влияет, а иногда команда тратит несколько недель на функцию, которая не попадает в реальную потребность.
Разберем, почему так происходит и какие практики помогают довести контекст от исследования до кода без потерь.
Почему задача теряет смысл еще до того, как попадает к разработчику
Когда аналитик переносит итоги исследования в задачу, он может их упрощать. Когда менеджер на основе информации от аналитика дописывает описание задачи — он может упрощать еще сильнее. В итоге, когда разработчик читает готовую карточку, он видит только то, что осталось после 2 «пересказов» задачи: что нужно сделать, но не почему именно так и какие варианты вообще рассматривались.
Получается эффект снежного кома, но наоборот — от общего объема информации до разработчика доходит лишь небольшая его часть. Кажется, что эта часть самая основная, но на самом деле между изначальным контекстом и финальным техническим заданием теряются детали, которые потом приходится восстанавливать уже в процессе разработки.
Разработчик получает не просто урезанную версию реальности, а своего рода «выжимку выводов», где уже не видно ни логики принятых решений, ни отброшенных альтернатив. В итоге он лишен возможности понять истинные мотивы задачи, а значит — предлагать более эффективные технические решения или замечать потенциальные противоречия на раннем этапе.
Где разрывы случаются чаще всего
Это происходит при переводе задачи из одного этапа в другой. Вот обычные сценарии:
От исследования к постановке задачи. Результаты исследования живут в заметках, презентациях или только в голове у аналитика. В задачу попадает вывод — например, «сделать шаблоны отчетов» — без данных, которые объясняют этот вывод. Разработчик не знает, что именно болит у пользователя, и не может принять хорошее решение, если в ходе работы столкнется с развилкой.
От постановки к реализации. Это особенно касается задач, к которым приступают не сразу. Например, задача попала в бэклог и пролежала там несколько недель. За это время состав команды мог поменяться, приоритеты сдвинуться, а те, кто держал контекст в голове, переключиться на другое. Новый разработчик на проекте видит карточку — и восстанавливает контекст по тому, что в ней осталось, или интерпретирует задачу по-своему.
От выпуска к следующей итерации. Допустим, новую функциональность все же без проблем выпустили. Команда идет дальше — к следующей задаче или следующему кварталу. Но почему изначально выбрали именно такое решение, что рассматривали и от чего отказались — нигде не записано.
Если через несколько месяцев команда возвращается к этой части продукта, она начинает обсуждение с нуля — и рискует потратить время на идеи, которые уже проверяли и отвергли.
Кажется, что решение простое: записывать больше контекста. Но стандартные способы хранения информации тоже не всегда решают эту проблему.
Почему стандартные подходы не решают задачу
Команды могут решать проблему с контекстом так: вести переписку в чате, хранить документы в вики-системе, записывать решения на планерках. На первый взгляд — достаточно. Но у каждого из этих инструментов одна и та же проблема: контекст хранится отдельно от работы.
Чтобы понять, почему задача сформулирована именно так, разработчику нужно:
- идти в другой инструмент и искать нужный документ;
- уточнять информацию у коллег;
- восстанавливать ход мыслей по разрозненным фрагментам переписки.
При этом переписка живет, только пока кто-то помнит о ее существовании, вики тем временем может пополняться черновиками, которые перестают обновлять, а в записях со встреч фиксируют только итоги, но не логику их принятия.
Теперь посмотрим, как можно перестать терять смыслы на пути от исследования до разработки.
3 практики, которые помогают удержать контекст
Разберем каждую практику отдельно.
Дерево возможностей и решений
Этот инструмент разработала продуктовый консультант Тереза Торрес. Он помогает команде визуализировать путь от метрики, которую хочется улучшить, до конкретных решений и экспериментов.
Дерево состоит из 4 уровней:
- Желаемый результат — метрика, которую команда хочет улучшить. Например: увеличить долю пользователей, которые возвращаются в продукт на второй неделе. В рамках концепции желаемый результат представляет собой корень дерева, от которого идут ответвления.
- Возможности — потребности и боли пользователей, которые мешают этой метрике расти. Возможности можно декомпозировать: крупная боль разбивается на более конкретные, пока не доходит до той, с которой удобно работать. Например: «пользователи тратят много времени на рутинные задачи» → «каждый раз приходится заново настраивать отчет» и «нет возможности поделиться готовым отчетом с коллегой напрямую из системы».
- Решения — идеи под конкретную возможность. Например: быстрая выгрузка, сохраненные шаблоны, автоматическая рассылка по расписанию.
- Проверочные эксперименты — тесты, которыми команда проверяет каждое решение. Например: если опрос пользователей показал, что 70% из них хотят именно шаблоны, то остальные варианты отпадают.
Смысл инструмента в том, что он остается рабочим документом на протяжении всего процесса. Команда обновляет его по мере того, как узнает новое: добавляет гипотезы, фиксирует результаты экспериментов, отмечает, что проверили и что отвергли.
Как сделать дерево. Удобнее всего вести дерево в той же системе, где живут задачи — тогда из карточки можно сразу перейти к контексту, не переключаясь между инструментами. Например, в Кайтене для этого есть раздел Документы с поддержкой совместного редактирования и истории версий.
Для дерева подойдет простой формат файла:
- Создайте документ и зафиксируйте в начале желаемый результат.
- Добавьте возможности — при необходимости декомпозируйте крупные на более конкретные.
- Под каждой возможностью перечислите решения и эксперименты.
- Когда задача появляется на доске, вставьте ссылку на карточку рядом с решением в документе.
Ниже — пример заполненного дерева, который можно бесплатно импортировать в свой аккаунт.
Если дерево кажется избыточным на старте, можно начать с дневника гипотез. Это простая таблица, где каждая строка — это 1 проверяемая идея. По каждой гипотезе фиксируют план: что делают для проверки, что измеряют и по какому критерию поймут, что гипотеза подтвердилась. После эксперимента заполняют факт: что сделали, какой результат получили и какой вывод из этого следует.
При использовании подобных файлов вся история гипотез, экспериментов и отмененных решений хранится рядом с задачей, а не в отдельных заметках, о которых все забывают.
Записи об архитектурных решениях
В 2011 году разработчик Майкл Нигард описал практику, которую сегодня рекомендуют AWS (Amazon Web Services) и Google в своих инженерных руководствах. Она называется «запись об архитектурном решении». Формат простой: для каждого значимого решения команда записывает 4 вещи:
- контекст, в котором принимали решение;
- само решение;
- варианты, которые рассматривали и отвергли;
- ожидаемые последствия.
Это небольшой документ, который занимает 1-2 страницы и отвечает на вопрос, который рано или поздно возникает у каждого: «почему здесь сделано именно так?»
Пример. Команда выбирает, как хранить пользовательские шаблоны отчетов, и фиксирует решение в записи:
- Контекст: нужно хранить настройки отчетов для каждого пользователя. Рассматривали 2 варианта: отдельная таблица или JSON-поле в таблице пользователей.
- Решение: хранить в отдельной таблице.
- Отвергнутый вариант: JSON-поле — проще в реализации, но усложнит поиск и фильтрацию по шаблонам в будущем.
- Последствия: структура сложнее, зато запросы к шаблонам останутся быстрыми при росте данных.
Через 8 месяцев новый разработчик берет задачу по доработке хранилища шаблонов. В карточке — ссылка на запись об архитектурном решении. Он открывает ее, видит, что вариант с JSON уже рассматривали и от него отказались — и не тратит время на повторное обсуждение такого варианта.
В Кайтене записи об архитектурных решениях удобно хранить в разделе «Документы» — по 1 файлу на каждое значимое решение. Когда запись готова, ссылку на нее добавляют в карточку задачи, которой это решение касается. Любой участник команды, открыв карточку, сразу видит не только что нужно сделать, но и почему именно так.
Вот пример заполненной записи:
В Кайтене ссылку на запись можно добавить в раздел «Ссылки» внутри задачи — она отображается и в самой карточке, и на ее фасаде. То есть разработчик может перейти по ссылке, не открывая задачу, чтобы сразу ознакомиться с контекстом.
Привлечение разработчиков к этапу исследований
Марти Каган — эксперт по управлению продуктом, который консультировал Netscape, eBay и другие крупные технологические компании — описал частый антипаттерн в командах. Его суть в разрозненности 2 команд: первая группа исследует проблему, другая реализует решение. Когда задача переходит между командами, ее описание всегда теряет часть деталей и контекст.
В принципе, это та же проблема, о которой мы уже говорили, но Каган предлагает конкретное решение — не делить команду на 2 части. Менеджер по продукту, дизайнер и разработчик работают вместе и разделяют ответственность за оба этапа: и за поиск правильного решения, и за его реализацию. При этом разработчику не нужно тратить на исследование столько же времени, сколько менеджеру — достаточно оставаться в курсе того, что происходит.
Тереза Торрес развила эту идею дальше и предложила более конкретный формат: менеджер, дизайнер и разработчик вместе ходят на интервью с пользователями. Вот чем можно объяснить пользу такого подхода:
Как выстроить совместную работу. Чтобы кросс-функциональной команде было проще работать, весь процесс от исследования до выпуска функциональности можно организовать в едином пространстве. В Кайтене для этого есть возможность добавлять несколько канбан-досок на 1 пространство. За счет этого менеджер по продукту, дизайнер и разработчик будут видеть одни и те же доски и карточки, не переключаясь между инструментами.
При таком подходе принцип работы будет следующий:
- Карточка с новой идеей сначала проходит через исследовательскую доску — обрастает данными из интервью, результатами валидации, выводами из тестового запуска.
- Когда задача готова к разработке, разработчик вместо «голого» технического задания получает карточку с историей: что проверяли, что узнали, почему решили делать именно так.
Что важно: разработчик, добавленный на это пространство, может участвовать в обсуждении задач еще на этапе исследования — видеть, какие гипотезы проверяют, и подключаться к тем, где нужна техническая оценка. Это и есть то, о чем говорят эксперты: разработчик не ждет готового решения, а участвует в его формировании.
В Кайтене для такого процесса есть готовый шаблон с 3 досками на одном пространстве — бэклог для всех задач, Upstream (исследование и валидация идей) и Downstream (разработка и запуск).
Бонусная практика: канбан-доска как отражение накопленных знаний
Мы только что говорили о том, как важно привлекать разработчиков к исследованиям. Но даже если команда работает слаженно, накопленные знания нужно где-то фиксировать. И здесь можно по-новому взглянуть на инструмент, который знаком большинству команд — канбан-доску.
Чаще всего доску воспринимают как способ контроля: кто что делает и на каком этапе. Но можно смотреть на нее иначе — как на карту знаний команды о каждой задаче. Чем дальше карточка продвигается по колонкам, тем больше команда знает о проблеме и ее решении. Например:
- В колонке «Исследование» известна только боль пользователя.
- В «Проектировании» — уже выбран подход.
- В «Разработке» — гипотеза проверена, а решение обосновано.
Каждый переход между колонками — это подтверждение того, что команда узнала достаточно для следующего шага.
Проблема в том, что сами по себе колонки ничего не гарантируют. Карточка может перетечь из «Исследования» в «Разработку», не оставив следов — без зафиксированных выводов и без обоснования выбранного пути. Вот пример такой карточки:
Чтобы этого не происходило, доску нужно подкрепить правилами, которые побуждают команду наполнять карточку знаниями по мере ее движения.
В Кайтене наполнять карточку контекстом помогают встроенные инструменты:
- Комментарии, в которых команда обсуждает задачу. Вся история переписки сохраняется прямо в карточке.
- Прикрепленные файлы: записи созвонов, результаты экспериментов, макеты.
- Ссылки на документы внутри Кайтена или внешние материалы.
- Чек-листы, которые делают прогресс по промежуточным задачам и оценку качества работы более прозрачными.
- Пользовательские поля для фиксации ключевых параметров: статуса гипотезы, источника данных, критериев приемки.
Когда карточка наполнена таким образом, она становится хранилищем всего, что команда узнала на пути от проблемы к решению. А выглядит она уже намного объемнее и подробнее:
Как довести задачу от идеи до выпуска и не потерять контекст: итоги
Основные выводы статьи:
→ Контекст теряется не из-за невнимательности, а из-за того, что каждый пересказ задачи упрощает ее. До разработчика доходит «что сделать», но не «почему именно так».
→ Задача теряет контекст, когда переходит из рук в руки: аналитик передает менеджеру, менеджер — разработчику, и на каждом шаге часть деталей отсеивается как «неважная».
→ Чаты, вики и записи со встреч в разных системах создают иллюзию порядка, потому что в таком случае контекст живет отдельно от задачи.
→ Фиксируйте знания рядом с работой: дерево решений хранит логику выбора, записи об архитектурных решениях отвечают на вопрос «почему так», а участие разработчика в исследованиях сокращает потребность запрашивать дополнительную информацию.
→ Канбан-доска — не только инструмент контроля. Вместе с этим она показывает, сколько команда знает о задаче на каждом этапе, что делает каждую карточку хранилищем контекста.
