Менеджер проекта с ТЗ в руках — это ещё не признак управления проектом

— Привет! Ну ты как, кто, где? — давно не виделись.
— Да я менеджер ИТ-проекта в большой компании.
— О, PRINCE, риски, экстремальное управление, финансы. Сложно!
— Да не. Так, ТЗ от клиента технарям и обратно таскаю за деньги. Фигня.

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

^[1]
Типичный прожект менеджер, который не очень понимает, что такое управление проектами

В феврале 2007 года в Нижнем Новгороде проходила конференция по управлению проектами. Тогда это была супер крутая и инновационная тема. Несколько сотен представителей крупного бизнеса, предпринимателей, депутатов, научных работников и студентов обсуждали существующие на тот момент практики управления проектами и механизмы бизнес-процессов. Признаться честно, выглядело всё это совершенно безбожно: иностранные компании и отечественные промышленные гиганты рассказывали о том, как они управляют проектами в своих компаниях и призывали перенять их опыт. Перед ними сидели растерянные представители малого бизнеса и понимали, что там одни системы автоматизации стоят миллионы долларов, не говоря уже об обучении, менторах, внедрении. Казалось, это будущее, которое за горами. В том далёком начале 2007 года наша RegionSoft CRM ^[2] только начинала свой путь, а участниками конференции были двое будущих наших сотрудников, тогда ещё студенты, ничего не слышавшие о нашей компании. И никто не знал, что в августе 2018 года выйдет релиз нашей CRM-системы RegionSoft CRM 7.0 ^[2], а мы напишем на Хабр (которому на тот момент не было и года) статью о том, что управление проектами доступно всем.

Не верите? Зря. На самом деле, в бизнесе всё есть процесс и всё есть проект. Стоит только немного заморочиться.

Осторожно! Статья написана профессиональными разработчиками и может содержать определённую долю сарказма и нелюбви к РМ.

На самом деле нет, мы их любим

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

