Delivery Club x GIST10.11.2020 12:17

Привет! Меня зовут Илья Воробьёв, в Delivery Club я отвечаю за направление клиентских продуктов. Вместе с Андреем Евсюковым я расскажу о том, как в растущей команде мы пересобирали процессы планирования и к чему это привело.

Готовя статью, мы поговорили с участниками и свидетелями событий, и будем разбавлять текст выдержками из их рассказов. Наши герои и непосредственные участники событий:

Мария Чебакова, руководитель группы оптимизации процессов. Отвечает за формирование и настройку бизнес- и операционных процессов.
Антон Сокольников, руководитель проектов в направлении логистики. Отвечает за развитие логистических продуктов.
Станислав Ураков, руководитель разработки в направлении логистики. Отвечает за систему, архитектуру и архитектурные решения, а также команды разработки.

С чего всё началось

К лету 2019 года переход к кросс-функциональным продуктовым командам дошёл до финальных стадий во всех продуктовых направлениях Delivery Club. В итоге мы получили понятный и достаточно предсказуемый темп движения на уровне менеджера продукта и разработки (кстати, про это мы уже рассказывали тут), но на контрасте стали более заметны трудности уровнем выше — взаимодействие продуктовых команд и менеджеров продукта со стейкхолдерами.

Мария:
— Год назад с каждой командой нужно было общаться по-разному. Например, у логистического продукта были планирования раз в две недели. С R&D не было планирования. Мы сидели за соседними столами и нормально всё решали. У остальных команд были разные процессы в зависимости от количества заказчиков, которых нужно подружить между собой и поделить ресурсы, и от количества исполнителей у каждой из команд.

Антон:
— Ежедневно мы проводим встречи с коллегами из операций, бизнеса, разработки и с менеджерами других продуктов для обсуждения новых идей и поиска решений для их реализации. Каждый видит это по-своему: менеджеры продуктов хотят сделать удобно, понятно и доступно, разработка думает с точки зрения архитектуры. Приходилось каким-то образом договариваться со всеми. Это было неудобно: ты говоришь с одним человеком и не учитываешь мнение других. Как следствие, многие фичи и проекты решали проблемы одних коллег, но порождали для других.

Стас:
— До внедрения GIST у нас применялся классический подход, когда компания находится в стадии переходного периода, внутри продуктов часто творился хаос. У менеджеров продукта был свой roadmap, но у разработчиков не было к нему доступа. Product-менеджеры где-то что-то фиксировали и с этим работали. Выдержки в виде продуктового описания приносили командам разработки, которые формировали технические требования. Появилась потребность весь этот хаос упорядочить, потому что работать становилось очень сложно.

Проблемы быстро обострялись, и этому способствовали:

нарастающая конкуренция на рынке;
переключение фокуса компании на развитие собственных операций и увеличение доли собственной доставки;
рост количества сотрудников, отвечающих за развитие операций и бизнеса (те самые стейкхолдеры, ага);
параллельный рост количества разработчиков и команд разработки.

Если окинуть взглядом происходящее на тот момент в компании ещё на уровень выше, то сразу возникают опасения: «У нас большая команда, которую мы продолжаем расширять, но уверены ли мы, что эти люди действительно заняты тем, чем нужно? Не теряются ли идеи, слышим ли мы все голоса в команде? Не упускаем ли ценные данные от стейкхолдеров?»

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

Не очень понятно, кому нести задачу. Вроде бы, надо менеджеру продукта, но какому? А в каком виде?
Неясно, что дальше произойдет с задачей. Кто и как её будет делать? Когда будет готова?
Нет прозрачного способа ускорить выполнение задачи (а ведь она, конечно же, самая важная).

Первую проблему было не так сложно решить: определили ответственных менеджеров, и поток задач потёк в нужную сторону. Но тут-то выстрелили две другие проблемы: не имея прозрачного процесса приоритизации, стейкхолдеры ринулись ускорять свои инициативы очень простым и широкодоступным способом — давлением. Вспоминают Антон Сокольников и Мария Чебакова:

