Percebi um padrão ao trabalhar em vários projetos de software: a grande maioria dos bugs relatados tinha uma prioridade alta / muito alta. Perguntei a alguns colegas sobre por que isso pode estar acontecendo e eles mencionaram que, se um bug não tem esse nível de prioridade, é muito raro que o Bug receba a atenção do desenvolvedor, o que de fato faz sentido.
Então, eu queria saber se esse problema é comum ou se apenas tive azar. Fiz uma pesquisa rápida no Google e descobri que algumas equipes implementam as diretrizes de relatórios de erros ou têm uma equipe "Triagem de erros" separada. Se você enfrentou e resolveu esse problema, qual foi a abordagem que funcionou para você?
Esta pergunta é especificamente sobre o problema "Inflação prioritária": se você enfrentar o cenário e quais medidas resultam efetivas contra esse problema.
fonte
Respostas:
Na verdade, se você me perguntar, isso não acontece. Quanto mais níveis de prioridade (usados), mais informações você tem. Se você efetivamente tem apenas uma prioridade, é a mesma coisa que não ter nenhuma prioridade.
E como você ainda tem o mesmo número de bugs para resolver e a mesma quantidade de horas de trabalho para fazê-lo, segue-se que outras heurísticas serão usadas, possivelmente a nula - "primeiro a chegar, primeiro a ser servido". E agora você tem uma métrica de prioridade de bug, exceto que é a hora de chegada e não está mais sob seu controle.
Pode ser um sintoma de não haver recursos suficientes sendo alocados para a correção de bugs (existem algumas políticas como " Nenhum novo recurso até que os bugs sejam corrigidos " que podem ajudar lá. Joel aprova ; entender limites e consequências é uma decisão de negócios ).
Em um projeto em que trabalhei, os bugs recebidos foram acumulados em um "buffer sem prioridade" e toda segunda-feira revisávamos a lista de bugs, calculávamos a dificuldade (uma estimativa muito aproximada; na maioria das vezes, apenas colocávamos "Média") e classifique-os pelo tempo disponível. Isso tendia a esbarrar na lista de bugs chatos, desinteressantes ou considerados difíceis; para compensar isso, os supervisores e o marketing tinham um certo número de créditos por semana que poderiam gastar para aumentar a prioridade dos bugs favoritos e eram reembolsados por bugs não resolvidos (isso estabelecia um limite de quanto um bug desprezado pelo desenvolvedor poderia ser adiado) .
Também foi possível mesclar, cancelar e dividir bugs; Lembro-me de um módulo que era tão irremediavelmente defeituoso que afundamos cerca de vinte ou trinta relatórios de erros em um único "reescrevemos essa coisa do zero", que foi então dividido em "declarar claramente as entradas e saídas da coisa miserável", "escrever testes para garantir que as entradas e saídas correspondam às especificações "e assim por diante. O último item foi "imprima o código antigo em papel reciclado, traga-o para o gramado e incendie-o" (também fizemos isso. Lembro-me de como foi bom. Revezamos o elogio; foi hilário )
Após algumas discussões, tínhamos a lista de tarefas da semana, dividida em "vai fazer", "pode fazer" e "não pode fazer" que foram enviadas para a semana que vem. Foi aqui que algumas discussões adicionais ocorreram: tínhamos cinquenta horas para alocar os bugs e tínhamos 95% de certeza de consertar as primeiras vinte. A gerência queria fortemente que um vigésimo primeiro bug fosse corrigido e não houvesse créditos; então ofereceríamos trocar esse bug por outro na lista "Will do", ou alguém diria "Tire-me da subequipe do FooBazFeature por alguns dias e eu o farei" ou diríamos "Precisamos de mais mão de obra ".
O sistema não satisfez ninguém, na verdade, mas acreditava-se que (pelo menos entre os desenvolvedores) fosse um bom sinal.
Alguns padrões negativos adicionais que apareceram foram o "Desejo de Pensar" da parte dos gerentes ("Você declarou que o bug 57212 requer oito horas. Isso é inaceitável. Faça quatro") e o "Debug by Fiat" ("Faça o que quiser" mas esses quarenta bugs devem ser corrigidos antes da grande demonstração na próxima semana. Você não pode ter mais tempo, não pode ter mais pessoas "). Também a Síndrome de Boxer ("Eu trabalharei mais"), que tendia a funcionar muito bem por um curto período de tempo , mas geralmente levava um desenvolvedor a surtar ou partir para pastos mais verdes.
fonte
Se você tiver esse problema em que os usuários estão atribuindo erros de prioridade cada vez mais alta, a única solução realista é um mecanismo de triagem. Todos os bugs são relatados com a prioridade que quiserem, mas algum gerente ruim precisará passar por todos os bugs relatados recentemente e redefinir sua prioridade para um nível razoável.
Depois de um tempo, os usuários receberão a mensagem ou você poderá alterar o sistema de relatórios para que cada bug tenha uma prioridade padrão. Se eles quiserem que ele seja escalado, eles terão que entrar em contato com alguém para fazer a verificação, o que exigirá alguma justificativa. Somente esse fato fará com que 99% de todos os bugs sejam deixados sem escalação pelo usuário.
Obviamente, você tem mais bugs do que pode processar, então talvez seja necessário embarcar em um resumo de correção de bugs para limpar a lista de pendências. Isso mostrará aos usuários que seus bugs serão corrigidos sem precisar que sejam marcados como super-super-dooper-realmente-não-honestos-desta vez-importantes.
fonte
AVISO LEGAL: Eu ainda não tive experiência com travessuras de prioridade de bug relatadas pelo usuário. Eu sei que a pergunta pede isso, mas pode ajudar a ter a perspectiva de alguém de fora.
Seu problema não é que você tenha muitos erros de alta prioridade. Seu problema é que você tem muitas pessoas que têm controle direto sobre a prioridade dos erros. Se todos os usuários puderem atribuir diretamente uma prioridade ao seu bug, eles reportarão quase automaticamente seu problema como alta prioridade.
Você pode fazer com que a prioridade do bug tenha que ser configurada por um gerente ou um zangão de suporte técnico, mas isso pode levar a favoritismo e engenharia social, onde um cliente recebe prioridade artificialmente mais alta por causa de seu status ou porque sabe como criar suas mensagens para fazê-los parecer mais importantes. Também é muito mais trabalhoso.
Existe um meio termo, em que seus usuários têm algum controle sobre a prioridade, mas de uma maneira que dificulta a exploração do sistema. Essencialmente, você força seus usuários a usar um modelo para relatar erros. Eles primeiro selecionam uma categoria:
O programa me permite fazer algo que não deveria ser capaz de fazer.
Para dar exemplos:
Como você pode ver, cada um desses erros tem um grau de gravidade diferente e as categorias são ordenadas aproximadamente com base nessa gravidade. Você pode então atribuir a cada bug uma prioridade com base na categoria, que relata e as palavras-chave que aparecem na descrição. Os erros na categoria 7 devem ter sua prioridade atribuída manualmente.
Observe que isso pode acontecer totalmente automaticamente, e você deve deixar isso acontecer automaticamente; de fato, a automação é a chave aqui. Os usuários tendem a superestimar sua própria importância para os negócios, portanto, não veem problema em relatar seus erros como uma prioridade mais alta do que deveriam. eles são menos inclinados a colocar deliberadamente seu bug em uma categoria diferente, porque isso exige que eles basicamente mentam sobre o bug.
Os usuários ainda podem inserir seus erros na categoria errada, é claro. A primeira coisa que você deve fazer é, a partir da versão 1.0, mostrar uma mensagem amigável incentivando os usuários a fornecer informações precisas sobre o bug para ajudar os desenvolvedores a encontrá-lo e corrigi-lo mais rapidamente. A maioria dos usuários entende e interrompe a declaração de erros. Alguns usuários ainda podem continuar fornecendo informações incorretas. Quando isso acontecer, envie a esses usuários um lembrete gentil por e-mail de que informações precisas são importantes e que não devem abusar do sistema. Se eles continuarem falsificando registros, você avisará que eles estão abusando voluntariamente do sistema e que o abuso continuado resultará na atribuição automática de seus erros a uma categoria inferior. Se eles persistirem, você pode ajustar o multiplicador de erros.
Você pode ver partes deste sistema em situações de suporte de alto rendimento: empresas gigantes de tecnologia como Microsoft, Facebook, Google, empresas de jogos com muitos usuários como Valve e Blizzard, certos governos, ... Embora eu não tenha certeza dos trabalhos por trás dos bastidores, você percebe que o sistema de suporte voltado para o usuário tem uma interface semelhante à sugerida aqui, com um sistema estrito de categorias.
fonte
Como as pessoas disseram, é por isso que as pessoas que relatam bugs não conseguem atribuir prioridade. Sua equipe de desenvolvimento deve controlar a própria atribuição de tarefas (dentro do escopo definido pelo gerenciamento superior). Então, alguém mais adiante diz "trabalhe neste aplicativo, conserte esse recurso, melhore- o ", e a equipe decide como proceder, porque são eles que têm o conhecimento técnico necessário para avaliar como melhor para alcançar o que a gerência deseja.
As pessoas que relatam os erros devem atribuir níveis de impacto ou gravidade , que têm escopo definido. Você pode facilmente chamar as pessoas por não aderirem aos níveis acordados de gravidade, porque você possui evidências materiais para esses níveis. Por exemplo:
Para começar, você pode usar esses níveis como um instrumento cego para apontar que um desalinhamento de algum texto do título não é um bug de Nível 1 porque não está inutilizando o aplicativo inteiro. Depois que eles tiverem a idéia, você poderá torná-la mais refinada e começar a debater se a falha na atualização dessa caixa de texto é de nível 5 porque você pode corrigi-la clicando com o botão direito do mouse na caixa de texto algumas vezes ou no nível 4 porque está diminuindo a velocidade de todos na Contabilidade, para que obtenham menos formulários processados por hora.
Depois de obter informações úteis e mensuráveis sobre quão ruim é o bug para sua organização , a atribuição de prioridade se torna óbvia. O que quer que esteja atualmente causando o maior problema para a organização - lucros perdidos, danos à imagem pública, infelicidade dos funcionários, o que for - será de alta prioridade e você trabalha a partir daí.
fonte
É mais ou menos assim:
Mons.: No que você está trabalhando? Dev: esta tarefa de baixa prioridade Mons.: Você não deveria estar trabalhando em tarefas de alta prioridade?
Cliente: quando meu bug será corrigido? Dev: é de baixa prioridade, temos tarefas de alta prioridade. Cliente: oh, bem, então defina meu status de bug como alta prioridade.
Isso levará a níveis cada vez maiores de prioridade. Vejo que você já foi além da alta prioridade para a muito alta prioridade. O que virá a seguir são:
etc etc.
Sim, este é um processo normal. Desde que não haja custos envolvidos na atribuição de prioridade e o chamador tenha influência, é claro que eles tentarão resolver o problema da maneira mais rápida e definir a prioridade mais alta.
Existem basicamente duas maneiras de combater isso:
fonte
Pode-se adicionar níveis de prioridade cada vez mais altos ao sistema, especialmente se for o Jira. Dar às novas prioridades altas nomes cada vez mais tolos, mas terríveis, pode aumentar o impacto do efeito Hawthorne na qualidade das escolhas de prioridades feitas por todas as partes. Se a prioridade mais alta tiver um nome realmente estranho, o efeito poderá ser permanente. Eventualmente, quando alguém escolhe uma prioridade, ele tem que pesar as consequências sociais de escolher a prioridade do "bug da morte" versus obter a devida atenção. Portanto, a prioridade mais alta é de fato reservada para algo que aconteceu com o CTO em casa na frente de seus convidados ou para outros incidentes de visibilidade equivalente.
fonte
Introduzir um custo para suportar solicitações. Você só pode permitir que um usuário relate X número de itens de alta prioridade em um determinado período de tempo, número Y de itens de prioridade média e Z de baixa prioridade.
Obviamente, isso também significa que a equipe de desenvolvimento e a gerência terão que garantir que um certo número deles seja corrigido - todos os itens de alta prioridade, a maioria dos itens de prioridade média e (talvez) alguns dos itens de baixa prioridade dentro de um determinado período.
Mas, se isso funcionar, a gerência terá que se comprometer, caso contrário, todo o exercício será uma perda de tempo.
No final do dia, porém, sua situação específica parece ser um sintoma do problema de que seu gerenciamento não está alocando recursos suficientes para lidar com problemas de suporte. Se os problemas estivessem sendo tratados em tempo hábil, não acho que isso estivesse acontecendo.
Algo assim foi implementado na primeira empresa em que trabalhei, pois o processo de suporte era disfuncional e levou a uma situação em que, se tudo é uma emergência, nada é. No nosso caso, após controlar a situação interna, o novo gerente de desenvolvimento de software impôs um limite rígido ao número de questões de alta prioridade que um cliente poderia apresentar, dependendo de quanto pagava nos contratos de suporte. Se ultrapassassem o limite, tossiam mais dinheiro ou a questão do suporte era reduzida em prioridade.
fonte
Isso acontece com muita frequência em grandes empresas onde a TI é vista como auxiliar e / ou terceirizada. As pessoas de negócios não entendem software e não se importam, tudo o que se importa é que o bug "deles" seja corrigido ontem, independentemente de não ser crítico. Eles não percebem, ou se importam, que há centenas de outros usuários também arquivando bugs e uma equipe de talvez 5 desenvolvedores disponíveis para consertar as coisas.
Isso é exacerbado pelo gerenciamento deficiente, especialmente os gerentes que não são de TI, que não podem dizer "não" ou que simplesmente deixam as pessoas de negócios definirem prioridade de bug. (Nos dois casos, o gerente não está realizando seu trabalho.) A maioria dos gerentes priorizará o bug sobre o qual eles foram contatados pela última vez porque "é urgente"; o resultado final é que os desenvolvedores acabam pulando de bug em bug, corrigindo um único bug leva mais tempo (alternância de contexto) e, no final do dia, todo mundo fica infeliz. "Quando todo bug é de alta prioridade, nenhum bug é de alta prioridade."
Eu já estive nessa situação, e geralmente a única maneira de escapar dela é sair. As diretrizes de relatórios de erros são sempre ignoradas, porque os usuários não dão **. A tentativa de introduzir a triagem de bugs será resistida ou será implementada e depois ignorada na próxima vez que um usuário ligar para o gerente para reclamar do bug "deles".
Basicamente, se os desenvolvedores não têm controle sobre a prioridade , você já perdeu.
fonte
Como empresa, você deseja resolver os problemas com a maior relação importância / custo. O usuário decide a importância, a engenharia decide o custo. Se os usuários atribuírem a mesma importância a todos os bugs, apenas os custos serão importantes.
Na prática, isso significa que você define prioridade como importância / custo e não permite que usuários ou desenvolvedores definam essa prioridade diretamente. Nenhum dos lados tem a imagem completa.
Se os usuários decidirem classificar todas as questões igualmente importantes, tudo bem - mas isso significa que a engenharia (custo) decide o que é feito. Explique a eles que a importância é a única maneira pela qual eles podem influenciar (mas não decidir) a prioridade.
fonte
Alguns fatores ...
Então, acho que todos os relatórios de erros precisam ser analisados RAPIDAMENTE por um a dois desenvolvedores experientes, adicionando seus pensamentos ao relatório de erros e, em seguida, o bug precisa ser triado. Esperar que a pessoa que encontra o bug possa definir uma prioridade útil no momento em que o encontra, está pedindo demais.
fonte
É bem possível que todos os bugs mencionados sejam de alta prioridade. Estive em projetos com subfinanciamento e subespecificação, e quando o teste começou o controle de qualidade, os usuários desistiram de relatar itens de baixa prioridade, porque sabiam que erros ortográficos ou falhas na usabilidade eram uma perda de tempo, se a funcionalidade principal do projeto foi completamente mangueira. Se o seu sistema automatizado de bagagem estiver colidindo com carrinhos e destruindo bagagens , quem se importa se a fonte nas tags for 2pt muito pequena?
Em uma situação como essa, o projeto está falhando. Se você suspeitar que isso seja uma possibilidade, precisará de um coração para as pessoas que relatam defeitos para descobrir. Se as pessoas estão inflando relatórios de erros, as outras respostas ajudarão. Se os erros forem tão ruins quanto os relatados, você precisará tomar medidas extremas .
fonte
A maioria já foi dita, mas eu destilaria a lista "bug zoo" para algo um pouco menos granular:
R: O bug interrompe o usuário em suas trilhas, produz resultados incorretos, geralmente torna o sistema / recurso / função inutilizável. Esse é um bug de "alta prioridade".
B: Tudo o resto. Estes são erros "negociáveis".
Os erros NEGOCIÁVEIS se enquadram em uma variedade de preocupações (que você colocaria em sua ordem específica):
1: Erros que afetam a segurança;
2: Erros que afetam a usabilidade (adequação ao objetivo pretendido);
3: Erros que afetam a estética;
4: Bugs que afetam o desempenho (talvez um subconjunto de usabilidade?);
5: Erros que ofendem sua sensibilidade como programador profissional;
6: Erros que diminuem a CONFIANÇA DO USUÁRIO;
Portanto, esse é o mundo utópico em que nenhum de nós vive. Suspiro Para concluir minha resposta à pergunta declarada pelo OP, em toda a indústria de software, é absolutamente comum que os esforços de desenvolvimento estejam em um status em que cada bug seja uma prioridade - um-super-banger-especial. E você sabe o que eles dizem sobre "especial": quando todo mundo é especial, ninguém é especial.
fonte
Basicamente, esse problema está enraizado no problema da priorização descentralizada. Sempre deve haver um número ímpar de pessoas com capacidade de priorizar a carga de trabalho de uma equipe, e 3 é demais. Para que uma pessoa seja responsável pela triagem eficaz. E deve ser um gerente / analista, em consulta com um líder / arquiteto de desenvolvimento. E o processo é bastante simples e também pode ser aplicado a solicitações de recursos. Qual o custo de fazer o desenvolvimento? Qual é o valor do resultado esperado para os negócios. A saída dessa função é a prioridade atribuída.
É claro que todo usuário deseja que seu problema seja corrigido primeiro. E assim que você permitir, caos. Você não tem priorização válida. Você precisa fazer isso por uma ÚNICA pessoa com autoridade (consultando outras pessoas quando necessário), com VISIBILIDADE em TODAS as questões e necessidades de negócios, e competente o suficiente para reunir os conselhos de negócios e de TI necessários e gerar estimativas razoavelmente precisas das métricas acima.
fonte
Correndo o risco de afirmar o óbvio, vou assumir que não há software de rastreamento de bugs que esteja configurando os bugs para alta prioridade como padrão (ou tenha sido definido para essa configuração).
Receio que, na ausência de controles, este seja o cenário padrão para várias equipes, clientes etc. informando. Se o status quo estiver sendo abusado, algum tipo de processo de triagem está definitivamente em ordem.
Uma vitória rápida que vi funcionar muito bem no passado é que o P1 (bugs de prioridade máxima) gera uma infinidade de alertas de gerenciamento. Se o sistema tiver sofrido abuso, ele será imediatamente derrubado. Ou, se for realmente urgente, uma teleconferência ou reunião física ocorrerá o mais rápido possível.
Estou assumindo aqui que você está falando de todos os bugs, não apenas daqueles do desenvolvimento inicial. Se você costuma contratar uma arma de desenvolvimento em campo verde, certamente não é incomum que a maioria dos bugs seja de alta prioridade após o lançamento inicial do alfa.
fonte
Você não pode simplesmente ter uma prioridade e esperar que tudo funcione magicamente. Às vezes, as pessoas descobrem por conta própria, mas nem sempre.
Para atribuir prioridades corretamente, deve haver uma definição exata do que constitui cada prioridade. Esses critérios devem ser objetivos, para evitar o favoritismo de bugs e a priorização política. Se os critérios objetivos não forem seguidos, você precisará fazer com que a equipe os siga.
Não há realmente nenhuma maneira de contornar isso - se você não pode ter critérios objetivos para o erro, e se as pessoas se recusarem voluntariamente a cumpri-los, é possível que você também não tenha prioridades atribuídas por submissores - fique sem prioridades ou tenha um terceiro atribui prioridade como outros sugeriram. Os dados de crowdsourcing somente funcionam se os remetentes são cooperativos e não sabotam ativamente a coleta de dados.
Se surgir a dificuldade de não conseguir criar critérios objetivos, você poderá usar critérios relativos:
Xé que ele deve ser mais importante do que todos os bugs em prioridadeX-1.Xpode exceder o número de bugs com prioridadeX-1.Mas parece que seu problema não é a definição, mas a crença entre os remetentes de que os erros de baixa prioridade não são corrigidos. Presumivelmente, você não pode convencê-los de outra maneira, pois (pelo que você diz) a crença deles se baseia de fato. Então, por que você os faz enviar esses bugs? Isso acaba sendo apenas trabalho ocupado. Você pode, por exemplo, depois de atingir um certo número de bugs ativos, dizer a todos para não se incomodarem em fazer relatórios, a menos que sintam que encontraram algo mais importante do que a maioria dos bugs pendentes. Concedido, esta é apenas a solução da fila com um limite superior no comprimento da fila.
fonte