ALL(PDF)

•Спонсор (куратор) проекту (Project Sponsor) – особа, що забезпечує ресурси проекту й будьяку адміністративну підтримку. Визначає пріоритети, забезпечує взаємодію з функціональними підрозділами, затверджує зміни. У внутрішніх проектах звичайно відповідає за результати проекту

•Замовник (споживач) проекту (Project Customer) – особа усередині або поза організацією,

що буде використовувати результати проекту

Діючі особи проекту

(виконавці)

•Керівник функціонального підрозділу направляє ресурси в затверджені проекти

•Функціональний лідер проекту об'єднує зусилля учасників проекту в рамках функції або підрозділу. Саме з ним взаємодіє менеджер проекту.

•Лідер пакета робіт об'єднує зусилля окремих осіб у рамках пакета робіт.

Трикутник компромісів

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

•гнучкість і пристосовність;

•ініціативність і якості лідера;

•агресивність, упевненість у собі, уміння переконувати, чітко виражати свої думки,

честолюбство, активність, енергійність;

•уміння спілкуватися, вести посередництво, об'єднувати зусилля;

•широкий кругозір, здатність до узагальнення;

•урівноваженість ентузіазм, уява, безпосередність;

•здатність дотримуватись балансу технічних, часових, вартісних і людських факторів;

•організованість і дисципліна;

•здатність і бажання присвячувати більшу частину свого часу плануванню й контролю;

•здатність виявляти проблеми й приймати рішення.

•

Галузі знань PMBOK

Управління проектами виконується за допомогою застосування й інтеграції логічно згрупованих 42 процесів управління проектами, об'єднаних в 5 груп процесів:

•ініціація;

•планування;

програмного забезпечення для середніх і великих компаній і організацій у всьому світі. Модель SEI CMM, а точніше CMMI Capability Maturity Model Integration [CMMI 1.1, 2002].

Функції цієї групи процесів деталізують питання управління інженерною діяльністю (13) у застосуванні до програмного забезпечення.

Ряд загальних технік, не пов'язаних зі специфікою Розширень PMBOK:

1.Software development maturity assessments (14.1.2.1) – оцінка (може передбачати сертифікацію)

зрілості «процесів» розробки програмного забезпечення;

2.Software acquisition maturity assessments (14.1.2.2) – оцінка зрілості «процесів» придбання ПЗ;

докладно описані в Software Acqusition моделей оцінки зрілості CMM і CMMI (SA-CMM і SACMMI, відповідно);

3.Software measures (14.1.2.3) – метрики програмного забезпечення; включають вимірні характеристики якості (quality metrics);

4.Life-cycle standards tailoring (14.1.2.4) – адаптація стандартів і методологій в галузі управління життєвим циклом; має на увазі, наприклад, адаптацію стандарту ISO/IEC 12207;

Дві ключові групи аспектів, пов'язаних з управлінням роботами (а не, наприклад, з архітектурними й технологічними питаннями):

1. Моделі, стандарти й методології управління життєвим циклом програмного забезпечення; 2. Моделі й методи оцінки зрілості й удосконалювання процесу розробки.

Agile-маніфест розробки ПЗ

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

Завдяки цій роботі ми змогли зрозуміти, що:

•Люди та співпраця важливіші за процеси та інструменти

•Працюючий продукт важливіший за вичерпну документацію

•Співпраця із замовником важливіша за обговорення умов контракту

•Готовність до змін важливіша за дотримання плану

Тобто, хоча, цінності, що справа важливі, ми все ж цінуємо більше те, що зліва.

Основні принципи Agile-маніфесту

•Найвищим пріоритетом для нас є задоволення потреб замовника, шляхом завчасного та регулярного постачання програмного забезпечення.

•Схвальне ставлення до змін, навіть на заключних стадіях розробки.

•Agile-процеси надають можливість використовувати зміни задля забезпечення конкурентоспроможності замовника.

•Працюючий продукт слід випускати якомога частіше, з періодичністю від пари тижнів до пари місяців.

•Впродовж усього проекту розробники і представники бізнесу повинні працювати разом

щодня.