Антон:
— На нескольких первых планированиях было мягко говоря непросто. Все приходили, изначально друг с другом не договорившись. В течение большей части встречи творился хаос и борьба за ресурсы команд разработки. От многих звучали фразы: «Я отказываюсь», «я не хочу, чтобы мы вот это брали», «а мне нужно вот это и срочно».
Часто запросы конфликтовали друг с другом: какая-нибудь из задач, призванная улучшить целевую метрику одного заказчика, при этом могла негативно повлиять на целевые метрики второго. Такое до сих пор бывает, но сейчас у нас в процессе GIST рождается истина. Все понимают, какие есть риски, что принесёт каждая задача, что она может ухудшить. Раньше такой прозрачности не было.

Мария:
— За 1,5 года количество команд разработки выросло в два раза, а количество людей — примерно в три. У них уже тогда было какое-то количество заказчиков. Проблема в том, что заказчиков было больше, чем ресурсов. В такой ситуации всегда возникает делёжка. В нашем случае она была не слишком структурирована: всё зависело от силы заинтересованности конкретного человека в решении конкретной задачи.
Были моменты, когда люди друг другу рассказывают и выясняют, чья задача важнее, почему это сейчас нельзя не делать. Участникам более широкого собрания это не нравится, потому что они не понимают, о чём спор, хотят видеть конечный результат.

Но даже если вы бог давления и впихнули задачи в нужную команду, то, с точки зрения компании, вы вполне могли нанести вред. Доказав ценность своей задачи и инвестировав время команды, можно:

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

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

Иногда сессии по разбору задач растягивались на долгие часы и выглядели как-то так.

Поиск пути

Осознав проблему, мы задали себе сакраментальный вопрос: «А чё делать-то?». Не то чтобы у нас не было процессов планирования, просто в складывающихся условиях вполне стандартные подходы работали плохо. Поиск решения начали с формулирования, а как должно быть в идеале.

Запросы удалось уложить в четыре лаконичных пункта:

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

При всей простоте этих запросов пришлось поломать голову и рассмотреть несколько гипотез, прежде чем мы нащупали подходящее решение:

Для заполнения пробелов в коммуникации и планировании стоит ввести новую роль в команде?

Часть задач по коммуникации и сбору требований можно возложить на определённого человека. Зачастую для этих задач в компаниях создаётся институт PMO, и в командах появляются менеджеры, сосредоточенные на выстраивании коммуникации и сведении множества интересов. И хотя этот подход позволяет закрыть пробелы и облегчить жизнь команде и стейкхолдерам, у него есть недостатки:

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

Мы решили обратиться к этому средству, если не сможем найти другого решения.

Существующего процесса будет достаточно, если внедрить систему скоринга?

Баталий на встречах можно избежать (ну, или хотя бы снизить накал страстей), если внедрить общую и понятную для всех систему оценки идей и гипотез. В голову сразу приходят подходы RICE (Reach, Impact, Confidence, Effort) или ICE (Impact, Confidence, Ease), которые позволяют при заполнении показателей получить почти автоматическую приоритизацию.

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

В итоговой реализации GIST мы действительно оцениваем Impact и Effort, но не пытаемся свести оценку задач к какой-то единообразной шкале. Но ICE мы тоже не без успехов используем в некоторых командах как вспомогательный инструмент.

Может выделить в команде слоты под задачи каждого из стейкхолдеров (или группы стейкхолдеров)?

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

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

Подойдём системно и перестроим процесс!

У трёх рассмотренных подходов есть общая черта: все они модифицировали существующий процесс и, по сути, являлись костылями. Нам же хотелось найти системное решение, которое уже в рамках дизайна процесса изначально закрывало наши потребности.

Изучая практики с рынка, нас заинтересовали подходы Итамара Гилада (Itamar Gilad, кстати, очень крутой дядя с большим количеством интересных трудов). Работая в Google, он собрал и внедрил этапную систему работы над задачами, которую назвал по первым буквам этапов жизненного цикла работы — GIST: Goals, Ideas, Step-Projects, Tasks.

Базовые принципы подхода:

