Фактори, що впливають на продуктивність

Коли надходив запит, Драгош повинен був надіслати його для оцінювання до Індії. Згідно з регламентом, оцінювання слід було здійснити і надати його результати власникам бізнесу протягом 48 годин. Так було легше вирахувати ROI (рентабельність інвестиції) і ухвалити рішення щодо запиту. Раз на місяць Драгош мав зустрічатися з менеджерами продукту та іншими зацікавленими особами, щоб оновити пріоритети в беклозі та скласти план проєкту з виконання запитів.

На той час щомісячно обробляли близько семи запитів. Беклог містив понад 80 елементів, і його обсяг продовжував збільшуватися. Отже, щомісяця потрібно було переглянути пріоритети та перепланувати більше ніж 70 запитів, а обробка запиту тривала в середньому чотири місяці. У цьому і полягала головна причина незадовільної роботи. Ці запити були невеликими, але постійна зміна пріоритетів призводила до постійної незадоволеності клієнтів.

Запити фіксувалися за допомогою інструменту, що мав назву Product Studio. Оновлену версію цієї програми було згодом випущено під назвою Team Foundation Server Work Item Tracking. Команда тех­підтримки XIT являла собою добре знайомий мені тип організації: вони накопичували безліч даних, але не використовували їх. Драгош почав аналізувати ці дані й виявив, що середній запит потребував 11 днів роботи інженера (як свідчили історичні дані і як описано в розділі «Встановлення вхідної каденції»). Час виконання при цьому становив від 125 до 155 днів, понад 90 % часу марнувалося, у тому числі за рахунок очікування в черзі.

Оцінювання нових робіт вимагало чимало ресурсів. Ми вирішили проаналізувати процес оцінювання, зробивши низку припущень. Хоча абревіатура ROM розшифровується як «приблизний порядок величини», клієнти очікували, що оцінювання буде максимально точним, і члени команди проводили його з особливою ретельністю. У кожного розробника і тестувальника одне оцінювання забирало приблизно робочий день. Ми підрахували, що на саме лише оцінювання витрачалося близько 33 % ресурсів команди, а в погані місяці навіть 40 %. До того ж оцінювання нових запитів нерідко вносило плутанину до планів, складених на поточний місяць.

Окрім запитів на зміни, у команди був інший вид робіт — так звані текстові зміни в працюючій системі (Production text changes, PTC), що стосувались змін інтерфейсу або текстів, чи потребували редагування даних у таблицях або XML-файлах. Ці зміни не вимагали участі розробників і часто вносилися власниками бізнесу, менеджерами продукту або програми. Але оскільки вони вимагали формального проходження тестів, участь тестувальників була все одно необхідною.

РТС приходили неочікувано та отримували найвищий пріоритет порівняно з оцінюванням або будь-якою іншою роботою. Крім того, вони надходили нерівномірними порціями і теж порушували поточні плани на місяць (рис. 4.3).

Рис. 4.3. Робочий процес із відображенням оцінок ROM і внесення PTC