Деякі правила поліпшення временн?й оцінки завдання

Автор статті: Олександр Дремов .
Підготовка статті до статті: Олексій Мудрик .

Зміст

© ralphb58


1. Введення

- Що ж ми бачимо, товариші? Ми бачимо, що блондин грає добре, а брюнет грає погано. І ніякі лекції не змінять цього співвідношення сил, якщо кожен індивідуум окремо не буде постійно тренуватися в шашки ... тобто я хотів сказати - в шахах ... І. Ільф & Є. Петров. «Дванадцять стільців».

Глава XXXIV. Міжпланетний шаховий конгрес

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

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

Якщо не вдаватися в нетрі психології, то можна сказати коротко і просто: люди діляться на сенсориків і інтуїти.

Робота з аспектом часу інтуїти дається від народження краще ніж сенсорика.

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

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

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

2. Про оцінку часу

2.1. Зрозумійте, що саме вам треба зробити в результаті

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

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

Далі, якщо завдання не атомарна, створіть її деталізацію.

2.1.1. Деталізація завдання

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

Розбивайте завдання на очевидні підзадачі до тих пір, поки підзадачі не будуть настільки для вас зрозумілі, що ви зможете дати їх прийнятну тимчасову оцінку

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

Не захоплюйтеся надмірним подрібненням.

Дуже сильне роздрібнення не несе користі; скоріше навпаки - воно шкідливе. Надмірна деталізація забирає час на її побудову та подальше підтримання деталізованого плану завдання. Також надмірна деталізація безглузда при недостатньо детальному тех.заданіі на завдання на момент оцінки.

Особисто я при оцінці найчастіше не опускаюся нижче 4 годин на задачу. Хоча іноді ставлю 2 години або 1 годину (необхідність у цьому виникає тоді, коли явно виділяються атомарні завдання невеликий тривалості). Але, в цілому, ваш мінімальний поріг буде залежати від того, який мінімальний рівень складності завдання ви зможете точно оцінити.

2.1.2. Визначення ризикових підзадач

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

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

2.1.3. Оцінка часу деталізованої завдання

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

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

• Оцінюючи завдання, уявіть, що ви реально сидите за комп'ютером і працюєте над нею безперервно. Подумайте, чи вистачить вас на таке безперервне кодування? Якщо ні, додайте до оцінки і витрати, які вам знадобляться на невиробничі потреби. А найкраще завжди закладайте в оцінку будь-якої задачі ці витрати часу на «попити кави і почитати пошту» .

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

2.2. Оцініть якість вашої оцінки

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

K = Tр/Tо

Чим більше статистика вимірів, тим більша ймовірність того, що ви більш точно врахуєте вашу похибка.

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

2.3. Для менеджерів

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

Додавайте до сумарних тимчасовим оцінками комплексних задач 20% -30% на ризики . Це може бути ризик того, що хтось із виконавців захворіє, або у нього несподівано (для вас) народиться дитина, або буде весільна подорож в Магадан. Так чи інакше, щось та обов'язково спрацює, особливо якщо терміни верхнеуровневих завдань більше двох тижнів.

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

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

2.4. Коротко про інструментарій

Є безліч програм для тайм-менеджменту та часового планування. Особисто я користуюся для побудови календарного плану загальновідомим продуктом MS Project. Мені його можливостей більш ніж достатньо.

У вас можуть бути свої переваги.

3. Підсумки

Резюмуємо все вищесказане. Що найчастіше призводить до помилок у тимчасових оцінках завдання?

Причини:

• Відсутність конкретики в поставленому завданню і спроба оцінити задачу, сформульовану в стилі «Піди туди, не знаю куди. Принеси то, не знаю що »

• Недостатнє розуміння оцінюючим кількості дій, необхідних для реалізації великого завдання

• Невраховані ризики, що впливають на ті чи інші завдання

• Оцінений завдання в «чистому» часу без обліку невиробничих витрат часу

• Неврахування тимчасових витрат на інтеграцію різних підзадач один з одним

• Неврахування блокуючих взаємозалежностей між завданнями різних виконавців

Методика усунення:

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

• деталізуйте завдання до тих пір, поки ви не отримаєте підзадачі які впевнено зможете оцінювати у часі.

• Не захоплюйтеся надмірною деталізацією

• Визначте ризикові завдання і збільшіть їх оцінку за часом, відповідно до ризиком (за замовчуванням це збільшення часу оцінки на 20% -30%)

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

• Враховуйте у вашій тимчасової оцінці невиробничі витрати часу

• Вирахуйте ваш коефіцієнт похибки оцінки і використовуйте його в подальшому для коригування.

• Враховуйте в оцінці блокуючі взаємозалежності між завданнями різних виконавців.

• Ведіть коефіцієнти похибки оцінки для ваших підлеглих і використовуйте їх для коригування видається ними тимчасової оцінки. Це все на сьогодні.

Спасибі за увагу.

Опубліковано: 12/01/12 @ 08:45
Розділ Різне

Рекомендуємо:

Дайджест цікавих вакансій № 15
Парламент відстрочив посилення штрафів за порушення, пов'язані з базами персональних даних
Дайджест: «Сталкер Шредінгера » , банкрутство Mandriva, демографічна незбалансованість , міфи App Store
25 - 26 лютого, Донецьк - ДОУ Хакатон - Донецьк!
Логіка замовників і програмістів, том перший