Огляд ролі менеджера проекту в RUP

illustration За відповідями менеджери проекту зазвичай звертаються до архітекторів, потім до розробників, потім до тестувальникам і т.д. Навіть маючи сертифікат Project Management Professional (PMP), менеджери проекту часто відчувають залежність від експертів в предметній області. Крім того, їм доводиться пристосовувати свої знання та навички до специфіки дисциплін IBM Rational Unified Process (RUP), оскільки колективи розробників часто використовують цю методологію.


У даній статті представлений погляд на управління проектами в сучасній ІТ-орієнтованої компанії. Стаття містить огляд поширених помилок щодо RUP як засобу управління проектами, обговорення точок перетину RUP і стандарту Project Management Body of Knowledge (PMBOK) і опис способів зменшення або повного усунення неоднозначностей, часто виникають при спільному розгляді цих взаємодоповнюючих інфраструктур побудови процесів. Завершує статтю опис та огляд потенційного значення ролі корпоративного менеджера проекту.


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


Що нам відомо про управління проектом


Згідно популярної інтернет-енциклопедії, проект – це “тимчасова діяльність, спрямована на досягнення певного результату, створення певного унікального продукту чи послуги”. Для виконання будь-якого проекту потрібні ресурси, в тому числі трудові й фінансові. Мета дисципліни управління проектом полягає в організації даних ресурсів і управлінні ними способом, що забезпечує створення продукту або послуги при дотриманні обсягу, рівня якості, термінів і вартості.


Незважаючи на те, що стиль управління проектом приблизно відповідає використовуваної методології життєвого циклу розробки програмного забезпечення (наприклад, Водоспадний метод, ітеративний підхід, швидка розробка (Rapid Application Development, RAD), Agile), будь-який проект включає наступний набір робіт:



Що таке PMI?


Інститут управління проектами (PMI), заснований в кінці 1960-х років, є однією з провідних організацій в області управління проектами. Інститут налічує більше 220 тисяч членів, включаючи 160 000 сертифікованих фахівців із понад 170 країн. У PMI була розроблена одна з найбільш всеосяжних програм сертифікації професіоналів з управління проектами (PMP), що передбачає кілька рівнів.


Що таке PMP?


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


Що таке PMBOK?


PMBOK являє собою збірник типових процесів, знань і кращих методів роботи, що є загальновизнаним стандартом в області управління проектами. Він включає п’ять груп процесів (наприклад, ініціації і планування) і дев’ять областей знань (наприклад, керування вмістом і управління термінами), застосовних в більшості предметних областей від будівництва до розробки програмного забезпечення. PMBOK описує процеси в термінах входів (input artifacts), інструментів і методів. Методи споживають і виробляють артефакти-входи і використовують інструменти.


Різні типи менеджерів


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


Функціональний керівник


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


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


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


Виконуючий обов’язки менеджера проекту


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


Технічний менеджер проекту


Нерідко роль менеджера проекту поєднується з роллю архітектора рішення або технічного керівника. Незважаючи на те, що таке поєднання часто приносить негативні результати, воно може виявитися цілком виправданим у разі, якщо проектна група невелика (звичайно не більше 10 учасників). Перевагою наявності у групі технічного менеджера проекту є те, що він може здійснювати грамотне планування проекту за рахунок глибокого розуміння вимог і / або принципів проектування програмного забезпечення. Це, в свою чергу, може усунути ефект “зіпсованого телефону” в групі розробки. Недолік даного підходу полягає в тому, що технічний менеджер проекту може не мати часу, достатнього для планування проекту, не кажучи вже про повне охоплення та управлінні всіма аспектами проекту.


Менеджер програми


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


Менеджер проекту підприємства


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


Основні турботи менеджера проекту


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


Оцінки


