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

Практически каждый раз, внедряя систему проектного управления в очередной компании, мы начинаем с того, что заказчик предлагает нам «сократить бюрократию», обойтись минимумом документов, и испытывает чувство вины, заставляя своих коллег заполнять уставы, реестры результатов, запросы на изменения и прочие чудесные документы. Да что там, я сам начал именно с этого: с чувства вины за «бюрократизацию» и стремления минимизировать количество бумажек.

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

Документ как чек-лист

Давайте для начала посмотрим на содержание какого-нибудь управленческого документа проекта.

Кстати, «управленческий документ» означает документ, который используется для управления проектом. Например, нужен, чтобы зафиксировать, кто за что отвечает в процессе управления, или результаты проекта. А бывают еще документы, которые разрабатываются для других целей: инструкции к системе, регламенты, договоры с подрядчиками и пр.

Возьмем, например, кусочек документа под названием «стратегия коммуникации».

Что мы видим? Таблица, в которой надо заполнить все ячейки по принципу «природа не терпит пустоты». При этом важно не только и не столько то, что мы их заполнили, а то, что мы обо всем этом подумали.

И вот здесь как раз кроется первый ключ к пониманию того, что собой представляет «бюрократия здорового человека». Заполнить управленческий документ означает подумать обо всем, о чем надо подумать. То есть, вы можете воспринимать документ как своего рода чек-лист, чтобы ничего не забыть.

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

Вот недавно мы как раз смотрели документ, в котором «зачем нужен проект» описано в одном поле, и выяснили, что руководитель проекта описал массу показателей, но забыл описать собственно проблему, на решение которой нацелен проект. Упс.

Договориться и зафиксировать договоренности

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

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

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

Ничего не потерять

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

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

Как сделать так, чтобы бюрократия не превращалась в бюрократизм?

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

Так вот, первое правило: детализация должна соответствовать сложности проекта.

Другой важный момент заключается в том, что каждое поле должно использоваться. Помню, мой наставник по проектному управлению, который помогал мне сделать первые шаги в качестве руководителя проектного офиса, сказал: «Если какую-то информацию ты не используешь, ты не имеешь права ее запрашивать!». Этой максимой я с тех пор и руководствуюсь. К сожалению, понимание, что потребуется, а что — лишнее, нарабатывается в основном с опытом.

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

Очень часто, когда я занимаюсь с командами планированием проекта — в качестве руководителя проекта или «играющего тренера», — возникает проблема с планированием сроков. Дескать, как можно прогнозировать какой-то срок по проекту, когда непонятно, что делать? С другой стороны, мы же не можем поставить в плане «ХЗ пока».

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

Так как же быть?

Два вида сроков

В этой ситуации я всегда сначала объясняю, что на самом деле существует два вида сроков:

«Когда можем» — это технологически и ресурсно обусловленный срок. Мы понимаем, что нужно сделать и какие ресурсы доступны. Это позволяет нам сказать: окей, мы выполним эту работу к такому-то числу.

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

Мне рассказывали про одного члена Правления банка, который говорил: «Не можете сказать срок? Тогда я вам скажу срок!».

Начинаем «крупными мазками»

Второй нюанс заключается в том, что проект можно планировать, постепенно повышая точность. Более того, в моем любимом PRINCE2 (британская методология управления проектами) это вообще способ по умолчанию. В других источниках это называется «метод набегающей волны».

Вы планируете весь проект «крупными мазками», приблизительно. Набрасываете основные этапы, даты, когда нужно получить ключевые результаты. Можно пользоваться достаточно грубыми предпосылками.

А вот ближайший этап вы планируете уже тщательно. При этом не забываете добавить в этап работы по планированию следующего этапа и уточнению плана всего проекта.

Срок — это принятие обязательств «со звездочкой»

Если вы работали в гос.органах или в гос.компаниях, возможно вы сейчас подумали: «Ага, я скажу предварительный срок, а мне потом его „пришьют“. Нет уж, спасибо!». Действительно, такое бывает. Здесь уже надо включать мастерство управления ожиданиями заинтересованных сторон.

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

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

Сроки — не самое важное

