Gerente de projeto que deseja bloquear a estimativa de tempo com um contrato assinado

Em um emprego anterior, um gerente de projeto (PM) não estava satisfeito com o tempo de entrega do código em um projeto em que eu estava. Foi-me dito pelo líder do meu projeto que o PM estava pensando em me assinar um contrato para fixar minhas estimativas de tempo que eu dei para tarefas e datas de entrega.

A situação no projeto era que estávamos trabalhando com novas tecnologias, base de código, padrões de codificação e requisitos muito propensos a alterações. Eu estava aprendendo coisas novas e aplicando-as da melhor maneira possível nos requisitos que continuavam mudando. Os requisitos ao longo das iterações aumentaram 2-3 vezes, com minha estimativa de conclusão crescendo aproximadamente 5-8 vezes. As únicas coisas que não mudaram foram as estimativas e as datas de entrega.

Sim, acabei perdendo a maioria dos prazos. E eu estava trabalhando em algumas tecnologias muito novas que ninguém na equipe de desenvolvimento inteira poderia realmente ajudar, porque eles não estariam familiarizados com isso. Pelo menos não facilmente.

Pareceu-me então que o primeiro-ministro queria que seus números aumentassem - e, assim, queria que eu assinasse um contrato para "garantir" que eu sempre entregaria código de trabalho a tempo. Suponho que, com um contrato assinado, o MP possa usá-lo contra mim se não puder cumprir o prazo.

Acredito que o que aconteceu depois foi que outros gerentes de projeto e / ou líderes de projeto me defenderam e não deixaram isso acontecer.

A minha pergunta é: isso deve levantar uma bandeira vermelha sobre o gerente? É prática comum para um gerente bloquear estimativas de tempo de um desenvolvedor de software com um contrato assinado? Ou, neste caso, tente.

Observe que eu era funcionário em período integral, não consultor independente.

Atualização : quero acrescentar que forneci novas estimativas semanalmente, mas parece que as estimativas originais e as datas de entrega foram as fixadas no PM.

A minha pergunta é: isso deve levantar uma bandeira vermelha sobre o gerente?

Sim . Isso significa que é hora de você atualizar seu currículo / currículo e começar a procurar um novo emprego. Ou isso significa que seu gerente está prestes a começar a jogar alguns jogos muito desagradáveis com você.

É prática comum para um gerente bloquear estimativas de tempo de um desenvolvedor de software com um contrato assinado?

Eu nunca ouvi falar disso sendo aplicado a um funcionário.

A estimativa de tempo e esforço é sempre difícil. Especialmente porque nossa profissão é cheia de otimismo excessivo. Existem alguns sistemas de estimativa que podem ajudar com estimativas no futuro, mas eles precisam coletar estatísticas históricas suas. Um é o PSP . Outro são os pontos de função . Muitos desenvolvedores não gostam de nenhum deles, e você encontrará opiniões muito fortes contra os dois.

A principal dificuldade na estimativa de tempo e esforço é a falta de feedback em nossas heurísticas de estimativa. Uma das chaves é anotar o que você acha que é a estimativa e quais parâmetros você usou para estimar. Em seguida, com base no que você realmente fez, compare isso com o que você pensou que faria. E use isso para modificar seus parâmetros de estimativa. Em engenharia, chamamos isso de " feedback ".

Sim, isso deve soar um alarme.

Se eu estivesse no cargo, para meu entretenimento pessoal, teria pedido ao gerente que assinasse um contrato congelando todos os requisitos. Eu imagino que o gerente provavelmente pagaria. Então eu iria embora.

Bem, isso é simples. Basta dizer ao seu gerente que você assinará para fixar sua estimativa de tempo quando ele assinará para fixar a especificação. Como você não pode, com certeza forneça estimativas para algo que é desconhecido. Especificações completas do projeto antes de começar, sem alterações - e você pode finalizá-las a tempo :)

Uma alteração em spec => contract é nula. Provavelmente a coisa será anulada logo após 10 minutos no seu primeiro dia :)

Sim, isso é uma bandeira vermelha. O que isso diz é que o gerente não entende como gerenciar riscos em projetos de software. O que ele deveria fazer é descobrir o que exatamente causou o atraso em primeiro lugar e depois começar a instrumentar um processo para gerenciar efetivamente os riscos do cronograma que inevitavelmente acontecerão durante um projeto de software.