Goals — цели, которые обозначаются командой на достаточно продолжительный промежуток времени. Они должны быть измеримы и понятны. При генерировании идей команда, менеджеры и стейкхолдеры сосредоточиваются на достижении общих целей.
Ideas — любой член команды может закинуть идею. Команда регулярно приоритизирует и разбирает идеи, выделяет минимум, который позволит проверить ценность предложения минимальной ценой.
Step-Projects — большие комплексные идеи разбиваются на этапы, которые можно сделать относительно быстро и проверить жизнеспособность и ценность на реальных данных. Чем быстрее такой проект можно завершить, тем лучше.
Tasks — декомпозиция проекта на конкретные задачи, которые команда будет брать в разработку.
Каждый из этапов команда разбирает на регулярных сессиях и сосредоточивает ресурсы на идеях, которые приносят наибольший результат.

Чтобы не превращать статью в пересказ подходов Итамара, рекомендуем ознакомиться с парой его статей, на основе которых мы начали прорабатывать наш процесс:

Принципы GIST звучат довольно просто (почти как Agile-манифест), но концептуально хорошо отражают то, как мы видели правильную работу команды и стейкхолдеров. Оставалось понять, как обернуть фреймворк в рамки конкретного процесса. Ну, и самое главное: как его запустить и убедиться, что всё действительно работает задуманным образом.

Have Space Suit — Will Travel

Понимая, что просто копировать описанные Итамаром идеи будет опрометчиво, мы начали разбирать и адаптировать фреймворк под наши запросы и особенности.

При этом какие-то части процесса не были описаны Итамаром совсем, а некоторые — вполне конкретно обозначены, и более того, многие компоненты уже были у нас внедрены:

Этапы Step-Projects и Tasks перенести на наши реалии было нетрудно: команды уже работали в рамках двухнедельных итераций, умели декомпозировать и запускать задачи в хорошем темпе (напоминаю, что детали можно посмотреть в этой статье).
C Goals тоже не было проблем. На уровне всего Delivery Club есть понятная стратегия развития, которая довольно просто трансформируется в цели и задачи на уровне команд и направлений. Например, у логистики, с которой мы и хотели начать пересобирать процессы, есть хорошо измеримые цели по загруженности курьеров, среднему времени и стоимости доставки заказа.
Самая мякотка для нас заключалась в этапе Ideas: как правильно научиться собирать идеи и выстроить работу по их приоритизации.

Чтобы разобраться с идеями, мы провели мысленный эксперимент в поисках ответа на вопрос: «А как должна выглядеть каждая идея, чтобы в момент приоритизации мы могли без проблем понять, что важнее?».

Идея и как её создать

Рассмотрев успешные кейсы в Delivery Club, мы выделили несколько общих факторов:

Почти у каждой выстрелившей идеи или гипотезы было проработанное бизнес-обоснование. Например, в начале 2019 года часть команд клиентского направления приступила к проработке решения по запуску доставки продуктов из магазинов. Но до перехода к проектированию мы очень подробно изучили динамику изменения рынка онлайн-ритейла за последние годы и перспективы роста на будущее. Это позволило сразу сфокусироваться на модели маркетплейса для магазинов — решения, которое в полной мере расцвело в безумный 2020 год.
Время на проектирование и реализацию в продукте всегда было ограничено либо внешними факторами, либо самой командой. Стараясь уложиться в срок, ребята находили оригинальные решения и отрезали всё, что не было важно для проверки гипотезы на запуске. Подчеркнём, что короткие итерации в разработке — это не что-то новое или революционное. Хитрость в том, чтобы у команд было изначальное ограничение на количество итераций для финального решения. Кстати, в книге «Shape Up» Райана Сингера есть подробный разбор этой механики и её использования для развития продукта в Basecamp.
Инициатор гипотезы работал в тесной связке с менеджером продукта и командой на протяжении всего процесса: от проектирования и разработки до запуска и оценки результатов. В ряде случаев такое вовлечение позволяло отказываться от реализации на ранних этапах. А где-то — раскопать несколько новых идей и гипотез на следующие этапы.

В этот момент проявились контуры того, как мы хотели построить работу:

