👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Як я розумію питання в переводі функціональних одиниць в реальні дні. Насправді усе доволі просто і одночасно складно. Припустимо вам відомо, що ваша команда здатна робити в строк 2 тижні в середньому 30 функціональних одиниць. Загалом проект оцінений на 700 одиниць. Таким чином ви можете розлити 700 на 30, після чого помножити це на 10, тобто кількість робочих днів на тижні і додати ще з гори 25% на вирішення проблем які гарантовано будуть. Таким чином зможете прорахувати строки. Чому така проста річ одночасно складна — на пресейлі у вас швидше за усе нема ніякої команди, а може її взагалі треба ще хайрити з ринку. В такому випадку ваші усі естімейт в функціональних одиницях фактично — пальцем в небо, а естімейт зі стелі. Як не дивно в людино годинах, чи місяцях вийде ще гірше. ІТ-шникі не здатні чітко оцінити роботу в реальних годинах, на сам перед робочий день не дорівнює 8 годинам роботи, максимум 6 а може в меньше. Чому — мітинги, вирішення якихось питань, блокери і т.д. Крім того люди не автомати, день на день не приходиться. В когось голова болить чи до дантиста треба, захворів і т.д. . В таких випадках вам допоможе лише стара добра діаграма Ганта, та критичний шлях на ній. Естімейт від одної людини одразу можна сказати, що повністю не дієва річ, як мінімум треба додати по одному спеціалісту з конкретного типу діяльності — дизайн, тестування, фронтенд, бекенд, девопс і т.д. з усіх типів робіт які мають бути зроблені. Якщо ви цього ще не розумієте тобто чого та скільки треба зробити — то малюйте діаграму Ганта, вона же роад мап. Це надає можливість зрозуміти які у вас взагалі є задачі, які між ними залежності та люди з якими вміннями потрібні для виконання проекту. P.S. Зверніть увагу на роботи Р. Де Марко, там пояснюється такі речі доволі не погано.

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

А навіщо, власне, трекати робочий час? Тут треба вияснити, чи вам потрібні робочі години, чи вам потрібен робочий проект. Підозрюю, що все-таки друге. Від цього і «танцюємо».

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

Якщо задачі закриваються вчасно та якісно — то яка різниця, скільки годин реально працював розробник? Щоб не дай боже не заплатити зайвого? Ну, так тоді наступного разу він чесно «відпрацює» весь естімейт. Щоб не «стригли клієнта як лоха»? Це захищається адекватністю початкових естімейтів (це «точка відмови», тут необхідна довіра).

Я за свою карʼєру працював і із тайм-трекерами (а-ля «дьоргай мишку кожну хвилину, а то не зарахує час»), і з ручними логами часу, і взагалі без логів. І як не парадоксально, але в довгій перспективі, чим більше контролю — тим гірша продуктивність.
Чому? Бо коли в тебе немає трекеру, і в кінці тижня ти жодного тікету не передав на QA — до тебе явно виникнуть запитання, при чому в приватному порядку. А якщо є трекер — то практично завжди можна вписати туди якість «інвестігейти, ресьорчі, мітинги», ітд. І, скоріш за все, це проканає, особливо якщо команда величенька.

Підсумовуючи, перш ніж будувати процеси тайм-менеджменту та КПІ, випишіть собі список проблем які ви хочете вирішити. Бо «менше платити розробникам» та «витрачати менше часу на продукт» — це далеко не завжди одна і та ж задача

Працював 4 роки з треканням годин в Jira Timesheet.
Суть — залупити кудись 8 годин в день.
Деякі персональні правила:
— будь-який мітинг це мінімум 0,5h
— часто до фактичних мітингів +0,5h на свіч контексту
— закидали емейлами — ловіть ще 0,5-2h на їх розгрібання (2h то кейс після відпустки)
— все інше розноситься по таскам щоб сильних перекосів estimated/spent не було
— само собою що нічого не естімейтилось по типу «та тут на годинку», мінімум 4h
Чи стало від цього комусь холодно чи жарко — до сих пір не знаю.
Кажуть, що менеджери рахували якісь там KPI.
В результаті пішов сам, разок зупинили контр-оффером, вдруге грошей не вистачило.

Не буде, бо на тому проекті упоролись в юніт-тести (яких було аж 11 000 штук) і навіть замінити 1 букву на кнопочці з усіма dev/test/PR/review/deploy/qa не може заняти менше 4 годин з моєї точки зору. Ще не дай Бог QA зловить якийсь локальний кеш і почалося перевідкривання тасок.

Я будь-який таск, який виходить за межі «1 строчка коду» естімейтив мінімум на 8 годин.
4 години — це буквально колір або слово поміняти десь.

Я популярно ще спочатку пояснив усім причетним:
розвели бюрократію — отримуйте відповідні естімейти.

Там ще треба було бачити оцю піраміду тікетів: epic — story — task — subtask.
Плюс по факту кінцеві тікети (сабтаски) в усіх усюди заливались на 80-120% від естімейту.
Тому якоїсь очевидної ями типу «естімейтимо х2-х3 від потрібного» не було.

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

В різних компанія по різному, але по моєму досвіду це 20-30% часу зверху на мітинги/комунікацію. Інвестігейт як окремі завдання з виділеним на це окремим часом. Тобто, виходить годин по 6 на робочий день

Як розробнику репортити час кожного дня? Що вкладати в репорт?

В залежності від довіри до колег та їхньої цінності.
Якщо цінуєте колег, то цілком прийнятно в JIRA в кожній історії поруч з estimated time, добавити можливість додавати spend time з коротким коментарем що було зроблено (Приклад: Added order description field to order form)
Якщо зовсім пофіг на колег, то можна примусити їх встановити таймтрекери з періодичним скріншотингом. Але з цього моменту можна вважати що колеги почали всерйоз шукати нову роботу

ІМХО, дев може і 2 години в дань працювати якщо закриває роботу з естімейтом у 8.

Але тоді питання, а як так оцінювали що таск який дев може закрити за 2 години має естімейт 8?

Бо оцінюють по спроможності «середнячка або найслабшого в команді».
Різниця між продуктивністю інженерів навіть в тій самій тімці і ± тій самій зарплаті може бути в рази. І це нормально.
Хтось висипається і харчується нормально, працює тільки над проектом і не вчиться.
А хтось має троє дітей, або бухає вечорами чи постійно вчиться щоб через рік піти на х2.

Підписатись на коментарі