Проблема

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

Програмісти і тестувальники цієї організації дотримувались методу PSP/TSP, розробленого Інститутом програмної інженерії (SEI). Такі вимоги керівництва компанії Microsoft були зазначені в контракті. Джон де Ваан на той час був безпосереднім підлеглим Білла Гейтса і великим шанувальником Воттса Гамфрі з Інституту програмної інженерії. Як голова інженерної служби Microsoft він міг вимагати від IT-відділу і його постачальників дотримання певних процедур. Це означало, що зміна методу життєвого циклу розробки ПЗ виявилася неможливою.

Драгош зрозумів, що основна причина наявних проблем полягає не в методі PSP/TSP і не в рівні зрілості організації — постачальника послуг. Ба більше, команда робила майже все, що від неї вимагалося, із досить високою якістю. Однак час виконання запиту на зміни сягав п’яти місяців і разом з обсягом беклогу продовжував безконтрольно збільшуватися. Складалося враження, що команда погано організована і майже некерована. Як наслідок, вище керівництво не поспішало виділяти додаткові кошти на вирішення цієї проблеми. Отже, стримуючі фактори, що гальмували здійснення змін, були пов’язані з політикою, фінансами і внутрішніми правилами компанії. Тоді Драгош звернувся до мене по допомогу.