К сожалению, есть руководители, которых не устраивает ни один из этих вариантов, считающие, что если сильно надавить, можно «впихнуть невпихуемое». Обычно это приводит к «выпихиванию ранее впихнутого», и, если заказчик сильно давит, это происходит в скрытом режиме и приводит к тому, что рвется что-то совсем в другом, неожиданном месте.

Конечно, бежать к четким срокам чаще всего правильно: это позволяет не перерасходовать ресурсы, держать в тонусе команду и заказчиков, быстрее получать бизнес-результаты. Но это далеко не всегда так.

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

Поэтому гораздо более полезным критерием успешности проекта является «счастливый заказчик». Заказчик обычно счастлив, если результаты проекта принесли ту ценность, ради которой он задумывался, при этом соблюдается приемлемое соотношение «вэлью фо мани».

Ну и, конечно, важно помнить, что счастье заказчика = результаты — ожидания заказчика.

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

У всех разное понимание того, что такое «цель»

Для начала расскажу случай из практики.

Мы запускаем портфель проектов по организационным изменениям в компании: есть стратегия СЕО, все подразделения готовят проекты. Я отвечаю за то, чтобы в каждом из проектов было корректно сформулировано, какие цели он преследует, каким образом и пр.

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

Так продолжалось довольно долго (слишком долго). В какой-то мы обсуждаем с шефом эту проблему, и выясняется, что мы никак не можем договориться о том, что собой представляют цели проекта (в ту пору я много спорил с шефом). В какой-то момент ему пришла в голову идея нарисовать на доске схему, что мы понимаем под «целью», и выяснилось, что я понимаю под целями проекта то, что будет создано в рамках проекта, а он — то, ради чего проект в принципе делается, и что может выходить далеко за рамки проекта.

Это был первый раз, когда я понял, что «цели» — очень, очень размытый термин, но с тех пор я убеждался в этом неоднократно. Правда я не сразу разобрался, как с этим быть.

Так как же быть?

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

1. Продукт проекта. Это то, что непосредственно создается в ходе проекта. Какие-то физические объекты или материалы в электронном виде. Например, если мы разрабатываем новую версию сайта, продуктом проекта будут скорее всего элементы сайта (в зависимости от того, как нам удобнее управлять): отдельные страницы, онлайн-калькулятор, форма заказа — то есть, те элементы, которые мы можем разработать и передать в эксплуатацию цельными кусками. Или, например, выкинуть из проекта (хотя бы в теории).
2. Результаты проекта. Это изменение каких-то показателей, которое произошло благодаря сайту. Например, увеличение просмотров страниц (по сравнению со старым сайтом), показов рекламы, скорости регистрации/покупки — то есть, улучшение процесса, которое произошло благодаря применению продукта проекта.
3. Выгоды проекта. Это измеримое улучшение бизнес-показателей, которое произошло благодаря результатам проекта. Выгоды чаще всего про деньги: прибыль, выручка, сокращение издержек. Иногда — увеличение доли рынка или иных показателей. В чем разница с результатами? Выгоды — это то, ради чего компания делает проект. Просмотры страниц вы «на хлеб не намажете»: обычно заказчик ожидает, что благодаря просмотрам вырастут какие-то финансовые показатели. Даже если вы делаете сайт-визитку, его тоже лучше привязывать к каким-то значимым и измеримым бизнес-показателям. Иногда это сделать сложно, но важно пытаться и задавать себе этот вопрос.

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

Обратите внимание: в описанной схеме нет такого понятия как «цели проекта». Потому что «выгоды», «результаты» и «продукт» гораздо точнее и позволяют определить, что и ради чего мы делаем.

Знаю, что различие между этими терминами тяжело заходит, поэтому давайте на закрепление еще один пример. Проект «Внедрение CRM системы» (это система, где продавцы работают и ведут информацию о всех клиентах):

• Продукт: сама CRM система. Для удобства управления мы скорее всего поделим ее на модули: ключевой функционал, интеграция с соцсетями, интеграция с АТС и т. п.
• Результат: увеличилось количество звонков, увеличилось количество коммерческих встреч на продавца.
• Выгоды: увеличилась выручка компании.

P.S.: А «Цели и задачи» вообще приехали из наших студенческих времен, когда мы писали курсовые. «Задачи» в проектном управлении есть, но означает совсем другое: в принципе то, что делается в рамках проекта, и «задач» могут быть сотни и тысячи. Точно не подходит для целеполагания всего проекта.

