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

Руководитель проекта упорно двигается к результату

Быть руководителем проекта (РП) — значит быть 100% нацеленным на результат. Помню, меня в свое время впечатлила фраза моего старшего товарища: «Я вцеплюсь в результат, как бульдог, и не отпущу хватку, пока не достигну его». С тех пор воспитываю в себе этот подход.

Но на практике постоянно возникают какие-то препятствия, о которые неопытные РП спотыкаются и буксуют. Особенно мешает, когда препятствует какая-то мутная, неясная фигня.

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

Лучше всего все опрозрачнивать при помощи моих любимых табличек.

Реестр открытых вопросов — паркуем всю неясную фигню

Открытый вопрос — a.k.a. «issue», «проблема» — это какая-то (сюрприз!) проблема, которая непременно повлияет на проект, если ее не решить.

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

Важно, что это не задача:

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

Приведу пример: ваш тимлид положил заявление на стол. Это проблема. Если с ней что-то не сделать, работа команды будет парализована.

Как руководитель вы можете:

• Пообщаться с тимлидом, попробовать его удержать
• Пообщаться с руководителем, выбить бюджет, чтобы повысить тимлиду зарплату
• Разместить новую вакансию
• Написать знакомым руководителям, нет ли у них подходящих кандидатов

Все это — задачи, и они падают в бэклог команды.

Сам открытый вопрос «Иванов увольняется с такого-то числа» висит в реестре открытых вопросов, вы удерживаете на нем фокус, т. к. на каждой планерке рассматриваете открытые вопросы

Универсальный алгоритм движения вперед

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

1. Формулируем цель
2. Планируем действия по ее достижению
3. Выявляем проблемы, мешающие двигаться вперед
4. Планируем действия по ее устранению. При необходимости — возвращаемся на п.3
5. Повторяем, пока не получили результат

На практике я реализую этот алгоритм, задавая вопросы:

1. Что делаем, какие следующие шаги? (записываем задачи в план)
2. Что мешает? (записываем открытые вопросы)
3. Что делаем с п.2? (записываем задачи в план)

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

Других вариантов нет, только вперед.

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

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

Но вопрос непростой, давайте его разберем.

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

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

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

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

В результате страдает проект: выплывают риски, едут сроки, появляются недовольные стейкхолдеры.

Поэтому первый вывод такой.

Чем сложнее проект, тем меньше на менеджере должно быть исполнительских задач.

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

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

Поэтому вот второй вывод:

Классно, когда РП шарит в предмете, но обычно не критично, если он хорош в менеджменте, а проекты большие.

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

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

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

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

Даже если оценить только эффект по ФОТ, то это дико выгодно. Синьор РП стоит примерно в 3-5 раз дороже администратора проектов.

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

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

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

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

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

Поможет отличный инструмент: календарно-сетевой график проекта, a.k.a. график Гантта.

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

• Заключен договор с подрядчиком.
• Выданы доступы исполнителям.
• Сдан в ОПЭ модуль системы.

За вехи очень полезно поставить ответственными членов команды.

Так разговор из нашего кейса превращается примерно в такой:
— Мне на этой неделе некогда, надо переносить срок по задаче.
— Понял. Ну, что поделать, давайте попробуем… вот незадача, ай-яй-яй. У нас на полторы недели вперед уезжает веха, по которой вы — ответственный и о которой мы докладываем на Управляющем комитете. Давайте придумаем, что будем говорить куратору!
— Не надо, мы переприоритизируем свои задачи.

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

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

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

Мой первый опыт внедрения проектного управления в компании был провальным.

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

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

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

Проектный офис часто «лезет не в свое дело»

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

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

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

Надо четко очертить границы проекта и не лезть в них

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

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

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

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

4. Внутри этих границ вы вольны руководить проектами как бог на душу положит: вы — профессионалы, мы вам доверяем. Не хотите проводить планерки — ваше дело.

Чего я этим добиваюсь?

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

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

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

Учить разумному, доброму, вечному можно только при наличии запроса

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