NUNCA, em circunstância alguma, assinaria um contrato com meu gerente, garantindo uma programação. Outros mencionaram que ele assinasse um bloqueio nas especificações. Na minha opinião, isso não é suficiente. Isso não explica dificuldades imprevistas com ferramentas ou tecnologia, projetos incompletos ou ruins, desempenho de outros membros da equipe etc.

Isso não é uma bandeira vermelha, é uma estupidez de nível de armas.

Se estimativas e prazos são consistentemente divulgados, a coisa racional a fazer é identificar causas e melhorar os processos.

Se você culpar e chutar o cavalo porque não sabe para onde está indo, não se surpreenda se o cavalo o morder e fugir!

Enquanto o gerente estava fora de sintonia com sua demanda. Ele não é totalmente culpado. Se você estava trabalhando em território totalmente desconhecido, não há nada de errado em dizer "não sei". Levei um tempo para perceber que "eu não sei" é uma resposta perfeitamente aceitável, então eu sei o quanto dói para pronunciar essas palavras. Mas se você realmente não sabe, essa é a resposta. E se eles se recusarem a pedir que você forneça uma estimativa de quantos centavos serão necessários para fazer uma pilha tão alta quanto a Torre Sears (faça Willis). E eles estariam dispostos a assinar um contrato pagando a cada centavo que gastaram?

Qualquer gerente de projeto que mereça seu salário deve saber que algumas coisas não se encaixam muito bem em uma planilha. Às vezes, as coisas são feitas quando são feitas. Acho que você está indo bem, progredindo em quanto fez. Apenas pare de atualizar o número.

Outro exercício é dividir a grande tarefa em unidades menores e mais estimadas. Este exercício também ajudará você a entender melhor o que você precisa fazer. Confira o Software Estimation, de Steve McConnell, e o Software Requirements Patterns, de Stephen Withall, para obter dicas sobre como dividir tarefas e descobrir requisitos ocultos, respectivamente.

Não atire do quadril em uma estimativa. Aproveite o tempo para quebrá-lo. Estimar um grande número de pequenas tarefas fornecerá uma estimativa geral melhor (devido à lei das médias, algumas de suas estimativas estarão abaixo, mas algumas terminarão e tenderão a pesar umas às outras) da grande tarefa.

Pergunte ao seu "gerente de projetos": estamos vendendo software ou prazos?

Sou gerente de projeto e programador :-) Eu poderia falar muito sobre como a maioria dos PMs é de fora da indústria e não consigo lidar com nada que não se encaixe perfeitamente em um modelo de linha de produção ... mas eu não vai, não aqui. Em vez disso, aqui está uma longa polêmica sobre o que realmente fazer (Sr. Mod, se for muito longo, faça o que você quiser). Concordo com os comentários já feitos aqui, alguns que você deve fazer antes de outros, mas aqui está o que eu acho que teria sido melhor sua primeira jogada . Ah, e a resposta óbvia à sua pergunta é sim, mas isso é elaborado em linguagem colorida e detalhada abaixo.

Antes de começar, observe que o PM provavelmente está lhe causando pesar, porque alguém mais adiante na cadeia alimentar está sofrendo. Eles (nós) são criaturas simples ... Existem maneiras de evitar a situação que você descreveu - Mike Brown cobre isso muito bem. Também não há nada errado em fazer algo durante 3/4/5 .. horas seguidas antes de iniciar (na verdade, todos os tipos de alarmes precisam disparar se isso não acontecer). E se você estiver entrando em um território desconhecido, recue e peça uma semana para pesquisar a área e as tecnologias para poder fazer uma estimativa sensata (você fará isso corretamente porque deseja que a nova tecnologia aprenda e brinque com o don não é?). Se o seu gerente geral e a gerência do local em que você está não entenderem isso ... atualize seu currículo e procure a saída mais próxima, deixando-os para o destino que eles merecem tanto. O fato de o PM pensar em conseguir que um funcionário em período integral assine um contrato como esse é um mau sinal ruim ... a única maneira de ver que elestalvez não seja totalmente incompetente é que eles estavam apenas brincando com o líder do seu projeto e você (pelo que li, eles não colocaram isso diretamente para você e, por fim, não seguiram adiante a ameaça). Afinal, PMing é um refúgio para o seu psicopata corporativo padrão. Foi bom que outras pessoas entrassem em conflito com você pelo que você disse, por isso os conselhos abaixo provavelmente teriam sido positivos para você no final. Eu imagino que eles teriam uma revolução em suas mãos se isso acabasse sendo mais do que conversa.

