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

На предыдущей работе менеджер проекта (PM) не был удовлетворен временем доставки кода для проекта, на котором я работал. Мой руководитель проекта сказал мне, что премьер-министр рассматривает вопрос о том, чтобы я подписал контракт, чтобы зафиксировать свои оценки времени, которые я дал для задач и сроков поставки.

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

Да, я пропустил большинство сроков. И я работал над некоторыми совершенно новыми технологиями, которые никто из всей команды разработчиков не мог бы реально помочь, потому что они не были бы знакомы с этим. По крайней мере, не легко.

Тогда мне казалось, что премьер-министр хочет, чтобы его цифры складывались, и, таким образом, хотел, чтобы я подписал контракт, чтобы «гарантировать», что я всегда буду доставлять рабочий код вовремя. Я полагаю, что с подписанным контрактом премьер-министр может использовать его против меня, если я не смогу выполнить его вовремя.

Я верю, что потом произошло то, что другие менеджеры проектов и / или руководители проектов защищали меня и не позволили этому случиться.

Мой вопрос, это должно поднять красный флаг о менеджере? Является ли обычной практикой для менеджера фиксирование временных оценок разработчика программного обеспечения с подписанным контрактом? Или в этом случае попробуйте.

Обратите внимание, я был штатным сотрудником, а не независимым консультантом.

Обновление : я хочу добавить, что я давал новые оценки еженедельно, но кажется, что первоначальные оценки и даты поставки были тем, на чем был сосредоточен премьер-министр.

Мой вопрос, это должно поднять красный флаг о менеджере?

Да . Это значит, что пришло время обновить свое резюме и начать искать новую работу. Или это означает, что ваш менеджер собирается начать играть с вами в некоторые очень неприятные игры .

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

Я никогда не слышал, чтобы это применялось к сотруднику.

Оценка времени и усилий всегда трудна. Тем более что наша профессия полна чрезмерного оптимизма. Существуют некоторые системы оценки, которые могут помочь с оценками в будущем, но они должны собирать статистические данные от вас самих. Одним из них является PSP . Другое - это функциональные точки . Многим разработчикам не нравится ни один, и вы найдете очень сильные мнения против них обоих.

Основная трудность в оценке времени и усилий заключается в отсутствии обратной связи в нашей оценке эвристики. Один из ключей заключается в том, чтобы записать, как вы оцениваете оценку, и какие параметры вы использовали для ее оценки. Затем, основываясь на том, что вы действительно сделали, сравните это с тем, что, как вы думали, вы сделаете. И используйте это, чтобы изменить ваши параметры оценки. В машиностроении мы называем это « обратной связью ».

Да, это должно звучать абсолютно точно.

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

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

Одно изменение в спецификации => контракт является недействительным. Вероятно, вещь будет недействительной только через 10 минут в ваш первый день :)

Да, это красный флаг. Это говорит вам о том, что менеджер не понимает, как управлять рисками в программных проектах. Что он должен делать, так это выяснить, что именно вызвало задержку, а затем начать инструктировать процесс для эффективного управления рисками графика, которые неизбежно произойдут во время проекта программного обеспечения.

НИКОГДА ни при каких обстоятельствах я не подпишу контракт с моим менеджером, гарантирующий график. Другие упоминали, что он подписал контракт со спецификациями. Это на мой взгляд не достаточно. Это не учитывает непредвиденные трудности с инструментами или технологией, неполный или плохой дизайн, производительность других членов команды и т. Д.

Это не красный флаг, это оружейная глупость.

Если оценки и сроки постоянно нарушаются, рациональным решением является выявление причин и улучшение процессов.

Если вы обвиняете и пинаете лошадь, потому что не знаете, куда идете, не удивляйтесь, если лошадь вас укусит и убежит!

В то время как менеджер не соответствует его требованию. Он не полностью виноват. Если вы работали на совершенно незнакомой территории, нет ничего плохого в том, чтобы сказать «я не знаю». Мне потребовалось некоторое время, чтобы понять, что «я не знаю» - вполне приемлемый ответ, поэтому я знаю, как сильно жаль произносить эти слова. Но если вы действительно не знаете, то это ответ. И если они откажутся от этого, попросите их дать вам оценку того, сколько пенни потребуется, чтобы сделать стопку такой же высокой, как Башня Сирс (сделайте это Уиллисом). И будут ли они готовы подписать контракт, выплачивая вам каждый пенни?

Любой руководитель проекта, достойный его зарплаты, должен знать, что некоторые вещи не вписываются в таблицу. Иногда дела сделаны, когда они сделаны. Я думаю, что вы преуспеваете, давая успехи в том, как много вы сделали. Просто прекратите давать обновления номера.

