DOU Labs: як в ELEKS застосували штучний інтелект для моніторингу проектів

В рубриці DOU Labs ми запрошуємо IT-компанії ділитись досвідом власних цікавих розробок та внутрішніх технологічних ініціатив. Питання і заявки на участь надсилайте на  Данный адрес e-mail защищен от спам-ботов, Вам необходимо включить Javascript для его просмотра. .

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

Уявіть, що ви СТО в компанії, яка займається розробкою проектів. Щодня перед вами постає безліч запитань, крім того, на вас покладена величезна відповідальність. Який стан справ у вашому бізнесі? Що ви знаєте про проекти у вашій компанії? Чи не випущено з поля зору нічого важливого? Як збудувати та якісно реалізувати технічну стратегію? Як запобігати проблемам? Що є їх першоджерелом?

Ви б змогли відповісти на всі ці запитання? А змогли би відповідати так, щоб з безумовною впевненістю оперувати безперечними аргументами та конкретними даними про деталі роботи принаймні одного із проектів?

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

Яка ж безкінечна кількість чинників формує в обох випадках вашу уяву про «успішність» і загальне враження, про її причини, про фактори та наслідки для одного і того ж проекту? Таким чином, правильним є лише той факт, що ви, звісно ж, щиро зацікавлені в якнайкращому результаті роботи проекту. Але незмінним залишається і те, що у кожного із вас «своя правда» про успіх і фактори, які на нього можуть впливати. Ця специфічна інформація найбільш доступна проектному менеджеру. Однак на шляху до СТО інформація опрацьовується під впливом інтерпретації різних ланок менеджерів, і життєво важливі деталі легко втратити.

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

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

Команда ELEKS Data Science

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

Отже знайомтесь — ProjectHealth — наше рішення для моніторингу та управління проектами.

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

Реалізація

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

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

Чому поєднання критеріїв є запорукою успішного вимірювання?

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

• Scope (масштаб) — для характеристики конкретних цілей проекту, функцій, завдань, дедлайнів, вимог і т. д.
• Budget (бюджет) — для відстеження фінансових показників проекту.
• Time (час) — для визначення вчасності (вкладання в термінам та графіки).
• Quality (якість) — для оцінки загального стану якості виконання проекту.
• Resources (ресурси) — для оцінки управління ресурсами проекту.

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

Отже, як обчислити 5 ключових показників успіху?

Після того, як ми прийняли рішення використовувати комбінацію критеріїв, настав час почати побудову математичної моделі, здатної розрахувати і проаналізувати окремі фактори, що впливають на загальний «стан здоров’я» проекту та кожен з визначених вище критеріїв. Для цього було обрано побудову ймовірнісної графічної моделї (probabilistic graphical model, PGM), а саме байєсівську мережу (Bayesian network, BN) — імовірнісну орієнтовану ациклічну графову модель.

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

Нижче зображено готову до використання модель, засновану на даних, отриманих з таких джерел:

• система управління проектами та відстежування помилок, яку використовуємо в ELEKS;
• програма для командної взаємодії і база знань, яку використовуємо в ELEKS;
• CRM-система;
• HR-система, яка використовується для відстеження процесів управління людськими ресурсами;
• репозиторій коду ELEKS;
• внутрішня система управління фінансами.

Рис 2. Так виглядає робоча модель Project Health

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

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

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

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

• індекс задоволеності клієнта;
• виконання релізу на конкретну дату;
• зміна значення середньої кількості часу, витраченого на роботу над задачею (cycle time);
• зміна кількості задач, що мають статус «in progress»;
• зміна кількості повторно відкритих багів;
• зміна співвідношення закритих і відкритих багів;
• фінансові дані поточного проекту, згідно з корпоративними KPI;
• стадія проекту;
• тип проекту;
• наявність запитів та доступність потрібного обладнання або специфічного середовища та ін.

Коли ми ще нічого не знаємо про проект, для прорахунку ймовірності його успіху метод використовує закладені в основу моделі CPD. Таким чином, базуючись на досвіді експертів, знання яких було покладено в основу моделі, ми отримуємо значення умовної ймовірності успіху проекту в компанії, яка дорівнює 87,36 %.

Рис. 3 . Стан проекту в умовах повної невизначеності

Отже, як тільки оновиться інформація, це призведе до перерахунку значень для залежних нод. Уявімо, що ми знаємо такі факти про проект:

1. Модель співпраці, що використовується для цього проекту є фіксованою (fixed bid).
2. Проект досягнув стабільної стадії.
3. Середній час для виконання задачі знижується порівняно з попередньою перевіркою.
4. Кількість відкритих і повторно відкритих багів нижча порівняно з попередньою перевіркою.
5. Фінансові цілі проекту збігаються з KPI компанії.
6. Всі інструменти налаштовані і використовуються.
7. Відсутні блокуючі запити, що стосуються програмного і апаратного забезпечення.
8. Немає відкритих вакансій.
9. Останній прорахований показник задоволеності клієнта є високим.
Загалом складається позитивна картина, однак ми також знаємо, що:
10. Акумулюються задачі у статусах «in progress».
11. Спрогнозована дата релізу проекту виходить за межі затвердженого графіка.

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

Описані спостереження спричиняють перерахунок ймовірностей всіх залежних від них нод у моделі і, як результат, отримуємо нове значення успіху проекту — 12,71 %.

Рис. 4. Стан проекту після отримання нових спостережень

Нашим наступним кроком було затвердити і реалізувати модель в межах всіх проектів компанії. Тому ми запропонували PM’ам компанії підтвердити точність розрахунків, отриманих від моделі. Ми виявили, що отримані нами розрахунки були дуже близькими до оцінок проектних менеджерів. Основна частина подальших удосконалень була пов’язана з уточненням значень CPD. Таким чином, ми скорегували вплив одного вузла на інший. І тільки після проведення ретельного аналізу ми продовжили збір даних для всіх проектів компанії, щоби розрахувати їх успіх. Так було побудовано систему, що є доступною для менеджерів різних ланок, яка допомагає їм тримати руку на пульсі кожного проекту та бізнесу загалом.

Рис. 5. BI dashboard — демонстрація реального стану проекту

На цьому скріншоті ми можемо побачити, що найменше значення Project Health було отримано 10 лютого 2017 року. Завдяки можливості робити дрілдаун на самому дашборді, дізнаємось, що саме спровокувало таку зміну.

Причиною є зниження значення наданої на цю дату якості роботи (Quality). Занурюючись глибше, бачимо, що знизилось значення ефективності роботи команди (Project Effectiveness), що в свою чергу було спровоковано збільшенням кількості задач зі статусом"in progress«.

Подальші кроки роботи над системою

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

Топ-менеджери компанії відтепер бачать більш чітку та широку картину для оцінки бізнесу з точки зору делівері проектів, з можливістю зануритись в деталі кожного з них, за необхідності доходячи аж до «сирих даних» завдяки реалізованому дрілдауну. Окрім того, для PM’ів цей продукт є додатковим засобом контролю та організації роботи всередині проекту. Інструмент можна використовувати для аргументації їхніх рішень та як додатковий засіб комунікації всередині компанії. Також система дозволяє швидше виявляти причину проблем, якщо такі існують. Іншими словами, це економить час та зусилля наших менеджерів, і, безумовно, робить їхнє життя легшим. Розуміння поняття успішного проекту тепер єдине для всієї компанії.

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

Ми продовжимо ділитись із вами нашими винаходами та досвідом. Слідкуйте за нашими новинами на elekslabs.com.