Альтернативи методології відстеження часу [закрито]

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

Пояснення:

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

Ми з'ясовуємо, скільки потрібно заряджати, отримуючи оцінку часу, що займається (Від дизайну та розробників), помножуючи його на нашу погодинну ставку, і все. Отже, скажімо, ми оцінюємо 50 годин для веб-сайту. У нас є програмне забезпечення для відстеження часу, і ми мусимо записувати час у 15, який ми витрачаємо на нього (наприклад, 7:00 до 7:15), назву проекту, і давати йому кілька коментарів.

Тепер, якщо ми переходимо за 50 годин, ми обидва втрачаємо гроші і неефективні.

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

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

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

У своєму особистому консалтинговому досвіді я намагаюся поєднати реалістичну оцінку зі стелею. В основному кажучи: "Я очікую, що ця функція займе 7-10 годин, але може досягти 18 - максимум, навіть якщо це займе 40 годин, вам виставлять рахунок за 18". Зазвичай такий тип підходу є новим для клієнтів, і деякі відмови відмовляються від нього, "дай мені тверду ціну" - ці клієнти отримують максимальну оцінку (або я ввічливо відхиляю свою діяльність). Для клієнтів, які приймають такий підхід, вони розуміють, що я чесно відслідковую час, і їх фактичний підсумковий рахунок відображатиме мій витрачений час (але не перевищує мою стелю). По суті це пісний підхід із додаванням гарантії; і замовник усвідомлює, що будь-які зміни вимог вносять зміни до кошторисів.

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

Якщо ви цього не зробили, я б запропонував прочитати Міфічний місяць людини

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

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

Чим крутіша крива, тим впевненіше ви впевнені, що дата корабля справжня.

Ось як ви це робите ...

Проблема цього методу полягає в тому, що він не враховує властивий ризику в оцінках. Найкращою практикою для будь-яких оцінок є його вираження у діапазоні разів, наприклад, 50 годин ± 15 годин, або щось подібне. Термін помилки важко придумати, але ніхто не вірить, що це все одно займе рівно 50 годин.

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

Ми робимо оцінки з коефіцієнтом "невизначеності", а не намагаємось оцінювати з коефіцієнтами "+/-". Програмісти можуть легко сказати вам, як довго щось займе, "припускаючи, що нічого не піде не так". Те, що вони не можуть вам легко сказати, - це скільки часу пройде, якщо щось НЕ піде не так. Отже, ми додаємо коефіцієнт невизначеності - "L" означає "додати 25%" - "M" означає "додати 50%", а "H" означає "додати 100% - може подвоїтися". Реальний час, як правило, знаходиться між розрахунковим часом та оцінкою плюс час невизначеності.

Що стосується ВІДТВОРЕННЯ свого часу, найточнішим методом є написання програми, яка щохвилини спливає діалогове вікно і запитує у вас "що ви робите?" Зі списком списку можливих завдань. Єдиний запис, який вам справді потрібен у цьому спадному списку, - це "відстеження часу", тому що якщо вас перебивають щохвилини, ви ніколи нічого іншого не зробите. Цей же принцип діє і для 15-хвилинних інтервалів, не так вже й погано.

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