Другое упражнение состоит в том, чтобы разбить большую задачу на более мелкие и более ценные единицы. Это упражнение поможет вам лучше понять, что вам нужно делать. Ознакомьтесь с оценками программного обеспечения Стива Макконнелла и шаблонами требований к программному обеспечению Стивена Солла, чтобы получить советы по разбивке задач и обнаружению скрытых требований, соответственно.

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

Спросите своего «менеджера проекта»: мы продаем программное обеспечение или сроки?

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

Прежде чем я начну, обратите внимание, что премьер-министр, скорее всего, вызывает у вас горе, потому что кто-то еще, находящийся дальше по пищевой цепи, дает им горе. Они (мы) простые существа ... Есть способы избежать ситуации, которую вы описали - Майк Браун довольно хорошо это освещает. Также нет ничего плохого в том, чтобы что-то делать в течение 3/4/5 .. часов прямо перед тем, как сработать (фактически, все виды аварийных сигналов должны сработать, если этого не произойдет). И если вы собираетесь на неизвестную территорию, отодвиньтесь и попросите неделю, чтобы исследовать область и технологии, чтобы иметь возможность сделать разумную оценку (вы хотите сделать это правильно, потому что вы хотите, чтобы новые технологии изучались и играли с Доном. не так ли?) Если ваш руководитель и администрация в том месте, где вы находитесь, не понимают этого ... обновите свое резюме и найдите ближайший выход, оставив их на произвол судьбы, которых они так заслужили. То, что премьер-министр даже подумает о том, чтобы заставить штатного сотрудника подписывать такой контракт, является плохим плохим знаком ... единственный способ, которым я мог видеть, что ониможет быть не совсем некомпетентным является то, что они действительно просто играли в интеллектуальные игры с вашим руководителем проекта и вами (из того, что я читал, они не говорили об этом непосредственно вам и в конечном итоге не реализовали угрозу). В конце концов, PMing - это рай для вашего стандартного корпоративного психопата. Это было хорошо, что другие пошли в тупик из-за того, что ты сказал, поэтому приведенный ниже совет, вероятно, в конечном итоге оказался бы для тебя положительным. Я предполагаю, что у них была бы революция в их руках, если бы это оказалось чем-то большим, чем просто разговор.

Итак, к реальной ситуации / дыре, которую вы описали , потому что это случится снова с кем-то, где-то (например, около 5 минут назад, и снова через 5, scheduleRepeat ()). Вероятно, без контракта глупости, но основная сюжетная линия всегда одинакова. Организуйте встречу (!), Им нравятся встречи ;-) каждый может похлопать себя по спине в конце, как будто что-то действительно было сделано. ВАЖНЫЙ:Убедитесь, что вы включили своего технического руководителя / руководителя группы / архитектора / дизайн-менеджера в приглашение на встречу, уже обсудив с ними проблему и получив их на борт. Чем выше иерархия, вы можете пойти на кого-то на вашей «стороне», тем лучше. Потому что ваш премьер увидит это и попробует сопоставить вашего менеджера по дизайну с аналогом. Если нет, они тупые, а ты уже выиграл. Это само по себе, как правило, подтягивает их обратно в линию, потому что теперь они видны кому-то, кто, вероятно, может уволить их на месте. Если они играют в игры с вами, вы можете вернуть услугу.

На собрании рассмотрите технические детали того, с чем вы имеете дело, и почему на это уходит время. Они должны хотеть знать это (и как они могут помочь вам сделать это), но печальный факт, как правило, этого не происходит ... вы, вероятно, получите 10 минут, прежде чем их глаза закатятся в их голову. То, что я хотел бы сделать здесь, вероятно, не является законным ... да, я проверил, это на самом деле очень незаконно, и вы не хотите так долго сидеть в тюрьме. Суть в том, что вы приложили максимум усилий, чтобы проявить инициативу, и если у вас есть некоторые высокопоставленные лица, ваша боль теперь их ... как и должно быть. Вы должны будете использовать свое суждение о том, как все может закончиться, потому что «эскалация» - это то, что произойдет. Если руководство в том месте, где вы находитесь, наполовину прилично, они поступят правильно, и поступай правильно с тобой. Если нет, то вы бы заранее разместили свое резюме на рынке ... вы все равно ушли бы при первой же возможности (и похоже, что в конечном итоге вы это сделали). Руководство разделится на две группы - либо они технически подкованы, и они сразу же увидят вашу точку зрения; или нет, и что они будут делать с этим, кроме как ухмыляться и нести это? Если бы они могли делать то, что вы делаете, то они уже сделали бы это. t и что они собираются делать с этим, кроме улыбки и терпения? Если бы они могли делать то, что вы делаете, то они уже сделали бы это. t и что они собираются делать с этим, кроме улыбки и терпения? Если бы они могли делать то, что вы делаете, то они уже сделали бы это.

