June 5

Принципы управления проектами

Привет, Олимпийский!

Управляя проектом или продуктом все менеджеры следуют некоторым принципам. Эти принципы следуют из определений проекта, управления проектом и руководителей проектов.

Основная статья про принципы управления проектами находится в Клубе: https://pmi.moscow/post/52/ Пожалуйста, присоединяйтесь для обсуждения!

ПРЕДЕЛЕНИЕ

Принципы проектного управления - это набор формальных и неформальных критериев и правил, а также набор мыслей (Прим.: "Mindset", как лучше сформулировать я не придумал), которым следуют руководители проектов и члены проектных или продуктовых команд в своей повседневной деятельности.

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

Принципы управления проектами

Принципы Agile

Agile - как же много о нём слышно! Agile был придуман инженерами по разработке программного обеспечения, и является реакцией снизу для улучшения процессов разработки ПО и сам по себе является не каким-то фреймворком, а скорее "набор мыслей" (mindset в прямом смысле этого слова). Давайте же ознакомимся, что же написано в Библии Agile?

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

Принципы Agile-manifesto

Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:

- Люди и взаимодействие важнее процессов и инструментов.
- Работающий продукт важнее исчерпывающей документации.
- Сотрудничество с заказчиком важнее согласования условий контракта.
- Готовность к изменениям важнее следования первоначальному плану.

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Вчитавшись в принципы Agile Manifesto трудно не обратить внимание, что все описанные принципы логичные и соответствуют "здравому смыслу", и трудно с ними не согласиться в принципе. На мой взгляд, все IT-компании по всему миру, независимо от используемого подхода, соответствуют этим принципам. Даже в случае использования Водопадного подхода (в реальной жизни чистый Водопадный подход никто не использует) всегда возможны изменения с помощью дополнительных актов, изменения нормативов и всему такому.

Принципы Agile (и с ними все просто и сложно одновременно)

  • Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
  • Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
  • Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
  • На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
  • Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
  • Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
  • Работающий продукт — основной показатель прогресса.
  • Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
  • Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
  • Простота — искусство минимизации лишней работы — крайне необходима.
  • Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
  • Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Четкое следование принципам Agile - сродни искусству, да и не всегда возможно в принципе.

  • Представьте, что конечный продукт - это бэкенд-сервис, который выполняется на сервере. Как же можно обеспечить раннюю поставку уже полезного сервиса? Что это может означать? Ну вот, допустим, разработали каркас сервиса, который умеет запускаться, выполнять одну функцию и писать логи - такой сервис полезен ли для заказчика? Разве можно такой сервис отдавать пользователям? А готов ли заказчик принимать активное участие на первых этапах разработки сервиса?
  • Другой пример, где найти команду высокомотивированных профессионалов, которые таковыми останутся на протяжении всей разработки? Если конечный продукт достаточно большой (а не стартап, или маленькое приложение), то он разрабатывается большим количеством людей с разной квалификацией и целями.
Подробнее про недостатки Agile принципов и SCRUM Framework можно почитать в "Черной Книге Скрам" от И. Селиховкина.

Фундаментальные принципы проектного управления

Если у проекта существуют ограничения по срокам, стоимости и/или содержанию, то применение принципов Agile основанных на тех или иных реализаций, таких, как SCRUM, Kanban, Lean не всегда оправдано по причине отсутствия гарантий по получению конечных результатов, соответствующих заданным ограничениям. Тот же SCRUM не может предиктивно оценить срок завершения разработки проекта, пока не вычислит истинную среднюю мощность команды.

<картинка здесь>

В таком случае, предлагается следовать фундаментальным четырем принципам управления проектами, которые неявно описаны в Библии проектного управления - PMBoK.

Информация взята из источника: https://infostart.ru/1c/articles/889250/

Принцип неизменности границ

Как ответ на вызовы конечности и неопределенности, родилось проектное управление. Появился принцип "яйца". Что символизирует куриное яйцо? Представьте, курица снесла яйцо и садится его высиживать. Яйцо сразу конечного размера, то есть скорлупа уже больше не увеличивается. И скорлупа – это аналог того, что называется «устав проекта». В каждом проекте обязательно есть такая вещь, как устав. В уставе фиксируются неизменные ограничения проекта - стоимость, сроки и кратко его суть (содержание). И сколько бы курица ни сидела, яйцо больше не растёт. Это жесткие рамки, в которые проект должен уложиться, и мы обязаны уложить его в эти рамки любой ценой

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

