Ninguém exigirá que o desenvolvedor escreva código sem acesso a um computador, mas muitas empresas acreditam que ele deve trabalhar de alguma forma sem a capacidade de utilizar totalmente suas capacidades mentais. E isso é tão irrealista.
Então, vamos examinar uma lista de doze itens que impedem que os desenvolvedores entrem em um estado de fluxo e ofereçam a máxima produtividade. Vou tentar passar das coisas mais importantes para as menos significativas. Sugira suas opções e comentários!
Se alguém duvida que vale a pena gastar dinheiro e esforço nisso, basta lembrar quanto os programadores são pagos. Mesmo um aumento de 10% na produtividade é muito dinheiro!
1) Reuniões e outras distrações
Na minha opinião, distrair o desenvolvedor é a maneira mais segura de matar sua produtividade pela raiz. Ele não pode simplesmente pegar e continuar do lugar onde foi interrompido. Primeiro, ele precisa se envolver no processo novamente e depois passar por toda a cadeia de pensamentos até o momento certo - isso por si só pode levar meia hora ou mais. E quanto mais essas interrupções acontecem, quanto mais irritação se acumula, menor a qualidade do trabalho, mais erros aparecem e essa lista pode ser continuada.
“Quanto mais eu me distraio quando tento iniciar uma tarefa, mais tempo começa a decorrer entre as tentativas. Se eu fui puxado a manhã toda, não há nada para se surpreender que o dia tenha sido improdutivo ”- desenvolvedor anônimo do Reddit
Bem, e a reunião? Sua única diferença em relação a outras distrações é que elas são planejadas com antecedência. E isso só piora a situação. É difícil para um programador avançar na solução de um problema se ele espera uma interrupção no trabalho com antecedência. Portanto, se em uma hora ou duas ele tiver que ir à reunião de planejamento, provavelmente ele não poderá fazer nada de significativo em nenhum de seus projetos - afinal, a maioria das tarefas de engenharia leva mais tempo.
Como Paul Graham disse: "Uma reunião pode matar meio dia: o tempo é dividido em dois períodos, para os quais você não pode fazer nada sério".
Como evitar esse estado de coisas? Tudo foi pintado sobre isso por um longo tempo, então não há desculpas. Você só precisa colocar a plaina no início do dia ou, digamos, pouco antes do jantar, para não precisar distrair as pessoas do trabalho sem necessidade.
2) nitpicking
De todas as variedades de gerentes, aquelas que intervêm por qualquer motivo, talvez o pior impacto na produtividade dos funcionários. Obviamente, isso também é afetado pelo fato de esse tipo específico estar especialmente inclinado a organizar um monte de reuniões e exigir a atenção dos desenvolvedores por razões imprevistas. Mas este não é o único ponto. Tais ações mostram falta de confiança e, como resultado, as pessoas sentem que são consideradas incapazes de qualquer coisa e põem em dúvida suas habilidades profissionais. Mesmo que o programador ainda tenha alguma motivação para trabalhar, apesar das intermináveis interrupções, essa atitude a desencorajará completamente. As consequências não se limitam a uma queda no desempenho. Os gerentes intrusivos costumam forçar os funcionários a deixar a empresa, ou pelo menos a equipe.
3) incerto
A falta de clareza pode ser ilustrada por muitos exemplos diferentes. Por exemplo, um relatório de erro com o espírito "Não funciona aqui, corrija-o!" obviamente, não fornece aos desenvolvedores todas as informações necessárias para o trabalho. A propósito, neste caso em particular, a introdução de um modelo para relatórios de erros pode ajudar.
Ou outro caso: requisitos vagos para alguma parte do produto. Com esses desenvolvedores introdutórios, simplesmente começam a fazer o que eles próprios imaginam e, em seguida, um gerente vem com uma descrição mais detalhada do comportamento esperado do usuário, e todos precisam começar tudo de novo.
As prioridades indistintamente definidas pertencem à mesma categoria. Os programadores passam muito tempo tentando entender o que devem começar, embora evitar isso seja muito simples. Bem, se eles tiverem que relatar ao gerente por que estão envolvidos nisso e não nisso (apesar de ninguém ter estipulado o pedido), você pode ter certeza de que isso os tornará ótimos.
4) Gerentes de gaivotas
Já ouviu falar disso? Existem gerentes que não participam do fluxo de trabalho, exceto nos momentos em que decidem repentinamente mergulhar em alguém e cometer um erro. "Isso não é bom, e isso também, mas não parece nada", e continuou. Devo admitir que gosto da comparação, mas o fenômeno por trás disso é muito mais comum do que gostaríamos. Esse comportamento afeta muito os desenvolvedores: muitos precisam criar um clima de trabalho por horas e alguém fica fora do fluxo por dias inteiros.
5) Roubo de louros
Já lhe aconteceu que um dos gerentes ou outros programadores atribuiu a si mesmo o que você lutou por várias semanas? Os desenvolvedores colocam seu profissionalismo acima de tudo. Roubar os méritos de outras pessoas é como negar a competência de uma pessoa para inflar a sua. Eu coloquei esse ponto alto o suficiente, porque acredito que essas coisas levam a uma situação muito tensa, que pode por um longo tempo "diminuir" o desempenho de toda a equipe.
6) Móveis: ruído, movimento, design do espaço de trabalho ...
Pode parecer estranho para pessoas de outras profissões, mas para os programadores, o ambiente decide muito no decorrer do trabalho. Digamos que o ruído branco - o zumbido do ar condicionado, o zumbido de carros e caminhões da rua - os ajude a se concentrar melhor. É por isso que muitos de nós trabalhamos com fones de ouvido! A propósito, eu descobri recentemente o RainyMood - uma grande coisa!
No entanto, se o escritório for projetado para que haja sempre algum movimento em torno da pessoa, isso terá o efeito oposto. E se, além disso, os monitores são instalados de tal forma que os gerentes veem constantemente o que está na tela, isso cria estresse desnecessário e motivos desnecessários para distrair os desenvolvedores dos negócios.
7) Limites deslocados do projeto
No gerenciamento de projetos, esse termo é usado para situações em que os volumes do projeto estão crescendo incontrolavelmente. Isso geralmente acontece quando, inicialmente, eles não eram estritamente definidos e documentados ou não eram monitorados no processo.
Devido ao deslocamento das fronteiras, consultas relativamente simples se transformam em monstros confusos que consomem muito tempo! E, na maioria dos casos, isso começa quando o produto já está em desenvolvimento.
Tomemos, por exemplo, uma função simples:
- Primeira versão (antes da implementação): a função é definida como "Exibir mapa de localização"
- A segunda versão (quando a primeira iteração está quase concluída): a descrição muda para "Exibir mapa de localização 3D"
- Terceira versão (quando a segunda iteração está quase concluída): a descrição muda para "Exibir um mapa de localização 3D no qual o usuário pode se mover"
8) Processo de determinação de recursos do produto
Pode parecer incompreensível à primeira vista, mas, de fato, tudo é simples. Se as pessoas encarregadas do produto priorizarem sem testar suas hipóteses (por meio de feedback ou de qualquer outra forma) sobre o interesse do público em determinadas oportunidades, e os desenvolvedores perceberem que essas oportunidades simplesmente não estão sendo usadas, terão a sensação de que o trabalho deles não faz sentido e a motivação entrará em colapso. Todos queremos sentir que estamos deixando alguma marca no mundo, e isso é especialmente importante para os desenvolvedores!
9) Ignorando dívida técnica
O dever técnico é uma decisão consciente de permitir certo alongamento na escolha de soluções e na redação do código, a fim de lançar o produto mais rapidamente. Uma certa quantia de dívida técnica surge inevitavelmente em qualquer projeto e pode ajudar com prazos em curtas distâncias. No entanto, a longo prazo, aumenta a complexidade do sistema e, assim, atrasa os desenvolvedores. Pessoas distantes da programação geralmente subestimam o impacto desses processos na produtividade e exigem avançar sem parar - nessa situação, problemas começam a surgir. Se a refatoração sempre permanecer fora da lista de prioridades, não somente a produtividade dos funcionários, mas também a qualidade do produto sofrerão.
10) Uma variedade de ferramentas e equipamentos
Os desenvolvedores diariamente usam muitas ferramentas para escrever, enviar e mesclar códigos. Quanto mais eles conseguem automatizar processos, melhor. Escusado será dizer que as ferramentas antigas terão um impacto direto no desempenho. Ele também decide muito do que o trabalho está sendo feito - em um laptop ou também em uma tela adicional. Se compararmos os preços do ferro com os salários dos programadores, mesmo um aumento de 5% na produtividade definitivamente pagará todos os custos! Você só precisa fornecer à equipe os equipamentos e ferramentas que eles preferem usar (para equipamentos, a solução deve ser individual, para ferramentas - coletivas).
11) Documentação de instruções
No processo de ensino da programação, todos aprendemos que você precisa começar a adicionar comentários ao código o mais rápido possível e o mais rápido possível. A idéia era que seria melhor se houvesse muitos comentários do que insuficientes. Infelizmente, muitas pessoas não entenderam isso e decidiram que todas as linhas precisavam de explicação. É por isso que temos exemplos como este, do
artigo de Jeff Atwood “Code without comment”:
r = n / 2; // Set r to n divided by 2
// Loop while r — (n/r) is greater than t while ( abs( r — (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}Você entende o que esse código faz em geral? Então, eu não entendi nada. O problema é que muito se fala aqui sobre como tudo funciona, mas nem uma palavra sobre por que isso é necessário. Se assumirmos que ocorreu um erro no programa e você encontrou um fragmento de código oculto, isso não ajudaria você a descobrir a situação.
12) Prazos extremamente apertados
O último ponto está ligado à tendência dos gerentes de pedir aos desenvolvedores que estimam aproximadamente quanto tempo eles precisarão, pressionando-os para subestimar essa estimativa e, em seguida, magicamente igualar a data final com o prazo final! Ao mesmo tempo, os gerentes até acreditam que, uma vez que os desenvolvedores “estabelecem os próprios prazos”, isso significa que eles se inscreveram no prazo correspondente e devem ser considerados uma opção finalmente aprovada que pode ser transferida para a gerência sênior.
Os desenvolvedores acreditam que esse prazo é uma loucura completa e é impossível manter-se dentro dele; Há discórdia na equipe e ninguém pode se concentrar.
Mas é apenas sobre desenvolvedores?
Se você observar todos esses 12 pontos, notará que eles são, na maior parte, relevantes para todos os envolvidos nos projetos. É que, no caso dos programadores, eles são especialmente críticos, pois seu trabalho exige uma imersão profunda no processo.
Se você perceber que alguns dos pontos mencionados são típicos para sua empresa, seria bom seguir esta lista com a equipe de desenvolvedores, estabelecer um diálogo com eles, descobrir onde os problemas surgem e qual a melhor forma de resolvê-los. O que eles dizem, é extremamente importante levar esse feedback e comentários a sério. Nos últimos trinta anos, muita coisa mudou em termos de tecnologia, mas o princípio básico do trabalho em equipe permanece o mesmo: ao discutir o desempenho, é necessário levar em consideração o fator humano. Melhore seus processos de trabalho, ambiente, hábitos de equipe e dê a eles a oportunidade de dizer como atingir a produtividade máxima.