Сохраняйте проблему изменяющихся требований в качестве своей козырной карты для использования в конце ... она послужит выходом для всех. Сам проект и проклятый клиент / заинтересованная сторона получат свое имя напрасно. Самый безболезненный путь вперед - это своего рода перезагрузка проекта, и, возможно, этот премьер-министр будет тихо переназначен в другую область. Чудеса случаются время от времени. Если вопрос о встрече был поднят на встрече премьер-министром, тогда ответьте на требования о замораживании встречного контракта - насколько я понимаю, они уже сожгли свои мосты с вами и со всей командой разработчиков, когда они начали играть в такие игры разума.

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

О, еще одна вещь: в заявлении «Я не знаю» всегда была моя личная оценка того, как измерить ценность коллеги-технолога или члена одной из моих проектных команд. Я считаю, что единственные люди, которые могут сказать, что прямое лицо - это лучшее, что есть, в первую очередь потому, что кто-то, кто знает, что они не в своей глубине, никогда не скажут этого - открывают их для того, чтобы их можно было четко разоблачить кому-то, у кого есть реальные способности в сердцебиение С другой стороны, кто-то, кто выступит и скажет это, также будет иметь основной план (даже если он не был обдуман) о том, как справиться с неизвестными, чтобы через 24 часа был более полезный ответ, и через неделю еще лучше. Когда Аполлон-13 летал вокруг темной стороны Луны, произошла целая куча «Я не знаю».

Да, это должно поднять красный флаг, особенно если вы работаете на полную ставку. Какие были условия договора? Вы бы на самом деле были уволены, если бы вы пропустили сроки? Или вы просто пропустите бонус? Что они будут делать?

Флаг, который это поднимает, заключается в том, что менеджер не знает, как управлять проектом, работающим с новыми / незнакомыми технологиями и меняющимися требованиями, которые напрямую влияют на оценку усилий. Хотя иногда случаются жесткие сроки, менеджер, который знает ситуацию, не должен пытаться заставить сотрудников подписывать контракты для их обеспечения. Поздние ночи и время хруста будут плохими, но это, вероятно, вполне естественно. И все же иногда крайний срок сдвигается. Это происходит, и, как кто-то другой опубликовал, единственный способ придерживаться графика - заморозить требования РАНЬШЕ, чтобы было достаточно места, чтобы сохранить график.

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

Тем не менее, я согласен с другими ответами. Кроме того, вы можете обновить свое резюме, если вы еще этого не сделали.

Как и все остальные респонденты, я не мог согласиться с тем, что это должно поднять красный флаг.

Кажется, премьер-министр не хочет участвовать в процессе разработки.

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

Причиной этого является осознание того, о чем говорят многие гуру Agile и Lean Software, что программное обеспечение не является фиксированным производимым объектом, но в основном это процесс открытия.

У многих людей все еще есть проблемы с этим понятием, и похоже, что ваш премьер тоже. Все сводится к простому пониманию компромиссов.

Жесткие предварительные спецификации и фиксированные оценки работают для систем, где стоимость изменений высока. Как строить многоэтажку. Если вы забыли заранее спроектировать шахты лифта, тогда будет очень сложно дооснастить здание, как только оно будет возведено. Высокая стоимость изменений требует большого предварительного планирования, изучения неизвестных компонентов и технологий и предварительных экспериментов. Только после того, как вы сделали всю эту домашнюю работу, вы можете оценить бюджет и стоимость.

В области программного обеспечения люди очень привыкли к мысли, что стоимость изменений невелика, и поэтому им нравится пользоваться возможностью изменять вещи после того, как они увидят релиз, включая новое понимание приложения, бизнеса, клиента на на постоянной основе. Все это хорошо и огромная возможность при правильном использовании. Большинство разработчиков программного обеспечения, с которыми я встречался и работал, на самом деле не любят тратить много времени на планирование или расследование; большинство из нас (включая премьер-министра) хотят видеть текущую тягу. Вот откуда пришла итеративная разработка с небольшими, постепенными выпусками функциональности. Есть и другие методы, которые можно использовать, такие как разработка через тестирование, чтобы гарантировать, что стоимость изменений остается низкой, а технический долг ограничен.