P.P.S.: Предупреждаю: множество лучших умов в области проектной методологии сломали десятки копий над русскоязычной терминологией в этом вопросе. Я привел свою версию, но на всякий случай приведу английскую, с которой таких вопросов нет: output (продукт), outcome (результат), benefits (выгоды).

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

Задача

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

Решение

Настраиваю форму для заполнения ответственными:

В столбцы таблицы — стадия разработки комплекта документации, строками — комплекты документации. На пересечении — статус «1» = «в работе», «2» = «готово», «3» = «Проблема!». Для «3» необходимо заполнить комментарий, незаполненный комментарий подсвечивается красным.
В скрытых столбцах с начальником управления проставили оценочные трудозатраты по каждой из стадий разработки.

На основе данных из первой таблицы строится аналитический свод:

Суммирую показатели с формы для заполнения. «∆» отражает разницу между текущим и предыдущим периодом (предыдущий период заполняется вручную из прошлого отчета методом «контрол ц, контрол в»).

Для оценки объема трудозатрат перемножаю незаконченные стадии на трудозатраты, суммирую в совокупные человекочасы. Сопоставляю три сценария, отличающиеся объемом выделения ресурсов: «Если мы выделим на это 100% трех человек, когда мы закончим?» Текущий прогноз сравнивается с утвержденным планом, считается отклонение в днях. То есть, когда-то мы оценили, что закончим пятого июня. По мере того, как мы продвигаемся, мы видим, как изменяется эта оценка. Это позволяет нам заметить, что мы начинаем отставать от графика. Это, в свою очередь, может свидетельствовать о том, что мы выделяем недостаточно ресурсов.

Процесс

Раз в неделю прошу ответственных заполнить информацию о статусе разработки документации. Заполнение занимает пару минут.
Копирую данные из предыдущего отчета для расчета отклонения («∆»).
Скриншот отчета отправляю руководству с комментариями, если что-то необычное.

Результаты

Благодаря этой эксельке мы могли вести аргументированный разговор «на фактах»:

1. Добавить или урезать ресурсы на работу.
2. Почему прогресс отличается от ожидаемого.
3. Когда мы закончим с этой задачей.
4. Почему буксуют те или иные отдельные работы.

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

Я поставил встречу с коллегой заранее. В день встречи приходит ответ на встречу «под вопросом» без дополнительных комментариев.

Пишу письмо: «Чувак, когда будешь знать точно? Встреча с внешним участником, надо его сориентировать».

Коллега: «Знаю точно, встречу переносим». Опять без дополнительных комментариев, при этом календарь в аутлуке он нормально не ведет, и мне приходится ему еще писать, затем звонить, отрывать от работы, договариваться о встрече.

Что происходит? Коллега, разумеется, в запаре, и пишет мне письмо на айфоне левой пяткой, сидя на другом совещании, но ведь он таким образом создает себе лишний головняк на пустом месте. Сэкономил 20 секунд, получил еще два письма, лишний созвон, потратил мое время.

Вместо этого он мог написать в сообщении об отмене встречи: «Вася, сегодня отбой, сорри. Предлагаю завтра до 11 или после 16 ч.». Все!

Кто-то может сказать: «Да ладно, Вася, это же всего лишь 20 секунд против двух минут». К сожалению, когда мы это умножаем на количество писем в день, получается уже неплохо. А если мы к этому добавляем задачи, которые не сделаны (не сделаны вовремя), потому что было неясно, чего хотят от исполнителя, то масштабы проблемы подрастают. На уровне корпоративной культуры это вообще приобретает характер стихийного бедствия.

Чтобы избегать таких ситуаций, надо каждое сообщение оценивать:

1. Чего я хочу от респондента? Любая коммуникация (любая!!!) имеет своей целью кого-то к чему-то побудить, даже информационная рассылка.
2. Сможет ли респондент предпринять конкретные действия на основе моего письма? Если нет, ваше письмо будет либо проигнорировано, либо вам будут задавать дополнительные вопросы. Конечно, даже идеально составленное алгоритмическое письмо может быть проигнорировано, но мутное письмо требует гораздо большей мотивации получателя, чтобы его прочли.

