Привет, Хабр! Меня зовут Виталий, и за 9-летний опыт работы PM и 2-летний Agile coach в энтерпрайзе я часто сталкивался с ситуациями, как продуктовые планы влияли на ИТ-команды. Некоторые из таких ситуаций были безобидными, другие могли угробить всю компанию. Подробнее рассмотрим три ключевые ситуации и их последствия: несвоевременное предоставление планов; задачи с фиксированным сроком; отсутствие планов или плохо проработанные задачи. Хороший план составленный сегодня, лучше идеального плана, который появится на следующей неделе.  Генерал Джордж Паттон Предпосылка: В компании существует квартальное планирование или ежемесячное, или годовое, или любое другое… При этом планы предоставляются уже тогда, когда работа должна во всю идти или даже намного позже. ИТ-команды ожидают, что планы будут предоставлены досрочно, чтобы смогли их проработать, грамотно спланировать и взять на себя обязательства, но планы предоставляют, когда работа над задачами/проектами уже должна начаться, а времени на качественное планирование не остается. И тут команды совершают убийственную ошибку — сокращают время на аналитику, проработку технического решения, дают оценку с потолка и подписываются на решение задачи. Или другой вариант: не могут признаться себе и бизнесу, что не способны сделать что-то ценное или не могут объяснить, что выделенного времени недостаточно. При этом менеджмент думает, что все хорошо, у команды есть куча времени. Если цикл разработки больше, чем осталось времени в отчетном периоде, или проект за предоставленные сроки сделать нереально, то может получиться, что команда вообще никакого бизнес-результата не предоставит в этом отчетном периоде. Нет результата — не выполнены KPI — нет премии. Последствия:  плохо проработанная аналитика; сложности при планировании задач и оценки трудозатрат; давление на ИТ команду сроками по задачам; выгорание и демотивация сотрудников; высокие риски для срыва сроков и плохого качества продукта. Не так давно был случай: до начала квартала оставалось две недели, я присутствовал на ретроспективе одной из команд и услышал следующий диалог между Техническим лидером и Владельцем продуктов (все имена и события вымышлены, любые совпадения случайны): У нас нет задач на следующий квартал. Завтра пришлю. Нам нужно 4 недели на аналитику.  Так квартал уже начнется!  Ничего не знаю, нам нужно 4 недели! ¯_(ツ)_/¯  Каждая команда сама решает как ей вести себя в такой ситуации, но лучше не доводить до нее. На мой взгляд, лучше один раз остановиться, потратить максимум усилий на выстраивание процесса, а потом вкладывать все силы в достижение планов. На поддержание процесса потребуется гораздо меньше трудозатрат. Давать предсказания очень трудно, особенно когда они касаются будущего. Нильс Бор, датский физик Предпосылка: Периодически к ИТ-командам приходят на разработку высокоприоритетные проекты/задачи с фиксированным сроком, и, как правило, у ИТ-команд нет возможности сдвинуть дедлайн для таких задач. Часто реальный дедлайн для таких задач намного позже, чем требует менеджмент (33% ИТ-проектов превышают график (McKinsey).  Чтобы успеть к сроку, команды жертвуют качеством и перерабатывают. Под такие проекты и задачи возникает необходимость сформировать новую команду из уже имеющихся, причем это может происходить, когда обязательства уже взяты. Новые команды изолируют от остальных задач, чтобы их ничего не отвлекало от цели, а старым, в лучшем случае, грозит перепланировать взятые на себя обязательства, утвердить новые и адаптироваться под новую ролевую модель, в худшем — им не дадут такой роскоши и обвинят в проваленных планах. При формировании новых команд никто не учитывает: время на адаптацию созданных и измененных команд, снижение производительности, потраченное время на новое планирование, время на переключение между задачами. Сделать зрелую команду при постоянно меняющихся составах невозможно. В результате: команды никогда не смогут выйти на свою максимальную производительность. Последствия:  плохо проработанная аналитика; сложности при планировании задач и оценки трудозатрат; высокий Time to market; давление на ИТ-команду сроками по задачам; выгорание и демотивация сотрудников; высокие риски для срыва сроков и плохого качества продукта; незрелые команды. Многие из нас сталкивались с проектами с фиксированными сроками. Этот челлендж захватывает, объединяет команду, заставляет бежать всем вместе в одну сторону, но, как правило, все заканчивается выгоранием и хотфиксами. Если не давать перерывов после таких забегов, о долгосрочной эффективности не может быть и речи. Создавайте для себя и своих коллег периоды с меньшей нагрузкой после длительных забегов, потратьте время на ретроспективу и на решение проблем, которые возникли за период марафона. Когда выгоды невозможно оценить количественно, в качестве общего правила считайте, что их нет.  Том Демарко и Тимоти Листер Предпосылка: Отсутствие владельца продукта обычно приводит к тому, что команды встречаются с первой и/или второй описанной ситуацией, но сначала — с нехваткой продуктовых планов. Вроде ничего страшного, и команды начинают заниматься техническим долгом, рефакторингом и всем тем, на что всегда не хватало времени, но в какой-то момент приходит менеджмент и спрашивает: «А чем занимается команда?».  Команда не в состоянии оценить свои результаты и перевести их в ценность для бизнеса. Сотрудников таких команд начинают привлекать в другие команды (см. ситуацию 2) или начинают подкидывать им плохо проработанные продуктовые задачи, ценность которых никто не рассчитал. Вина за недостигнутые бизнес-показатели, которые менеджмент считал реальными, лежит на ИТ- команде, ведь до бизнес-анализа руки ни у кого так и не дошли. В результате: растет недовольство бизнес-подразделениями.  Чтобы реализовать хоть какой-то положительный эффект, в команды закидывают все больше слабо проработанных задач в надежде на то, что какая-то из них сработает. В таких условиях у команды все чаще начинают появляться внеплановые задачи с высоким приоритетом, и они все сильнее страдают от выполняемой работы. Последствия:  команды не понимают для чего выполняют ту или иную работу, и как их результаты влияют на бизнес; высокий Time to market; выгорание и демотивация сотрудников; возрастает недовольство бизнес-подразделениями. Если вы не возьмете на себя роль, в которой нуждается команда, за вас это больше никто не сделает. В свое время я работал и аналитиком, и тестировщиком, и брал часть функций владельца продукта в своей команде, т.к. понимал, что без этих компетенций последствия будут гораздо хуже. Быть или не быть кросс-функциональным специалистом — это отдельная история. На мой взгляд — быть, но не забывать об исправлении сложившейся ситуации, а то так можно и роль сменить. Или еще хуже — решат, что вы и так справляетесь. Все компании рано или поздно сталкиваются с трудностями при планировании: как я писал выше, по информации McKinsey, 33% крупных софтверных проектов превышают сроки, 66% — бюджет. Яндекс, Сбер и Лига Ставок не стали исключениями, мы тоже время от времени сталкиваемся с похожими проблемами. Но тут самое главное — это выбор, который делает каждый из нас видя такие сложности. Вот так выглядит дерево текущей реальности компании, которая не построила у себя процесс планирования и не понимает к каким последствиям приводит такое поведение. Срыв сроков, долгая реализация задач, низкое качество продукта и, как следствие, невыполнение планов по прибыли — с этими проблемами может столкнуться компания, если ничего не предпримет. Корневыми причинами в этом случае являются: несвоевременное предоставление планов, задачи с фиксированным сроком и плохо проработанные задачи.  На данной схеме отображены основные нежелательные явления, связанные с продуктовыми планами, но для полноты картины ее можно дополнитьнехваткой компетенций и ресурсов (человеческих и других), давление на команды, недостаток контроля и обратной связи.  Решение выглядит простым — убрать корневые проблемы. Но найти эти проблемы в своей компании, а тем более устранить — является очень сложной задачей. Страх и сопротивление изменений порой делает данную задачу невыполнимой. Для решения проблем на текущей схеме необходимо: сосредоточиться на управлении стратегией и управлением заинтересованными лицами; внедрить OKR или любой другой метод повышения прозрачности целеполагания; cнизить давление на команды и перестать вбрасывать внеплановые задачи; начать управлять командами, а не сотрудниками; повысить уровень контроля, давать развивающую обратную связь сотрудникам и признавать их заслуги. Это путь, который стоит пройти, чтобы выйти на более высокий уровень сложностей.В Лиге Ставок мы работаем с ролевой моделью и моделью зрелости команд, внедряем метрики эффективности для получения обратной связи о влиянии организационных и технических изменений на команды, выстраиваем наставничество и постоянно развиваем сотрудников. Я вам предлагаю следующий план: осознать необходимости изменений (я надеюсь, это статья помогла вам в этом); выявить желание поддерживать изменения и участвовать в них; собрать знания того, как осуществлять изменения и каким должен быть результат (этим вам предстоит заняться в ближайшее время). ответить на вопросы: зачем нужны изменения? кого они затрагивают? кого из «спонсоров» нужно привлечь для поддержки задуманного? разработать план по внедрению изменений; внедрять изменения день за днем; закрепить изменения. Дерзайте, дорогу осилит идущий.  А как вы решали такие проблемы в своей компании?