Менеджери проекту розчаровуються у своїх архітекторах, отримуючи від них оцінки трудовитрат із запасом в 20, 50 або навіть всі 100%. Безсумнівно, багато галузей досягли рівня розвитку при якому вимірювання, оцінки та план проекту можуть бути отримані виключно на основі стандартної термінології, високорівневого опису змісту робіт і галузевих норм продуктивності. Знаючи про це, менеджер проекту може очікувати того ж самого і в індустрії розробки програмного забезпечення. Подібні очікування, однак, найчастіше виявляються невиправданими. В ІТ-індустрії, де все, починаючи з інфраструктур і платформ і закінчуючи методологіями і інструментами, знаходиться в стані постійного розвитку, отримання результатів адекватної точності вимагає глибокого розуміння вимог.


У сучасній індустрії розробки програмного забезпечення значний обсяг робіт може бути оцінений з прийнятною точністю тільки в тому випадку, якщо оцінка заснована на детальних, структурованих, Розроблених з урахуванням конкретної методології вимогах [4] і використовує норми продуктивності, засновані на результатах раніше успішно завершених проектів, виконаних однією і тією ж групою і з використанням одних і тих же технологій. Оцінки, зроблені архітекторами, дуже часто грунтуються або на неструктурованих вимогах (що недобре), розроблених на основі аналогічних існуючих рішень (що погано) або на оцінках трудовитрат, отриманих від проектних груп (що ще гірше).


Бюджет і витрати


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


Методологія


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


Довіра


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


Володіння і відповідальність


У деяких організаціях бюрократія і політика беруть гору над конструктивною логікою. Чудово коли і проектна група і група менеджерів однаково мотивовані. У цьому випадку вони швидше за все виберуть “Мінімалістичний” метод реалізації, який дозволить прагматично підійти до розподілу областей відповідальності між усіма учасниками. Якщо ж обов’язки розподілені недостатньо прозоро, менеджеру проекту слід вдатися до використання підходу, заснованого на чітко визначеному володінні та розподілі відповідальності, наприклад, на моделі RACI (Responsible Accountable Consulted Informed). Безумовно, хороші відносини з архітектором і спонсором проекту ніколи не завадять, але і заміною чітко сформульованої ієрархії відповідальності вони бути не повинні. Чітка структура відповідальності – страхувальна сітка для менеджера проекту, яка до того ж робить процес прозорим для решти учасників проектної групи.


Поширені помилки щодо RUP


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


Оману: RUP є альтернативою стандарту PMBOK


Як це не сумно, RUP часто приймають за конкурента стандарту управління проектами PMBOK. Можливо, в основі цього нерозуміння лежить визначення RUP як методології, “забезпечує організований підхід до розподілу завдань і обов’язків в організації, що займається розробкою “, цілком відповідне управління проектами. В даному випадку це визначення не тільки не може вважатися показовим, але і цілком невірно витлумачене.


Хоча управління проектами входить до числа дев’яти основних дисциплін RUP (рисунок 1), організації, що застосовують цю методологію, можуть бути також зацікавлені в наявності базової інфраструктури управління проектами. Відповідна дисципліна RUP докладно розглядає окремі аспекти обов’язків менеджера проекту, що відносяться до планування його роботи та виконання завдань, особливо в частині планування ітерацій. На відміну від PMBOK, RUP не розглядає управління проектами як основний процес. Крім того, RUP повністю залишає без уваги деякі важливі завдання управління проектами, такі як управління трудовими ресурсами, планування ресурсів і оцінка витрат, ескалація і управління комунікаціями.


Оману: RUP – це тільки варіанти використання


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


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


Оману: RUP відволікає увагу від управління проектами


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


Центральна роль в RUP належить дисципліні управління проектами, успадкованої від PMBOK. У типовому життєвому циклі RUP завдання управління проектом починають виконуватися раніше задач інших дисциплін. Фактично, як показано на малюнку 1, ці завдання можуть почати виконуватися навіть до офіційного старту проекту RUP (докладніше про це нижче). З деякими пересторогами і після аналізу змісту проекту, заснованого на вимогах, PMBOK можна використовувати в якості основного процесу, на якому будуть будуватися ітерації, як показано на малюнку 1.


Дисципліни RUP

Малюнок 1. Дисципліна управління проектами RUP, розроблена на основі PMBOK


