Справа з жахливими оцінками

Недавній проект, над яким я працював, архітектором був сильно недооцінений. Оцінка була не менше 500%.

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

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

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

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

Отже, як програмісти, який ваш досвід подібної ситуації і як ви порадили б вирішити цю проблему?

Довга відповідь, але ей, у мене є підсумок в кінці, тому просто переходьте до резюме, якщо вам не завадить читати всю справу!

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

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

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

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

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

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

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

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

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

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

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

Дізнайтеся очевидні ознаки слабких оцінок:

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

• Грубозернисті оцінки (тобто завдання довше, ніж на пару днів).

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

• Оцінки, складені іншими людьми, ніж фактичні виконавці

• Неясні оцінки (не зрозуміло, що включено, і що не менш важливо, виключено).

• Суттєва різниця в порядку величин завдань.

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

Підсумовувати:

• Не покладайте на це жахливої ​​чи будь-якої оцінки з цього приводу, перш ніж у вас з’явилася можливість зробити належну ретельність.

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

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

• Будьте готові захистити свою оцінку.

• Дізнайтеся, як оцінювати оцінки інших людей, щоб не потрібно брати на себе великі неточні цифри.

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

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

Ніхто не знає "правильної" відповіді. І поки це не буде зроблено, ніхто не дізнається.

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

Оцінка - пастка - це сфальсифікована гра. ви не можете виграти, ви не можете зламати рівних і навіть не можете вийти з гри.

Редагувати

Справа з поганими оцінками; Оцінка "спадщини", яка виявляється неправильною .

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

Це так само ймовірно, що ваші припущення такі ж неправильні, як і їхні припущення. Не менш вірогідний.

На запит оцінити .

1. Ви будете помилятися.

   1. Вони брешуть про масштаби роботи.

   2. Ви не знаєте продуктивності команди.

   3. Яка б нова технологія не стосувалася, вона була представлена ​​неправильно.

2. Ви не можете просто кинути набивки, щоб покрити ці речі випадковим чином. Ви насправді не знаєте і не маєте основи для "оцінки". Це просто здогадки. Закінчуй з цим.

Правило 1: Оскільки ви лише здогадуєтесь, здогадуйтесь невеликими кроками.

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

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

Правило 2: Підтримуйте особу, яка приймає рішення, фактичну інформацію.

Більшість людей найкраще обслуговує спритний підхід. Перший реліз - через місяць - займе 5 людей × 4 тижні, і він отримає функцію X, яка фіксує втрати на 1 мільйон доларів на день та функцію Y, яка виправляє пропущені можливості в 200 000 доларів на тиждень. Ви маєте детальні знання про те, що робите, тому цей прогноз має сенс. Випуск після цього трохи туманний.

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

Коли вони запитують, що таке ТСО, ви повинні бути чесними. "Загальна вартість виникає, коли ви перестаєте платити за розвиток. Доки ви не перестанете платити, ви завжди будете нести витрати".

Справжнє питання - "які проблеми ви намагаєтеся виправити?" або "яку нову можливість ви шукаєте?" і "чого це варто?"

Правило 3: Зробіть програмне забезпечення менш дорогим, ніж проблему, яку він повинен вирішити.

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

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

Немає ймовірності вивчити речі та змінити область застосування. Це певність.

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

"Планування" - це звичайне хороше управління.

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

Якщо оцінка була на 500%, а проект все-таки продовжувався, яке значення має оцінка?

Немає. Все, що вона робила, робило людей нещасними. Але проект все одно йшов вперед.

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

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

Не дозволяйте плану стати єдиною «священною правдою» в проекті. Функціонал, який можна отримати, є священним. Все інше має змінюватися у міру зміни результатів.

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

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

"Розробники - це майстри, і найгірше, що ви можете зробити майстрам - це змусити його доставити шалений продукт". Відома цитата звідкись, але я не можу згадати, звідки.

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

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

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

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

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

