Что полезного делает ПМ?

Прошло 6 лет с тех пор как я впервые занялся проектным управлением. В начале это была услуга товарищам, которым требовался кто-то контролирующий их работу и общающийся с заказчиком. Со временем это переросло в нечто большее и эта работа стала своего рода испытательным полигоном для идей, которые мне хотелось бы проверить прежде чем начать использовать всерьез. Так что заняв должность TeamLead я уже был достаточно глубоко погружен в сферу управления проектами. Специфика проектов которыми я занимаюсь – внедрение CRM Битрикс24 и автоматизация на ней бизнеса.  За время работы какие только проекты не приходилось выполнять: автоматизации рассылок клиентам, настройка документооборота, автоматизация продаж, обработка клиентов, интеграции с внешними система учета (1С, SAP, Oracle), интеграции с система аналитики (Google, ROIStat) и т.п. Проекты хоть и похожие, но у каждого находится своя уникальность.

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

Главная его работа — нести персональную ответственность за конечный результат!

[sendpulse-form id=”278″]

На каких уровнях работает проект-менеджер?

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

1. Бизнес-цели — вершина пирамиды. Уровень, где формируются конкретные цели бизнеса. Например, «заявка клиента должна быть обработана за 15 минут».
2. Процессный уровень — как построить/перестроить процессы внутри организации, чтобы достичь поставленных бизнес-целей.
3. Прикладной уровень — автоматизация, софт и его архитектура.
4. Уровень инфраструктуры — архитектура ВК, СХД, СУБД, общесистемное ПО.
5. Уровень СПД — архитектура сети передачи данных, включая СКС.
6. Инженерный уровень — электрика, вентиляция, водоснабжение, СКУД, видеонаблюдение, кондиционирование и т. д.
7. Стройка, или «уровень бетона», — какое здание, где, какая разбивка по помещениям и т. д.
8. Безопасность — проходит через все уровни. В нижней части пирамиды — физическая, в верхней — информационная (нормативы, регламенты, политики и т. д.).

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

Например строительство электростанции и разработка софта — кардинально разные проекты. Разная методология управления (PMI, Agile, Scrum…), разная ролевая модель проектной команды, организация коммуникаций, гарантированно разная модель финансирования и т. д. К каждому проекту — свой персональный подход. Универсальных знаний не бывает, но есть универсальность применяемых подходов.

Есть проекты, которые охватывают всего 1 или 2 уровня (например, модернизация корпоративной сети передачи данных, разработка веб-приложения). А есть те, которые покрывают все 7 (например, «Безопасные города»). В них есть и консалтинг, и разработка софта, и строительство зданий с инженерными системами, и, конечно же, ИТ. Такие проекты требуют от ПМа особой подготовки и накопленного опыта. Одной из ключевых задач ПМа на таких проектах всегда остаётся набор ключевых специалистов и правильная организация работы большой команды.

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

Чем управляет ПМ на проекте, чтобы достичь его цели?

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

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

Управление бюджетом (стоимостью)

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

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

Что это: тотальные ошибки планирования, чёткий расчёт и умышленный демпинг или предсмертная агония?!

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

Управление сроками

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

Почему кратчайший путь не всегда является оптимальным?

Например, я могу работать по 12 часов в сутки без выходных и могу склонять к этому всех остальных участников проекта — но они попросту окажутся к этому не готовы, особенно заказчик. Мне нужны доступы на площадку или к системам в определенные часы, а у заказчика на этот счёт есть особая процедура. Нужен даунтайм, а у заказчика это бизнес-критичная система — и он готов дать согласие на отключение, но только в первую субботу месяца в 22:00.

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

Не имеет смысла «разгонять» проект только ради самого факта скорейшего его окончания.

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

Это называется «допущения и ограничения». На старте проекта их больше всего, т. к. степень неопределённости выше.

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

Управление качеством

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

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

Для иллюстрации я привожу такой пример. На заре своей ИТ-карьеры в управлении проектом друг попросил сделать для него сайт. Он пересмотрел миллион сайтов и, как ему казалось, чётко понимал, чего хочет. На заданный вопрос о требованиях он уверенно объявил: красивый, современный, удобный, масштабируемый — и много всего в таком духе. Я послушал и сказал: «Это всё круто. А требования-то какие? Какой движок, какая админка, интеграция с платёжными системами, структура и т. д.?» Естественно, что сразу он ответить не смог — это был мой и его первый опыт. Сейчас я могу не задавать половины вопросов поскольку, прошёл это не один раз и на основе даже отсутвующих данных могу сделать предложение по проекту..

Утрирую, конечно, но с похожими требованиями заказчик часто выходит на конкурс. А на первой встрече выясняется, что хотел он совсем не то, что записал в ТЗ. И если с этим ничего не делать, в конце проекта всех ждёт большой «сюрприз», ругань, долгая и муторная приёмка. Построили по ТЗ, но не так, как хотел заказчик; система работает, но не соответствует его ожиданиям; текущим потребностям соответствует, но не заложен запас на масштабирование, рост, интеграцию. И предъявить собственно нечего: как написано, так и построили. Что с этим делать дальше — никто не знает, особенно когда бюджета на доработку уже нет. Тупик, расстройство, испорченные отношения с заказчиком…

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

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

В проектах с программной разработкой помогают современные и набирающие всё большую популярность методологии Agile, scrum и т. п., подразумевающие глубокую вовлечённость заказчика в проект, а также короткие спринты с показом работающего функционала. Исполнитель с заказчиком находятся в постоянном диалоге в духе «Мы туда идём? Это то, что ты хотел?». Это позволяет всегда двигаться в заданном направлении и минимизировать ошибки. Вопреки расхожему мнению, что тот же agile хорош всегда и везде, просто отмечу, что для военного ОКРа или инженерно-строительного проекта круче классического «водопада» мало что подходит. Так устроена система. У каждой методологии своя область применения. Это не религия, это инструменты, позволяющие эффективно управлять параметрами проекта.

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

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

Управление рисками

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

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

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

1. Организационно-методологические — риски, связанные с организацией работ и областями знаний, которыми управляет ПМ. Зона ответственности ПМа и проектного офиса. Технологические — риски, связанные с разрабатываемой архитектурой решения, применяемыми технологиями и т. д. Зона ответственности архитектора и ключевых технических специалистов команды.
2. Финансовые — всё, что связанно с бухгалтерским учётом, выполнением требований регуляторов, используемыми финансовым моделям и т. д. Зона ответственности бухгалтерии и казначейства.
3. Правовые — риски, связанные с действующим законодательством, нормативными актами, требованиями пунктов договора, правилами согласования с надзорными органами и т. д. Зона ответственности юристов.
4. Специфические риски — обычно это риски, связанные с отраслевой спецификой либо требующие узкоспециализированных знаний. Здесь, в зависимости от проекта, периодически приходится прибегать к помощи сторонних экспертов.

Если оценка произведена качественно, то такого деления обычно достаточно, чтобы избежать наиболее критичных рисков.

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

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

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

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

Профессионализм ПМа

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

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

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