Що робити, коли оцінка часу пішла не так?

Скажімо, ви розраховували, що час для справи склав 3 дні. У другий день ви помічаєте, що справа зростає, і з’являються нові сценарії, які не враховувались під час оцінки часу. Нова знахідка призводить до додаткових 2 днів (всього 5 днів). Це типова проблема, з якою ви рано чи пізно зіткнетеся як розробник.

• Яку стратегію можна використовувати, коли ви збираєтесь повідомити керівника проекту про новий час доставки?
• Часто виникає питання, чому? Як ви мотивуєте новий час доставки?

Справа в тому, що багато проектів не приділяють багато часу аналізу та дизайну під час SDLC.

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

Подання поганих новин

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

Як і у всіх поганих новинах, найкраще надати детальну інформацію (а не просто розмивати "це буде пізно"), тому надайте стільки / багато:

1) Переглянуті кошториси / часові шкали завдань, які пройшли.

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

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

4) Якщо можливі альтернативи, щоб повернути речі в дорогу (як правило, скорочення обсягу, але можуть бути й інші варіанти - інші частини проекту можуть бути випереджені і можливо перемістити завдання).

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

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

Запобігання появі поганих новин

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

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

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

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

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

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

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

Припиніть оцінювати в днях і почніть використовувати замість них відносну оцінку . Ось простий приклад:

1. Призначте номер до кожного завдання. Найскладніше завдання може бути 10, а найлегше завдання 1.
2. Почніть програмування для виконання завдань.
3. Через тиждень припиніть свою роботу і підсумовуйте всі номера виконаних завдань. Скажемо, ви закінчилися з 14. Це ваша щотижнева швидкість.

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

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

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

Швидкий доступ, швидше за все, принесе більше шкоди в підсумку, і всі учасники повинні це знати. Або якнайменше, чи варто їм це пояснити.

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

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

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

В ідеалі ваш список функцій був би MoSCoWed - Must, Should, Could, Won't.

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

В ідеалі у вас буде лише ~ 60%. Якщо вам доведеться вирізати тих, з ким ви стикаєтеся з дуже глибокими проблемами (дуже серйозний переріз), і тоді вам доведеться вирізати кути.

Переконайтеся, що ви приділяєте собі достатньо часу після звільнення, щоб очистити безлад, зроблений розрізанням кутів!

Оцінка проекту гральна, проста та проста. Без ризику немає винагороди.

Якщо менеджер цього не розуміє, я б це пояснив.

Питання в тому, хто покриває ризик?

Якщо ви укладаєте договір з фіксованою ціною, тоді ви покриваєте ризик.

Якщо час і матеріали, то він покриває ризик.

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

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

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

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

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

Найкраще, що ви можете зробити, коли ви спізнюєтесь (а також коли ви «ризикуєте доставити заздалегідь», оскільки проблема одна і та сама: ви погано оцінили) - це ескалація та підняття факту до замовника якомога швидше. Це називається управлінням ризиками. Чим швидше ви дасте відгуки, тим ефективнішим буде контрзапад. Зазвичай це означає, що якщо у вас є докази, що ви не можете все доставити, вам слід поговорити зі своїм клієнтом, сказати їй, що ви можете виконати лише 70% зобов'язань і нехай вона вирішить, що для неї має більше ділової цінності і має розгорнутися першим .

Я писав про це тут Неправильна оцінка, допоможіть! Я запізнився! Виріжте функції та зупиніть водоспад!

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

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

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

а. Спробуйте знайти тимчасове виправлення або швидку допомогу

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

Запропонуйте альтернативний підхід до їх проблеми, можливо, хороша ідея.

c. Понаднормовий

Параметри:

• Особливості вирізання
• Якість вирізання (виправлення помилок залишайте на потім)
• Підвищення продуктивності
  • Знайдіть та видаліть блокатори
  • Перерва / відпочинок
  • Скоротіть особистий час / час сну
  • Отримайте більше робочої сили
  • Отримайте кращі інструменти
  • Навчання
  • Підвищити мотивацію
    • Безкоштовна їжа
    • [Обіцянка] підвищення / просування / відпустка / бонус / тощо.
    • Загрози
    • Покращення умов праці (покращення обладнання, меблів тощо)
    • Змініть оточення - працюйте в кав’ярні або перенесіть всю команду кудись круто - гірський будиночок чи озерний будиночок?

Це поширена проблема :)

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

У більших командах більше людей, які можуть захворіти, і менше людей, які знають "все".

Нові технології завжди більш ризикові, ніж ті, які ви вже знаєте.

І коли ви побачите, що очікувана дата вас не закінчить, повідомте рано з зацікавленими сторонами. Можливо, ви можете повторно визначити пріоритет або затримати певні функції після розмови з замовником / учасником.