Пм в бизнесе что это

Для того, чтобы продемонстрировать насколько важна роль PM мы расскажем об одном проекте, который позволил обрести очень важные выводы, касающиеся этой роли.

Пример (WO)

В прошлом году у нас появился новый проект в области Fintech. Легаси:
Система заказчика обрабатывала до 80 млн платежей в сутки. Возникла потребность обрабатывать до 1.5 млн операций в сутки.
Мы встретились с потенциальным заказчиком и задали важный вопрос с нашей стороны: кто будет руководить проектом?
Заказчик предложил, что их Product Owner может легко выполнять функции PM.
Проект стартанул очень бодро: каждый месяц мы проводили ДЕМО перед учредителями Заказчика. В конце каждого демо РО делал прогноз по дальнейшим срокам.
Неожиданно для всех к концу 4-го месяца выяснилось, что Акционеры ожидали готовность проекта через 2-3 недели, а по версии РО еще оставалось работы на 3-4 мес.
Разобравшись в причинах, выяснилось, что узкое место — недостаток детального управления проектом, т.к. РO был перегружен: он одновременно был РО, BA и РМ.

PM2. Рабочий день проджект менеджера // Project Manager для новичков

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

PM должен обладать достаточным временным и другими ресурсами, иначе проект будет сталкиваться с серьезными рисками роста издержек и временных затрат

Роль PM относится к “Локомотивным Ролям”, т.е. отвечает за движение проекта в правильном направлении.

С точки зрения частоты контроля:

• Заказчик следить за проектом раз в две-недели/месяц.
• РО — минимум два раза в неделю.
• РМ — каждый день.

PM решает задачу оперативного управления и прогноза состояния проекта.

В этом плане — он как пилот самолета. Нужно долететь до пункта назначения за определенное время и с ограниченным запасом топлива. В частности, это означает, что именно роль РМ — решать “блокирующие”, кризисные ситуации на проекте.

Возможно ли распределять ответственность PM между другими ролями?

На небольших проектах совмещение роли РМ возможно. Но совмещать ее нужно с “локомотивными ролями”.

• Например с РО.
• Совместимость с “Экспертными ролями” возможна в точечных ситуациях, когда у вас есть проверенный “человек-оркестр”.

С какими ролями взаимодействует PM? И Как он обеспечивает реализацию проекта на повседневной основе?

PM, по сути, является связующим звеном между РО и командой.
Все начинается с того, что в диалоге с PO, BA и Архитектором производится верхнеуровневое планирование, оценка сроков, понимание архитектуры и технологического стека разработки.

Таким образом первая функция PM — это:

IT PROJECT MANAGEMENT | Чем занимается Проджект менеджер, какие навыки нужны для IT Project manager

Планирование и прогнозирование сроков и бюджета проекта.
Следующим шагом PM должен собрать команду под задачи проекта (аналитиков, разработчиков, девОпсов, тестировщиков и тд). И, по мере необходимости, гибко, менять ее состав.

Таким образом, вторая функция PМ:
Комплектация проекта командой с соответствующими компетенциями.

Третья задача PM:
Обеспечить команду разработки необходимым инструментарием

У всех участников команды должен был доступ в тасктрекер, хранилище проектной информации, канал коммуникации (мы предпочитаем Jira, Confluence и Slack, соответственно), а разработчикам нужен доступ репозиторий (Gitlab, bitbucket или github)
На этом завершается подготовительный этап работ.

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

Критически важна прозрачность процессов.

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

Регулярность коммуникаций. (обязательным атрибутом являются регулярные коммуникации).

Важен Ежедневный командный созвон (так называемый daily scrum meeting) и регулярные встречи для командного планирования. Важно, чтобы в планировании участвовал PO, так как это позволяет синхронизировать ожидания и при необходимости скорректировать направление разработки.

Соблюдение процессов всеми участниками позволяет PM’у управлять задачами с точки зрения последовательности и взаимозависимости.
Вышесказанное можно обобщить в функциях Управление задачами проекта (4) и Управление командой проекта (5)

Финальная функция РМ-а:

Демонстрация результатов и актуальных планов РО и Заказчику.
Мы понимаем, бизнес-заказчики “любят глазами”, поэтому PM организует регулярное ДЕМО – раз в несколько недель, на котором заказчик может “пощупать, покликать” результат и дать обратную связь.

Какие компетенции нужны человеку для того, чтобы стать хорошим PM?

Во главе угла стоят личностные компетенции:

• Позитивное отношение к людям.
• Коммуникативные компетенции,
• Эмоциональный интеллект.

Также, PM должен обладать достаточной чуткостью и наблюдательностью, чтобы поддерживать благоприятный эмоциональный фон в команде.