П.2 на практике проще сказать, чем сделать. По моим наблюдениям, «конкретность» требует большого навыка. Попробуйте для тренировки визуализировать, что конкретно человек пойдет делать после получения письма: вот он встал и пошел куда-то, что-то сказал, получил какой-то ответ, пришел обратно, написал вам.

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

Задача

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

Решение

Разрабатываю форму для заполнения ответственными департаментами:

В столбцы таблицы — необходимые действия, строками — партнеров. На пересечении — статус «1» = «в работе», «2» = «готово», «3» = «Проблема!», «—» = «не применимо». Для «3» и «—» необходимо заполнить комментарий. В общей сложности, три формы для заполнения тремя ответственными на трех листах.

Пилю аналитический свод:

Суммирую показатели с трех форм для заполнения по каждому из направлений работы. Из суммы вычитаются статусы «—».
∆ отражает разницу между текущим и предыдущим периодом (предыдущий период заполняется вручную из прошлого отчета методом «контрол ц, контрол в»). Благодаря этому видно, какой был прогресс за прошедший период, кто — молодец, а кто нифига не делал.

Итоговый процесс:

Формы для заполнения рассылаются ответственным раз в период. Заполнение непосредственно формы в экселе занимает у ответственного пару минут, не считая сбора информации о статусе (но в этом отчасти и была цель опроса).
Полученные данные вставляются в итоговую таблицу методом «контрол ц, контрол в», заодно уточняются детали.
Скриншот обновленного отчета отправляется руководству в почте.

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

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

Стадия «Синхронизация» — целеполагание встречи

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

Во-первых, участники могли уже позабыть, о чем вообще речь. Даже если вы отлично подготовили совещание, у них могло две минуты назад кончиться другое, и погрузить их в контекст будет просто человечно.

Во-вторых, вы даете шанс участникам внести предложения по содержанию обсуждения. Это важно не только для того, чтобы повестка была актуальна для всех, но и для того, чтобы дополнительно легитимировать ее (сейчас расскажу подробнее).

Также на данной стадии полезно договориться о формате обсуждения. Что это будет: свободная дискуссия? Стикеры в Миро? Высказывание позиции по очереди, затем дискуссия? Если вы предложили формат и все согласились, это очень поможет вам в дальнейшем модерировать дискуссию.

Еще на «синхронизации» могут быть вводные доклады, например, описание проблемной ситуации, предыстории и пр.

Стадия «Расхождение» — максимальная свобода в рамках повестки

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

Если вы чувствуете, что дискуссия идет конкретно не туда, хорошо подходят мягкие техники фасилитации, типа «шесть шляп мышления» Де Боно (кстати, слышал про нее давно, а попробовал применять только недавно — и не пожалел).

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

Стадия «Схождение» — концентрация смыслов и ценности

Где-то немного за середину совещания пора закруглять дискуссию и фокусировать участников на целях встречи. Здесь полезно сделать промежуточное резюме: что обсудили, какие выявили противоречия, какие основные идеи.

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

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

— Коллеги, позволю себе вклиниться на правах модератора. — Если это стандартное рабочее совещание. Если это высокопоставленные участники, то я сначала прошу реплику, буквально в этой формулировке: «Прошу реплику» — лучше всего работает.

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

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

Может статься, что вы действительно набрели на совещании на какую-то убер-важную тему, и она окажется важнее первоначальной темы совещания. Тогда можно отправиться «по этой дорожке». Если вы не согласны так просто отказываться от первоначальной темы, сделайте попытку ее отстоять, пользуясь конфликтной стратегией: «Чтобы двинуться вперед по проекту, надо принять решение сегодня, если не сегодня, то еще не скоро, а это просрочка» и т. д.

Стадия «Резюме» — главный тест проджекта на профпригодность

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

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

Очень помогает техника онлайн протоколирования, которую я недавно описывал. Формулировки, до которых вы дожимаете, как правило должны быть предельно конкретны: кто, что и когда делает, какой результат получает. Чем визуальнее удастся обрисовать этот результат, тем лучше.

Плохо:

Обсудили, что <проблема> серьезная, и надо привлечь Иванова к решению.

Хорошо:

