Интересное наблюдение: мы проводим семинары для проектных менеджеров внутри компании и периодически приглашаем туда ключевых технических специалистов — архитекторов, проектировщиков, тим-лидов. Сначала они довольно неохотно приходят, сидят где-то час и внезапно начинают записывать и задавать вопросы. В конце дня может прозвучать что-нибудь вроде: «А я думал, вы бездельники и упыри, а оказывается, у вас тяжёлая и ответственная работа». Такое обучение сильно помогает участникам команды лучше понимать друг друга.
Более 10 лет в разных должностях я занимаюсь проектным управлением. Поработал в четырёх крупных интеграторах и сейчас возглавляю департамент из 100 человек. За время работы какими только проектами не приходилось управлять: внедряли SAP, автоматизировали деятельность предприятий, разрабатывали ИСы для госзаказчиков, проектировали и строили уникальные ЦОДы, делали военные ОКРы, проводили сложные миграции ИС… — даже строили под ключ электростанции в Белоруссии и угольные котельные в п. Черском (2000 км от Якутска). Основной сложностью тогда оказалась доставка оборудования и материалов — река была проходима только 5 месяцев в году. Вылез за дедлайн или просто поймал холодный год — потерял 7 месяцев. Либо дорогущий вертолёт. Все проекты разные, и каждый по-своему уникален.
Твоя команда написала кривой код, уронили сервер на разгрузке, оборудование не пришло вовремя, заказчик задерживает приёмку, техтребования сильно меняются, а сроки и бюджет — нет… Всё это головная боль ПМа, и это только часть его работы.
Но главное — персональная ответственность за конечный результат!
На каких уровнях работает проект-менеджер?
Для простоты понимания я использую упрощённую «технологическую пирамиду». Деление довольно условное, но оно помогает на пальцах объяснить многие сложные вещи.
- Бизнес-цели — вершина пирамиды. Уровень, где формируются конкретные цели бизнеса. Например, «кредит от момента подачи заявки клиентом должен быть одобрен и выдан банком за 15 минут».
- Процессный уровень — как построить/перестроить процессы внутри организации, чтобы достичь поставленных бизнес-целей.
- Прикладной уровень — автоматизация, софт и его архитектура.
- Уровень инфраструктуры — архитектура ВК, СХД, СУБД, общесистемное ПО.
- Уровень СПД — архитектура сети передачи данных, включая СКС.
- Инженерный уровень — электрика, вентиляция, водоснабжение, СКУД, видеонаблюдение, кондиционирование и т. д.
- Стройка, или «уровень бетона», — какое здание, где, какая разбивка по помещениям и т. д.
- Безопасность — проходит через все уровни. В нижней части пирамиды — физическая, в верхней — информационная (нормативы, регламенты, политики и т. д.).
Это модель, по которой с некоторыми допущениями можно разложить абсолютно любой комплексный проект. Управление реализацией на каждом из описанных выше уровнях обладает своей организационной и технологической спецификой, требующей от ПМа определённых навыков и знаний.
Например, строительство электростанции и разработка софта — кардинально разные проекты. Разная методология управления (PMI, Agile, Scrum…), разная ролевая модель проектной команды, организация коммуникаций, гарантированно разная модель финансирования и т. д. К каждому проекту — свой персональный подход. Универсальных знаний не бывает, но есть универсальность применяемых подходов.
Есть проекты, которые охватывают всего 1 или 2 уровня (например, модернизация корпоративной сети передачи данных, разработка небольшого софта). А есть те, которые покрывают все 7 (например, «Безопасные города»). В них есть и консалтинг, и разработка софта, и строительство зданий с инженерными системами, и, конечно же, ИТ. Такие проекты требуют от ПМа особой подготовки и накопленного опыта. Одной из ключевых задач ПМа на таких проектах всегда остаётся набор ключевых специалистов и правильная организация работы большой команды.
Знание специфики и умение ПМа работать на каждом из этих уровней делают его универсальным и определяют степень профессионализма.
Чем управляет ПМ на проекте, чтобы достичь его цели?
Сначала ответ на этот вопрос не вызывает большого труда, и многие быстро вспоминают, что есть бюджет, сроки и качество. Затем, немного поразмыслив, люди вспоминают, что есть команда и риски. На этом фантазия быстро заканчивается. Но основной ступор наступает, когда просишь описать: «А как вы это делаете? Как этим всем управляете?»
Как показывает практика, даже самые, казалось бы, простые категории проектного управления, которые мы часто используем в быту, вызывают трудности не только у ключевых членов проектной команды, но и у самих ПМов.
Управление бюджетом (стоимостью)
Как сказал классик, «любую проблему можно решить при наличии достаточного количества денег и времени». Отчасти это действительно так, но в условиях современного рынка появляются нюансы. Рынок сжимается, бюджеты заказчиков урезаются, конкуренция растёт… В борьбе за выживание рынок заставляет ИТ-компании действовать агрессивно, участвовать в проектах, которые ранее считались зоной повышенного риска, например, когда в компании нет достаточного опыта и ресурсов.
Всё чаще можно встретить ситуации, когда на конкурс приходит конкурент, никогда не являвшийся экспертом в подобных проектах, и даёт цену ниже или близкую к твоей себестоимости!
Что это: тотальные ошибки планирования, чёткий расчёт и умышленный демпинг или предсмертная агония?!
Роль ПМа и группы управления на пресейле резко возросла. Качественная работа на данном этапе — это половина успеха проекта. Чётко определить себестоимость и оптимизировать затраты, оценить доступность ресурсов и наличие необходимых компетенций, правильно выбрать стратегию реализации и разработать финансовую модель сделки, оценить риски и запас финансовой прочности на случай конкурсной борьбы — и всё это за короткий промежуток времени. Организовать такую подготовку в сжатые сроки крайне непросто, но это основная задача ПМа на этапе пресейла, чтобы дальнейшая реализация была успешной.
Управление сроками
Начало проекта — самая высокая точка неопределённости. Дойти до конца можно разными путями, но задача РП — выбрать оптимальный маршрут и темп движения. Нюансов, которые нужно учесть по дороге, очень много.
Почему кратчайший путь не всегда является оптимальным?
Например, я могу работать по 12 часов в сутки без выходных и могу склонять к этому всех остальных участников проекта — но они попросту окажутся к этому не готовы, особенно заказчик. Мне нужны доступы на площадку или к системам в определённые часы, а у заказчика на этот счёт есть особая процедура. Нужен даунтайм, а у заказчика это бизнес-критичная система — и он готов дать согласие на отключение, но только в первую субботу месяца в 22:00.
Вообще, довольно часто заказчик оказывается не готов к выбранному темпу исполнителя. Все потому, что реализация проекта для специалистов заказчика часто является не основной функциональной деятельностью, а дополнительной нагрузкой по поручению руководства. Обсуждать техтребования, анализировать документацию, тестировать код, производить необходимые настройки системы быстрее, чем ему позволяет основная деятельность, заказчик не сможет. А если вам даже и удастся заставить его это сделать, то негатива и ошибок просто не избежать. А ещё есть нюансы в работе подрядчиков и вендоров. Но самое сложное и непредсказуемое — это взаимодействие с госорганами, особенно это касается силовиков и регуляторов. Заставить их оперативно работать просто невозможно, да и на ваш проект им чаще всего по барабану. Но это отдельная история, здесь есть свои нюансы, о них не в этой статье :).
Не имеет смысла «разгонять» проект только ради самого факта скорейшего его окончания.
Угробите свою команду, выделите много «тепла» и испортите отношения с заказчиком.
Всё это называется «допущения и ограничения». На старте проекта их больше всего, т. к. степень неопределённости выше.
А ещё план работ — величина живая, а сам процесс творческий. Где-то не уложились в сроки, поставка не пришла вовремя, ошиблись в выборе решения, заказчик поменял требования — всё это требует пересмотра календарного плана и бюджета проекта.
Управление качеством
Один из параметров, вызывающий больше всего споров в профессиональном сообществе. С одной стороны, всё выглядит довольно просто: качество — это соответствие заданным параметрам/требованиям. Когда есть техзадание и все требования закрыты, можно считать реализацию качественной. Но так ли это?
А что делать, когда на первой встрече с заказчиком вы вдруг обнаружили, что его ожидания сильно отличаются от того, что вы ему собрались реализовать? А вообще, требования и ожидания — это одно и то же? И почему они вдруг стали разными: хочет одно, требует другое? Я часто задаю эти вопросы на собеседованиях, и, как ни странно, на них плавают даже опытные ПМы. Вдвойне огорчает, когда перед тобой ПМ, руководящий разработкой.
Для иллюстрации на тренингах я привожу такой пример. На заре своей ИТ-карьеры я делал веб-сайт для супруги. Нашёл дизайнера/разработчика, пересмотрел миллион сайтов и, как мне казалось, чётко понимал, чего я хочу. На заданный вопрос о требованиях уверенно объявил: красивый, современный, удобный, масштабируемый — и много всего в таком духе. Разработчик послушал и сказал: «Это всё круто. А требования-то какие? Какой движок, какая админка, интеграция с платёжными системами, структура и т. д.?» Естественно, тогда я ответить не смог — это был мой первый опыт и первый сайт. Сейчас могу, но лишь потому, что прошёл это не один раз.
Утрирую, конечно, но с похожими требованиями заказчик часто выходит на конкурс. А на первой встрече выясняется, что хотел он совсем не то, что записал в ТЗ. И если с этим ничего не делать, в конце проекта всех ждёт большой «сюрприз», ругань, долгая и муторная приёмка. Построили по ТЗ, но не так, как хотел заказчик; система работает, но не соответствует его ожиданиям; текущим потребностям соответствует, но не заложен запас на масштабирование, рост, интеграцию. И предъявить собственно нечего: как написано, так и построили. Что с этим делать дальше — никто не знает, особенно когда бюджета на доработку уже нет. Тупик, расстройство, испорченные отношения с заказчиком…
Опытный ПМ знает, как работать с такими ситуациями. Они чаще всего возникают в верхней части пирамиды, особенно когда заказчик внедряет что-то впервые либо создаёт продукт, о разрабатываемых характеристиках которого пока нет фитбэка пользователей.
Одна из основных задач ПМа в таких проектах — сделать так, чтобы ожидания и требования сошлись по ходу проекта.
В проектах с программной разработкой помогают современные и набирающие всё большую популярность методологии Agile, scrum и т. п., подразумевающие глубокую вовлечённость заказчика в проект, а также короткие спринты с показом работающего функционала. Исполнитель с заказчиком находятся в постоянном диалоге в духе «Мы туда идём? Это то, что ты хотел?». Это позволяет всегда двигаться в заданном направлении и минимизировать ошибки. Вопреки расхожему мнению, что тот же agile хорош всегда и везде, просто отмечу, что для военного ОКРа или инженерно-строительного проекта круче классического «водопада» мало что подходит. Так устроена система. У каждой методологии своя область применения. Это не религия, это инструменты, позволяющие эффективно управлять параметрами проекта.
К примеру, когда требования на проекте не достаточно детальны (их трактовка допускает большую вариативность) или их уточнение подразумевается по ходу реализации проекта, то «прототипирующие и спринтовые» методы очень хороши.
Когда требования чётко определены, есть жёсткие требования регуляторов и контрольно-надзорных органов по этапности реализации, реализация подразумевает использование ГОСТов и нормативно-правовых документов — хорошо работают классические модели, такие как «водопад».
Управление рисками
С рисками тоже всё совсем не просто. Несмотря на то, что по управлению рисками написано множество книг и статей, управлять ими эффективно — задача отнюдь не тривиальная. По сути, мы пытаемся прогнозировать и оценивать события, которые носят исключительно вероятностный характер и конкретно в твоём проекте вообще могут никогда не произойти. А их нужно выявить, классифицировать, дать качественную и количественную оценку, разработать стратегию реагирования, контролировать, пересматривать…
На самом деле это сложный и многогранный процесс, в котором участия одного только ПМа явно недостаточно, приходится звать на помощь коллег. Несмотря на то, что одних только категорий и подкатегорий классификации рисков различные методологии предлагают бесчисленное множество, на практике большинство компаний используют наиболее понятные и простые для оценки. Редко где среди ИТ-компаний процесс управления рисками выведен на принципиально другой — продвинутый — уровень.
В оценке рисков обычно принимают участие ключевые участники проектной команды и привлечённые ПМом службы компании. Обычно на практике разделение выглядит примерно так:
- Организационно-методологические — риски, связанные с организацией работ и областями знаний, которыми управляет ПМ. Зона ответственности ПМа и проектного офиса. Технологические — риски, связанные с разрабатываемой архитектурой решения, применяемыми технологиями и т. д. Зона ответственности архитектора и ключевых технических специалистов команды.
- Финансовые — всё, что связанно с бухгалтерским учётом, выполнением требований регуляторов, используемыми финансовым моделям и т. д. Зона ответственности бухгалтерии и казначейства.
- Правовые — риски, связанные с действующим законодательством, нормативными актами, требованиями пунктов договора, правилами согласования с надзорными органами и т. д. Зона ответственности юристов.
- Специфические риски — обычно это риски, связанные с отраслевой спецификой либо требующие узкоспециализированных знаний. Здесь, в зависимости от проекта, периодически приходится прибегать к помощи сторонних экспертов.
Если оценка произведена качественно, то такого деления обычно достаточно, чтобы избежать наиболее критичных рисков.
Проще всего с рисками, о которых мы знаем заранее. Именно знаем, т. к. часть из них лежит на поверхности, а по части есть накопленный опыт из ранее реализованных проектов. Их обычно называют «известные риски». Такие риски просто анализировать и можно заранее спланировать ответные действия (стратегию реагирования). Сложнее, когда проект, например, реализуется впервые. Накопленного опыта нет, а своих компетенций не всегда достаточно. В таких проектах о наличии некоторых рисков мы даже можем не догадываться, а если и предполагаем их наличие, то не в состоянии оценить корректно. В таких ситуациях спасает только резерв на непредвиденные расходы и экспертная оценка команды.
«Задача максимум» при управлении рисками — сделать так, чтобы не наступило ни одно событие, которое может негативно сказаться на целях и показателях вашего проекта. Но это практически невозможно. Часть рисков всегда будет по отношению к вам внешними, а ваше влияние на них крайне ограниченным. И чем больше и сложнее проект, тем больше вероятность наступления одного из таких событий. Поэтому основной задачей ПМа будет минимизация последствий от их наступления.
Управление рисками — это непрерывный процесс на протяжении всего проекта. Большая ошибка, когда он стартует одновременно с самим проектом. Время на оценку и «место для манёвра» при этом резко снижаются. Я видел ситуации, когда ошибки планирования и сработавшие риски не только сжирали маржу проекта, но и топили проект вместе с компанией. Правильно начинать этот процесс на стадии глубокого пресейла, заблаговременно до принятия решения о вхождении в проект. Это особенно актуально в текущей рыночной ситуации, о которой я писал выше, когда компания входит в новые, незнакомые проекты с жёсткими требованиями заказчиков и регуляторов. Результатом пресейловой оценки рисков в таких проектах может быть решение группы управления вообще не идти в этот конкурс.
Такое решение внутри любой компании даётся всегда непросто, т. к. внутри команды происходит внутренний конфликт интересов. Это та самая грань, когда «жадность» сейлз-подразделений борется с консерватизмом и «боязнью» производства. В компаниях со зрелым менеджментом и бизнес-процессами такой конфликт даже полезен, т. к. истина в данном споре всегда оказывается где-то посередине. Главное в таких спорах — наличие арбитра, чтобы в случаях жарких дебатов не перейти черту, когда взвешенный и осознанный риск превращается в авантюризм и лотерею.
Профессионализм ПМа
К сожалению, многие искренне уверены, что профессионализм ПМа измеряется количеством времени, проведённым в профессии. Я считаю иначе: опыт, знания и умения. Чем их больше — тем профессиональнее ПМ. Практический опыт, накопленный в реальных «боевых» проектах, бесценен и является конкурентным преимуществом. Конечно, от ошибок никто не застрахован, но, как говорят в народе, «за одного битого двух не битых дают». Собрав своим лбом все грабли на своём огороде, вряд ли наступишь на них снова.
Выбирая ПМа на конкретный проект, я обращаю внимание на несколько параметров и пользуюсь всё той же «технологической пирамидой». Например, если надо построить здание и завести туда инженерку — я отдам предпочтение опытному строителю, а если провести модернизацию ИТ — бывалому инфраструктурщику. Знание технологической и отраслевой специфики, подрядчиков, подводных камней, наработанная команда помогают избежать лишних ошибок, сэкономить бюджет и время.
К себе в команду я стараюсь брать максимально универсальных и самостоятельных ПМов. Умеющих эффективно работать на всех уровнях пирамиды, а также в условиях высокой неопределённости. Большое внимание приходится уделять личностным качествам ПМа и его внутренней мотивации. Важно, чтобы человек быстро влился в коллектив, освоился и был «комфортным» для команды. Хорошие специалисты на рынке — большой дефицит.
Если интересно — задавайте вопросы, с удовольствием на них отвечу. Постараюсь на примерах конкретных проектов рассказать про разные нестандартные ситуации и как мы из них выкручивались.
Текст подготовлен Юрием Корчуковым, проджект-менеджером и заместителем директора центра инженерных компетенций «Техносерв».
Комментарии (30)
marenkov
06.02.2018 12:24Что делает — понятно, а где «что нужно, чтобы им стать»?
TS_Cloud Автор
06.02.2018 16:57Управление проектами, как и любая другая профессиональная деятельность, требует получения профессиональных знаний.
Их получение не составляет большого труда, ведь рынок сейчас дает большое количество предложений по обучению руководителей проектов. Начинать нужно именно с этого.
Выбирая тренинговый центр, нужно понимать, что большинство из них предлагает лишь получение академических знаний, основанных на одной из наиболее популярных и часто применяемых методологий (PMI, PRINCE2, Agile, Scrum и пр.). Если вы начинающий ПМ, и ваша текущая должность подразумевает только администрирование проектов без принятия управленческих решений, этого обычно бывает достаточно, чтобы «втянуться» в профессию. На рынке есть и более продвинутые тренинги, которые помимо погружения в методологию, основываются на практикумах и тренировке необходимых навыков. Некоторые центры предлагают даже специальные образовательные проекты, построенные на использовании бизнес-симуляторов для формирования/развития компетенции проектного управления. С одним из таких центров мы дружим и обмениваемся опытом — STS-VostoK (www.stsvostok.ru) Тут, как говориться, на вкус и цвет…
Стоит помнить, что любая методология — это всего лишь набор инструментов и описание правил по их применению: «отвертка — чтобы закручивать шурупы», «молоток — чтобы забивать гвозди». И это только часть решаемой задачи по выращиванию профессионального ПМ'а. Чтобы управлять большими комплексными проектами, нужна практика, опыт и навыки, полученные в реальных проектах.
Умение взвешенно принимать самостоятельные управленческие решения и нести за них ответственность — основное отличие руководителя проекта от администратора.
Вообще для профессионального ПМ'а обучение это процесс непрерывный. Оно помогает не только получать новые знания, но и систематизировать/улучшать полученные ранее.
Его можно сравнить с профессиональным хирургом, который владеет множеством инструментов и техник, но в конкретном случает применяет именно ту, которая спасет пациенту жизнь).
PMVyatkin
07.02.2018 15:07Я бы наверное идеальный путь ПМа описал так:
0. Выбор области, где человек хочет работать — хочет ли делать проекты по строительству ракет, или домов, или софта.
1. Хороший университет, который дает хорошую управленческую базу, а так же формирует критическое мышление и правильное видение бизнеса вообще (и проектного бизнеса, как подможества). Минутка рекламы — в регионе, откуда я родом это СУ — там же нам давали знания о проектном менеджменте (как частном случае менеджмента, вообще).
2. На 2-3-4 курсе университета — работа по специальности в области, где ты хочешь работать (например, если хочешь руководить проектами в разработке софта, желательно иметь представление о процессах разработки, внедрения, тестирования и т.д. — для чего можно пойти в компанию на джуниора — аналитика, разраба, тестера, внедренца и т.д.). Компания нужна не абы какая, а с хорошо (или неплохо) поставленными процессами управления проектами — Ланит, Астерос, Неткрекер, Наумен, АйТеко, СМС-ИТ.
3. Далее — через 1-2 года, когда будешь чувствовать себя уверенно на этом месте — попросить дополнительно загрузить работой администратора проекта (вести протоколы, вносить данные в систему управления проектам, низкоуровнево планировать ресурсы в проджект-сервере и т.д.).
4. Далее — брать на себя роль ПМа в проекте, где ты был аналитиком/тестировщиком/программистом и т.д. Как правило, свой проект/продукт знаешь уже хорошо, много общался с заказчиком (особенно если ты аналитик), знаешь все процессы в организации, людей, и т.д. и т.п.
А просто пройти курсы по ПМству — надо обязательно (например, сразу после универа), но только в паре с реальным опытом, без опыта — они бесполезны.
P.S. Прям статью написать захотелось, о том, что нужно запланировать, для того что бы пойти в ПМы )))
meranged
06.02.2018 12:37+1По какой-то причине, в статье сделан упор на работу с чем угодно, но не с собственно командой, с людьми, которые делают основную работу по проекту. Сколько раз приходилось сталкиваться с ситуацией, что за проект берётся вроде бы грамотный человек, который большинство описанных вопросов так или иначе закрывает, но к своей команде относится как к ресурсам, которые подобны роботам — должны делать то-то и то-то, по процессу. Может это где-то и работает, но обычно от руководителя проекта требуется тесный контакт с командой и не только на уровне постановки задач и не только с лидами. Команду нужно мотивировать, знать, чем она живёт, отслеживать внутрикомандные риски, планировать состав и качество команды, объяснять ей что за проект мы делаем. Скажем, если говорить о проектах из линейки «Безопасный город», то энтузиазма и осознанности в своих действиях у команды будет гораздо больше, если они будут понимать, что результатом их работы будет система, которая будет спасать человеческие жизни, нежели чем просто выполнение плана по прибыли для акционеров своей компании или формальные кипиаи. И по 12 часов будут работать с другим пониманием, а не из-под палки. Да, всё, что приведено в статье, безусловно, важно, но если руководитель проекта не установит хорошего контакта со своей командой и команда не увидит в нём лидера, за которым хочется идти, то всё остальное будет иметь мало смысла.
TS_Cloud Автор
06.02.2018 17:03Вы, разумеется, правы — от команды очень многое зависит, умение договориться и замотивировать — обязательная компетенция ПМ'а. И любая часть работы — и управление рисками, и управление качеством, и бюджетом — так или иначе в команду упирается.
А то, что вы описали — «грамотный человек, который большинство описанных вопросов так или иначе закрывает, но к своей команде относится как к ресурсам, которые подобны роботам» — на мой взгляд, куда лучше, чем массовик-затейник без понимания специфики. Поэтому на специфику я и сделал упор. Работа с командой — огромная тема, которая тянет на отдельный пост.
snp
07.02.2018 13:54умение договориться и замотивировать — обязательная компетенция ПМ'а
А если команда уже замотивирована по самое нехочу? Как показывает опыт, в таких случаях ПМ'а может проглючить очень сильно.
но к своей команде относится как к ресурсам, которые подобны роботам» — на мой взгляд, куда лучше, чем массовик-затейник без понимания специфики
Самое смешное, когда ПМ, работавший с ресурсами, приходит в команду высококвалифицированных спецов и пытается общаться с ними как в детском саду. «Мотивировать» человека, который сеньор и так уже на 100%+ отдаётся проекту, но просто не хочет манагерским буллшитом ещё себе голову забивать.
Думаю, стоит ещё один пункт дописать: понимание, где надо управлять, а где лучше не лезть :)
PMVyatkin
07.02.2018 15:18ПМ вообще людьми не командует — у них есть функциональный руководитель. Как правило, из команды ПМу напрямую никто не подчиняется, и уж в 100% случаев ПМ не может приказывать заказчикам.
У вас на проекте есть цели (например внедрить систему электронного документооборота за 6 месяце, в бюджете 10 млн рублей, соответствующую текущим БП предприятия) и есть люди (например команда из 5 человек с какими-либо скиллами — БА, СД, QA и т.д., а так же заказчик и его команда).
Для того что бы обеспечить достижение целей данными людьми, ПМ должен применить лидерство — обеспечить готовность, желание, намерения людей достигать целей некоторым способом (чем их мотивировать это каждый раз отдельный вопрос).
Если ваш ПМ не лидер, если он не умеет мотивировать людей, не умеет управлять командой и заказчиком, — это не настоящий ПМ, пусть идет в функциональные руководители и там командует.
habradante
06.02.2018 14:51Что-то в статье совершенно не отражен момент, что надо бы выяснять, в первую очередь, какую проблему решает проект, а уже потом что и как. И очень много ошибок именно из-за отсутствия понимания проблематики клиента. Даже сам клиент, часто, не может сформулировать проблему.
И да, как заметили выше, менеджер это сначала работа с людьми, а потом уже методологии. Если в команде много народу, то менеджер не может с каждым тесно взаимодействовать, но в этом случае он должен транслировать принцип «люди важнее всего» вниз по иерархии.TS_Cloud Автор
06.02.2018 20:01Специфика «Техносерва» в том, что у нас за уровень «какую проблему решает проект», все-таки отвечает не столько ПМ, сколько архитектор. Про его работу мой коллега недавно подробно писал — habrahabr.ru/company/technoserv/blog/344702. На самом деле этот вопрос отражен в разделе по управлению качеством (требования и ожидания). Решение данного вопроса мы делегируем системному архитектору, поскольку именно он отвечает за то, чтобы техническая реализация проекта отвечала требованиям заказчика, в том числе, решала его бизнесовую и функциональную проблематику.
habradante
07.02.2018 10:50Т.е. архитектор решает бизнес проблемы заказчика?
PMVyatkin
07.02.2018 14:55В моем понимании — архитектор подключается на этапе пресейла, смотрит что из предполагаемого скоупа проекта (требований заказчика) реализуется стандартный функционалом ПО (при условии, что это ПО вообще есть, и у него есть стандартный ф-л), а что требует доработки (или если разработка идет с нуля, определяет как надо доработать — какие методы и технологии использовать).
Далее — заказчику показывается некий прайс с гэп анализом, и заказчик далее проводит функционально-стоимостной анализ каждой фичи в проекте.
Например:
Проект: Внедрение MS Excel в компании ООО «Вектор».
Требование 1: Создание электронных таблиц. Стандартный функционал. Доплата не требуется.
Требование 1: Загрузка данных о отпусках участников ликвидации Чернобыльской аварии в таблицы из самописной ERP. Не стандартный функционал. 90 тыс. рублей.
Далее, заказчик думает и выбирает — надо ли ему эти отпуска за 90 тысяч реализовывать, или он их руками забьет (может у него одни ликвидаторы работают). И так по каждому требованию пользователей (конечно, верхнеуровнево, мы же в пресейле еще).
Ну и плюс тут архитектор должен ограничения грамотно написать, например если предполагается миграция данных сколько данных мигрируется (не более 1 млн записей например), кто отвечает за валидацию, какими средствами происходит миграция и т.д. и т.п.
Это позволяет рамки проекта определить правильно, а ПМ это не всегда может сделать, на сложных проектах — скорее никогда.
habradante
07.02.2018 15:25Указанное, вполне, в рамках компетенции архитектора, но это не бизнес проблема. Бизнес проблемой тут, может быть отсутствие учета ликвидаторов и непрозрачность (или невозможность) учета выплат.
PMVyatkin
07.02.2018 15:38Ага, все верно.
У заказчика есть проблема — учет ликвидаторов ведется неверно. Это у него болит, и он хочет это исправить. Он звонит интегратору и озвучивает свою проблему.
Тот присылает проектную команду, проводит анализ и предлагает заказчику несколько вариантов решений, с их стоимостью, например:
0. Уволить ликвидаторов (бесплатно, но есть риски, которые заказчик не готов взять на себя — затем то он и позвонил нам!). Не рассматриваем.
1. Учитывать ликвидаторов в эксцеле (100к + 3 часа работы пользователя в месяц).
2. Поставить SAP и учитывать все автоматически (90 млн. рублей).
Конечно, представляет это не арх, а ПМ\пресейл, но именно арх ответственный за то, что бы правильно понять бизнес-проблему заказчика и предложить ее решение с помощью имеющихся средств (или несколько альтернатив).
NeverIn
06.02.2018 16:46Как определяете сколько проектов потянет ПМ или сколько ПМ нужно на проект?
TS_Cloud Автор
06.02.2018 19:59Решение принимается всегда индивидуально. Все зависит от организационной сложности проекта и его территориально распределенности. Например, если это региональный проект, то часто назначают одного РП в Москве и одного в регионе, иногда в этом нет необходимости. У меня бывали случаи, когда в одном проекте участвовало 12 РП (он состоял из 800 объектов по всей России, работы велись параллельно), и было в точности наоборот — один РП вел 12 небольших проектов.
PMVyatkin
07.02.2018 14:46Вопрос — очень интересно, а есть ли у вас среднее по больнице по бюджету на одного ПМа?
Например, один ПМ ведет от 1 до 5 проектов с общим бюджетом ~40 млн в год.
Cherrr
06.02.2018 17:07Я работаю в комапании, которая сейчас активно встает на рельсы скрама. И по процессу у нас нет никакого PM. И непонятно, в чем его роль может заключаться в нашей команде. Причем у нас не доконца скрам, потому что бюджетом владеет не Product Owner, а мой линейный менеджер. Если бы было совсем по канону, то линейный менеджер был бы вообще не нежен (сейчас мы у него согласуем отпуска и прочую административку, видим его раз в месяц на стендапе).
В связи с этим бытует мнение, что PM это умирающий вид, рудимент в современном IT. Понятно, что не во всех областях, там где не обойтись без Waterfall, PM — важная роль в команде.meranged
06.02.2018 20:59Пиэм отвечает за результат проекта. Кто у вас отвечает за результат?
Cherrr
07.02.2018 10:03Команда целиком. Мы коммитимся на результат, постоянно даем обратную связь по выполнению, меняем подход, если что-то меняется внутри или снаружи. Продукт оунер в курсе ситуации всегда, а это человек из бизнеса.
PMVyatkin
07.02.2018 14:45profyclub.ru/uploads/3/45/0a88936c1bac2f5f14a5948694db3.png
Такую картинку предлагаю вам рассмотреть.
Но там РМ — это програм менеджер, а не проджект )
Вам ПМ может быть и не нужен, но это сильно от процессов зависит, о которых данных не достаточно.
Кто то же поставляет вам эпики, кто то считает бюджет, кто то считает TCO, экономические эффекты, курирует нагрузку команды и планирует использование людей и средств, рисует роадмэпы и показывает их топам и т.д. и т.п. Если это все делает скрам-мастер — это и есть ваш ПМ ))
Знаю крупный банк, где скрам и более 10 скрам команд пилит один продукт, а ПМ координирует эти команды и управляет сверху результатом, который они выдают.
reader123
07.02.2018 10:16У вас, видимо, продуктовая компания. А если бы заказ был на доработку продукта заказчика? Менеджер продукта у них свой, если повезет. И ваш ПМ бегал бы по ихним стекхолдерам и шлифовал (своими штанами) на совещаниях треугольник проекта. Это достаточно специфичная роль, чтобы ее играл линейный руководитель.
В пределе получается сильная матрица, когда все бюджеты в проектном департаменте. А линейный руководитель занимается развитием персонала и выделением его на проекты (за долю из бюджетов).
Valdamir
07.02.2018 13:19Понятно то всех вопросов в одном посте не раскрыть, поэтому есть вопросы.
А именно, как организовать четкое распределение задач и ответственных в проектах, затрагивающих несколько подразделений компании? При этом инициатор проекта из сферы продаж, а для остальных этот проект — новая головная боль. Высшее руководство в текущем уровне коммуникации между подразделениями проблему не видит (соответственно куратора не предвидится).
Я больше 5-ти лет работаю в сфере продаж в крупной, вертикально ориентированной компании, где отделы, как правило, занимаются прикрыванием собственных спин. Есть огромная заинтересованность в развитии проектного мышления, отсюда необходимость попробовать себя в управлении проектами внутри текущего работодателя. Есть большие опасения, что добиться положительного итога не получится. Что посоветуете?PMVyatkin
07.02.2018 14:35Мимо проходил, и увидел ваш комментарий, попробую ответить что подсказыват мой опыт ПМства.
Поскольку терминология гуляет от методологии к методологии, буду приводить объяснения по ходу рассуждений.
У вас у проекта есть инициатор, и есть спонсор (часто это одно и то же лицо, но не всегда).
Для вас главное спонсор — пусть для вас это ваш заказчик проекта (и не важно, он инициатор или нет).
Задача спонсора в этом проекте — организовать ресурсы для проекта в нужном количестве.
Задача ПМа — предоставить спонсору данные о ресурсах, необходимых в компании.
Для этого ПМ составляет план проекта, в которых входит план управления ресурсами. Последний (в вашем случае) должен отвечать на следующие вопросы:
— кто нужен?
— зачем нужен?
— когда нужен?
— на сколько нужен?
Предположим вам нужна уборщица тетя Глаша, для того что бы прибрать кабинет после того как айтишники насверлили там дырок для сети. Тета Глаша вам (и ПМу если это еще не вы) не подчиняется.
Так вот, вы включаете ее в план управления ресурсов, исходя из плана работ, который вы составили.
В плане работ вы видите, что айтишники будут тянуть сеть с 1 по 10 июля (± 1 день). Убирать за ними надо по вашим экспертным оценкам 2 дня.
Итого — в плане управления ресурсами вы пишете — «Тетя Глаша, с 10 по 12 июля, в объеме 16 часов».
После этого вы показываете план управления спонсору проекта, который либо соглашается с ним, либо вносит в него правки (например пишет, что может выделить тетю Глашу вместо 10-12 июля на 10-14 июля, но в объеме 4 часа в день — вы соглашаетесь, но объясняете спонсору что эта работа стоит на критическом пути проекта и следовательно срок всего проекта увеличивается на 2 дня (либо у вас есть запас по времени для этой работы)).
Итого, спонсор проекта (как правило это один из топ-менеджеров) подписывает вам план управления ресурсами, и согласно этому плану — ресурсы должны быть выделены.
Что происходит, например если тетя Глаша 10 июля вместо того что бы убирать кабинет после айтишников, уходит убирать цех по приему стеклотары (несмотря на все ваши напоминания об этой работе)? Вы пишете письмо ее руководителю, с копией на спонсора — который становится ответственным за задержку проекта на 1 день — а далее в соответствии с уставом проекта и внутренними регламентами к нему применяются санкции — например штрафы, лишение премии, и т.д.
Но, естественно, если ПМ в начале проекта тетю Глашу не попросил на 2 дня или не внес это в план управления ресурсами — ее руководитель имеет полное право отказать в предоставлении — и это значит что ПМ очень плохо планирует ресурсы.
Конечно, есть и изменения — например тетя Глаша заболела. Но у хорошего ПМа всегда есть 10% сроков — заложенных на риски, и это как раз тот самый (± 1 день) про который речь шла выше.
Ну или как то так. Если у вас серьезные проблемы с организацией проектной деятельности — наймите хорошего ПМа со стороны, который придет, все организует, найдет ответственных, сделает разумный план проекта, организует управляющие комитеты, объяснит людям их роли на проекте, зафиксирует ответственных за работы, заложится на риски, и т.д. и т.п. После этого у вас работы встанут на проектные рельсы. Самим это делать может быть и дешевле, но долго — 2-3 года в среднем проходит от идеи «хотим делать проекты правильно» до «делаем проекты успешно».
TS_Cloud Автор
07.02.2018 16:24Сложно дать конкретный совет без понимания специфики компании и самого проекта (организационная структура, модель бизнеса, устоявшиеся бизнес-процессы и т.д.).
Тем не менее, начать нужно со следующих вещей:
1. Определить цели проекта
Зачем он нужен в принципе, какие задачи/проблемы бизнеса решает, какой результат ожидают заинтересованные стейкхолдеры, если они вообще есть. Любой заинтересованный VIP — ваш потенциальный союзник в преодолении бюрократических барьеров.
2. Определить ролевую модель проектной команды
Она будет зависеть от специфики самого проекта. Если это верхняя часть пирамиды (бизнес-процессы, разработка ПО) — она будет одна, если инфраструктурный проект — другая, стройка и инженерные системы — третья. Из этого будет понятно, какие подразделения необходимо будет привлечь для выполнения поставленных задач. Возможно, окажется так, что требуемых компетенций внутри компании не окажется, придется искать их на рынки (подрядчики, срочные трудовые договора и т.д.).
В любом случае, вам понадобятся ключевые участники команды:
Системный архитектор — будет отвечать за всю технологическую часть, чтобы результат проекта соответствовал требованиям и решал поставленную задачу. По сути за качество в проекте(соответствие заданным параметрам). Он должен декомпозировать глобальную задачу на составные части, определить численность и квалификацию необходимых для реализации ресурсов, и при их наборе поставить частные задачи каждому исполнителю.
ПМ — будет отвечать за всю организационную часть проекта (комментарии излишне, собственно об этом статья)
Специалисты по направлениям — например, проектировщики, аналитики. Кол-во и компетенции будут сильно зависеть от самого проекта.
3. Закрепление проектной команды
Если в компании "… вертикально ориентированной компании, где отделы, как правило, занимаются прикрыванием собственных спин..." пишите и протаскивайте через руководство приказ о старте проекта с назначением ответственных исполнителей (согласно ролевой модели), а также Устав проекта, где должны быть описаны ответственность и полномочия каждого исполнителя. Это поможет персонализировать ответственность, как за результат в целом, так и за отдельные его части между исполнителями.
ВАЖНО! В описанной вами ситуации, если вы не найдете заинтересованных союзников среди ТОП-менеджеров, взаимодействие с горизонтальными подразделениями превратится в позиционно-осадную борьбу. Результат будет низким, а его достижение долгим. Должен быть арбитр данного взаимодействия.
Основная проблема, как я понял, что культура проектной деятельности в компании отсутствует, либо находится в крайне зачаточном состоянии.
Если в вашей компании проекты — это не мероприятия носящие разовый характер, нужен диалог с руководством о создании проектного офиса и внедрения процессов проектной деятельности на системной уровне. В противном случае, каждый старт и реализация нового проекта будет «как в первый раз».
Желаю вам удачи! Надеюсь все получится!
PMVyatkin
07.02.2018 14:18>> Например, строительство электростанции и разработка софта — кардинально разные проекты. Разная методология управления (PMI, Agile, Scrum…)…
PMI — Project Management Institute, а не методология.
PMBOK — свод знаний, об управлении проектами, разработанный PMI — а не методология (и это явно в нем прописано).
AGILE — философия, объединяющая в себе методы управления проектами, а не методология. Agile подходы так же включены в последнюю версию PMBOK, пруфлинк — www.pmi.org/pmbok-guide-standards/foundational/pmbok/sixth-edition
SCRUM — управленческий фреймворк (в крайнем случае набор принципов для построения процессов) применяемый для управления проектными командами, а не методология.
Правильнее было бы просто написать — разная методология управления, или методология управления построенная на разных принципах (гибкий и классический подходы).
Может быть я чего то не знаю, и какой то скрытый смысл за этим лежит?
Потому что сейчас в моих глазах это выглядит как закидывание в статью модных терминов (и аббревиатур).
WizardryIB
08.02.2018 14:50Приветствую!
Большинство согласно, что 80% времени работы PM — коммуникации (а то и все 90)! Коммуникации с командой, с заказчиками, с другими стейкхолдерами проекта. А основные задачи в ходе проекта — управление рисками (намерено упустил этап подготовки)! Если рисков нет то и PM нам без надобности…
Как в Техносерве расставляют приоритеты для управления рисками проекта? Какие инструменты используют? Вот, собственно, что хотелось бы услышать.)
cawakharkov
А не много ли вы ему обязаностей приписали?
TS_Cloud Автор
Спасибо за комментарий! Мы не претендуем на универсальное знание, в каждой компании проджект-менеджмент строится по-разному. Мы рассказали, как это выглядит в нашем случае.