Оцінка повернення інвестицій від впровадження процесу управління конфігураціями

Олександр Новачків, Дмитро Лапигін

Вступ

Будь-який довгостроковий проект, пов'язаний з розробкою програмного забезпечення, розростається через зміну вимог замовників і кінцевих користувачів створюваного продукту. У результаті такий проект стає важко керованим. Керівництво компанії розробника виявляється не в змозі контролювати діяльність підлеглих і не має чіткого уявлення про якість випускається вироби. Підлеглі ж, у свою чергу, не мають повної інформації про поточні проектних завданнях, їх актуальності, взаємозалежність і пріоритетах.

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

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

Один з процесів, що дозволяють суттєво підвищити якість як самого процесу розробки ПЗ, так і вихідного продукту, - управління конфігурацією (КК) програмних засобів. Складовою частиною цього процесу є інший процес -- управління змінами (УІ), у тому числі відстеження виявлених помилок і інших запитів замовників на зміни в продукті.

Детальний опис КК і УІ представлено в документах, що описують методологію IBM Rational Unified Process (RUP), яка зараз є найбільш певною методологією колективної розробки, що має повноцінну інструментальну підтримку. Нижче коротко викладено основні характеристики цих процесів.

Цілі:

контроль внесених змін;

поліпшення якості продукту або послуги;

підвищення ступеня задоволеності користувачів, або замовників;

організація взаємодії різних робочих груп. Дії:

створення або оновлення робочого простору за заданим профілем;

внесення змін у файли проекту;

інтеграція змін із змінами, внесеними іншими учасниками;

фіксування базової лінії поточних версій файлів проекту;

реєстрація запитів;

призначення виконавців і термінів;

контроль виконання (періодичний контроль).

Важливі складові процесів:

автоматизована процедура збирання версії програмного засобу;

автоматизоване повідомлення учасників проекту про зміну файлів, важливих з точки зору проекту, а також про інші ключові події;

можливість кількісної і якісно ної оцінки виконану розробниками роботи;

спільний доступ до інформації про запити на зміни.

Ефект від впровадження на рівні керівництва

Розглянемо основні переваги впровадження цих дисциплін з точки зору керівництва:

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

Чітке уявлення про те, хто і чим займається в проекті, скільки помилок виправлено, скільки помилок знайдено і т.д.

Повний документування всіх ключових змін.

Планування діяльності кожного розробника, який точно знає, що йому потрібно зробити сьогодні, завтра і післязавтра.

Графічне подання метрик проекту, що формуються при визначенні процесу (типи, кількість і т.д.).

Формування статистичних звітів по проекту (часто званих зрізами). Сформовані метрики проекту ранжуются в залежності від рівня керівництва: керівник департаменту, начальник відділу, менеджер проекту і т.д.

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

Приклади зрізів

Рис. Приклади зрізів

Тут приведені тільки типові види зрізів. У реальних проектах типи і кількість зрізів можуть істотно відрізнятися залежно від розмірів компанії, числа розробників, кількості проектів і т.д.

Економічний ефект від впровадження

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

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

Прямі витрат включають витрати на закупівлю засобів автоматизації процесу КК, навчання, технічна підтримка (на чому особливо люблять економити російські компанії) та інші витрати, пов'язані з пере будівництвом процесу розробки та супроводження ПС.

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

Давайте порахуємо

Розглянемо типовий сценарій оцінки термінів повернення інвестицій для проекту розробки ПЗ. Для реалізації цього сценарію не обходимо наступні дані:

Кількісне розподіл учасників проекту розробки ПО з їхніх функцій. Наприклад, розробників нової версії - 50, сопровожденцев - 50, технічних письменників -- 10, тестувальників - 20, менеджерів - 12, системних адміністраторів - 2, інженерів технічної підтримки - 10.

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

Кількісне розподіл фахівців, які беруть участь у впровадженні процесу управління конфігурацією. Напри заходів, розробників - 5, технічних письменників - 2, тестувальників - 2, менеджерів - 1, системних адміністраторів - 1, інженерів технічної підтримки - 1.

Вартість години робочого часу кожного фахівця.

Робоче час кожного фахівця, зайнятого в проекті впровадження (на основі плану проекту).

Оцінка зекономленого часу для кожної операції з п. 2 за тиждень. Такі дані можуть бути визначені під час пілотного проекту або взяті з інших аналогічних проектів.

Вартість навчання фахівців, які беруть участь у проекті розробки ПЗ.

Вартість зовнішніх консультантів, які беруть участь у проекті впровадження процесу КК.

Вартість ліцензій засобів автоматизації процесу КК.

Вартість річної технічної підтримки засобів автоматизації процесу КК.

Тепер можна приступати до підрахунків часу окупності, які зазвичай проводяться з річним інтервалом.

За перший рік підраховуються:

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

Витрати:

вартість робочого часу спеціалістів, які беруть участь у проекті впровадження. Тут також можна врахувати упущену вигоду від їх використання в інших проектах;

вартість навчання фахівців;

вартість зовнішніх консультантів;

вартість ліцензій;

вартість річної технічної підтримки.

За другий і наступні роки підраховуються:

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

Витрати:

вартість навчання нових фахівців проекту розробки ПЗ (звичайно не більше 10% від загального числа фахівців);

вартість ліцензій (при розширенні числа учасників проекту, зазвичай до 10% від початкового кількості ліцензій);

вартість річної технічної підтримки.

З наведеної схеми розрахунків видно, що максимальні витрати припадають на пер вий рік, а доходи мають тенденцію до зростання за рахунок двох факторів:

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