Então, para a situação / buraco real que você descreveu , porque isso acontecerá novamente com alguém, em algum lugar (como cerca de 5 minutos atrás, e novamente em outros 5, scheduleRepeat ()). Provavelmente sem a estupidez do contrato, mas o enredo básico é sempre o mesmo. Organize uma reunião (!), Eles gostam de reuniões ;-) todo mundo pode dar um tapinha nas costas no final como se algo tivesse realmente sido feito. IMPORTANTE:Certifique-se de incluir o líder do projeto técnico / líder da equipe / arquiteto / gerente de design na reunião já tendo analisado o problema com eles e colocado a bordo. Quanto mais alto a hierarquia você puder ir para alguém do seu lado, melhor. Porque o seu gerente verá isso e tentará combinar seu gerente de design com um equivalente. Caso contrário, eles são burros e você já venceu. Isso por si só geralmente os coloca de volta na linha, porque agora eles são visíveis para alguém que provavelmente pode demiti-los no local. Se eles estão jogando com você, você pode devolver o favor.

Na reunião, consulte os detalhes técnicos do que você está lidando e por que leva o tempo necessário. Eles devem querer saber disso (e como podem ajudá-lo a fazer isso), mas o fato triste é que geralmente isso não acontece ... você provavelmente terá 10 minutos antes que seus olhos voltem à cabeça. Agora, o que eu gostaria de fazer aqui provavelmente não é legal ... sim, verifiquei, é altamente ilegal na verdade e você não quer ir para a cadeia por tanto tempo. O ponto é que você se esforçou ao máximo para ser pró-ativo e se você tem alguns superiores presentes, sua dor agora é deles ... como deveria ser. Você terá que usar seu julgamento sobre como as coisas provavelmente vão acontecer, porque 'escalada' é o que acontecerá. Se a liderança no local em que você está é meio decente, eles farão a coisa certa, e faça a coisa certa por você também. Caso contrário, você teria seu currículo no mercado de antemão ... você sairia na primeira oportunidade de qualquer maneira (e parece que você acabou). A liderança se dividirá em dois grupos - eles são tecnicamente esclarecidos e verão instantaneamente o seu ponto de vista; ou não são e o que farão a não ser sorrir e suportar? Se eles pudessem fazer o que você faz, então já o fariam. te o que eles farão a não ser sorrir e aguentar? Se eles pudessem fazer o que você faz, então já o fariam. te o que eles farão a não ser sorrir e aguentar? Se eles pudessem fazer o que você faz, então já o fariam.

Mantenha a questão dos requisitos em mudança como seu trunfo para usar no final ... ele servirá como saída para todos. O projeto em si e o cliente / parte interessada terão seu nome em vão. O caminho mais simples a seguir seria um tipo de redefinição no projeto, e talvez esse PM fosse silenciosamente transferido para uma área diferente. Milagres acontecem ocasionalmente. Se a questão do contrato foi levantada na reunião pelo gerente geral, revide os requisitos e congele a demanda de contratos contratuais - até onde eu sei, eles já queimaram suas pontes com você e com toda a equipe de desenvolvimento quando começaram. jogando esses tipos de jogos mentais.

Antes de assinar: Alterar escopo / requisitos - um dos melhores motivos para adotar a metodologia Agile, para que os clientes / partes interessadas sejam devidamente responsáveis ​​por mudar de idéia sobre o que desejam ...

Ah, mais uma coisa: na declaração "eu não sei", sempre foi minha referência pessoal sobre como avaliar o valor de um colega tecnólogo ou membro de uma das minhas equipes de projeto. Eu acho que as únicas pessoas capazes de dizer que diretamente na sua cara são as melhores que existem, principalmente porque alguém que sabe que está fora de profundidade nunca dirá isso - as abre a serem claramente expostas por alguém com habilidade real em um batimento cardíaco. Por outro lado, alguém que se manifestar e dizer isso também terá um plano básico (mesmo que não tenha sido pensado) sobre como lidar com as incógnitas, para que em 24 horas haja uma resposta mais útil, e em uma semana ainda melhor. Quando a Apollo 13 estava voando pelo lado escuro da Lua, havia um monte de "não sei" acontecendo.

Sim, isso deve gerar uma bandeira vermelha, especialmente se você é um funcionário em período integral. Quais foram as condições do contrato? Você realmente seria demitido se não cumprisse os prazos? Ou você apenas perderia um bônus? O que eles fariam?

