— Если я в чём-то сомневаюсь, я возвращаюсь к началу.
Альбус Персиваль Вульфрик Брайан Дамблдор
Статья коллеги про отношение к вынужденной удалёнке вдохновила меня рассказать о самом серьёзном испытании, с которым я столкнулся в первые полгода такого режима: грумминг сложных задач стал невыносим. Под катом я постарался не только рассказать о проблеме, но и поделиться своими соображениями о её решении. Возможно, кто-то сочтёт мои рассуждения очевидными и подумает, что были допущены детские ошибки. Но я также верю, что найдутся и те, кому мой опыт окажется полезен.
Введение
Чтобы разобраться с изменениями, к которым привела удалёнка, сперва расскажу вам немного о том, как устроен спринт в нашей команде. Product owner (PO) и техлид готовят задачи к n+1-ому спринту в течение всего n-ого двухнедельного периода. Простые (если выразиться точнее, то понятные) задачи сразу попадают в трекер с более или менее подробным описанием. Такая таска самодостаточна и не требует дополнительного разбора, поэтому разработчик может увидеть её первый раз на планировании, при необходимости — задать уточняющие вопросы, и успешно с ней справиться. Второй класс задач требует особого отношения: их нельзя просто скинуть на разработчика, потому что решение не очевидно, или кажется сложным, или делать придётся так много, что за один спринт не уложиться и лучше задачу разбить. Такая история уносится на грумминг.
Цель грумминга — получить из истории готовый набор задач, распределённый между сторонами разработки и спринтами. После такого разбора вся команда становится в курсе не только истории, но и принятого решения, у PO появляются примерные сроки реализации и понимание трудоёмкости грядущей доработки. Состав участников церемонии сильно разнится в зависимости от ситуации: вопросы оптимизации взаимодействия с БД касаются только беков, при обсуждении доработки админки не нужны мобильные разработчики, а стандарт веб-виджетов не требует присутствия всех беков. Но подключиться к обсуждению может любой желающий член команды.
В грумминге истории, о которой я буду рассказывать, участвовали все, кроме мобильных разработчиков. PO принесла команде интересную и амбициозную задачу: пользователям неудобно управлять шаблонами в трёх средах, поэтому нам нужна единая админка! Речь тут идёт о шаблонах уведомлений, которыми управляет специальный сервис, живущий в средах QA, STAGE и PROD. И проблема заключалась в неудобстве переключения между этими тремя средами и в их изолированности. Нет возможности перенести шаблон из одной среды в другую, синхронизация только руками, переход между средами — новый URL в браузере. Логичный вывод, к которому и пришла PO — единый интерфейс, один сервис для управления тремя средами вместо трёх полностью решил бы озвученные проблемы. Тем более, что в компании уже был такой успешный опыт. И мы начали думать над реализацией.
На первый взгляд задача казалась несложной, но когда мы касались деталей или пытались проговорить конкретный сценарий использования единого бекенда, мы наталкивались на противоречия, непонимание интеграции с остальными частями сервиса, сложностями тестирования и неоднозначными моментами с точки зрения безопасности. После второго грумминга у меня сложилось твёрдое впечатление, что мы делаем что-то не то, но PO была уверена в правильности выбранного курса, а у команды не было альтернативного решения, поэтому на третий грумминг я честно пытался разработать техническую реализацию, но мозаика не складывалась. Ощущение неправильности только укоренилось. Эта ситуация уже изрядно вымотала команду, ведь мы топтались на одном месте, никак не находя выхода из замкнутого круга.
Спас нас тогда наш технический руководитель. Сейчас мне кажется, что для этого было задано всего два вопроса:
— Зачем нам единый бекенд?
— Чтобы объединить три админки в одну, потому что три ужасно неудобно.
— Это единственное решение?
— ...
После этого, отталкиваясь от изначальной проблемы, мы ушли от концепции «единого бекенда» и остались жить на трёх отдельных сервисах. Проблему решили иначе: научили среды общаться друг с другом и дали пользователям возможность переключаться между средами и переносить шаблоны по кнопке.
Новое решение было выработано примерно за час; вся команда понимала, как будут работать сценарии использования сервиса; PO согласилась с тем, что мы таким образом добьёмся желаемого результата.
Сейчас я вспоминаю то время и понимаю, что эта задача была не единственной, которая вызвала лишние трудности. Команда на удалёнке гораздо чаще сталкивалась со сложностями на груммингах. И триггером, который меня очень сильно злил, служил вопрос «а какую проблему мы решаем?», звучащий примерно через 40 минут после начала от произвольного члена команды. И злил он не потому, что это глупо, а потому, что я в этот момент понимал, что не могу на него толком ответить. И очень хорошо, что он задан сейчас, а не ещё через 40 драгоценных минут. Но лучше, если бы ответ мы узнавали в самом начале, когда погружались в проблему.
Объяснение
Что же происходило? Почему было так тяжело?
На грумминге мы начали не с того: упомянув проблему (неудобства использования трех админок), мы сразу приступили к обдумыванию реализации решения (единый сервис). Решение было принято ещё до грумминга, не командой, а одним PO. Почему его изначально никто не подверг сомнению? Оно выглядело логичным. У PO была хорошая техническая база, она сама была разработчиком, внутреннюю структуру сервисов знала прекрасно и, очевидно, потратила немало времени и сил на обдумывание принесённой истории. Поэтому формулировка «.., поэтому нам нужен единый бек» была принята. Позднее начались сложности, ведь в головах членов команды не было того же пройденного пути и того же контекста задачи, что и у PO. Принесённое извне решение, сталкиваясь с трудностями, не находило поддержки в команде, и совершенно не хотелось искать пути реализации, потому что на самом деле мы не считали его правильным. Оно не рождалось в пылу дискуссии и пинг-понга из аргументов разных членов команды. Было ли оно плохим? Нет. Сейчас я понимаю, как можно было встроить его в наш сервис. Но тогда не понимал. Не понимала и команда. Мы считали правильным другой путь развития, на который и получилось попасть, сделав шаг назад благодаря тому диалогу с техническим руководителем.
А может быть, дело совершенно не в этом, и ценой хорошего решения как раз и были те три неудачных грумминга? Может быть, именно они добавили нам понимания проблемы и наших возможностей? Я считаю, их можно было избежать. Изначальный рассказ о проблеме загнал нас в определённые рамки, и в них проходили все дальнейшие рассуждения. Хочется сказать, что мы стали жертвами фрейминга. Ууу, эта злая PO издевалась над командой. На самом деле PO, как мне кажется, оказалась в той же самой ловушке: перед ней был успешный пример соседнего сервиса, развивающегося по готовой схеме, а наши потребности казались очень похожи. Единственное, что отличало её от нас, это эмоциональная привязанность к решению, выросшая в ходе предварительной работы и осмысления. Именно поэтому она его защищала, а мы были настроены скептически.
При чём тут удалёнка?
Как иной режим работы повлиял на наши способности понимания проблем?
Позвольте начать с аналогии. В детстве мама мне говорила «не кусочничай, хочешь есть — поешь нормально». На удалёнке мы все невольно начали следовать этому совету в отношении потребления информации о рабочих задачах. Раз в неделю случался полноценный обед (грумминг), на котором мы получали большую порцию информации за короткий промежуток времени. Причём часто это оказывалась первая порция по этой теме. В офисе всё было иначе. Часть общения PO с бизнесом соседних команд происходила прямо на рабочем месте; когда мы ходили выпить кофе, то обсуждали интересные баги и идеи; брошенное в сердцах ругательство после очередной непростой встречи по планированию интеграции завязывало разговор; то есть команда всё время получала кусочки информации об окружающих делах и проблемах. Таким образом, к груммингу мы подходили уже каждый с собственным представлением о задаче. Мы почти никогда не слышали о теме первый раз на грумминге. И обязательно в первые минут десять мы выравнивали свои представления о предстоящем предмете обсуждения. Удалёнка убрала все эти случайные перекусы, оставив только грумминг, блюда для которого PO готовила в одиночку.
Получается, на грумминге PO и остальная часть команды оказывались во власти совершенно разных контекстов:
PO успевала подумать, поискать референсы и даже, возможно, прикипеть к какому-то решению. ("Тому, кто занимается моделированием и проектированием программных систем, нельзя слишком привязываться к своим собственным идеям." Эрик Эванс в книге "Domain - Driven Design")
Команда была лишена этого предварительного опыта, из-за чего сразу оказывалась на середине пути: решение, можно сказать, уже принято, осталась лишь техническая реализация, но... «а какую проблему мы, собственно, решаем?»
Что можно сделать?
Удалённый режим стал неотъемлемой частью нашей жизни: одну коллегу я так и не успел увидеть вне зума, она уволилась раньше, чем мы пересеклись. Так что с такими ситуациями нужно уметь справляться, ведь сам по себе информационный разрыв между бизнесом и разработкой никуда не денется. И вот что мы предприняли в своей команде:
Обсудили на ретро возникшие проблемы. Я поделился мыслями о фрейминге, и мы согласились с тем, что нельзя приносить на грумминг готовое решение и лишь ожидать разбора технической реализации. Вместо этого всегда начинаем обсуждение с проблемы, и все вместе приходим к общему аргументированно выбранному в результате диалога и споров решению. Так мы устранили фрейминг.
Договорились, что перед груммингом инициатор заранее заводит страницу с предварительной информацией, с которой заранее может ознакомиться любой желающий. Более того, вопросы можно задавать тоже заранее, чтобы инициатор подумал над ответами на них и дополнил страницу. Выражение проблемы и требований в письменном виде структурировало мысли в голове инициатора и помогало отделить исходные данные от выводов. Так мы устранили разрыв контекста.
Не знаю, насколько эти советы универсальны и подойдут ли они конкретно вашей команде, но эта история придала мне уверенности в том, что возникающие трудности разрешимы. Не легко, ведь нужно осознать, что происходит, порефлексировать и найти слова, которые помогут команде понять тебя. Но это стоит того. Надеюсь, я смог подтолкнуть вас к разгадке какой-нибудь дилеммы в вашей работе или просто принёс новые мысли. Продуктивных вам груммингов.