Como parte de uma revisão de todas as descrições de cargos, minha empresa decidiu incluir o seguinte como resultado principal:

desenvolvimento do site concluído dentro do prazo, dentro das especificações e sem erros

Dado que as especificações mudam regularmente, não há processo formal de controle de mudanças e os ambientes são, digamos, um pouco imprevisíveis, quão realista e razoável é esse KPI?

"Sem erros" é muito subjetivo . A "Solicitação de recurso não preenchido" de um homem é o "Erro" de outro homem. Algo como "Deve atender substancialmente às especificações do projeto" seria mais apropriado. Na verdade, nunca vi o que você descreve em uma descrição do trabalho. Eu já vi isso por contrato de trabalho , mas não por funcionários.

Vou tomar uma posição oposta à maioria das respostas e dizer que é absolutamente razoável e realista.

Todo o desenvolvimento será concluído no prazo? Claro que não, nem sempre.

Todo o desenvolvimento será concluído dentro da especificação? Você gostaria de esperar que sim, mas às vezes isso simplesmente não será possível e você terá que sinalizar um desvio de uma especificação impossível ou auto-contraditória.

E todo o desenvolvimento estará livre de erros? Nunca .

Mas é para isso que serve um KPI. É algo que pode ser medido e pelo qual você pode acompanhar o desempenho e o progresso.

Se as especificações mudam regularmente, não há processo formal de controle de alterações e os ambientes são imprevisíveis, será um desafio manter esse valor próximo de "livre de erros". Mas esse desafio é o seu trabalho , e é um trabalho que, esperamos, você fará muito bem - e ainda melhor no próximo ano, à medida que tiver mais prática em gerenciar o sabor particular do caos da sua empresa.

Contra-pergunta: quais KPIs você proporia para um programador? É difícil. Muito do que fazemos é difícil de medir.

Se for uma descrição do trabalho, não me preocuparia muito com isso, pois trabalhar no sentido de código sem erros faz parte do trabalho de um programador típico (mesmo que nunca possamos alcançá-lo).

No entanto, como um KPI, é muito abrangente, mas não culpe a pessoa que o sugeriu se não for programador. Explique apenas que essa afirmação define uma meta que pode ser indesejável para a organização. Ou seja, "livre de erros" é um padrão extremamente alto para software que custaria uma fortuna para ser entregue. Explique que um projeto de software bem executado exige que sejam tomadas decisões sobre se vale a pena gastar um tempo valioso do desenvolvedor.

Aqui está um exemplo que mostra bem o ponto.
Um programador descobre que nosso software possui um erro "ano 3000" e deixará de funcionar após 31 de dezembro de 1999. Levará de 6 a 8 meses para corrigir o problema. Com base no KPI, é incentivado a assumir esse projeto, apesar de não ter valor real para a empresa.

Ok, então esse exemplo é um pouco extremo, mas em qualquer projeto de software, literalmente, dezenas de pequenos defeitos serão descobertos que, da mesma forma, não geram o ROI necessário para corrigi-los. Se o KPI pretendia implicar que o programador nunca introduzisse o defeito em primeiro lugar, parece razoável QUALQUER funcionário ser mantido no padrão de nunca cometer um erro no desempenho de seu trabalho?

Não

Não só não é apropriado, é ridículo

Os testes podem apenas provar a existência de erros, e não a ausência deles; portanto, todos os programas escritos sob este compromisso precisam incluir uma prova rigorosa de correção ... e 100% de cobertura do teste

"Cuidado com os bugs no código acima; eu apenas provei que está correto, não tentei." - D. Knuth

Obviamente, é tarefa e responsabilidade de todo programador escrever código livre de erros. Essa é uma expectativa perfeitamente razoável. Como você pode ser um programador profissional se liberar um código que não funcione? Como você pode se considerar um programador profissional se liberar um código que não sabe que funciona?

Se você contratar um pintor, espera que ele faça bem o seu trabalho. Você espera que o resultado do trabalho dele seja livre de erros. Se houver erros, você espera que ele assuma a responsabilidade por esses erros e os corrija gratuitamente. Além disso, se os erros lhe custarem dinheiro, você espera que ele o reembolse. Por que você tem essas expectativas? Porque o pintor é um profissional.

Os programadores gostam de culpar os outros por seus erros. "Meu programa tem bugs por causa dos requisitos, ou por causa do cronograma ou porque a Lua está na 8ª casa". Mas não há realmente mais ninguém para culpar. Se o seu programa tiver erros, você os coloca lá.

Nossa profissão nunca será uma profissão até que os programadores percebam que o dinheiro acaba com eles. Que eles são responsáveis ​​pela qualidade de seus programas.

Você sabe por que as empresas criaram departamentos de controle de qualidade de software? Porque programadores não estavam fazendo seu trabalho! Os programadores estavam lançando tanta porcaria que as empresas tiveram que formar departamentos totalmente novos para checá-los.

Quanto tempo dura a lista de bugs? É profissional ter milhares de bugs no banco de dados de bugs? Claramente, não é. É um reflexo de mau comportamento, falta de disciplina e, francamente, desonra.

Nunca seremos uma profissão até percebermos que é nosso trabalho garantir que o controle de qualidade não encontre nada.

Infelizmente, isso apenas soa como uma maneira de "cobrir todas as bases", e claramente não é recomendado e provavelmente causará desilusão nos desenvolvedores.

No entanto, tendo dito isso, isso realmente importa apenas quando você vê o que eles fazem com esse texto durante o período em análise. Portanto, não exagere muito rapidamente - ainda pode haver sanidade no final do túnel.

"Livre de erros" como em "perfeito?" Como "escrito por Deus e pelos anjos, não pelos humanos?" (estamos falando aqui de erros de lógica do programa e talvez de lógica do hardware)

Não posso dizer com sinceridade, mesmo que uma única linha de código, que seja sem erro. Isso porque nós humanos, bem, não podemos provar hipóteses negativas!

O melhor que posso dizer é que a probabilidade de um erro é um número entre 0 e 1. Eu alcanço esse número por meio de princípios de teste e desenvolvimento de software bem definidos ou mal definidos e mal compreendidos; por uma contagem das linhas de software de origem em questão; pela compreensão de quão bem ou mal candidato, pobre vira-lata, aplica esses princípios na produção dessas linhas de código; e mais.

E eu posso expressar esse entendimento apenas como uma probabilidade. Portanto, o termo "sem erros de lógica" significa quase nada.

Se eu visse um anúncio para um engenheiro de software que produzisse código "livre de erros", eu aplicaria imediatamente ou correria imediatamente: a empresa não pensou muito sobre como desenvolve, testa e entrega seu software . Portanto, será uma grande oportunidade ou um pesadelo sem fim.

De qualquer software, embora, eu posso facilmente - e deve - dizer espero código que não tem erros que caem fora que sucky, obscuro, lógica-ey coisas: código que compila e links sem erros ou avisos; que é "html válido" ou "css válido"; JavaScript (digamos) que não gera mensagens de erro inexplicáveis ​​ou falhas no navegador. Essa parte eu posso medir diretamente e marcar em preto e branco em um gráfico.

Essa parte é fácil como torta. Qualquer um pode fazer isso .

Ei, boa sorte na sua pesquisa :-)

Estou sendo estúpido ou "erro" não significa "mensagem fatal do compilador no valor de código não compilável"?

Por essa definição, é um requisito bastante razoável ...