Анотація
Введення до проектного менеджменту. Особливості програмного
забезпечення як предметної сфери управління ІТ-проектами.. «Залізний трикутник»
у менеджменті програмних проектів. Еволюція підходів до управління проектами
інформатизації. Основні специфічні особливості проектів з розробки програмного
забезпечення.
Проектна діяльність пронизує сьогодні всі
сфери функціонування традиційного підприємства: у маркетингу — це проекти
маркетингових досліджень, рекламних акцій, виведення на ринок нових продуктів,
завоювання нових ринків збуту; у дослідно-конструкторських підрозділах — це
проекти розробки нових продуктів, технологій; у виробництві — проекти освоєння
випуску нової продукції, технічного переозброєння, впровадження нових
технологій; у збуті — проекти побудови торговельно-збутової мережі…
Водночас усі ми постійно здійснюємо проекти у
повсякденному житті: підготовка до пікніка, ремонт несправного крана,
прибирання домівки до приходу гостей або курсова робота в університеті. Проекти оточують нас, ми працюємо з
ними майже щодня, але рідко намагаємося свідомо
опанувати їх, іншими словами, управляти ними.
Управління
проектами як специфічна галузь прикладної науки є досягненням останніх
десятиліть. Великою мірою вона виявилася побічним продуктом масштабних проектів
часів Другої світової війни, чи не найвідомішим з яких є «Манхеттен».
Керівники його зробили спробу свідомо, відповідально й
ефективно скоординувати величезний бюджет, графік і складні ресурси; вони мали
за мету перенести управління проектами зі сфери випадкового до, принаймні,
старанно обміркованого.
Останнім часом управління проектами
перетворилося на невід’ємну рису західного менеджменту. Тимчасом як світова
економіка вступала у постіндустріальну фазу, американські менеджери
усвідомлювали те, що основи управління, розроблені для традиційного
підприємства, в умовах нової, так званої інформаційної, економіки «не
працюють». У виробничій сфері наголос, як правило, робиться на передбачуваності
й повторюваності дій, а керівники здебільшого опікуються стандартизацією і
раціоналізацією виробничих процесів. Із посиленням конкуренції і розвитком
інформаційної економіки наперед виходить унікальність, а не повторюваність
подій, що відбуваються. Невід’ємною ознакою інформації є динаміка і постійні
зміни. Гнучкість стала девізом сьогодення, а управління проектами, або ж
проектний менеджмент, — ключем до досягнення цієї гнучкості.
Менеджмент
– це одночасно наука і мистецтво управління, насамперед, – людськими
ресурсами.
Слово проект
дуже часто вживається у нашому житті це і проведення виборчої кампанії, взяття
в оренду та ремонт нового офісу, впровадження нової інформаційної системи або підготовка до свята.
Коли мова
йде про ІТ-проекти, то на сучасному етапі розвитку науки і техніки це проекти,
які пов’язані з програмним забезпеченням і передбачають розробку, впровадження
чи супровід програмного забезпечення.
Визначення:
Програмне
забезпечення (ПЗ) – це кінцевий продукт програмного проекту. ПЗ містить
програму, пакет програм чи окремі складові програм (бібліотеки) та інші
складові, зокрема, документацію, що регламентує спосіб його використання.
Комп’ютерна
програма – символічний код, що керує функціонуванням апаратних засобів.
Проект –
послідовність дій, яка була запланована для вирішення поставленої задачі.
ПЗ
властиві багато особливостей, які більш детально будуть розглядатися далі. Одна
з них полягає у тому, що проект з розробки ПЗ – це далеко не лише створення
комп’ютерної програми, це значно більше – необхідно не лише створити програму,
потрібно також забезпечити вирішення нею задач, які перед нею поставлені, а
задачі можуть змінюватися і уточнюватися, крім того,
змінюватися може і зовнішнє середовище, у якому програма функціонує.
Відповідно
до PMI, проект розглядається як тимчасове зусилля, здійснене для того,
щоб створити унікальний продукт чи послугу з певною датою початку та закінчення
дії, що вимагає прогресивного поліпшення характеристик.
Таким
чином, програмний проект – проект зі створення ПЗ та підтримки його протягом
життєвого циклу. Однак, дуже часто підтримка ПЗ виходить за рамки початкового
проекту із його створення, оскільки є тривалою дією, і розглядається як окремі
проекти.
Проекти мають низку спільних ознак:
· спрямованість на досягнення конкретної мети;
· базування на координованому виконанні пов’язаних між собою дій;
· обмеженість у часі виконання, визначеність певної дати початку і
закінчення;
· наявність певного бюджету (фінансового,
матеріального тощо);
· певною мірою неповторність, унікальність.
Загалом, саме ці п’ять ознак, або
характеристик, відрізняють проекти від інших заходів, планів, програм,
ініціатив. Кожна з перелічених характеристик має важливий внутрішній зміст:
Спрямованість на досягнення мети. Проекти спрямовуються на досягнення певних результатів — іншими
словами, на досягнення мети. Саме ця мета є рушійною силою проекту, і всі
зусилля, що докладаються до його планування та реалізації, спрямовані на її
досягнення.
Проекти мають численні ієрархічні цілі.
Основною метою, наприклад, проекту, пов’язаного з програмним забезпеченням для
комп’ютера, може бути розробка складної системи управління базами даних.
Проміжною метою може бути тестування системи в процесі розробки для
налаштування програм, а метою нижчого рівня — визначення дат, коли працівники,
що розробляють проект, звітуватимуть про свої результати на оперативній нараді.
Зорієнтованість
проектів на досягнення мети надає величезний внутрішній потенціал для
управління ними. Передусім це передбачає необхідність точного визначення й формулювання цілей, від вищого рівня — до нижчого, до найпростіших речей.
Водночас проект можна розглядати як процес
досягнення ретельно обраних цілей, просування проекту на шляху його
реалізації пов’язане з покроковим досягненням цілей дедалі вищого рівня, поки,
нарешті, не буде досягнута кінцева мета. Якщо цілей декілька, то вони мають
бути пов’язані між собою і не конфліктувати одна з одною.
Протягом останніх десятиліть розроблена
методологія сприяння формулюванню та досягненню мети. Цю методологію називають
управлінням за цілями (mаnаgеmеnt ву
овjесtivеs — MВО), розроблялася вона незалежно від
загального розвитку теорії та практики управління проектами. Упевнене
оволодіння основними принципами МВО може значно полегшити життя проектного
менеджера — керівника проекту.
Координоване виконання пов’язаних між собою дій. Сама сутність проектів визначає складність їхнього втілення в
життя. Проекти потребують виконання численних завдань, жорстко або гнучко взаємопов’язаних: деякі проміжні завдання не можуть
реалізовуватися, доки не завершені інші завдання; інші завдання мають
виконуватися паралельно і т. п. Якщо порушується синхронізація виконання різних
завдань, весь проект може опинитися під загрозою невиконання. Якщо поміркувати
над цією характеристикою проекту, стає зрозумілим, що він є системою, тобто
цілим, яке складається з пов’язаних між собою частин. Протягом останніх
десятиліть фахівцями з управління проектами розроблено спеціальні методики
роботи з системами. Зведені разом, ці методики становлять системний аналіз. Керівник проекту, який опанував основні методи
системного аналізу, може ефективно використовувати ці знання для реалізації
проектів.
Часові рамки проекту. Проекти
виконуються протягом певного проміжку часу (хоча інколи керівникам проектів, що
обстоюють виконання початкових графіків, здається, що проект не буде завершено
ніколи) і мають більш-менш чітко окреслені початок і закінчення. Момент початку
та завершення дії – для початку виділяється час початку і час його завершення,
як правило, у вигляді конкретних дат. Проект вважається завершеним, коли
досягнуті його основні цілі. Під час виконання проекту значні зусилля спрямовані
саме на те, щоб його було завершено у намічений термін. У цьому допомагають
графіки, де зазначається час початку і закінчення робіт, які передбачаються
проектом. Слід звернути увагу на те, як це
відрізняється від циклів виробництва продукції. Випуск товарів не є
обмеженим у часі і залежить лише від наявності та рівня попиту. Коли попит
зникає, закінчується й виробничий цикл, тому традиційні процеси виготовлення
продукції не можуть бути віднесені до проектів.
Наявність бюджету. Проектна
діяльність, спрямована на отримання певного результату у заданий проміжок часу,
не може відбутися без використання певних ресурсів (матеріальних, людських,
фінансових). Тому невід’ємною рисою проекту є наявність бюджету, який
виділяється на забезпечення ресурсних потреб фінансування проекту, що
відповідають його масштабам, змісту і термінам виконання. Управління проектом,
фактично являє собою процес використання ресурсів з метою досягнення цілей
проекту з урахуванням його обмежень.
Унікальність. Проекти — це
певною мірою неповторні та одноразові заходи. Водночас рівень унікальності може
значно коливатися залежно від особливостей проекту. Скажімо, якщо йдеться про
зведення п’ятдесятого будинку у стилі «стандарт» за програмою житлової
забудови, то рівень унікальності цього проекту досить скромний. Базові елементи
такого будинку ідентичні елементам тих сорока дев’яти будинків, що їх було
зведено раніше. Проте основні елементи унікальності можуть відбиватися у
специфіці земельної ділянки, де розташовується будинок, у рішенні налагодити
нову систему опалення і вентиляції або у необхідності працювати з новою
бригадою фахівців і т. ін.
З іншого боку, якщо спеціалісти розробляють операційну систему
комп’ютера нового покоління, вони, певна річ, мають справу з досить унікальним
завданням, бо працюють над тим, що ніколи раніше не робилося. Оскільки досвід
минулих розробок може лише в загальних рисах підказати їм, чого треба очікувати
від цього проекту, то у цьому разі йдеться про ризик і невизначеність.
Проект –
одночасна сутність, що не завжди повторює один і той же шлях. Хоча можуть
існувати типові і схожі рішення, кожен проект у тій чи іншій мірі є унікальним.
Для інтелектуальної діяльності (до якої відноситься виконання програмних
проектів) це означає, що її результат не є визначеним на 100% до її завершення.
Узагальнюючи, можна
зробити висновок, що проект — це діяльність, за якої матеріальні, фінансові та
людські ресурси організовано новаторським шляхом для виконання унікальної
роботи при обмеженні у часі та витратах, щоб досягти позитивних змін,
визначених кількісними та якісними параметрами. Зв’язок
між головною метою і основними цілями проекту показано на рисунку 1.1.
Рисунок 1.1 – Зв’язок між
метою і цілями проекту
Найпоширенішими сферами діяльності, пов’язаними з проектами
(проектно-орієнтованими), є будівництво, автомобілебудування, фармацевтика,
архітектура, медичне обслуговування, розробка комп’ютерних програм та багато
інших. Окрім проектів у традиційному розумінні можна вести мову про здійснення
соціальних (пенсійна реформа), політичних (вибори до парламенту) або ж
побутових (сімейне свято) проектів.
Застарілий
підхід, зокрема той, що зустрічається в радянській літературі, визначає
програмне забезпечення як набір алгоритмів, викладених алгоритмічною мовою
програмування чи у машинних кодах, і призначений для розв’язання певних задач з
застосуванням ЕОМ. Зокрема, замість терміну «програмне забезпечення» дуже часто
використовувався термін «математичне забезпечення».
Подібне
досить вузьке визначення ПЗ є наслідком основної сфери застосування ПЗ у СРСР,
якою була, насамперед, сфера наукових розрахунків, відповідно, цікавість для
замовника розрахунків становив їх кінцевий результат, а не засіб у вигляді ПЗ,
за допомогою якого він досягався. Відповідно ПЗ не розглядалося як самостійний
ринковий продукт, підхід до створення якого має бути таким же, як до будь-якого
товару чи послуги на ринку. Слід зазначити, що і в СРСР були окремі наукові
дослідження з метою уточнення визначення ПЗ, наприклад, дослідженнями у цьому
напрямку займався А. Бабій [4], проте, подібні публікації не стали основою
більш серйозних наукових досліджень і практичних розробок.
Сучасний
підхід розглядає ПЗ, насамперед, як товар, у якому зацікавлений кінцевий
споживач.
Сучасні
підходи до визначення діяльності з розробки ПЗ розглядають її як таку, що
містить три складові: процеси, продукти та ресурси [3]. Власне ПЗ слід
розглядати невідривно від вказаних складових, оскільки взаємодія покупця і
продавця не обмежується лише здійсненням операції купівлі-продажу, звичайно
вона починається з детального аналізу вимог клієнта (чи ринку, коли мається на увазі
масове ПЗ), включає взаємодію на етапі розробки і впровадження та продовжується
на етапі супроводження продукту.
Даючи
визначення сутності ПЗ, Ф. Брукс зазначає,
що «сутністю програмного об’єкту є конструкція, що складається із поєднаних
разом концепцій: наборів даних, взаємозв’язків між елементами даних, алгоритмів
та викликів функцій».
Характеризуючи
природу процесу розробки ПЗ, Ф. Брукс виділив
дві групи труднощів, з якими зустрічаються розробники: труднощі, що витікають
із сутності ПЗ, тобто такі, які внутрішньо властиві природі ПЗ, та труднощі,
які супроводять розробку ПЗ на певному етапі розвитку науки і техніки, однак не
є такими, що властиві його природі. Труднощами, що витікають із сутності ПЗ
були названі такі як складність, узгодженість, здатність до змін, незримість.
Складність ПЗ є характерною
особливістю даного продукту цивілізації і проявляється у значно більш високій
мірі, ніж у будь-якій іншій галузі людської діяльності. Ф. Брукс підкреслює, що складність є сутністю програмних
об’єктів і нелінійно прискорюючими
темпами зростає разом зі зростанням їх обсягів. На відміну від продуктів інших
галузей людської діяльності, програмні об’єкти не складаються із повторювальних
елементів, оскільки такі елементи в процесі розробки мають вилучатися і
оформлюватися у вигляді допоміжних модулів. Складність ПЗ визначається великою
кількістю можливих його станів, великим обсягом інформації, який містять
вихідні коди ПЗ, що в результаті призводить не лише до технічних, а й до
адміністративних проблем.
Г. Буч
виділяє чотири головні причини, що викликають складність ПЗ:
–
складність предметної області розробки ПЗ;
–
складність управління процесом розробки ПЗ;
–
необхідність забезпечення достатньої гнучкості ПЗ;
–
незадовільні способи опису великих дискретних систем [9].
Узгодженість передбачає відсутність
інформаційної асиметрії між усіма учасниками процесу розробки ПЗ.
Неефективність комунікацій, різне сприйняття системи та припускання
неперевірених допущень її розробниками призводять до того, що окремі складові
єдиного програмного комплексу, а також взаємозв’язок ПЗ із зовнішніми вимогами
стає неузгодженим, що вимагає суттєвих витрат ресурсів на усунення даної
проблеми.
Здатність до змін. Характеризуючи
здатність ПЗ до змін у порівнянні з іншими результатами людської праці,
Ф. Брукс зазначає: «…програмне забезпечення
легше змінювати: це чиста думка, нескінченно податлива». Видима в теорії
легкість змін ПЗ на практиці виливається у істотні витрати ресурсів, зростання
складності та порушення концептуальної цілісності продукту. Об’єктивними
факторами, що вимагають змін у ПЗ є необхідність усунення помилок, розширення
функціональності та забезпечення сумісності із змінами середовища експлуатації.
Незримість. На відміну від карт, схем, рисунків та інших засобів
візуального абстрагування, які можуть бути використані для представлення
більшості об’єктів матеріального і нематеріального світу, програмні об’єкти
дуже слабко піддаються наглядній візуалізації. Прийняті на практиці нотації
блок-схем, моделей даних [15], мови графічного моделювання, такі як, наприклад,
UML [43, 10], не здатні достатньо ефективно вирішити проблему наглядного
представлення структури ПЗ і принципів його функціонування. Незримість
властива природі ПЗ і призводить до складнощів під час його розуміння і
осмислення, а також ускладнює процеси обміну інформацією між учасниками
проекту.
Таким
чином, природі ПЗ властиві об’єктивні складнощі, які, відповідно,
відображаються на процес розробки ПЗ.
Слід
відзначити, що характерна особливість діяльності з розробки ПЗ – велика доля
витрат на робочу силу у загальній суми витрат на розробку. При розробці ПЗ доля
витрат на оплату робочої сили за певних умов може досягати майже 100%, в той
час коли інженерні компанії з інших сфер діяльності автоматично відносять
проекти до проектів з високим ризиком, коли доля витрат на оплату робочої сили
перевищує 50% .
Виробничі
витрати, тобто витрати власне на відтворення копій розробленого ПЗ, можуть бути
надзвичайно низькими у порівнянні з витратами на розробку. Це дозволяє
використовувати такі форми розповсюдження програмних продуктів і побудови
економічної моделі взаємовідносин з замовниками, які не прийнятні в інших
сферах підприємницької діяльності, наприклад, безкоштовне розповсюдження
програмного продукту і надання платних послуг впровадження і супроводу.
Що
стосується раніше наведеного поділу інновацій на продуктові та процесні, то
слід зазначити, що специфіка діяльності з розробки ПЗ передбачає створення
нового продукту чи надання нових якостей існуючому продукту у кожному
програмному проекті. Таким чином, створення продуктових інновацій є звичайною
практикою діяльності компаній-розробників ПЗ, а саму діяльність, на наш погляд,
можна охарактеризувати як інноваційну за своєю природою.
Завдання управління проектами — досягти встановлених цілей за
показниками обсягів, часу, затрат (бюджету), якості.
Менеджерові проекту потрібно забезпечити найкращу якість
виконання необхідних робіт з мінімальним бюджетом і в стислі строки. Проте, як
бачимо з рис. 1.2, згадані цілі мають різні вектори спрямування, тобто
скорочення строків виконання проекту потребує збільшення бюджету за незмінних
обсягів і якості, чи навпаки — обмеження бюджету вимагає збільшення строків або
ж коригування вимог щодо якості. Тому від природного, але нездійсненного
бажання мати за всіма цілями якнайкращі показники знаходять розумний компроміс
і обирають прийнятний варіант проекту — адекватного вимогам замовника щодо
обсягів і якості, поміркованого за строками й економічного за бюджетом. Таким
чином, дуже важливими є, по-перше, гармонізація цілей, а по-друге —
встановлення пріоритетів (залежно від характеру проекту і вимог замовника), що
їх надають цим цілям у ході виконання проекту і виникнення відхилень.
Наприклад, якщо йдеться про проект виведення нового продукту на
ринок перед початком сезонного зростання попиту на цей товар, то пріоритетним,
безумовно, є своєчасне завершення
проекту, і в разі потреби бюджет може бути збільшено, аби проект не вийшов за
встановлені строки. У проекті впровадження системи контролінгу на підприємстві
таким пріоритетом може виступати бюджет,
якщо кошти підприємства обмежені, а строки впровадження не мають критичного
значення і можуть коригуватися. У проекті підготовки літньої бази відпочинку
пріоритетними можуть бути і строки, і бюджет, тоді коригуванню
підлягатимуть передусім обсяги робіт, тобто може бути прийняте рішення ремонтувати
не всі будиночки, а тільки якусь частину їх.
В
практиці управління проектами з розробки ПЗ використовується поняття «залізного
трикутника», який визначає обмеження на найважливіші параметри програмного
проекту: обсяг робіт, час та ресурси (рис. 1.3).
Рисунок 1.3
– «Залізний трикутник» – обмеження програмного проекту
Відповідно
до правила «залізного трикутника» для забезпечення успіху програмного проекту
необхідно, щоб фіксованими залишалися не більш, ніж дві його вершини, інакше
проект буде перевантажений обмеженнями.
А. Коуберн пропонує додати до правила «залізного трикутника»
нову вершину – процес і представити його таким чином, як зображено на рисунку 1.4.
Рисунок 1.4
– Модифікований «залізний трикутник»
Необхідність
введення додаткової вершини пояснюється наявністю на практиці проектів, у яких
фіксованими є всі три вершини традиційного трикутнику, однак ці проекти залишаються
успішними.
Діяльність
з розробки, впровадження і супроводу ПЗ – це інтелектуальна діяльність, яка, як
правило, здійснюється колективно, включає в себе окремі складові (етапи моделі
SLC), що передбачають поділ праці та інтенсивний обмін інформацією між
учасниками, характеризується інноваційною природою, складністю, високою
здатністю до змін, відносно великою долею витрат на оплату праці у загальній
структурі витрат. Дана діяльність передбачає не лише розробку і поставку
програмного продукту, а й супровідної документації до нього, надання послуг з
впровадження, що передбачають встановлення програмного продукту у замовника,
його інтеграцію з існуючою апаратно-програмною інфраструктурою, проведення
навчання персоналу, а також послуги супроводу, які передбачають модифікацію
продукту після його поставки, усунення помилок у самому продукті та супровідній
документації до нього, здійсненні будь-яких інших операцій по підтримці
продукту, передбачених домовленостями між розробником і клієнтом.
Основна
проблема невдач більшості проектів інформатизації полягає, насамперед, у
неврахуванні специфіки ПЗ як особливого виду інтелектуальної діяльності,
насамперед, колективної діяльності.
Спочатку
діяльність з розробки ПЗ розглядалася як наукова діяльність (50-ті рр. XX ст.), оскільки
ПЗ у той час використовувалося для наукових розрахунків, пізніше – як
математична чи інженерна.
Діяльність
з розробки ПЗ почала розглядатися як будь-яка інша самостійна діяльність з
розробки ринкового продукту в зв’язку зі створенням концепції життєвого циклу
ПЗ (SLC, Software Life Cycle), що стала наслідком проведеної у жовтні 1968 р.
в німецькому м. Гармиш конференції підкомітету
НАТО з науки і техніки. Модель SLC отримала назву «каскадної» чи «водоспадної»,
її графічне представлення SLC зображено на рисунку 1.5.
Рисунок 1.5
– Каскадна модель життєвого циклу розробки ПЗ SLC
В даний
час модель SLC вважається застарілою і у «чистому» вигляді майже не
застосовується, однак вона стала основою практично всіх сучасних моделей
вивчення життєвого циклу розробки ПЗ, термінологія та послідовність етапів SLC
були запозичені більш досконалими моделями, тому їх сутність та значення для
характеристики діяльності з розробки ПЗ не втратили своєї актуальності в наш
час.
Відповідно
до рис. 1.5 діяльність з розробки ПЗ фактично включає 9 послідовних
етапів. Узагальнено прийнято виділяти чотири етапи: проектування, розробка,
впровадження та супровід. Проектування включає перші три етапи SLC (дослідження
концепції, дослідження системи, вимоги), розробка включає четвертий етап SLC
(розробка проекту), впровадження включає п’ятий та шостий етапи (впровадження
та встановлення), супровід – останні три етапи (встановлення, експлуатація та
підтримка, виведення із експлуатації). Для цілей даного дослідження етап
«проектування» буде спрощено розглядатися як складова етапу «розробка»,
оскільки з економічного погляду результатом послідовного виконання цих двох
етапів буде ПЗ як товар, який виступатиме об’єктом економічних відносин між
розробником і клієнтом у наступних етапах впровадження та супроводу.
Іноді як
окремий етап каскадної моделі виділяється тестування, однак цей етап доцільно
виділяти лише для тих моделей, які передбачають ітераційне виконання чи повернення
на попередній етап, у оригінальній каскадній моделі тестування є складовою
частиною етапу розробки проекту і звичайно окремо не виділяється.
Таким
чином, слід визначити основні специфічні особливості проектів з розробки
програмного забезпечення.
Це
інтелектуальна діяльність, що характеризується високим рівнем складності і
невизначеності.
Це
колективна діяльність, яка потребує досконалих комунікації та координації дій.
Проекти
реалізуються за умов обмежень, значний рівень порушення яких може привести до
невдачі проекту.
Вимоги до
проектів не є статистичними, вони можуть уточнюватися
і змінюватися.
Успіх проекту у значній мірі
залежить від якості проектного менеджменту.
СP.01 – Вступ в управління ІТ- проектами.
Компетенції управління проектами інформатизації [7, С. 34-75].