10 инструментов для управления проектами: эффективность, постановка задач и общение

Проблемы

Организация процесса

Наиболее типовую в России модель процесса производства программного обеспечения можно охарактеризовать следующим образом: «Каждый разработчик выбирает тот или иной метод или технику для создания программ в соответствии с собственными привычками и пристрастиями. Практически полное отсутствие четкой ответственности за выполнение тех или иных функций. Качество программного обеспечения является случайной величиной и напрямую зависит от способностей отдельных сотрудников компании. Практически все зависит от инициативы и деловых качеств нескольких личностей». Эта формулировка практически полностью соответствует 1 уровню CMM под названием «начальный». По некоторым источником, 2 года назад доля фирм-производителей программного обеспечения, использующих эту модель, составляла свыше 70%.

Вот какие выводы делает Мартин Фаулер , сравнивая процесс производства программного обеспечения с классическими типами строительства и производства:

в процессе производства ПО фаза непосредственного программирования (construction) гораздо дешевле всех остальных фаз (проектирование, тестирование и т.п.);
в процессе производства ПО все основные усилия направляются на проектирование. Процесс проектирования требует, чтобы в нем участвовали творческие и одаренные люди;
творческие процессы нельзя легко запланировать

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

Требования и итеративность

Классический процесс производства программного обеспечения, который использовался во всем мире вплоть до середины девяностых годов и который практически является символом эпохи структурного программирования, состоит из следующих шагов: обследование, постановка задачи, проектирование, программирование, тестирование и внедрение. Этот процесс называется «Водопад». Он подразумевает, что требования к программному продукту, собранные во время обследования и формализованные в процессе постановке задачи, зафиксированы и не меняются в течение всего производственного цикла. Однако, современный бизнес очень динамичен и смена требований в нем – обычное дело.

Фаулер пишет: «В процессе производства программного обеспечения все зависит от требований. Если вы не можете добиться устойчивости требований, вы не сможете создать предсказуемый план». Как же быть? С одной стороны требования должны быть устойчивыми, а с другой они будут неизбежно меняться в ходе проекта.

Ключ ко всему – итеративный процесс производства.

Планирование проектного времени

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

Структурная декомпозиция работ (СДР)

СДР – графическое отображение иерархии проектных работ – первый этап календарного планирования проекта. По сути, СДР – это разделение проекта на такие части, которые нужны и достаточны для планирования и эффективного контроля. Составление иерархической структуры предполагает соблюдения следующих правил:

  1. Исполнение работ верхнего уровня достигается путём исполнения работ нижнего уровня.
  2. Родительский процесс может иметь несколько дочерних работ, выполнение которых автоматически завершает родительский процесс. Но для дочерней работы существует только одна родительская.
  3. Декомпозиция родительского процесса на дочерние работы производится по единому критерию: либо по привлекаемым ресурсам, либо по видам деятельности, либо по этапам жизненного цикла и др.
  4. На каждом уровне должны быть собраны равнозначные дочерние работы. Критериями для выявления их однородности могут, например, выступать объём и время выполненных работ.
  5. При построении структуры в целом нужно применять разные критерии декомпозиции на разных иерархических уровнях.
  6. Последовательность для критериев декомпозиции выбирается так, чтобы максимально большая часть взаимодействий и зависимостей между работами оказалась на нижних уровнях иерархической структуры. Работы высших уровней – автономны.
  7. Декомпозиция работ считается завершённой, если работы нижнего уровня понятны менеджеру и участникам проекта, ясны способы достижения конечного результата и его показатели, однозначно распределена ответственность за выполнение работ.

На основе СДР создаётся список работ проекта. А далее определяется последовательность их выполнения, взаимосвязи с помощью организационно-технологических моделей и продолжительность работ.

Продолжительность работ

Продолжительность работ определяется на основе нормативов, на основе личного опыта (когда существует пример аналогичных работ), на основе расчётных методов планирования проектов. К таким методам относится, например, метод событийного анализа PERT, применяемый при неопределённости в оценке продолжительности операций. Существуют, однако, различные способы управления проектным временем.

  • PERT
    . Метод рассматривается как средневзвешенная трёх видов прогнозов: оптимистичного, ожидаемого и пессимистичного. После установления продолжительности по каждому прогнозу (с применением формулы и/или с привлечением экспертов) рассчитывается вероятность каждого из прогнозов. А затем значения каждого из прогнозов и их вероятности перемножаются, а величины складываются.
  • Сетевая диаграмма
    . Сетевой диаграммой называется отображение работ и зависимостей между ними в графическом виде. Чаще она представлена в виде графика, вершинами которого становятся проектные работы, а их последовательность и взаимосвязь демонстрируется соединительными стрелками.
  • Диаграммы Ганта
    . Это горизонтальная диаграмма с отображением проектных работ в виде отрезков, ориентированных по календарю. Длина отрезка соответствует продолжительности работы, а стрелки между отрезками – взаимосвязь и последовательность работ.

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