O sinal que isso levanta é que o gerente não tem idéia de como gerenciar um projeto que lida com tecnologias novas / desconhecidas e requisitos de mudança que afetam diretamente o esforço estimado. Enquanto prazos rígidos às vezes acontecem, um gerente que conhece a situação não deve tentar fazer com que os funcionários assinem contratos para cumpri-los. Tarde da noite e tempo de crise serão ruins, mas isso provavelmente é o mínimo para o curso. E ainda assim, às vezes, o prazo termina. Acontece e, como alguém postou, a única maneira de manter o cronograma é congelar os requisitos com antecedência, para que ainda haja espaço suficiente para manter a linha do tempo.

Pelo que você disse, os sinos de alarme estão alguns meses atrasados. Normalmente, é arriscado basear um projeto sensível ao tempo em tecnologias com as quais a equipe ainda não esteja familiarizada. É tolice fazê-lo se você não tiver conhecimento da coleta de requisitos e do gerenciamento de escopo.

Dito isto, concordo com as outras respostas. Além disso, você pode atualizar seu currículo se ainda não o fez.

Assim como todos os outros entrevistados, eu não poderia concordar mais que isso deveria levantar uma bandeira vermelha.

Parece que o PM não quer se envolver no processo de desenvolvimento.

Na minha prática pessoal, deixei de lidar com especificações detalhadas iniciais, aprovações, estimativas completas de projetos ou preços de lances fixos (do ponto de vista da consultoria).

A razão para isso é a compreensão, sobre a qual muitos gurus do Agile e Lean Software falam, que o software não é uma entidade fixa de fabricação, mas é principalmente um processo de descoberta.

Muitas pessoas ainda têm problemas com essa noção, e parece que o seu PM também. Tudo se resume a uma compreensão simples das compensações.

Especificações rígidas iniciais e estimativas fixas funcionam para sistemas onde o custo da mudança é alto. Como construir um arranha-céu. Se você esqueceu de especificar os eixos dos elevadores na frente, será muito difícil adaptar o edifício depois que ele for erguido. Alto custo de mudança requer muito planejamento inicial, aprendendo as incógnitas de componentes e tecnologias e experimentação inicial. Somente depois de fazer todo esse trabalho de casa, é possível estimar o orçamento e o custo.

No software, as pessoas se acostumaram com a idéia de que o custo da mudança é baixo e, portanto, gostam de tirar proveito de poder mudar as coisas quando vêem um lançamento, incorporando um novo entendimento do aplicativo, dos negócios e do cliente. numa base contínua. Tudo isso é bom e uma grande oportunidade quando alavancado corretamente. A maioria das pessoas que conheci e trabalhei com software não gosta de gastar muito tempo planejando ou investigando; a maioria de nós (incluindo PM) deseja ver a tração em andamento. É daí que surgiu o desenvolvimento iterativo com seus pequenos e incrementais lançamentos de funcionalidade. Existem outras práticas que podem ser usadas, como desenvolvimento orientado a testes para garantir que o custo da mudança permaneça baixo e que a dívida técnica seja contida.

Fazer esse trabalho envolve um "contrato" entre os dois lados, o proprietário do produto (o Agile fala para seu gerente de vendas ou clientes ou equipe de controle de qualidade) e desenvolvedores. Os desenvolvedores concordam em trabalhar apenas nas coisas que foram priorizadas como as mais importantes para a iteração especificada e não levarem uma eternidade para isso, mas esforçam-se para liberar frequentemente pedaços de funcionalidade totalmente integrados (por exemplo, semanalmente ou mensalmente). Os proprietários do produto, por outro lado, concordam em revisar continuamente as liberações incrementais e fornecer feedback imediato. Eles também concordam em definir as prioridades para a próxima iteração e, uma vez configurados, para não mudar de idéia durante a iteração.

Esta última parte do contrato é algo que seu gerente de contas provavelmente não entende. Muitos PM tradicionais realmente não. Alguns deles acham que seu trabalho é feito quando eles abandonam as especificações; eles não querem ouvir sobre problemas, alternativas, maneiras melhores etc. A desvantagem é que isso não apenas contraria o fluxo do desenvolvimento de software, mas também prejudica a organização, deixando muitas oportunidades em cima da mesa.

Dê uma olhada no Manifesto Ágil: http://agilemanifesto.org/ Ele pode ressoar com você. Um bom livro para ler também é "Lean Software Development" de Mary Poppendieck

Boa sorte.

Parece que o gerente está procurando alguém para culpar quando se reporta ao seu superior.

