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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • ¯_(ツ)_/¯ 

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

Источник: yandex.ru
Источник: yandex.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: youtube.com
Источник: youtube.com

Ситуация 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. закрепить изменения.

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

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

Комментарии (12)


  1. lookid
    28.12.2021 20:59

    Вся проблема в том, что бизнес обычно довольно агрессивный в корпоративном сегменте. И диктует порой идиотские решения и задачи, которые нужны прямо сейчас. Это такая плата за рост, зряплату и бонусы. Все работают ради бонусов. Особенно менеджмент. Которому начальство говорит, что нужно деливерить по 500 задач в год с отдела. А какие... сами придумайте. Имитация деливери и велью ради отчетности перед акционерами. 60% задач и 80% начальства можно былоб вообще не нанимать и не делать. Но важен оборот, отчетность и количество закрытых тасок.


    1. vasaushev Автор
      28.12.2021 21:42

      Согласен, есть и такие компании. Я надеюсь, что у нас все-таки не так, а те изменения, которые происходят в нашей компании, принесут пользу. Последние из них - ориентация и ответственность продуктовых команд за бизнес-показатели, теперь они напрямую влияют на бизнес и могут оценить свой вклад.


    1. DikSoft
      30.12.2021 16:09
      +1

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

      А может он потому и дорос до корпоративного размера и остается в нём, что был "агрессивным" и не позволял себя водить за нос новомодными типа методологиями? )


      1. vasaushev Автор
        31.12.2021 10:13

        Agile и продуктовому подходу в ИТ уже 30 лет, сложно их назвать новомодными, учитывая, что первый ПК всего лишь на 10 лет старше :)

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


  1. lxsmkv
    28.12.2021 21:55

    Расскажете как проводить анализ для построения Эффект-Диаграммы? Откуда берутся формулировки этих эффектов? Это обобщенные "жалобы"? Как их выясняют? Через личное интервью с участниками цепочки? Через рассмотрение записей из ретроспектив команд? Или каким-то другим способом?

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


    1. vasaushev Автор
      29.12.2021 10:49
      +1

      Узнал о инструменте после прочтения книги Элияху Голдратт. Цель-2. Дело не в везении.

      Для построения Дерева текущей реальности я использовал материалы статьи: https://vc.ru/hr/81710-instrukciya-kak-stroit-derevo-tekushchey-realnosti-dlya-resheniya-biznes-problem

      У меня, как у agile coach, есть доступ ко многим командам и ретроспективам, мы проводили исследования и интервью. Когда в компании работаешь 4 года, знания накапливаются в голове, остается их только оформить с помощью какого-либо инструмента.

      Что может помочь собрать нежелательные явления:

      • Ретроспективы. От чего сильно бомбит команду или проблемы, которые не решаются на постоянной основе;

      • 1t1 с сотрудниками из компании. Доверительные отношения в командах дает больше информации о проблемах;

      • Инетрвью/исследования. С другими Agile коучами проводили исследования на уровне всей компании мидл менеджмента.

      Я советую прочитать Цель-2, тогда можно быстро погрузиться и узнать из бизнес-романа о данном и других инструментах.

      P.S. Книги Голдратта одни из самых любимых и многие из них читаются на одном дыхании.


  1. OlegZH
    28.12.2021 22:37

    На показанной диаграмме, самый интересный момент — первый квадратик: "В работу поступают проекты с фиксированным сроком". Можно было бы ожидать, что к моменту получения заказа, имеется набор вариантов реализации с указанием важнейших свойств и спроков выполнения. У заказчика будет возможность самому выбрать один из возможных вариантов. А у разработчиков для каждого варианта будет готовый план реализации проекта.


    1. vasaushev Автор
      29.12.2021 10:57
      +1

      К сожалению, задачи с фиксированным сроком обычно появляются как снег на голову.

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

      Решение: подключать команду на этапе discovery для проработки проектов. Мы только начинаем это делать.


  1. DikSoft
    29.12.2021 06:34
    +1

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


    1. vasaushev Автор
      30.12.2021 15:56

      @DikSoft А какой подход лучше использовать? И в чем его преимущества?


      1. DikSoft
        30.12.2021 16:07
        +1

        По поводу внутренней разработки я солидарен с позицией описанной в этой статье. Если ИТ не Ваш основной бизнес, то "Продукт" и все пляски вокруг скорее всего будут худшим выбором. Оптимальнее, как мне кажется, брать конкретные задачи и закрывать их Проектным подходом.


  1. burdukale
    30.12.2021 20:13
    +1

    Статья хорошая, только не затрагивает коренную проблему описанных здесь кейсов: мне видится, что проблема не в отсутствии эффективного продуктового планирования (как бы не резала слух сама фраза), а в отсутствии единой ценностной модели принятия управленческих решений. Наверху: мне нужны деньги завтра. Где-то на середине: чтобы деньги были завтра пусть все работают на деньги. Внизу PO: команда наляпает много фичей, какая-то выстрелит и возможно принесет деньги. Отсюда: чем больше гипотез - тем хуже детализация; гипотеза выстрелит когда-то (в следующем квартале скорее нет - эффект накопительный), нет очевидной связи со сроком начала оценки (отсюда нет привязки к кварталам); главное больше гипотез - поэтому члены команд лишь ресурс, если людей считать лишь за ресурс - формализм в работе и необходимость dead line со стороны РО или иных стейкхолдеров.

    Как должно быть - можно погуглить, kanban maturity model может натолкнуть на интересные мысли. Но agile прородители сказали лаконичнее: люди важнее процессов. Иначе "продуктовая революция" через силу и для галочки будет выглядеть как-то так: