Как продуктовые планы могут внести хаос в IT команду

Привет, Хабр! Меня зовут Виталий, и за 9-летний опыт работы PM и 2-летний Agile coach в энтерпрайзе я часто сталкивался с ситуациями, как продуктовые планы влияли на ИТ-команды. Некоторые из таких ситуаций были безобидными, другие могли угробить всю компанию.

Подробнее рассмотрим три ключевые ситуации и их последствия:

1. несвоевременное предоставление планов;

2. задачи с фиксированным сроком;

3. отсутствие планов или плохо проработанные задачи.

Если хотите об этом поразмыслить, добро пожаловать под кат.

Ситуация 1: несвоевременное предоставление планов

Хороший план составленный сегодня, лучше идеального плана, который появится на следующей неделе. 

Генерал Джордж Паттон

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

ИТ-команды ожидают, что планы будут предоставлены досрочно, чтобы смогли их проработать, грамотно спланировать и взять на себя обязательства, но планы предоставляют, когда работа над задачами/проектами уже должна начаться, а времени на качественное планирование не остается. И тут команды совершают убийственную ошибку — сокращают время на аналитику, проработку технического решения, дают оценку с потолка и подписываются на решение задачи. Или другой вариант: не могут признаться себе и бизнесу, что не способны сделать что-то ценное или не могут объяснить, что выделенного времени недостаточно.

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

Последствия: 

1. плохо проработанная аналитика;

2. сложности при планировании задач и оценки трудозатрат;

3. давление на ИТ команду сроками по задачам;

4. выгорание и демотивация сотрудников;

5. высокие риски для срыва сроков и плохого качества продукта.

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

• У нас нет задач на следующий квартал.

• Завтра пришлю.

• Нам нужно 4 недели на аналитику. 

• Так квартал уже начнется! 

• Ничего не знаю, нам нужно 4 недели!

• ¯_(ツ)_/¯ 

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

Ситуация 2: задачи с фиксированным сроком

Давать предсказания очень трудно, особенно когда они касаются будущего.

Нильс Бор, датский физик

Предпосылка: Периодически к ИТ-командам приходят на разработку высокоприоритетные проекты/задачи с фиксированным сроком, и, как правило, у ИТ-команд нет возможности сдвинуть дедлайн для таких задач. Часто реальный дедлайн для таких задач намного позже, чем требует менеджмент (33% ИТ-проектов превышают график (McKinsey). 

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

При формировании новых команд никто не учитывает: время на адаптацию созданных и измененных команд, снижение производительности, потраченное время на новое планирование, время на переключение между задачами. Сделать зрелую команду при постоянно меняющихся составах невозможно. В результате: команды никогда не смогут выйти на свою максимальную производительность.

Последствия: 

1. плохо проработанная аналитика;

2. сложности при планировании задач и оценки трудозатрат;

3. высокий Time to market;

4. давление на ИТ-команду сроками по задачам;

5. выгорание и демотивация сотрудников;

6. высокие риски для срыва сроков и плохого качества продукта;

7. незрелые команды.

Многие из нас сталкивались с проектами с фиксированными сроками. Этот челлендж захватывает, объединяет команду, заставляет бежать всем вместе в одну сторону, но, как правило, все заканчивается выгоранием и хотфиксами. Если не давать перерывов после таких забегов, о долгосрочной эффективности не может быть и речи. Создавайте для себя и своих коллег периоды с меньшей нагрузкой после длительных забегов, потратьте время на ретроспективу и на решение проблем, которые возникли за период марафона.

Ситуация 3: отсутствие планов или плохо проработанные задачи

Когда выгоды невозможно оценить количественно, в качестве общего правила считайте, что их нет. 

Том Демарко и Тимоти Листер

Предпосылка: Отсутствие владельца продукта обычно приводит к тому, что команды встречаются с первой и/или второй описанной ситуацией, но сначала — с нехваткой продуктовых планов. Вроде ничего страшного, и команды начинают заниматься техническим долгом, рефакторингом и всем тем, на что всегда не хватало времени, но в какой-то момент приходит менеджмент и спрашивает: «А чем занимается команда?». 

Команда не в состоянии оценить свои результаты и перевести их в ценность для бизнеса. Сотрудников таких команд начинают привлекать в другие команды (см. ситуацию 2) или начинают подкидывать им плохо проработанные продуктовые задачи, ценность которых никто не рассчитал. Вина за недостигнутые бизнес-показатели, которые менеджмент считал реальными, лежит на ИТ- команде, ведь до бизнес-анализа руки ни у кого так и не дошли. В результате: растет недовольство бизнес-подразделениями. 

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

Последствия: 

1. команды не понимают для чего выполняют ту или иную работу, и как их результаты влияют на бизнес;

2. высокий Time to market;

3. выгорание и демотивация сотрудников;

4. возрастает недовольство бизнес-подразделениями.

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

К чему все это может привести?

Все компании рано или поздно сталкиваются с трудностями при планировании: как я писал выше, по информации McKinsey, 33% крупных софтверных проектов превышают сроки, 66% — бюджет. Яндекс, Сбер и Лига Ставок не стали исключениями, мы тоже время от времени сталкиваемся с похожими проблемами. Но тут самое главное — это выбор, который делает каждый из нас видя такие сложности.

Вот так выглядит дерево текущей реальности компании, которая не построила у себя процесс планирования и не понимает к каким последствиям приводит такое поведение.

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

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

Как все это можно исправить? И что сделали мы?

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

Для решения проблем на текущей схеме необходимо:

1. сосредоточиться на управлении стратегией и управлением заинтересованными лицами;

2. внедрить OKR или любой другой метод повышения прозрачности целеполагания;

3. cнизить давление на команды и перестать вбрасывать внеплановые задачи;

4. начать управлять командами, а не сотрудниками;

5. повысить уровень контроля, давать развивающую обратную связь сотрудникам и признавать их заслуги.

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

Вы спросите: «А что я сейчас могу сделать в своей компании?»

Я вам предлагаю следующий план:

1. осознать необходимости изменений (я надеюсь, это статья помогла вам в этом);

2. выявить желание поддерживать изменения и участвовать в них;

3. собрать знания того, как осуществлять изменения и каким должен быть результат (этим вам предстоит заняться в ближайшее время).

   1. ответить на вопросы: зачем нужны изменения? кого они затрагивают? кого из «спонсоров» нужно привлечь для поддержки задуманного?

   2. разработать план по внедрению изменений;

4. внедрять изменения день за днем;

5. закрепить изменения.

Дерзайте, дорогу осилит идущий. 

А как вы решали такие проблемы в своей компании?