Цели и задачи использования систем управления

Рассмотрим основные цели использования систем управления:

  • Повышение КПД работников в рамках проекта.
  • Повышение эффективности управления со стороны менеджера.
  • Увеличение общей эффективности при управлении: сдача проекта в срок, минимизация сопутствующих трат.

Как ведется учет неопределенности и рисков инновационности при проектировании и управлении проектами?

Базовые задачи, которые ставятся перед системами управления:

  • Формирование инструментов для планирования и контроля над исполнением поставленных задач.
  • Формирование площадки, с помощью которой сотрудники получают доступ к сведениям, нужным для работы над проектом, а также к инструментам для решения текущих задач.
  • Возможность проверки загруженности того или иного сотрудника, для того чтобы принять решение о привлечении его к дополнительной работе.
  • Обеспечение эффективного перераспределения нагрузки.
  • Создание инструмента для автоматизации работы над рутинными делами.
  • «Прозрачность» статуса всех текущих проектов.
  • Возможность мониторинга изменений.
  • Контроль над сроками выполнения проектов.
  • Контроль над соответствием исполняемых проектов целям компании.

К СВЕДЕНИЮ! Очевидно, что системы управления важны как с точки зрения решения текущих задач, так и с точки зрения стратегии компании. Они незаменимы в том случае, если фирма ведет сразу несколько проектов. Если один проект можно полноценно контролировать без автоматизации, то в случае множественности заданий — это нерешаемая задача.

ВАЖНО! Различные отрасли предполагают использование систем управления со своей спецификой. К примеру, особые системы требуются для строительных, инвестиционных, инновационных, организационных проектов

Разрабатываем требования к проекту

Требования содержат подробную информацию о том, каким должен быть результат, и функции, которые он должен иметь. Они описывают конкретные потребности проекта

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

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

Первым шагом в разработке требований является сбор информации о том, что требуется. Есть несколько методов для сбора требований:

Интервью – отличный способ поиска информации. Ключ в том, чтобы выбрать правильных людей для интервью и подготовить список вопросов. Если в вашем проекте участвуют несколько групп, вы можете провести мозговой штурм, чтобы обсудить их требования к проекту. Другой подход – понаблюдать, как работают люди. Другими словами, следите за тем, что люди делают в своей повседневной деятельности. Чтобы убедиться, что вы правильно поняли требования, запишите их и рассмотрите с работниками. Анкеты и опросы являются еще одним способом получения требований от заинтересованных сторон

Важно тщательно их составлять, чтобы не влиять на полученные ответы. Если уже существует какая-то документация проекта с предварительными результатами, вы можете получить требования, проанализировав ее

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

Как стать менеджером проектов

Для начала нужно устроиться на стажировку в компанию или агентство, где можно наблюдать за работой проект-менеджера.

Сначала вас ждет работа стажера. В основном это задания “принеси-подай”. Стажер должен быть везде и помогать в мелочах всем членам команды. В это время можно слушать и запоминать все, что происходит вокруг. Со временем надо решаться высказывать свои мысли и переходить на второй уровень – помощник менеджера.

Третья ступень в карьерной лестнице – менеджер. Должность будет доступна, если вы будете полезны и обучаемы, у вас есть идеи и вы хотите их реализовать. Менеджер разрабатывает проекты, участвует в их реализации и контролирует работу младших сотрудников.

Старший менеджер – это лидер с большим опытом работы. Он стремится узнать как можно больше и сделать работу как можно эффективнее.

И только после этого следует менеджер проектов.

Где и как учиться

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

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

Серьезные и проверенные платформы: Skillbox, Нетология, GeekBrains.

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

После обучения вам выдадут сертификат или диплом, который станет подтверждением ваших знаний. Документ выдают авторы таких курсов, как:

  • Управление проектами
  • Профессия Руководитель Digital-проектов
  • Руководитель digital-проектов
  • Project manager
  • Факультет Проджект-менеджмента

