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

•Системне адміністрування.

•Управління брандмауером (firewall); адміністрування системи безпеки.

•Обслуговування застосувань.

•Інтеграція серверів.

•Підтримка служб каталогів.

Ця область компетенції пов'язана з поряд операційних завдань, які повинні виконуватися при здійсненні проекту. Вона відповідальна за те, щоб створюване і впроваджуване рішення було узгодженим з тими, що мають до нього відношення бізнес - процесами. Її характеристики схожі з характеристиками ролевого кластера "Бізнес - процеси" (operations) MOF.

Масштабування моделі проектної групи

У своїй книзі "Rapid Development" колишній розробник програмного забезпечення майкрософтом Steve McConnell пише:

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

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

Крім того, коли ролевому кластеру потрібно багато ресурсів, формуються т.з. функціональні групи (functional teams), які потім об'єднуються в ролеві кластери.

Групи напрямів

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

Уцю структуру вплетені так звані групи напрямів (feature teams). Це компактні мінікоманди, утворюючі матричну організаційну структуру. У них входять поодинці або декілька членів з різних ролевих кластерів. Такі команди мають чітко певне завдання і відповідальні за питання, що все відносяться до неї, починаючи від проектування і складання календарного графіка. Наприклад, може бути сформована спеціальна група проектування і розробки сервісів друку.

У"Rapid Development" Steve McConnel писав:

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

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

40

Рисунок 2. Групи напрямів

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

Функціональні групи

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

Аналогічно, в команді розробників можливе угрупування співробітників відповідно до призначення модулів, що розробляються ними: інтерфейс користувача, бізнес-логіка або об'єкти даних. Часто програмістів розділяють на розробників бібліотек і розробників рішення. Програмісти бібліотек зазвичай використовують низькорівневу мову C і створюють повторно використовувані компоненти, які можуть стати в нагоді всьому підприємству. Творці ж рішення зазвичай сполучають ці компоненти і працюють з мовами більш високого рівня, такими як, наприклад Microsoft® Visual Basic®.

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

Об'єднання ролей

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

41

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

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

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

Рисунок 3. Об'єднання ролей в малих проектах

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

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

42