text
Коммерческий директор

Зона ответственности в проекте: как определить и контролировать

  • 20 февраля 2018
  • 668
Фото © shutterstock.com
Фото © shutterstock.com

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

Вы узнаете:

  • Почему важна зона ответсвенности в проекте.
  • Как формировать состав рабочей группы проекта.
  • Какие выделяют роли в эффективной проектной команде.
  • Как определить зоны ответственности в проекте с помощью матрицы.
  • Как составить эффективную матрицу зон ответственности.
  • Как руководителю следует контролировать зоны ответственности членов команды проекта.

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

Почему важна зона ответственности в проекте

Что такое зона ответственности в проекте? Это определенные области в рамках намеченной программы действий, реализация которых находится в компетенции конкретного члена команды. В современной литературе по менеджменту часто встречается очень узкая трактовка понятия «зона ответственности», что в практическом применении может стать причиной снижения эффективности деятельности и возникновения конфликтных ситуаций.

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

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

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

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

Четкое разграничение этих сфер позволяет:

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

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

Как формировать состав рабочей группы проекта

Специалисты рекомендуют при выполнении задач по реализации проектов внутри компании, к примеру, для внедрения коммуникационных систем использовать следующую структуру:

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

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

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

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

Мнение эксперта

Состав и количество участников проектной группы определяются индивидуально для каждого проекта

Франк Мюллер,
генеральный директор международной группы компаний AsstrA, Цюрих

В 2006 году мы внедрили проектное управление. Это решение было принято с целью реализации задач по таким направлениям, как:

  • увеличение процента дохода от продажи услуг при комплексном сервисе клиентов в общем объеме сбыта компании;
  • повышение качественного уровня услуг.

В первые месяцы 2007 года я сформировал департамент контрактной логистики и стал его руководителем. Эта структура была создана для управления проектами во всех подразделениях группы компаний. Система менеджмента качества AsstrA получила сертификат, подтверждающий соответствие стандартам ISO 9001:2000, а следовательно, внедрение механизма управления проектами производилось через процедуры, связанные с разработкой, утверждением и реализацией всех новых бизнес-процессов.

В целевую группу потребителей услуг, которые предоставляются проектными командами ГК, входят предприятия, отдающие организацию логистики на аутсорсинг. Для поиска клиентов были задействованы сотрудники департамента маркетинга. Они проводили соответствующие мероприятия среди новых и существующих потребителей наших услуг. Если у кого-либо из очерченного круга потенциальных клиентов присутствовала заинтересованность, то мы создавали проектную команду, состоящую из:

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

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

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

Методические рекомендации, содержащиеся в современных научных источниках, по-разному описывают роли и зоны ответственности участников проекта. В приведенной здесь таблице представлена наиболее популярная по версии исследований PWC (глобальная сеть компаний Pricewaterhouse Coopers International Limited) модель управления – PMBOK.

Название роли

Зона ответственности

Полномочия

Руководитель

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

Определяются иерархией компании

Клиент

Утверждение требований к результатам проекта.
Приемка продуктов проекта

Изменение важности отдельных моментов в системе требований к результатам проекта

Спонсор проекта

Утверждение задач, сроков выполнения и стоимости работ.
Финансирование проекта

Разрешение вопросов, которые не входят в зону компетенций руководителя проекта

Команда проекта

Выполнение поставленных задач в сроки, утвержденные руководителем проекта

Предоставление информации о проблемных вопросах, возникающих в процессе реализации задач

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

Зона ответственности в проекте: как определить и контролировать

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

8 обязательных ролей в эффективной проектной команде с точки зрения классического подхода

Авторитетный эксперт в области менеджмента Рэймонд Мередит Белбин предложил подход к распределению зон ответственности при работе над проектами, который считается классическим. Согласно этой системе в команде эффективного проекта необходимо, независимо от численности участников, предусмотреть 8 ролей.

  1. Председатель (chairman)

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

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

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

  1. Оформитель (shaper)

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

  1. Генератор идей (plant)

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

  1. Критик (monitor-evaluator)

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

  1. Рабочая пчелка (company worker)

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

  1. Опора команды (team worker)

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

  1. Добытчик (resource investigator)

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

  1. Завершающий (completer)

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

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

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

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

