Métricas - são como canetas de feltro, cada uma a seu gosto. Sem métricas, a existência de um negócio lucrativo como tal é impossível, eles nos cercam constantemente, isso é desagradável, mas um axioma. Para alguns, a métrica é o plano de vendas do mês, para outros é a conclusão do pedido antes do prazo acordado e para outros o número de horas trabalhadas.
Não há “Imagens de atração” adequadas sobre esse assunto, portanto, mantenha um gatoPor alguma razão, a palavra "métricas" no campo de TI está intimamente associada a "excelente" em suas práticas de estupidez, como contar linhas de código escritas ou tarefas fechadas. Podemos dizer com confiança que essas são as “ferramentas de gerenciamento” de controle mais inúteis e desdentadas. De fato, métricas adequadas são, de maneira bastante condicional, mas ainda assim, apenas de dois tipos: métricas para o projeto e / ou trabalho, cujo resultado e tempo de execução são claros e previsíveis no tempo e vice-versa, métricas para o projeto e / ou trabalho, o resultado e o tempo de execução fisicamente impossível de prever. Para o primeiro tipo, as métricas do resultado são definidas e, para o segundo - a distância, em outras palavras, o tempo trabalhado.
O primeiro tipo de métrica "por resultado"
Não existe uma receita universal para definir métricas para qualquer funcionário - esse é sempre um fenômeno situacional. A métrica do funcionário é sempre formada de uma resposta simples para a seguinte pergunta: podemos prever claramente o resultado final e, como resultado, o tempo de trabalho a distâncias curtas ou médias?
Vamos olhar para a situação do freelancer. Na maioria das vezes, os clientes constroem relacionamentos com artistas com base no pagamento pela quantidade de trabalho realizado. Ou seja, existe um orçamento para o projeto, e o prazo e prazo para sua entrega são acordados durante esse orçamento de negociação. É assim que designers, designers de layout e vários desenvolvedores trabalham. Na maioria das vezes, o orçamento não se move, ou seja, o "tempo de execução" é a parte móvel.
Mas é sempre previsível mais / menos, ou seja, o cliente entende claramente quanto tempo "aproximadamente" será gasto na execução de seu pedido. Com base nessa figura, um orçamento é alocado, após o qual é procurado um artista adequado.
Em geral, o princípio "não nos importamos quanto tempo você gasta na conclusão de um pedido, apenas o faz bem e no tempo que é aceitável para nós" é claramente pregado no ambiente freelancer. Isso elimina muitas perguntas sobre o monitoramento do trabalho de um freelancer ou empregado temporário, elimina a necessidade de pagar a ele três, quatro, dez vezes o "salário" e assim por diante. Há uma parcela de pré-pagamento, há um fechamento da conta final pré-acordada.
Uma abordagem semelhante vazou para pequenas e médias empresas, onde as pessoas parecem trabalhar e em período integral, mas a empresa vive em um estado de concorrência acirrada e distâncias curtas quando o resultado é necessário em uma data específica. Com "esforços malucos", você pode desenhar um diagrama de blocos aproximado que o orienta na decisão:
E as taxas horárias do UpWork e outros modelos de tempo freelance?
Talvez essa pergunta tenha nascido para você, leitor, no início do artigo, mas chegamos à resposta apenas agora. Mais precisamente, para as respostas, porque existem várias delas.
Primeiro: a empresa contratada está acostumada a controlar, porque a taxa horária em 50% dos casos envolve um rastreador e em relatórios 100% periódicos com uma auditoria do trabalho realizado. Ou seja, o cliente transfere parte das funções gerenciais para o próprio contratante, que se reporta.
Segundo: a empresa precisa controlar o processo de desenvolvimento, porque possui apenas uma tentativa. Se o projeto se estender por mais de algumas semanas, o cliente precisará entender "sob que luz" o trabalho. Na maioria das vezes, o orçamento é alocado apenas uma vez para pedidos tão grandes e há apenas uma tentativa. De fato, havia empresas no mercado que não exigiam relatórios periódicos e, às vezes difíceis, de executores em grandes projetos, mas o mesmo acontecia com os elefantes com orelhas pequenas - eles desapareciam (elefantes por superaquecimento, mas empresas - por causa dos prazos).
O segundo tipo de métrica é "in time"
Mas tudo se torna muito, muito mais complicado se começarmos a falar de um grande projeto, cujos prazos de entrega variam de "de um a três anos" e "este é um desenvolvimento eterno". No caso de "desenvolvimento eterno", é quase impossível prever o tempo para obter o resultado final. seguintes razões:
- não apenas uma pessoa está trabalhando no projeto, mas até várias equipes;
- cada equipe "nas direções" tem de duas a três a várias dezenas de funcionários;
- quando o trabalho no projeto termina, ninguém sabe.
Em tais condições, é fácil se perder e espalhar peras conhecidas com um objeto conhecido. Mas como a empresa não está envolvida em obras de caridade, é necessário passar das métricas "por resultados" para uma categoria mais complexa de métricas "por tempo".
O exemplo mais simples e lógico de trabalhar “pontualmente” é o escritório habitual em tempo integral em empresas de 30 a 50 pessoas no departamento de desenvolvimento. Nessas condições, o negócio "on the shore" concorda com um funcionário em potencial, ou seja, na fase da entrevista, não sobre o tempo de conclusão do projeto, mas sobre o custo de uma hora de trabalho com base em uma semana de trabalho de 40 horas, de acordo com o Código do Trabalho. Para nós, parece apenas um salário.
Ao mesmo tempo, é preciso entender claramente que os negócios não são tolos. O tamanho da RFP (mais precisamente, sua redução) inclui crises de personalidade, agitação no escritório, intervalos para fumar, mais 20 a 30 minutos para o almoço (ou seja, uma hora e meia, em vez de uma hora) e apenas procrastinação no YouTube. Algumas empresas podem arcar com esses custos, porque o negócio é atualmente lucrativo e ele pode oferecer uma versão "leve" do controle, simplesmente configurando tarefas de curto prazo com prazos imprecisos nos quais a gerência júnior e média está envolvida.
Mas se o negócio é de margem baixa ou existe em um ambiente Legado competitivo, tudo fica pior. E aqui começa o inferno uniforme, para o qual os desenvolvedores não gostam tanto da palavra "métricas".
Uma referência muito precisa ao tempo trabalhado não é uma métrica independente de eficiência, são necessárias muletas aqui
Se uma pessoa é paga não pelo resultado, mas pela quantidade de tempo trabalhada, como avaliar sua eficácia? Esta pergunta está sendo constantemente solicitada pelas empresas. Existem várias variáveis aqui:
- Vincular o desempenho da equipe à métrica "resultado" a uma curta distância.
- O uso de métricas menores no nível de tarefas e sprints.
- Construindo uma estrutura clara de responsabilidade, termos e prioridades, chame como quiser, por exemplo, "política de desenvolvimento".
De fato, o negócio se depara com uma situação em que parece ter mudado para um mecanismo mais compreensível de "tempo de compra", mas ainda é necessário controlar se algo foi recebido pelo pagamento desse tempo na forma de resultados trabalhistas. Ou seja, nosso conceito de "comprar um resultado" se torna uma variável incorporada no conceito de "tempo de compra".
Na maioria das vezes, a gerência não é capaz de rastrear claramente as necessidades de negócios e funcionários ao mesmo tempo, isto é, de criar um sistema e uma política de aplicação de métricas nas quais ambas as partes ficariam felizes com o que está acontecendo. O que significa: as métricas devem atender simultaneamente aos interesses dos negócios e ser compreensíveis e factíveis pelos funcionários.
Aqui nos deparamos com outro problema: se, ao trabalhar “em ordem” a curtas distâncias, a tarefa é mais clara e compreensível para todas as partes, então, ao desenvolver um produto grande, toda a estrutura está em constante movimento. Banal: os concorrentes lançaram um novo produto ou um novo kit de ferramentas apareceu e todos os planos que foram criados com carinho pela gerência foram desperdiçados.
Neste ponto, depende muito da gestão. Aqui você pode simplesmente descrever as abordagens inadequadas e adequadas para definir métricas.
Métricas inadequadas:- número de linhas de código e confirmações;
- número de tarefas fechadas sem levar em conta a complexidade;
- privar o desenvolvedor do direito de voto;
- ignorar as necessidades de dinâmica e desenvolvimento no período coberto pelo relatório (métricas que excedam o bom senso);
- processo demorado de revisão de métricas, falta de flexibilidade, ignorando opiniões de desenvolvimento.
Aqui, descrevi uma "galera" típica quando um desenvolvedor passa de uma pessoa para uma "máquina de escrever código" e não se importa com o modo como lida com tarefas / métricas de curto prazo que vêm de cima para ele. Nesse caso, o desenvolvedor perde qualquer oportunidade de influenciar o desenvolvimento, mesmo que veja o "interior" do problema. Ao mesmo tempo, a complexidade das tarefas não é levada em consideração e tudo se resume ao trabalho do macaco.
Métricas adequadas:- Contabilizando a complexidade da tarefa;
- A capacidade de revisar as métricas após o fato de surgirem problemas;
- Capacidade de comentar sobre a tarefa;
- Falta de forte ligação a indicadores quantitativos de linhas de código / número de tarefas;
- Ignorando a não conformidade parcial com métricas, se necessário.
Métricas adequadas são aquelas que não são pregadas no chão e que podem ser movidas. Se uma empresa busca eficiência máxima, essa eficiência deve estar em todos os níveis. Há muito tempo ficou claro que o número de tarefas ou linhas de código, na verdade, não significa muito, pois algumas tarefas podem ter um efeito decisivo no produto e centenas de outras custam.
Além disso, a vinculação estrita à conformidade com as métricas é contraproducente: se o desenvolvedor souber que terá "problemas" devido ao fato de ter fechado 19 tarefas em uma semana em vez de 20, a qualidade da tarefa ficará em segundo plano. E o último mínimo, 20 tarefas, será colocado no “lixão”, com muletas e bicicletas, em vez de realmente e de uma vez por todas resolver a tarefa.
Feedback como parte integrante do modelo de "compra a prazo"
De fato, um modelo de desenvolvimento bem construído, vinculado ao tempo de trabalho, é muito mais complicado do que parece à primeira vista. Para trabalhar efetivamente nesse modelo, o feedback de alta qualidade deve ser organizado entre artistas e líderes, que devem ajustar constantemente a “política de partido” em todos os níveis. Afinal, uma tarefa inadequada, ou seja, uma métrica formulada, está longe de ser um problema para os desenvolvedores, embora seja habitual levar esse problema aos executores. Uma métrica inadequadamente formulada é um problema, apenas do gerenciamento que definiu essa tarefa para os contratados, desde que o trabalho de ambas as partes seja transparente.
É o gerenciamento que organiza o trabalho para que o tempo de trabalho seja gasto com eficiência, ou seja, os orçamentos não são "queimados", mas, ao mesmo tempo, os desenvolvedores podem lidar com suas tarefas sem esgotamento total em poucas semanas. Porque o recurso humano, embora vasto, mas não infinito, especialmente quando se trata de pessoal qualificado.
É a presença de feedback e responsabilidade pelas decisões tomadas pela gerência que difere de uma empresa que mantém um registro detalhado das horas trabalhadas, de uma "galeria" explícita na qual os desenvolvedores entram em um moedor de carne sem sentido.
É o feedback que permite à empresa encontrar gargalos no desenvolvimento. Quantas vezes você se deparou com uma situação em que os funcionários de um departamento estavam sufocando, trabalhando para desgaste, mas não receberam "reforços" na forma de um par de novos especialistas que substituíam seus ombros e assumiam parte da carga? Tais situações surgem o tempo todo, precisamente devido à falta de feedback de alta qualidade entre desenvolvimento e gerenciamento. Em vez de rastrear claramente a eficácia da equipe e sua carga de trabalho, o gerente enfia o dedo no nariz e, quando alguém quebra, incapaz de suportar esse ritmo, empurra tudo para os demais desenvolvedores. Não faça isso.
Em vez de saída
A pior coisa que pode acontecer no processo de organização de um processo de trabalho é "distorcer" os mecanismos inerentes a um modelo para outro. Por exemplo, quando prazos rígidos são definidos para projetos de longo prazo sem uma avaliação sólida da complexidade e dos recursos da equipe. Ou quando, em projetos e tarefas auto-suficientes de curto prazo, essas formas de controle são construídas para caber no campo da ciência dos foguetes, e estamos falando apenas de um pedido de freelance.
Um entendimento claro da adequação de certos métodos de trabalho em empresas de várias estruturas e tamanhos ajudará a preservar uma grande parte da saúde e do sistema nervoso ao procurar trabalho. E quanto mais desenvolvedores, gerentes e empresários entenderem esses mecanismos, melhor será para todos os participantes do segmento de TI.