Post #1475

Как организовывать приоритизацию в командах, отвечающих за общие компоненты Представьте, что ваша команда разрабатывает какой-то кусок системы, от которого зависят нескольких других команд, каждая из которых делает важные для компании штуки. Они постоянно приходят к вам со своими запросами, которые зачастую конфликтуют друг с другом за приоритеты, и вам надо принимать решение, чьей задачей заниматься в первую очередь, и как их вообще совместить с вашими собственными целями. Есть несколько подходов, как это можно организовать: 👉Вы раздаете обещания налево и направо, пытаетесь угодить всем заказчикам, но в итоге подводите по срокам всех. Нереалистичные коммитменты постепенно нарастают друг на друге, и доверия к вашей команде все меньше. Единственный плюс такого подхода – вы выглядите довольно выгодно первые несколько циклов планирования. Основной минус – это впечатление длится недолго. 👉Вы приоритизируете задачи в вакууме, избегаете конфликтов, и противопоставляете части неудовлетворенных заказчиков хороший трек рекорд законченных проектов и собственных выполненных целей. Плюсы – вас ничто не ограничивает, команда движется быстро, дает какой-то результат. Минусы – доверия к команде все еще мало, так как она действует как черный ящик. 👉Вы строите систему, в которой ваши заказчики сражаются друг с другом за приоритеты в очереди задач. Плюсы – удобно для команды, вы снимаете с себя ответственность и ничем не рискуете. Минусы – вас начинают воспринимать сугубо как сервисную команду. 👉Вы делаете так, чтобы в компании появилась сквозная приоритизация для проектов. Условно говоря, если для всей компании проект А важнее, чем проект Б, то и ваши задачи для проекта А получают понятный приоритет. Такой подход дает всем командам понятные ориентиры и позволяет автономно принимать решения. Минус – менеджмент обычно не любит принимать такие сложные решения. Конечно, сквозная приоритизация – идеальный вариант, но ее появление не всегда зависит от вас. Второе место занимает подход с созданием очереди задач. С его помощью вы избегаете накапливания WIP задач на команде, у команды есть понятные приоритеты, а у вашего руководства – свидетельство того, что со своей частью работы вы справляетесь.