Acho que se você tem um gerente irracional que pensa que uma 'estimativa' é igual a um 'período fixo', a melhor coisa a fazer é pensar em um período de estimativa muito generoso e depois dobrá-lo!

Além disso, force o gerente a garantir que os requisitos sejam totalmente detalhados e corrigidos. Quaisquer alterações a partir de então não serão tratadas sem uma 'renegociação formal' com o gerente do projeto do novo tempo de conclusão.

Eventualmente, o gerente de projeto obtém a ideia e planeja adequadamente.

Minha experiência pessoal com esse tipo de coisa é que o gerente de projeto está tentando montar uma trilha de papel para descartar você e, ao mesmo tempo, tornar sua rescisão sua própria culpa. Isso tornaria uma bandeira muito vermelha. Sua milhagem pode, é claro, variar um pouco.

Boas respostas, mas deixe-me adicionar meus 2 centavos.

Se você estuda probabilidade, existe uma "variável aleatória". Esse é um número cujo valor você não conhece, mas pode descrever o seu desconhecimento com uma distribuição, como uma distribuição normal (curva de sino) ou outra.

A questão é que o trabalho levará algum tempo, mas qualquer estimativa anterior estará errada, de pouco ou muito, no lado negativo ou positivo, então há risco e alguém tem que correr o risco. Geralmente, se as pessoas correm riscos, são pagas por isso. Seguro custa dinheiro.

Quando eu era consultor, geralmente tinha a opção de assinar um contrato de tempo e materiais versus um contrato de preço fixo. Com o tempo e os materiais, o cliente assume o risco. Com preço fixo, eu assumo o risco. Com preço fixo, construo uma margem de segurança, porque, se não cumprir a meta, ninguém vence.

Pedir que você se comprometa com uma data de entrega fixa, especialmente sem requisitos fixos, parece tentar transferir o risco para você, mesmo que não esteja claro o que você está realmente arriscando. De qualquer forma, uma resposta é simplesmente colocar uma margem de segurança realmente generosa.

PS Você vê isso o tempo todo com contratos governamentais. Há uma solicitação inicial de propostas, lances são feitos, uma oferta baixa é aceita e, em seguida, as solicitações de mudança começam a chegar, então os custos aumentam e o contratado é responsabilizado. As coisas funcionam muito melhor se houver uma relação de trabalho em equipe entre cliente e contratado, em vez de uma relação contraditória.

Sim, é claro que isso levanta uma bandeira sobre a experiência e competência de seu ex-chefe. Sim, como a maioria das pessoas sugeriu, este seria um bom momento para atualizar seu currículo.

Sim, como as outras respostas indicam, na maioria das situações você não gostaria de assinar esse contrato. No entanto, quero sugerir que pode haver algumas situações em que você pode considerá-lo.

A maioria dos desenvolvedores e gerentes está ciente do atrito constante entre a funcionalidade, o prazo e o orçamento. Muitos também indicariam a qualidade como uma quarta dimensão ("Eu posso entregar qualquer conjunto de requisitos que você quiser, amanhã, com um orçamento baixo, contanto que você esteja disposto a aceitar que não funcionará!")

Mas há ainda outra dimensão: risco. Se eu só precisar entregar com êxito 50% do tempo, posso reduzir imensamente minhas estimativas; eles são acolchoados para lidar com uma taxa de entrega muito mais alta.

Podemos tratar do risco de várias maneiras (e as estimativas de preenchimento são uma delas). O gerente não está disposto a aceitar nenhum risco e quer colocar o risco em seus ombros. Normalmente, você deve recusar esse movimento ... a menos que esteja sendo bem recompensado.

Se você puder indicar seu prazo, com uma quantidade de preenchimento mutuamente aceitável para lidar com atrasos inesperados, e conseguir negociar um bônus (muito grande) se o atingir, e estiver em uma posição financeira para poder lidar com o penalidades (por exemplo, ser demitido), se não puder, você pode achar que vale a pena "arriscar" aceitar esse risco e assinar o contrato - com cláusulas adequadas para lidar com as mudanças nos requisitos.

Isso é estupidez direta. Não sei qual era o objetivo final, mas todo gerente de projetos decente responsável por produtos de software deve estar ciente de que as estimativas são exatamente o que elas chamam: estimativas. Eles não são promessas e não podem ser cumpridos sem esgotar toda a energia do desenvolvedor de software ou forçá-lo a quebrar sua "promessa" de qualquer maneira.

Se você quiser mostrar o quão ridículo é esse contrato, aqui estão duas sugestões:

