---
title: "Дидар Арыстан — Современные подходы к управлению проектами"
description: "Дидар Арыстан – Аналитик Казахстанского центра государственно-частного партнерства Современная жи..."
author: "kzppp"
published: "2016-08-08T05:10:37+00:00"
modified: "2016-08-08T05:35:06+00:00"
locale: "ru"
canonical_url: "https://yvision.kz/post/didar-arystan-sovremennye-podhody-k-upravleniyu-proektami-706055"
markdown_url: "https://yvision.kz/post/didar-arystan-sovremennye-podhody-k-upravleniyu-proektami-706055/markdown"
site_name: "Yvision.kz"
---

# Дидар Арыстан — Современные подходы к управлению проектами

> Дидар Арыстан – Аналитик Казахстанского центра государственно-частного партнерства Современная жи...

**Дидар Арыстан –**

**Аналитик Казахстанского центра государственно-частного партнерства**

![Дидар Арыстан — Современные подходы к управлению проектами](https://storage.yvision.kz/images/user/kzppp/7maMmIs6S7M0OMY9dISptoNJnl2f92.jpg)

Современная жизнь и её реалии диктуют свои жесткие условия. Прошли те времена, когда можно было оставаться закостенелым консерватором и работать на старый манер. Чтобы «выжить» в современной бизнес среде надо быть готовым к изменениям, необходимо развивать гибкость и умение подстраиваться под любые ситуации. Нельзя стоять на месте, надо постоянно совершенствоваться. Как говорит старая латинская пословица «Qui non proficit – deficit» (прим. «Кто не движется вперед – отстает»). Именно в такое время на помощь управленцам многих компаний приходит проектное управление.

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

Разные методологии в проектном управлении по-разному оценивают успешность проекта.

Группы оценок успешности:
- Ориентированные на контракт, например традиционные методологии (к примеру, [PMBOK](https://ru.wikipedia.org/wiki/PMBOK)): «проект успешен, если при его реализации соблюдены все критерий: объём, срок, качество».

- Ориентированные на заказчика, например гибкие методологии (к примеру, [SCRUM](https://ru.wikipedia.org/wiki/SCRUM)), направленные на длительное сотрудничество и взаимодействие (на несколько проектов): «проект успешен, если заказчик удовлетворен». Здесь делается акцент на продолжение сотрудничества Исполнителя с Заказчиком в рамках последующих проектов и иного взаимодействия. Оценка успешности рассматривается в основном с точки зрения заказчика.

- Смешанные, (к примеру, [PRINCE2](https://ru.wikipedia.org/wiki/PRINCE2)): «проект успешен при сбалансированности по трем категориям — бизнеса, ориентации на пользователя/клиента и технологической зрелости». Здесь делается акцент на финансовой успешности проекта (бизнес), удовлетворенности пользователей (ориентация на пользователя) и развитии (технологическая зрелость). Такие методики оценки чаще используются для внутренних проектов в рамках одной организации.

Приведем пример: проект, который уложился в утвержденные сроки и затраты, но при этом не окупился по результатам проекта (затраты велики, результат неактуален после завершения проекта, заказчик не может воспользоваться результатом и т. п.) будет считаться успешным по традиционной методологии (PMBOK 3 версия), но не будет таковым по методологии, ориентированной на заказчика (PMBOK 4 версия, Agile). Ответственность за неуспешность такого проекта несет заказчик и, в некоторых случаях, [проектный офис](https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BD%D1%8B%D0%B9_%D0%BE%D1%84%D0%B8%D1%81) либо [служба заказчика](https://ru.wikipedia.org/wiki/ITSM) (Agile, так как предусматривает долгосрочное сотрудничество, и в случае неокупаемости заказчик вряд ли захочет продолжать «такое сотрудничество»).

![Дидар Арыстан — Современные подходы к управлению проектами](https://storage.yvision.kz/images/user/kzppp/gi2VOfp4CRs8bNC1eiRddO38w95IK7.jpg)

Далее поговорим о 2 наиболее крупных подходах к управлению проектами:

- ***Каскадная модель*** (модель «водопада» - waterfall model) – модель на которой основывается наиболее классический стандарт по управлению проектами PMBOK. Изначально, данная модель появилась в ходе реализации крупных военных проектов в США и затем стала [модель](https://ru.wikipedia.org/w/index.php?title=%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%28%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B0%29&action=edit&redlink=1)ю процесса [разработки программного обеспечения](https://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8F), в которой процесс разработки выглядит как поток, последовательно проходящий различные фазы: анализ требований, проектирование, реализацию, тестирование, интеграцию и поддержку.

- ***Гибкая модель*** (Agile model) - серия подходов к [разработке программного обеспечения](https://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8F), которые появились как итог вследствие недовольства каскадной моделью. Данные подходы ориентированы на использование итеративной разработки (многократное повторение какого-либо действия). В результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля, формируются требования, которые могут постоянно меняться и обеспечивается их реализация. Результат agile-методов измеряется рабочим продуктом, в том числе его качеством. Agile-методы уменьшают объём письменной документации по сравнению с другими методами, так как отдают предпочтение непосредственному общению. Со временем это привело к критике этих методов как недисциплинированных.

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

Все это произвело к тому, что в 2001 году 17 ведущих специалистов IT отрасли собрались вместе и сформулировали так называемый Agile Manifestо:

1. **Люди и взаимодействие** важнее процессов и инструментов;

2. **Работающий продукт** важнее исчерпывающей документации;

3. **Сотрудничество с заказчиком** важнее согласования условий контракта;

4. **Готовность к изменениям** важнее следования первоначальному плану.

Как отмечают сами создатели манифеста, «не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева».

К гибкому методу относятся следующие практики по управлению проектами:

XP Экстремальное программирование;

[Crystal Clear](https://ru.wikipedia.org/w/index.php?title=Crystal_Clear&action=edit&redlink=1);

[DSDM](https://ru.wikipedia.org/wiki/DSDM) (Dynamic Systems Development Method);

FDD ([Feature driven development](https://ru.wikipedia.org/wiki/Feature_driven_development));

[Scrum](https://ru.wikipedia.org/wiki/Scrum);

ASD ([Adaptive software development](https://en.wikipedia.org/wiki/Adaptive_software_development)).

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

Waterfall

Agile

**Сильные стороны**

Простой и понятный для использования;

Итеративная разработка;

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

Использование временных рамок (time boxes);

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

Конечный пользователь вовлечен в процесс с самого начала;

Проекты легко контролируются, отслеживаются ресурсы, риски, время;

Быстрое получение первой/пробной версии продукта для тестирования;

Качество имеет первоочередный приоритет по сравнению со стоимостью и временем.

Легко вносятся корректировки и изменения в процессе разработки.

**Слабые стороны**

Все требования должны быть определены и детально описаны до начала разработки;

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

Дорого и медленно;

Риск никогда не достигнуть завершения проекта;

Чувствителен к изменениям (любые изменения могут привести к отклонениям, причем зачастую в отрицательную сторону);

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

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

Слабая формализованность приводит к высоким рискам

Зачастую проблемы выявляются на этапе тестирования, уже после завершения проекта;

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

**Где и когда использовать**

Требования к продукту предельно ясны и стабильны;

Конечный пользователь вовлечен в проект со старта;

Известны используемые технологии и инструменты;

Четко определены бизнес-цели проекта/продукта;

Проект большой, дорогой и сложный, много рисков по проекту;

Небольшой или средний проект, относительно короткий по времени;

Состав команды стабильный;

Команда с высоким уровнем профессионализма;

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

В целом, на основе вышеизложенного, создается впечатление, что каскадная модель имеет много недостатков и лучше использовать гибкую модель. Однако это не должно вводить в заблуждение интересующихся проектным управлением людей. Каждый из этих методов имеет свои плюсы и минусы, к тому же у каждого метода имеются свои более развитые подвиды, такие как RUP (Rational Unified Process) и Scrum к примеру. Также, надо понимать, что agile метод не будет работать в командах, в которых нет взаимоуважения и коллективной работы, в которых не хотят учиться и самосовершенствоваться. Кроме того, есть отрасли, такие как банковские и медицинские системы, в которых нет потребности в изменении требований, но есть потребность в высоком уровне надежности. Если в какой-то области цена ошибок очень велика и требования заранее определены и утверждены на самом старте, то в Agile здесь нет необходимости.

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

***Статья опубликована в журнале** "National Business"*

***№5-6 (24) 2016***

---

Source: [https://yvision.kz/post/didar-arystan-sovremennye-podhody-k-upravleniyu-proektami-706055](https://yvision.kz/post/didar-arystan-sovremennye-podhody-k-upravleniyu-proektami-706055)