з часом підвищується майстерність виконання процедур управління кон фігурації і збільшується економія часу.

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

Як видно з представленої схеми розрахунку окупності, впровадження процесу КК в від ладу взятому короткостроковому проекті, термін реалізації якого не перевищує року, звичайно нерентабельно. Але чи варто відмовлятися від використання управління конфігурацією в короткострокових проектах? Не обов'язково. Є два шляхи виправлення цієї ситуації. Перший, за яким йдуть зараз багато вітчизняні компанії-розробники, - якомога більше скоротити витрати першого року. При цьому зазвичай:

повністю припиняються витрати на зовнішніх консультантів;

кількість тих, яких навчають фахівців урізується до 12 осіб, які потім у ролі «гуру» повинні будуть поширювати набуті знання серед інших учасників проекту;

використовуються найбільш дешеві засоби автоматизації процесу КК, або, м'яко кажучи, «Умовно-безкоштовні» версії;

послуги, пов'язані з технічною підтримкою, не купуються. Такий варіант рішення проблеми може

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

Оптимізація витрат на впровадження процесу управління конфігурацією

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

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

скорочення витрат на типові операції, постійно виконуються учасниками проекту;

витрати на технічну підтримку.

Наявність великого числа учасників впливає в основному на наступні вели чини:

скорочення витрат на типові операції, постійно виконуються учасниками проекту;

витрати на навчання;

витрати на ліцензії.

Таким чином, для великих проектів найбільшу віддачу обіцяє збільшення доходів від типових операцій, постійно виконуються учасниками проекту. Це може бути досягнуто тільки за рахунок постійного вдосконалення процесу управління конфігурацією. Тому у великих проектах має сенс виділити додаткові ресурси на постійно діючу групу фахівців, зайнятих вдосконаленням процесу КК. Наявність такої групи (назвемо її групою вдосконалення процесу) дозволить також оптимізувати і всі витратні статті, важливі для великого проекту, а саме:

витрати на навчання - наявність постійно діючої групи вдосконалення процесу (ГСП) дозволить використовувати її фахівців в якості тренерів для навчання нових учасників проекту, що дозволить знизити витрати на навчання починаючи з другого року. Початкове навчання все ж таки слід проводити силами зовнішніх фахівців;

витрати на ліцензії - одним із завдань вдосконалення процесу КК є оптимізація використання ліцензій, яка може здійснюватися ДСП на основі постійного моніторингу застосування ліцензій у проекті. Зазвичай початкове кількість закуповуваних ліцензій приблизно розраховується виходячи з загальних даних. Реальна потреба в ліцензіях може відрізнятися від первісної оцінки на 15-20% в ту чи іншу сторону,

витрати на технічну підтримку - зазвичай виробники програмного забезпечення застосовують політику забезпечення не скількох рівнів технічної підтримки різної вартості, що залежить від набору ус луг. Наявність ГСП у організації дозволить знизити рівень технічної підтримки за рахунок використання досвіду фахівців ДСП для вирішення частині технічних проблем.

Решта статті витрат не настільки критичні для великого проекту. Можливості їх зниження будуть розглянуті при описі інших типів проектів.

Обговоримо тепер протилежний тип проектів - малі проекти. Головною проблемою малих проектів є їх коротко терміновість, яка не дозволяє говорити про реальне повернення інвестицій для одного малого проекту. Як уже зазначалося, цього випадку виникає спокуса максимально зрізати всі витрати, в першу чергу разові. Подивимося, до чого це може привести:

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

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

Вартість ліцензій - на цьому теж економлять у всіх малих проектах. Результат - доступний тільки базовий набір функцій управління конфігурацією (у випадку з простими і дешевими продуктами типу CVS і Microsoft SourceSafe). Або ж (при використанні неліцензійного продукту більш високого класу) збільшується вартість адміністрування, але в основному знову ж таки застосовуються базові функції - на самостійне освоєння інших немає часу (адже треба і основною роботою займатися). У такій ситуації краще використовувати більш простий легальний продукт.

Вартість річної технічної підтримки - про неї можна говорити тільки для легальних продуктів. На цьому економлять майже завжди, хоча великої вигоди не виходить, тому що вартість технічної підтримки залежить від кількості використовуваних ліцензій, а в малих проектах воно невелике.

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

Строго кажучи, впровадження дисципліни управління конфігурацією на рівні одного проекту - Невиправдано дороге задоволення. Розумний підхід полягає в поетапному впровадженні КК в організації.

Загальні вигоди від впровадження КК

До загальним вигод від впровадження процесу управління конфігураціями можна віднести:

приріст проізводітельності (щодо вихідного рівня) з другого проекту - 30% (в Залежно від типів проектів, кількості розробників і числа замовників ефект може бути істотно вище);

планомірне розвиток без різких спадів;

забезпечення взаємодії між учасниками проекту;

прозоре управління проектом;

зниження ризиків, пов'язаних з невиконанням проекту в заданий термін із запланованими ресурсами;

чітке розуміння поточної завантаження розробників;

використання статистичної інформації з раніше виконаними проектами;

незалежність компанії від окремих осіб;

відповідність процесів розробки і з проводження стандартам якості (CMM, ISO 12207).

Висновок

Досягнення всіх вищезазначених цілей віз можна з використанням будь-якої сучасної методології, заснованої на міжнародних стандартах. Це ж стосується і інструментів: IBM Rational є лідером у цій дисципліні, але існують схожі інструментальні середовищ ства інших компаній: Telelogic Synergy, Borland StarTeam, PVCS, CVS, MS Source Safe.

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

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://www.cmcons.com/