В прошлых постах про #системное_мышление мы уже поговорили об инструментах, позволяющих произвести анализ причин конкретной проблемы. Но что делать, если проблема, с которой мы столкнулись, оказывается более сложной и запутанной? Что, если она возникает вновь и вновь? В такой ситуации мы можем говорить уже об определённом паттерне поведения и нашей целью становится анализ его причин.

🦔 День сурка — Мы не можем работать в таких условиях — задачи приходят к нам не готовыми для разработки! — упорно твердил голос Миши из динамика. — Да как так-то?! — воскликнул Симон, находившийся в одной комнате со мной. — Ахмет и так пихает в описание тикетов всё подряд! Если он будет прописывать там ещё больше деталей, то зачем нужны мы?

Шёл второй час общей ретроспективы с представителями команд. Я ощущал себя героем фильма «День сурка»: тема бэклога поднималась каждые два-три спринта, и достичь консенсуса с каждым разом становилось всё сложнее. Миша был негласным лидом аутсорс-команды из Кракова, а Симон — разработчиком в нашем берлинском офисе.

— Михаил, мы уже три раза пересматривали наш Definition of Ready, — включился Ахмет, владелец продукта. — Я трачу больше половины своего времени на описание тикетов, вместо того чтобы общаться с клиентами и заниматься стратегией! — Ахмет, да не вопрос. Просто не надо потом обвинять нас, что мы неверно оценили размер задач и не смогли сделать всё за спринт! — отрезал Миша. — Миша, спокойно, никто никого не обвиняет. Мы пытаемся найти тот уровень детализации, с которым будет комфортно всем сторонам, — вставил я, стремясь вернуть обсуждение в конструктивное русло.

☕️ Разговор за кофе — Симон увольняется, — как бы между делом бросил Фридрих, наш CTО, пока мы стояли в очереди за кофе. — Говорит, не видит смысла работать в условиях, когда всё решается без участия команды. Я невольно вздохнул. Это был уже третий подобный случай за восемь месяцев. Мы продолжали терять ребят, которые закладывали фундамент нашего продукта.

— Что думаешь делать? Снова затыкать дыры аутсорсом? — спросил я. — А что ещё остаётся? Клиенты уже видели роадмап. Хотя инвесторы явно не обрадуются — эти ребята дорого нам обходятся… Я снова вздохнул. Каждый раз, теряя кого-то из команды, мы добавляли людей на аутсорсе. В итоге Ахмет и берлинские ребята оставались в меньшинстве, а бэклог обрастал всё большим количеством деталей.

— Давай попробуем проанализировать эту проблему системно, — предложил я.

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

— Кто бы мог подумать, что эти две проблемы связаны между собой! — озадаченно протянул Фридрих.

Из модели мы поняли, что рычагами, которыми мы сможем повлиять на ситуацию, являются наш Definition of Ready и политика комплектования продуктовой группы. В результате мы решили откатиться к версии DoR, составлявшейся до подключения внешних специалистов. В долгосрочной же перспективе нам следовало зафиксировать идеальное соотношение in-house- и outsource-специалистов и постепенно снижать долю последних в нашей продуктовой группе.

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

Денис 💚