Керівник проекту, який хоче зафіксувати часову оцінку за підписаним контрактом

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

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

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

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

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

Моє запитання: чи повинно це підняти червоний прапор щодо менеджера? Чи звичайна практика для менеджера фіксувати часові оцінки розробника програмного забезпечення за підписаним контрактом? Або в цьому випадку спробуйте.

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

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

Моє запитання: чи повинно це підняти червоний прапор щодо менеджера?

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

Чи звичайна практика для менеджера фіксувати часові оцінки розробника програмного забезпечення за підписаним контрактом?

Я ніколи не чув, щоб це було застосовано до працівника.

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

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

Так, це повинно абсолютно звучати дзвони тривоги.

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

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

Одна зміна spec => договору недійсна. Можливо, річ буде недійсною вже через 10 хвилин у перший день :)

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

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

Це не червоний прапор, це дурне озброєння.

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

Якщо ви звинувачуєте і б'єте коня, бо не знаєте, куди їдете, не дивуйтеся, якщо кінь кусає вас і тікає!

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

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

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

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

Запитайте свого «менеджера проекту»: чи продаємо ми програмне забезпечення або терміни?

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

Перш ніж я розпочну, хоча зауважте, що прем'єр-міністр, швидше за все, доставляє вам горе, тому що хтось інший за харчовим ланцюгом доставляє їм горе. Вони (ми) - прості істоти ... Є способи уникнути описаної вами ситуації - Майк Браун досить добре висвітлює це. Немає нічого поганого і в тому, щоб щось зайняти 3/4/5 .. години прямо перед тим, як розпочати його (насправді всі сигнали тривоги потрібно вимкнути, якщо цього не відбувається). А якщо ви їдете на невідому територію, відштовхуйтесь і попросіть тиждень дослідити область та технології, щоб можна було зробити обґрунтовану оцінку (ви хочете зробити це належним чином, оскільки ви хочете, щоб нові технології навчалися та грали з доном ти?). Якщо ваш прем'єр-міністр та керівництво в місці, де ви перебуваєте, цього не розуміють ... тоді оновіть своє резюме та шукайте найближчий вихід, залишаючи їх долі, яку вони так сильно заслуговують. Що прем'єр-міністр навіть подумає про те, щоб отримати штатного працівника для підписання такого контракту - це поганий поганий знак ... єдиний спосіб я бачив, що вониможе бути не зовсім некомпетентним є те, що вони насправді просто грали в розумові ігри з керівництвом вашого проекту, і ви (з того, що я прочитав, вони не передавали це вам безпосередньо, і в кінцевому рахунку не переслідували загрозу). Зрештою, PMing - притулок для вашого стандартного корпоративного психопата. Було добре, що інші, хто говорив за вас, пішли з вашої уваги, тому поради нижче, напевно, виявились б позитивними для вас. Я думаю, вони мали би революцію на руках, якби це виявилося більше, ніж розмова.

Тож до реальної ситуації / дірки, яку ви описали , тому що це повториться з кимось десь (як, наприклад, 5 хвилин тому, і знову в іншій 5, графік повторити ()). Можливо, без контракту дурість, але основна сюжетна лінія завжди однакова. Організуйте зустріч (!), Їм подобаються зустрічі ;-) кожен може погладити себе по спині, як щось було насправді. ВАЖЛИВО:Переконайтеся, що ви включили свого керівника технічного проекту / керівника / архітектора / керівника дизайну до зустрічі, запросивши його вже розібратися з проблемою та взяти їх на борт. Чим вище вгору за ієрархією ви зможете перейти на когось із вашої "сторони", тим краще. Тому що ваш прем'єр-міністр це побачить і спробуйте узгодити свого менеджера з дизайну з аналогічним. Якщо ні, то вони німі, і ви вже виграли. Це само по собі, як правило, поверне їх у відповідність, тому що тепер їх видно тому, хто, можливо, може їх звільнити на місці. Якщо вони грають з вами в ігри, вам дозволяється повернути послугу.

