Як відповісти, коли вас запитують про оцінку?

Нас, як програмістів, постійно запитують "Скільки часу це займе"?

І знаєте, ситуація майже завжди така:

• Вимоги незрозумілі. Ніхто не провів глибокого аналізу всіх наслідків.
• Нова функція, ймовірно, порушить деякі припущення, які ви зробили в своєму коді, і ви почнете негайно замислюватися над усіма речами, які вам можуть знадобитися для рефактора.
• У вас є інші речі, які можна зробити з попередніх завдань, і вам доведеться скласти кошторис, який враховує цю іншу роботу.
• Визначення "зроблено", ймовірно, незрозуміле: коли це буде зроблено? "Готово", як щойно закінчене кодування, або "зроблено", як у "користувачі його використовують"?
• Незалежно від того, наскільки ви усвідомлюєте всі ці речі, іноді ваша "гордість програміста" змушує вас давати / приймати коротші рази, ніж ви спочатку вважаєте, що це може зайняти. Особливо, коли ви відчуваєте тиск термінів та очікувань керівництва.

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

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

Який ваш особистий процес для прийняття рішення та надання оцінки? Які прийоми ви знайшли корисними?

Від прагматичного програміста: від мандрівника до майстра :

Що сказати, коли запитують оцінку

Ти кажеш: "Я повернуся до тебе".

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

У розділі автори рекомендують наступний процес:

• Визначте точність, яка вам потрібна. Виходячи з тривалості, ви можете цитувати оцінку з різною точністю. Сказати "5 - 6 місяців" відрізняється від того, щоб сказати "150 днів". Якщо трохи засунеш на 7-й місяць, ти все ще досить точний. Але якщо ви ковзаєте на 180 чи 210 день, не так вже й багато.
• Переконайтеся, що ви розумієте, про що вас запитують. Визначте масштаб проблеми.
• Моделюйте систему. Модель може бути ментальною моделлю, діаграмами або наявними записами даних. Розкладіть цю модель і побудуйте оцінки з компонентів. Призначте значення та діапазони помилок (+/-) кожному значенню.
• Розрахуйте оцінку на основі вашої моделі.
• Відстежуйте свої оцінки. Запишіть інформацію про проблему, яку ви оцінюєте, вашу оцінку та фактичні значення.
• Інші речі, які слід включити до вашої оцінки, - це розробка та документування вимог або зміни специфікацій вимог, створення або оновлення проектних документів та специфікацій, тестування (підрозділ, інтеграція та прийняття), створення або оновлення посібників користувача чи README із змінами. Якщо 2 або більше людей працюють разом, накладні комунікації (телефонні дзвінки, електронні листи, зустрічі) та злиття вихідного коду. Якщо це довге завдання, враховуйте такі речі, як інші роботи, вихідні (канікули, канікули, час хвороби), зустрічі та інші накладні завдання під час вибору дати доставки.

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

Існує маса тактик їх створення, все ґрунтується на тому, щоб спочатку отримати хороші вимоги. Але коли ваша спина прилягає до стіни, і вони відмовляються надавати вам кращі деталі, підробляйте:

1. Погляньте добре на вимоги, які ви маєте.
2. Робіть припущення щодо заповнення прогалин, ґрунтуючись на найкращих здогадах про те, що вони хочуть
3. Запишіть усі свої припущення
4. Змусьте їх сісти, почитати і погодитися з вашими припущеннями (або, якщо пощастить, змусьте їх поступитися і дати вам реальні вимоги).
5. Тепер у вас є детальні вимоги, за якими можна оцінити.

Це так, як моя мама раніше, коли я була дитиною, погрожувала "Поспішай і вибери якийсь одяг, або я виберу їх тобі!"

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

• Я виставив рахунок за весь час, витрачений на оцінку. Це склало приблизно 20-25% від того, що я виставив рахунок.
• Я зробив надзвичайно детальне вивчення завдань. Немає стрілянини з стегна. Я зайшов у код, зрозумів, які рядки потрібно змінити, на які інші частини програми це вплине, скільки тестування мені доведеться зробити, щоб все ще працювало. Я оцінював би кожен шматок в одиницях .1 годин (6 хвилин).
• Я надіслав йому свою оцінку для кожного завдання разом із детальною розбиткою.

20-25% рахунків звучить як багато.

Але він попросив би мене змінити XYZ, думаючи, що це займе близько 2 годин. За 1 годину детального оцінювання я б визначив, що це займе 8,5 годин. Тож він вирішив, чи варто йому платити 8,5 годин. Якщо ні, то він заощадив 7,5 годин на те, що коштувало б йому, якби я зробив це без оцінки.