Выполнение этой работы подразумевает «контракт» между обеими сторонами, владельцем продукта (Agile, выступающий за вашего руководителя или клиентов или команду QA) и разработчиками. Разработчики соглашаются работать только над тем, что было расставлено по приоритетам как наиболее важное для данной итерации, и не продолжать с этим навсегда, но стремиться выпускать полностью интегрированные блоки функциональности часто (например, еженедельно или ежемесячно). Владельцы продуктов, наоборот, соглашаются постоянно просматривать инкрементные выпуски и предоставлять оперативную обратную связь. Они также соглашаются установить приоритеты для следующей итерации и однажды принять решение не менять свое мнение в течение всей итерации.

Эта последняя часть соглашения - то, что ваш премьер-министр, вероятно, не понимает. Многие традиционные PM на самом деле нет. Некоторые из них думают, что их работа сделана, когда они отказываются от спецификации; они не хотят слышать о проблемах, альтернативах, лучших путях и т. д. Недостатком является то, что это не только противодействует потоку разработки программного обеспечения, но и наносит ущерб организации, оставляя много возможностей на столе.

Взгляните на Agile Manifesto: http://agilemanifesto.org/ Это может резонировать с вами. Хорошей книгой для чтения является также «Попугая разработка Мэри» Мэри Поппендик.

Удачи.

Звучит так, будто менеджер ищет кого-то в этом виноват, когда он сообщает своему начальнику.

Я считаю, что если у вас есть необоснованный менеджер, который считает, что «оценка» совпадает с «фиксированным периодом», то лучше всего подумать об очень щедром периоде оценки, а затем удвоить его!

Также заставьте менеджера убедиться, что требования полностью детализированы и исправлены. Любые изменения с этого момента не будут рассматриваться без «формального пересмотра» с менеджером проекта нового времени завершения.

В конце концов, руководитель проекта получает идею и планирует соответственно.

Мой личный опыт с такими вещами заключается в том, что менеджер проекта пытается настроить бумажный след, чтобы избавиться от вас, в то же время делая ваше увольнение по вашей собственной вине. Это сделало бы это очень красным флагом. Ваш пробег может, конечно, несколько отличаться.

Хорошие ответы повсюду, но позвольте мне добавить свои 2 цента.

Если вы когда-либо изучаете вероятность, существует такая вещь, как «случайная величина». Это число, значение которого вы не знаете, но вы можете описать свое незнание с помощью распределения, такого как нормальное распределение (кривая колокольчика) или другое.

Дело в том, что работа займет определенное количество времени, но любая предварительная оценка будет неправильной, в некоторой степени, отрицательной или положительной, так что риск есть, и кто-то должен рискнуть. Как правило, если люди рискуют, им платят за это. Страхование стоит денег.

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

Запрос о назначении фиксированной даты поставки, особенно без фиксированных требований, звучит как попытка передать вам риск, даже если неясно, чем вы на самом деле рискуете. В любом случае, один из ответов - просто ввести действительно щедрый запас прочности.

PS Вы видите это все время с правительственными контрактами. Есть первоначальный запрос предложений, сделаны предложения, принята низкая цена, а затем начинают поступать запросы на изменение, поэтому стоимость увеличивается, и подрядчик обвиняется. Все работает намного лучше, если между клиентом и подрядчиком существуют командные отношения, а не состязательные.

Да, конечно, это поднимает флаг об опыте и компетентности вашего бывшего босса. Да, как и предполагало большинство людей, сейчас самое время обновить свое резюме.

Да, как говорится в других ответах, в большинстве случаев вы не захотите подписывать это соглашение. Тем не менее, я хочу предположить, что в некоторых ситуациях вы можете подумать о подписании.

Большинство разработчиков и менеджеров знают о постоянном трении между функциональностью, сроками и бюджетом. Многие также называют качество четвертым измерением («Я могу предложить любой набор требований к завтрашнему дню с небольшим бюджетом, если вы готовы признать, что это не сработает!»)

Но есть еще одно измерение: риск. Если мне нужно только успешно выполнить поставку в 50% случаев, я могу значительно снизить свои оценки; они дополняются, чтобы справиться с гораздо более высокой скоростью доставки.

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

Если вы можете назначить свой крайний срок, с взаимно приемлемым количеством отступов, чтобы справиться с неожиданными задержками, и можете договориться о (очень большом) бонусе, если вы его нажмете, и у вас есть финансовое положение, чтобы справиться с штрафы (например, увольнение), если вы не можете, вы можете найти, что стоит рискнуть, чтобы принять этот риск на себя и подписать контракт с подходящими условиями для обработки изменений требований.