• Бизнес не знает, что такое проект. По сути, это ничего сложного: цели, задачи, бюджет, риски, распределение ресурсов, отчётность. Но какие-то компоненты постоянно игнорируются: то бюджет выходит за рамки (а это ошибка планирования), то задачи пересекаются, накладываются и делают работу одних сотрудников невыносимой, а других — халявой. Из-за этого под угрозой находится весь проект, что бьёт прежде всего по интересам заказчика (внутреннего или внешнего — без разницы).
• В управлении проектами постоянно забывают о рисках. А они есть всегда, от обыденных и легко прогнозируемых (нехватка ресурсов, косяки поставщиков, болезнь сотрудника) до совершенно внезапных, которые всегда нужно учитывать (сезонность, экономическая ситуация в мире, работа с валютой, законодательный риск). Безусловно, возникновение риска ставит под удар весь проект. Поэтому оценка риска должна быть проактивной, а не реактивной — то есть происходить до того, как песец решил вас посетить. Если проект длинный, переоценка рисков должна осуществляться каждые 2-3 месяца жизни проекта.
• Бизнес увлекается методологией и забывает о сути работы, теряя время на формальности. Особенно этим грешат крупные компании и, как ни странно, стартапы. Причём причины у них разные: стартапы стремятся соответствовать моде и обязательно фиксировать факт управления по PRINCE или PMBOK, а в крупных компаниях (особенно не работающих по ISO) всегда есть коты, которые, как известно, когда нечего делать, яйца лижут сотрудники, которым необходимо продемонстрировать свою важность и приверженность стандартам. Нередко в погоне за правильной организацией документации, митингов, этапов и т.д. теряется быстрое и качественное выполнение работы.
• Менеджеры проектов (именуемые project manager) — весьма неопределённая категория работников. Более-менее неплохо дела обстоят в ИТ, где большинство (но, увы, не все) проджектов растут изнутри, из среды разработчиков. Но горе ИТ-компании, если менеджером технического проекта становится гуманитарий или выпускник «Менеджмента». Нет, это не плохие ребята, и вероятно, они прочитали много толстых книжек (включая многочисленные источники «мотивации»), но ИТ слишком специфическая отрасль для того, чтобы проектами управляли люди без технического бэкграунда (уверены, что с нами будут спорить — и хорошо, если есть истории успеха). Что касается других сфер, то в них менеджерами проектов берут людей без должного опыта, но, например, с релевантным образованием или резюме, в котором можно наврать с три короба. В общем, отбор должен быть более критичным, а ещё лучше — из внутренних резервов.
• В работе с проектами учитываются задачи и ресурсы только одной стороны. У любого проекта есть холдер (исполнитель) и заказчик, который ждёт результата исполнения проекта. Чаще всего весь проект нацелен на интересы заказчика, которые нужно исполнить любой ценой, реже — исходит исключительно из ресурсов исполнителя (внутренние проекты). При правильном управлении проектами должны быть учтены интересы всех участников, действия должны быть согласованными.
• Страх перед руководством загоняет проект в кризисную ситуацию. Часто сотрудники боятся сообщить о реальном положении дел, информировать о срыве сроков или перерасходе бюджета. В конечном итоге проект может быть выполнен с низким качеством или же погрузиться в полностью безнадёжное состояние. В свою очередь у руководителя в такой ситуации может не быть инструмента контроля и мониторинга проекта.
• Работа менеджера проекта не измерима или плохо измерима, а он сам всеми силами пытается выйти из-под KPI (например, утверждая, что проект — это эксклюзивная работа, которую нельзя измерять) и уйти в сторону премий по итогам (разовые). Такой подход снижает ответственность менеджера за проект и «размазывает» её по другим участникам.
• У проектов часто не устанавливаются границы — расплывчатое понимание масштаба проекта может легко превратить его в долгострой.
• Внутренние проблемы проекта и проблемы коммуникации. Изначально менеджер проекта — это лидер и одновременно проводник-коммуникатор, задача которого среди прочих координировать и направлять команду. Но случается так, что менеджер считает себя единолично правым, ставит себя выше команды и игнорирует предложения и даже целые пласты работы, занимаясь микроменеджментом и стремясь закрыть собой все задачи. Команда в прямом смысле слова постепенно учится молчать. Конечно, проектная работа, даже во главе с самым гениальным менеджером, не тот случай, где один в поле воин.

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

• Увы, как и в любой деятельности, в проектной работе почти всегда есть место принципу Парето: 20% команды по факту выполняют 80% работы. Конечно, можно смириться с этим положением вещей, но лучше стимулировать работу и получить более эффективную команду.

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

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

project = time + cost + scope

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

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

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

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

Границы проекта — это не только оценка его масштаба, но и строгое следование требованиям заказчика и, конечно, техническому заданию и паспорту проекта. Техническое задание — это фактически броня исполнителя, потому что можно всегда сослаться на описанные объёмы работ и ограничения. Чтобы ТЗ было успешным, необходимо тщательно собрать требования, разбить их по этапам проекта и согласовать техзадание. Будет идеально, если вы оговорите и зафиксируете не только то, что будет сделано, но и то, что сделано не будет.

Ещё один важный вопрос: какое программное обеспечение подходит для управления проектами?

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

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

Ещё один тип программ — это CRM, BPM и другой софт с встроенными механизмами управления проектами. Поэтому мы встроили модуль управления проектами в редакцию RegionSoft CRM Enterprise ^[3]. В ходе разработки у нас были дополнительные ограничения (точнее, наоборот, требования к расширению) — модуль управления проектами находится внутри нашей RegionSoft CRM, а значит, должны быть дополнительные связи. Помешают ли они задачам управления проектами? Нет, конечно — связь с клиентами и другими сущностями пойдёт только на благо пользователю:

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

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

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

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

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

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

Конечно, мы не собираемся покрыть тему управления проектами одной обзорной статьёй — будут более детальные материалы, в частности о менеджерах проектов, о методологиях и об отдельных аспектах управления. Но и затягивать с проблематикой не хочется. Поэтому мы сформулировали несколько правил управления проектами, которые доступны и адресованы прежде всего малому и среднему бизнесу — то есть как раз тем, ради кого ведёт разработку RegionSoft ^[2] и чьи боли он знает как никакие другие.

