Розробник у трикутнику керування проектами

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

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

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

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

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

В ідеалі кожна задача, яка поставлена розробнику, повинна бути вирішена так, щоб:

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

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

Навіщо це нам потрібно?

  1. Підвищення ефективності роботи HR.

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

  1. Задоволений замовник.

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

  1. Невеликі витрати, відносно очікуваного ефекту.

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

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

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

Тепер про два можливі підходи до грошей і на часі

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

  • оцінка завдання в годинах того розробника, який буде їй займатися (попередньо узгоджена з самим розробником);
  • дані про те, скільки годин реально було витрачено на це завдання (для цього необхідний тайм-трекер);
  • термін, due date, до якого завдання має бути готове.

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

Щодо бюджетних характеристик цей підхід розглядає три варіанти проектів з точки зору підходу до ціноутворення:

  1. Fixed cost проект не передбачає відхилення від бюджетних характеристик в принципі.
  2. Time and Material проект означає, що вартість лінійно пов'язана з витраченими годинами, з чого випливає, що відхиленню від бюджету тотожне відхилення від термінів. Таким чином, у цих варіантах фактично відсутні бюджетні метрики.
  3. При нестрогом же fixed cost проекті, в якому є можливість погоджувати зміни бюджету, потенційно не ясно, яку частину зміни в бюджеті слід віднести до «заслуги» конкретного розробника. В цілому, цей підхід означає, що в трикутнику управління проектом для окремого розробника показники бюджету адекватно відобразити неможливо, і залишаються лише метрики якості/термінів.

Другий погляд пропонує частину метрик часу перерахувати на бюджетні показники. Потрапляння в терміни тут вимірюється з використанням календарних дат - Start date, Due Date, Actual Date. Конкретно метрика терміну може вимірюватися як кількість зірваних термінів на завдання, або ж як співвідношення різниць між Start date/Due Date і Due Date/Actual Date. Показник бюджету - будується на основі попередньої оцінки часу і реально витраченого на завдання часу. Бюджетну розбіжність тут передбачається розраховувати як середнє відхилення витраченого часу від часу оцінки.

У зв'язку з усім викладеним вище, виникає кілька природних питань:

По-перше, який з двох підходів, на ваш погляд, краще описує професіоналізм розробника в контексті потрапляння в терміни/бюджет/якість? І які варіанти, крім проектного трикутника, можна було б використовувати?

По-друге, хотілося б зрозуміти, чи можна співвіднести бюджети в грошах з естімейтами і реально витраченими годинами в завданнях? Що таке терміни і чи належать вони до естімейтів або ж до Start date і Due Date?

Чи можливо врахувати відмінності в проектах з точки зору підходу до ціноутворення (fixed cost, time and material, інші варіанти) при розрахунку бюджетної метрики для конкретного розробника, або для нього має сенс тільки fixed cost підхід?

По-третє, цікаво, наскільки коректно використовувати модель, яка ілюструє об'єктивні обмеження, що виникають при управлінні проектами, для кількісного опису професіоналізму розробника?

Буду радий почути вашу думку з цього приводу!