- Если я в чем-то сомневаюсь, я возвращаюсь к началу.Теги: #Управление разработкой #разработка #agile #техлидер #команда #решение проблем #уходАльбус Персиваль Вульфрик Брайан Дамблдор Статья Коллеги об отношении к вынужденной удаленной работе вдохновили меня рассказать о самом серьезном испытании, с которым мне пришлось столкнуться за первые полгода этого режима: заниматься сложными задачами стало невыносимо.
Под катом я постарался не только рассказать о проблеме, но и поделиться своими мыслями по ее решению.
Возможно, кто-то посчитает мои рассуждения очевидными и подумает, что допущены детские ошибки.
Но я также верю, что найдутся те, кому мой опыт будет полезен.
Введение
Чтобы понять, какие изменения принесла удаленная работа, сначала расскажу немного о том, как работают спринты в нашей команде.Владелец продукта (PO) и технический руководитель готовят задачи для n+1-го спринта в течение всей n-й двухнедельного периода.
Простые (точнее, понятные) задачи сразу попадают в трекер с более-менее подробным описанием.
Такая задача самодостаточна и не требует дополнительного анализа, поэтому разработчик может впервые увидеть ее при планировании, при необходимости задать уточняющие вопросы и успешно с ней справиться.
Второй класс задач требует особого отношения: их нельзя просто свалить на разработчика, потому что решение не очевидно, или кажется сложным, или нужно сделать так много, что за один спринт его не выполнить, и это лучше.
разделить задачу.
Такая история берется за груминг.
Цель груминга — получить из истории готовый набор задач, распределенный между партиями разработки и спринтами.
После такого анализа вся команда становится в курсе не только истории, но и принятого решения, у ПО есть примерные сроки реализации и понимание сложности предстоящей доработки.
Состав участников церемонии сильно варьируется в зависимости от ситуации: вопросы оптимизации взаимодействия с базой данных касаются только бэкеров, при обсуждении доработок админки не нужны мобильные разработчики, а стандарт веб-виджета не требует присутствия всех покровители.
Но к обсуждению может присоединиться любой член команды.
В подготовке истории, о которой я расскажу, участвовали все, кроме мобильных разработчиков.
ПО поставило перед командой интересную и амбициозную задачу: пользователям неудобно управлять шаблонами в трех средах, поэтому нужна единая админка! Речь идет о шаблонах уведомлений, которыми управляет специальный сервис, обитающий в средах QA, STAGE и PROD. А проблема заключалась в неудобстве переключения между этими тремя средами и их изоляции.
Нет возможности перенести шаблон из одной среды в другую, синхронизация только вручную, переход между средами - новый URL в браузере.
Логический вывод, к которому пришел ПО, заключается в том, что единый интерфейс, один сервис для управления тремя средами вместо трех полностью решит поставленные проблемы.
Более того, у компании уже был такой успешный опыт. И мы начали думать о реализации.
На первый взгляд задача казалась простой, но когда мы затронули детали или попытались обсудить конкретный сценарий использования единого бэкенда, мы столкнулись с противоречиями, непониманием интеграции с другими частями сервиса, трудностями тестирования и неоднозначными вопросами со стороны точки зрения безопасности.
После второго груминга у меня сложилось стойкое впечатление, что мы делаем что-то не так, но ПО было уверено в правильности выбранного курса, а альтернативного решения у команды не было, поэтому для третьего груминга я честно постарался разработать техническая реализация, но пазл не подошёл.
Чувство своей неправоты только усилилось.
Эта ситуация уже изрядно утомила команду, ведь мы топтались на одном месте, не находя выхода из порочного круга.
Тогда нас спас наш технический менеджер.
Сейчас мне кажется, что для этого было задано всего два вопроса:
— Зачем нам единый бэкенд? — Объединить три админки в одну, потому что три — это жутко неудобно.После этого, отталкиваясь от исходной проблемы, мы отошли от концепции «единого бэкенда» и остановились на трёх отдельных сервисах.- Это единственное решение? — .
Проблему решили иначе: научили среды общаться друг с другом и дали пользователям возможность переключаться между средами и передавать шаблоны с помощью кнопки.
Новое решение было разработано примерно за час; вся команда понимала, как будут работать сценарии использования сервиса; ПО согласился, что таким образом мы добьемся желаемого результата.
Сейчас я вспоминаю то время и понимаю, что эта задача была не единственной, вызывавшей лишние трудности.
Удаленная команда гораздо чаще сталкивалась с трудностями при груминге.
И триггером, который меня очень разозлил, стал вопрос «какую задачу решаемЭ», услышанный минут через 40 после старта от произвольного члена команды.
И разозлил он меня не потому, что это было глупо, а потому, что в тот момент я поняла, что не могу толком ему ответить.
И очень хорошо, что это задается сейчас, а не еще через 40 драгоценных минут. Но было бы лучше, если бы мы узнали ответ в самом начале, когда погрузились в проблему.
Объяснение
Что случилось? Почему это было так тяжело? При груминге мы начали не с того: упомянув проблему (неудобство использования трех админок), мы сразу начали думать о реализации решения (единого сервиса).Решение было принято до груминга не командой, а одним ПО.
Почему никто не задавался этим вопросом изначально? Это казалось логичным.
У ПО была хорошая техническая подготовка, она сама была разработчиком, прекрасно знала внутреннюю структуру сервисов и, очевидно, потратила много времени и сил на обдумывание истории, которую принесла.
Поэтому была принята формулировка «.
поэтому нам нужен единый бек».
Позже начались трудности, потому что у членов команды не было в голове того же пройденного пути и того же контекста задачи, что у ПО.
Принесенное извне решение, столкнувшись с трудностями, не нашло поддержки в команде, и мы не хотели искать пути его реализации, потому что по сути не считали его правильным.
Оно не зародилось в пылу дискуссий и пинг-понга между аргументами разных членов команды.
Было ли это плохо? Нет. Теперь я понимаю, как это можно было встроить в наш сервис.
Но тогда я не понял.
Команда тоже не поняла.
Мы посчитали правильным другой путь развития, на который в итоге и пошли, сделав шаг назад благодаря тому диалогу с техническим менеджером.
Ошибка заключалась в том, что мы не начали с корня проблемы.Изначально, оказавшись во второй на тот момент тупиковой ветке для команды, мы не смогли прийти к устраивающему нас решению.
А может, дело совсем не в этом, и ценой хорошего решения стали именно те три неудачных груминга? Может быть, именно они добавили нам понимания проблемы и наших возможностей? Я считаю, что их можно было избежать.
Первоначальный рассказ о проблеме загнал нас в определённые рамки, и все дальнейшие рассуждения происходили внутри них.
Я хотел бы сказать, что мы стали жертвами фрейминга.
Ух, этот злой ПО издевался над командой.
По сути, ПО, мне кажется, попало в ту же ловушку: раньше это был успешный пример соседнего сервиса, развивающегося по готовой схеме, и наши потребности казались очень похожими.
Единственное, что отличало ее от нас, — это эмоциональная привязанность к решению, которая росла в ходе предварительной работы и размышлений.
Вот почему она защищала его, а мы были настроены скептически.
Причем здесь удаленная работа?
Как разные способы работы повлияли на нашу способность понимать проблемы? Позвольте мне начать с аналогии.В детстве мама говорила мне: «Не кусай, если хочешь есть, ешь нормально».
Работая удаленно, мы все невольно начали следовать этому совету относительно потребления информации о рабочих задачах.
Раз в неделю был полноценный обед (груминг), на котором мы получали большую порцию информации за короткий промежуток времени.
Причем зачастую это оказывалась первой порцией по данной теме.
В офисе все было по-другому.
Часть общения ПО с бизнесом соседних команд происходила непосредственно на рабочем месте; когда мы шли пить кофе, обсуждали интересные баги и идеи; Горячее проклятие после очередной трудной встречи по планированию интеграции положило начало разговору; то есть команда постоянно получала информацию об окружающих делах и проблемах.
Таким образом, каждый из нас подходил к грумингу со своим представлением о задаче.
Впервые на груминге мы почти никогда не слышали об этой теме.
И обязательно в первые десять минут мы сравняли свои представления о предстоящем предмете обсуждения.
Удаленный работник убрал все эти случайные перекусы, оставив только груминг, блюда, которые ПО готовил самостоятельно.
Оказывается, во время подготовки ПО и остальная часть команды оказались во власти совершенно разных контекстов:
- У ПО было время подумать, поискать ссылки и даже, возможно, привязаться к какому-то решению.
(«Тот, кто занимается моделированием и проектированием программных систем, не должен слишком привязываться к своим собственным идеям».
Рик Вэнс в книге «Проектирование, управляемое предметной областью»)
- Команда была лишена этого предварительного опыта, поэтому сразу оказалась на середине пути: решение, можно сказать, уже было принято, оставалось только техническая реализация, но.
«какая проблема мы действительно решаем проблемуЭ»
Что может быть сделано?
Удаленный режим стал неотъемлемой частью нашей жизни: у меня никогда не было времени увидеть ни одного коллегу за пределами Zoom; она ушла до того, как мы встретились.Так что с такими ситуациями нужно уметь справляться, потому что информационный разрыв между бизнесом и развитием сам по себе не исчезнет. И вот что мы сделали в нашей команде:
Не знаю, насколько эти советы универсальны и подойдут ли они конкретно вашей команде, но эта история вселила в меня уверенность в том, что возникающие трудности разрешимы.
- Мы обсудили проблемы, которые возникли на ретро-встрече.
Я поделился своими мыслями по поводу кадрирования, и мы сошлись во мнении, что нельзя принести готовое решение по грумингу и просто ожидать анализа технической реализации.
Вместо этого мы всегда начинаем обсуждение с проблемы и вместе приходим к общему аргументированному решению, выбранному в результате диалога и дебатов.
Вот так мы устранили кадрирование.
- Мы договорились, что перед грумингом инициатор заранее создает страницу с предварительной информацией, которую может прочитать каждый желающий.
Причем вопросы также можно задавать заранее, чтобы инициатор подумал над ответами на них и добавил на страницу.
Изложение проблемы и требований в письменной форме структурировало мысли в голове инициатора и помогло отделить исходные данные от выводов.
Таким образом мы устранили контекстный разрыв.
Это непросто, потому что нужно осознавать происходящее, размышлять и находить слова, которые помогут команде понять тебя.
Но оно того стоит. Надеюсь, мне удалось подтолкнуть вас к решению какой-то дилеммы в вашей работе или просто навестить на новые мысли.
Устройте себе продуктивный уход.
-
Как Удалить Плагин
19 Oct, 24 -
Теорема Байеса: О Чем Весь Этот Шум?
19 Oct, 24 -
Xbrl: Простые Вещи - Глава 1. Введение
19 Oct, 24 -
Преимущества И Недостатки Azure Cosmos Db
19 Oct, 24