І якщо він так хоче інвестувати 8,5 годин, деталі роботи я зробив для оцінки була робота , я б мав зробити в будь-якому випадку.

Я виявив, що за допомогою цього методу я зміг вчасно поставити більшість завдань або навіть рано, без того, щоб сильно переоцінювати. Оскільки час був розбитий так щомісячно, я рано міг сказати, чи ковзаю. Якщо я потрапив на блокпости, щоб через 3 години я міг сказати, що на 8,5-годинне завдання потрібно буде взяти 12, я міг би поговорити з ним про це ще до того, як пройде більше часу, щоб він міг переоцінити та виграти функцію, якщо його турбує вартість .

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

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

Вони майже завжди отримують крапку.

Це залежить від того, на що складається оцінка.

Для початкової оцінки на високому рівні для ділової справи ключовими речами є:

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

Я вважаю найкращою технікою обрати порівняний проект, який «відчуває» те саме. "Відчуваю" цілком суб'єктивний характер, але при такій оцінці мій досвід говорить мені, що ви не знайдете об'єктивних вимірів. Тоді надайте широкий вибір. Я читав деякі книги, в яких говориться, що діапазон від -50 до + 100% - це добре, але це залежить від багатьох факторів.

Для детальної оцінки низького рівня:

1. Вам потрібна базова лінія. Якщо базовий рівень не є стабільним, оцінка не має сенсу.
2. Найкраще знизу вгору. Отримайте детальний розбір роботи, оцініть кожен компонент, а потім згорніть його на більшу кількість. Я вважаю, що планування покеру тут є чудовою технікою.
3. Випадковість документа Дайте зрозуміти, куди додано будь-яку ситуацію (якщо така є). Чи додається вона до кожної позиції? Або на всю оцінку? Або до конкретних ризиків? Або його немає?
4. Сформулюйте свої припущення. Слід перевірити якомога більше даних, враховуючи часові рамки.
5. Вкажіть чітко те, що включено та виключено в кошторис. Наприклад, чи включений огляд? Чи включаються технічні затримки?

Деякі поради з темної сторони від того, хто навчився важкого шляху.

Вимоги незрозумілі. Ніхто не провів глибокого аналізу всіх наслідків.

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

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

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

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

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

Визначення "зроблено", ймовірно, незрозуміле: коли це буде зроблено? "Готово", як щойно закінчене кодування, або "зроблено", як у "користувачі його використовують"?

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

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

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

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

Тим часом Джо оцінює 5 місяців. Ви думаєте, що це смішно, ви думаєте, що можете зняти це за один тиждень. Скільки працює Джо? 10 годин на тиждень? ... за винятком того, що він закінчує вчасно рівно за 5 місяців.

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

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

"Два тижні!"

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

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

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

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

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

Це залежить від організації та способів використання кошторисів.

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

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

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

Оцінки для чого? Невеликі завдання або комплексні рішення.

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

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

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

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

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

Їх: скільки це буде коштувати?

Я: Це залежить від того, що ти хочеш від мене зробити. Як правило, я починаю подібний проект близько $ X.

Іноді оцінка стає величезною проблемою для вас та вашої команди, особливо коли ми говоримо про оцінку програмного проекту.

Одного разу ми вирішили поділитися своїм досвідом та знаннями щодо процесу оцінки програмного забезпечення та визначили чотири різних типи оцінок :

• фігура бального парку
• кошторис обслуговування
• оцінка функції
• компонентна оцінка

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

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

Кожна людина повинна пам’ятати про ризики, пов'язані з розробкою програмного забезпечення: недооцінка, завищення, загальний сценарій невдач епічних тощо.

Ви можете прочитати більше на нашому блозі!

http://blog.lemberg.co.uk/project-management/software-estimation-process/

Сподіваюся, ця інформація допоможе вам!

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

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

Деякі поради на основі мого ~ 10-річного досвіду:

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

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

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

Якщо ви робите багато проектів для одного начальника чи клієнта, ви можете спробувати оцінити широкими штрихами складності замість тижнів чи місяців, можливо, розмірами футболки. Визначте кілька минулих проектів та призначте їх розміри S, M, L, XL.

А потім запитайте себе: який проект схожий на масштаб? І тоді замість відповіді на "2 місяці", ви можете відповісти "звучить як L для мене" (або як би не було калібрування вашого проекту).

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

Потім, коли вимоги змінюються, ви можете сказати, "що ця зміна звучить більше як XL".

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