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

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

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

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

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

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

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

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

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

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

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