Важливою особливістю RUP є те, що методологія не бере до уваги проблеми бюрократії та політики [2], що дозволяє зосередитися на вирішенні найбільш важливих проблем – якщо тільки процес управління проектом не зводиться до послідовності команд “ховайся”, “треба” або “давай, давай”, а спрямований на створення професійних колективів та управління ними. У цьому випадку RUP виразно здатний допомогти.


Інше питання, чи є RUP найкращим вирішенням проблеми. Деякі організації настільки далекі від розуміння і правильного застосування стандартів управління проектами, що навряд чи можуть досягти поліпшення шляхом негайного переходу на методологію життєвого циклу розробки програмного забезпечення, таку як RUP. Замість цього їм слід розглянути можливість реінжинірингу існуючих процесів, систем і методів шляхом застосування структурної моделі архітектури підприємства, такий, як схема Захмана (Zachman Framework), для ліквідації відставання від індустрії. Це може допомогти їм краще зрозуміти і документувати поточний стан ІТ-архітектури з подальшою еволюцією в бік застосування єдиної нотації моделювання, наприклад UML і в остаточному підсумку прийти до використання методології життєвого циклу розробки програмного забезпечення, подібної RUP.


Оману: RUP складніше водоспадні методу


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


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


Іншим помилковим припущенням є віра в те, що проблему будь-якої складності можна вирішити за допомогою підходу “Великого вибуху”. Експериментально (і науково) доведено, що зростання складності вимагає експонентного зростання трудовитрат, що в свою чергу призводить до підвищення витрат часу і зростання вимог до професійної підготовки фахівців. В основі RUP, навпаки, лежить концепція зниження складності шляхом ділення задач на менші за обсягом, але важливі за значенням підзадачі, послідовно вносять зміни до вимоги користувачів. Результат кожної з них має певну цінність для зацікавлених осіб. Вважається, що проект, що включає численні підзадачі – “псевдопроекти” і, отже, ітеративний підхід в цілому, вимагає більше трудовитрат на управління. Але додаткові трудовитрати дають результат у вигляді підвищення надійності в результаті чого знижуються загальні витрати на реалізацію. На практиці ітеративний підхід як правило додає впевненості групі розробників і знижує собівартість проекту.


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


Оману: В RUP відсутні чіткі умови початку і завершення проекту


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


Заслуговує згадки (повторного) той факт, що RUP являє собою методологію розробки рішень, яка бере за основу чітко сформульовану потребу в розробці вирішення певної бізнес-проблеми. Дана методологія використовується для вирішення проблем окремої групи осіб, що функціонують у певній частині організації та беруть участь в обмеженій частині її бізнес-процесу. Отже, роботи, які менеджери проекту намагаються знайти в RUP, лежать поза цією методологією. Однак деякі з них нерідко виконуються в ході фази початку проекту RUP і ставляться як правило до дисципліни бізнес-аналізу. Даний спосіб архітектурного планування може вважатися “антішаблоном” проектування архітектури підприємства, який до того ж суперечить PMBOK, в якому результати аналізу є входом процесів прийняття рішень, що виконуються в ході ініціації (малюнок 2).


Дисципліни EUP

Малюнок 2. Дисципліни RUP, PMBOK і Enterprise


Багато організацій до цих пір не обзавелися групами розробки архітектури підприємства, здатними виконати акуратну трасування стратегічних рішень до можливостей і компонентів розроблюваних продуктів. На жаль, область архітектури підприємства (Enterprise Architecture), яка підтримується такими методиками, як The Open Group Architecture Framework (TOGAF) і Catalyst, досить повільно освоюється індустрією розробки програмного забезпечення. Почасти в силу низьких темпів освоєння, почасти через існуючих протиріч щодо їх призначення, методики розробки архітектури підприємства недостатньо повно описують процеси переходу від власне архітектури підприємства до проекту рішення. Процеси та інструменти дисциплін “Управління портфоліо” та “Управління змінами”, службовці для вирішення різноманітних завдань управління адміністративним шляхом не надають повної підтримки прийняття рішень на основі архітектурних міркувань.