joyreactor.cc

• Соблюдайте главную триаду ограничений сферы управления проектами: сроки, стоимость, границы. Таким образом бизнес (и команда!) будет управляться более качественно и прозрачно. Даже чисто психологически марш-бросок в виде проекта воспринимается позитивнее, чем вечная рутина: когда ты знаешь сроки и видишь свет в конце тоннеля, ну то есть окончание задачи, работается не в пример легче.
• Не бойтесь стартовать одновременно несколько проектов — грамотное распределение задач и ресурсов даст вам выигрыш во времени и в конечном итоге компания сможет работать быстрее и с высоким качеством.
• Лошадь сдохла — слезь. Если проект разваливается, границы и сроки давно пробиты, не тяните его на себе и не пытайтесь скакать дальше, проанализируйте причины и проблемы и перезапустите задачи. Бывает, что все проблемы кроются в таких вещах как, например, слишком громоздкий проект — достаточно его разбить на несколько небольших и параллельных подпроектов и дело полетит.
• Собирайте отчёты, проводите ретроспективы и анализируйте проблемы, достижения и откровенные факапы. Таким образом, вы сможете избежать проблем в будущем. Если решение оказалось успешным, не оставляйте его одним лишь поводом для командного поедания пиццы с пивом, разберитесь в причинах успеха и смело внедряйте находки в жизнь.
• Не промахнитесь с менеджером проекта (чаще всего с этого все беды и начинаются). Менеджер проекта это не человек с какими-то требованиями к образованию (типа «Менеджмент», красный диплом) и не хороший презентатор, а человек, который разбирается в теме проекта и должен организовать систему, в которой всё отлажено, проще говоря, каждый процесс даёт выход, который служит входом для следующего процесса. В этом, конечно, кроется и коммуникация, и делегирование, и умение работать в команде.
• Управляйте изменениями — если в проекте появляется что-то новое, обязательно обработайте событие, не отстраняйтесь и не отказывайтесь от изменений. Опять же, всё в рамках триады: стоимость, сроки, границы.
• Проект должен быть реальным — по задачам, которые он решает, и для исполнения. Если у вас есть 200 тыс. рублей и нет дополнительных источников финансирования, глупо затевать строительство десятиэтажного дома — не хватит даже на котлован. Обязательно оцените соответствие имеющихся ресурсов задачам проекта.
• Определите, насколько экономически эффективен и/или целесообразен проект. Вот где кладбище погибших стартапов — именно в неумении просчитать эффективность. Можно запустить производство электромобиля из дерева или приложение для подсчёта убитых комаров, но это будет проект ради проекта, об экономике нет и речи. Оцените реального заказчика или будущий объём рынка перед тем, как стартовать проект. Кстати, нонкоммерсов это тоже касается — к примеру, благотворительность и меценатство тоже могут оказаться бесполезными, но отожрать массу ресурсов.
• Планируйте загрузку с определённым горизонтом — так вы сможете понять, кто чем занимается и какие ресурсы уже задействованы и будут задействованы в дальнейшем. Например, для этих задач можно использовать групповые планировщики, встроенные в систему управления проектами или CRM (ну или диаграмму Гантта).
• Управляйте документацией — все документы проекта должны быть собраны воедино и содержать исчерпывающую информацию о каждом этапе, платеже, требованиях и т.д.
• Не тоните в методологии (например, вы считаете, что право на существование имеет только водопадная модель или только Agile), а лучше выбирайте лучшее, комбинируйте и делайте так, чтобы методология была вашим инструментом, а не вы её рабом и заложником.
• Не забудьте закрыть проект. Совет кажется смешным, но только для того, кто с проектами не работал. Не допускайте частично незавершённых проектов, долгостроев и остановок в одном шаге от финала. Впрочем, закрыть проект — это реально сложно.

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

Вы же не хотите получить зарплату имитацией денег?