Це одна з найбільших загадок інформаційних технологій.
“Гей, Філ, як просувається розробка цієї підсистеми?”
“Досить непогано. Я закінчив приблизно на 90 відсотків».
“Овва. Хіба ти не закінчив її на 90 відсотків ще пару тижнів тому?”
“Так, але тепер я дійсно закінчив роботу на 90 відсотків!”
Той факт, що у звітах проєкти з розробки програмного забезпечення та завдання завжди «виконані на 90 відсотків», вже став свого роду галузевим жартом. (Згідно з цим жартом, на першу половину проєкту з розробки ПЗ витрачаються перші 90 відсотків ресурсів, а на другу – інші 90 відсотків ресурсів.) Таке визначення прогресу робиться з добрими намірами, але вводить в оману, оскільки ускладнює судження, коли основна робота дійсно буде завершена, щоб ви могли відправити наступний випуск продукту своїм клієнтам. Ось кілька типових причин синдрому «90 відсотків зроблено» і кілька можливих методів лікування.
Причина #1: Неадекватне планування завдань
Можливо, ви справді фактично виконали 90 відсотків завдань, які спочатку вважали необхідними для виконання якогось обсягу роботи, але після цього виявили, що роботи набагато більше, ніж ви думали. Це часто трапляється при впровадженні змін в існуючій системі, оскільки ви постійно стикаєтеся з додатковими компонентами та файлами, які потрібно змінити, а потім перевірити. Основна проблема полягає в тому, що ми не думаємо про всі необхідні завдання при плануванні та оцінці якогось шматка роботи.
Щоб вирішити цю проблему, витратьте трохи більше часу на виявлення всієї роботи, яку вам доведеться виконати. Можна створити контрольні списки планування завдань, у яких детально описано кроки, пов’язані з виконанням типових дій, які повторюються у проєктах. Ці контрольні списки допоможуть вам краще оцінити, скільки часу займе робота, вони зменшать ймовірність пропустити необхідний крок і допоможуть точніше відстежувати свій прогрес. Так само, ретельно проведіть аналіз впливу (impact analysis), коли вас попросять внести зміни в існуючу систему. Деякі контрольні списки та робочі аркуші для аналізу впливу доступні в Requirements Engineering Set #4 за посиланням www.processimpact.com/goodies.html. Почніть з них і адаптуйте їх відповідно до вашої власної ситуації.
Причина #2: Забагато оцінки часткової готовності
Ми схильні занадто високо оцінювати відсоток часткової готовності завдань, які ми почали, але не повністю виконали. Одного ранку в душі ви можете придумати складний алгоритм для певного модуля і зробити висновок, що ви майже наполовину виконали завдання, тому що визначення алгоритму було важкою частиною. Дуже важко точно визначити відсоток виконання великого завдання, як тому, що, ймовірно, досі залишаються неідентифіковані дії (див. Причина #1), так і тому, що ми надмірно оптимістичні щодо того, наскільки гладко пройде робота, що залишилася.
Першим кроком до вирішення цієї проблеми є розбиття великих завдань (майлстоунів) на кілька маленьких завдань (окремі цеглинки; розумієте?). Маленькі завдання не повинні бути довше одного-двох днів тривалістю. Окремі елементи у вашому контрольному списку планування завдань із причини #1 можуть служити цими окремими цеглинками. Гнучкі методології ведення проєкту зазвичай складаються з наборів цих окремих цеглинок, таких як історії користувачів (user stories). Однак без ретельної оцінки деякі історії чи інші завдання можуть виявитися більш складними, ніж вони здавалися спочатку.
Далі відстежуйте свій прогрес на маленьких завданнях у бінарному вигляді: невелике завдання або повністю виконано, або не виконано. Ви не повинні розраховувати часткове виконання незавершені завдань. Не зроблено. І крапка. Прогрес у виконанні великого завдання визначається тим, який відсоток окремих цеглинок для цього великого завдання повністю виконаний, а не вгадуванням, яка частка великого, задіяного і нечітко визначеного обсягу робіт завершена. Якщо хтось запитає вас, як просувається робота над завданням, і ви відповідаєте: «Я все закінчив, крім…», то ви не закінчили, і ви не отримуєте ніякий відсоток готовності. Діаграми згоряння у гнучких методологіях – це спосіб відстежувати прогрес виконання окремих цеглинок, за умови, що команда не забуває вважати роботу завершеною, коли вона виконана повністю.
Якщо ви використовували засоби відстеження проєктів, наприклад Microsoft Project, можливо, вам знайомий елемент управління, за допомогою якого можна вказати, яку частину завдання виконано під час перегляду діаграми Ганта завдань проєкту. Я раджу бути обережним, використовуючи ці засоби контролю часткового завершення. Вони можуть оманливо створити уявлення, що ви далі, ніж є насправді. В якості альтернативи можна розбити завдання на невеликі кроки, які можна позначити як повністю виконані після їх завершення, а потім дозволити інструменту обчислити відсоток виконання загального завдання з цих підзавдань.
Причина #3: Ігнорування часу на переробку
Деякі дослідження показали, що у проєктах з розробки програмного забезпечення 30 до 50 відсотків усіх зусиль зазвичай витрачаються на переробку, роблячи знову те, що, на вашу думку, вже було зроблено. Однак плани і кошториси проєктів часто ігнорують реальність переробки, мабуть, очікуючи, що все піде правильно з першого разу (це не так). В результаті ви можете подумати, що майже закінчили із завданням лише для того, щоб виявити, що виправлення помилок, виявлених під час інтеграції та тестування системи, додає ще близько 20 відсотків у ваш графік.
Лікування тут просте: включіть переробку як явне завдання у свої плани після кожної перевірки якості зробленої роботи, такої як тестування або експертна оцінка. Ви не будете знати, скільки часу ви витрачаєте на переробку в середньому, допоки не почнете вести якісь записи. Наприклад, ви можете зʼясувати, що виявили вісім дефектів під час тестування одного модуля, що зайняло у вас п’ять годин на виправлення та повторне тестування (інша форма переробки). Тепер у вас є деякі дані, щоб оцінити, скільки зусиль ви можете очікувати витратити на переробку наступного типового завдання, будь то модуль коду, історія користувача або будь-яка інша одиниця «роботи», яку ви використовуєте.
Можливо, вам не доведеться витрачати стільки часу, скільки ви припускали, на переробку, особливо якщо ви зосередитеся на постійному вдосконаленні того, як ви виконуєте свою роботу. У такому випадку ви випереджаєте план! Це дозволено у всіх 50 американських штатах і багатьох інших країнах. Не маючи доступних даних про минулі переробки, ви завжди будете здогадуватися про своє майбутнє планування. Але якщо ви не враховуєте можливість переробки при оцінці завдань і оцінці поточного стану виконання завдання, ви майже завжди будете занадто оптимістичні. Як вказує наліпка на бампер, таке буває (в оригіналі – It happens!!!).
Якщо ви хочете вилікувати хронічний випадок синдрому «90 відсотків виконано» у вашій організації, спробуйте визначити основні причини, які зривають прогрес вашого проєкту, і скористайтеся цими простими методами для більш точного відстеження статусу вашого проєкту та його завдань.
Оригінальна стаття – Why Is Software Always Ninety Percent Done?, переклад Іван Вільчавський, ревью – Олександра Серебрянська (Business Analysis Community Kyiv). Оригінальна графіка від автора.