Интересное наблюдение: мы проводим семинары для проектных менеджеров внутри компании и периодически приглашаем туда ключевых технических специалистов — архитекторов, проектировщиков, тим-лидов. Сначала они довольно неохотно приходят, сидят где-то час и внезапно начинают записывать и задавать вопросы. В конце дня может прозвучать что-нибудь вроде: «А я думал, вы бездельники и упыри, а оказывается, у вас тяжёлая и ответственная работа». Такое обучение сильно помогает участникам команды лучше понимать друг друга.
Более 10 лет в разных должностях я занимаюсь проектным управлением. Поработал в четырёх крупных интеграторах и сейчас возглавляю департамент из 100 человек. За время работы какими только проектами не приходилось управлять: внедряли SAP, автоматизировали деятельность предприятий, разрабатывали ИСы для госзаказчиков, проектировали и строили уникальные ЦОДы, делали военные ОКРы, проводили сложные миграции ИС… — даже строили под ключ электростанции в Белоруссии и угольные котельные в п. Черском (2000 км от Якутска). Основной сложностью тогда оказалась доставка оборудования и материалов — река была проходима только 5 месяцев в году. Вылез за дедлайн или просто поймал холодный год — потерял 7 месяцев. Либо дорогущий вертолёт. Все проекты разные, и каждый по-своему уникален.
Твоя команда написала кривой код, уронили сервер на разгрузке, оборудование не пришло вовремя, заказчик задерживает приёмку, техтребования сильно меняются, а сроки и бюджет — нет… Всё это головная боль ПМа, и это только часть его работы.
Но главное — персональная ответственность за конечный результат!
На каких уровнях работает проект-менеджер?
Для простоты понимания я использую упрощённую «технологическую пирамиду». Деление довольно условное, но оно помогает на пальцах объяснить многие сложные вещи.
- Бизнес-цели — вершина пирамиды. Уровень, где формируются конкретные цели бизнеса. Например, «кредит от момента подачи заявки клиентом должен быть одобрен и выдан банком за 15 минут».
- Процессный уровень — как построить/перестроить процессы внутри организации, чтобы достичь поставленных бизнес-целей.
- Прикладной уровень — автоматизация, софт и его архитектура.
- Уровень инфраструктуры — архитектура ВК, СХД, СУБД, общесистемное ПО.
- Уровень СПД — архитектура сети передачи данных, включая СКС.
- Инженерный уровень — электрика, вентиляция, водоснабжение, СКУД, видеонаблюдение, кондиционирование и т. д.
- Стройка, или «уровень бетона», — какое здание, где, какая разбивка по помещениям и т. д.
- Безопасность — проходит через все уровни. В нижней части пирамиды — физическая, в верхней — информационная (нормативы, регламенты, политики и т. д.).
Это модель, по которой с некоторыми допущениями можно разложить абсолютно любой комплексный проект. Управление реализацией на каждом из описанных выше уровнях обладает своей организационной и технологической спецификой, требующей от ПМа определённых навыков и знаний.
Например, строительство электростанции и разработка софта — кардинально разные проекты. Разная методология управления (PMI, Agile, Scrum…), разная ролевая модель проектной команды, организация коммуникаций, гарантированно разная модель финансирования и т. д. К каждому проекту — свой персональный подход. Универсальных знаний не бывает, но есть универсальность применяемых подходов.
Есть проекты, которые охватывают всего 1 или 2 уровня (например, модернизация корпоративной сети передачи данных, разработка небольшого софта). А есть те, которые покрывают все 7 (например, «Безопасные города»). В них есть и консалтинг, и разработка софта, и строительство зданий с инженерными системами, и, конечно же, ИТ. Такие проекты требуют от ПМа особой подготовки и накопленного опыта. Одной из ключевых задач ПМа на таких проектах всегда остаётся набор ключевых специалистов и правильная организация работы большой команды.
Знание специфики и умение ПМа работать на каждом из этих уровней делают его универсальным и определяют степень профессионализма.
Чем управляет ПМ на проекте, чтобы достичь его цели?
Сначала ответ на этот вопрос не вызывает большого труда, и многие быстро вспоминают, что есть бюджет, сроки и качество. Затем, немного поразмыслив, люди вспоминают, что есть команда и риски. На этом фантазия быстро заканчивается. Но основной ступор наступает, когда просишь описать: «А как вы это делаете? Как этим всем управляете?»
Как показывает практика, даже самые, казалось бы, простые категории проектного управления, которые мы часто используем в быту, вызывают трудности не только у ключевых членов проектной команды, но и у самих ПМов.
Управление бюджетом (стоимостью)
Как сказал классик, «любую проблему можно решить при наличии достаточного количества денег и времени». Отчасти это действительно так, но в условиях современного рынка появляются нюансы. Рынок сжимается, бюджеты заказчиков урезаются, конкуренция растёт… В борьбе за выживание рынок заставляет ИТ-компании действовать агрессивно, участвовать в проектах, которые ранее считались зоной повышенного риска, например, когда в компании нет достаточного опыта и ресурсов.
Всё чаще можно встретить ситуации, когда на конкурс приходит конкурент, никогда не являвшийся экспертом в подобных проектах, и даёт цену ниже или близкую к твоей себестоимости!
Что это: тотальные ошибки планирования, чёткий расчёт и умышленный демпинг или предсмертная агония?!
Роль ПМа и группы управления на пресейле резко возросла. Качественная работа на данном этапе — это половина успеха проекта. Чётко определить себестоимость и оптимизировать затраты, оценить доступность ресурсов и наличие необходимых компетенций, правильно выбрать стратегию реализации и разработать финансовую модель сделки, оценить риски и запас финансовой прочности на случай конкурсной борьбы — и всё это за короткий промежуток времени. Организовать такую подготовку в сжатые сроки крайне непросто, но это основная задача ПМа на этапе пресейла, чтобы дальнейшая реализация была успешной.
Управление сроками
Начало проекта — самая высокая точка неопределённости. Дойти до конца можно разными путями, но задача РП — выбрать оптимальный маршрут и темп движения. Нюансов, которые нужно учесть по дороге, очень много.
Почему кратчайший путь не всегда является оптимальным?
Например, я могу работать по 12 часов в сутки без выходных и могу склонять к этому всех остальных участников проекта — но они попросту окажутся к этому не готовы, особенно заказчик. Мне нужны доступы на площадку или к системам в определённые часы, а у заказчика на этот счёт есть особая процедура. Нужен даунтайм, а у заказчика это бизнес-критичная система — и он готов дать согласие на отключение, но только в первую субботу месяца в 22:00.
Вообще, довольно часто заказчик оказывается не готов к выбранному темпу исполнителя. Все потому, что реализация проекта для специалистов заказчика часто является не основной функциональной деятельностью, а дополнительной нагрузкой по поручению руководства. Обсуждать техтребования, анализировать документацию, тестировать код, производить необходимые настройки системы быстрее, чем ему позволяет основная деятельность, заказчик не сможет. А если вам даже и удастся заставить его это сделать, то негатива и ошибок просто не избежать. А ещё есть нюансы в работе подрядчиков и вендоров. Но самое сложное и непредсказуемое — это взаимодействие с госорганами, особенно это касается силовиков и регуляторов. Заставить их оперативно работать просто невозможно, да и на ваш проект им чаще всего по барабану. Но это отдельная история, здесь есть свои нюансы, о них не в этой статье :).
Не имеет смысла «разгонять» проект только ради самого факта скорейшего его окончания.
Угробите свою команду, выделите много «тепла» и испортите отношения с заказчиком.
Всё это называется «допущения и ограничения». На старте проекта их больше всего, т. к. степень неопределённости выше.
А ещё план работ — величина живая, а сам процесс творческий. Где-то не уложились в сроки, поставка не пришла вовремя, ошиблись в выборе решения, заказчик поменял требования — всё это требует пересмотра календарного плана и бюджета проекта.
Управление качеством
Один из параметров, вызывающий больше всего споров в профессиональном сообществе. С одной стороны, всё выглядит довольно просто: качество — это соответствие заданным параметрам/требованиям. Когда есть техзадание и все требования закрыты, можно считать реализацию качественной. Но так ли это?
А что делать, когда на первой встрече с заказчиком вы вдруг обнаружили, что его ожидания сильно отличаются от того, что вы ему собрались реализовать? А вообще, требования и ожидания — это одно и то же? И почему они вдруг стали разными: хочет одно, требует другое? Я часто задаю эти вопросы на собеседованиях, и, как ни странно, на них плавают даже опытные ПМы. Вдвойне огорчает, когда перед тобой ПМ, руководящий разработкой.
Для иллюстрации на тренингах я привожу такой пример. На заре своей ИТ-карьеры я делал веб-сайт для супруги. Нашёл дизайнера/разработчика, пересмотрел миллион сайтов и, как мне казалось, чётко понимал, чего я хочу. На заданный вопрос о требованиях уверенно объявил: красивый, современный, удобный, масштабируемый — и много всего в таком духе. Разработчик послушал и сказал: «Это всё круто. А требования-то какие? Какой движок, какая админка, интеграция с платёжными системами, структура и т. д.?» Естественно, тогда я ответить не смог — это был мой первый опыт и первый сайт. Сейчас могу, но лишь потому, что прошёл это не один раз.
Утрирую, конечно, но с похожими требованиями заказчик часто выходит на конкурс. А на первой встрече выясняется, что хотел он совсем не то, что записал в ТЗ. И если с этим ничего не делать, в конце проекта всех ждёт большой «сюрприз», ругань, долгая и муторная приёмка. Построили по ТЗ, но не так, как хотел заказчик; система работает, но не соответствует его ожиданиям; текущим потребностям соответствует, но не заложен запас на масштабирование, рост, интеграцию. И предъявить собственно нечего: как написано, так и построили. Что с этим делать дальше — никто не знает, особенно когда бюджета на доработку уже нет. Тупик, расстройство, испорченные отношения с заказчиком…
Опытный ПМ знает, как работать с такими ситуациями. Они чаще всего возникают в верхней части пирамиды, особенно когда заказчик внедряет что-то впервые либо создаёт продукт, о разрабатываемых характеристиках которого пока нет фитбэка пользователей.
Одна из основных задач ПМа в таких проектах — сделать так, чтобы ожидания и требования сошлись по ходу проекта.
В проектах с программной разработкой помогают современные и набирающие всё большую популярность методологии Agile, scrum и т. п., подразумевающие глубокую вовлечённость заказчика в проект, а также короткие спринты с показом работающего функционала. Исполнитель с заказчиком находятся в постоянном диалоге в духе «Мы туда идём? Это то, что ты хотел?». Это позволяет всегда двигаться в заданном направлении и минимизировать ошибки. Вопреки расхожему мнению, что тот же agile хорош всегда и везде, просто отмечу, что для военного ОКРа или инженерно-строительного проекта круче классического «водопада» мало что подходит. Так устроена система. У каждой методологии своя область применения. Это не религия, это инструменты, позволяющие эффективно управлять параметрами проекта.
К примеру, когда требования на проекте не достаточно детальны (их трактовка допускает большую вариативность) или их уточнение подразумевается по ходу реализации проекта, то «прототипирующие и спринтовые» методы очень хороши.
Когда требования чётко определены, есть жёсткие требования регуляторов и контрольно-надзорных органов по этапности реализации, реализация подразумевает использование ГОСТов и нормативно-правовых документов — хорошо работают классические модели, такие как «водопад».
Управление рисками
С рисками тоже всё совсем не просто. Несмотря на то, что по управлению рисками написано множество книг и статей, управлять ими эффективно — задача отнюдь не тривиальная. По сути, мы пытаемся прогнозировать и оценивать события, которые носят исключительно вероятностный характер и конкретно в твоём проекте вообще могут никогда не произойти. А их нужно выявить, классифицировать, дать качественную и количественную оценку, разработать стратегию реагирования, контролировать, пересматривать…
На самом деле это сложный и многогранный процесс, в котором участия одного только ПМа явно недостаточно, приходится звать на помощь коллег. Несмотря на то, что одних только категорий и подкатегорий классификации рисков различные методологии предлагают бесчисленное множество, на практике большинство компаний используют наиболее понятные и простые для оценки. Редко где среди ИТ-компаний процесс управления рисками выведен на принципиально другой — продвинутый — уровень.
В оценке рисков обычно принимают участие ключевые участники проектной команды и привлечённые ПМом службы компании. Обычно на практике разделение выглядит примерно так:
- Организационно-методологические — риски, связанные с организацией работ и областями знаний, которыми управляет ПМ. Зона ответственности ПМа и проектного офиса. Технологические — риски, связанные с разрабатываемой архитектурой решения, применяемыми технологиями и т. д. Зона ответственности архитектора и ключевых технических специалистов команды.
- Финансовые — всё, что связанно с бухгалтерским учётом, выполнением требований регуляторов, используемыми финансовым моделям и т. д. Зона ответственности бухгалтерии и казначейства.
- Правовые — риски, связанные с действующим законодательством, нормативными актами, требованиями пунктов договора, правилами согласования с надзорными органами и т. д. Зона ответственности юристов.
- Специфические риски — обычно это риски, связанные с отраслевой спецификой либо требующие узкоспециализированных знаний. Здесь, в зависимости от проекта, периодически приходится прибегать к помощи сторонних экспертов.
Если оценка произведена качественно, то такого деления обычно достаточно, чтобы избежать наиболее критичных рисков.
Проще всего с рисками, о которых мы знаем заранее. Именно знаем, т. к. часть из них лежит на поверхности, а по части есть накопленный опыт из ранее реализованных проектов. Их обычно называют «известные риски». Такие риски просто анализировать и можно заранее спланировать ответные действия (стратегию реагирования). Сложнее, когда проект, например, реализуется впервые. Накопленного опыта нет, а своих компетенций не всегда достаточно. В таких проектах о наличии некоторых рисков мы даже можем не догадываться, а если и предполагаем их наличие, то не в состоянии оценить корректно. В таких ситуациях спасает только резерв на непредвиденные расходы и экспертная оценка команды.
«Задача максимум» при управлении рисками — сделать так, чтобы не наступило ни одно событие, которое может негативно сказаться на целях и показателях вашего проекта. Но это практически невозможно. Часть рисков всегда будет по отношению к вам внешними, а ваше влияние на них крайне ограниченным. И чем больше и сложнее проект, тем больше вероятность наступления одного из таких событий. Поэтому основной задачей ПМа будет минимизация последствий от их наступления.
Управление рисками — это непрерывный процесс на протяжении всего проекта. Большая ошибка, когда он стартует одновременно с самим проектом. Время на оценку и «место для манёвра» при этом резко снижаются. Я видел ситуации, когда ошибки планирования и сработавшие риски не только сжирали маржу проекта, но и топили проект вместе с компанией. Правильно начинать этот процесс на стадии глубокого пресейла, заблаговременно до принятия решения о вхождении в проект. Это особенно актуально в текущей рыночной ситуации, о которой я писал выше, когда компания входит в новые, незнакомые проекты с жёсткими требованиями заказчиков и регуляторов. Результатом пресейловой оценки рисков в таких проектах может быть решение группы управления вообще не идти в этот конкурс.
Такое решение внутри любой компании даётся всегда непросто, т. к. внутри команды происходит внутренний конфликт интересов. Это та самая грань, когда «жадность» сейлз-подразделений борется с консерватизмом и «боязнью» производства. В компаниях со зрелым менеджментом и бизнес-процессами такой конфликт даже полезен, т. к. истина в данном споре всегда оказывается где-то посередине. Главное в таких спорах — наличие арбитра, чтобы в случаях жарких дебатов не перейти черту, когда взвешенный и осознанный риск превращается в авантюризм и лотерею.
Профессионализм ПМа
К сожалению, многие искренне уверены, что профессионализм ПМа измеряется количеством времени, проведённым в профессии. Я считаю иначе: опыт, знания и умения. Чем их больше — тем профессиональнее ПМ. Практический опыт, накопленный в реальных «боевых» проектах, бесценен и является конкурентным преимуществом. Конечно, от ошибок никто не застрахован, но, как говорят в народе, «за одного битого двух не битых дают». Собрав своим лбом все грабли на своём огороде, вряд ли наступишь на них снова.
Выбирая ПМа на конкретный проект, я обращаю внимание на несколько параметров и пользуюсь всё той же «технологической пирамидой». Например, если надо построить здание и завести туда инженерку — я отдам предпочтение опытному строителю, а если провести модернизацию ИТ — бывалому инфраструктурщику. Знание технологической и отраслевой специфики, подрядчиков, подводных камней, наработанная команда помогают избежать лишних ошибок, сэкономить бюджет и время.
К себе в команду я стараюсь брать максимально универсальных и самостоятельных ПМов. Умеющих эффективно работать на всех уровнях пирамиды, а также в условиях высокой неопределённости. Большое внимание приходится уделять личностным качествам ПМа и его внутренней мотивации. Важно, чтобы человек быстро влился в коллектив, освоился и был «комфортным» для команды. Хорошие специалисты на рынке — большой дефицит.
Если интересно — задавайте вопросы, с удовольствием на них отвечу. Постараюсь на примерах конкретных проектов рассказать про разные нестандартные ситуации и как мы из них выкручивались.
Текст подготовлен Юрием Корчуковым, проджект-менеджером и заместителем директора центра инженерных компетенций "Техносерв".