Петров: Встретиться с Ивановым, обсудить <проблему>. Результат обсуждения: тезисы для эскалации на Правление. Тезисы нужны к 15.12.2021

Важно: дожим до такого уровня конкретики может занять уйму времени и энергии. Бывает физически тяжело. Можно зарезервировать на этот процесс до 10 минут от часового совещания. Зато сразу после совещания вы выйдете с готовым, согласованным протоколом, а ваш проект двинется дальше.

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

Бизнес-критичность — это степень влияния данной задачи или требования на функционал целевой системы. Можно выделить следующие уровни бизнес-критичности.

1. Blocker — эта задача стоит на пути у других задач. Например, если вы разрабатываете онлайн магазин, то запилить движок, на котором вы размещаете товары, будет блокером.
2. Сritical — без этой задачи системой невозможно пользоваться. Совсем. Для онлайн магазина кнопка «купить» скорее всего будет критичным функционалом.
3. Major — без этой задачи систему можно запускать, но польза сильно пострадает. В примере с онлайн магазином, это, наверное, «корзина». То есть, купить товар можно, но только по одной штучке со страницы товара. Очень неудобно.
4. Minor — без этой задачи функционал можно запускать. Польза страдает, но не сильно. В примере с онлайн магазином это может быть функционал сравнения товаров.
5. Trivial — это «бантики». Пожелания, которые не влияют на бизнес-функционал. В нашем онлайн-магазине это может быть функционал смены темы в зависимости от национальных праздников. Прикольно, конечно, но можно спокойно пережить.

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

Бизнес-критичность помогает резать скоуп

Случай из практики. Я руковожу проектом, который мне передали на доделку по «джентльменскому соглашению», и скоуп уже трещит по швам. Значительная часть функционала работает кривовато, багов куча, фиче-риквестов тоже навалом. «Сходимость бэклога» не наблюдается — т. е. пополнение бэклога идет быстрее, чем опустошение, или как минимум поровну.

Я провожу сессию целеполагания с заказчиком: какие бизнес-результаты мы хотим получить с применением системы. Выделяем несколько целевых сценариев, которые позволят заказчику «забить гол» и выполнить ключевые задачи, для которых нужна система.

Затем все задачи в бэклоге мы классифицируем по бизнес-критичности относительно целевых сценариев.

После этого говорим: «Дорогой заказчик, мы очень хотим принести вам пользу, поэтому мы подписали с вами „джентльменское соглашение“. Но наши ресурсы ограничены, поэтому мы сделаем для вас все задачи критикал и мэйджор, а остальные, сорри, когда вы у нас докупите работ».

Так я сократил объем бэклога примерно на 30%.

Обсуждение бизнес-критичности гораздо конкретнее, чем просто «мы хотим красненького добавить». Причем это работает не только в отношении софтовых проектов, но и в любых других ситуациях, где вам приезжают требования, которые вы исполняете. То есть, практически везде.

Да, и не путайте с приоритетом

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

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

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

Для тех, кто не такой прожженый, рассказываю с начала.

Технология простая и очень полезная, но ее можно даже улучшить при помощи пары лайфхаков

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

В протокол можно писать только задачи, решения (решение это: «Решили отныне действовать таким-то образом») и открытые вопросы (что-то непонятное, надо разбираться). Если вы быстро печатаете — можно более подробно: кто что сказал, принципиальные тезисы и т. п.

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

Хозяйке на заметку:

Заведите специальный гуглдок или иной текстовый инструмент для совместной работы и ведите все протоколы в нем. Ссылку разошлите всем участникам (можно вставить в повторяющуюся встречу в аутлуке). Каждый новый протокол обозначайте как заголовок: «2021-11-26 — планерка», тогда у вас сформируется удобное оглавление.

Также благодаря этому удобно разделить обязанности прямо на совещании: руководитель проекта как председатель идет по повестке и модерирует, секретарь совещания в это время пишет в гуглдоке. Наступает момент согласования, РП открывает и может сам что-то быстро дописать/подкорректировать в том же документе.

Очевидные бонусы:

