A escolha é má

Começarei com o principal: se seus programadores escolherem suas próprias tarefas, você terá grandes problemas.

Estamos acostumados a considerar uma escolha como operador condicional em uma linguagem de programação ou esquema de algoritmos. Bem, lembre-se, esse losango é desenhado, contém uma condição de seleção e dois ramos - sim e não. Quando o algoritmo é executado, a condição é verificada instantaneamente, portanto seu desempenho geralmente não é levado em consideração.

E qual é a escolha feita pelo homem? Este não é um algoritmo instantâneo, mas um processo. Esse processo tem um começo, um fim (que Deus não permita) e, mais importante, uma duração. Quanto tempo você acha que a seleção de tarefas pode levar?

Você pode adivinhar, mas é melhor medir. Eu assisti esse processo várias vezes, e a conclusão é decepcionante: o programador pode escolher uma tarefa por vários dias.

O processo de seleção é ruim porque está escondido dos nossos olhos. Se uma pessoa estivesse andando pelo escritório, correndo de um lado para o outro, erguendo a cabeça em um longo uivo, entenderíamos que ele tinha um problema. Mas isso acontece de maneira diferente.

Os programadores há muito tempo inventam um algoritmo como o reconhecimento em batalha. Em relação às tarefas, significa: não apenas leia a condição, mas entre e veja. Dê uma olhada no código, formulários, links, metadados, exemplos de reprodução e relatórios analíticos.

Você precisa procurar para avaliar a tarefa "como deveria", não pela vista. Se você pegar um programador nesta ocupação, ele dirá: Eu sou um profissional e não posso assumir a tarefa sem conhecer todas as sutilezas. Parece, por que isso acontece? É certo que um homem faz?

Claro que está certo. Mas apenas se, de acordo com os resultados de sua pesquisa, ele tomar a decisão final - assumir a tarefa ou não. Como opção, faça a tarefa com reservas, como a necessidade de estudar mecanismos adicionais.

Se o programador decidiu assumir a tarefa e se sentou para fazer, tudo está bem. Se ele abandonou a tarefa, tudo está ruim. O tempo gasto em pesquisa será desperdiçado.

Existem duas opções. Primeiro, o programador se recusará categoricamente e outra pessoa acompanhará a tarefa. Em princípio, é possível que o primeiro programador simplesmente reconteça os segundos resultados de sua pesquisa, armadilhas descobertas e dificuldades associadas. Mas, na prática, os programadores preferem independência um do outro, inclusive das opiniões dos colegas. Alguns até experimentam certa empolgação, entendendo uma tarefa que um colega não realizou.

A segunda opção - o programador não recusou, mas adiou a tarefa para mais tarde. Quando esse "mais tarde" chegar - não se sabe, mas provavelmente - depois de um tempo bastante longo. O que acontecerá durante a segunda iteração de reconhecimento em batalha? Comece de onde você parou na sua pesquisa? Claro que não - ele seguirá o mesmo caminho, do começo ao fim. E, com uma alta probabilidade, ele irá parar no mesmo lugar que pela primeira vez.

E assim acontece. Há tempo que os programadores gastam na solução de problemas. Tempo normal, certo, bom. Como regra, o tempo é gasto na solução de um problema uma vez.

E há tempo que os programadores gastam em vários reconhecimentos. Não há nenhum benefício específico no momento - nem para o programador, nem para o cliente ou para sua empresa. A hora do reconhecimento nas batalhas é quase uma perda pura.

Mas o problema não é apenas inteligência. Isso acontece pior.

Por exemplo, um programador entende todas as tarefas em sua lista, mas simplesmente não pode escolher o que fazer. O problema é agravado pelo fato de que a escolha ocorre como Deus coloca na alma - sem um algoritmo, critério e prioridades específicos. E então há muitas pessoas.

Escolhe-se o que é mais interessante. Outro escolhe o que é mais fácil. O terceiro escolhe tarefas por mecanismos que lhe são familiares. O quarto escolhe as tarefas de seu amado cliente, porque o resultado é mais fácil de passar. O quinto escolhe a tarefa mais ambiciosa para se mostrar.

Ao mesmo tempo, o que é importante, quase todos sofrem um sério tormento mental devido à incerteza dos critérios. Ele compreende aproximadamente as tarefas que deseja resolver, mas consciente ou inconscientemente sente que está fazendo algo errado. Parece-lhe que precisamos escolher uma tarefa completamente diferente, baseada na estratégia da empresa, no estado do projeto, no plano para o desenvolvimento de nossas próprias competências, etc. Mas quero escolher não o que é necessário, mas o que eu gosto.

Tal tormento mental agrava ainda mais o processo de seleção. Uma pessoa mergulha em pensamentos sombrios, pesando sua escolha na balança da consciência. E assim horas e dias podem passar.

Do ponto de vista do gerente à margem, todo esse processo se assemelha à marmota de um filme famoso que sai de um buraco e “escolhe o clima para as próximas seis semanas”. O que ele segue lá, vê sua sombra ou não, e por que a marmota faz isso? É verdade que, se o gerente frequentemente olha esse processo de fora, então a pergunta é mais provável para ele do que para os programadores.

Além disso, no contexto da escolha, as férias são de grande importância. Um programador é uma pessoa, antes de tudo, e não um robô. O que uma pessoa deseja após concluir um trabalho difícil? Feriado, é claro!

