За результатами дослідження PwC, в якому брало участь понад 10,5 тис. проектів, тільки 2,5% компаній вдалося успішно завершити 100% початих проектів. Інш і або не змогли досягти всіх поставлених цілей, або зіткнулися з нестачею часу і бюджету. Проблеми, що виникають під час розробки IT-проектів, призводять до істотних витрат. Так, американські компанії втрачають на цьому від 50 до 150 млрд доларів. Одна з причин збільшення витрат та необхідність доопрацювання проекту.
ДООПРАЦЮВАННЯ ЯК ФАКТОР ЗБІЛЬШЕННЯ ВИТРАТ НА ПРОЕКТ
Доопрацювання - це усунення дефектів, виявлених в системі після запуску. На це витрачається, як правило, 30-50% загальних зусиль, які можуть бути спрямовані як на виправлення технічних помилок, так і на роботу з «пропущеним и вимогами». В останньому випадку мова йде про невідповідність проекту початковим умовам. Так, будь-який проект розглядається в розрізі двох показників: скільки повинен коштувати і скільки буде коштувати з урахуванням внесення всіх змін.
Доопрацювання сприймається як частина процесу розвитку більшості проектів, проте навряд чи хтось сперечатиметься з тим, що вона вимагає значних витрат. Її вартість може на 50% перевищувати сукупні витрати! Виникає логічне запитання: чому так рідко вдається цього уникнути? Складність в тому, що необхідність в доопрацюванні стає очевидною не відразу, а т ільки після запуску програмного забезпечення. Ви не можете реально оцінити якість його функціонування аж до етапу тестування, при цьому деякі помилки виявляються вже після введення в експлуатацію програмного продукту. Все це робить доопрацювання мало не найдорожчим етапом роботи над проектом.
За експертними даними, розробники ПЗ переробляють, в середньому, близько 26% коду. Для середнього бізнесу це величезні витрати: в залежності від масштабу і складно сті проекту, за рік вони складають понад 4,7 млн дол. Якщо взяти за основу дослідження, проведене DORA в 2017 році, побачимо, що вартість доопр ацювання залежить переважно від рівня професіоналізму IT-виконавця.
Так, для великих компаній з власним програмним забезпеченням і 8500 технічних співробітників в штаті, вартість заощаджень на доопрацюваннях за рік становить 13,4 млн доларів. Для середніх суб'єктів бізнесу (від 2000 технічних спі вробітників) - це 3,2 млн доларів, для дрібних (250 співробітників) - 393,8 тис. доларів.
Однак потрібно враховувати, що домогтися гідних результатів можливо лише за умови, що проектом будуть займатися професіонали - IT-фахівці з високим рівнем навичок і значним досвідом роботи.
ЯКІ ПРИЧИНИ ДООПРАЦЮВАННЯ І ЧИ МОЖНА ЙОГО УНИКНУТИ?
Одна з ключових причин проблем з проектом - відсутність чітких вимог щодо розробленого ПЗ. Можливо, список вимог було надано не в повному обсязі або ж в процесі розробки відбулися зміни, які не задокументували.
А може справа в тому, що у розробника і замовника різні погляди на ведення проекту, що створює додаткові труднощі для всіх зацікавлених сторін. Іноді процес гальмують обмеження, які не залежать від розробника, наприклад, відсутні сть необхідної документації та стислі терміни, через що неможливо приділити достатньо часу виявлення і виправлення помилок до запуску ПЗ.
Існують методи, що дозволяють скоротити частоту доопрацювання. Чому ж компанії не використовують їх? Більшість вважає цей процес неминучим. Однак не все так складно, як здається на перший погляд.
Проаналізувавши численні дослідження, ми виділили найбільш ефективні способи запобігання доопрацювання:
1. СТАНДАРТИ І ПРОЦЕДУРИ
Створення загальних стандартів і процедур дозволяє уникнути повторних помилок. Стандарти можуть включати як продукти, наприклад, стиль програмування, так і процеси, тобто методи створення продуктів.
Суворе дотримання встановлених стандартів і правил спрощує розуміння документації (планів тестування, посібників з програмування і т.д) і вибір оптимальних методів для виявлення та виправлення помилок, а також скорочує час на вик онання разових процесів. Все це веде до підвищення якості ПЗ, знижує ймовірність серйозних помилок і виключає необхідність доопрацювань.
2. АУДИТ
Є й інший варіант - проведення експертних перевірок продуктів і процесів на предмет їх схильності збоїв. Аудитори вивчають всю систему або ж її частину з метою виявлення дефектів і невідповідностей.
Ось приклади такого аудиту:
- оцінка поточного стану програмного забезпечення в порівнянні з еталонними тестами;
- технічний огляд, тобто перевірка коректності роботи системи і підтвердження якості;
- аналіз проекту після всієї виконаної роботи для визначення причин збою і пошуку способів виправлення помилок.
Професійний аудит допомагає знаходити будь-які дефекти: в коді, специфікаціях, дизайні або документації. Аудит дозволяє не чекати, поки ПЗ буде введено в експлуатацію, а вживати заходів щодо усунення помилок відразу ж після їх ви явлення.
3. УПРАВЛІННЯ КОНФІГУРАЦІЄЮ (SCM)
Мета SCM - управління конфігурацією ПЗ - забезпечення узгодженості характеристик продукту відповідно до вимог і технічної документації впродовж усього життєвого циклу. Без SCM не обійтися, коли необхідно впевнитися, що система пр ацює так, як задумано і всі заплановані зміни внесені в продукт і задокументовані.
За допомогою інструментів SCM можна керувати кількома версіями продукту і контролювати внесення будь-яких змін в систему. Це перевірений спосіб підвищення якості продукту і скорочення часу на доопрацювання.
Незважаючи на безліч способів підвищення якості ПЗ, повністю виключити доопрацювання навряд чи вдасться, адже не всі проблеми піддаються виявленню відразу після виникнення. Однак такі процедури, як аудит і огляд, управління систе мними змінами, дотримання стандартів допомагають уникнути серйозних проблем і зводять до мінімуму витрати часу на доопрацювання.
Це стосується будь-яких IT-проектів, в тому числі, пов'язаних зі створенням мобільних додатків. В такому випадку терміни залежать не тільки від складності додатка, а й від кількості пристроїв і типів платформ, на які він буде вст ановлюватися. Потрібно враховувати, що проект для ОС Android вимагає більше часу, ніж для iOS, так як тестування виконується на різних пристроях. Нехтування своєчасним аудитом і тестуванням додатка може спричинити серйозні збої: зав исання, проблеми із перемиканням режимів і дозволом екрану, помилки в каналах зв'язку, вразливості безпеки і т.д.
Як показує практика, простіше і дешевше попередити помилки в проекті, ніж їх виправити. Варто прислухатися до експертів ISITLab і найняти професійних IT-виконавців, які мінімізують вартість доопрацювання, зберігши вам сотні тисяч бюджету.