Rational Method Composer як спосіб розширення RUP до закінченого процесу життєвого циклу масштабу підприємства є спробою зняття частини цих обмежень шляхом надання обширної процедурної та інформаційної підтримки, яка може бути вибірково використана для отримання спеціалізованого процесу, що підтримує переходи між фазами методології. Rational Method Composer включає керівництво по об’єднанню бізнес-цілей, результатів аналізу архітектури бізнесу [TOGAF, Enterprise Unified Process (EUP) та інші] із запитами зацікавлених осіб та функціональними вимогами [RUP, Feature Driven Development (FDD), Scrum], а також з управлінням ресурсами (PMBOK) і існуючими системними архітектурами (Zachman). Для найбільш популярних моделей управління підприємством [наприклад, Department of Defense Architecture Framework (DoDAF) або Capability Maturity Model Integration (CMMI ®)], різновидів архітектур рішення і шаблонів реалізації [наприклад, сервісно-орієнтована архітектура (SOA), керована моделлю розробка систем (MDSD) або розробка коробкових продуктів (COTS)] наведені еталонні процеси, які підходять для застосування в проекті будь-якого масштабу (шляхом адаптації RUP для малих, середніх і великих проектів відповідно). Крім того, все більше і більше важливих для галузі процесів реалізується у вигляді додаткових модулів (недавно так був реалізований процес для TOGAF).


Оману: RUP не включає оцінку трудовитрат


Багато менеджерів проекту скаржаться, що RUP не робить оцінку. І це насправді так. RUP являє собою інфраструктуру розробки процесів, не містить і не пропонує жодних конкретних методів оцінки. Тим не менш, в RUP можна знайти деякі корисні вказівки на те, де і як проводити оцінку.


При роботі з ранніми версіями RUP відчувалася сильна недостача вказівок щодо проведення оцінки. Але з появою Rational Method Composer і з розвитком декількох моделей проведення оцінки цей недолік зник. У Rational Method Composer оцінка представлена ​​як у вигляді окремих елементів, які при необхідності можуть бути включені в спеціалізований процес, так і у вигляді частин еталонних процесів, призначених для різних методологій і типів проектів [наприклад, RUP для проектів по забезпеченню та RUP для розробки на основі наявних активів (asset-based development)]. Крім того, існує ряд розроблених сторонніми виробниками виконуваних модулів розширення функціональності Rational Method Composer, таких як, наприклад, модуль Quantitative Software Management (QSM) Measurement and Estimation. Вищезгаданий модуль призначений для розрахунку оцінок як при проходженні ключових контрольних точок процесу, так і по необхідності. Модуль може виконувати розрахунки на основі значного числа параметрів, що включають метрики середовища, процесів і проекту.


Поточна версія RUP включає бібліотеку, що містить керівництво по оцінці, заснованій на функціональних точках із застосуванням варіантів використання і методу wideband DELPHI. Модуль розрахунку оцінки QSM реалізує поліпшену модель Putnam Lifecycle і приймає в якості параметрів такі метрики як кількість функцій (function counts, FC) або кількість рядків коду (software lines of code, SLOC). На жаль, в Rational Method Composer не представлені методи, засновані на експертній оцінці і навчанні. Решта потенційно корисні методи також здебільшого залишені без уваги.


Важливою особливістю Rational Method Composer є рівність підходів до оцінки і до решти методам, таким як аналіз варіантів використання або модульне тестування. Ця особливість змушує розробників процесів і менеджерів проекту вважати оцінку необов’язковою (хоча і важливою) роботою, яка може при необхідності виконуватися як в певний момент процесу, так і в будь-який час на розсуд відповідальних осіб.


Оману: в RUP не ведеться реєстрація подій


Дисципліна управління проектами заснована на власних стандартах і склепіннях кращих методів, таких як PMBOK і Projects in Controlled Environments (PRINCE2). У цьому з нею схожа робота з аудиту (Audit). У базовому процесі RUP дана робота є частиною дисципліни конфігураційного управління і управління змінами. Подібно роботам з управління проектами, роботи по управлінню змінами починаються на ранніх етапах проекту. Роботи по цій дисципліні включають конфигурационное управління, управління запитами на зміну, управління статусами і керування вимірами. Кожна з цих робіт формує вхідні дані для робіт з аудиту.


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


