As metas SMART são úteis para programadores? [fechadas]

Conheço várias organizações que usam metas SMART para seus programadores. SMART é um acrônimo para Específico, Mensurável, Alcançável, Relevante e Limite de Tempo. Eles são bastante comuns em grandes corporações.

Minha própria experiência anterior com objetivos SMART não foi tão positiva. Outros programadores encontraram uma maneira eficaz de medir o desempenho? Quais são alguns exemplos de boas metas SMART para programadores (se existirem).

Em um mundo

Não

Primeiro: meus projetos nunca permaneceram estáveis ​​o suficiente para estabelecer metas SMART com algum significado. O tempo varia entre quando minhas funções mudam em um projeto e quando as análises de desempenho são feitas estão muito fora de sincronia.

Segundo: Medir o desempenho individual é uma ótima maneira de criar uma mentalidade "não é meu trabalho" e uma competição negativa entre indivíduos e / ou as várias sub-equipes de uma organização. É muito fácil jogar o sistema e verifique se você está cuidando de si mesmo e não está realmente ajudando a equipe inteira. Deveríamos incentivar as pessoas a participarem de equipes, mas nossas organizações fazem exatamente o oposto.

A maioria desses tipos de sistemas é contrária à formação de equipes. Mary Poppendieck fez um trabalho muito melhor ao articular isso do que eu jamais posso fazer no LeanEssays: Team Compensation .

Sue recebeu uma ligação de Janice em recursos humanos. “Sue”, ela disse, “Ótimo trabalho que sua equipe fez! E obrigado por preencher todos esses formulários de avaliação. Mas, na verdade, você não pode dar a todos uma classificação máxima. Sua classificação média deve ser 'atende às expectativas'. Você só pode ter uma ou duas pessoas que 'excederam as expectativas' ... ”

... Um dos maiores líderes de pensamento do século 20, W Edwards Deming, escreveu que um dano não mensurável é criado pela classificação de pessoas, sistemas de mérito e pagamento de incentivos. Deming acreditava que toda empresa é um sistema e o desempenho das pessoas é o resultado da maneira como o sistema opera. Na sua opinião, o sistema causa 80% dos problemas em um negócio, e o sistema é de responsabilidade da gerência. Ele escreveu que usar exortações e incentivos para levar indivíduos a resolver problemas de gerenciamento simplesmente não funciona. Deming se opôs à classificação porque destrói o orgulho na mão-de-obra, e o mérito aumenta porque eles tratam dos sintomas, e não das causas, dos problemas.

... vamos dar uma olhada mais profunda nos sistemas de avaliação e recompensa dos funcionários e explorar o que os leva a se tornarem disfuncionais ...

Usamos as metas SMART na grande corporação em que trabalho. Eles são sem sentido na maior parte.

Os objetivos descem da alta gerência e são elevados e abstratos. Relacioná-los com projetos e desenvolvimento concretos é geralmente uma piada. A maioria dos projetos que entram no grupo vem do negócio e deve atender a uma necessidade específica do negócio. Então você codifica o projeto, coloca-o em produção e faz um excelente trabalho, como de costume. Como isso se relaciona com uma meta que alguém da alta gerência criou?

Como grupo, nos saímos muito melhor quando criamos nossos próprios objetivos. Às vezes, eles incluem treinamento sobre um tópico específico ou implementam uma nova mudança de processo, algo que pode realmente estar relacionado ao que fazemos. Eles ainda não estão realmente relacionados à operação diária da codificação, pelo menos são coisas que ajudam a levar o grupo para a frente no ambiente corporativo.

EDITAR

Como Mnementh apontou corretamente, minha resposta é baseada em objetivos SMART que não são, bem, SMART. Eu acrescentaria à minha resposta que, se você é gerente de programadores e deseja implementar metas SMART, verifique se elas são SMART. Use o exemplo dos meus gerentes como uma maneira de NÃO implementar metas SMART. Se você não gerencia programadores e alguém lhe diz que agora você começará a usar as metas SMART e elas acabam como a nossa, entenda que você tem pessoas na alta gerência que gostam de palavras de efeito e podem verificar eles fora de uma lista de coisas que eles implementaram.