Моя команда проводила ночі, щоб закінчити проект. Пізно однієї ночі близько 3:00 ранку (я працював 19 годин прямо) я надіслав електронним повідомленням своїм менеджерам, щоб зробити щось із цим.

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

Вся команда (навіть якщо вони не беруть участь у проекті) перевірила програму та допомогла у швидкому виправлення помилок.

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

Моя єдина порада була б "Поговоріть з менеджером. Скажіть їм, що проект не може бути доставлений вчасно. Також дайте їм альтернативу. Менеджер завжди очікує, що дитина буде доставлена ​​вчасно, незалежно від того :)"

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

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

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

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

Можливо, вас зацікавить ця стаття про IEEE, про яку я раніше блогував . Ось основні моменти.

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

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

Тоді я спробую зайти до вашого лінійного менеджера / менеджера проекту та обговорити його з ним / ними.

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

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

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

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

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

https://stackoverflow.com/questions/541873/developing-on-for-a-moving-target

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

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

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

Це гра керованих очікувань.

Проблема полягала не в тому, що початкові кошториси не були - це те, що керівництво вам не повірило.

Найкращий спосіб змусити менеджмент прийняти рішення:

1. Окресліть проблему із доказами, щоб її підтвердити; і
2. Надайте для них декілька рішень (для того, щоб принаймні кращі до найбільш переважних).

Для (1) впровадження програми Scrum і відстеження фактичних даних проти химерних оцінок добре працює для резервного копіювання ваших претензій.

Для (2) одним із моїх варіантів буде "Розробити пріоритетний список функцій з клієнтом (він же" Блокування продукту "в Scrum). Це може бути складним для організацій з фіксованою ціною чи високо бюрократичних організацій, але це можливо .

Сподіваюся, що це допомагає!

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

Як згадував Том - за день існує лише стільки часу. Навіть якщо ти не спиш.

Три речі, я думаю.

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

Я думаю, що крім управління очікуваннями та прозорості у вашому навантаженні, інша велика річ - це управління сферою . Існує велика область між аналом / образливістю в тому, щоб бути прицільним нацистом, і охоплювати власний хвіст. Коли хтось хоче цієї додаткової функції чи функціональності - погоджуйтесь на це! А потім дати їм досить точну оцінку того , скільки часу , що додасть до проекту Перевагою цього є не тільки (або в наступному випуску.) Чи не зубріння себе в іншій 80 годин в тиждень - ви отримаєте деяку площадку в цій оцінці теж можливо наздогнати іншого.

Удачі!

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

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

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

Мати обертові двері людей, які намагаються вирішити це, буде для них куди гірше.

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

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

Що я тут би робив - це взяти кількість часу, який я маю, і витратити його так розумно, як тільки можу. Визначте пріоритети замовника та поставте їх. Дев'ять із десяти разів замовник буде задоволений тим, що його основні пріоритети були виконані, і не помітить 80% роботи, яка не була виконана.

Останнє, що ви хочете зробити, - це закликати до екстрених зустрічей і звинувачувати людей у ​​злі. Ти кажеш:

"нехай пізнають реальність"

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

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

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

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

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

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

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

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

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

Я думаю, що недостатньо оцінювачів не приділяють достатньо уваги фактам "Оцінка - це ти просиш мене зробити математику та здогадки, щоб передбачити майбутнє корисним способом" та "Зобов'язання, яке ми беремо на себе, є повністю окремим від математики, яку ми робимо зробіть оцінку; ми можемо погодитись робити дурні обсяги роботи, погоджуватися на речі, які ми бачимо, що ми, мабуть, не можемо закінчити, але жодне з них насправді не змінить математику рішення "та" Ми можемо робити методики розвитку, які не є гігантськими пакет функцій A буде зроблено до дати B, що робить збій набагато менш імовірним "

Багато оцінок приведені мовою переговорів. Їх потрібно купірувати мовою математики і говорити про невизначеності математики .

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