Оману: життєвий цикл RUP заснований на фазах


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


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


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


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



Другорядні (але що не є вкрай незначними) контрольні точки співпадають із завершенням робіт над основними релізами продукту.


Для RUP як інфраструктури розробки процесів поняття ітерації, безсумнівно, є більш важливим, ніж поняття фази. Поділ на фази часто створює у фахівців, в тому числі і у менеджерів проекту, помилкове уявлення про те, що збір вимог відбувається у фазі початку, розробка – у фазі побудови, а введення в експлуатацію – у фазі впровадження, що більше нагадує Водоспадний метод ніж RUP. Не зовсім вдалим тут є схожість фаз RUP з життєвим циклом зведення будівлі, запозиченим з будівельної індустрії. Переважаюча в будівництві модель виробничого процесу за своєю природою має послідовний характер, тоді як модель, що переважає в інженерній справі, є циклічною [6].


Оману: необхідно встановлювати відповідність між PMBOK і RUP


Займатися пошуком відповідностей між RUP і PMBOK не обов’язково, проте, якщо в ході проекту ці стандарти будуть використовуватися спільно, деякого роду порівняння все ж буде потрібно. На верхньому рівні встановити відповідності нескладно, але практика показує, що кожен проект трохи відрізняється від інших. Спочатку необхідно вибрати один з двох стандартів в якості базового. Я настійно рекомендую RUP, незважаючи на те, що зазвичай основним процесом є PMBOK. Це пов’язано з тим, що RUP спеціально створювався як процес розробки програмного забезпечення, тоді як PMBOK являє собою не прив’язаний до конкретної галузі підхід до управління проектами. Після того як індивідуальна версія методу розроблена і налаштована, процес виробництва, побудований на основі RUP з урахуванням PMBOK, може бути випущений у вигляді практичного посібника, чого неможливо було б досягти іншим способом.


Якщо між процесам вирішено встановити відповідність, не слід опускатися нижче рівня деталізації, до якого прагне менеджер проекту. Деякі менеджери проекту готові дійти навіть до встановлення відповідності між окремими завданнями і артефактами. Я вважаю, що достатньо лише погодитися про принципи встановлення відповідності між елементами життєвого циклу, а зекономлений час спрямувати на виконання рекомендацій RUP з планування проекту. У таблиці наведені відповідності між елементами життєвого циклу стандартів RUP і PMBOK.


Відповідність між елементами RUP і PMBOK































RUP PMBOK
Фаза (Phase) Фаза (Phase)
Основна контрольна точка (Major Milestone) Контрольне подія (Milestone)
Ітерація (Iteration) Проект (Project)
Другорядна контрольна точка (Minor Milestone) Контрольне подія (Milestone)
Дисципліна (Discipline) Галузь знань (Knowledge Area)
Робота (Activity) Група процесів (Process Group)
Результат роботи (артефакт, проміжний / допоміжний артефакт) [Work Product (Artifact, Deliverable)] Результат поставки (Deliverable)
Завдання (Task) Процес (Process)

Колізії на рівні артефактів і привнесена надмірність складають лише частину потенційно можливих складнощів, з якими групі розробки процесу або проектній групі доведеться зіткнутися при використанні гібридного підходу. Вдалим прикладом тому є документ “Статут проекту” (Project Charter) PMBOK, який, як зазначають деякі менеджери проекту, “заміщається” артефактами RUP “Бізнес-сценарій” (Business Case) і “Концепція” (Vision). Незважаючи на те що гібридний підхід може виправдовувати використання змішаного набору артефактів, що належать обом стандартам, я наполегливо рекомендую в цілях забезпечення трассируемого використовувати набір артефактів RUP, а артефакти PMBOK при необхідності формувати на їх основі.


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


Омани: RUP є процесом, готовим до застосування “з коробки”


