Як відповісти "Коли це буде зроблено?"

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

Як можна відповісти на запитання "Коли це буде зроблено?", Особливо коли клієнт може не розуміти властивих йому складнощів розробки програмного забезпечення?

Ви відповідаєте на питання чесно.

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

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

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

причому D є самим процесом розкладання.

У реальному світі єдина проблема полягає в тому, що t ( D ) насправді буде більшим за час, який ви витрачаєте на вирішення дрібних проблем. Іншими словами, щоб дійти до цього рівня декомпозиції проблеми, вам практично потрібно вирішити проблему самостійно.

Ви все ще можете:

• Розділіть задане завдання (вирішення питання) на менші шматки, кожен шматок як і раніше є складною проблемою,

• Оцініть очікуваний час для кожного куска та відповідний ризик.

  Наприклад, завдання 1 вимагає бл. 5 годин, але ризик заблокувати його високий, тому надайте 12 годин, як очікуєте клієнту.

• Оцініть залежності та те, як вони впливають на час.

  Наприклад, на завдання 19 потрібно 2 години, а ризик настільки низький, що можна сказати, що це 2 години точно. Не 1. Не 3. Але завдання 19 покладається на завдання 24: завдання 24 може впливати на завдання 19 таким чином, щоб вам було потрібно повністю переписати код завдання 19, використовуючи інший підхід.

• Надайте всі ці дані своєму клієнту. Не дайте суму.

Останній пункт важливий. Якщо ви дасте суму, скажімо, 192 години, клієнт вважає, що це дуже точний показник, а час, який ви витратите, становить від, скажімо, 189 до 195 годин.

Якщо натомість ви даєте реквізити,

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

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

Що б ви не оцінювали, не забудьте включити закон Гофстадтера : Це завжди триває довше, ніж ви очікували, навіть якщо ви враховуєте закон Гофстадтера.

Зазвичай я використовую модифіковану формулу від CPM / PERT. Це щось подібне:

Mn + Mx + C(T) / 2 + C, where
Mn is the minimum number of hours you think it will take,
Mx is the maximum number of hours you think it will take,
T is the typical number of hours it takes,
and C is a confidence factor from 1 - 3 based on how much you've done similar things.

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

So, if you think:
Mn = 60  hours
Mx = 180 hours
T  = 100 hours
C  = 2
Then: 60 + 180 + 2(100) / 4 = 110 hours.

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

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

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

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

• Спробуйте діапазон - "Я впевнений, що це займе не менше N днів (наприклад, 3), але це може зайняти стільки 4N".
• Зверніться за підтримкою старших інженерів в оцінці та захисті оцінок.
• Працюйте у коротших ітераціях (стиль Agile / Scrum), щоб створити мінімальний код, який додає ділової цінності (завоювання впевненості та довіри), а потім повторіть.
• Навчіться навичкам ведення переговорів із книги, як класична Як дістатися до так (http://www.amazon.com/gp/aw/d/0143118757).

Для нового розвитку, особливо Agile-розробки:

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

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

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

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