• Целеустремленность.
• Умение находить нестандартные решения

Подводя итог хотелось бы привести еще одну метафору:

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

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

Источник: itquick.ru

Правда ли, что ПМ делает что-то полезное и что нужно, чтобы им стать

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

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

За время работы какими только проектами не приходилось управлять: внедряли SAP, автоматизировали деятельность предприятий, разрабатывали ИСы для госзаказчиков, проектировали и строили уникальные ЦОДы, делали военные ОКРы, проводили сложные миграции ИС… — даже строили под ключ электростанции в Белоруссии и угольные котельные в п. Черском (2000 км от Якутска). Основной сложностью тогда оказалась доставка оборудования и материалов — река была проходима только 5 месяцев в году. Вылез за дедлайн или просто поймал холодный год — потерял 7 месяцев. Либо дорогущий вертолёт. Все проекты разные, и каждый по-своему уникален.

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

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

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

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. Специфические риски — обычно это риски, связанные с отраслевой спецификой либо требующие узкоспециализированных знаний. Здесь, в зависимости от проекта, периодически приходится прибегать к помощи сторонних экспертов.

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

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

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

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

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

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

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

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

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

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

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

Если интересно — задавайте вопросы, с удовольствием на них отвечу. Постараюсь на примерах конкретных проектов рассказать про разные нестандартные ситуации и как мы из них выкручивались.

Текст подготовлен Юрием Корчуковым, проджект-менеджером и заместителем директора центра инженерных компетенций «Техносерв».

Источник: habr.com

Кто такой менеджер проектов и зачем он в компании

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

На HH.ru размещено почти 17 тысяч вакансий для менеджеров проектов. И это только в России. Большинство предложений от работодателей начинаются с зарплаты 60–70 тысяч рублей — на такую зарплату претендуют новички и проджекты с небольшим опытом. Опытному менеджеру компании готовы предложить и по 200–300 тысяч в месяц.

Разбираемся, что это за специалисты, почему они так востребованы у бизнеса и за что работодатели готовы предлагать столь конкурентную зарплату.

Менеджер проектов: кто это

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

Шутка.

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

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

Проект-менеджер — это главный человек в команде

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

Зачем Trello, когда есть OkoCRM

Управлять командой, задачами и загрузкой в 1000 раз удобнее в таск-трекере OkoCRM. Идеальный софт для управления проектами.

Чем занимается проект-менеджер в компании

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

Обычно проект-менеджер находится между молотом и наковальней. Он должен отстаивать интересы сразу трех сторон:

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

Окей, а что с практической точки зрения? Мы тут в Oko взяли и препарировали должностную инструкцию проект-менеджера в одной компании. Вот 13 главных обязанностей рядового проджекта:

1. Планирование работы команды. Введение итераций, отслеживание сроков и прогресса по проекту
2. Выявление потребностей клиента. Определение функционала продукта, согласование итогового результата
3. Информирование руководства и команды, коммуникация между руководством и командой
4. Проведение встреч, совещаний, летучек по проекту
5. Решение вопросов и проблем команды. Устранение препятствий для сотрудников, решение конфликтов.
6. Коммуникация с заказчиком. Введение заказчика в курс дела по проекту, сопровождение коммуникации команды с заказчиком на всех этапах
7. Планирование и учет расходов, согласование бюджета проекта, прогноз прибыли
8. Обеспечение команды необходимыми ресурсами: инструментами, софтом, документами, бюджетом
9. Составление проектной документации, технических заданий, брифование заказчика
10. Отслеживание и управление рисками. Коррекция рабочих процессов в зависимости от приоритетов
11. Анализ и выделение задач. Разбивка задач на подзадачи, проектов на подпроекты
12. Ведение отчетности. Анализ результативности команды, эффективности продукта
13. Презентация продукта заказчику, обсуждение поправок и рекомендаций

Зачем менеджер проектов бизнесу

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

Если модель менеджмента в компании построена на проектном управлении, должность менеджера проектов — must have для штатного расписания. Вот 4 задачи, которые проджект выполнит лучше любого другого спеца:

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

Понимание потребностей делает работу команды системной и грамотно распределяет силы команды.

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

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

4. Управлять рисками. Для ПМ нет понятия «неожиданность» и «сюрприз». Он не может наверняка и заранее знать, что именно пойдет не так. Но если это произойдет, у проджекта в кармане всегда есть минимум три решения на этот случай.

А еще кобура с ресурсами, которые помогут все наладить.

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

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

Собирайте лиды отовсюду

OkoCRM пылесосит все каналы, по которым приходят клиенты. Сайт, соцсети, мессенджеры, телефония, сделки и проекты внутри одного окна.

