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

113

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.

sunpech
fonte
145
Fugir! Fleee
Nifle
36
+1 por fazer uma pergunta que acaba sendo relevante para quase todos os programadores . Muitos de nós já fomos pegos nessa situação muito antes de sermos experientes e sábios o suficiente para lidar com isso corretamente.
Adam Crossland
13
Parece que você precisa multiplicar suas estimativas iniciais por um número não trivial para garantir a pontualidade.
18
Você precisava da Cheops Law of Project Management - dobrar a estimativa e arredondar para a próxima unidade de tempo - 1 hora se torna 2 dias.
JQA
11
Se alguém pedir isso, insista para que cumpram os requisitos do mesmo contrato (e, é claro, inclua um grande fator de segurança nas suas estimativas). Além disso, verifique se eles não podem usar linguagem vaga nos requisitos para dizer que você não cumpriu o que foi prometido. (Ou, sim, apenas RUN .)
Samb

Respostas:

109

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 ".

Tangurena
fonte
1
Isso também pode significar que o gerente está sob muita pressão para entregar a tempo e devido à falta de experiência em como os projetos de palavras reais funcionam remonta aos formalismos, na tentativa de tentar tornar a incerteza tratável.
Michael Borgwardt
160

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.

whatsisname
fonte
58
+1, eu estava pensando a mesma coisa sobre o congelamento dos requisitos no contrato. Isso mostra absurdo por ser absurdo.
precisa saber é o seguinte
22
Vale ressaltar que, mesmo com requisitos congelados, a estimativa ainda é um número aproximado que pode mudar de tempos em tempos.
Codism
4
A fluência de recursos é apenas um risco possível que afeta os cronogramas. Eu apostaria que há 100% de probabilidade de que os requisitos de bloqueio não sejam suficientes para garantir um cronograma.
pemdas
7
@Pemdas O objetivo do contra-contrato não é realmente bloquear as especificações; é fazer o PM recuar.
chrisaycock
6
Só estou dizendo ... bloquear os requisitos não é suficiente.
Pemdas
59

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 :)

Slawek
fonte
12
+1, mas lembre-se de que a especificação bloqueada é a etapa 1 e as estimativas bloqueadas, a etapa 4. É claro que a etapa 2 é um protótipo funcional de cada área e risco e a etapa 3 é um processo de estimativa completo e detalhado (incluindo a revisão por pares externos por especialistas técnicos e de domínio reconhecidos claro). "Arriscar" é caro ...
Richard
4
"Provavelmente a coisa será anulada logo após 10 minutos no seu primeiro dia." Sim, provavelmente, mas Deus o ajude se o contrato continuar e o trabalho ainda demorar mais do que você pensava!
PeterAllenWebb
O problema é que o tempo necessário para criar uma estimativa suficientemente detalhada, dada qualquer especificação (mesmo bloqueada), não é trivial. De fato, para obtê-lo realmente preciso, você precisa fazer a maior parte do trabalho primeiro. Software é um projeto de design, não um projeto de construção. Você precisa projetar porque não o fez antes. Quando você sabe o que precisa ser feito, o design está concluído. Nesse ponto, apenas pressionamos Compile.
Scott Whitlock
7
+1 Passeio na água e software de gravação baseado em especificação é possível desde que ambos são congelados :)
Jacek Prucia
31

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.

Pemdas
fonte
3
“Na minha opinião, isso não é suficiente.” - Eu não acho que deveria ser. Acho que todos esperamos que nenhum gerente sensato assine esse contrato.
Konrad Rudolph
13
Nenhum gerente sensato proporia que o desenvolvedor assinasse um contrato de cronograma também.
pemdas
1
esse é um tipo diferente de insanidade. Exigir uma estimativa de tempo com contrato bloqueado é estúpido, mas de certa forma. A assinatura de um contrato que responsabilize o gerente por qualquer confusão futura é o oposto disso.
Konrad Rudolph
1
+1 Melhor resposta. Gerenciar riscos é o trabalho do gerente. Ele deve verificar frequentemente como as coisas estão indo e oferecer ajuda nos pontos difíceis, e deve ter um buffer generoso no final, que distribuir conforme necessário. (E a coisa contrato é estúpido de qualquer maneira, depois que o gerente é executado através de dois ou três programadores que se conserva sobre o contrato, ele se tornará óbvio que os programadores não são o problema.)
Kyralessa
27

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!