Например, не выполняется в срок контрольная точка из плана:
«2022-09-13 — Сдан в ОПЭ модуль „Бюджетирование“»
Мы можем 13 сентября сходить в бухгалтерию, и посмотреть своими глазами, сдан модуль в эксплуатацию или нет. И вот уже у нас есть неоспоримый факт: не соблюдена контрольная точка, и разговор проектного офиса становится гораздо конкретнее, и от него так не отмахнешься.
— Не выполнили контрольную точку? Вы должны инициировать процедуру переноса сроков, эскалации и т. д.
— Систематически не выполняются контрольные точки? Вот вам рейтинг руководителей или КПЭ, вы в нем в красной зоне. И вот уже руководителю проектов сложно сказать «я таких проектов сделал сотни, не надо меня учить». Глядишь, он и сам приходит на вебинар по управлению сроками, рисками и т. д.

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

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

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

• Каждый член команды усердно работает над своими задачами, но общий результат оказывается не достигнут.
• Задачи ставятся и теряются, находятся тогда, когда уже поздно.
• Очередной раз «перепрыгнули пропасть на 99%».
• Менеджер чувствует, что проект «разъезжается»: в шквале текучки теряется фокус на результатах и поддерживать его требует огромных усилий.

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

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

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

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

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

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

Регулярные совещания должны охватывать разные горизонты и аспекты управления

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

Также есть разные аспекты, которыми нужно управлять: сроки, закупки, риски, управление персоналом, качество и пр.

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

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

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

Как настроить график совещаний так, чтобы ничего не упускать?

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

1. Регулярность, длительность, участники, роли участников
2. Типовая повестка
3. Материалы, в первую очередь — отчетность, заточенная под повестку
4. Правила подготовки (в виде чек-листов)
5. Правила проведения совещания (Например, как делаем доклад? Как поступаем, если возникла посторонняя тема в обсуждении? Предусмотрено ли вообще обсуждение на встрече?)
6. Правила обработки результатов (ведение протоколов и пр.)

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

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

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

Без «кто, что, когда» никто нихрена не сделает

Я стал руководителем довольно крупного (для меня на тот момент) проекта. У меня в команде два методолога и один эксперт (все трое — старше и опытнее меня). Мы сидим на совещании, посвященном старту работ: обсуждаем концепцию решения, подход к командному взаимодействию, основные задачи. Совещание прошло продуктивно: мы всесторонне обсудили вопросы повестки, вся команда чувствует, что понимает проблему одинаково. Я заканчиваю обсуждение фразой: «Ну, отлично, тогда действуем, как обсудили. До встречи на следующем совещании!».

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

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

Что произошло?

У руководителя проекта ничего не «само собой разумеется»

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

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

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

Так как же дожимать до конкретики?

Это сложно: одна из самых ресурсоемких задач на совещании. Заложите на это время: где-то минут за 10 до окончания часового совещания можно уже начинать, если было много решений.
Мы уже это обсуждали здесь.

Задачи должны быть сформулированы в совершенном виде, т. е. как ответ на вопрос: «Что сделать?», при этом желательно, чтобы при виде формулировки рисовалась в голове картинка.
Например:

❌ «Некорректные чеки!»
✅ «Назначить совещание “Разбор ошибок чеков коррекции”»

❌ «Правила командной работы»
✅ «Выделить 30 минут, набросать предложения по правилам командной работы»

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

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

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

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

Суть очень проста:

1. Настроить реестр, в котором хранятся все поручения менеджмента (или одного менеджера).
2. Настроить средство коммуникации по поручениям. В аутлуке можно слать отчеты по задачам, которые будут обновлять исходную задачу у автора (вы знали об этом?).
3. Обучить сотрудника, который все поручения будет вносить и контролировать по срокам. Обычно — ассистент руководителя.
4. Обучить людей, которые будут исполнять поручения.

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

Очень простой принцип, который позволяет двигать большие дела

Контроль поручений работает так хорошо за счет очень простого принципа:

Задача «попала на карандашик» — «вынь да положь» результат, или обоснуй, почему его нет

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

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

Есть еще один удивительно простой и эффективный принцип, который запускает работу с поручениями в компании:

Нет просроченных поручений

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

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

Ограничения контроля поручений

Благодаря простоте и неотвратимости, система контроля поручений — очень жесткий инструмент. В этом есть плюсы — чувство руля у руководителя, — но и минусы.

Главный минус в том, что это инструмент «ручного управления». У меня был шеф, который так сыпал поручениями, только успевай ловить. Какое счастье, что он потом забывал процентов 70 из них, потому что иначе никто в компании ничем больше и не занимался бы, кроме отработки его поручений!

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

Поэтому используйте контроль поручений мудро и очень дозированно.

Не только контроль поручений

Как выяснилось, на этих простых принципах можно построить очень, очень большую систему.

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

