Como você gerencia solicitações de recursos e alterações de software? [fechadas]

Sou engenheiro de software e, nos últimos anos, me tornei o gerente de projeto de software de fato simplesmente porque não há um. Portanto, para manter nossa sanidade no departamento de P & D / Engenharia, os clientes se acostumaram a me procurar com seus pedidos. Não tenho experiência neste domínio, por isso é minha primeira vez atuando como gerente de projetos de projetos de software. Eu consegui outras coisas, mas não software.

Então, como você gerencia projetos de software e marca prioridades? As solicitações são recebidas em intervalos pouco frequentes, para que possamos muito bem estar trabalhando em algo para outra pessoa e, em seguida, outra pessoa entra com um trabalho "urgente" que precisa ser trabalhado. É mais fácil dizer Primeiro a chegar, Primeiro a servir ou é a pessoa com mais dinheiro?

Descobri que quanto mais um cliente reclama da urgência de sua solicitação, a menos que também seja um desenvolvedor por si só, geralmente é um bom sinal de que a solicitação não é urgente. Um dos meus professores na faculdade sempre nos dizia para não deixar o urgente interromper o importante.

Normalmente, classifico os pedidos nesta ordem (YMMV):

1. Problemas relacionados a uma atualização ou migração recente (mais importante).
2. Correções de segurança.
3. Funcionalidade corrompida do sistema existente.
4. Funcionalidade corrompida nos recursos RC e beta.
5. Solicitações de recursos pagas.
6. Solicitações de recursos de pesquisa e desenvolvimento de grande parte da base de usuários.
7. Solicitações de recursos de pesquisa e desenvolvimento de apenas um ou dois usuários.

Este último, na verdade, leva muito mais tempo porque eles tendem a ser os pedidos "urgentes, eu preciso disso ontem". Na realidade, o usuário raramente pensou completamente no que realmente precisava ou como apoiará seu modelo de negócios. Na maioria das vezes, esses pedidos urgentes, uma vez entregues, acabam sendo usados ​​uma ou duas vezes e esquecidos. E uma vez esquecidos, eles se tornam uma dor de cabeça sem fim de brechas na segurança e consequências não intencionais.

Eu gosto dos princípios:

1. QI - Importante e Urgente
2. QII - importante, mas não urgente
3. QIII - Não é importante, mas urgente
4. QIV - Não é importante e não é urgente

1. Configure um sistema de rastreamento de recursos / erros / solicitações e solicite a seus tickets de clientes / colegas de trabalho. Se eles não apresentarem um ticket, você não estará fazendo isso. Os tickets devem ser detalhados o suficiente para serem acionáveis ​​e devem especificar uma "urgência" ("eu preciso agora" versus "é bom ter").
2. Passe por novos tickets e cuidadosamente os escaneie. Digite o custo do ticket em dólares, desenvolvedores, recursos e / ou tempo. Isto é essencial . Quando seus clientes virem o que realmente lhes custará, você verá escolhas muito diferentes no campo "urgência".
3. Diariamente, descubra sua programação com base nos tickets arquivados e na urgência deles. Torne a programação visível para outras pessoas, para que fique óbvio o que você está fazendo e sua disponibilidade para solicitações futuras.

Eu já vi projetos nos quais as mudanças de requisitos são gerenciadas por um sistema de controle de mudanças muito pesado. Isto é mau. Muitas mudanças importantes não acontecem porque o cliente não deseja passar pelo trabalho de enviar um controle de alterações, para que o software não atenda às suas necessidades. Algumas pequenas alterações são inseridas "sob o radar" para evitar o processo, de modo que o software nem coincide com o que você pensa que faz.

Por outro lado, também vi projetos nos quais o gerente de projetos pensa que "reativo" significa fazer com que os codificadores respondam a todas as solicitações dos usuários, o que significa que você nunca realiza nenhum desenvolvimento principal e que seu código se torna uma grande bagunça pesada de hackers. hackear. Essencialmente, agora você não tem nenhum desenvolvedor, você tem uma equipe de engenheiros de vendas superqualificados.

Então, pode-se esperar que exista uma situação entre esses dois pólos que funcione bem, e espero que o que funcione melhor para você seja uma escolha pessoal e situada. Definitivamente, vale a pena capturar o custo de cada alteração. Em uma estrutura como o Scrum, você pode expressar o custo em pontos da história, e a equipe pode trocar o trabalho que eles fazem em cada iteração versus o esforço total disponível. Se você tiver um gerente de produto, poderá solicitar que essa pessoa quantifique o benefício esperado de uma solicitação de alteração ou recurso. Isso geralmente é feito em termos de receita protegida (quantos clientes sairiam se você não fizer isso) e receita atraída (quantos clientes chegarão se você fizer isso). Isso pode ajudar na priorização, mas também pode refletir apenas o viés ou preferência pessoal do gerente de produto.

Aqui alguns pensamentos ...

Existem muitos softwares no mercado que ajudam você, http://www.fogcreek.com/ com Fogbugz, GeneXus USA com XPM http://www.genexususa.com/xpm , etc.

É como uma arte equilibrar solicitações de novos recursos com correções de bugs e com suas próprias idéias. Você tem que conseguir comida para o próximo inverno, mas também tem que comer hoje.

Você tem tempo, recursos e escopo, aproveita ao máximo.

Henry Ford também disse certa vez: "Se eu tivesse ouvido os clientes, teria dado a eles um cavalo mais rápido" ...

Pessoalmente: seja dinâmico, não coloque regras como as que você disse ... e tenha cuidado com as regras de outras pessoas ... elas podem funcionar bem em seu contexto, mas não no seu.

O que acabamos de apresentar foi que agora teríamos reuniões bimensais de vendas / engenharia para discutir projetos atuais e solicitações de recursos futuras ou futuras. Os engenheiros de vendas se tornarão gerentes de projeto e, pelo menos, estarão em sintonia com as últimas ofertas de produtos. No passado, era fácil transmiti-lo à Engenharia e esquecê-lo. Isso provavelmente diminuirá a carga que um engenheiro de software precisa fazer e sobrecarregará as vendas e o gerenciamento para usar nosso tempo com sabedoria.

A empresa em que trabalho utiliza dois aplicativos principais, uma ferramenta baseada na Web chamada JIRA para lidar com os aspectos relacionados ao projeto e nosso sistema de suporte técnico para lidar com a solicitação de alteração por meio da funcionalidade rfc

As respostas que vejo até agora são boas. Uma coisa que explicarei especificamente é que você precisará ser bom em dizer "não" a alguns pedidos.

Se você permitir que o cliente defina a urgência, ela quase sempre será "Alta" (ou maior).

Você (você ou uma equipe, dependendo da configuração) precisará avaliar essas solicitações e priorizá-las com base em seus próprios critérios.