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

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

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

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

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



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

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

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


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

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

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


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

У доповнення до стандартних методів 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 підхід?

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

Буду радий почути вашу думку на цей рахунок!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.