De repente, percebemos que Jira se tornou um depósito de lixo. A cada segundo RP configurava Jira como era mais conveniente para ele incontrolavelmente. E quando o projeto começou a queimar, começou a apagar incêndios manualmente, deixando as tarefas no rastreador em algum estado, longe de concluídas. Se o projeto criou um IC / CD completo, a maioria das tarefas de desenvolvimento estará no status final correto, mas o restante ...
Alguns dos projetos congelaram, outros caíram, os PR foram expulsos, mas as tarefas em Jira não foram limpas. Você tem de 10 a 20 projetos em andamento e precisa entender rapidamente onde dói mais.
Comparando a experiência dos participantes nas reuniões do KiFB (Francis Bacon Club) na solução desse problema, apresentamos essa experiência de forma gravada (pela qual agradecemos a todos os participantes).
No começo, você chegava a uma organização com mais de 50 projetos, onde um rastreador foi apresentado com um grande desejo de estabelecer um gerenciamento sistemático de projetos, incluindo relatórios transparentes.
Um entendimento do estado do projeto, com base em algo que não seja a opinião do gerente de projeto (RP), é investido em objetividade.
Porque assim? Os PRs, como a maioria das pessoas, estão acostumados a ser derrotados por erros. O que o RP faz? Esconde seus erros até que seja tarde demais.
Alguns relatórios são fornecidos pela gerência financeira e legal. Pagamentos, contratos, despesas, atos etc. Mas esses recursos são de pouca utilidade para o diagnóstico precoce de problemas, se surgirem problemas no próprio processo de trabalho. Se o fluxo de trabalho for controlado pelo rastreador de tarefas, é possível obter informações dele.
(Mas é claro que isso funciona se alguém no RP ler esses relatórios, tirar conclusões e tomar decisões pelas quais são responsáveis).
Por que preciso de relatórios
Relatório não necessário para o relatório
Filmado a partir do filme "As Guerras do Pentágono". O auditor trouxe relatórios. TODOS os relatórios.
Um gerente que enfrenta uma massa de dados em uma massa de relatórios pode cair em um estupor. (Formulário de aviso: se você deseja relatórios - obtenha relatórios).
A empresa recebe dinheiro executando tarefas.
Os relatórios devem mostrar principalmente o fluxo de entrada de dinheiro futuro, o capital associado, a taxa de geração de lucro e as despesas operacionais. Se o rastreamento for usado para gerenciar alterações, também será a taxa de alteração.
Existem diferentes tipos de atividades (que ocorrem em conjunto e se complementam): design, processo, organização e pesquisa, cuja análise varia um pouco.
Atividades do projeto
Em projetos de custo fixo, é importante rastrear a taxa de combustão de um emprego. Se o trabalho for iniciado como tarefas no Jira, os relatórios (com os quais não lidamos neste artigo) podem ajudar. Outra maneira comum é rastrear o status de um projeto usando um gráfico de Gantt junto com um fato do plano de orçamento (infelizmente, as tarefas em Jira costumam ser esquecidas para fechar).
Pesquisa
A atividade de pesquisa não exige a solução de todas as tarefas atribuídas, por um lado, por outro lado, as tarefas resolvidas geralmente não geram renda. As organizações para as quais essa não é a principal atividade realizam pesquisas em equipes pequenas e ciclos curtos, nos quais o gerenciamento é realizado "nos dedos" do resultado. Os relatórios Jira ajudam pouco no gerenciamento.
Atividades de processo
Considere a atividade do processo - esta é a execução do fluxo de tarefas recebidas com pagamento vinculado à sua implementação, enquanto as tarefas chegam constantemente com certa regularidade (em outras palavras, não há escopo fixo). Por exemplo, melhorias no sistema de TI. Nesse caso, os relatórios podem refletir diretamente o status do processo.
A tarefa que chega é dinheiro futuro. Tarefa pendurada = pendurar dinheiro. Um problema que está podre (não é mais necessário) = perda de dinheiro. A tarefa para a qual o trabalho foi executado, mas que não está fechado = capital relacionado, que pode ser descartado se a tarefa falhar.
Quanto volume de negócios você tem? Essas são novas tarefas, com uma avaliação acordada com o cliente. Mas para ver isso, você precisa limpar as tarefas obsoletas e não relevantes da escória.
Qual é o capital relacionado? Nos preços de venda, essas são tarefas que foram levadas para o trabalho e não foram concluídas. Nos preços de custo, esses são os custos de mão-de-obra para essas tarefas em horas ou no valor da folha de pagamento. Menos escória.
Qual é a taxa de geração de receita? A quantia em dinheiro para resolver o problema no sprint menos o custo de propriedade da equipe. Mas, para isso, é necessário que as tarefas mudem de status + as pessoas observaram o tempo gasto no projeto. No entanto, com esses indicadores de problemas, via de regra, o menos surge.
A atividade organizacional é principalmente uma atividade de mudança.
Quão rápido você está mudando? Tem tempo para mudar? Essa é a velocidade das tarefas organizacionais e a taxa de acumulação de novas. E relatórios sobre tarefas que dependiam dos funcionários, permitindo que você lembre-se de implementar as decisões tomadas.
O caminho adicional para o Lean é suportado por relatórios mais complexos (que não foram muito abordados nas reuniões e não assinam em detalhes).
Que idéias vêm à mente:
- Perda de tempo devido a espera. A proporção de tempo gasto no tempo entre a contratação e a implementação. Tempo limite da lista de pendências.
- Perdas devido a transporte desnecessário. O número de retornos ao longo do ciclo de vida com o cálculo da perda de tempo de espera no processamento
- Perdas devido a etapas de processamento desnecessárias. Tempo de inatividade devido a estágios desnecessários na coordenação de tarefas com supervisores ou supervisores.
- Perdas por excesso de estoque. Tempo de inatividade para funcionários sem carga de treinamento, relações públicas ou pré-venda
- Perdas devido a movimentos desnecessários. Perda de tempo organizando reuniões, localizando contatos, aguardando a compilação do código e executando a unidade e outros testes.
- Perdas devido à liberação de produtos com defeito. A proporção de erros encontrados na batalha contra os encontrados no teste. A quantidade de trabalho para corrigir erros. A quantidade de trabalho em alterações devido ao preparo inadequado.
- Perdas de superprodução. Implementação de funcionalidade que não afetou o desempenho dos negócios. Perdas por testar funcionalidades não críticas ou não afetadas. Suporte para navegadores obsoletos ou suas versões.
Mas antes disso, você precisa limpar o rastreador da escória.
Limpamos Jira
Etapa 1. Nós não configuramos nada
Não altere o fluxo de trabalho, status, resoluções. Embora seja incomum lidar com status incomuns, mas são dados nos quais as pessoas investiram algum sentido.
Etapa 2. Removemos projetos antigos
Relatório no formato (Projeto, Última data da última alteração do status da tarefa).
Projetos para os quais não houve movimentos são candidatos à transferência para o arquivo.
Se a pessoa encarregada do projeto ainda estiver trabalhando, ele dirá o status, se não, a busca para encontrar um fim começa.
Transferimos as tarefas dos projetos de arquivamento para o status final com não corrigido. Existem projetos congelados. O status de tais tarefas se traduz em congelado.
Etapa 3. Removemos as tarefas antigas
Relate tarefas não fechadas com a última alteração de status menor que X (dois anos a mais do que suficiente. Mas, geralmente, se a tarefa for interrompida por 90 dias - “fica ruim”) dias, agrupados por responsável. Muito provavelmente eles estão podres, a pessoa responsável dirá (se ele for nomeado e não demitido).
Etapa 4. Remova os tipos de tarefas desnecessários
Um relatório da distribuição de tarefas não fechadas por tipo de tarefa para eliminar tipos desnecessários.
Etapa 6. Analisamos as tarefas dos demitidos
Destacamos tarefas com artistas demitidos.
É especialmente interessante observar as tarefas dos funcionários demitidos por seus superiores. O chefe do funcionário permitiu a "drenagem" do capital associado do tempo gasto na tarefa e não organizou a conclusão da tarefa.
Entramos no regulamento sobre demissão a obrigação de compensar / encerrar tarefas irrelevantes.
Etapa 5. Pesquise e analise a maior pilha
Relatório sobre status de tarefas não fechadas. Identificamos em qual status a maioria das tarefas.
Se o status for uma tarefa no trabalho, criamos um relatório sobre a distribuição de tarefas nesse status pelos artistas. Destacamos tarefas sem um executor designado, analisamos as tarefas por executores "ativos". Em alguns artistas, 2000 tarefas foram acumuladas. Hmm ...
Etapa 7. Nós padronizamos status, resoluções, ciclos de vida
Uma oportunidade de analisar igualmente qualquer projeto. Nós encontramos e quebramos a resistência do RP. Infelizmente, as pessoas não gostam de pensar em sua intercambiabilidade, um argumento típico: "Sou único no gerenciamento de um projeto, preciso de um ciclo de vida único".
Etapa 8. Estamos procurando os projetos mais problemáticos. Nós olhamos para os relatórios de combustão
Jira - pode haver dois tipos de projetos
- Projetos com um escopo conhecido de tarefas (isso acontece) em que os relatórios de combustão são aplicáveis. Às vezes acontece.
- Processos: Processando tarefas contínuas
ProjetosSe o conjunto de tarefas for iniciado, examinamos a previsão de conclusão e tomamos medidas se a previsão não for reconfortante.
Os processosAnalisamos os problemas resolvidos em relação às tarefas recebidas.
As tarefas divididas são divididas em externas e internas (treinamento, refatoração, etc.), exibimos apenas as externas no gráfico.
Como ler gráficos
Existem três gráficos condicionais:
A realidade da TI é que o trabalho envolvido na liberação de tarefas tem uma expansão estatística significativa (a menos que, é claro, sejam tarefas como conceder direitos).
Como resultado, para garantir o SLA necessário para suporte, os recursos devem ser planejados com uma margem; caso contrário, isso levará ao acúmulo de tarefas nos buffers de tarefas recebidos, o que tornará os prazos inadmissíveis. As pessoas nem sempre estarão ocupadas com as tarefas recebidas, realizando treinamento ou outro trabalho não essencial durante os intervalos.
No processo de desenvolvimento de produtos, eles tentam impedir que os desenvolvedores fiquem inativos para garantir velocidade máxima de desenvolvimento = ganhar dinheiro. Para fazer isso, você sempre deve ter um suprimento de tarefas no backlog, o que significa que parte da tarefa geralmente não será realizada e, como as tarefas estão gradualmente perdendo relevância, isso significa que as tarefas nunca serão realizadas.
Opção A
É normal que seja uma implementação de recursos. Mais recursos entram na entrada do que a equipe pode digerir.
Se isso é suporte (administração e correção de bugs), a situação é ruim. Quanto mais erros, mais lenta é a correção. Quanto mais lenta a correção, mais erros se acumulam. Algo está passando sob o barril de pólvora. Tick-to-tick-to-tick ....
Opção B
Se uma equipe executar exatamente tantas tarefas quanto a lista de pendências, isso significa que
- o backlog é mantido em outro projeto / local e, como resultado, você não vê rotatividade futura nos relatórios e não pode tomar uma decisão com base nos relatórios sobre a importância de aumentar o tamanho da equipe,
- ou as pessoas inventam tarefas para si mesmas no momento da inatividade (sobre sensações e intuição, sem custdev, análise de mercado etc.); Quantas tarefas não são claras e isso é alarmante (e se já houver 90% delas),
- ou os relatórios são falsificados.
Opção C
OK, se for suporte. A equipe deve ter tempo de inatividade para poder resolver rápida e eficientemente problemas e tarefas.
Se essa é uma implementação de recursos, a situação geralmente não é normal. Depois que o acúmulo de tarefas foi acumulado, o que é mais rápido do que o novo. Por que isso poderia ser?
- Por exemplo, a equipe aumentou dramaticamente e está analisando a dívida, mas, ao mesmo tempo, as necessidades dos negócios não estão mais crescendo. A empresa não responde (não conseguiu reagir) ao crescimento de oportunidades ou pior, o produto tomou seu lugar e parou de crescer.
- Ou o produto estagna e não requer desenvolvimento.
- Ou o marketing parou de criar novas oportunidades.
Etapa de segurança de acesso ao palco
Pegamos tarefas com links na Internet para o Google Dox. Todos os documentos devem estar dentro do perímetro, definimos a tarefa de transferir materiais para dentro
Etapa de controle do analista
As etapas são feitas onde?
Opção A. Direito na gordura.
Opção B. No funcionário do Google Doks.
Opção correta: Uma alteração na funcionalidade geralmente deve ser acompanhada de uma alteração na documentação técnica e de trabalho no Confluence. Como controlar isso?
Vinculamos a página de instruções à tarefa em fat (basta inserir o link, isso levará automaticamente à criação de links bidirecionais).
Criamos um relatório sobre alterações de página na confluência e o resumimos nas análises com os relatórios Jira sobre melhorias nos custos de mão-de-obra. Todas as melhorias com custos significativos de mão-de-obra devem estar correlacionadas com as alterações nos artigos.
Agradecimentos
Agradecemos aos membros ativos do KiFB pelos materiais preparados e pela organização da discussão, e a todas as pessoas que participaram da discussão.