Контрольные точки вносите в реестр и контролируете примерно так же, как поручения. Просрочилась маленькая промежуточная веха — задаем вопрос: «Что случилось? Не нужна ли помощь?».

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

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

Постараюсь в недалеком будущем рассказать кейс, как я настроил такую систему на экселе.

Продолжаем разговор про планирование проекта. Составив в прошлый раз реестр результатов мы определились, какие конкретные результаты будут созданы. Теперь надо наметить путь к ним. Это сложно:

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

И вот здесь хочу поделиться приемом, который не все применяют, а вернее, мало кто: прежде, чем набрасывать список работ, мы разработаем product flow diagram (инструмент из моего любимого PRINCE2, кстати). Не придумал, как это емко перевести на русский язык, приблизительно — диаграмма декомпозиции продукта проекта (помним, как отличаются и чем похожи результаты и продукты проекта). Проще показать на примере.

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

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

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

Помимо того, что это просто красиво, это удобно:

• Позволяет увидеть костяк плана, пока его не завалило отдельными работами. Это гораздо проще обсуждать с ключевыми пользователями. Диаграмму на иллюстрации все еще реально обсудить на одном совещании. План из 200+ работ можно только презентовать, со всеми ограничениями формата.
• Промежуточные продукты — это важные вехи. Можно их использовать для планирования отдельных блоков работ: в крупных проектах их может создавать отдельная команда, а в маленьких они станут ключевыми результатами в операционном плане.
• К промежуточным результатам тоже можно описать требования. Это очень полезно, потому что на этом постоянно происходят срывы: команда разработки ждет от пользователей выгрузку данных текущих систем, выгрузка приходит, но в кривом формате. Проблема. Или команда разработки передает модули в тестирование, а пользователи не знают, с какой стороны к ним подходить: не прописали, что должен быть промежуточный продукт «сценарии тестирования», не заложили в план, не сделали.

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

Диаграмму на картинке я разработал в программе Flying Logic Pro. Программа удобна тем, что автоматически перестраивает диаграмму, чтобы минимизировать пересечения линий, а также позволяет сворачивать и разворачивать целые блоки на схеме. Если вам кажется, что это пустяки, попробуйте разработать схему из сотни блоков, после этого поговорим :) Также она позволяет готовую диаграмму экспортировать в МС Проджект. Правда, она платная, причем довольно сильно платная.

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

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

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

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

Сначала расскажу небольшую историю.

Я руководил большим проектом по изменению деятельности компании в соответствии с требованиями регулятора. Изменения затрагивали многие области: доработка документации по продуктам (сотни документов), изменение и переподписание договоров с партнерами (больше сотни договоров), доработка сайта, офисов компании, нескольких внутренних регламентов + массовое обучение для широких кругов сотрудников.

Работая таким широким фронтом впервые, я столкнулся с тем, что разные направления «разъезжаются»:

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

Анализируя свой опыт я понял, что:

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

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

Сначала — согласовать образ конечного результата

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

Когда я впервые приступаю к заполнению реестра результатов с коллегами, я предлагаю им представить следующую картину: «Вот мы закончили проект. Приходим довольные к руководству и кладем на стол толстую папку с результатами: „Мы сделали“. Что в этой папке?» По опыту, этот вопрос очень помогает начать разговор.

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

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

Реестр результатов должен жить на протяжении всего проекта

Итак, мы описали все результаты проекта. Что теперь с ними делать?

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

Проводить аудит результатов. Очень полезно в ходе проекта задаваться вопросом, насколько мы продвинулись. Для этого можно добавить в реестр столбец «статус». Особенно это полезно делать, если вы консультант: когда вы приходите к заказчику с предложением подписать на следующей неделе акты, это лучший способ спровоцировать волну комментариев и отличных идей по доработке, которых так не хватало, пока вы работали над этим результатом. Аудит готовности позволит начать этот разговор сильно раньше: «Мы считаем, что этот результат готов на 50%». «А мы — что на 15%!».

Опись результатов проекта. У меня была отличная практика: когда на моем проекте работали консультанты, мы каждому результату присвоили уникальный код — типа РН-001П — и договорились о том, что все письма, в которых они нам передают те или иные результаты, будут содержать этот код. Благодаря этому я мог мгновенно найти в почте всю релевантную переписку, а после проекта все результаты лежали в кодированных папочках, а реестр результатов превратился в опись.

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