Como você lida com agendamento / prazos torno de programadores? [fechadas]

Question

Os programadores fazem o gosto de criar prazos? Im um desenvolvedor web e horários / prazos estão por todo o lugar no meu campo. Mas eu tenho trabalhado com alguns engenheiros de software / programadores que odeiam prazos, existe uma maneira de contornar isso?

Answer 1

Em primeiro lugar, é preciso distinguir entre prazos e estimativas.

• Prazos vir de fontes externas, por exemplo, "as necessidades de recursos X para estar pronto para a feira".
• As estimativas vêm de fontes internas, por exemplo, "Recurso X terá N semanas para ser concluído".

Geralmente, os programadores devem criar estimativas, e as vendas / marketing irá criar prazos.

Os problemas ocorrem quando os dois não podem ser resolvidos - se o prazo está mais perto do que a estimativa

.

Dicas úteis para dev (leads):

• Deixe a pessoa a fazer o trabalho criar a estimativa.
• Certifique-se de estimativas são baseadas em tarefas pequenas, cada uma não mais que um ou dois dias.
• Use um loop de feedback para permitir que os desenvolvedores melhorar suas habilidades de estimação.
• habilidades estimativa precisa permite que você empurrar com mais força contra as exigências de prazo.

Dicas úteis para os comerciantes / criadores Prazo:

• não substituem uma estimativa com um prazo.
• Se um fim do prazo conflitos com uma estimativa, as opções só reais são (a) desenvolvedores trabalhar horas extras, (b) os requisitos para o prazo são cortados, ou (c) o prazo não for cumprido.
• Explique por que o prazo é importante, e qual é o propósito do prazo de recurso é ( "cliente X vai assinar um contrato de seis dígitos").
• Entenda que as pessoas que sentem que não podem cumprir os prazos agressivos não serão motivados.

Answer 2

Os programadores ODEIO prazos por razões muito boas!

É quase impossível estimar com precisão quanto tempo um pedaço de código vai demorar para projetar, gravação e depuração até que você tenha feito isso.

Da minha experiência pessoal eu passei mais de uma semana recebendo um script shell "simples" para o trabalho que eu teria estimado em cerca de uma hora. Por outro lado levou cerca de uma semana para escrever um analisador para definições de dados COBOL (incluindo todo o COMP estranho COMP-3 ocorre redefine SYNC e folga bytes coisas) que eu tinha estimado em cerca de dois meses.

O outro grande problema é que enfrentou com as melhores práticas de prazos apertados programadores pular e começar a cortar. Assim, uma economia de cerca de 50% do tempo de codificação, mas a adição de 300% para o tempo de teste e de depuração.

Answer 3

Tradicionalmente, você só pode ajustar qualidade, recursos ou tempo, sendo o último o prazo. Qualidade que você realmente não quer mexer. Então, enquanto o processo que você está usando permite calibrar apresenta para atingir prazos, estou ok.

Answer 4

Os desenvolvedores necessidade de ser envolvido na criação dos prazos. Se eles são arbitrários e criado sem a entrada de desenvolvedores, então eles têm o direito de reclamar. Projetos legitimamente obter restrições de tempo do negócio, mas os recursos e características devem ser ajustados para compensar. Essas adaptações não podem ser feitas sem a entrada de desenvolvedores (para não mencionar BAs, QA e pessoal de operações).

Answer 5

Os engenheiros de software apenas / desenvolvedores que eu conheci que odeiam prazos sentir assim para uma de duas razões:

1. Eles são completamente desorganizado, e sei que eles não vão atender a prazo, e por isso não gosto deles porque quando eles perder o prazo fá-los ficar mal.
2. Não faça tem um problema com prazos, como desde que alguém que entende o trabalho envolvido está definindo o data limite. Os piores prazos são feita por gerentes que tentam vender um projeto e dizendo "3 semanas? Não problema!" e, em seguida, contar a sua equipe de desenvolvimento que eles têm 3 semanas para produzir uma versão de trabalho de MS Office e recriar o internet para criança do CEO.

Answer 6

Eu acho que isso depende de como os horários são criados. O desenvolvedor precisa ter um papel significativo na vinda acima com a programação. Caso contrário, como você vai saber se é razoável ou não?

Se alguém na gerência superior simplesmente dita que "as necessidades de recursos X para ser feito por Y" sem ter qualquer boa visão para quanto tempo isso pode realmente ter (algumas coisas são muito mais complicado de implementar do que eles soam como), em seguida, isso é uma coisa ruim. No entanto, se eles trabalham com os desenvolvedores para estimar a quantidade de esforço realmente necessário e equilíbrio que com o resto das necessidades da empresa, então ele geralmente funciona muito bem.

Answer 7

Bem, eu estou muito feliz com um prazo se que prazo foi determinado por meio de bem pensado processo de estimativa com a entrada de ambos os gerentes e engenheiros e os requisitos para o que deve ser entregue na referida prazo são bem definidas.

Answer 8

As revisões regulares são cruciais:

• Lista dos principais marcos e prestações
• dividi-lo em pedaços menores
• Criar um conjunto de estimativas menores
• Faça os prazos razoáveis ??

Você deve ter prazos, mas igualmente esses prazos devem ser realistas e mensuráveis. Movendo a especificação redor vai irritar o desenvolvedor - pode ser inevitável, mas não tenha medo de mudar as coisas (após discussões).

Os prazos e estimativas de trabalho nunca vai ser particularmente precisas, mas as técnicas tão básicos de gerenciamento de projetos deve significar que as pessoas estão conscientes da falta deles - e por que isso aconteceu.