Это просто глупость. Я не знаю, какова была конечная цель, но каждый наполовину порядочный руководитель проекта, ответственный за программные продукты, должен знать, что оценки - это именно то, что они называют: оценки. Они не являются обещаниями, и их нельзя сделать такими, не потратив разработчика программного обеспечения всей своей энергией или не заставив их нарушить свое «обещание» в любом случае.

Если вы хотите показать, насколько нелепым является такой контракт, здесь может быть два предложения:

а) Высокая переоценка до такой степени, что проект занимает в пять или десять раз больше времени, чем вы оценили бы без контракта. Если менеджер проекта спрашивает, почему оценки так высоки, просто скажите, что вы просто уверены, что сможете выполнить свой контракт.

б) Это уже было предложено: попросите контракт, который гарантирует, что ни одно требование не изменится, и убедитесь, что это включает исправление орфографических ошибок. По моему опыту, нет ни одного программного проекта, где требования не меняются в какой-то момент в процессе разработки. Руководитель проекта с большей вероятностью нарушит свой контракт, чем вы.

Если руководитель проекта согласится с любым из этих двух предложений, вы наверняка будете знать, что они не в своем уме.

Кстати, как же будет работать контракт на штатного сотрудника? Я не знаю о правилах работы в других странах, но, работая на полную ставку в компании, я не думаю, что кто-либо может заставить вас подписать обязывающий контракт, чтобы уложиться в срок и иметь действительное дело. Конечно, они могут принести вам ад, если вы не уложитесь в срок, но для этого им не нужен контракт. Никто не может уволить вас или дать вам меньше денег. Они могут сократить ваш согласованный бонус в худшем случае. Таким образом, если в других странах это не отличается, это больше похоже на пустую угрозу, чем на все, что вы должны воспринимать всерьез.

Я собираюсь пойти против зерна здесь.

Ситуация, которую вы описываете, не так уж необычна на уровне команды инженеров , особенно после особенно позднего проекта / релиза. Во многих ситуациях ваше руководство и вся ваша организация фактически могли подписаться на определенную дату выпуска, и другие части организации будут подготовлены к этой дате. Может быть огромное давление на вашу цепочку управления, чтобы достичь этой даты.

Вот тут-то и начинается общий инженерный процесс. Вы, наверное, слышали о модели водопада. Существуют и другие модели, но конечной целью всех них является последовательное предоставление чего-либо, когда это ожидается и содержит то, что было согласовано. Функциональные спецификации, проекты, списки задач и т. Д. Делают этот процесс предсказуемым. Коммуникация, анализ рисков и (как вы сказали) регулярное обновление ожиданий относительно графика сокращают количество сюрпризов и делают информацию доступной как можно скорее, чтобы планы могли быть скорректированы. И да, должны быть внесены коррективы в план всякий раз, когда функции добавляются или удаляются.

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

Я говорю, поставьте себя на его место и попытайтесь понять, что мотивировало это. С точки зрения менеджеров / бухгалтеров, им нужен номер, чтобы объяснить, что происходит и как идут дела.

Возможно, он был высмеян в зале заседаний за смещение сроков, пропустив слишком много сроков, и он попытался найти самый простой способ заблокировать их. Дайте мне номер и подпишите здесь! Вы, находясь на другом конце, могли только понять, что это что-то против вас. Однако, когда он делает оценки и понимает, что их необходимо скорректировать, он является для него более полезным. Если вы понимаете, что послужило причиной запроса и с какой реальной проблемой он сталкивается, вы сможете помочь ему и себе. Как программисты мы решаем проблемы. Это ничем не отличается, понять и решить его проблему, и он будет вашим лучшим другом. Так много работы предстоит сделать, что ни у кого нет времени на то, чтобы подготовить личную вендетту! Ему нужна помощь в работе, самое простое решение - подписать бумагу! Вероятно, он получил это из книги руководства для манекенов: «Пусть ваши работники подпишутся и будут нести ответственность за число». Смешно но грустно

«Ходить по воде и разрабатывать программное обеспечение по спецификации легко, если оба они заморожены».

Эдвард В. Берар

Если ваши требования меняются, то не стоит ожидать, что ваши первоначальные оценки будут точными. Да, это должен быть красный флаг.

Есть ли в договоре штраф за несоблюдение сроков? Если это не так, это совсем не проблема - вы просто подписываете оценку, основанную на ваших знаниях на тот момент.