1. Протокол готов сразу на совещании, не надо потом после совещания тратить время на написание протокола или фачить эту важную задачу с неизбежным чувством вины и рисками для проекта.
2. Что еще важнее, протокол согласован сразу на совещании. Нет войны правок в почте, никто не скажет: «Ой, сорян, у меня столько писем, могло что-то затеряться», не надо ни за кем бегать, и задачки из протокола могут мгновенно переехать в таск-трекер.

Неочевидные бонусы: скрытая фасилитация

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

Дело в том, что наш внутренний диалог устроен таким образом, что внутри головы мы не всегда додумываем мысли до конца (прочитал у Л. Выготского в книге «Мысль и слово»). Даже в устной речи, особенно в пылу мозгового штурма, это может проявляться в том, что человек многое оставляет как «само собой разумеющееся». Письменная речь организована иначе: вы вынуждены построить семантически корректное предложение.

И вот фасилитатор (то есть, вы), прося людей сформулировать что-то ему под запись, заставляет додумать мысль.

Другой прием фасилитации, уже не такой скрытой, заключается в том, что, зафиксировав какую-то мысль, вы можете к ней больше не возвращаться. Особенно мешают в дискуссии открытые вопросы, которые уводят в сторону от основной повестки. Их нужно «парковать» и переносить на конец совещания или на другую встречу.

В общем, отличная технология, странно, что так редко встречаю ее применение.

Да, кстати, подписывайтесь на меня в Телеге: последняя площадка, на которой вы сами решаете, какой контент читать.

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

Отчетность в стиле «как мы провели прошлую неделю» работает очень ограниченно

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

За эту неделю закончили разработку модуля Х.
Пилотирование модуля задерживается из-за проблем на стороне департамента А. Они загружены отчетностью и не могут приступить к тестированию. Обещают на этой неделе начать.
На следующей неделе планируем пройти тестирование модуля Х.
Также приступаем к разработке бэкенд функционала для модуля Y.

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

Но можно ли из этого отчета сделать уверенные выводы о том,

1. Успеваем ли мы к важному дедлайну, вроде окончания этапа, проекта, старту продаж?
2. На что влияет задержка тестирования модуля Х? Задержка на неделю — это много или мало?
3. Насколько серьезные проблемы у проекта, надо ли руководителю вмешиваться?

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

Если у спонсора один-два-три проекта, с этим еще можно жить: все-таки память у него хорошая. Но можно ли так курировать десять, двадцать, пятьдесят проектов? Нет.

Каким же критериям должна соответствовать отчетность, лишенная этих проблем?

Отчет показывает прогресс, прогноз и отклонение

Прогресс надо показывать через соотнесение плановых, прогнозных и фактических значений. Пример:

Ранее мы договаривались, что разработка модуля Y должна закончиться к 30-му ноября. Это план.
Сегодня менеджер понимает, что команда успевает только к 6-му декабря. Это прогноз.
Модуль Х был разработан 16 ноября. Это — факт. А план был — 1 ноября.

Теперь мы видим следующую картину:

Разработка модуля Х. Готово. План: 01.11. Факт: 16.11
Тестирование модуля Х. В работе. План: 19.11. Прогноз: 26.11
Разработка модуля Y. В работе. План: 30.11. Прогноз: 06.12

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

Отчет подсказывает, куда смотреть и не жрет «мыслетопливо»

Давайте ка для лучшей читабельности зафигачим это в эксельку и добавим в отчет такой показатель, как ∆ (дельта): разница между прогнозом и планом.

Стало лучше? Красные циферки прямо «прыгают в глаза».

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

Если мы представим, что у нас не один менеджер, а пять, и у каждого по три-пять-десять задач, или календарный план больше 1000 задач, то на планерке вы это никогда не обсудите. Зато вы можете обсудить только те, где ∆ больше 5 дней, например. Таких задач будет всего несколько штук.

Я проделывал такой фокус, когда настраивал планерку своего шефа в одной компании. Совещание департамента, которое длилось по полтора часа, стало проходить 15 минут, когда мы сфокусировали его на отклонениях.

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

Новые перспективы открывает календарно-сетевой график. Если работы в плане связаны с другими и, уезжая вправо по линии времени, толкают своих последователей, то мы можем заметить, что задержка тестирования модуля Х приведет к сдвигу опытно-промышленной эксплуатации (ОПЭ), а это уже живые деньги, которые мы могли бы заработать, начав применять систему. А если речь идет о запуске продаж? Олимпиады? Там даже один день просрочки — это очень дорогой провал.

