
- •Технологія програмування та створення програмних продуктів
- •(частина 2)
- •Візуальне моделювання на основі UML
- •MSF – Модель проектної групи (v. 3.1)
- •Анотація
- •1. Основи моделі проектної групи MSF
- •Основні принципи
- •Розподіл відповідальності при фіксації звітності
- •Наділення членів команди повноваженнями
- •Концентрація на бізнес-пріоритетах
- •Єдине бачення проекту
- •Прояв гнучкості і готовність до змін
- •Заохочення вільного спілкування
- •2. Ключові концепції
- •Команда соратників
- •Фокусування на потребах замовника
- •Націленість на кінцевий результат
- •Установка на відсутність дефектів
- •Прагнення до самовдосконалення
- •Зацікавлені команди працюють ефективно
- •3. Випробувані методики
- •Малі багатопрофільні проектні групи
- •Колективна робота
- •Загальна участь в проектуванні
- •4. Огляд моделі команди MSF
- •Задоволені замовники
- •Досягнення результату в рамках проектних обмежень
- •Створення продукту відповідно до специфікації
- •Схвалення випуску продукту лише після того, як всі дефекти виявлені і відлагоджені
- •Підвищення споживчої цінності продукту
- •Безпроблемне впровадження і супровід продукту
- •Ролеві кластери моделі проектної групи
- •I. Ролевий кластер "Управління продуктом"
- •Області компетенції
- •1. Планування продукту
- •2. Бізнес-віддача
- •3. Представлення інтересів замовника
- •4. Маркетинг
- •II. Ролевий кластер "Управління програмою"
- •Області компетенції
- •1. Управління проектом
- •2. Вироблення архітектури рішення
- •3. Контроль виробничого процесу
- •4. Адміністративні служби
- •III. Ролевий кластер "Розробка"
- •Області компетенції
- •1. Технологічне консультування
- •2. Проектування і здійснення реалізації
- •3. Розробка програмних рішень
- •4. Розробка інфраструктури
- •IV. Ролевий кластер "Тестування"
- •Області компетенцій
- •1. Планування тестів
- •2. Розробка тестів
- •3. Звітність про тести
- •V. Ролевий кластер "Задоволення споживача"_
- •Області компетенцій
- •1. Загальнодоступність
- •2. Інтернаціоналізація
- •3. Забезпечення технічної підтримки
- •4. Навчання користувачів
- •5. Зручність експлуатації (ергономіка)
- •6. Графічний дизайн
- •VI. Ролевий кластер "Управління випуском"
- •Області компетенції
- •1. Управління випуском
- •2. Інфраструктура
- •3. Супровід
- •4. Бізнес-процеси
- •Масштабування моделі проектної групи
- •Групи напрямів
- •Функціональні групи
- •Об'єднання ролей
- •Ескалація і підзвітність
- •Модель проектної групи немає організаційної структури
- •Зовнішня координація – на кому лежить відповідальність?
- •Висновок
- •MSF: Модель процесів
- •Анотація
- •Короткий огляд методології
- •Введення
- •Інші моделі процесів
- •Краще з двох світів
- •Базові принципи MSF
- •Єдине бачення проекту
- •Проявляйте гнучкість – будьте готові до змін
- •Концентруйтеся на бізнес - пріоритетах
- •Заохочуйте вільне спілкування
- •Ключові концепції моделі процесів MSF
- •Замовники
- •Зацікавлені сторони (учасники)
- •Що є рішення?
- •Створення базових версій
- •Рамки проекту
- •Управління компромісами
- •Трикутник компромісів
- •Матриця компромісів проекту
- •Характеристики моделі процесів MSF
- •Підхід, заснований на віхах
- •Характеристики підходу, заснованого на віхах
- •Головні і проміжні віхи
- •Віхи як точки синхронізації
- •Віхи як орієнтири виробничої відповідальності
- •Провідні ролі різних фаз
- •Аналіз пройдених віх
- •Ітеративний підхід
- •Характеристики ітеративного підходу
- •Випуск версій
- •Створення "живої" документації
- •Ранні базові версії, відкладені підсумкові версії
- •Щоденні білди
- •Управління конфігураціями проекту
- •Рекомендації для випуску версій рішення
- •Створюючи плани, передбачайте версіонування
- •Перш за все, поставляйте базову функціональність
- •Вибирайте пріоритети, враховуючи ризики
- •Здійснюйте часті ітерації розробки
- •Інституціюйте процедури контролю змін в проекті
- •Цілісний погляд на розробку і впровадження
- •Переваги інтегрованої моделі процесів
- •Зосередження на потребах підприємства
- •Покращена підтримка розробки веб-приложений
- •Покращена підтримка веб-сервісів
- •Поліпшення взаємодії з командою супроводу
- •Зауваження про використання інтегрованої моделі процесів
- •Тривалість фаз не однакова
- •Діяльність може виходити за межі однієї фази
- •Проекти, обмежені розробкою застосування або впровадженням інфраструктури
- •Фази і віхи моделі процесів MSF
- •Фаза вироблення концепції
- •Введення
- •Віха "Концепція затверджена"
- •Результати
- •Основні завдання проектної групи на фазі вироблення концепції
- •Проміжні віхи, що рекомендуються
- •Ядро проектної групи сформоване
- •Чорновий варіант концепції проекту складений
- •Фаза планування
- •Введення
- •Віха "Плани проекту затверджені"
- •Результати
- •Основні завдання проектної групи на фазі планування
- •Проміжні віхи, що рекомендуються
- •Верифікація технологій
- •Базова версія функціональної специфікації створена
- •Базова версія звідного плану проекту створена
- •Базова версія звідного календарного графіка проекту створена
- •Середовища розробки і тестування розгорнені
- •Фаза розробки
- •Введення
- •Віха "Розробка завершена"
- •Результати
- •Основні завдання проектної групи на фазі розробки
- •Проміжні віхи, що рекомендуються
- •Концепція підтверджена
- •Білд n завершений, білд n+1 завершений...
- •Фаза стабілізації
- •Введення
- •Віха "Готовність рішення затверджена"
- •Результати
- •Основні завдання проектної групи на фазі стабілізації
- •Проміжні віхи, що рекомендуються
- •Точка конвергенції
- •Точка досягнення нуля
- •Версії-кандидати
- •Контрольне тестування завершене
- •Тестування прийнятності для споживачів завершене
- •Пілотне впровадження завершене
- •Фаза впровадження
- •Введення
- •Віха "Впровадження завершене"
- •Результати
- •Основні завдання проектної групи на фазі впровадження
- •Проміжні віхи, що рекомендуються
- •Ключові компоненти розгорнені
- •Впровадження на місцях завершене
- •Упроваджене рішення стабілізоване
- •Методики моделі процесів MSF, що рекомендуються
- •Стимулювання винахідливості для розширення функціональності й обмеження ресурсів
- •Фіксування календарного графіка
- •Календарне планування на невизначене майбутнє
- •Використання паралельно працюючих компактних команд
- •Розбиття великих проектів на реальні частини
- •Отримання уроків з пройдених віх
- •Використання прототипіювання
- •Використання частих білдів і швидких тестів
- •Часті ітерації розробки і впровадження
- •Уникання розповзання рамок проекту
- •Оцінка з низу до верху
- •Інтеграція представлених проектною групою оцінок
- •Застосування A
- •Зміни в порівнянні з попередньою версією MSF
- •Висновок
- •Література
- •Анотація
- •Введення
- •Основні відомості про ризики
- •Базові принципи:
- •1. Гнучкість і постійна готовність до змін
- •2. Вільне спілкування
- •3. Отримання зі всього уроків
- •4. Розподіл відповідальності при фіксації звітності
- •Ключові концепції:
- •Найбільш ефективним є превентивне управління ризиками
- •2. Заохочення до виявлення ризиків
- •3. Постійна оцінка ризиків
- •4. Підтримка відкритого спілкування
- •5. Постійний аналіз ризиків
- •6. Кількість ризиків не характеризує реальне положення речей
- •Планування управління ризиками
- •Процес управління ризиками
- •Загальне уявлення
- •Етап 1. Виявлення ризиків
- •Введення
- •Початкові дані
- •Кроки по виявленню ризиків
- •Структурований підхід
- •Класифікація ризиків
- •Формулювання ризиків
- •Результати
- •Етап 1. Аналіз і пріоритезація ризиків
- •Введення
- •Мета
- •Початкові дані
- •Процес аналізу ризиків
- •Вірогідність ризику
- •Загроза ризику
- •Очікувана величина ризику
- •Додаткові кількісні методики
- •Результати
- •Головна таблиця ризиків
- •Інші методи проведення аналізу
- •Документ опису ризиків
- •Список головних ризиків
- •Деактивація ризиків
- •Планування ризиків_
- •Введення
- •Початкові дані
- •Заходи
- •Дослідження
- •Ухвалення
- •Уникнення
- •Перенесення
- •Запобігання
- •Пом'якшення наслідків (реагування)
- •Календарне планування
- •Результати
- •Діяльність по управлінню ризиками
- •Документування планів
- •Оновлення плану і календарного графіка проекту
- •Моніторинг ризиків_
- •Початкові дані
- •Заходи щодо моніторингу
- •Звітність про стан ризиків
- •Результати
- •Коректування ситуації_
- •Мета
- •Початкові дані
- •Дії з коректування ситуації
- •Результати
- •Витягання уроків з ризиків
- •Введення
- •Типи отримуваних уроків
- •Управління витяганням уроків
- •Контекстна класифікація ризиків
- •База знань про ризики
- •Досягнення зрілості в управлінні знаннями про ризики
- •Управління ризиками як складова частина життєвого циклу проекту_
- •Управління ризиками на підприємстві
- •Створення культури управління ризиками
- •Управління портфелем проектів_
- •Висновок
- •MSF: Дисципліна управління проектами
- •Анотація
- •Введення
- •Базові принципи MSF
- •Пр.1: Розподіл відповідальності при фіксації звітності
- •Пр.2: Наділення членів команди повноваженнями
- •Ключові концепції
- •1) Дисципліни MSF
- •2) Поняття управління проектом
- •3) Менеджмент проекту і менеджер проекту
- •4) Управління проектами і специфічні IT-процеси
- •Особливості управління проектами в MSF
- •Роль менеджера проекту покладається на кластер "Управління програмою"
- •Взаємодія "Управління програмою" з лідерами командних ролей
- •A. Функціональні групи
- •B. Групи напрямів
- •Масштабування функцій управління проектом
- •Обов'язки по управлінню проектами
- •Лідери груп
- •Кластер "Управління програмою"
- •Управління великими і складними проектами
- •Адміністративні служби проекту
- •Звітність перед замовником
- •Рекомендації проектним групам
- •Управління рамками проекту
- •Визначення рамок на етапі вироблення концепції
- •Рамки рішення і рамки проекту
- •Визначення рамок (scope definition)
- •Управління змінами рамок (scope change control)
- •Підготовка планів
- •Повторне використання документів
- •Плани проекту
- •Ієрархічна структура робіт
- •Відповідність між WBS, функц. специфікаціями і зведеним планом
- •Створення WBS
- •Рекомендації по декомпозиції роботи
- •Оцінка знизу вгору
- •Інтеграція представлених проектною групою оцінок
- •Формування реалістичних очікувань
- •Невизначеність і точність оцінок
- •Оцінюйте завдання нижнього рівня декомпозиції
- •Аналіз PERT
- •Рекомендації по складанню календарного графіка
- •1) Впорядкування завдань
- •2) Обмеження часу
- •3) Вибір пріоритетів, з врахуванням ризиків
- •Створення часових буферів
- •Висновок
- •MSF: Дисципліна "Управління підготовкою"
- •Анотація
- •Вступ
- •Базові принципи
- •Пр.1: Заохочення вільного спілкування
- •Пр.2: Інвестування в якість
- •Пр.2: Отримання уроків
- •Пр.3: Гнучкість та готовність до змін
- •Ключові концепції
- •1) Інвентаризація наявних знань
- •2) Прагнення до самовдосконалення
- •3) Підготовка повинна бути перманентним процесом
- •Випробувані методики
- •1) Планування підготовки
- •Оцінка і моніторинг професійного рівня і індивідуальних цілей
- •Відноситеся до пропусків в підготовці як до ризиків
- •Огляд процесу Управління підготовкою
- •1) Визначення:
- •2) Оцінювання:
- •3) Коригування:
- •4) Осмислення:
- •Превентивне Управління підготовкою
- •Підготовка впродовж життєвого циклу ІТ
- •Кроки процесу Управління підготовкою
- •Крок 1: Визначення
- •Скл. 1: Проектні сценарії
- •Скл. 2: Кваліфікаційні вимоги
- •Скл. 3: Професійні навики
- •Крок 2: Оцінювання
- •Оцінка знань, умінь, здібностей
- •Специфікація процесу оцінювання
- •Збір і обробка даних
- •Обробка результатів оцінювання
- •Аналіз невідповідностей
- •Створення планів навчання
- •Крок 3: Коригування
- •Навчання
- •Моніторинг прогресу
- •Крок 4: Осмислення
- •Аналіз результатів
- •Управління знаннями
- •Вимоги до професійних навиків проектних ролей
- •Створення планів підготовки
- •Висновок
Також сусідство робочих місць допомагає команді укріпити відчуття згуртованості і єдності. Зближення співробітників – наприклад, робота в одній секції будівлі, об'єднання їх офісів або виділення спеціального місця для збору команди – найбільш ефективний спосіб створення умов для вільного спілкування є суттєвою складовою формули командного успіху
MSF.
Проте, хоча ідеальним вибором є зближення робочих місць, вимоги бізнесу і сучасні технологічні нововведення в комунікаціях роблять можливим створення успішних "віртуальних" команд.
Віртуальні команди – це команди, що взаємодіють і спілкуються головним чином за допомогою електронних комунікацій. Обмін інформацією в них йде через межі країн і організацій, простір і час. Зв'язок з колегами через Internet в режимі реального часу корінним чином міняє принципи роботи і обміну інформацією. Internet стає для членів команди новим комунікаційним стандартом, і програмне забезпечення, що робить можливою віддалену колективну роботу, відкриває шлях до подальшого підвищення продуктивності в нових умовах.
Для віртуальних команд модель проектної групи MSF є ключовою. Без належного рівня організації, об'єднуючого всі робочі ролі в єдине ціле, віддаленість працівників зажадала б ще більшої кількості дискусій, договорів і взаємозв'язків, жорсткішого планування і додаткових інструментів моніторингу проекту для забезпечення злагодженості роботи.
Життєво важлива складова віртуальної команди – це упевненість кожного її члена в можливості спиратися на інших, що досягається виробленням загальної корпоративної культури, невпинною управлінською роботою і – як тільки це стає можливим – перенесенням роботи в одне місце (або хоч би сумісним відпочинком).
Дослідження показують, що при формуванні віртуальних команд комунікаційним здібностям і соціальним якостям працівників зазвичай приділяється недостатня увага.
Аналітики говорять, що це упущення зазвичай є основною причиною невдач багатьох проектів. Тому при створенні віртуальної команди підбирайте людей, які:
•можуть працювати самостійно;
•володіють лідерськими якостями;
•мають необхідні для створення продукту професійні навики;
•здатні передавати свої знання колегам;
•можуть допомогти в розвитку ефективних методів роботи.
Загальна участь в проектуванні
Кожен ролевий кластер бере участь в створенні специфікації рішення, оскільки має унікальний погляд на продукт з погляду його відповідності своїм завданням, також як і завданням всієї команди. Це створює клімат, стимулюючий виникнення і втілення кращих ідей, що охоплюють всі точки зору.
4. Огляд моделі команди MSF
MSF заснований на постулаті про шість якісних цілей, досягнення яких визначає успішність проекту. Ці цілі обумовлюють модель проектної групи. Тоді як за успіх проекту відповідальна вся команда, кожен з її ролевих кластерів, визначуваних моделлю, асоційований з однією із згаданих шести цілей і працює над її досягненням.
Шість ролевих кластерів моделі проектної групи – це
1."Управління продуктом" (product management),
2."Управління програмою" (program management),
3."Розроблення" (development),
23
4."Тестування" (test),
5."Задоволення споживача" (user experience) і
6."Управління випуском" (release management).
Вони відповідальні за різні області компетенції (functional areas) і пов'язані з ними цілі і завдання. Іноді ролеві кластери називаються просто ролями. Але у будь-якому випадку суть концепції залишається тій же – побудувати основу виробничих відносин і пов'язану з нею модель команди такими, щоб вони були пристосованими (масштабованими) для задоволення потреб будь-якого проекту. Одна роль (або один кластер) може бути представлена одним або декількома співробітниками, залежно від розміру проекту, його складності і професійних навиків, потрібних для реалізації всіх областей компетенції кластера.
Модель проектної групи MSF підкреслює важливість побудови ролевих кластерів відповідно до потреб бізнесу. Угрупування зв'язаних областей компетенції, кожна з яких має свою специфіку, забезпечує хорошу збалансованість команди. Чітке визначення цілей підвищує рівень відповідальності і сприяє кращому їх сприйняттю проектною командою, що негайно позначається найкращим чином на якості продукту, що випускається. Оскільки кожна з цілей однаково необхідна для успішності проекту, всі ролі знаходяться в рівноправних партнерських взаєминах з рівною значущістю при ухваленні рішень.
Відмітимо, що використання ролевих кластерів не має на увазі і не нав'язує ніякої спеціальної структури організації або обов'язкових посад. Адміністративний склад ролей може широко варіюватися в різних організаціях і проектних групах. Найчастіше ролі розподіляються серед різних підрозділів однієї організації, але іноді частина їх відводиться співтовариству споживачів або зовнішнім по відношенню до організації консультантам і партнерам. Ключовим моментом є чітке визначення працівників, відповідальних за кожен ролевий кластер, їх функцій, відповідальності і очікуваного внеску в кінцевий результат.
Ролевий |
Мета |
|
Область компетенції |
|
|
|
Функції |
|
|
|
||
кластер |
|
|
|
|
|
|
|
|
|
|
|
|
Управління |
Задоволені |
|
Маркетинг |
|
Виступає в ролі представника замовника |
|
||||||
продуктом |
замовники |
|
Бізнес-віддача (бізнес - |
Формує загальне бачення рамок проекту |
|
|||||||
|
|
|
пріоритети) |
|
Організовує |
роботу |
з |
|
вимогами |
|||
|
|
|
Представлення |
інтересів |
замовника |
|
|
|
|
|
|
|
|
|
|
замовника |
|
Розвиває сфери застосування в бізнесі |
|
||||||
|
|
|
Планування продукту |
Формує очікування замовника |
|
|
||||||
|
|
|
|
|
Визначає |
компроміси |
між |
параметрами |
||||
|
|
|
|
|
"можливості продукту / час / ресурси" |
|
||||||
|
|
|
|
|
Організовує |
|
маркетинг, |
|
PR |
і |
||
|
|
|
|
|
євангелізацію |
|
|
|
|
|
||
|
|
|
|
|
Розробляє, підтримує і виконує план |
|||||||
|
|
|
|
|
комунікацій |
|
|
|
|
|
|
|
Управління |
Досягнення |
|
Управління проектом |
Управляє процесом розробки з метою |
||||||||
програмою |
результату в рамках |
Вироблення |
архітектури |
отримання готового продукту у відведені |
||||||||
|
проектних |
|
рішення |
|
терміни |
|
|
|
|
|
|
|
|
обмежень |
|
Контроль |
виробничого |
Формулює |
специфікацію |
продукту |
і |
||||
|
|
|
процесу |
|
розробляє його архітектуру |
|
|
|
||||
|
|
|
Адміністративні служби |
Регулює |
взаємини |
і |
комунікацію |
|||||
|
|
|
|
|
усередині проектної групи |
|
|
|
||||
|
|
|
|
|
Стежить |
за |
тимчасовим |
графіком |
||||
|
|
|
|
|
проекту і готує звітність про його стан |
|
||||||
|
|
|
|
|
Проводить в життя важливі компромісні |
|||||||
|
|
|
|
|
рішення |
|
|
|
|
|
|
|
|
|
|
|
|
Розробляє, підтримує і виконує звідний |
|||||||
|
|
|
|
|
план і календарний графік проекту |
|
||||||
|
|
|
|
|
Організовує управління ризиками |
|
||||||
Розробка |
Створення продукту |
Технологічне |
|
Визначає деталі фізичного дизайну |
|
|||||||
|
відповідно |
до |
консультування |
Оцінює необхідні час і ресурси на |
||||||||
|
специфікації |
|
Проектування |
і здійснення |
реалізацію кожного елементу дизайну |
|
||||||
|
|
|
реалізації |
|
Розробляє |
|
або |
контролює |
розробку |
|||
|
|
|
|
|
|
|
|
|
|
|
24 |
|
|
|
|
|
|
|
|
Розробка застосувань |
елементів |
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
Розробка інфраструктури |
Готує продукт до впровадження |
|
|
||||||||
|
|
|
|
|
|
|
|
|
|
|
|
Консультує |
команду |
по |
технологічних |
||||
|
|
|
|
|
|
|
|
|
|
|
|
питаннях |
|
|
|
|
|
|
|
|
Тестування |
Схвалення |
випуску |
Планування тестів |
Забезпечує виявлення всіх дефектів |
|
|||||||||||||
|
|
|
продукту |
|
тільки |
Розробка тестів |
|
|
Розробляє стратегію і плани тестування |
||||||||||
|
|
|
після того, як всі |
Звітність по тестах |
Здійснює тестування |
|
|
|
|
|
|
||||||||
|
|
|
дефекти |
виявлені |
і |
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
улагоджені |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Задоволення |
Підвищення |
|
|
|
Забезпечення |
|
|
технічної |
Представляє |
інтереси |
|
споживача |
в |
|||||
|
споживача |
ефективності |
|
|
підтримки |
|
|
|
команді |
|
|
|
|
|
|
|
|||
|
|
|
користувача, |
|
|
Навчання |
|
|
|
Організовує |
роботу |
|
з |
вимогами |
|||||
|
|
|
збільшення |
|
|
|
Ергономіка |
|
|
|
користувача |
|
|
|
|
|
|
|
|
|
|
|
споживчої |
цінності |
Графічний дизайн |
Проектує і розробляє системи підтримки |
|||||||||||||
|
|
|
продукту |
|
|
|
|
Інтернаціоналізація |
продуктивності |
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
Загальнодоступність |
Визначає компроміси, що відносяться до |
||||||||||
|
|
|
|
|
|
|
|
(забезпечення |
можливості |
зручності використання |
і |
споживчих |
|||||||
|
|
|
|
|
|
|
|
роботи для |
користувачів з |
якостей продукту |
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
обмеженими |
|
фізичними |
Визначає вимоги до системи допомоги і |
||||||||
|
|
|
|
|
|
|
|
можливостями) |
|
|
її зміст |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Розробляє учбові матеріали і здійснює |
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
навчання користувачів |
|
|
|
|
|
||
|
Управління |
Безпроблемне |
|
|
Інфраструктура |
|
|
Представляє |
інтереси |
|
відділів |
||||||||
|
випуском |
впровадження |
і |
Супровід |
|
|
|
постачання і обслуговування продукту |
|||||||||||
|
|
|
супровід продукту |
|
|
Бізнес - процеси |
|
|
Організовує постачання проектної групи |
||||||||||
|
|
|
|
|
|
|
|
Управління |
|
|
випуском |
Організовує впровадження продукту |
|
||||||
|
|
|
|
|
|
|
|
готового продукту |
Виробляє компроміси в керованості і |
||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
зручності супроводу продукту |
|
|
|||||
|
|
|
|
|
|
|
|
|
|
|
|
Організовує |
супровід і |
інфраструктуру |
|||||
|
|
|
|
|
|
|
|
|
|
|
|
постачання |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Організовує |
логістичне |
забезпечення |
|||||
|
|
|
|
|
|
|
|
|
|
|
|
проектної групи |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ролевий |
|
Відповідальність |
|
|
Мета |
|
|
Область компетенції |
|
Функції |
|
|
||||||
|
кластер |
|
|
|
|
|
|
|
|
||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Виступає |
в |
ролі |
представника |
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
замовника |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Формує |
|
|
|
|
загальне |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
бачення/рамки проекту |
|
|||||
|
|
|
|
|
|
|
|
|
|
|
Маркетинг |
|
Організовує роботу з вимогами |
||||||
|
|
|
|
|
|
|
|
|
|
|
|
замовника |
|
|
|
|
|
||
|
Управління |
|
|
|
|
|
|
|
|
Бізнес-віддача (бізнес - |
Розвиває сфери застосування в |
||||||||
|
Формування |
вимог |
|
|
Задоволені |
|
|
пріоритети) |
|
бізнесі |
|
|
|
|
|
|
|||
|
продуктом |
до продукту |
|
|
|
замовники |
|
|
Представлення інтересів |
Формує очікування замовника |
|||||||||
|
|
|
|
|
|
|
|
|
|
|
замовника |
|
Визначає |
|
компроміси |
між |
|||
|
|
|
|
|
|
|
|
|
|
|
Планування продукту |
параметрами |
|
"можливості |
|||||
|
|
|
|
|
|
|
|
|
|
|
|
|
продукту / час / ресурси" |
|
|||||
|
|
|
|
|
|
|
|
|
|
|
|
|
Організовує маркетинг, PR і |
||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
євангелізацію |
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
Розробляє, підтримує і виконує |
||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
план комунікацій |
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
Управляє процесом розробки з |
||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
метою |
отримання |
готового |
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
продукту у відведені терміни |
||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
Формулює |
|
|
специфікацію |
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
продукту |
і |
|
розробляє |
його |
||
|
|
|
|
|
|
|
|
|
|
|
|
|
архітектуру |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Управління проектом |
Регулює |
|
|
взаємини |
і |
|||
|
|
|
|
|
|
|
|
|
|
|
комунікацію |
|
|
|
усередині |
||||
|
|
|
|
|
|
|
|
|
|
|
Вироблення |
архітектури |
|
|
|
||||
|
Управління |
|
|
|
|
|
Досягнення |
|
|
проектної групи |
|
|
|
||||||
|
Поставка |
продукту |
|
|
|
|
рішення |
|
|
|
|
||||||||
|
|
|
результату в рамках |
|
виробничого |
Стежить |
|
за |
тимчасовим |
||||||||||
|
програмою |
замовнику |
|
|
|
проектних обмежень |
|
Контроль |
графіком |
|
проекту |
і готує |
|||||||
|
|
|
|
|
|
|
|
|
процесу |
|
|
||||||||
|
|
|
|
|
|
|
|
|
|
|
Адміністративні служби |
звітність про його стан |
|
||||||
|
|
|
|
|
|
|
|
|
|
|
Проводить |
в |
життя |
важливі |
|||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
компромісні рішення |
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
Розробляє, підтримує і виконує |
||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
звідний |
план |
і |
календарний |
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
графік проекту |
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
Організовує |
|
|
управління |
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
ризиками |
|
|
|
|
|
|
|
Архітектори |
Проектування |
|
|
Проектування |
|
|
|
|
Розробка архітектури продукту |
|||||||||
|
продукту |
|
|
|
|
продукту |
з |
|
|
|
Розробка структури продукту |
||||||||
|
|
|
|
|
|
|
|
|
|
||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
25 |
|
|
урахуванням |
|
|
|
|
|
|
|
|
|
|
|
|
|
існуючих обмежень |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Визначає |
деталі |
фізичного |
||||
|
|
|
|
|
Технологічне |
|
дизайну |
|
|
|
|
|
|
|
|
|
|
|
|
Оцінює необхідні час і ресурси |
|||||||
|
Розроблення |
Створення |
продукту |
консультування |
|
на |
реалізацію |
|
кожного |
||||
Розробка |
відповідно |
до |
Проектування і здійснення |
елементу дизайну |
|
|
|
||||||
продукту |
реалізації |
|
Розробляє |
|
або |
контролює |
|||||||
|
специфікації |
|
|
|
|||||||||
|
|
|
Розробка застосувань |
розробку елементів |
|
|
|
||||||
|
|
|
|
|
|
|
|
||||||
|
|
|
|
|
Розробка інфраструктури |
Готує продукт до впровадження |
|||||||
|
|
|
|
|
|
|
Консультує |
|
команду |
по |
|||
|
|
|
|
|
|
|
технологічних питаннях |
|
|
||||
|
|
Схвалення |
випуску |
|
|
Забезпечує |
|
виявлення |
всіх |
||||
Тестування |
Забезпечення якості |
продукту |
тільки |
Планування тестів |
дефектів |
|
|
|
|
|
|||
після того, як всі |
Розробка тестів |
|
Розробляє |
стратегію |
і |
плани |
|||||||
продукту |
|
||||||||||||
|
дефекти виявлені |
і |
Звітність по тестах |
тестування |
|
|
|
|
|
||||
|
|
|
|
|
|
|
|||||||
|
|
улагоджені |
|
|
|
|
Здійснює тестування |
|
|
||||
|
|
|
|
|
|
|
Представляє |
|
|
інтереси |
|||
|
|
|
|
|
Забезпечення |
технічної |
споживача в команді |
|
|
||||
|
|
|
|
|
Організовує роботу з вимогами |
||||||||
|
|
|
|
|
підтримки |
|
|||||||
|
|
|
|
|
|
користувача |
|
|
|
|
|
||
|
|
Підвищення |
|
|
Навчання |
|
|
|
|
|
|
||
|
|
|
|
|
Проектує і |
розробляє |
системи |
||||||
|
|
|
|
Ергономіка |
|
||||||||
|
|
ефективності |
|
|
підтримки продуктивності |
|
|||||||
Задоволення |
Забезпечення |
|
Графічний дизайн |
|
|||||||||
користувача, |
|
Визначає |
компроміси, |
що |
|||||||||
придатності |
|
Інтернаціоналізація |
|||||||||||
споживача |
збільшення |
|
|
відносяться |
|
до |
зручності |
||||||
продукту |
|
|
Загальнодоступність |
|
|||||||||
|
споживчої |
цінності |
використання |
і |
споживчих |
||||||||
|
|
(забезпечення можливості |
|||||||||||
|
|
продукту |
|
|
якостей продукту |
|
|
|
|||||
|
|
|
|
роботи для користувачів з |
|
|
|
||||||
|
|
|
|
|
Визначає вимоги |
до |
системи |
||||||
|
|
|
|
|
обмеженими |
фізичними |
|||||||
|
|
|
|
|
допомоги і її зміст |
|
|
|
|||||
|
|
|
|
|
можливостями) |
|
|
|
|
||||
|
|
|
|
|
|
Розробляє |
учбові |
матеріали і |
|||||
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
здійснює навчання користувачів |
||||||
|
|
|
|
|
|
|
Представляє |
інтереси |
відділів |
||||
|
|
|
|
|
|
|
постачання |
і |
обслуговування |
||||
|
|
|
|
|
|
|
продукту |
|
|
|
|
|
|
|
|
|
|
|
|
|
Організовує |
|
|
постачання |
|||
|
|
|
|
|
Інфраструктура |
|
проектної групи |
|
|
|
|||
|
|
|
|
|
|
Організовує |
|
впровадження |
|||||
Управління |
|
Безпроблемне |
|
Супровід |
|
|
|||||||
Впровадження |
|
|
продукту |
|
|
|
|
|
|||||
впровадження |
і |
Бізнес - процеси |
|
|
|
|
|
||||||
випуском |
продукту |
Виробляє |
|
компроміси |
в |
||||||||
супровід продукту |
|
Управління |
випуском |
|
|||||||||
|
|
|
керованості |
|
і |
зручності |
|||||||
|
|
|
|
|
готового продукту |
|
|||||||
|
|
|
|
|
супроводу продукту |
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
Організовує |
|
супровід |
і |
|||
|
|
|
|
|
|
|
інфраструктуру постачання |
||||||
|
|
|
|
|
|
|
Організовує |
|
|
логістичне |
|||
|
|
|
|
|
|
|
забезпечення проектної групи |
Задоволені замовники
Успішний проект повинен породжувати рішення, що задовольняє замовників і споживачів. Можна повністю вкластися у відведений час і бюджет, але при цьому потерпіти повну невдачу, якщо потреби замовників не будуть задоволені.
Досягнення результату в рамках проектних обмежень
Ключова мета будь-якої проектної групи – створення рішення в рамках встановлених обмежень. Основні обмеження всякого проекту – це виділений бюджет і терміни. Успішність більшості проектів визначається саме витраченим часом і засобами.
Створення продукту відповідно до специфікації
Специфікація продукту детально описує, що саме проектна група повинна поставити замовникові. Для проектної групи важливо максимально точно слідувати специфікації продукту, що поставляється, оскільки вона складає суть угоди між проектною групою і замовником.
26