Если у менеджера проекта нет опыта или системного подхода, то проект с большой вероятностью зайдёт в тупик, выбьется из выделенного бюджета или просто провалится. Найти грамотных управленцев в одночасье очень сложно. Поэтому на выручку приходят готовые, давно обкатанные и высоконадёжные методологии управления проектами. С ними риск прогореть существенно снижается. А работа подчиняется не законам хаоса, а законам логики.
Классификация (виды) систем управления проектами
Сразу стоит оговориться, что системы управления проектами могут быть рассчитаны на разный уровень охвата: национальные (например, P2M для Японии, DIN 69901 или V-Modell для Германии, AFITEP для Франции), глобальные (известный многим PMBOK и стандарт на его основе – ISO 21500:2012, PRINCE2 и др.) и специализированные (применяемые для проектов определённого типа).
Так как глобальные и национальные системы слабо применимы для использования внутри небольших команд и средних/малых предприятий, рассмотрим разные виды специализированных систем управления проектами.
Здесь стоит выделить два основных направления:
- Классические практики управления. Они соотносятся с общей теорией менеджмента, описываемой в высших учебных заведениях.
- Современные практики управления проектами. Обычно это гибкие методологии.
Исторически так сложилось, что проектная работа в России в коммерческом поле (без привязки к государственным структурам, включая работу над национальными проектами и научными исследованиями) вращается преимущественно вокруг IT-проектов. И именно для этой отрасли разрабатываются разные подходы и практики управления.
Наиболее популярные практики управления проектами
Во многих IT-проектах берутся на вооружение преимущественно простые, понятные и максимально практичные методики. К ним относятся:
- Agile — «гибкая» методология, объединяет большой пул систем управления проектами со схожими или не очень чертами.
- Scrum — «схватка», на самом деле входит в семейство гибких методологий, но из-за высокой популярности выносится как отдельная методика.
- Канбан — все задачи по проекту получают свою Канбан-табличку и перемещаются из стартового состояния в финальное, процесс продвижения легко отслеживается на специальной Канбан-доске.
- Waterfall — она же каскадная модель или «Водопад».
- Итеративная разработка проекта относится к разряду линейных/последовательных методик, как и «Водопад».
- Инкрементная модель — проект разбивается на множество модулей, каждый из которых может быть реализован отдельно, но с привязкой к этапам, с увеличением инкремента.
- Инкрементно-итеративная модель — как своеобразный симбиоз предыдущих двух моделей.
Расскажем о топ-3 моделях немного подробнее.
Agile-практика управления проектами
Agile – это не совсем методика. Это общий подход, базовые принципы и ценности, которых нужно придерживаться при работе над проектом. Ценностей всего четыре:
- Максимальный приоритет имеют люди и взаимоотношения.
- Основная цель – работающий продукт, а не подробная документация к нему.
- Сотрудничество с заказчиком или клиентом важнее согласования условий договоров (контрактов).
- Всегда нужно быть готовыми к изменениям условий изначального плана (отсюда и гибкость Agile).
Принципов 12, но все они вращаются вокруг тех же ценностей, разъясняя подход более детально. Например, в agile-команде должны работать только профессионалы, оценка процесса производится по работающему продукту и по реализуемым функциям, наивысший приоритет всегда имеют потребности заказчика, внесение изменений в проект возможно даже на последних стадиях работы, представители клиента должны работать вместе с проектной командой, чтобы обеспечить непрерывную коммуникацию и контроль, и прочее.
Scrum – эффективная практика управления проектами для небольших команд
В отличие от общего Agile-подхода, Scrum – это вполне конкретная методика, которая хорошо документирована и формализована. Фактически это своего рода итеративная модель работы над проектом, где каждая итерация – это своего рода забег (спринт).
Перед забегом ставится конкретный список задач, при этом в постановке целей активно участвуют представители заказчика.
Далее задачи заносятся в SCRUM-доску, которая во многом схожа с Канбан-подходом, только таблички с задачами здесь более информативны (кто работает над задачей, какие сроки и другое).
Из минусов – эта система управления плохо масштабируется на большие команды. А продуктивность сотрудников и/или всех, кто участвует в работе над проектом, можно адекватно оценить только через несколько спринтов.
Канбан-практика и бережливое производство
Слово «Канбан» пришло из теории бережливого производства. Но сейчас Канбан ассоциируется не столько с методологией, сколько с методом визуализации задач. Это действительно удобно, когда у вас перед глазами есть список всех задач проекта, разбитых по наглядным признакам статуса работы над ними.
По мере изменения статуса табличка с задачей перемещается по столбцам. Последний столбец – конечное состояние. Это значит, что работа над задачей завершена.
Так легко можно отследить, какие задачи у вас в пуле, над какими сейчас активно работают сотрудники и какие уже завершены. В Канбан-табличка может быть любое количество статусов. По такому же принципу работают воронки продаж в CRM-системах (в общий пул попадают все контакты с клиентами, а конечным статусом будет совершение сделки – продажа), только к конечному состоянию приходят не все таблички, отсюда и название «воронка» из-за сужающегося горлышка к концу.
Бережливое производство как методика весьма эффективно. Вы распределяете для работы над проектом только те ресурсы, которые у вас имеются, и каждый сотрудник всегда занят делом.
Больше вариантов современных методик управления вы можете найти в нашем материале «Топ 10 методологий для ведения проектов».
Время, деньги и ресурсы
При применении разных практик управления проектами не менее интересны вопросы юридической ответственности за результат. Ведь любые отношения между заказчиками и исполнителями можно перевести в плоскость материальной ответственности (как вопрос реализации права на ошибку).
Что, если рассматривать исходные данные проекта в разрезе имеющихся ресурсов? Тогда в схеме будут точно участвовать:
- время – то есть конкретные сроки реализации или время специалистов, задействованных в проекте;
- деньги – а точнее бюджет, который выделяется для реализации проекта, сюда могут входить разные расходы, но наиболее важные – заработная плата проектной команды;
- другие ресурсы, в том числе человеческие, выделяемые для существования и реализации проекта.
Исходя их этих критериев, при документировании ответственности следует придерживаться следующих принципов.
Фиксированный набор ресурсов
При постановке задач проектному менеджеру (то есть всему проекту) могут быть жёстко ограничены:
- время — у проекта могут быть конкретные сроки (дедлайн) или заданная периодичность отчётности — приёмки результата;
- бюджет — максимальная сумма, превышать которую нельзя, тоже может привязываться либо ко всему проекту в целом, либо к конкретным периодам или функциям;
- объём работ — чётко обозначенные функции продукта, задачи, которые необходимо реализовать на момент сдачи проекта.
Соответственно, при приёмке результата работы над проектом будут обязательно оцениваться эти критерии. Все ресурсы, выделенные сверх нормы – уже за счёт исполнителя. Это важная юридическая тонкость. Соответственно, цели, задачи и лимиты строго оговариваются в договоре с проектной командой. Там же указывается материальная ответственность на случай неисполнения условий.
Гибкая схема расчёта по материалам и ресурсам
«У самурая нет цели, у него есть только путь…»
Заказчики крупных проектов прекрасно понимают, что для достижения конкретных целей и результатов им нужно много ресурсов и времени. Оценить объём работ заранее крайне сложно. Тогда и вопрос юридической ответственности оговорить непросто.
Наиболее гибкий подход в этом случае – оценка по краткосрочным периодическим затратам. Лучший критерий оценки – время задействованных специалистов.
Иными словами, менеджер проекта нанимает нужных ему исполнителей и оплачивает их труд исходя из объёма выполненной работы. Так общий уровень затрат будет оптимальным.
Профильные специалисты фактически будут привлекаться по мере появления специфичных задач, выполнять их и уходить из проекта. У них будет пул своих задач со своей ответственностью и мотивацией.
Таким образом, право на ошибку при такой схеме оценки для исполнителей будет выглядеть более лояльно. А заказчик будет видеть общий прогресс и, исходя из него, планировать дальнейшие действия и расходы. Правда, в этом случае бремя ответственности за результат в большей части переходит к нему, а не к команде, которая может сорвать сроки задач.
Примерно по таким же принципам заказчик может оперативно наращивать собственную проектную команду, получая «приходящих» специалистов по схеме аутсорсинга (в данном случае будет правильнее термин «Outstaffing»).
Инструменты управления проектами
Сама по себе методика или практика управления проектом обречена на провал, если вместе с ней вы не внедрите качественную систему контроля и постановки задач. Есть различные программные средства: профессиональные, заточенные под определённый круг задач и совместимые методики, универсальные, облачные и для офлайн-установки, с подпиской и без и т.д.
Лучшим решением для небольших команд и проектов будет облачная система с оплатой подписки по количеству сотрудников. Например, такая, как наш сервис Projecto.
Это универсальная система управления проектами, которая легко адаптируется практически под любую современную практику или методику (Канбан, SCRUM, сетевая модель и прочие).