Отчет помогает принять решение

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

В частности, непонятно, как реагировать на выявленные отклонения. Что, если все эти модули нам понадобятся только в марте, когда будет разработана система, с которой нам предстоит интегрироваться? До тех пор +/- пара недель нас вообще не очень волнуют.

Чтобы отчетность помогала принять решение, надо добавить контекст и комментарии или иные сигналы от менеджера, помогающие понять его мнение о причинах проблем и необходимых решениях.

Давайте добавим к нашему отчету индикатор «критичность» (заполняет менеджер проекта вручную) и комментарий.

Вот это уже другое дело. Тут можно понять: здесь — есть отклонение, но менеджер справляется, а тут — нужно повышенное внимание.

Отчетность должна быть полна, а не «тут отчитываемся, тут — забыл»

Чтобы быть уверенными, что мы ничего не пропускаем, надо убедиться, что отчетность формируется по четким правилам и по всем объектам, которыми мы управляем. Это отдельная большая история, для краткости сосредоточимся на маст-хэв любой проектной отчетности:

1. Календарный план.
2. Поручения.
3. Проблемы/открытые вопросы. Очень полезный инструмент менеджера проекта. Когда-нибудь напишу о нем отдельно. Если в двух словах, то это какая-то ситуация или вопрос, с которой нужно что-то делать, иначе будет плохо. Например, уволился разработчик — это проблема. Связанные задачи: «Написать бриф вакансии и отравить в эйчар», «Обзвонить своих знакомых разработчиков» и т. п.
4. Риски. В отличие от проблемы, это какая-то вероятностная штука, т. е. не факт еще, что произойдет. Например, «В январе может выйти новый ФЗ, который изменит требования к нашей системе, что увеличит объем работ». Добавлю, что идентифицировать риски и управлять ими довольно сложно, поэтому это продвинутый уровень РП.

Оставляю за скобками бюджет: финансовая отчетность — отдельная тема.

Принципы отчетности для всех этих объектов похожие: попал объект в реестр? Будь любезен, отчитайся. Например:

Все поручения попадают в реестр поручений и ответственные отчитываются по ним, только если просят перенос срока (или каждую неделю, что сделано, вне зависимости от сроков).

Или:

Менеджер пишет комментарий по тем работам календарного плана, где есть отклонение более 5 дней.

Вот, во что превращается наша секси-экселька.

Уже не очень секси, хотите сказать? Посмотрели бы вы на БДДС или БДР у финансистов. С любой отчетностью надо учиться работать. Но за счет того, что она единообразна, подсвечивает отклонения и компактна, вы довольно быстро к ней привыкнете, и сможете например, читать с листа А4 отчет о состоянии портфеля из 50 проектов.

Отчет должен быть многоуровневым

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

1. Руководитель проекта смотрит все работы календарного плана, все поручения и т. д.
2. Спонсор/куратор смотрит только важные вехи календарного плана: старт ОПЭ, сдача функционала, заключение контрактов, ключевые риски, отклонения по бюджету.
3. Топ-руководство в составе Проектного комитета интересует только когда результаты проекта начнут приносить пользу компании (генерить прибыль), поэтому им важны только окончания этапов и проекта в целом, а также сводные индикаторы по бюджету и рискам.

В сводном отчете по портфелю каждому проекту может быть посвящена вот такая строка:

Все индикаторы, из которых она состоит, собираются из предыдущих секси-табличек, которые я показывал.

Отчет формируем по графику, а не «когда есть, что показать»

Это не самая интуитивная мысль, но очень важная: отчетность должна формироваться по графику. Потому что если мы идем по дорожке «ну, что мы будем руководство беспокоить по таким мелочам, ничего же особого не произошло», то скоро возникает вопрос: кто оценивает, что же такого «особого» должно произойти, чтобы показать руководству? Не факт, что исполнитель или менеджер правильно этот момент определит.

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

Как сделать, чтобы это заработало?

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

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

Да, кстати, подписывайтесь на меня в Телеге, если еще не. Пишу туда довольно регулярно про проектное управление, управление собственной продуктивностью и лидерство.