Основні принципи Agile-маніфесту (продовження)

•Над проектом повинні працювати вмотивовані професіонали.

•Щоб робота була виконана, створіть їм умови, надайте підтримку і повністю на них

покладіться.

•Особиста комунікація – найефективніший та найпрактичніший метод як донести інформацію до команди, так і поширити її всередині.

•Працюючий продукт – головний показник прогресу.

•Інвестори, розробники і користувачі повинні мати можливість підтримувати постійний ритм як завгодно довго. Agile допомагає налагодити такий сталий процес розробки.

Основні принципи Agile-маніфесту (закінчення)

•Постійна увага до технічної досконалості і якості проектування підвищує гнучкість проекту.

•Простота – мистецтво мінімізації зайвої роботи – вкрай необхідна.

•Найкращі вимоги, архітектурні та технічні рішення виникають у командах, що здатні самоорганізовуватись.

•Команда регулярно намагається знайти способи підвищення ефективності та відповідно коригує свою роботу.

• Система прискореного будівництва.

Організаційні форми управління проектом можна класифікувати лише умовно. “основна система”

•менеджер проекту є представником (агентом) замовника і не несе фінансової відповідальності

за рішення, що приймаються.

•Повноваження менеджера проекту обмежуються умовами, передбаченими контрактом із замовником.

•Менеджером проекту (агентом замовника) може бути співробітник практично будь-якої фірми - учасниці проекту (замовника, включно) або консультативної фірми.

Обов’язки між учасниками проекту за “основної системи” розподіляються так:

Замовник: визначає масштаби проекту, укладає контракти з менеджером проекту та іншими учасниками і несе відповідальність по цих контрактах, керує процесом взаємодії між усіма учасниками.

Менеджер проекту:

•відповідає за координацію та управління всім ходом розробки та реалізації проекту,

•працює за контрактом із замовником. З іншими учасниками відносини на умовах інших контрактів недопустимі.

Інші учасники проекту виконують традиційні для них функції. “основна система”

•Переваги: зняття фінансової відповідальності з менеджера проекту, що забезпечує об’єктивність рішень, що приймаються.

•Недоліки: ризик за долю проекту повністю лягає на замовника. Крім того немає впевненості в

стабільності “граничних” витрат по проекту, тому він вимушений повністю покладатись на компетентність менеджера проекту.

“системи розширеного управління” передбачають встановлення фіксованої ціни

Загальна схема розподілу відповідальності:

Замовник - відповідає за визначення масштабів та параметрів проекту, укладає контракт з

менеджером проекту, який повинен забезпечити спорудження об’єкта, у більшості випадків, “під

ключ”.

Фахівці розглядають такі організаційні форми як своєрідні “спільні підприємства” до складу яких входять всі учасники проекту за виключенням замовника.

Менеджер проекту забезпечує управління та координацію процесів проектування та будівництва у відповідності з угодою між учасниками проекту у межах фіксованої (кошторисної) ціни.

Менеджером може бути представник підрядної організації або консалтингової фірми (іноді інжинірингові), який управляє проектом, координує поставки та роботи з інжинірингу. Ризик покладається на підрядчика.

Система прискореного будівництва

•проектування та будівництво здійснюється однією проектно-будівельною фірмою, з якою замовник укладає контракт “під ключ” із заздалегідь визначеною ціною проекту.

Ця модифікація найбільш ефективна у тих випадках, коли замовник чітко уявляє основні

характеристики проекту, його параметри, масштаби, вимоги до окремих його частин тощо.

2. Поняття організаційно-динамічної структури управління проектом

Динамізм - це постійні зміни.

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

Це означає, передусім, забезпечення можливості безперервного вдосконалення структури управління в умовах динамічного розвитку проекту.

Оскільки проект у своєму розвитку має різні фази, стадії та етапи життєвого циклу, то абсолютно очевидно, що і обсяг управлінських робіт безперервно змінюється.

Звідси відбувається постійна зміна кількості елементів в організаційній структурі управління проектом, їх взаємозв'язків, ієрархії і чисельність персоналу.

