ALL(PDF)

Автори моделі CMMI настійно рекомендують проводити оцінку обсягу проекту на основі структури робіт (work breakdown structure, WBS). Її визначення - важливий елемент планування, оскільки весь проект декомпонується на комплекс взаємозалежних керованих компонентів. Доцільно розробляти структуру робіт на основі архітектури продукту. Це дозволяє виділити логічні елементи робіт, так звані «робочі пакети», кожним із яких можна керувати автономно. Як правило, WBS розвивається, доповнюється й уточнюється в міру виконання проекту, тому при початкових оцінках доцільно використовувати структуру робіт верхнього рівня.

Рисунок 5. Вихідні оцінки

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

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

Рекомендовані робочі продукти - результати даного етапу: опис завдань; опис пакетів робочих продуктів, структура робіт.

2.Установлення оцінок робочих продуктів і характеристик виконуваних завдань Більшість моделей по оцінці трудовитрат, вартості й графіка засновані на визначенні розміру,

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

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

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

Рекомендовані робочі продукти - результати даного етапу: технічний підхід; розмір і складність виконуваних завдань і робочих продуктів; оцінні моделі; оцінки атрибутів.

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

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

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

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

Рекомендовані робочі продукти - результати даного етапу: опис фаз життєвого циклу проекту.

4.Оцінка трудовитрат і вартості Оцінки трудовитрат і вартості звичайно ґрунтуються на результатах оцінок розмірів, робіт і інших

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

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

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

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

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

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

Рекомендовані робочі продукти - результати даного етапу: обґрунтування оцінок, оцінки проектних трудовитрат, оцінки проектної вартості.

5. Установлення бюджету й графіка Установлення бюджету й графіка - перший крок у розробці плану проекту. Загальна схема

розробки плану проекту представлена на рис. 6.

Рисунок 6. Схема розробки плану проекту

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

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

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

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

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

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

Рекомендовані робочі продукти - результати даного етапу: графік проекту; критичний шлях; бюджет проекту.

6.Визначення проектних ризиків

Угрупі процесів «Планування проекту» виконуються ідентифікація ризикових подій, їхній аналіз

івизначення пріоритетів, у групі «Моніторинг і контроль проекту» проводиться моніторинг ризиків, в групі «Управління ризиками» здійснюються відстеження й пом'якшення впливу ризиків.

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

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

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

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

Рекомендовані робочі продукти - результати даного етапу: список ідентифікованих ризиків; вплив ризиків і ймовірність їхнього прояву; пріоритети ризиків.

7. Планування управління проектними даними Під проектними даними розуміють різні форми документації. Документуються всі аспекти

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

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

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

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

Рекомендовані робочі продукти - результати даного етапу: план управління даними; перелік керованих даних; опис змісту й формату даних; вимоги до конфіденційності й безпеки даних; механізм повернення, відтворення й розподілу даних; графік збору даних; перелік даних, які повинні збиратися в проекті.

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

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

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

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

Рекомендовані робочі продукти - результати даного етапу: робочі пакети структури робіт; словник задач WBS; вимоги до людських ресурсів; перелік критично важливого обладнання й виробничих площ; описи й діаграми процесів; перелік вимог до адміністрування проекту.

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

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

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

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

Рекомендовані робочі продукти - результати даного етапу: перелік необхідних знань; плани укомплектування проектної команди; плани наймання нового персоналу; бази даних (наприклад, навички й навчання).

10. Планування залучення зацікавлених осіб

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

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

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

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

Рекомендовані робочі продукти - результати даного етапу: список зацікавлених осіб; матриця залучення; ролі й відповідальності в проекті.

11. Установлення плану проекту Результатом робіт із планування проекту є документований план, що визначає всі аспекти проекту:

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

12.Аналіз планів

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

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

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

Рекомендовані робочі продукти - результати даного етапу: записи про аналіз планів.

13.Узгодження рівнів робіт і ресурсів

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

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

