2. Ключові концепції

Успішне використання моделі проектної групи MSF ґрунтується на ряду ключових концепцій (key concepts), представлених в цьому розділі.

Команда соратників

Концепція "команди соратників" (teem of peers) означає рівноправне положення кожної з ролей в команді. Це сприяє вільному спілкуванню, збільшує командну відповідальність і зумовлює рівну важливість кожної з шести якісних цілей. Щоб досягти успіху в рамках команди соратників (команди рівних учасників), кожен з її членів, незалежно від ролі, повинен нести відповідальність за якість продукту, розуміти інтереси замовника і суть вирішуваної бізнес-задачі.

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

Фокусування на потребах замовника

Задоволення потреб замовника – головний пріоритет будь-якої добре працюючої проектної групи. Концентрація на потребах замовника (customer-focused mindset) означає обов'язкове розуміння його бізнес-задач і прагнення до їх вирішення з боку команди. Одним із способів визначення успіху такої уваги до замовника є здатність відстежити зв'язок

кожного елементу в дизайні системи з відповідним йому початковою вимогою замовника або користувача (trace each feature in the design back to а customer or user requirement). Іншим ключовим моментом в задоволенні потреб замовника є його активна участь в проектуванні рішення і отримання його відгуків в ході процесу розробки. Це дозволяє проектній групі і замовникові успішно погоджувати свої очікування і потреби.

Націленість на кінцевий результат

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

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

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

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

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

20

частиною виробничої культури, кожен член колективу починає відчувати відповідальність за результат проекту.

У своїй презентації 1991-го року колишній менеджер програми майкрософт Chris Peters так описував цю концепцію стосовно розробки програмного забезпечення:

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

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

Коли ви прокидаєтеся вранці і приходите на роботу, ви говорите: "Що є пріоритетом – ми створюємо продукт або пишемо програмний код?" Відповіддю є: ми створюємо продукт. Не намагайтеся створювати код – створюйте продукт".

Установка на відсутність дефектів

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

Установка на відсутність дефектів (zero-defect mindset) – це прагнення до високого рівня якості. Вона означає, що мета команди – виконання своєї роботи з максимально можливою якістю, причому таким чином, що якщо від команди зажадають поставити результат завтра, вона буде здатна поставити щось, що працює. Необхідне розуміння того, що продукт щодня повинен бути практично готовий до постачання. Це не означає постачання програмного коду, повністю вільного від дефектів. Але це означає, що продукт відповідає вимогам якості (quality bar), встановленим спонсором (sponsor) проекту 1і прийнятим проектною групою на етапі вироблення концепції.

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

Пізніше в автомобільній промисловості якість стала "завданням номер один". Це означає, що як тільки певна операція (наприклад, приєднання дверей або установка радіо) завершена, інспектор перевіряє поточний стан зразка і упевняється, що стандарти якості дотримані. Якщо в ході всього процесу збірки зберігається належний рівень якості, потрібний значно менше часу і ресурсів на остаточну перевірку придатності автомобіля. Крім того, це робить процес перевірки набагато більш передбаченим, оскільки інспекторові потрібно лише перевірити якість збірки продукту в цілому, а не стан окремих його частин.

Прагнення до самовдосконалення

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

1 В контексті управління проектами під термином "спонсори проекта" (project sponsors) зазвичай розуміють осіб (або організації), які ініціювали проект, виділяють для проекта ресурси і затверджують його результати. Іноді "project sponsor" перекладають как "куратор проекта".

21