Любой член команды может завести идею и положить её в общее пространство.
У идеи должен быть набор обязательных параметров к заполнению:
- Суть.
- Почему возникла идея и какую ценность она несёт. Чем больше здесь доказательств, тем лучше. Именно из этого и складывается Impact, который кратко описывается.
- Как выглядит верхнеуровневая реализация по мнению инициатора.
- Какой результат ожидаем и почему.
Менеджер продукта будет периодически просматривать новые идеи с командой и давать комментарии по описанию, а также дополнять идею данными со своей стороны и фиксировать ограничение по времени на поиск и реализацию решения (это отражает для нас Effort).
При первичном разборе часть идей будет «склеиваться» с уже существующими, часть будет отсеиваться, а часть — наполняться деталями. На обсуждение выносим те идеи, которые инициатор готов защищать не только силой своей харизмы, но и набором фактов с пониманием ограничений на реализацию.
Раз в две недели проводим общую встречу по приоритизации, на которой происходит три важных события:
- инициаторы публично защищают свои идеи;
- команда разбирает результаты завершенных проектов;
- пересматриваем приоритеты по задачам, которые находятся в бэклоге, и команда сообщает, что уйдёт в разработку далее.

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

Настроить инструмент для сбора идей. В нашем случае это задача в Jira в определённый проект.
Упростить человеку, который добрался до заведения идеи, её правильное заполнение. Для этого настроили необходимые поля и добавили предзаполненные подсказки в описании.
На заведённую идею нужно получить обратную связь. Назначили менеджерам продукта время для разбора новых идей. Чтобы ничего не терять, установили правило — вести переписку только в комментариях в Jira-задаче.
Подготовить идею к защите помогает менеджер продукта: рассказывает, как дособрать часть данных, и совместно с командой закладывает предварительный слот на проектирование и реализацию решения.
Защитить идею на одной из приоритизаций предстоит самому инициатору. Менеджер продукта с командой фокусируются на защите предварительных деталей реализации и отстаивают слот на реализацию.
И самое важное: о новом подходе нужно рассказывать. Поэтому после первых пробных шагов мы стали рассказывать о подходе внутри компании. Теперь и вы об этом читаете.

Как проходит защита

Стало понятнее, но последним пробелом остаётся сама защита. Да и как проходит встреча по приоритизации, тоже неясно. А устроено это так:

В полном составе команды, стейкхолдеры и менеджеры встречаются раз в две недели.
Должны быть разобраны три блока: защита идей, разбор результатов по завершённым проектам, реприоритизация бэклога.
Для простоты и прозрачности все идеи и проекты — это задачи в Jira, которые разложены на Kanban-доске (доска идей). Кроме очевидных Done и Closed доступны ещё шесть статусов:
- Inbox — список новых идей. Задачи из этого статуса регулярно просматривают менеджеры продукта, помогая сформировать правильное описание и дойти до защиты.
- Pitch — идеи на защиту, которые будут обсуждаться на ближайшей приоритизации. Успешная защита означает перемещение в бэклог.
- Backlog, Next, Now — отражают состояние защищённой идеи в бэклоге. Соответственно, ожидаем реализации в рамках квартала, следующего спринта, или уже следим за реализацией.
- Analysis — запущенные проекты, по которым команда и стейкхолдеры должны собрать результаты и оценить, насколько идея была успешна (или неуспешна) и почему.
У самих задач на доске для наглядности вывели поля Impact (влияние идеи на бизнес и продукт) и Effort (какое время команда берёт на проектирование и реализацию решения). Оба значения заполняются в свободной форме. Обычно в Impact попадает несколько ключевых метрик и прогнозируемые изменения, а в Effort — количество спринтов на реализацию.
Итогом каждой встречи должно стать следующее: колонка Pitch пуста, Backlog—Next—Now отражает актуальное положение дел, а в Analysis остаются только те задачи, по которым ещё не набралось достаточно данных.
Пара слов про защиту. Инициатор должен отстоять идею, команда и менеджер будут бороться за слот на реализацию. Ограничений по формату нет, но на каждую защиту выделяется 5–7 минут, за которые нужно успеть доказать ценность идеи, согласовать ограничения на реализацию и перенести в бэклог. Изначально мы предполагали собирать на защиту комитет из людей с независимой позицией, но решили отложить эту схему на случай крайней необходимости.

