Ескалація і підзвітність

Модель проектної групи немає організаційної структури

При застосуванні моделі проектної групи MSF постійно виникає питання: "Хто відповідальний?" З організаційної структури завжди ясно, на кому лежить та або інша відповідальність, і хто кому підзвітний. В протилежність цьому, модель проектної групи MSF описує ключові ролі і завдання в команді, але не визначає управлінську структуру з погляду адміністративних повноважень персоналу. У багатьох випадках проектна група складається з людей, що належать різним організаціям, і вони можуть бути адміністративно підзвітні різним керівним особам.

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

Зовнішня координація – на кому лежить відповідальність?

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

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

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

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

43