Приехав в офис SemRush, обнаружил там 4 очень разных команды. Давно не видел такого разнообразия :) Обычно все команды в одной компании исповедуют более менее одну идеологию. А тут прям совсем разные люди, впрочем, мирно уживающиеся друг с другом.
Было интересно: то, что работало с одной командой, не работало с другой, и наоборот. Но вначале мы собрались вместе и составили список проблем, которые видели сами команды и руководство компании:
- нет обратной связи от руководства об успешности действий
- нет обратной связи от пользователей в команду (только маркетологам)
- сроки не выполняются
- нет последствий нарушения качества или сроков
- в некоторых ситуациях не понятно, кто должен принимать решение
- менеджеры перегружены
- затруднено согласование действий между командами
- опасность развала процесса при расширении команд и увеличении их количества
- у некоторых разработчиков нет желания совершенствовать работу.
Некоторые жалобы весьма типичны, не так ли? Особенно "менеджеры перегружены" и последняя. Когда они есть, значит явно есть проблема с прозрачностью. Помните ту чудесную матрицу доверия-прозрачности?
Вот она и говорит нам, что раз есть такие жалобы "нет желания совершенствовать работу", значит на самом деле, что бы ни говорили люди, нет доверия. Но глупо считать, что оно само по себе возьмётся. Как иллюстрирует эта матрица скачков от "нет доверия" к "есть доверие" на том же уровне прозрачности не бывает. Тут нужно начать с другого – сначала сделать очевидным, кто над чем и как работает, и тогда только повысится доверие. Которое сохранится и при уменьшении прозрачности, НО если снова всё станет непрозрачно есть риск уйти снова в квадрант "нет-нет".
В такой жалобе и подобных всегда нужно искать корневые причины - с которыми и работать. Scrum, Kanban или другие процессы – это средство, а не цель. Цель же в устранении не всех проблем, а в устранении корневых проблем, мешающих эффективно выполнять бизнес-задач. Поэтому одним из первых шагов было построение такого "дерева проблем".
Жёлтым тут выделены корневые проблемы. Мы пришли к ним строя вместе с командами и руководством связи между причинами и следствиями. Это заняло первые пару дней.
А вот уже потом началось собственно внедрение Scrum с прицелом на покрытие конкретно этих проблем, проходившее в 4-х командах параллельно, что, кстати, было очень удачным решением в условиях разнообразности – наконец, все стали говорить на одном языке, понимая друг друга.
Про само внедрение писать не буду. Там свои тонкости ;) Захотите внедрить – обращайтесь :)
А компании SemRush удачи! У них хороший коллектив и замечательный офис на Ладожской, в котором очень вкусные печеньки!