Ознакомиться с полным перечнем онлайн-курсов вы можете в другой нашей статье.

Советы новичкам

Прежде чем посвящать себя этой профессии, убедитесь, что она вам подходит. Прочитайте истории опытных проект-менеджеров, попросите у них совета. Еще лучше – сходите на стажировку, чтобы своими глазами увидеть “кухню” изнутри.

Для тех, кто уже начал работать в этой должности, есть парочка рекомендаций:

внимательно слушайте клиента, а если не понимаете его, то переспросите;
тщательно подбирайте членов команды, они – ключ к успеху;
акцентируйте внимание на главных и реальных проблемах, умейте расставлять приоритеты;
будьте разумными – не заставляйте делать своих подчиненных то, что не можете выполнить сами;
будьте готовы к провалам;
держите наготове план “Б”.

Технологии решают все

 В вопросе использования программного продукта я не
хочу ставить под сомнение профессионализм тех преподавателей и известных учебных
центров, в которых
я училась. Но я понимаю, чем они
руководствовались. Действительно, если говорить о мировой практике, которая
сконцентрирована в PMBoK, то мы должны следовать золотому правилу: «7 раз
отмерь – один раз отрежь». Только для современного мира его нужно
немного преобразовать.

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

Теперь представьте себе, что компания решила поставить
процессы проектного управления без программного продукта и обкатать их в течение,
например, полугода. Что это будет означать
для рядового сотрудника? Появятся новые правила, новые документы, новые отчеты.
Появятся люди, которые контролируют
исполнение этих правил и качество этих документов. Появятся рычаги для
мотивации, то есть неисполнение правил или их нарушение будет влиять на
материальную составляющую конкретного человека. Итого – у вас в 2-3 раза больше
головной боли. И вам придется значительную часть времени и сил отдать
не на эффективное управление проектами, а на обеспечение «ручных» процессов.

Да, документы важны – их не может не быть. Они помогут
избежать рисков, зафиксируют решения и соглашения, помогут определить
необходимые правила для управления. Но в

«бумажном» виде это будет медленно, несвоевременно и даже опасно. Оформление
документов, их согласование, поиск документов среди почты, объединение данных
для отчетов руководству, быстрый сбор
статуса для принятия
решения – все это
станет ощутимой проблемой для управления, которая
может убить светлую идею
системного управления проектами.

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

Снова
дополнительная нагрузка.

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

Lean

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

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

Lean – подход к управлению и оптимизации бизнес-процессов, тем не менее, принципы, подходы и инструментарий бережливого производства активно используются в управлении проектами.

ТРИ “M”

Как и Agile, этот подход вращается вокруг принципов и ценностей, а не фиксированной методологии и строгих процессов.

Принципы Lean касаются трех основных форм отходов, или трех “M”.

  • Muda (потери) – Lean определяет семь различных видов потерь, которые могут быть искоренены. Некоторые из них включают транспортировку продукта, перемещение работников или машин, чрезмерную переработку и перепроизводство.
  • Mura (нерегулярность) – этот принцип направлен на оптимизацию рабочего процесса за счет уменьшения отклонений и устранения накладных расходов.
  • Muri (напряжение) – относится к устранению переутомления, стресса и перегрузки сотрудников. Это может быть результатом неадекватной организации, обучения или неправильных инструментов.

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

ПРИНЦИПЫ

Методология бережливого производства основана на пяти основных принципах:

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

Принцип вытягивания отличается от традиционных подходов: команда никогда не продвигается вперед и действует только тогда, когда клиент просит об этом

Принцип совершенства еще больше подчеркивает важность совершенствования и устранения отходов

СИЛЬНЫЕ И СЛАБЫЕ СТОРОНЫ

Доктрина бережливого производства, направленная на устранение ненужных процессов, может привести к снижению затрат и увеличению прибыли.

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

Кроме того, этот подход подчеркивает важность планирования и сотрудничества

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

ПРИМЕНЕНИЕ МЕТОДОЛОГИИ

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

Планирование проекта

Этап должен ответить на следующие вопросы:

  1. Что планируется сделать?
  2. Как планируется сделать?
  3. Какие события являются критериями завершения проекта?

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

Результатом завершения этого этапа должен стать документ «План проекта», который будет включать в себя следующие разделы (см. рисунок 3).

