Como você gerencia um grande atraso produto? [fechadas]

https://stackoverflow.com/questions/109141

01-07-2019
|

Pergunta

Temos um grande acúmulo de coisas que devemos fazer em nosso software, em um monte de diferentes categorias, por exemplo:

Novas áreas problemáticas para os nossos produtos para resolver
A nova funcionalidade de suporte áreas problemáticas existentes
A nova funcionalidade solicitada por nossos usuários existentes
Usabilidade e "olhar" melhorias
atualizações de arquitetura para o back-end
Correções de bugs

Gerir todos estes de uma forma sensata é um trabalho que cai para Gestão de Produtos, mas é complicado para uma série de razões. Em primeiro lugar, temos um número de diferentes sistemas que mantêm as coisas diferentes (documento de requisitos do mercado em arquivos, erros em um banco de dados de erro, os requisitos do cliente em nosso sistema de help desk, lista de desejos de enginering em nossa intranet, etc). E em segundo lugar, muitos dos itens são de tamanho totalmente diferente, o escopo, complexidade e de valor claro, o que significa que escolha não é tão simples como apenas encomendar uma lista por prioridade.

Porque nós agora são bastante grande, tem um produto complexo e muitos clientes, as soluções básicas (uma planilha, um documento do Google Docs, um basecamp lista de coisas a fazer) só não é suficiente para lidar com isso. Precisamos de uma forma de agrupar coisas juntas de várias maneiras, priorizá-los em uma base contínua, deixar claro o que estamos fazendo eo que está vindo -. Sem ele exigindo todo o tempo de alguém para apenas gerenciar alguma ferramenta

Como você administra isso de uma maneira que permite a empresa a fazer sempre o que é mais valioso para os clientes existentes, ajuda a obter novos, e mantém a sã entranhas de software?

Note que isto é diferente do lado do desenvolvimento, que eu acho que nós temos para baixo muito bem. Desenvolvemos tudo de forma iterativa, ágil, e uma vez que algo foi escolhido para o projeto e implementação, podemos fazer isso. É a parte onde precisamos descobrir o que fazer a seguir desse mais difíceis!

Você encontrou um método ou uma ferramenta que funciona? Se assim for, por favor, compartilhe! (E se você gostaria de saber a resposta também, avaliar a questão, para que fique visível:)

Adenda: É claro que é bom para corrigir todos os erros primeiro, mas em um sistema real que realmente está instalado nas máquinas dos clientes, que nem sempre é prático. Por exemplo, podemos ter um erro que só ocorre muito raramente e que levaria uma enorme quantidade de tempo e revolta de arquitetura para fix - podemos deixar isso por um tempo. Ou podemos ter um bug em que alguém acha que algo é difícil de usar, e achamos que a fixação deve esperar por uma maior reformulação da área. Assim, existem muitas razões pelas quais nós não apenas corrigi-los todos de imediato, mas mantê-las abertas para que não se esqueça. Além disso, é a priorização dos não-bugs que é o mais difícil; imaginem não temos qualquer:)

Solução

A gestão de um grande atraso de uma forma agressiva é quase sempre um desperdício. No momento em que você começa a meio de uma priorizados pilha coisas têm mais frequentemente do que não mudou. Eu recomendo adotando algo como o que Corey Ladas chama um filtro de prioridade:

http://leansoftwareengineering.com/2008/08/19/priority-filter /

Essencialmente, você tem alguns baldes de aumentar o tamanho e diminuindo prioridade. Você permite que as partes interessadas para preenchê-los, mas forçá-los a ignorar o resto das histórias até que haja aberturas nos baldes. Muito simples, mas muito eficaz.

Editar: Allan perguntou o que fazer se as tarefas são de tamanhos diferentes. Basicamente, uma grande parte de fazer esse trabalho é dimensionar direito suas tarefas. Nós só aplicar esta priorização de histórias de usuários. histórias de usuários são tipicamente significativamente menor do que "criar um site da comunidade". Eu consideraria o site da comunidade mordeu um épico ou mesmo um projeto. Seria preciso ser dividido em pedaços significativamente menores, a fim de ser priorizada.

Dito isso, ele ainda pode ser um desafio para fazer histórias de tamanho similar. Às vezes você apenas não pode, de modo que você se comunicar que durante suas decisões de planejamento.

Com relação ao movimento Wibbles dois pixels, muitas dessas coisas que são fáceis pode ser feito por "livre". Você apenas tem que ter cuidado para equilibrar estes e só fazê-los se eles estão realmente perto de livre e eles são realmente um pouco importante.