Тому дуже важливо на початковій (концептуальній) фазі визначити динамізм організаційної структури, це дозволить своєчасно підготувати «вхід» і «вихід» необхідного персоналу проекту.

2. Поняття організаційно-динамічної структури управління проектом

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

Ця обставина забезпечує єдиний підхід до проектування організаційно-динамічної структури управління.

Проектування організаційно-динамічних структур спирається на такі принципи:

•принцип єдності адміністрування, що виключає подвійність підкорення і суперечність вказівок;

•принцип точних меж між лінійним і функціональним керівництвом. Лінійна організація покликана здійснювати керівництво проектом, а функціональна надавати всіляку допомогу в цьому, забезпечувати необхідною інформацією, давати рекомендації;

•принцип керованості, згідно з яким необхідно визначити, якою кількістю підлеглих може керувати одна людина, тобто яка норма керованості для даного керівника. Вона залежить від кількості зв'язків між керівниками і підлеглими і між самими підлеглими;

•принцип мінімізації рівнів управління: чим менше рівнів в структурі, тим більш гнучкою вона є

іоперативно будуть вживатися заходи у випадку будь-яких ускладнень;

•принцип раціонального поєднання централізації і децентралізації функцій. При децентралізації керівництва підвищується активність низових ланок управління. При централізації створюються умови для ефективного застосування сучасних засобів управлінської техніки, спеціалізації підрозділів і виконавців, однак при цьому може постраждати оперативність прийняття

іреалізації рішень, значно знизитися активність і відповідальність нижчих ланок.

На вибір варіанта організаційної структури впливають такі чинники:

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

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

•соціально-психологічні (соціальна структура і відносини в команді проекту, характеристика психологічного клімату і інш.);

•зовнішні зв'язки і умови (характеристика кооперації та конкуренції, система постачання,

кліматичні та природні умови та інш.);

•найбільший вплив на структуру управління спричинюють функції управління, їх склад, зміст і обсяг. Зростання обсягів робіт проекту зумовлює розвиток функцій управління, які вимагають реорганізації структури управління.

3.Типи організаційних структур груп для управління проектами

Концепція управління проектами передбачає:

створення для УП спеціальної групи (проектної команди), яка стає самостійним учасником проекту або входить до складу одного з учасників та здійснює управління процесом реалізації проекту.

Ця група створюється на період реалізації проекту і після його завершення розпускається. На практиці застосовуються два основних підходи до формування груп для УП:

•Провідні учасники проекту - замовник і підрядчик (крім них можуть бути й інші учасники),

створюють свої власні групи, які очолюють менеджери проекту, власне від замовника та підрядчика. Ці менеджери підпорядковуються єдиному менеджеру проекту, яким може бути один з них, в залежності від організаційної форми реалізації проекту.

•Для управління проектом створюється єдина група на чолі з менеджером проекту. В групу входять повноважні представники всіх учасників проекту. Всередині кожної фірми-учасниці може створюватись своя група контролю за ходом проекту.

Логіку взаємодії учасників проекту всередині такої групи відображає її організаційна структура. Існує кілька типів організаційних структур, які широко застосовують в управлінні проектами:

•проектна,

•матрична,

•комбінація цих двох типів структур,

•проект здійснюється у межах функціональної структури фірм учасниць.

Згідно з проектною структурою управління

•для розв’язання конкретного завдання на підприємстві створюють спеціальну робочу групу,

яку після реалізації проекту розпускають.

При цьому залучений до робочої групи персонал і ресурси повертаються до відповідних спеціалізованих підрозділів.

У проектній структурі менеджер проекту має повні повноваження.

Члени команд проектів залишають свої функціональні відділи й переходять у підпорядкування до менеджерів проектів у проектно-орієнтовані підрозділи.

Тим самим досягається повна координація роботи команди проекту.

За проектної структури

• персонал робочої групи виділяється для участі в проекті на повний робочий день.

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

коли, в ідеальному варіанті він може розташовуватись в одному місці.

Увипадку проектної структури

Уцілому робоча група проекту - це підрозділ, створений для того, щоб розподіляти робочі завдання

увідповідності з вказівками менеджера проекту, а також технічними умовами та процедурами проекту.