Рисунок 3. Структура плана проекта

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

Два других раздела итогового плана, о которых стоит упомянуть отдельно – это финансовая модель и план мероприятий. Приведем несколько основных тезисов, обязательных при формировании этих разделов.

  1. Финансовый план и план мероприятий должны быть синхронизированы.
  2. Финансовый план должен рассчитывать объем необходимых инвестиций и бюджеты проекта. Бюджеты могут быть разбиты по времени и подразделениям, но в сумме они должны быть сопоставимы с объемом запрошенных инвестиций.
  3. Финансовый план должен учитывать именно те ресурсы, которые будут предоставлены для его реализации. Из этого тезиса, например, возникает необходимость разделения учета расходов на персонал на операционную деятельность и непосредственно на реализацию проекта.
  4. Оба плана должны допускать возможность внесения изменений в рамках утвержденных процессов.
  5. Финансовый план и бюджет проекта должны быть синхронизированы с текущей учетной политикой компании. Неэффективно планировать расходы и доходы без возможности последующего сбора соответствующих фактических значений.

Планирование проекта – это сложный и порой дорогостоящий процесс

Самое важное на этом этапе понять два ключевых момента:

  1. Степень обоснованности доходной части проекта (если речь идет о проектах с запланированной отдачей на вложенный капитал). Недоработки в этой части были и остаются основной причиной неудач проекта.
  2. Способы управления рисками проекта. То, как команда проекта планирует управлять рисками, определит величину потенциальных убытков.

Проектные задачи – это всегда умение работать с неопределенностью.

Инициирование проекта

Инициирование проекта можно разделить на две части:

  1. Формирование устава проекта.
  2. Формирование команды проекта.

Устав проекта – это относительно небольшой по объему документ (6–7 слайдов максимум). Напомню, что мы говорим о внутренних проектах, где исполнитель и заказчик работают в одной компании. Устав проекта преследует следующие цели:

  • формальное одобрение использования ресурсов компании для последующих действий;
  • фокус внимания участников проекта на основных задачах проекта.

Устав проекта резюмируется в небольшую таблицу (см. таблицу 2).

Таблица 2. Резюме проекта.

Наименование проекта: Улучшение процесса обслуживания покупателей

Предпосылки:

покупатели выражают недовольство длительным сроком или отсутствием ответов на свои запросы

Участники проекта:

  1. Спонсор проекта:
  2. Заказчик проекта:
  3. Куратор проекта:
  4. Руководитель проекта:
  5. Команда проекта:

Цели:

  1. Обеспечить ответ на каждый запрос.
  2. Сократить средний срок решения запроса покупателя на 60%.
  3. Сократить количество повторных обращений на 80%

Критерии оценки:

  1. Среднее время реагирования на запрос покупателя.
  2. Количество повторных запросов.
  3. Результаты ежегодного опроса покупателей

Периметр проекта: подразделение Южного-Федерального округа

Допущения:

Документация проекта будет рассмотрена не позднее20 декабря 2019 г.

Проектная команда будет утверждена в предложенном составе

Ключевые вехи:

Утверждение проекта – январь 2020 г.

Анализ и протоколирование источников – февраль 2020 г.

Утверждение рекомендаций – апрель 2020 г.

Внедрение рекомендаций – май 2020 г.

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

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

УПРАВЛЕНИЕ СТОИМОСТЬЮ ПРОЕКТА

7.3. Определение бюджета

Бюджет проекта – это распределение стоимости проекта по времени.

Управленческие резервы — это деньги, который спонсор проекта отложил на «всякий случай»

«План по стоимости» — это бюджет проекта.

Стоимости делят на две важные группы:

  • стоимости ресурсов — состоят из стоимости людей, оборудования и материалов, требуемых для исполнения работ проекта,
  • денежные затраты — это затраты на оплату работ внешних исполнителей – поставщиков и подрядчиков. На рисунке эти затраты показаны кривой «Ожидаемый денежный поток»

«Резерв управления» – это превышение бюджета, вызванное выявленными рисками.

7.4. Контроль стоимости

Собираем все вместе  и контролируем календарный план проекта (MS Project):

Пример: The Practice Standard for Earned Value Management

Далее разберем:

  • управление качеством,
  • управление HR,
  • управление коммуникациями,
  • управление рисками,
  • управление закупками,
  • управление заинтересованными сторонами.
Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector