Основні принципи розподілення ролей учасників програмного проекту

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

Найбільш важливі моменти.

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

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

Згідно з MSF виділяють наступні ролі учасників проектів.

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

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

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

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

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

Дуже важливо розрізняти тестування і контроль якості. Тестування зосереджене на проекті й оперує деталями і технікою роботи.

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

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

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

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

Таблиця 10.1

Можливість об’єднання ролей у проектній групі відповідно до MSF