В последнее время мы все чаще наблюдаем попытки внедрить проектное управление и здесь пути предпринимателей расходятся. Одни предпочитают консервативный PMI, другие гибкие методологии Agile, но на практике получается совсем не то что обещали тренеры.
Дело здесь вовсе не в качестве тренеров или попытках применить западные (в случае с Kanban — дальневосточные) методологии на нашей почве. Проблема кроется в том, что воссоздание внешних признаков методологии далеко не всегда означает её успешное внедрение на конкретно взятом предприятии, а использование гибкой методологии в консервативных специальностях в принципе ломает устоявшуюся логику бизнес-процессов.
Agile, в понимании большинства предпринимателей сегодня — это доска со стикерами, на которых записаны задачи. Они перемещаются по секторам в зависимости от статуса и процента выполнения. Но сам факт наличия доски не означает внедрения методологии. В результате задачи накапливаются, либо выполняются не те или не вовремя. Это неизбежно приводит к дисбалансу в коммуникациях.
Одни отделы действительно начинают работать эффективнее, но отделы с налаженными бизнес-процессами, наоборот, дают сбои из-за возросшего потока входящих задач от смежников и образуется затор.
Чтобы избежать негативных последствий при внедрении проектного управления, необходимо чётко разграничить области применения выбранной методологии. Если рассматривать три основных проектных подхода, мы получим:
Стандарт PMI PMBoK блестяще работает при жёстком временном и ресурсном планировании. Если рассматривать области применения, где он реализуется без полутонов и доработок — это конвейерное производство, документооборот с ясными сроками (бухучёт, финансовое планирование, регулярная аналитика и формирование отчётности).
Фактически, если мы имеем жёстко установленные сроки, применение вех и задач по стандарту PMI более чем оправдан. При этом, если мы можем себе позволить менять задачи местами, начинаются нежелательные для этого стандарта компромиссы.
Agile: SCRUM — отличительной чертой является разделение этапов реализации одной глобальной задачи на "спринты". Как правило, это двухнедельный временной отрезок, который начинается с постановки потенциальных задач и заканчивается готовым промежуточным продуктом. При этом очерёдность выполнения задач остаётся на усмотрение исполнителя, но обязательное условие — достижение поставленной цели к концу спринта.
Методология прекрасно зарекомендовала себя в случаях связанных с IT-разработкой и технической поддержкой, когда мы не можем позволить себе сместить сроки, но высокая вариативность допускает удаление ряда задач, не критичных в конечном продукте.
Agile: Kanban — применяется при штучном производстве и в исследовательских проектах. Гибкая методология всегда имеет цель в виде готового продукта, но не имеет чётко обозначенных объёмов и сроков. Фактически, если мы знаем перечень участвующих в технологической цепочке элементов, мы выстраиваем их в установленной последовательности, а потом фиксируем результат. Методика требует предельной заинтересованности сотрудников в результате, но становится неэффективной, когда мотивация падает, или нам требуется провести точные расчёты объёмов выпуска.
Таким образом, если говорить о типичном предприятии, мы увидим, что невозможно применить любую из методологий в чистом виде.
Предприятие, в котором есть жёстко регламентированные отделы, привязанные к календарному расписанию или маршруту (бухгалтерия или курьерская служба) это PMI, отделы с возможностью гибкого управления задачами и привязанные только к конечному сроку (например, техническая поддержка клиентов) это SCRUM, а департаменты ориентированные только на результат (например, разработка новых продуктов) это Kanban.
Следует ли из этого несостоятельность каждой отдельно взятой методологии? Конечно нет! Если взять за основу все три варианта, нам понадобится только внедрить подходящие методологии в соответствующих их концепции отделах и научиться трансформировать результат при передаче из одного отдела в другой.
