Методологии управления проектами: как сделать выбор? | JET BI

Методологии управления проектами: как сделать выбор?

Категория: Salesforce FAQ
Опубликовано: Июнь, 01, 2020

Доводилось ли Вам слышать мысль о том, что “проджект менеджер это - тамада”. ПМ управляет этим веселым хаосом, происходящим на проекте, структурируя работу каждого члена команды, налаживая коммуникацию и подбирая грамотные слова в общении не только с заказчиком, но и со своей командой. И весь этот балаган в итоге превращается в налаженные процессы, где каждый участник проекта прекрасно знает свой объем работы, свою зону ответственности и итоговый результат, к которому все синхронно движутся.

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

Методологий управлениями проектами великое множество и каждый вариант призван стандартизировать шаги работы и чек-листы на каждом этапе, ведь каждый проект по своей сути уникален и может быть реализован абсолютно разными инструментами управления. Методология может являться как инструментом, если мы говорим, например о Agile, так и способом применения тех самых инструментов, если мы вспомним о PMBoK.

К слову, у Agile достаточно широкая область применения и данная методология управления проектами отлично прижилась в качестве инструмента в современной IT-индустрии. Agile является наиболее узнаваемой методологией управления проектами, которая лучше всего подходит для итеративных и инкрементных проектов. Это тот тип процесса, в котором требования и решения развиваются благодаря совместным усилиям самоорганизующихся и кросс-функциональных команд в кооперации с клиентом.

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

 

Некоторые методологии управления проектами просто определяют принципы, например Agile. Другие определяют методологическую структуру “full stack" тем и процессов, такие как Prince2. Отдельные методологии представляют собой обширный список стандартов с определенным процессом, как например методология PMI PMBOK, а некоторые очень легкие и просто определяют сам процесс, можно привести Scrum в качестве примера.

Одним из самых популярных ответвлений Agile как раз и является Scrum. Вероятно, это самая популярная методология на данный момент. Ведь в мире, где всё стремительно развивается и меняется, необходимо быть довольно гибким и подвижным. А SCRUM как раз и предусматривает управление проектом как поступательную и итеративную проектную методологию. Главной особенностью Scrum является то, что в начале выполнения проекта точно неизвестно, каким должен быть конечный продукт и каким будет жизненный цикл проекта.

Scrum базируется на пяти ценностей:

  1. Целеустремленность;

  2. Смелость;

  3. Сосредоточенность;

  4. Открытость;

  5. Уважение.

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

В соответствии с данной структурой команда состоит из нескольких составляющих и ответственность за результат делится между тремя основными ролями:

Product owner: эксперт по продукту, который представляет интересы заинтересованных сторон и является голосом клиента;

Dev team: группа профессионалов, которые поставляют продукт (разработчики, дизайнеры);

Scrum мастер: организованный лидер, который обеспечивает понимание и выполнение Scrum задач.

Исходя из опыта, точно можно сказать одно, какой бы гибкой методология ни казалась, могут возникать проблемы. Вот лишь самые распространённые:

  1. Применение Scrum методик занимает много времени - для того,чтобы прошерстить бэклог и проработать каждую задачу нужно достаточное количество времени. Также много времени уходит на довольно-таки важные вещи, как kick-off спринт митинги и те же самые ретроспективы. Это действительно упрощает жизнь, когда процессы налажены, но всё ещё отнимает значительную часть вашего времени. Плюс одной из задач проджект менеджера является фасилитация и умение организовать митинги таким образом, чтобы они не затягивались на половину вашего рабочего дня;

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

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

  4. Заказчику все кажется приоритетным - ещё одна проблема гибкости, когда каждая новая фича и доработка заказчику кажется самой приоритетной и необходимой прямо сейчас. Отсюда переносы сроков доставки либо бесконечные движения одних и тех же задач из спринта в спринт.

 

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

А пока мы можем подойти к еще одной популярной методологии реализации проекта - Kanban. Это еще один гибкий фреймворк, который, как и Scrum, фокусируется на ранних доставках с коллективными и самоуправляющимися командами. Концепция, которая была разработана на производственной линии заводов Toyota в 1940-х годах, является весьма визуальным методом, который направлен на достижение высокого качества результатов, рисуя картину рабочего процесса так, чтобы самые проблемные места можно было выявить на ранней стадии процесса разработки. Методология Kanban оперирует шестью общими практиками:

  1. Visualize - задачи, рабочий процесс, риски, метрики и всё остальное должно быть визуализировано;

  2. Limit WIP (Pull system, not Push) - необходимость фокусироваться, устранять узкие места;

  3. Manage flow - активное применение метрик и обсуждений;

  4. Make Explicit Process & Policies - понятные и доступные всем правила;

  5. Implement Feedback Loops / CI - постоянное улучшение;

  6. Improve Collaboratively, Evolve Experimentally (используя модели и научные методы).

Хотя нет никаких установленных правил Kanban как такового, в основном работа представлена с  помощью доски Канбана, чтобы представить этапы развития от самого начала, когда идеи презентованы, до момента, когда работа находится в самом процессе, и до самого последнего этапа, когда работа была завершена. Основная структура таких бордов состоит из трех столбцов, обозначенных как "To-Do, Doing и Done", что довольно логично. Таким весьма наглядным способом можно легко отслеживать статус работы и критичные моменты, которые будут визуально заметны. 

Как и большинство Agile фреймворков, Kanban внёс свой вклад в индустрию разработки программного обеспечения. Однако благодаря своей гибкости получил распространение в других отраслях и является одной из немногих методологий управления проектами, которые могут быть применены к любому проекту, требующему постоянного совершенствования в процессе разработки.

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

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

И помните, что вы тот самый тамада и именно вы управляете процессом!

 

 

Поделиться

Спасибо за то, что отправили форму. Мы свяжемся с Вами в течении 1-2 рабочих дней.
Узнавайте первыми о важных новостях и событиях из мира IT

О нас

Мы разрабатываем и внедряем решения класса Business Intelligence на базе платформ SAP BO/BW. Мы также предоставляем полный спектр консалтинговых услуг для Salesforce: внедрение Salesforce и индивидуальная доработка, поддержка, а также решения для ISV. Департамент Мобильной разработки специализируется на разработке бизнес-приложений на iOS и Android.

Связаться с нами

JET BI

Беларусь, Минск
220002, пр-т Машерова,19, 8 эт.
Телефон: +375 17 355 24 16

Проекты: sales@jetbi.com

Карьера: jobs@jetbi.com

Социальные сети