Há muita pesquisa para mostrar que os programadores farão um excelente trabalho em qualquer critério que lhes seja apresentado, à custa de outros objetivos possíveis.

Isso significa que eles farão bem em atingir objetivos específicos e mensuráveis, e menos bem em qualquer coisa não listada especificamente. Isso significa que você deve ser extremamente cuidadoso ao estabelecer metas.

Você não deseja definir linhas de código como objetivo. Confie em mim. A configuração de bugs corrigidos leva a escrever código de buggy para começar. Pedir correções de erros no código existente resultará em definições muito liberais de "bug" (e talvez "correção"). (Além disso, a parte "alcançável" depende de quão bugs o código foi.) Solicitando a integridade dos recursos em um determinado período, bem ...

O que você deseja que seus programadores façam é escrever coisas úteis em um período razoável com boa qualidade de código e aprimorá-las e modificá-las, mantendo a qualidade do código. Nunca vi metas específicas e mensuráveis ​​que fossem bons critérios.

Passamos por esse exercício todos os anos. O problema é que os desenvolvedores aqui tendem a ter muito pouca autonomia sobre o que fazem (tarefas determinadas pelo gerente de produto). Temos sorte de que, pelo menos no papel, temos tempo dedicado a perseguir nossos objetivos. Realisticamente, temos muito menos que isso, no entanto.

Dentro dessa estrutura, descobri que definir metas de autodesenvolvimento funciona muito bem. Por exemplo, dois dos meus objetivos do ano passado foram:

1. Ler Padrões de Design e escrever projetos de brinquedos para aprender e demonstrar cada padrão até o próximo ano. Isso acabou levando dois anos, mas a melhoria na minha codificação foi notável.
2. Estudar os recursos da linguagem .NET 3.5 e fazer uma apresentação para meus colegas de trabalho a cada trimestre. Isso acabou sendo uma apresentação no LINQ que meus colegas apreciaram em vários graus entre apático e levemente interessado. No entanto, aprendi muito e, tendo demonstrado meu conhecimento em C #, fui transferido para o trabalho em um novo projeto bem legal.

Então, sim, eu me beneficiei e me diverti enquanto fazia isso.

Honestamente, em nossa empresa, acho que a falta de bons objetivos SMART para desenvolvedores tem mais a ver com a aversão instintiva ao discurso corporativo.

Sim, se definido corretamente.

Se definidos corretamente, os objetivos podem melhorar a equipe e as pessoas. Eles também devem estar alinhados ao trabalho e projetados para o indivíduo.

Eu já estive em lugares onde uma equipe inteira de DBA tem os mesmos objetivos, além de repassar alto nível, como "estar em conformidade com os KPIs globais e regionais, conforme determinado pelo comitê de KPI". Que ninguém sabe, é claro ..

Por outro lado, estive em lugares em que o gerente define objetivos individuais com o pensamento antecipado.

Editar:

Eu li o artigo de Mary Poppendieck e não é sobre o SMART. "A Percepção de Impossibilidade" falha em "Realizável", por exemplo.

Objetivos devem ser definidos para o indivíduo, para compartilhar suas forças, ajudar a corrigir fraquezas, contribuir para a equipe. A medição é para o indivíduo.

Não deve haver comparação de x vs y.

Os objetivos para x e y devem ser proporcionais à sua posição ou posição dentro de um sistema: não se estabelecem os mesmos objetivos para idosos e juniores. Isso é injusto.

Alguma referência é necessária para definir bônus ou pagamentos de um pote limitado: devemos contar linhas de código? Revisões por pares?

E mostre-me alternativas válidas que não exigirão que eu mude meu ethos corporativo global. Eu não tenho nenhuma crítica a SMART: eu faço têm críticas dos gestores pobres mijo ...

Como estrutura de desempenho, o SMART é tão eficaz quanto o quanto seus objetivos estão alinhados com os de seus gerentes. Às vezes, seus objetivos SMART precisam desmoronar primeiro, ou seja. faça-os:

• Factível
• Compreensível
• Gerenciável
• Benéfico

Por mais estranho que isso possa parecer.

A definição de objetivos do tipo SMART pode ser útil em um contexto de programação, mas deve ser feita de maneira inteligente ou, como apontado em outras respostas, é provável que seja uma perda de tempo (ou pior).