Хорошие результаты дает модель RACI, которая предполагает наличие четырех ролей в команде, работающей над проектом:

  1. Responsible (исполнитель) – эта роль предполагает ответственность за конкретный этап рабочего процесса. То есть исполнителю доверяется один или несколько участков работы, которые соответствуют его компетенциям.
  2. Accountable (ответственный) – эту роль, связанную с управлением полным объемом процессов, чаще всего выполняет собственник. В его зону ответственности входит контроль ключевых показателей и вопросы стратегического руководства. В отдельном проекте подобная роль является единственной.
  3. Consulted (эксперт) – играет роль эксперта в конкретных сферах. Для успешной реализации проектов необходимо, чтобы в команде было не более 2 таких специалистов, так как большое их количество в одном проекте может создавать сложности в коммуникациях и способно оказаться причиной профессиональных споров.
  4. Informed (информирующий) – обладает полным объемом информации по процессам, которые могут иметь место в проекте. Исполняющий эту роль также обладает влиянием на результат.

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

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

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

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

6 советов, которые позволят составить эффективную матрицу зон ответственности в проекте

Совет 1. Исключите нерациональное распределение зон ответственности.

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

Индикаторы:

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

Совет 2. Формированием шаблонов по зонам ответственности должны заниматься не теоретики, а специалисты, имеющие практический опыт в данной сфере.

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

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

Совет 3. При формировании матрицы необходимо учесть специфические потребности проекта.

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

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

Совет 4. В процессе формирования матрицы зон ответственности необходимо отталкиваться от стратегии развития проекта и его задач.

Надо учесть требования выбранной политики в таких областях, как качество и формирование стоимости.

Совет 5. Начните с составления упрощенной матрицы по системе задача/ответственный, а потом дополните ее детализацией зон ответственности, показателями KPI и контрольными точками.

Совет 6. При формировании матрицы применяйте принципы коллегиальности и анализа реальных процессов внутри проекта.

В показатели KPI внесите полученный доход для участков, от которых зависят операционные итоги и результативность в отношении качественно-количественных показателей при реализации задач проекта.

Как руководитель должен осуществлять контроль зон ответственности участников проекта

  1. Определите для каждого участника проекта основные зоны ответственности.

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

  1. Зона ответственности менеджера.

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

  1. Дифференцированный контроль исполнителей.

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

  1. Развивайте взаимоуважение среди участников и проводите работу над ошибками.

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

  1. Административные зоны ответственности не следует передавать квалифицированным специалистам.

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

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

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

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

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

  1. Покажите, что контроль — способ убедиться, что все в порядке, и похвалить за достижения.

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

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

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

Важная новость для подписчиков!

5 полезных книг по эффективному управлению проектами

  1. Том Демарко «Deadline. Роман о правильном управлении проектами»

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

  1. Сазерленд Джефф «Scrum. Революционный метод управления проектами»

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

  • несогласованность командных действий;
  • невыполнение поставленных задач;
  • дублирование зон ответственности внутри отделов.
  1.  «Руководство к своду знаний по управлению проектами (Руководство PMBOK)»

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

  1. А. Д. Перерва, В. Иванова, С. Сергеев «Путь IT-менеджера. Управление проектной средой и IT-проектами»

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

  1. Том Демарко «Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения»

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

Подписка на статьи

Чтобы не пропустить ни одной важной или интересной статьи, подпишитесь на рассылку. Это бесплатно.

Рекомендации по теме

Школа руководителя

Школа руководителя

Проверьте свои знания и приобретите новые

Записаться

Лучшее предложение

Самое выгодное предложение

Воспользуйтесь самым выгодным предложением на подписку и станьте читателем уже сейчас

Мы в соцсетях
Простите, что прерываем Ваше чтение

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

Предлагаем Вам зарегистрироваться и продолжить чтение. Это займет всего 2 минуты.

У меня есть пароль
напомнить
Пароль отправлен на почту
Ввести
Я тут впервые
2 минуты, и Вы продолжите читать
Введите эл. почту или логин
Неверный логин или пароль
Неверный пароль
Введите пароль
Зарегистрируйтесь на сайте и документ Ваш! Это бесплатно и займет всего минуту!

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

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

У меня есть пароль
напомнить
Пароль отправлен на почту
Ввести
Я тут впервые
И получить доступ на сайт Займет минуту!
Введите эл. почту или логин
Неверный логин или пароль
Неверный пароль
Введите пароль
Сайт использует файлы cookie. Они позволяют узнавать вас и получать информацию о вашем пользовательском опыте. Это нужно, чтобы улучшать сайт. Посещая страницы сайта и предоставляя свои данные, вы позволяете нам предоставлять их сторонним партнерам. Если согласны, продолжайте пользоваться сайтом. Если нет – установите специальные настройки в браузере или обратитесь в техподдержку.