Внедрение

Всё вышеописанное, начиная от формата задач до повестки встреч, зафиксировали в Confluence. Потом завели проект в Jira и настроили Kanban-доску. На этом простая часть закончилась и началась сложная — внедрение.

Справедливости ради, не во всех направлениях проблема стояла одинаково остро, поэтому пилотировать мы начали там, где болело больше всего. А больше всего болело в направлении логистики.

Какие шаги предприняли:

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

В первые пару месяцев получалось довольно тяжко. Вот как вспоминают и оценивают тот период Мария, Антон и Стас:

Мария:
— Хорошо помню переход на GIST. Сначала было больно, потому что новый процесс ставил людей в новые рамки. Каким бы они ни были благом для конкретного человека, воспринимались в штыки. Выгоды были понятны, но когда ты их ещё не получил, а ограничения уже есть, это вызывает протест. Когда внедряли GIST в первой команде, люди сопротивлялись. А когда дошли до третьей команды, люди уже сами просили внедрить GIST.

Антон:
— Сначала нужно было свыкнуться с тем, что у тебя есть соседи по целям и проектам, и с ними придётся делиться ресурсами. Мы аккуратно, постепенно ко всему этому приходили. Начали с доски, в которой мы заводили задачи и описывали их, то есть приучали бизнес к тому, что задачи надо завести. Раньше они просто набрасывали свои идеи, а менеджеры всё заводили.
Затем мы создали отдельную доску, на которой все, кто хочет, могут завести идеи — менеджер продукта, разработчик, коллеги из бизнеса. Мы открыты к обсуждению, и даже стали проводить специальные встречи для этого.

Стас:
— Чтобы процесс проходил менее деструктивно внутри команд, мы стали заводить задачи разработки в продуктовые эпики. Они же потом стали формировать список проектов — Step-Projects. После того, как все привыкли к Step-Projects, мы ввели следующий этап — Идеи. Идея, в свою очередь, может состоять из нескольких этапов — нескольких Step-Projects.
В тот момент как раз поступила крупная задача на 2,5–3 месяца разработки. Мы её оформили в Идею, выделили MVP — это и был наш Step-Project. Дальше его поделили на таски и попытались поставить их на продакшен за два спринта в составе Step-Project«а. Поняли, что идея нам подходит, есть прогресс со стороны бизнеса. Дальше сформулировали следующий этап итерации.
Пока мы делали этот большой эпик, все поняли, какой элемент для чего нужен, где что должно находиться, куда и за какой информацией идти. Примерно отладили процесс. У нас появились регулярные этапы предпланирования, когда мы приоритизировали и проверяли идеи, то есть этап питчинга. Думаю, это и был момент запуска GIST в нашей логистике.

В целом, описанную ребятами картину мы наблюдали и при масштабировании на другие подразделения.

Например, чтобы перейти на GIST в одной из команд клиентского направления и обучить стейкхолдеров работать по новой схеме, пришлось провести пять дополнительных встреч, помимо kick-off и первых двух модерируемых приоритизаций.

Эти встречи позволили:

Объяснить правильную структуру и принципы описания идеи.
Выстроить и зафиксировать прозрачные для стейкхолдеров цели.
Научиться получать верхнеуровневые оценки по разработке на ранних этапах.
Мыслить в формате влияния на бизнес и метрики.
Технической команде приносить и высказывать продуктовые идеи.

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

Хорошие новости в том, что ситуация постепенно исправляется. Эмпирически выяснили, что на трансформацию мышления у всех участников процесса уходит 2–3 месяца, после чего нагрузка на менеджеров продукта постепенно спадает.

И жили они долго и счастливо?

GIST хорошо прижился в рамках логистического направления (хоть и пришлось немного помучиться при внедрении):