Nós tratamos erros semelhante. Erros obter uma das três categorias, agora, mais cedo ou eventualmente. Nós corrigir agora e os erros que rapidamente quanto possível com a única diferença é quando publicar as correções. Eventualmente erros não obter correção a menos devs se cansar e não têm nada para fazer ou que de alguma forma tornar-se maior prioridade.

Outras dicas

A chave é categorização agressivo e priorização.

Corrigir os problemas que estão mantendo os clientes afastado rapidamente e adicionar mais recursos para manter os clientes chegando. Empurrar para trás questões que só afetam um pequeno número de pessoas, a menos que eles são muito fáceis de corrigir.

Uma técnica simples é usar uma matriz de priorização.

Exemplos:

Também é útil dos quadrantes de priorização (duas dimensões: Importância, Urgência) que Covey propõe: http : //www.dkeener.com/keenstuff/priority.html . Concentre-se no importante e urgente, então a importantes e não urgentes. O material não-Importante ... bem .. se alguém quiser fazer isso em suas horas de folga :-). Uma variante do Covey quadrantes que eu usei é com as dimensões de importância e facilidade. Facilidade é uma boa maneira de priorizar as tarefas dentro de um quadrante Covey.

Eu acho que você tem que pegá-los todos em um só lugar para que o podem ser priorizados. Tendo para agrupar várias fontes diferentes faz com que este praticamente impossível. Uma vez que você tem que então alguém / um grupo tem que classificar cada bug, recurso solicitado e desenvolvimento desejado.

As coisas que você poderia priorizar por são:

Valor adicionado ao produto
importância para os clientes, actuais e potencial
dimensão da tarefa

Você deve corrigir todos os erros em primeiro lugar e só então pensar sobre a adição de novas funções a ele.

Todo este material pode ser monitorado por um sistema de rastreamento bom bug que tem as seguintes características:

Capacidade de itens de trabalho marca como bugs ou solicitações de melhoria
campo Categoria para a região de responsabilidade que o item de trabalho se enquadra (UI, back-end, etc)
Versão # campo para quando a correção ou recurso está programado para ser feito
campo Status (em andamento, completou, verificado, etc)
campo Prioridade

Uma vez que você já está fazendo as coisas de maneira ágil, você pode tomar emprestado algumas idéias de XP:

put todas suas histórias em grande pilha de cartões de índice (ou alguma ferramenta)
Agora os desenvolvedores devem estimar quão grande ou pequeno essas histórias são (aqui os desenvolvedores têm a palavra final)
e deixe cliente (ou seu procurador - como gerente de produto) a fim dessas histórias por seu valor de negócio (aqui cliente tem a palavra final)
e se os desenvolvedores pensam que há algo técnico que é mais importante (como corrigir estes erros traquinas), eles têm que comunicar que a cliente (pessoa de negócios) e o cliente faça a subir que a prioridade (cliente ainda tem a palavra final)
selecione como muitas histórias para a próxima iteração como seu equipes velocidade permite

Desta forma:

não há uma única fila de tarefas, ordenados por necessidades de negócios
clientes a obter melhor retorno para seu investimento
unidades de valor do negócio, não a tecnologia ou os geeks
desenvolvedores começar a dizer como as coisas difíceis são para implementar
se não houver ROI , estadias tarefa quase inferior do que a pilha

Para obter mais informações, consulte Programação Planejamento Extrema por Kent Bech e Martin Fowler . Eles dizem que muito melhor do que eu jamais pode fazer.

Eu não tenho certeza se a ferramenta é tão crítico quanto o processo. Eu vi equipes de ser muito bem sucedido usando algo tão simples como cartões de índice e quadros brancos para gerenciar bastante grandes projectos. Uma coisa que eu recomendaria na priorização é se certificar de que você tem uma lista abrangente de esses itens juntos. Desta forma, você pode pesar a prioridade de fixar um problema vs. um novo recurso, etc ..

Além de qualquer ferramenta e processo, deve haver ... algumas pessoas;)

Na nossa loja, ele é chamado de Gerenciador de Lançamento e ele determina o próximo perímetro funcional para enviar para a produção.
Depois, há um Congelar Gestor que realmente sabe sobre o código e os arquivos e bugs (ele é geralmente um dos programadores), e irá impor as escolhas do gerente de lançamento, e monitorar as fusões necessárias, a fim de ter algo a prova e depois solte.

Entre eles dois, uma priorização pode ser estabelecida, tanto de alto nível (solicitações funcionais) e de baixo nível (bugs e problemas técnicos)

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow