Я работаю разработчиком ПО в команде, и у нас много загвоздок и распожаризация регулярно должна проводиться. Поэтому этот семинар очень для меня был полезен. У нас в общем классная команда, и хороший и важный продукт (ETL приложение - часть платформы по прогнозированию закупок для ритейла).
Повлиять на правила коммуникации в команде своим примером важно. Если важно сначала обработать проблему в ИИ и уже приходить к коллегам с оформленным запросом, а не просто дергать стихийно, то можно просто это самой постоянно делать и делать на это упор для коллег. Если нет полномочий вводить новые правила директивно, можно, действительно, транслировать свои принципы и показывать на своем примере другим, пропитывать окружение. У нас в команде есть knowledge sharing сессии и именно во время них можно рассказать о какой-то технологии, идее или процессе или своих принципах и предложить делать также. Буду собирать материал для такой сессии для коллег. Хочу провести ее.
У нас есть в команде дежурства, когда мы обрабатываем входящие запросы от пользователей нашего продукта, и я конечно не люблю дежурить, потому что нужно сразу реагировать и работать в стихийном режиме, также сталкиваться с эмоциональностью пользователей, и это меня выматывает, но такие дежурства необходимы. В принципе, я думаю, у нас этот процесс хорошо организован.
По поводу лишних встреч и собраний мы тоже пришли в команде к такому выводу, что надо минимизировать число созвонов и просить организаторов писать развернутую повестку и рекомендации к подготовке ко встречам.
Одна из ключевых проблем в нашей команде - накапливания merge requests до последнего, когда MR был анонсирован как готовый для code review, могут пройти недели, прежде чем его будут проверять, и если приходится вдруг менять подход к имплементации задачи по мнению проверяющих, это психологически тяжело - начинать все заново и менять подход, когда прошло столько времени с момента прошлой итерации. Тут много сопротивления появляется, что понятно. И часто исполнитель уже работает в этот момент над другой задачей не менее важной. И так накапливаются задачи. Еще у нас некоторые сотрудники больше делают имплементацию и меньше заняты как ревьюеры. То есть бывает ситуация когда кто-то постоянно сидит на ревью и не может заниматься ничем другим, так как количество ревью большое и постоянно повышается, а кто-то постоянно продолжает делать новые MR. Я по себе знаю, моя мотивация понижается, если я застряну в цикле ревью. Мне нужен баланс между работой над какой-то задачей по реализации и ревью чужих проектов.
С релизами у нас тоже проблема, очень долгие циклы (хорошо если получается делать релиз 2 раза в год, а план был хотя бы 4 раза в год, но он никогда еще не был выполнен, а я уже в этой команде работаю почти 7 лет). Накапливается куча новых фич и изменений, релиз гигантский сам выкатывается почти месяц, а потом еще почти месяц после мы получаем обратную связь в виде каких-то багов и пытаемся делать патчи. Мы правда уже закладываем этот месяц обратной связи и реакции на нее в план. Но хотелось бы сделать циклы релизов короче и не получать столько непредвиденной обратной связи в виде каких-то ошибок. Такая проблема у нас годами и мы не можем никак это решить, хотя пытались. Также прямо перед релизом волшебным образом появляется какое-то жесткое требование включить в релиз что-то еще недоделанное и мы часто еще дальше смещаем план релиза и ждем когда же это будет доделано, чтобы включить (впихнуть) в релиз. Соответственно, спешим и делаем ошибки.
Еще у нас есть определенные периоды когда мы делаем change freeze в компании, это часто праздники и длинные выходные, Рождество, летние каникулы, равноденствиеи тп. когда все в отпусках некому тушить пожары и реагировать на major incident. И постоянно так получается что мы делаем релиз именно в аккурат перед таким change freeze когда даже нету шанса на то, чтобы после релиза что-то исправить. Для меня это большая проблема, потому что часто именно меня назначают релиз менеджером в такие периоды (точно как по закону подлости) и мне приходится с этим всем в стихийном режиме работать, а я упираюсь как могу, расписываю свои опасения, но повлиять ни на что не могу. Короче я к этому отношусь как к личной проблеме уже 
и очень хочется это изменить.
Про коммуникацию - подтверждаю, что не надо срочно отвечать на вопрос коллеги в чате. Часто люди сначала дергают а потом решают проблему сами, если не получают ответа сразу. Это видно по реальным примерам.
У нас в бэклоге куча неначатых даже тикетов, есть инициативы, которые заморожены, мы всегда работаем в режиме многозадачности. Тем не менее наша команда как-то справляется, но только можно предположить, как бы мы работали, если бы применяли эти принципы распожаризации, наверняка,намного более эффективно и продуктивно. Плюс если смотреть по команде в целом, на кого-то больше падает и ответственности и давления, когда происходят пожары,а кто-то вообще не участвует и отсиживается в такие моменты. Нет равной ответственности как будто. И это считаю тоже не очень справедливым и мне это видится как дисбаланс.
Еще далеко не все тикеты расписаны и требования в них указаны. Часто тикеты полупустые и задача на 100 процентов не ясна. Нужен refinement и часто групповой. Но проводим мы такие встречи нечасто.
Еще надо приоритет ставить на том, что уже в работе чтобы его закончить, а новые проекты не начинать или начать, но не фокусироваться на новом, пока старое не закрыли. У нас часто сверху прилетают приоритеты. Например мы работаем в полную силу над чем-то и вдруг нам сообщает, что надо это заморозить до лучших времен и вот нам новая более важная задача. А мы даже и не думали и не предвидели. И всегда какие-то аргументы конечно же есть, почему это так. И мы то, над чем усиленно работали, кладем на полку и постепенно это все покрывается пылью и потом года через 2 снова возвращаемся и уже в там устарело все и надо заново начинать и переделывать. В принципе описала примерно опыт работы. Не знаю, как это можно контролировать, если мы обязаны подчиняться.
В целом про многозадачность, мы с подругой вчера смеялись, как еще 10-12 лет назад это было модно - быть многозадачным и даже выставлялось как сильная сторона личности на собеседованиях. А теперь уже и не модно.
Благодарю за семинар, буду еще дослушивать. Не с самого начала делала заметки. Там очень много пользы.