На что смотреть при найме проект-менеджера

Релевантный опыт. Самое ценное, что есть у хорошего менеджера проектов, кроме мотивации. Если вы строительная компания, проджект с опытом работы в IT или диджитал-агентстве может не подойти. Его функции на прошлой работе вероятно совпадали с вашими задачами. Но вот специфика ниши часто решает больше.

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

Кейсы. Какие проекты были реализованы? С какими проблемами столкнулась команда и как их решил ПМ? Были ли сорваны сроки, соблюден бюджет? Чтобы понять уровень скилов, достаточно изучить 2–3 кейса, что о них расскажет кандидат.

Навыки. 80% трудовых функций проект-менеджера приходится на soft skills: гибкость, умение договариваться, дисциплина, находчивость, ответственность, умение разрешать конфликты, лидерские качества, адаптивность к новым условиям. Жесткие навыки ПМ:

• управление командой
• работа с инструментами управления проектами — MS Project, Trello и подобные
• знание языков — если вы работаете с иностранными заказчиками
• работа с инструментами управления расходами и сроками
• внедрение гибких методологий, включая Скрам, Канбан и пр.
• внедрение регламентов и корпоративных стандартов
• работа со стандартами P2M, Prince2, PMBOK и пр.
• бюджетирование, работа с методом освоенного объема

Образование. Онлайн-курсы, тренинги, учебные проекты. Название учебного заведения в дипломе на самом деле не так важно, как кейсы и опыт. Но для общего понимания узнать стоит. Возможно, вы захотите в перспективе отправить кандидата на обучение и будете знать, куда НЕ нужно отправлять своих сотрудников.

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

А оно нам надо?

Все каналы продаж в OkoCRM

В одном окне чаты в Telegram и WhatsApp, VK и на сайте, почта и другие каналы продаж. Обращения клиентов не теряются.

Как вырастить толкового проект-менеджера

Тут все сложно. Не получится просто отправить сотрудника на онлайн-курсы и сразу получить высококлассного project manager. Такой специальности нет в институте. А прохождение месячных курсов еще не делает из человека прожекта: тут нужны опыт, практика.

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

• Стажер
• Профильный специалист. Например, PHP-разработчик
• Главный PHP-разработчик
• Руководитель отдела
• Проект-менеджер

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

ТОП-5 курсов подготовки проект-менеджеров

Сфера: Диджитал, IT

Сроки: 8 месяцев

Формат: профпереподготовка, очно или онлайн

Сфера: IT и другие сферы

Цена: от 112 200 ₽

Формат: профпереподготовка, онлайн

Сфера: IT, строительство, энергетика, другие сферы

Сроки: 12 месяцев

Сроки: 6 месяцев

В каких сферах нужен проджект

 Обычно обязанности менеджера проектов незаменимы в IT. Специфика бизнеса предусматривает проектное управление и работу с заказчиками в виде неких циклов. Поэтому без проджекта никуда. Но это не значит, проектное управление работает только в IT. Ребята из Скилбокс проанализировали вакансии на HH и сделали вывод, что на компании в области информационных технологий приходится лишь около 40% вакансий.

Вот как выглядит выглядит ТОП-5 сфер, где нужны проджекты:

1. Информационные технологии, системная интеграция, интернет
2. Услуги для бизнеса
3. СМИ, маркетинг, реклама, дизайн, продюсирование
4. Финансовый сектор
5. Строительство, недвижимость, проектирование

Project manager нужен не только в IT. Толковым проджектам всегда рады в маркетинге, строительстве и даже финансовых организациях.

Какую зарплату установить для должности project manager

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

от 70 000 ₽ — начинающий специалист, совмещает проектное управление с другими функциями в команде (за которые получает отдельную зарплату). Отвечает за несложные проекты, длительностью до 3–4 месяцев.

от 120 000 ₽ — специалист с опытом от 2 лет. Полностью отвечает за работу команды, берет на себя организацию всех процессов. Не имеет узкой специализации, работает с продуктами средней сложности. Для специалиста в IT — +20%.

от 200 000 ₽ — специалист с опытом от 5 лет. Курирует работу команды, взаимодействует с заказчиком на всех этапах, делегирует полномочия. Решает текущие задачи в условиях стрессовых ситуаций, умеет очень быстро приспосабливаться к новым условиям (урезали бюджет, забрали половину команды и пр.). Работает по узкой специализации. Для специалиста в IT — +40%.

Попробуйте OkoCRM бесплатно

CRM-система, управление проектами и задачами, общение с клиентами и каналы продаж — всё внутри OkoCRM. 7 дней бесплатно.

Полезные материалы для развития навыков по профессии project manager

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