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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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