На протяжении проекта устав неизменен, а планы меняются, расширяются. Это очень важное правило – скорлупу трогать нельзя. Если вы расковыряли пальцем скорлупу яйца, то результат у вас уже не получится, высидеть яйцо будет невозможно. Точно так же и с проектом: если вы устав нарушили, этот проект надо перезапускать. Если яйцо сначала высиживала курица, а потом вы решили, что это должен делать крокодил, то придется брать уже другое яйцо.

Задача менеджера проекта – обеспечить, чтобы внутреннее содержимое не переросло ограничения, чтобы белок и желток не стали больше самого яйца. Если скорлупа лопнет, проект тоже не получится. И PMBoK – это пособие о том, как впихнуть то, что не вмещается, как яйцо удержать в скорлупе.

Принцип завершенности и цикличности

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

Внутренний клубок процессов - это ни что иное, как цикл Деминга.

PDCA циклически повторяющийся процесс принятия решения, используемый в управлении качеством. Также известен как Deming Cycle, Shewhart cycle, Deming Wheel или Plan-Do-Study-Act. Также известен как принцип Деминга-Шухарта, но Деминг предпочитал PDSA у Шухарта.
  • Планирование (P) - установления целей и процессов, необходимых для достижения целей, планирования работ по достижению целей процесса и удовлетворения потребителя, планирования выделения и распределения необходимых ресурсов;
  • Выполнение (D) - выполнение запланированных работ;
  • Проверка (C) - сбора информации и контроль результата на основе ключевых показателей эффективности, получившегося в ходе выполнения процесса, выявления и анализа отклонений, установления причин отклонений;
  • Воздействие (A; управления, корректировки) - принятия мер по устранению причин отклонений от запланированного результата, изменений в планировании и распределении ресурсов.

Принцип проактивности

Проактивность – это антоним реактивности. Что такое реактивность? Когда что-то загорелось, побежали – потушили. А проактивность – это мы сидим и думаем, как бы так сделать, чтобы не загорелось никогда, а если загорится, чтобы мы быстро справились. Фактически, проактивность - это управление рисками. Превентивное.

Принцип командности

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

Проект - это всегда человеческое взаимодействие. То, насколько хорошо налажена коммуникация в проекте, определяет качество руководителя. Очень простая логика: проектное управление не предполагает, что вы, как руководитель, можете взять и сделать проект самостоятельно. Понадобятся знания большого количества экспертов в разных доменах, которые вам нужно объединить. Вы – интегратор в первую очередь. Принцип командности говорит о том, что вся команда участвует в формировании планов. Планы пишутся всей командой – вами и вашими сотрудниками. Одному чрезвычайно тяжело, а порой и невозможно, учесть все нюансы и риски.

Набор почти универсальных проектных принципов

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

  • NUP1: выбирай результаты и истину, а не привязанности
  • NUP2: береги и оптимизируй энергию и ресурсы
  • NUP3: всегда будь проактивен
  • NUP4: помни, что прочность цепи определяется по самому слабому звену
  • NUP5: не делай ничего без четкой цели
  • NUP6: используй воспроизводимые элементы

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

Шесть принципов высокого качества обслуживания

Нашел тут статью: https://www.prostoy.ru/642.html - любопытно. Хорошая мысль - начинать с конца.

  • ВИДЕНИЕ И МИССИЯ ПРОЕКТА
  • БИЗНЕС ЦЕЛИ
  • СТРАТЕГИЯ ВМЕШАТЕЛЬСТВА И ВЫПОЛНЕНИЯ ПРОЕКТА
  • ОРГАНИЗАЦИОННОЕ ВЫРАВНИВАНИЕ
  • ИЗМЕРЕНИЕ И ОТСЛЕЖИВАЕМОСТЬ

ЗАКЛЮЧЕНИЕ

Следовать принципам - важно. Надеюсь, что вам понравилась статья, увидимся в будущих сериях.

❤️Meow! ❤️