2017-10-25
862
Робота над проектом включає безліч різних видів діяльності й вивчення вимог з різних точок зору, тому розподіл основних завдань по декількох ролях підвищує шанси на успіх проекту. Як видно з рис. 2.1. визначені шість таких ролей, які й становлять модель проектної групи. У кожної з ролей свої обов'язки, виконання яких і спричиняється удачу проекту.
|
|
|
|
|
|
|
Рис. 1.1. Ролі в моделі проектної групи
Звичайно кожну роль виконують кілька людей, один із яких вважається керівником, саме він на нарадах з іншими членами групи представляє свій напрямок. Колективна відповідальність не повинна виливатися в колективну безвідповідальність. Це особливо важливо в моделі проектної групи, оскільки виконання кожною роллю всіх своїх обов'язків – обов'язкова умова успіху проекту.
Менеджер продукту
Менеджер продукту повинен вчасно реагувати на потреби замовника. Його головне завдання – сформувати загальне подання про поставлене завдання й про те, як його вирішувати. Він повинен відповістити на запитання – «Навіщо робимо все це?» і переконатися, що всі члени групи знають і розуміють відповідь на нього.
|
|
|
Основна мета цієї ролі – задоволення вимог замовника. Для цього менеджер продукту виступає представником замовників у групі розробників і представником групи в замовника. (На цьому етапі важливо розуміти різниці між замовником і користувачами: замовник платить за створення продукту, а користувачі з ним працюють.) Крім того, менеджер продукту разом з менеджером програми повинні прийти до компромісного рішення щодо функціональних можливостей продукту, строків його розробки й фінансування.
Як представник замовника, менеджер продукту відповідає за виконання вимог замовника, створення бізнес-сценаріїв, формування загального подання про проект у групи й клієнта, а також перевіряє, чи задовольняють рішення групи потребам замовника.
Як представник групи, менеджер продукту відповідає за взаємодію із замовником і керування його очікуваннями. При цьому він проводить брифінги із клієнтом і головними менеджерами, улаштовує зустрічі з користувачами й демонстрації продукту.
Менеджер програми
Завдання менеджера програми – вести процес розробки з урахуванням всіх обмежень. Керівник цього напрямку повинен розуміти різницю між поняттями «керівник» і «начальник».
Головний обов'язок менеджера програми – виконати всі стадії розробки так, щоб потрібний продукт був випущений у потрібний час. Він координує діяльність інших членів групи. І хоча іноді йому доведеться підганяти своїх співробітників, він не повинен і думати про диктаторський стиль керування.
|
|
|
Головний менеджер програми складає графік проекту на основі інформації, отриманої від інших членів групи. Він координує цей графік з керівниками всіх підгруп. Буферним часом проекту також управляє менеджер програми. Якщо окремі частини роботи виконуються раніше графіка або, навпаки, затримуються, саме менеджер програми повинен з'ясувати, як це позначиться на проекті, і змінити графік.
Для виконання своїх обов'язків менеджер програми повинен відмінно розбиратися в діловій стороні проекту й мати ясне подання про технології, необхідних для його виконання. Природно, що від керівника відділу програмного менеджменту потрібна комунікабельність і талант організатора.
В зв’язку з тим, що менеджер програми відповідає за набір функціональних можливостей додатка, один з його обов'язків – визначити їхній набір, необхідний для виконання вимог замовника. Критичні для проекту вимоги виявляє менеджер продукту, але набір їхніх функцій, що реалізують, визначає менеджер програми. Крім того, менеджер програми дає замовникові рекомендації, що стосуються подальшого розвитку продукту. Відділ програмного менеджменту відповідає за функціональні можливості, викладені в специфікаціях (тут описано, що буде створене) і в головному плані проекту (визначає, як це буде зроблене). Він також координує роботу над цими документами. Проте кожний учасник проекту вносить свій внесок у функціональні специфікації й у план проекту.
Менеджер програми відповідає й за бюджет проекту, поєднуючи вимоги до ресурсів всіх членів групи в єдиний план витрат.
Розробник
Розробники знайомлять інших членів групи із застосовуваними технологіями й створюють продукт. Як консультанти вони надають вихідні дані для проектування, проводять оцінку технологій, а також розробляють прототипи й тестові системи, необхідні для перевірки рішень і скорочення ризиків на ранніх стадіях процесу розробки. Щоб створити продукт певної якості, розробникам не слід замикатися на створенні коду, вони повинні брати участь і в рішенні прикладного завдання. Вони творять не заради творчості, а для реалізації вимог замовника. Часто, щоб повністю розібратися в проекті, доводиться створювати прототипи, а щоб протестувати нову технологію, – іспитові системи, що допомагають прийняти остаточне рішення щодо архітектури додатка. Цим також займаються розробники.
Як програмісти розробники відповідають за низькорівневе проектування й оцінку витрат на реалізацію продукту. У більшості організацій кілька основних розробників займаються й архітектурою додатка. Як правило, це потрібно на ранніх стадіях проекту, коли уточнюються деталі функціональних специфікацій і описується взаємодія продукту із зовнішніми системами.
Розробники самі оцінюють строки своєї роботи. Така концепція MSF – створення графіків відповідальними за виконання конкретної ділянки членами групи – називається складанням розкладу «знизу – нагору». Дозволяє випустити потрібний продукт у потрібний час за рахунок уточнення графіків і підвищення відповідальності за виконання роботи в запланований термін.
Розробники відповідають і за технічну реалізацію проекту – в основному на фазах створення логічної й фізичної моделі. На цих стадіях їхнє завдання – визначити методи реалізації функціональних можливостей і заданої архітектури, а також оцінити строки виконання цієї роботи. Розробники не вибирають функції – вони тільки вирішують, як їх реалізувати.
Крім того, на стадії «Планування» розробники вирішують, яке вплив зробить на проект додавання або видалення деяких функцій. Розробники не беруть участь у заключній стадії проекту – розгортанні продукту, однак вони повинні тісно співробітничати з логістиками на стадії установки додатка.
|
|
|
Тестер
Завдання тестерів – випробування продукту в реальних умовах, щоб визначити, що в продукті працює й що не працює, і намалювати в такий спосіб точний «портрет» додатка. Природно, для проведення тестів потрібно відмінно розбиратися й у вимогах користувачів, і в тому, як їх задовольнити.
Тестери розробляють стратегію, плани, графіки й сценарії тестування, які дозволяють переконатися, що всі помилки виявлені й виправлені до випуску додатка. Помилкою називають будь-яку проблему, через яку продукт не виконує свої функції. Нею може виявитися й помилка в коді, називана «жучком», і відхилення від специфікацій, заданих менеджером програми, і недоробки в документації, підготовленою групою навчання користувачів.
Важливо розрізняти тестування й загальну оцінку якості (Total Quality Assurance, TQA). Тестування стосується тільки проекту – його технічної сторони. Перевірку якості організує керівник, відповідальний за якість, – він з'ясовує відповідність продукту корпоративним, урядовим і іншим стандартам.
Не можна суміщати посади тестера й розробника. Поділ цих обов'язків:
– гарантує незалежну перевірку того, що продукт дійсно виконує всі вимоги;
– підвищує якість продукту за рахунок конкуренції між групами.
Хоча перевіряють якість продукту тільки тестери, за випуск гарного продукту відповідають всі члени проектної групи.
За якість коду відповідають розробники. Відділення тестування від розробки не знімає з них цей обов'язок.
Контроль змін
При роботі над проектом необхідно контролювати зміни. Цим повинні займатися всі учасники групи, але найчастіше в повному обсязі цим доводиться займатися саме групі тестування.
Для керування змінами необхідно:
– створити еталонний документ;
– визначити змінювані елементи;
– визначити вплив змін на існуючі системи, процеси або документи;
|
|
|
– визначити метод реалізації змін;
– призначити людину, що внесе зміни;
– визначити вплив зміни на умови виконання проекту, його бюджет, графік і політику;
– одержати схвалення змін (скажемо, у керівника проекту);
– внести зміни;
– створити новий документ, у якому зміна врахована.
Інші обов'язки
Деякі важливі обов'язки тестерів часто випустять із уваги. До них відносяться:
– повідомлення про помилки і їхнє відстеження – тестова група відповідає не тільки за керування змінами, але й за систему виявлення помилок і інформування про їх;
– складання продукту – у групі повинен бути людина, відповідальний за складання (компіляцію) продукту, і часто такий «головний збирач» є тестером, він може використовувати тільки код, що зберігається в системі керування версіями; цю рутинну роботу вдається автоматизувати за допомогою сценаріїв, однак необхідно перевіряти правильність складання;
– виявлення й контроль ризиків – це обов'язок всіх членів групи, менеджер програми повинен розробити метод контролю; тестери відповідають за роботу програми в реальних умовах, тому їхнє завдання – представити групі аналіз ризиків із цього погляду.
Процес контролю ризиків повинен бути безперервним і постійним – тільки тоді гарантується якість продукту й дотримання строків випуску.
Інструктор
Ціль групи навчання – підвищити ефективність праці користувачів. Тому інструктори «приймають сторону» користувачів подібно тому, як менеджери продукту представляють інтереси замовника. Однак перед користувачами інструктори виступають у ролі представників проектної групи.
У цій останній якості група навчання відповідає за випуск зручного, корисного продукту, якому практично не потрібна підтримка. Персонал групи тестує зручність використання продукту, виявляє проблеми в цій області й перевіряє проект користувальницького інтерфейсу.
Активно беручи участь у створенні користувальницького інтерфейсу, інструктори скорочують витрати на супровід продукту й підтримку користувачів. Часто ж буває, що вивченню цих витрат практично не приділяється уваги, хоча всі розрахунки дуже прості: чим легше працювати з додатком, тим менше витрати на підтримку.
Досить часто додаток здається в експлуатацію без плану навчання, а проектні групи навіть не мають подання про те, як користувачі будуть вивчати додаток. Завдання інструкторів – не допустити цього, заздалегідь спроектувавши, склавши й протестувавши всі необхідні матеріали, включаючи короткі пам'ятки, керівництва користувачів, системи онлайнової допомоги, Web-Сторінки й навіть – якщо знадобиться – цілий навчальний курс. Коли матеріали підготовлені, група координує навчання користувачів.
Управляти очікуваннями користувачів так само важливо, як і очікуваннями замовника. Однак не слід думати, що користувачі будуть розбиратися у функціональних специфікаціях. Вони більш прихильно відносяться до прототипів системи, демонстрація яких значно підвищить шанси на успіх проекту. Крім того, користувачам корисно показати діючі модулі програми. Хоча маркетинг входить в обов’язки менеджерів продукту, також важливо вчасно інформувати й користувачів. Для цього варто періодично розсилати електронні повідомлення про нові функції програми і її бета-версій.
Логістик
Логістик представляє інтереси служб підтримки й супроводу, довідкових служб і інших служб каналу доставки. Він займається розгортанням продукту і його супроводом і контролює продукт із цього погляду в процесі проектування. Крім того, його завдання – складання графіків розгортання додатка. Логістики, менеджери продукту й менеджери програми спільно визначають порядок передачі продукту користувачам і організації, після чого логістики готовлять їх до розгортання додатка.
Логістик, що бере участь у великому проекті, повинен мати досвід розгортання великомасштабних додатків на декількох сотнях комп'ютерів. Саме тому від нього потрібна комунікабельність і гарна технічна підготовка. Логістик керує всіма співробітниками, що встановлюють і набудовують користувальницькі системи. Крім того, він повинен уміти координувати установку програмного забезпечення й оцінювати її результати.
Логістик зобов'язаний розбиратися в інфраструктурі продукту й вимогах до його супроводу. Його завдання – перевірити, щоб всі сервери розгортання й робітники станції користувачів задовольняли цим вимогам. Звичайно дані питання враховуються в планах випуску, розгортання й супроводи продукту.
Хоча основне завдання логістика полягає в плавному розгортанні продукту, обов'язок керівника цього напрямку – скласти план супроводу й експлуатації й переконатися, що існуючі групи здатні із цим упоратися. Важливо навчити не тільки користувачів, але й персонал довідкової служби. Причому останніх треба почати знайомити із продуктом ще на ранніх стадіях розробки – скажемо, на етапі бета-тестування. Перед здачею додатка в експлуатацію варто скласти документацію, визначити вимоги до резервного копіювання даних і розробити план відновлення на випадок відмови систем. Після розгортання логістики протягом деякого часу консультують групу супроводу. Звичайно, складно пророчити всі труднощі, які можуть виникнути в процесі експлуатації додатка, тому у всіх планах варто передбачати й порядок дій в екстреному випадку.
Крім перерахованих вище обов'язків, логістик займається супроводом проміжних версій продукту в процесі розробки. Його знання потрібні й при вивченні поводження додатка в тестовому середовищі, Крім того, допомога логістиків необхідна при створенні тестових, сертифікаційних і виробничих систем. Вони повинні також супроводжувати додаток у процесі моделювання експлуатації на етапі бета-тестування.
Багато організацій використовують системи моніторингу продуктивності й стабільності. Тому логістики обов'язково повинні проінформувати розробників про наявність таких засобів.
Розмір групи логістики визначається графіком розгортання, рівнем автоматизації установки, наявністю засобів автоматичного розгортання додатків і інших характеристик цього процесу.