a) Altamente superestime o ponto em que o projeto leva cinco ou dez vezes o tempo que você estimaria sem contrato. Se o gerente do projeto perguntar por que as estimativas são tão altas, basta dizer que você está apenas certificando-se de que pode cumprir seu contrato.

b) Isso já foi sugerido: solicite um contrato que garanta que nenhum requisito seja alterado e verifique se isso inclui a correção de erros ortográficos. Na minha experiência, não há um único projeto de software em que os requisitos não mudem em algum momento durante o desenvolvimento. É mais provável que o gerente de projeto tenha que quebrar o contrato deles.

Se o gerente de projeto concordar com qualquer uma dessas duas sugestões, você saberá com certeza que elas estão loucas.

A propósito, como seria um contrato para um funcionário em tempo integral? Não sei sobre regulamentos de trabalho em outros países, mas como funcionário em tempo integral em uma empresa, não acho que alguém possa forçá-lo a assinar um contrato vinculativo para cumprir um prazo e ter um caso válido. Claro, eles podem te dar um inferno se você não cumprir o prazo, mas eles não precisam de um contrato para isso. Ninguém poderia demiti-lo ou lhe dar menos dinheiro. Eles poderiam reduzir seu bônus acordado na pior das hipóteses. Portanto, a menos que isso seja diferente em outros países, isso parece mais uma ameaça vazia do que qualquer coisa que você deva levar a sério.

Eu vou contra a corrente aqui.

A situação que você descreve não é tão incomum no nível da equipe de Engenharia , especialmente após um projeto / release particularmente tardio. Em muitas situações, seu gerenciamento e toda a organização podem ter se inscrito para uma data de lançamento específica e outras partes da organização serão preparadas para essa data. Pode haver uma pressão tremenda em sua cadeia de gerenciamento para atingir essa data.

É aqui que entra um processo de engenharia geral. Você provavelmente já ouviu falar do modelo em cascata. Existem outros modelos, mas o objetivo final de todos eles é fornecer consistentemente algo quando é esperado e contendo o que foi acordado. Especificações funcionais, projetos, listas de tarefas, etc., tudo isso torna um processo previsível. A comunicação, a análise de risco e (como você disse) atualizando regularmente as expectativas sobre o cronograma reduzem as surpresas e disponibilizam as informações o mais rápido possível para que os planos possam ser ajustados. E sim, deve haver ajustes no plano sempre que os recursos forem adicionados ou removidos.

Em algumas das equipes com as quais trabalhei, não hesitaria em tratar minhas estimativas como compromissos assinados, mas isso reflete a qualidade das equipes e da gerência, e nenhuma habilidade específica em estimar. Uma equipe que está disposta a assinar um contrato para entrega pontual é um indicador de uma equipe que trabalha bem, não uma bandeira vermelha.

Eu digo, coloque-se no lugar dele e tente entender o que motivou isso. Dos gerentes / contadores em perspectiva, eles precisam de um número para justificar o que está acontecendo e como as coisas estão indo.

Pode ser que, sendo ridicularizado na sala de diretoria por mudar prazos, perdendo muitos prazos, ele tentou a maneira mais simples possível de prendê-los. Dê-me um número e assine aqui! Você estar do outro lado, só poderia ter percebido que é algo contra você. Como sempre fazer estimativas e perceber que elas precisam ser ajustadas é o que ele é mais útil para ele. Se você entender o que motivou a solicitação e qual é o verdadeiro problema que ele está enfrentando, poderá ajudar ele e a si mesmo. Como programadores, resolvemos problemas. Não é diferente, entenda e resolva o problema dele e ele será seu melhor amigo. Há tanto trabalho a ser feito que ninguém tem tempo para planejar uma vingança pessoal! Ele precisa de ajuda com seu trabalho, a solução mais simples era alguém assinar um trabalho! Provavelmente, ele conseguiu isso em um livro de gerenciamento de manequins: "Faça com que seus funcionários assinem e ajudem a responder por um número". Engraçado mas triste

"Andar na água e desenvolver software a partir de uma especificação são fáceis se ambos estiverem congelados".

-Edward V. Berard

Se seus requisitos estão mudando, não é razoável esperar que suas estimativas iniciais sejam precisas. Sim, isso deve ser uma bandeira vermelha.

O contrato especifica uma penalidade por não cumprir o prazo? Caso contrário, não será um problema. Você está apenas assinando uma estimativa com base no seu conhecimento da época.