На зустрічі ознайомтеся з технічними подробицями того, з чим ви маєте справу і чому це займає час. Вони повинні хотіти знати про це (і як вони можуть допомогти вам це зробити), але сумний факт, як правило, цього не відбувається ... ви, ймовірно, отримаєте 10 хвилин, перш ніж їх очі відкинуться в голову. Тепер те, що я хотів би зробити тут, мабуть, не є законним ... так, я перевірив, це фактично протизаконно, і ви не хочете так довго їхати до в'язниці. Справа в тому, що ви доклали максимум зусиль, щоб бути ініціативними, і якщо у вас є якісь вищі навчальні центри, ваш біль тепер їхній ... як і має бути. Вам доведеться скористатись судженням про те, як все ймовірно розіграється, тому що відбудеться "ескалація". Якщо керівництво на місці, де ви знаходитесь, наполовину пристойне, вони зроблять правильно, і робиш правильну справу і ти. Якщо ні, то ви б заздалегідь отримали своє резюме на ринку ... у будь-якому випадку ви збиралися виїхати при першій же можливості (і виглядає так, як у кінцевому підсумку). Керівництво поділиться на дві групи - або вони технічно підковані, і вони моментально побачать вашу точку зору; або вони ні, і що вони зроблять з цим, окрім усмішки і нести це? Якби вони могли робити те, що ти робиш, то вони б уже робили це. т і що вони будуть робити з цим, окрім як посміхнутися і нести? Якби вони могли робити те, що ти робиш, то вони б уже робили це. т і що вони будуть робити з цим, окрім як посміхнутися і нести? Якби вони могли робити те, що ти робиш, то вони б уже робили це.

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

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

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

Так, це повинно підняти червоний прапор, особливо якщо ви штатний працівник. Якими були умови контракту? Чи насправді ви звільнили б, якби пропустили терміни? Або ви просто пропустите бонус? Що б вони робили?

Цей прапор підкреслює, що менеджер не має уявлення, як керувати проектом, що займається новими / незнайомими технологіями та зміною вимог, що безпосередньо впливають на передбачувані зусилля. Хоча іноді трапляються жорсткі терміни, керівник, який знає ситуацію, не повинен намагатися змусити працівників підписувати договори для їх виконання. Пізні ночі та час хрускіт будуть погані, але це, мабуть, однаково для курсу. І все одно іноді термін проскочить. Це трапляється, і, як хто-небудь інший, розміщений, єдиний спосіб дотримуватися розкладу - заморозити вимоги НАРОДНО ВКЛЮЧЕНО, щоб було ще достатньо місця для збереження часової шкали.

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

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

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

Схоже, прем'єр-міністр не хоче брати участь у процесі розробки.

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

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

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

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

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

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

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

Погляньте на маніфест Agile: http://agilemanifesto.org/ Він може резонувати з вами. Гарною книгою для читання є також «Постійна розробка програмного забезпечення» Мері Поппендієк

Удачі.

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

Я знаходжу, якщо у вас є нерозумний менеджер, який вважає, що "оцінка" є такою ж, як "фіксований період", найкраще робити - придумати дуже щедрий період оцінки, а потім подвоїти його!

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

Врешті-решт менеджер проекту отримує ідею та відповідно планує.

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

Хороші відповіді навколо, але дозвольте додати свої 2 копійки.

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

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

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

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

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

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

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

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

Але є ще один вимір: ризик. Якщо мені потрібно успішно поставити лише 50% часу, я можу значно знизити свої оцінки; вони підбиті, щоб обробити набагато більшу швидкість доставки.

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

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

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

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

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

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

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

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

Я йду сюди проти зерна.

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

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

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

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

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

"Ходити по воді та розробляти програмне забезпечення із специфікації легко, якщо обидва заморожені".

-Едвард В. Берард

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

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