Steven A. Lowe
fonte
19

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.

Mike Brown
fonte
5
Não tenho problema em dizer "não sei". O problema é que não é um número que pode ser colocado na planilha do MP para análise de projeto / recurso ou o que quer que eles façam com as planilhas.
Spong
Atualizei minha resposta para dar mais algumas dicas.
Michael Brown
1
+1 para Mike Brown. Quando comecei, devo dizer que estava otimista demais, um dia decidi revelar o negócio real: não sei. No meu caso, o problema não era a tecnologia, mas o conceito por trás dela. (De C ++ e Java para Prolog para um algoritmo específico)
DIERRE
14

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

ThomasW
fonte
3
Olá ThomasW, bem-vindo ao Programmers.SE! Você deve ter notado o tamanho das outras respostas a esta pergunta: aqui, acreditamos que uma boa pergunta convida os usuários a fornecer respostas que fornecem explicações (consulte as Perguntas frequentes para obter mais informações). Você pode fornecer mais detalhes?
7
Cara, a resposta principal tem apenas 3 linhas, qual é o problema ... Gostei desta resposta.
Ninguém
Bem, na verdade ambos. O software vendido gera receita. O software ainda em desenvolvimento não possui receita (hit # 1); ainda custa dinheiro para o desenvolvedor (hit # 2); e tem um custo de oportunidade de não fazer a próxima coisa (hit # 3). Portanto, é justo tentar entregar os pedidos com agendamento. Se a programação é REALISTA é uma questão separada!
quickly_now
10

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.

nomaderWhat
fonte
2
você precisa aprender a ousar nas idéias principais, e não quando você gritar na tela. é difícil escanear o post e ter uma idéia geral.
Nome de exibição
1
+1 para "o PM provavelmente está causando luto, porque alguém mais adiante na cadeia alimentar está sofrendo". Parte do trabalho de um gerente é ser um guarda-chuva para protegê-lo disso - mas mesmo grandes gerentes têm guarda-chuvas vazados se a chuva cair forte e rápido o suficiente.
Bob Murphy
@ bold Desculpe. Eu sei que era um post muito longo, e nem sempre será assim, mas esse era um tópico muito querido pelo meu coração - o suficiente para passar de ouvinte de longa data para iniciante. Eu apenas me atrevi a marcar para onde ir para a estratégia de contra-ataque e pular a gargalhada. Além disso, usei parágrafos da mesma maneira que o idioma inglês foi projetado antes da internet ;-) Você pode apenas escanear a primeira linha de cada uma para obter um jist geral.
nomaderWhat
2
Além disso, precisa de mais chocalho.
ocodo 20/01
1
Por que esse comentário incitante não foi mais votado? Leite saiu do meu nariz quando o li!
MAWG
9

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.

FrustratedWithFormsDesigner
fonte
Não havia contrato real. Ouvi apenas que o PM queria que eu assinasse um contrato para tentar me responsabilizar mais pelas minhas estimativas de tempo. Não sei até que ponto o PM queria que as consequências chegassem, se eu não pudesse entregar.
spong
@ sunpech: Eu nunca ouvi falar de uma coisa tão louca.
FrustratedWithFormsDesigner
8

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.

Larry Coleman
fonte
4

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.

Wolfram Arnold
fonte
4

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.

martinws
fonte
2

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.

PSU
fonte
1

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.

Mike Dunlavey
fonte
0

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.

Oddthinking
fonte
0

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.

Anne Schuessler
fonte
0

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.

ÁRVORE
fonte
Eu acho que isso não é "tudo é novo e os requisitos mudam massivamente 2-3 vezes do início ao prazo", embora?
Vatine
Desde o início do lançamento até o GA real, com certeza, o conteúdo pode mudar completamente algumas vezes. No entanto, um bom processo irá elaborar isso cedo , como antes dos projetos detalhados ou estimativas de baixo para cima.
ÁRVORE
++ Certo. Uma boa equipe terá bons processos e estará disposta a aceitar riscos. Eu acho que funciona melhor quando o cliente e o contratado fazem parte da equipe e veem todos os problemas da mesma perspectiva. Não vejo isso frequentemente no desenvolvimento de software.
precisa saber é o seguinte
0

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

Arjang
fonte
++ para "você pode ajudar ele e a si mesmo".
precisa saber é o seguinte
0

"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.

Bill the Lizard
fonte
-2

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.

Andomar
fonte