Então, por que não há novas produções? Onde estão as vitórias nas competições? O que você quer dizer com dois meses correndo e coletando papéis? Que outra criatividade? E por que você não tem tempo para isso? Que outra secretária você deve contratar? O que quer dizer com "estou saindo"? Você realmente acha que pode lidar com isso sem nós? Bem, boa sorte.
Algo assim foi descrito por um excelente líder de uma vida de grupo de dança muito boa "sob a asa" de uma instituição estatal, quando explicou por que saiu "sob a asa".
O caso afundou na alma, tk. Eu estava apenas conduzindo um experimento (mais uma vez) para livrar outras pessoas criativas - programadores - de não-core, mas “um trabalho tão importante, necessário e obrigatório” - estar no tempo.
O que acontece se?
Eu conduzi esta experiência várias vezes, em diferentes empresas - tanto em projetos, quanto no desenvolvimento, e em programadores de fábrica, e na prestação de serviços de revisão. Acredite ou não, o resultado é sempre o mesmo.
Se os programadores pararem de se preocupar com prazos e apenas resolverem os problemas, um após o outro, sem distrações, a produtividade dobrará. Conseqüentemente, se você ativar o modo "catching on time" novamente, o coeficiente será exatamente o mesmo - duas vezes, só que desta vez a produtividade é dividida por ele.
Bem, e o mais importante: o programador ainda não atingiu o prazo, por minha vida. E se isso acontecer, apenas às vezes, por acidente. Ou ao custo de produtividade reduzida.
Tudo é muito simples aqui. Não vou provar o axioma de que um programador nunca sabe exatamente quanto tempo levará para resolver um problema - há muitos artigos e livros sobre esse assunto. Se você trabalhou como programador, a prova não é necessária. Existem, é claro, exceções - tarefas semelhantes e repetitivas - mas essas são as exceções.
A maior parte do nosso trabalho contém tantas incógnitas em constante mudança, flashbacks constantes de tarefas antigas, surpresas de subcontratados e atualizações de dependências, erros de design, etc.
Como você planeja fazer este trabalho? Fundamentalmente, existem quatro abordagens - fantasia, reserva, volume e fluxo.
Métodos de "planejamento"
Fantasy é a aplicação de métodos de planejamento de produção em lote ao trabalho de programadores. Por exemplo, Lean ou MRP. Esta abordagem é usada por todos os "gerentes clássicos", especialmente suas castas separadas - "gerentes". Você só precisa espremer os custos de mão de obra planejados do programador, ignorando todos os seus gritos como "Droga, eu nem sei o que vou enfrentar aí" e desenhar uma bela salsicha no gráfico de Gantt. E redesenhe todos os dias.
A reserva é abordagens como a teoria das restrições, quando a parte de um cavalo é simplesmente adicionada aos custos de trabalho planejados, apenas no caso. A figura resultante também é desenhada como uma salsicha no gráfico de Gantt. Ele é redesenhado com menos frequência, mas quase sempre.
Volume é quando não é o prazo planejado para resolver os problemas, mas sim a produtividade. Por exemplo, esta abordagem é usada no Scrum - conhecendo a velocidade aproximada do trabalho da equipe (em pontos de história), você pode planejar a quantidade de trabalho por sprint (no mesmo SP). Conseqüentemente, todas as tarefas de sprint têm a mesma data de vencimento.
Fluxo é quando há apenas velocidade. As tarefas são alinhadas, o programador senta-se e resolve uma a uma. As datas não são conhecidas, mas podem ser calculadas - conhecendo a velocidade e o número da tarefa na fila. O principal é não confundir o próprio programador com o cálculo do termo.
Prós e contras
Não faz sentido nem mesmo discutir uma abordagem de fantasia - não funciona. Não só isso - também cria um estresse constante e selvagem e um trabalho de replanejamento idiota. Você pode viver se outra pessoa não estiver envolvida no replanejamento, mas isso raramente acontece. Normalmente o programador é martelado todos os dias com perguntas como "diga-me o prazo final", "quando você terminará esta tarefa?" ou "todos os prazos já passaram, você vai trabalhar ou não?" De forma natural e harmoniosa, o programador passa a ter reservas de tempo, mesmo que não saiba nada sobre os métodos da moda.
As reservas de tempo evitam complicações, mas reduzem a produtividade, devido à ação da lei de Parkinson - o trabalho leva todo o tempo alocado para isso. Em algumas circunstâncias, essa abordagem é adequada para todos - por exemplo, para programadores de fábrica. É verdade que até o programador se demitir, então, via de regra, ele percebe que sua velocidade de trabalho é inferior às exigências do mercado.
Os prazos são cumpridos, uma vez que as reservas de tempo podem ser milhares de por cento dos custos reais de mão de obra. Se o negócio ou processo for estruturado de forma que o indicador-chave atinja precisamente o prazo, então o método de reserva de tempo é muito adequado.
Métodos em massa como Scrum podem praticamente dobrar sua produtividade porque reduzir a influência da lei de Parkinson e focar na produtividade mais ou menos real, não em fantasias e reservas de tempo. No entanto, um sprint ainda é um prazo, então a lei de Parkinson continua a operar, assim como as reservas de tempo e as tentativas de manipular os pontos da história. Pessoas são pessoas - tanto programadores quanto gerentes. Os programadores querem ser bons funcionários. E os gerentes estão tão acostumados a considerar bons funcionários apenas aqueles que “cumprem o prazo” que pelo menos uma conta está em suas cabeças. Tudo isso será simplesmente denominado de forma diferente - como "todas as tarefas do backlog devem ser realizadas dentro do sprint e não há nada para facilitar aqui." E eles vão propor algum outro KPI para este negócio, porque a imaginação não é rica.
Não existem tais problemas no fluxo, uma vez que não há razão para eles - o planejamento do trabalho do programador e as tentativas, de uma forma ou de outra, de estimar o tempo do trabalho. O fluxo protege a essência do trabalho do programador - a criatividade. Eu gostaria, claro, de dizer que fluxo é pura criatividade, mas isso não acontece. No entanto, a pureza é muito maior. E a produtividade é mais o dobro do Scrum.
O que é interessante: a proteção do programador, ou de qualquer executor da obra, está incorporada em qualquer um dos métodos acima. Mas, quando aplicada a programadores, a proteção é sempre esquecida.
Qual é a base de qualquer método
Por exemplo, o Lean, curiosamente, também se baseia na ideia de fluxo, uma vez que inventado em uma correia transportadora. A ideia é organizar o trabalho da forma mais uniforme e harmoniosa possível. Para que cada ator da cadeia, por um lado, tenha sempre algo para fazer e, por outro, para que não haja fila à sua frente. Apenas o pé direito mínimo necessário. Para um programador, essa é uma tarefa. Tente passar essa ideia para um gerente que é um especialista em Lean - ele nem vai entender do que se trata, porque Pulei a seção sobre proteção de desempenho quando li o artigo da Wikipedia sobre Manufatura Enxuta.
Na Teoria das Restrições, que trata das reservas, a proteção do elo de execução é geralmente um postulado básico. Onde os programadores se sentam, eles quase sempre são um gargalo. O que o CBT diz sobre o gargalo? Isso mesmo - ele deve ser protegido. Remova toda a carga de trabalho não essencial (incluindo agendar seu próprio trabalho), evite o tempo de inatividade e não calafete seu cérebro com perguntas e reuniões estúpidas. Organize o fluxo de trabalho na velocidade em que o gargalo funciona. Bem, gerentes especialistas em TOC, admitam - vocês já pensam há muito tempo sobre como proteger os programadores de todo tipo de tolice?
Bem, Scrum é tudo sobre fluxo. Lá, o princípio "não atrapalhe o trabalho das pessoas" é elevado ao absoluto, e se expressa na exigência de máxima autonomia da equipe durante o sprint. Então - por favor, venha, veja o que aconteceu, escolha tarefas para a próxima corrida, dê uma olhada no chuveiro. Durante a corrida, nem respire nas proximidades. Quem trabalha no Scrum - o que você diria? Ninguém toca em você durante o sprint, hein?
Total
Onde quer que você cuspa, em qualquer lugar você precisa de um fluxo. Para o programador sentar e apenas programar. Não calculei prazos, não fantasiei com custos trabalhistas, não reorganizei prioridades cem vezes, não compareci a reuniões, não participei de correspondências e bate-papos idiotas.
No entanto, onde quer que você cuspa, não há fluxo em parte alguma. Qualquer que seja a abordagem usada, o gerente, o cliente ou algum idiota encontrará uma razão para arrancar o programador do fluxo criativo harmonioso por causa de algum absurdo insanamente importante.
Você sempre pode retornar ao fluxo. Ou volte. Precisa, no entanto, vontade - e para retornar e manter. A coceira do monitoramento constante do trabalho do programador não dá descanso. Principalmente aqueles que não entendem nada no trabalho de um programador.