Мария:
— Есть очевидный плюс: все команды приоритизируются одинаково, процесс знаком всем сотрудникам в любой команде. Каждый может посмотреть, чем занимается другая команда. Это добавляет прозрачности. Все понимают, что делает команда, и что она делает благо: у задач есть спрогнозированный результат для бизнеса. Все радуются, что эта команда принесёт нам дополнительный прирост KPI там, где он нужен.
Второе — это про другой аспект прозрачности: понятно, когда будет сделана задача, которую ты ждёшь. Либо она взята в работу, либо нет. Не нужно звонить менеджеру раз в неделю и спрашивать, когда 1 из 20 задач будет сделана. Это новый и более формализованный способ коммуникации, у которого есть простые и понятные правила. Людям становится намного легче общаться, причём не разговаривая. Всё собрано на одной доске. Экономится куча времени. Важно любить время других людей и уважать его. Не только своё.
У меня есть и личные профиты: в моей жизни стало меньше ответов на вопросы, меньше стресса от того, что нужно много раз людям объяснять. Сейчас даже если задают этот вопрос, можно кидать ссылку.

Антон:
— Я не зря возлагал на GIST много надежд. Новый процесс привнёс прозрачность для всех. Все понимают, что мы хотим сделать, зачем это делать, какие ожидаем результаты и сколько это будет «стоить».
Да, в редких случаях всё ещё бывают плохо проработанные идеи, у которых понятна ценность, но не проработаны требования. Как правило, мы стараемся не пропускать такие идеи в разработку и просим коллег довести их описание до требуемого состояния. Это описание не «для того, чтобы было». Доска служит историей для любого человека, который придёт в компанию или не погружён в текущую задачу. У любого человека в компании должна быть возможность зайти на доску, открыть любую реализованную идею и понять: зачем её брали в работу, что она дала компании, как она работает.

Стас:
— У меня не было чётких ожиданий перед внедрением. У меня были проблемы, которые я хотел решить с помощью GIST. И они действительно решились. Но при этом я точно знаю, что у GIST большой потенциал, если его продолжать внедрять. Останавливаться не стоит.
Из плюсов: был прецедент, когда ребята из разработки сами предложили какие-то идеи. У них появился для этого прозрачный механизм. Есть доска идей, есть правила оформления и прохождения через весь этот процесс. Когда у кого-то есть идея, он знает, что нужно зайти, создать задачу, довести её до нужного статуса, указать все необходимые элементы. А потом по этой задаче придёт product-менеджер с вопросами, и дальше она пойдёт в приоритизацию.

Если подняться на уровень выше, то любопытно посмотреть и на культурные изменения, которые произошли с момента запуска пилота:

У команд и стейкхолдеров вырабатывается привычка подробно оценивать идеи с точки зрения влияния на бизнес и продукт. А это, в свою очередь, отличная предпосылка к поддержанию и развитию целеполагания по OKR.
Ориентация на единый инструмент (Jira) и возможность отследить движение идеи добавляет прозрачности и снижает использование сторонних решений (меньше Google-таблиц и их аналогов, да).
Понятные шаги по созданию и продвижению идей постепенно вовлекают в работу с продуктовыми командами людей из бизнеса, обычно далёких от разработки.

Результаты в направлении логистики нас порадовали, и началось постепенное внедрение в других командах. К осени 2020 года GIST проник во все продуктовые направления Delivery Club, но не везде прижился как основной процесс.

Например, в большей части команд клиентского направления мы продолжаем использовать запущенный в 2018 году подход с фокусом на бэклог гипотез (подробнее про это расскажем в другой раз). Эмпирически выяснили, что если у команды небольшое количество стейкхолдеров и меньший разброс по ключевым метрикам, то можно применять принципы GIST без перестраивания привычных процессов. Тем не менее, даже в этом случае мы провязали Jira-проекты и настроили регулярный разбор идей — это необходимо для поддержания консистентности в рамках всей компании.

Напоследок нужно сказать, что GIST и наше его воплощение, конечно же, не являются серебряной пулей от мира процессов и, как видно из примера с клиентским направлением, приживается не везде. Более того, не всё проходит гладко и в тех командах, где GIST работает уже достаточно давно. Из основных проблем:

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

В целом же, получилось вполне неплохо. GIST доказал свою ценность и продолжает развиваться, а мы обязательно продолжим рассказывать об изменениях и результатах.