A tarefa concluída deve ser anotada. Vá fumar, tome um chá ou café, converse com amigos, gabar-se de uma tarefa resolvida, sentar nas redes sociais, ler as notícias - em geral, existem muitas opções. Infelizmente, este feriado às vezes é atrasado.

É especialmente ruim se a tarefa foi concluída em uma hora ou até duas antes do final do dia útil. Bem, quem, em sã consciência, escolherá uma nova tarefa para si, se em breve - em casa?

Como é difícil sair do estado de férias, todo russo sabe - todos descansamos nos feriados de Ano Novo. No nosso caso, é ainda mais difícil, porque o programador deve voltar não para resolver o problema, mas para escolher o próximo. Quão dolorosa é a escolha, já discutimos.

Se resumir as perdas da escolha, elas sempre estarão lá. A única questão é a sua quantidade. Para se inspirar, chamarei esse número: leva até 50% do tempo para escolher uma tarefa. Basta pensar nesta figura.

Mas, no contexto de nosso material, essa figura é simplesmente linda. Ao eliminar a perda de escolha, você pode dobrar a eficiência.

Como se livrar da escolha? Não há nada mais fácil. Na verdade, você mesmo sabe como fazê-lo. Apresentarei minhas sugestões e você as combinará com seus próprios métodos, resultando em um aumento decente de eficiência.

A primeira e mais importante coisa para começar é controlar. Qualquer que seja o sistema de prioridades e a distribuição de tarefas que você criar, ele não funcionará até que os programadores "ouçam você".

Controlar, em poucas palavras, é controle numérico. Nesse caso, o número não será o lucro ou a quantidade de vendas, mas o número de sequência da tarefa na fila. Você precisa gerenciar a seleção de tarefas com base nesse número e garantir que as tarefas sejam resolvidas na ordem especificada.

O controle é necessário se você gerencia uma equipe e mesmo quando se controla. Afinal, concordar com você mesmo é mais fácil do que com um chefe? "Sim, agora, pela última vez, e então com certeza!"

Em geral, falaremos mais sobre o controle com mais detalhes, aqui corri à frente, mas vale a pena. Se você criou as regras para escolher uma tarefa, mas ninguém as executa, nada funcionará.

Portanto, tudo o que precisa ser feito é alinhar as tarefas na fila e garantir que essa fila seja seguida. Em algumas fontes, é recomendável ocultar a fila dos programadores, deixando apenas duas tarefas à vista - a atual e a seguinte. Se você mostrar ao programador todas as tarefas de uma só vez, não importa o quanto tente, ele ainda “espiará”, estudando o que está por vir.

O primeiro método é a distribuição de tarefas pelo chefe, sem usar a automação. Você acabou de dizer quem faz o quê e em que ordem. Você pode fazer planos simples - por exemplo, na forma de pequenos pedaços de papel, como ordens de serviço ou tarefas de produção. Você pode simplesmente ditar os números das tarefas para gravar em um notebook.

Você pode fazer um quadro, como scrum, e pendurar adesivos lá durante o dia. O método de scrum envolve pendurar muitas tarefas, por exemplo - por uma semana ou um mês, mas isso não nos convém, porque a escolha aparece novamente.

A alocação manual de tarefas é muito fácil de iniciar e também fácil de parar, porque você fica entediado rapidamente. Você precisa ter força de vontade significativa, ou boas habilidades de gerenciamento regular, para se forçar a distribuir tarefas diariamente. Se o que precede é sobre você, você pode começar hoje.

Para automação preguiçosa é adequado. No seu sistema de informações, onde as tarefas são armazenadas, você precisa criar um mecanismo para classificá-las. Como você está mais perto? Classificar por data de produção? Por prazo? Qualquer maneira é boa. O principal é que seja determinado e igualmente compreendido pelos programadores. Pessoalmente, recomendo não limitar a classificação, mas armazenar números em uma fila como um campo separado. Os sistemas modernos são convenientes demais para o usuário e permitem que ele configure a classificação independentemente. Então, você decidiu que precisa executar tarefas na ordem de recebimento (FIFO), e o programador acidentalmente ou intencionalmente alterou a classificação para o oposto e recebeu o LIFO.

Se o número na fila for salvo, classifique, não classifique, é difícil cometer um erro.

Você não pode se apegar à classificação, mas defina os números manualmente. Também funciona se você tiver força de vontade suficiente para organizar esses números.

O princípio, eu acho, é claro. Qualquer sistema de enfileiramento entendido pelos programadores e monitorando sua conformidade. Este será o primeiro passo para privar uma escolha que exige eficiência.

O segundo passo consideraremos mais adiante. Isso nos permitirá obter muito mais benefícios das filas - não apenas para simplificar a escolha, mas também para corrigi-la.

Sumário

  • A escolha de uma tarefa não é um instante, mas um processo demorado;
  • O programador escolhe uma tarefa com base em suas próprias idéias;
  • Uma quantidade enorme de tempo é gasta na escolha;
  • O processo de seleção não é bom nem prazer;
  • A escolha deve ser privada;
  • Você pode distribuir tarefas manualmente, como um capataz;
  • A automação pode ajudar na fila.

Source: https://habr.com/ru/post/pt450794/


All Articles