numa startup I advise, as tarefas arquivadas pela PMs para os engenheiros implementarem tinham uma prioridade baixa/média/alta.Uma vez que é uma startup inicial, há sempre mais trabalho a ser feito do que o tempo ou as pessoas, então os engenheiros nunca conseguiram fazer nenhuma tarefa baixa ou média.
assim PMs parou de preencher tarefas de baixa e média prioridade.
agora todas as tarefas são de alta prioridade. Assim, as prioridades são comunicadas informalmente:”Sim, ambos são de alta prioridade, mas X vem antes de Y”. O que naturalmente leva a desacordos: “Porque não terminaste o “A”?”Porque eu estava a trabalhar no B.” Mas ” A ” é uma prioridade maior.”Não, eles têm a mesma prioridade de alta.”
a coisa interessante é que isso não aconteceu porque um lado subverteu o sistema. Pelo contrário-ambos os lados estavam a fazer o que deviam estar a fazer no âmbito do sistema. Os engenheiros que abandonam as tarefas baixas e médias fizeram sentido porque o objetivo da priorização é dizer o que pode ser descartado quando nem todos podem ser feitos. A decisão do PMs de arquivar apenas tarefas de alta prioridade novamente fez sentido, porque Qual é o objetivo de arquivar tarefas que não serão feitas, de qualquer forma? Fazê-lo só perde tempo para todos os envolvidos. Ou arquivá-lo como alto ou não.
assim o sistema quebrou.Quais são algumas alternativas?
um método de priorização que funciona é ter prioridades que são objetivamente definidas. No Google, por exemplo, P0 significava uma emergência de produção: pare o que está fazendo e trabalhe nisso. Não é irracional as pessoas serem chamadas para consertar um P0, acordado a meio da noite. P1 significava uma tarefa excepcionalmente alta prioridade — você não precisa parar o que está fazendo para trabalhar no P1 (não é um P0), mas quando você está feito com o que está fazendo, você precisa trabalhar no P1. P2 foi usado para a maioria das tarefas. E o P3 e o P4 nunca seriam feitos.
Este sistema funcionou porque as prioridades eram objetivamente definidos e amplamente compreendido, para que as pessoas pudessem empurrar para trás e definir o direito de prioridade: “não, isso não é uma P0 — não é uma produção de emergência” ou “não, isso não é um P1 — sim, é importante, mas não têm precedência sobre todo o trabalho que temos.”Considerando que com baixo / médio / alto, uma tarefa particular é um meio ou um alto? É uma questão de opinião. Pode significar qualquer coisa, fazendo com que o sistema se desmorone.
um segundo método de priorização que funciona é para a PM definir um ciclo ou um sprint consistindo de uma lista definida de tarefas a serem feitas em um período de tempo acordado. Se uma tarefa é incluída no ciclo atual, isso significa que ela deve ser feita neste ciclo, então a prioridade é menos relevante .
um terceiro método de priorização que funciona é para a PM definir uma lista de tarefas prioritárias. Uma lista numerada onde o primeiro é mais importante que o segundo, que é mais importante que o terceiro, e assim por diante. Mais uma vez, faz sentido. Em última análise, o que importa é se um engenheiro deve fazer a tarefa X ou Y, quando não há tempo para fazer ambos. Não se X é médio em um sentido absoluto, o que não faz sentido de qualquer maneira.
em qualquer caso, não use uma prioridade baixa/média / alta. Use algo como o Trello onde você arrasta as tarefas para cima ou para baixo para definir uma prioridade implícita .
isto funciona especialmente bem se a lista inclui um objetivo de alto nível, como o recurso de lançamento X. Isso dá às pessoas a propriedade e motiva-as.
é claro, tudo isso assume que você tem PMs competente e bem intencionado. Eu trabalhei com alguns PMs de segunda categoria que tentam encaixar tantas tarefas quanto possível em um ciclo, e então estão zangados quando as coisas mais do que o esperado. Não podem dar prioridade. Eles querem tudo. Ou eles não entendem o tradeoff fundamental na gestão de projetos, ou seja, o tradeoff entre o tempo, escopo e qualidade.
ou eles entendem tudo o acima, mas usar isso para manipular engenheiros para obter mais trabalho deles. Isso não funciona por muito tempo-eu parei de dar informações relevantes para o PM, porque ele usualmente usaria isso como uma oportunidade para me criticar. Eu descartaria tudo o que ele diz. Quando ele teve um desentendimento com alguém da equipa, eu começaria por assumir que a outra pessoa tem razão.
se tiver PMs de segunda ou más intenções, nenhum método de definição de prioridades funcionará bem.
é interessante que Ferramentas de rastreamento de bugs projetadas para engenheiros não funcionam bem como ferramentas de rastreamento de Tarefas projetadas para qualquer tipo de tarefa. Isto é provavelmente por causa do viés dos engenheiros para apenas colocar uma IU em cima de um banco de dados. Mas os humanos não pensam como uma base de dados. Uma metáfora do mundo real, como um monte de cartões dispostos e classificados em uma mesa pode ser um modelo melhor.