Рекомендовані робочі продукти - результати даного етапу: ревізовані методи й параметри оцінки (наприклад, краще обладнання, використання покупних компонентів); переглянуті бюджети; уточнені графіки; список ревізованих вимог; переглянуті угоди між зацікавленими особами.

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

здійсненними й беруть на себе зобов'язання виконати доручені їм задачі. У моделі CMMI всі ці аспекти включені в термін commitment, що будемо перекладати як «зобов'язання».

Дуже часто «зобов'язання» інтерпретують як обов'язок і ототожнюють із покладанням обов'язків по виконанню роботи. Модель CMMI вкладає інший зміст у цей термін. Поняття «зобов'язання» означає, що робота зрозуміла виконавцеві, що він уважає цю роботу необхідною й здійсненною, що він приймає на себе зобов'язання виконати цю роботу в строк і якнайкраще. Можна зобов'язати співробітника виконати те або інше завдання, але важко очікувати, що він докладе всіх зусіль і вміння для його виконання. Скоріше треба приготуватися до пояснень із приводу того, чому дана робота не могла бути виконана.

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

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

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

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

Рекомендовані робочі продукти - результати даного етапу: документовані запити на прийняття зобов'язань; документовані зобов'язання.

Глосарій

Група процесів (process area) — група взаємозалежних практик, виконання яких дозволяє досягти мети даної групи процесів.

Ціль (goal) - заява на вищому рівні про те, що повинно бути досягнуто при ефективному застосуванні практик. Спеціальні цілі застосовні до кожної групи процесів.

Практика (practice) — опис дій, які варто почати, щоб «пустити в хід» ключові елементи даної групи процесів. Спеціальна практика - це дії, що необхідні для досягнення спеціальної мети.

Типовий робочий продукт (typical work product) — приклад того, що повинно бути отримане в результаті виконання спеціальної або загальної практики. Ці приклади названі типовими робочими продуктами, тому що можуть існувати й інші, не менш ефективні, робочі продукти.

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

Уточнення (discipline amplification) містять інформацію про конкретну інженерну дисципліну (наприклад, програмування, системний інжиніринг) і пов'язані зі спеціальними практиками.

Загальна ціль (generic goal) називається загальною тому, що одне й та саме формулювання цілі з'являється в різних групах процесів. У стадійному поданні CMMI кожна група процесів має тільки одну загальну ціль.

Загальна практика (generic practice) — елемент інституалізації процесів, певним чином гарантія того, що процеси даної групи будуть ефективними, повторюваними й стабільними.

Уточнення загальних практик (Generic practice elaborations) є

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

Тема. ОРГАНІЗАЦІЯ ОФІСУ ПРОЕКТУ

1.Поняття офісу проекту

2.Основні принципи проектування й склад офісу проекту

3.Основні принципи організації віртуального офісу проекту

1. Поняття офісу проекту

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

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

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

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

Офіс проекту - це оптимально організоване середовище (у традиційному розумінні місце), де члени команди проекту можуть здійснювати процеси управління проектом, проводити наради, вести переговори

зпартнерами, зберігати проектну документацію.

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

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

головний офіс, де розміщається менеджер проекту, проводяться важливі наради, зберігається основна документація, встановлені засоби зв'язку, комп'ютерне обладнання й оргтехніка тощо;

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

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

Убагатопроектній системі офіс проекту, як правило, являє собою багаторівневу систему:

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

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

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

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

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

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

Реалізація бізнес-процесів у рамках управління проектом повинна бути організована оптимальним чином і це обумовлює вимоги до організації офісу:

інформаційний супровід бізнес-процесу повинен бути орієнтований на оптимальне за часом і витратами його виконання;

повинне бути виключене дублювання бізнес-операцій;

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

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

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

6.2.2.На ньому представлена схема планування офісу, розміщень-комп'ютерів і засобів зв'язку, розміщення персоналу відповідно до бізнес-процесів, реалізованими їм.

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

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

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