Para obter objetivos úteis, é útil concordar com o significado do acrônimo SMART: uma pesquisa rápida no Google encontrou várias definições :

• S: parece ter consenso em Specific (embora haja alguma discordância sobre o que isso significa)
• M: Significativo e Motivacional são alternativas para o Mensurável mais comum
• R: parece representar com maior frequência o Achievable, mas também vi Concordado
• R: dependendo de onde você olha, você pode encontrar realista, relevante, focado em resultados
• T parece sempre fazer referência ao Tempo, embora a ênfase varie

Então, primeiro, os dois lados da negociação de definição de objetivos devem trabalhar a partir de um entendimento comum do processo.

Em seguida, os objetivos gerais da organização, divisão, grupo, equipe (ou qualquer hierarquia relevante) precisam ser explicados e compreendidos. Nesse ponto, deve ser possível que o indivíduo (IMO, as metas devam ser definidas no nível individual para que valha a pena) para poder concordar com um pequeno número de objetivos que devem informar as atividades dessa pessoa no futuro.

Se termina aí, ainda foi um desperdício de tempo de todos. Os objetivos precisam ser revisados ​​e ajustados regularmente - quando alcançados, a possível necessidade de estabelecer novos objetivos deve ser considerada, quando não alcançada, as razões devem ser identificadas e as ações corretivas prescritas quando necessário.

Todos os envolvidos devem estar cientes de que esse tipo de exercício não vale a pena se não for levado a sério, ou talvez de maneira mais algorítmica, o valor a ser extraído seja proporcional ao esforço realizado.

Pode ser instrutivo ver o que as pessoas acham que podem ser objetivos úteis / úteis da SMART. Eu fiz uma pergunta aqui ...

O problema dos objetivos SMART é que eles precisam escolher o que é mensurável. Como o que é mensurável e o que é importante para o sucesso da organização geralmente não é a mesma coisa (e praticamente nunca é na programação), os objetivos SMART sempre fracassam nas avaliações de desempenho em minha experiência. E, às vezes, as coisas parecem mensuráveis, mas não exigem muito esforço (como o objetivo SMART, tive um tempo para responder a todos os emails em quatro horas. Realmente quem quer tentar passar pelos milhares de emails que recebo por ano, determine se era informativo ou precisava de uma resposta e, em seguida, observe meus e-mails enviados para ver se eu atendi e ouça as gravações de todos os telefonemas para ver se eu atendi, verifique meu log de mensagens instantâneas para ver se eu atendi etc. e o e-mail que me foi enviado no sábado à noite à meia-noite ...)

Para todas as pessoas que responderam NÃO, seus objetivos provavelmente não foram suficientemente inteligentes.

Eu os usei e os acho incrivelmente úteis. Você pode tentar algo que funcione para nós:

1. Definir metas trimestrais.
2. Estabeleça metas mensuráveis.
3. Defina apenas uma meta para o indivíduo
4. Faça o indivíduo aceitar a meta, se ele disser que a meta é um reajuste ambicioso demais até o momento em que vocês dois concordarem.
5. No final do trimestre, crie um valor booleano. Objetivo alcançado = verdadeiro ou falso.

Isso é extremamente poderoso, cria responsabilidade pelo desenvolvedor. As pessoas que querem encontrar desculpas ficam com frango após 6 meses ou mais.

PS: Eu posso entender as pessoas que votam na resposta, mas por favor escreva um comentário relevante pelo menos eu vou aprender algo que eu não sei :-)

SMART é um acrônimo para lembrar de alguns critérios para melhores objetivos. Assim, ao introduzir os meios SMART, sua gerência precisa melhorar seguindo esse princípio. Sem a SMART, o gerenciamento definiria metas de qualquer maneira, mas provavelmente seria muito difícil.

Portanto, para os programadores não virem mudanças, o gerenciamento precisa mudar seu estilo para implementar o SMART. E se eles derem certo, seu trabalho como programador pode se tornar mais fácil, porque a direção do projeto é mais clara, os prazos são definidos e assim por diante.

Se a gerência não fizer o que é certo, muita coisa mudará.