Найчастіше менеджери, так само як і багато інших учасників ІТ-проектів, приймають RUP за фіксований процес, негайно готовий до застосування. Ймовірно, таке розуміння даної методології зародилося на ранніх періодах її еволюції, коли RUP ще був монолітним процесом, призначеним для вузької категорії проектів (головним чином, проектів розробки ПЗ “з нуля”) і не мав достатньої гнучкості щодо масштабів проекту (всі проекти вважалися скоріше великими). Крім того, в той момент RUP не мав адекватних описів і керівництв із застосування, можливості індивідуальної настройки також були відсутні. Незважаючи на те, що всі ці обмеження давно усунені, уявлення про RUP як про строго формальному і негнучке процесі досі збереглося.


Ситуація ще сильніше змінилася в кращу сторону з появою Rational Method Composer. В останніх випусках RUP проекти стали ділитися за розміром (і, мабуть, за рівнем формалізму) на “RUP для малих проектів”, “RUP для проектів середнього розміру” і “RUP для великих проектів”. Спеціальні модулі, такі як “RUP для коробкових продуктів” і “RUP для бізнес-моделювання” можуть використовуватися для отримання спеціалізованих процесів виробництва необхідного масштабу на основі базової версії RUP. Крім готових розширень, при створенні спеціалізованого процесу може бути використана внутрішня нормативно-довідкова документація компанії, матеріали, запозичені з інших методологій, інфраструктур та кращих практик, таких як PMBOK або Information Technology Infrastructure Library (ITIL ®) і, крім того, модулі розширення RMC.


Оману: в RUP відсутній процес “ініціації”


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


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


Якщо ж причиною є бажання виграти побільше часу на бізнес-аналіз або політичні ігри, до RUP це не має відношення. Можливо, вирішення проблеми можна знайти в галузі архітектури підприємства. Остання має більш широкі цілі, ніж RUP і, крім того, Rational Method Composer містить керівництво по перетворенню концептуальних цілей і бізнес-метрик, що містяться в документах “Концепція підприємства” (Enterprise Vision), “Бізнес-сценарій” (Business Case) та інших документах з планування в специфікацію бізнес-технології і пропозиції по розробці рішень. Методології архітектури підприємства включають керівництва з аналізу структури і процесів підприємства, визначенню мети і кордонів, оцінці ресурсів, архітектурному аналізу, ідентифікації і визначенню пріоритетів рішення, а також вибору способу реалізації. Крім того, додаткову підтримку можна знайти в області управління портфелем проектів. Цілком природно, що за наявності налагоджених процесів управління портфелем проектів функції відбору проектів і здійснення загального контролю стають частиною робочого порядку, що сприяє усуненню будь-яких упереджень відносно методології реалізації рішення.


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


Менеджер проекту підприємства: роль у процесі розвитку


Чи виправдане створення в організації ролі менеджера проекту підприємства? Можливо, має, якщо розглядати розвиток підприємства як один тривалий процес – з тих, що створюють попит на TOGAF та інші методики реалізації архітектури підприємства.


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


Тому більш розумним підходом є поділ процесу реалізації архітектури підприємства на кілька проектів розумної тривалості. Ці проекти могли б, наприклад, охоплювати одну або кілька фаз реалізації архітектури підприємства і виконуватися як паралельно, так і послідовно з накладеннями. Наприклад, при використанні TOGAF ADM можуть бути запущені три проекти для формулювання концепції (Фаза А), розробки архітектури (Фази BF), управління процесом розробки рішення та управління змінами (Фази GH).


Організація повинна сама визначити, чи потрібно їй виділений менеджер проекту підприємства для вирішення питань, пов’язаних з архітектурою чи буде достатньо покласти додаткові обов’язки на архітектора підприємства [1]. Кінцеве кількість проектів, необхідне для реалізації архітектури підприємства, повинен визначити менеджер проекту підприємства (або архітектор). При цьому необхідно взяти до уваги такі фактори як рівень мотивації для внесення змін, здатність організації досягати результату, продуктивність при виконанні аналогічних проектів у минулому, тривалість циклу реалізації архітектури підприємства в минулому і її оцінка для поточного проекту. Практика вирішення даної проблеми показує, що в архітекторів підприємства достатньо інших турбот (таких як питання власне архітектури), а це може створити при виконанні ними додаткових обов’язків складності які буде не так-то просто дозволити.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*