Ретроспективы. Что делать если твои проблемы игнорируют?

В форму обратной связи пришёл такой вопрос от анонимного читателя:

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

Как я понимаю, раз уж используется термин "ретроспектива спринта", то мы говорим про более-менее классический СКРАМ или его вариацию.

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

При этом проблемы будут везде: у молодого стартапа и у старого легаси-проекта с десятками годами истории. Если проблем нет, то скорее всего ты работаешь над чем-то, что никому не нужно.

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

У живого проекта такой беклог будет забит работой на несколько лет вперёд, и практически всегда у твоей команды не будет хватат времени на все фиксы и все фичи.

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

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

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

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

Что же касается ретроспективы, то рассматривай её, как ещё один этап формирования спринта. У тебя может быть 99 проблем, но физически, вы можете решить две из них. Конечно, можно остановить работу и сфокусироваться на всех проблемах, но возможно это плохо скажется на работе продукта, и что немаловероятно — даст преимущество конкурентам, которые в итоге задавят твой продукт. Надо оно тебе?

Если уж заявляете "митинг для решения проблем", надо решать все заявленные проблемы, неважно, сколько времени это займет, несмотря на аргумент "у нас мало времени" (если вы время на ретроспективы и прочие митинги находите, у вас его очень много, но почему-то, когда дело доходит до самого митинга ой, у нас времени нет)

Такая постановка вопроса пожалуй неверна. Ретроспектива — это митинг для выявления проблем, и для выработки стратегии итеративного решения наиболее приоритетных из них.

Какие-то из предложенных проблем могут быть болезненны для тебя лично, но в целом устраивать команду, а какие-то могут быть серьёзным препятствием для работы большинства членов команды, но особо не касаться тебя. Вот тут тебе и нужны те самые people skills. Вы все должны объяснять, как проблема влияет на вас лично, на команду в целом и на продукт. И все вместе должны набрать себе на ближайший спринт-месяц-квартал несколько наиболее приоритетных проблем и сфокусироваться на их решении.

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

Однажды я работал в команде в которой плохо было примерно всё: сложная распределенная система из 80+ микросервисов различного возраста. Множество "культурных слоёв" легаси-кода, накопленного за 12 лет эксплуатации. Постоянные пожары на продакшне, и смехотворно маленькая команда в 4 инженера на всё это. Ну и добавим сюда бэклог в несколько лет, и постоянное недовольство от остальных команд, которым мы регулярно срывали все сроки.

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

Разруливали ситуацию именно так, как делают это у тебя в команде. Обсуждали варианты, брали в разработку какие-то идеи, замеряли результаты и либо вводили практику в процесс, либо отбрасывали её и брались за другую проблему.

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

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

Что же тебе делать?

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

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

И конечно же почитай что-нибудь про итеративные процессы разработки.

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

Я бы предложил почитать какие-нибудь книги про это дело.

The Phoenix project
Lean from the trenches
Extreme Programming Explained

Это всё достаточно старые книги, наверняка, читатели смогут поделиться хорошей и современной литературой по теме. С удовольствием выпущу пост с дополнениями, если такие варианты найдутся.

Посты на эти и другие темы публикую в канале: https://t.me/your_soft_skillzz

и твиттере https://twitter.com/soft_skillzz

Напоминаю, что мне можно задать вопрос или предложить свою тему для нового поста через форму обратной связи: https://goo.gl/forms/1G2206MfVzfoowHf2

Подписывайтесь и рассказывайте друзьям.

МS.