какие методологии управления проектами существуют
Топ Методологий Управления Проектами: От Требовательной Waterfall до Правительственной Prince2
Методология управления проектами — это набор руководящих принципов и процедур для управления проектом.
Методология, которую вы выберете, определяет, как вы будете работать и взаимодействовать.
В статье описаны основные методологии управления проектами, их преимущества, недостатки, а также ситуации для лучшего их использования.
Виды методологий управления проектами
В теории можно использовать любую методологию вне зависимости от того, каким программным обеспечением для управления проектом вы пользуетесь.
В реальности же большинство систем управления задачами и проектами подходят для нескольких различных методологий.
Значит, нужно разобраться в том, какие бывают виды методологий управления проектами, в их преимуществах и недостатках, и для каких проектов они лучше всего подходят.
Итак, рассмотрим 9 популярных методологий управления проектами.
1. Waterfall (каскадная модель, «водопад»)
Методология Waterfall – самая «старая» из всех. Впервые она была изложена американским ученым в области информатики Уинстоном Уокером Ройсом в 1970 году в ответ на потребность управления все более усложняющимся процессом разработки программного обеспечения. С тех пор она получила широкое распространение, особенно в сфере программного обеспечения.
Каскадная модель характеризуется последовательностью. Помимо этого, она в значительной степени ориентирована на требования.
Когда проект уже будет в разработке, вы не сможете скорректировать его курс.
Методология Waterfall делится на три отдельных этапа. Сначала необходимо собрать и проанализировать требования, затем разработать решение (и подход), внедрить решение и исправить проблемы, если они появились.
Вышеописанное применимо к разработке программного обеспечения. Для быстрого начала планирования воспользуйтесь готовым шаблоном диаграммы Ганта для разработки ПО.
В рамках других проектов, например, творческих, этапы будут другими, но подход останется таким же.
Преимущества Waterfall модели
Затрачивая время на ранних стадиях развития проекта, менеджеры создают условия для своевременного выполнения требований. Это позволяет сэкономить время и силы на исправлении недочетов и решения проблем в дальнейшем.
Таким образом, методология Waterfall обладает рядом преимуществ:
Эту модель просто понять и использовать. Деление на этапы довольно интуитивно, его просто освоить вне зависимости от опыта.
Жесткость методологии Waterfall – одновременно и недостаток, и явное преимущество. Четкое разделение на этапы позволяет организовать и распределить работу. Поскольку назад вернуться нельзя, необходимо идеально справляться с выполнением каждого этапа, что зачастую позволяет добиться лучших результатов.
Поскольку много внимания уделяется сбору и пониманию требований, модель Waterfall в значительной степени опирается на документацию. Благодаря этому новым ресурсам проще влиться в проект и начать работу над ним.
Недостатки Waterfall модели
Жесткость методологии означает, что, если вы обнаружите ошибку или вам понадобится внести изменения, придется начинать проект сначала. А это значит, что вы и вовсе можете не завершить проект вовремя.
Весь подход Waterfall зависит от того, насколько правильно вы поймете и проанализируете требования. Если вам не удастся сделать это или если требования изменятся, придется начинать сначала. Поэтому эта методология управления не подходит сложным долгосрочным проектам.
Для каких проектов лучше всего подойдет Waterfall
Методология управления Waterfall зачастую используется в сфере разработки программного обеспечения. Она лучше всего подходит для:
2. Agile (гибкая методология)
Agile — это еще одна методология управления c акцентом на разработке программного обеспечения. Появилась она как результат неприменимости методологии Waterfall в рамках сложных проектов.
Хотя идеи, присущие Agile, уже давно используются в сфере разработки ПО, формально методология появилась лишь в 2001 году, когда несколько представителей из IT выпустили Agile-манифест.
Agile полностью противоположна методологии Waterfall по подходу и идеологии. Само название с английского языка переводится как «Гибкий», а это значит, что в управлении используется быстрый и гибкий подход.
Методология скорее характеризуется небольшими циклическими изменениями, которые внедряют в ответ на изменение требований.
Преимущества Agile методологии
Поскольку здесь не нужно четко обозначать этапы и делать упор на требованиях, у исполнителей проекта появляется возможность экспериментировать и вносить изменения постепенно. Именно поэтому Agile отлично подходит творческим проектам.
Методология Agile подразумевает регулярное получение обратной связи от заинтересованных участников и последующее внесение изменений. Это значительно сокращает риск провала проекта, так как нужные ресурсы вовлечены в процесс.
Недостатки Agile методологии
В Agile подходе реагирование на изменения происходит тогда, когда они возникают. Отсутствие четкого плана затрудняет управление ресурсами и планирование. Вам придется постоянно балансировать и в случайном порядке переводить ресурсы с одной задачи на другую.
Отсутствие четкого плана означает, что всем заинтересованным сторонам, включая заказчиков и спонсоров, придется работать в гораздо более тесном сотрудничестве, чтобы каждый участник проекта знал обо всех изменениях, задачах и их актуальности.
Для каких проектов лучше всего подойдет Agile
Гибкость подхода Agile позволяет адаптировать его к проектам различного типа. Методология лучше всего работает в случаях:
Онлайн диаграмма Ганта GanttPRO поможет вам в планировании проектов любой сложности и длительности по методологиям Waterfall и Agile.
3. Гибридная модель
Гибридный подход — это сочетание методологий Waterfall и Agile. Ему присуще все лучшее, что есть в этих методологиях. Это гибкий и при этом хорошо структурированный метод, который можно использовать для различных проектов.
Сочетая свойства Waterfall и Agile, гибридная методология, которую иногда называют «Структурированным Agile», позволяет воспользоваться преимуществами обеих составляющих.
Преимущества гибридной методологии
Если не считать этап планирования, гибридной методологии свойственна значительно большая гибкость, чем методу Waterfall. Если требования не будут значительно меняться, в проект можно будет вносить изменения по мере необходимости.
Позаимствовав этап первоначального планирования из Waterfall, гибридная методология решает одну из основных проблем подхода Agile — недостаточную организованность и отсутствие плана. Таким образом, эта методология сочетает в себе лучшее от этих подходов.
Недостатки гибридной методологии
Поскольку вам придется поддерживать баланс между двумя совершенно противоположными подходами, нужно будет искать компромиссы в области требований и гибкости.
Для каких проектов лучше всего подойдет гибридная методология
Гибридная методология больше всего подойдет проектам с размытыми требованиями, в которых важны и планирование, и гибкость.
В основном это проекты среднего объема с высокой сложностью и фиксированным бюджетом. Скорее всего, у вас будет определенное представление о конечной цели, но при этом возможны эксперименты. С заинтересованными сторонами понадобится тесное взаимодействие, особенно после этапа планирования.
4. Scrum
Scrum — это не полнофункциональная методология управления проектами. Это скорее подход к методологии Agile с акцентом на командах проекта, спринтах и ежедневных собраниях.
Несмотря на то что Scrum заимствует принципы и процессы из Agile, этому подходу свойственны свои методы и тактики управления проектами.
В какой-то степени возможна такая формулировка:
Преимущества Scrum
В подходе Scrum упор делается на 30-дневные спринты, или отрезки времени. Так, команда проекта делит список конечных целей на небольшие задачи, а потом работает над ними в течение 30-дневных периодов с ежедневными собраниями. Благодаря такому подходу проще справляться с большими сложными проектами.
Благодаря разбивке работы на 30-дневные периоды с ежедневными собраниями разработка и внесение изменений происходят довольно динамично.
Поскольку подразумевается самоорганизация команды проекта, участники четче понимают и знают проект. А еще лидеры проекта могут самостоятельно расставлять приоритеты согласно своим знаниям и возможностям.
Кроме перечисленных, этой методологии свойственны все преимущества Agile: быстрое внесение изменений и регулярная обратная связь с заинтересованными сторонами.
Недостатки Scrum
Поскольку дата завершения проекта не установлена и отсутствует менеджер проекта, который занимался бы планированием и бюджетом, Scrum может стать причиной неконтролируемого расширения масштабов проекта.
Поскольку команда проекта занимается самоорганизацией, увеличивается риск провала, если команда недисциплинирована и немотивирована. Если у команды недостаточно опыта, работа в рамках Scrum с большой вероятностью закончится неудачей.
Акцент на команде проекта означает, что уход любого ресурса окажет значительное воздействие на результат. Также этот подход недостаточно гибок для больших команд.
Для каких проектов лучше всего подойдет Scrum
Методология Scrum лучше всего подойдет опытным, дисциплинированным и мотивированным командам, которые умеют расставлять свои приоритеты и имеют четкое представление о требованиях проекта.
Ей свойственны все преимущества и недостатки Agile. Ее можно применять для работы над большими проектами, но она не подходит командам со множеством участников.
5. Метод критического пути (Critical Path Method, CPM, МКП)
Описанные выше методологии управления проектами появились в сфере разработки ПО. И хотя их можно использовать для проектов, не связанных с разработкой, существует ряд альтернатив, которые лучше подойдут для проектов иного типа.
Одна из наиболее популярных альтернатив — это метод критического пути (CPM).
В рамках метода критического пути вы классифицируете все действия, которые необходимо выполнить, чтобы достигнуть цели проекта в рамках Иерархической структуры работ (Work breakdown structure). После этого вы определяете длительность всех задач и зависимости между ними.
Преимущества метода критического пути
Благодаря акценту на длительности активностей и взаимосвязях между ними вы сможете лучше спланировать задачи. Если для выполнения задачи X сначала нужно завершить задачу Y, CPM поможет вам определить это заранее и распланировать все должным образом.
Успех метода критического пути зависит от определения и планирования критических важных задач и задач второстепенного значения. Определив задачи, вы сможете оптимально распределить ресурсы.
Недостатки метода критического пути
Любой опытный менеджер по управлению проектами скажет, что на все всегда уходит больше времени, чем планировалось. Если у вас нет реального опыта планирования, вы наверняка неправильно рассчитаете время на выполнение задач.
Как и в Waterfall, первый этап работы здесь громоздкий. Необходимо все распланировать с самого начала. Если появятся изменения, весь план будет уже не важен. Именно поэтому эта методология не подходит для проектов с меняющимися требованиями.
Для каких проектов лучше всего подойдет метод критического пути
Метод критического пути лучше всего подойдет проектам, в которых есть взаимозависимые части. Если необходимо выполнить задачи одновременно или необходимо завершить одну задачу перед тем, как перейти к другой, эта методология управления проектами подойдет.
CPM хорошо подходит для сложных проектов, в рамках которых часто повторяются задачи и действия, например, для промышленных проектов. Для динамичных проектов, к примеру, творческих, она подходит в меньшей степени.
6. Метод критической цепи (Critical Chain Project Management, CCPM)
Метод критической цепи — одна из относительно новых методологий управления проектами. Она была разработана в качестве альтернативы методу критического пути с акцентом на управлении ресурсами.
Вы намечаете результаты работы, а потом используете свой опыт, чтобы спланировать задачи для достижения целей проекта. Вы также определяете взаимозависимость между ресурсами проекта и назначаете их на каждую задачу соответственно.
CCPM уделяет большое внимание использованию ресурсов и минимизации снижения производительности. Эта методология основывается на однозадачности, то есть сосредоточенности на одной задаче и недопущении многозадачности.
Преимущества метода критической цепи
Благодаря акценту на правильном управлении ресурсами, метод критической цепи — одна из наиболее ресурсоэффективных методологий. Однозадачность также отлично подчеркивает современное понимание неблагоприятных эффектов многозадачности.
CCPM не ставит целью поиск наиболее благоприятного решения проблемы. Напротив, приоритет отдается поиску «достаточно хороших» решений, которые помогают в достижении конечной цели. Поскольку работа строится от конечной цели, CCPM, как правило, позволяет достичь лучших результатов в рамках сложных проектов.
Недостатки метода критической цепи
Поскольку этот метод управления в значительной степени сосредоточен на ресурсах, он применим лишь в однопроектной среде. В многопроектной среде ресурсы могут быть задействованы в нескольких проектах. CCPM не поддерживает сценарий распределения ресурсов между несколькими проектами.
CCPM учитывает буферы — временные промежутки между задачами – в общем времени задач. В теории это может привести к переоценки ресурсами своей эффективности. Но в реальности это приводит к неоправданным задержкам.
Для каких проектов лучше всего подойдет метод критического цепи
Эта методология управления проектами лучше всего работает в случаях, когда все ресурсы заняты на одном проекте. Но если ваши ресурсы заняты сразу в нескольких проектах, будет сложно спланировать их работу.
Метод критической цепи также идеально подходит командам с ограниченными ресурсами. Если вам постоянно приходится работать сверх нормы, и вы уже не знаете, как не срывать сроки проекта, методология CCPM может оказаться кстати.
7. Интегрированная система управления проектами (Integrated Project Management, IPM)
Подход IPM появился как ответ на растущий интегрированный характер креативных кампаний. Например, недостаточно просто сделать рекламу. Ее нужно интегрировать в микросайты, цифровой контент и т.д. В большинстве случаев креативные проекты являются частью более крупных кампаний.
Комплексный проект состоит из следующих компонентов:
Устав проекта → объем работ → план → выполнение → мониторинг → контроль за изменениями
Повсеместное внедрение процессов интегрированной системы управления позволяет менеджерам лучше понимать суть проекта и находить подходящие ресурсы.
Таким образом, IPM идеально подходит для креативных агентств.
Преимущества интегрированной системы управления
Внедрение одинаковых процессов во всей компании позволяет увеличить прозрачность процессов в организации. Подход IPM подразумевает, что члены проектной команды ведут документацию и регулярно встречаются, благодаря чему они все всегда в курсе ситуации.
Из-за комплексности подхода IPM вся команда проекта несет за него ответственность. Поскольку ни один сотрудник не работает изолированно от других, IPM позволяет улучшить подотчетность.
Недостатки интегрированной системы управления
В рамках подхода IPM вам придется подробно планировать работу заранее и следить за тем, чтобы все процессы были правильно интегрированы. Это существенно увеличивает вашу загрузку и может привести к задержкам завершения проекта.
Для каких проектов лучше всего подойдет интегрированная система управления
Методология подойдет для больших агентств с разноплановыми командами и процессами. Лучше всего она подходит для сложных творческих проектов, в которых задействованы ресурсы из разных команд и отделов, для организации взаимодействия.
8. PRiSM
PRiSM (Projects integration Sustainable Methods, Устойчивые методы интеграции проектов) — это методология управления проектами, разработанная Green Project Management (GPM) Global.
Методы управления проектами
В последние годы набирает популярность проектный менеджмент. По сути, это проектный подход к достижению целей. В рамках этого подхода компании разной величины, работающие в разных сферах бизнеса, создают проектные команды для решения тех или иных задач (выполнения проектов). Для координации действий сотрудников, работающих над этими задачами, используют разные методы управления проектами. В статье упоминаем самые популярные из них, а также рассказываем об их особенностях.
Понятие методов управления проектами
Чтобы уяснить, что представляет собой термин, надо знать его определение и определения других близких понятий, которые к тому же часто путают:
Существует много методов проектного управления, но на практике ни один из них не позволяет решать глобальные цели компании (лишь задачи), поэтому руководитель должен знать хотя бы основные, чтобы уметь выбирать из них подходящие для разных ситуаций.
Краткая история проектного управления
Проектное управление использовалось ещё во времена строительства египетских пирамид, хотя данные о применяемых тогда способах или системах управления не сохранились. Поэтому принято считать, что зародился проектный менеджмент в 50-е гг. ХХ века в США, когда там разработали методики сетевого планирования в рамках работы над Polaris Missile Project. Проект предполагал создание одноимённых баллистических ракет для атомных подводных лодок, причём сначала надо было провести научные исследования, а потом уже наладить производство.
В общем, было задействовано больше 3800 подрядчиков, но они управились с задачами даже раньше срока. Опыт управления ими и координации их работы впоследствии взяли за основу большие корпорации, чтобы сохранять конкурентоспособность в условиях изменчивого рынка. Так стал развиваться проектный менеджмент. Методики сетевого планирования, использованные в проекте Polaris Missile Project, стали базой для разработки методов проектного управления.
Сегодня существуют также системы управления проектами, которые используют разные компании, чтобы ускорять, контролировать и координировать работу нескольких специалистов по достижению целей.
Базовые термины проектного управления
Популярные подходы и методы управления проектами
Прежде всего следует описать вышеупомянутую каскадную модель, поскольку это наиболее простой способ управления. Работы по продукту разбиваются на этапы, а те выполняются последовательно.
Каскадная модель — это базовый подход, но сегодня он используется не так часто и преимущественно в строительстве и разработке инженерных систем, поскольку не даёт возможности изменять требования к проекту (если они изменятся, надо всё начинать сначала). Другое дело — Agile.
Agile
Это методология управления проектами, которая позволяет разбивать проект на инкременты (подпроекты) и работать над ними. Если нужно, можно вносить изменения, чтобы сделать продукт, отвечающий требованиям заказчика.
Agile широко используется при разработке инновационных продуктов, поскольку позволяет подстраиваться под изменяющиеся требования. На его основе был разработан ряд гибких методов, фреймворков, в том числе Scrum.
Scrum
Это методика управления проектами, помогающая организовать совместную работу. Чаще всего используется при разработке IT-продуктов, хотя её можно адаптировать под любые условия. Она, так же как и Agile, подразумевает деление проекта на части и определение самых важных частей, по которым в первую очередь будут проводиться работы. В ней есть спринты — временные отрезки на выполнение работ. Перед каждым из них можно ещё раз обсудить требования и, если нужно, внести изменения. Также есть ежедневные обсуждения задач членами команды.
Это метод управления проектами и философская концепция для экономии ресурсов и получения наилучшего результата. Также предполагает деление проекта на подпроекты, но является более гибким, чем Scrum и используется там, где важно качественно реализовать все этапы задуманного. Это достигается ещё и за счёт того, что в этом методе нет чётких временных отрезков, что позволяет более скрупулёзно проработать все задачи.
Kanban
Это метод, предполагающий деление работы на этапы, которые изображаются в виде столбцов. Задачи прописываются на карточках, а те — перемещаются по этапам. При этом ограничений по времени нет, важно просто завершить процесс. Если надо, количество задач можно менять, выполняя их по принципу приоритетности.
Kanban — один из основных методов управления проектами, которые широко используются в разных компаниях. Но у него есть существенный недостаток — отсутствие жёстких дедлайнов, из-за чего он может не подойти некоторым командам.
Six Sigma
Это методология, которая по большей части позволяет управлять процессами. Её основная задача — исключить брак производства (её разработал инженер «Motorola»).
К слову, у Six Sigma есть ряд инструментов (регрессионный анализ, кривая Парето и т. д.).
PRINCE2
Это методика управления проектами, которая широко используется во многих странах. И всё благодаря тщательному планированию, грамотной организации работы на каждом из этапов проекта и своевременному устранению недоработок.
Основной недостаток — отсутствие инструментов для проектной работы.
Другие методы
Чаще всего используются:
Как выбрать метод управления проектами
Следует отметить, что универсальной методологии не существует, её надо выбирать индивидуально под каждый проект. При выборе ориентируйтесь на цели, масштаб проекта, сложность, сроки выполнения, поскольку одни методологии позволяют ускорить работу, в то время как другие — сделать её более основательной, исключить риск возникновения неполадок, брака.
Также может иметь значение индустрия, ведь есть методологии, которые применимы только в программировании. Ещё один момент — профессионализм команды и её дисциплинированность.
Выводы
Есть разные методы, методологии и методики управления проектами, у каждой из которых свои задачи и возможности. Хорошо, если руководитель будет разбираться хотя бы в основных методах, чтобы выбрать оптимальный для того или иного проекта. Это может быть методология Agile и её фреймворк Scrum (последний незаменим там, где нужны быстрые результаты), Lean (позволяет выдерживать стабильно высокое качество и экономить ресурсы), Kanban (применяется, если не так важны дедлайны) и др.
Методологии управления проектами: водопад, эджайл
В предыдущей части мы разбирались, что такое проект и зачем нужен менеджер проектов. Сегодня углубимся в тему и поговорим о инструментах, которые менеджер использует в работе.
Методологией в управлении проектами называется стандартизация проведения проектов. Под стандартизацией здесь подразумевается описание шагов работы, чеклисты к проверке – эдакая канва, в которую можно закинуть проект, и он под присмотром менеджера приплывет к завершению и готовому продукту. Так как каждый проект в той или иной степени уникален, методология не панацея, думать все-таки придется.
Методологий управления проектами великое множество – они бывают используемыми только в одной компании, бывают глобальными. Методологии бывают в виде инструментов (типа Agile), бывают в виде большой книги с набором этих инструментов (PMBoK, тоже методология).
В жизни я использовал и использую две, самые популярные методологии – Waterfall (“водопад”/“каскадная”) и Agile (и его ответвление – Scrum), о них и пойдет речь. Ради расширения кругозора читателя расскажу и о других известных мне вещах. Если читатель работает с диджитал, то “водопада” и “эджайла” хватит за глаза – можно будет использовать их в работе, жизни, рассказывать знакомым и незнакомым людям, на митапах, с умным видом попивая смузи.
Само собой, ничто ниоткуда не берется, и Петр Первый ничего не слышал про эджайл. Методологии придумываются всякими разными организациями и ассоциациями, где умные дядьки собирают свои проблемы в кучи, затем понимают, как их можно было избежать, и делятся после решениями с такими обывателями как я, например. Иногда продумывание методологий происходит на государственном уровне – там тоже решают проблемы и собирают best practices (в приличном обществе так не выражайся) в книги и руководства.
Речь сегодня пойдет в основном об этих двух зверятах. После прочтения этого раздела можешь смело идти и требовать себе самое классное место менеджера проектов в самой крупной подходящей организации города.
Водопад, каскадная методология – традиционная, самая популярная и логичная методология управления проектами. В чистом виде может сработать совсем в простых проектах. Допустим, тебе потребовалось посадить дерево. “По водопаду” выполнение проекта выглядит так:
Каждый этап в таком проекте идет следом за предыдущим и не может быть выполнен раньше предыдущего – это и есть “водопад”. Еще это пересекается с “методом критического пути”, но о нем расскажу в отдельной статье – напомни мне.
Я работаю с проектами в сфере разработки сайтов и мобильных приложений. Этапы разработки таких проектов по водопаду примерно одинаковы:
Чтобы двигаться по водопаду, нужно иметь четкое техническое задание и понимание шагов, следующих друг за другом. Из практики скажу, что работать по чистому водопаду нереально – обязательно где-то выясняется, что что-то упустили, где-то нужно откатиться на предыдущий этап и делать это параллельно с текущим этапом. Тем не менее, чем четче техническое задание, тем меньше шансов на то, что проект уйдет в сторону. Для проектов, где “уход в сторону” приемлем, есть Agile.
“Эджайл” (или “агиль”, или “а жаль” – много у него прикольных названий) относится к типу гибкой методологии. Главное его отличие от водопада – рабочий продукт на каждом этапе работы и неясный финал проекта. В примере с тем же деревом, где каждый этап последователен, этот эджайл не покатит: ну купил ты саженец, а толку? У эджайла достаточно широкая область применения, однако более всего он прижился в IT. А его виды и подтипы толстой пленкой накрыли прилегающие сферы – бизнес-планирование, продуктовый менеджмент и так далее, и тому подобное.
Для примера работы “по агилю” представим проект посложнее. Пусть это будет проект из строительства. Задача: построить дом, где можно жить.
Этапы производства (представим, что каждый этап занимает ровно спринт):
Пусть в состоянии MVP (минимальный жизнеспособный продукт), но этим домом можно будет пользоваться примерно после первого этапа – не очень комфортно, но можно. Также “по эджайлу” этапы могут не следовать друг за другом, а идти параллельно или в разном порядке. Ключевой момент: на каждом этапе реализации продукта продуктом можно пользоваться.
Чтобы фиксировать этапы, умные дядьки придумали спринты, каждый из которого содержит набор операций и сроки (чаще равные) их реализации и планируются непосредственно перед спринтом. Задачи, прилетающие в процессе спринта складываются в бэклог – корзинку с тем, что при следующем планировании спринта кто-то будет разгребать. Ну и еще одна особенность эджайла: у проекта может не быть технического задания – вот думали вы строить одноэтажный таунхаус, а в процессе решили, что для вас окей построить шестиэтажный особняк и вы вот его строите, гибко меняя планы в процессе производства.
Agile используют в IT (“диджитале”) – лучше всего он живет в стартапах, когда финальный проект не ясен, нужно проверять гипотезы и делать это быстро и гибко. Эджайл удобно использовать в проектах стороннего клиента (не из компании), когда финал проекта не ясен и у клиента тысяча тысяч идей по ходу разработки. В таком случае определяешь, сколько времени команды в неделю можешь выделить, считаешь стоимость этого времени и выставляешь счета в финале каждого спринта.
Если ты работаешь со внешними клиентами, эджайл гораздо удобнее водопада в любых проектах – ты же знаешь, сколько комментариев клиент может выдать на каждом этапе проекта и как сложно объяснить клиенту, что его комментарии превышают заложенное время на разработку, а значит и бюджет проекта. Доплачивать-то он вряд ли будет – есть же смета, и ты вроде как профессионал, должен был сразу понять, что ему вообще нужно. Эджайл работает с понимающими клиентами, остальным будет крайне сложно объяснить, почему это окей.
Еще одна особенность методологии: в ней нет как такового менеджера проекта. Есть владелец продукта, скрам-мастер (в Scrum), члены команды. То есть, менеджер здесь выступает в роли владельца продукта и делает примерно то же самое, что делает при любой другой методологии. Внутри любой проектной команды продакт-оунером выступает менеджер проекта – он заказывает продукт у команды, а не тот человек, который брифует менеджера.
В одно семейство с эджайлом (“гибкие методологии”) входят Scrum, XP и Lean – хипстерские вещи из мира стартапов – читайте интернеты.
Никакая методология не панацея. Ближайшую аналогию могу провести с чеклистами – это такая классная штука (читай статью на моем медиуме @salakhmir), которая люто помогает в работе, но, почему-то, работает не у всех. Любой инструмент – всего лишь инструмент, и сам по себе работать не будет. Представь, что лопату положили на землю и ждут, когда что-то произойдет – так и тут, чтобы что-то сделалось, нужно что-то сделать.
Преимущественно использую гибридную методологию (и водопад, и эджайл), где есть техническое задание, понятны этапы, но случаются отклонения по ходу проекта. Со стороны может казаться, что творится хаос, главное делать лицо с понтом всё идёт по плану. Часто отклонения уходят в отдельные проекта, но чаще остаются внутри текущего и тянут за собой увеличение времени (бюджета) проекта. Кажется, это плохо, но момент политики в работе с людьми (мы же работаем с людьми, а не с сайтами, помнишь?) исключать нельзя.
Эти организации, по большей мере, именно управляют развитием методологий – развивают их такие же менеджеры, каким однажды станешь ты. В мире их не так много, но все они дико важные – за деньги и время можно получить их дипломов и ходить на собеседования, поражая интервьюеров.
Project Management Institute – наш друг. Питаю к этой организации особую привязанность – у них мощная комьюнити и хорошая база. Организация базируется в США, существует с 1969 года, а их стандарты управления проектами признаются ANSI.
Основной продукт PMI – свод знаний по управлению проектами PMBoK, осенью 2017 года вышла шестая часть. Свод знаний содержит канвы выполнения проектами в мелочах – от сбора требований стейкхолдеров до закрытия проекта. Рекомендую хотя бы ознакомиться с книгой – в ней же можно почитать и про ватерфолл с эджайлом, и про метод критического пути и метод быстрого прохода – темы одной из будущих моих статей.
Дополнительно к PMBoK у PMI есть такие основные вещи: стандарты управления портфелями (проектов) и программой, стандарты управления рисками и Scrum Guide. PMBoK – не IT-книга, методики из свода применимы фактически ко всем проектам (для некоторых типов есть отдельные расширения) – маст хэв, в общем.
У PMI куча куч видов сертификаций, со ступенями и наворотами. Сертификаты PMI известны и популярны. Например, PMP – профессионал управления проектами – типа подтверждает, что ты можешь руководить проектами. Получить сертификаты организации не имея опыта нельзя, потому они больше как подтверждение, нежели как этот твой университетский диплом, который ты получил, пока учился учиться.
Международная Ассоциация Управления Проектами – такая же организация, как PMI, только европейская (Швейцария), и о ней меньше слышно. Работает с 1965 года, и изначально называлась Internet (когда интернета в помине не было).
Что они там делают – понятно мало. Ну, сертифицируют менеджеров. Выпускают свои журналы – сами и под представительствами. Зарабатывают деньги. И слава Б-гу.
“Принц” (PRojects IN Controlled Environments). Появилась методология в 1989 году, в Великобритании (и тут отделились). Ключевой особенностью методологии является польза, которую принесут процессы внутри проекта проекту. Минимизация рисков, соблюдение качества проекта. Еще у проектов PRINCE2 сложная организационная структура с комитетом проекта. В остальном, такие проекты, как проекты по другим методологиям, имеют старт, этапы и завершения – все знакомо и привычно.
«A Guidebook of Project and Program Management for Enterprise Innovation». Японская методология управления проектами – на этот раз свежее, она 1999 года. Тентаклями тут является акцент на инновации и управление ожиданиями заинтересованных лиц. Близко не сталкивался, не изучал, оценки дать не могу.
“Частная” методология управления проектами, MSF, была придумана и введена в работу в 1994 году майкрософтом. Она особенна тем, что разрабатывалась непосредственно под разработку программного обеспечения, а не адаптировалась, что можно сказать о том же PMBoK. Внешне похожа на список внутренних рекомендаций (типа как у вас в интре) для менеджеров проектов. В чистом виде не используется даже Microsoft – добавляют тот же эджайл, например. В википедии есть познавательная статья об этом фреймворке, прошу пройти туда – там больше, чем могу рассказать я.
Ничто не панацея, но понимать принципы и брать из них лучшее можно и нужно. Пока писал статью, краем глаза наткнулся на статью о Стаханове – был такой чувак при Советах, его еще в советской пропаганде продуктивности использовали. Он тоже работал по методологии (уголь добывал), но однажды понял, что если чуток переставить людей и пустить некоторые процессы параллельно, можно работать лучше. Вот и заработал себе страницу в википедии. Так и здесь – тестируй, применяй и дорабатывай (потом делись). Все, с чем ты сталкиваешься, все советы – гипотеза, которую нужно проверить. Enjoy it!
В следующей части постараюсь рассказать про планирование задач и времени, включая собственный микроменеджмент. Статья должна помочь не только начинающим менеджерам, но и тем, кто с ними работает. Если хватит запала, то статья будет прям на этой неделе. Пишите письма.