Como lidar com mudanças frequentes de requisitos?

Estou lidando com uma situação bastante estressante (na minha opinião) no meu local de trabalho atual.

Começamos a desenvolver um novo projeto, obtemos alguns requisitos, o implementamos e depois mostramos a alguém que você pode chamar de 'consultor de negócios' (pessoa que conhece os requisitos de negócios, mas não usa o programa). Essa pessoa deve avaliar a aplicação do ponto de vista dos clientes, testá-la etc.

Aqui está a aparência do 'processo':

1. consultor de negócios fala à noite com meu chefe por uma ou duas horas no windows messenger
2. no dia seguinte, recebo e-mail com cópia dessa conversa. Devo escolher tarefas a partir disso, verificar bugs relatados (que geralmente não são bugs, apenas testes ruins e esquecer os estabelecimentos anteriores)
3. Eu implemento mudanças, a implementação é aceita e, em uma semana ou duas, acontece que não é o que eles querem (eles conversaram com algum cliente em potencial que viu o software por 5 minutos e ele sugeriu alterações) - eu tenho que fazer novas alterações

Não me interpretem mal, eu entendo que às vezes os requisitos mudam. O que me chateia é a frequência com que as alterações ocorrem no meu local de trabalho e a facilidade com que o 'gerenciamento' oferece dois requisitos novos ou, às vezes, alterações fundamentais nos recursos existentes.

Ao mesmo tempo, estamos trabalhando em prazos apertados e tenho a impressão de que, em vez de seguir adiante com nosso software, estamos executando círculos.

Peço conselhos de você como lidar com esta situação? Esta é uma situação normal e eu sou apenas hipersensível a isso?

Se possível, pegue a conversa por e-mail e transforme-a em um documento de requisitos. Liste as tarefas que você pode recolher e ordene-as pelo que você considera prioritário e atribua uma estimativa a cada uma delas. Em seguida, pergunte quais recursos eles desejam para o próximo lançamento.

Basicamente, force algum tipo de loop de feedback em que a gerência esteja ciente do que você irá criar. Escreva seus próprios documentos de requisitos até que eles recebam a mensagem.

História Cartões

Acho que sua situação é adequada para a introdução de histórias de usuários . Eles são realmente úteis para fornecer uma maneira interativa e contínua para o seu gerente definir prioridades e ele pode até jogá-las fora quando voltar à ideia uma semana depois e perceber que não é viável.

No mundo real, os requisitos mudam rotineiramente. No lado positivo, você descobre isso antes de concluir a criação do software e enviá-lo - você tem um ciclo de feedback rígido do usuário direto do software, o que é realmente ótimo.

Parece que o maior problema aqui é a maneira muito ad-hoc de gerenciar as mudanças. Você tem o que o ágil / Scrum considera um "proprietário do produto", que fornece feedback, mas o processo é pouco documentado e mal pensado.

Você provavelmente deseja examinar os modelos no Scrum e a visão deles sobre o que é um proprietário de produto eficaz , para ajudar a informar seus próximos passos.

Portanto, em vez de ter esse processo ad-hoc, tente mudar para um mundo em que você tenha um relacionamento mais próximo e útil com o "consultor de negócios" e onde todos estejam na mesma página sobre os resultados das mudanças que estão discutindo .

Seu processo atual facilita demais para essas pessoas debaterem idéias sem levar em consideração os recursos e o dinheiro que isso consumirá. Se eles querem todos esses recursos, precisam obter uma "aparência do jogo".

Pegue esse e-mail da conversa e coloque-o em algum tipo de aplicativo de rastreamento de bug / recurso, mesmo que seja apenas uma planilha. Envie as novas adições de volta ao consultor comercial e peça que ele assine cada item ou forneça correções. Juntamente com a assinatura, eles devem priorizar (quais você deseja primeiro?).

Depois que eles aprovarem, envie-os de volta a sua programação sobre quando os itens serão concluídos para teste e faça com que eles se comprometam com um tempo para fazer o teste / aprovação da conclusão.

Sei que criar esse tipo de documentação não é por que você se tornou um programador, mas você pode arriscar jogar essas listas fora ou continuar jogando seu código suado.

Retrocesso. Os responsáveis ​​precisam ver quanto esses pedidos estão custando.

As alterações de requisitos nem sempre são ruins. O importante é lembrar o seu cliente. Provavelmente, seu chefe é seu cliente neste caso. Você precisa notificar seu chefe de que essas mudanças constantes nos requisitos estão limitando sua capacidade de produzir o produto que é mais útil para ele. É perfeitamente possível que os negócios se beneficiem de você reagindo constantemente às mudanças. Nesse caso, esse é o modelo de negócios deles e você não está fazendo nada de errado, embora eu recomendo correr pelas montanhas nesse caso!

As pessoas frustradas com as mudanças nos requisitos são frequentemente valorizadas pela forma como gerenciam cada mudança. Essa métrica de "número de alterações suficientemente manipuladas" é provavelmente a fonte do seu verdadeiro problema. Considere discutir melhores métricas com seu chefe. Quando estou enfrentando requisitos que mudam constantemente, eu me esforço para escrever um conteúdo que me permita me adaptar às exigências que mudam constantemente. Em vez de executar uma simulação e analisar os dados todos os dias, escreverei ferramentas que tornam o processo de execução da simulação e da análise dos dados mais baratos e colho as recompensas ao longo do tempo. Se isso ainda é muito louco, posso até escrever uma ferramenta para escrever ferramentas!

Seu processo pode se beneficiar de alguns princípios ágeis, como iterações bloqueadas. Acho que uma semana é razoável com mudanças tão rápidas que você está descrevendo. 2 semanas podem funcionar melhor eventualmente.

Depois que requisitos importantes forem identificados, peça à pessoa que está na Project Ownerfunção que assine e prenda-o por um período de uma semana enquanto você os constrói. Aloque trabalho suficiente para si mesmo, onde você estará ocupado e deixe que os poderes saibam sua alocação. ou seja, se por semana você pode produzir um trabalho de 16 pontos e você tem 16 pontos de trabalho, então você é totalmente utilizado nessa semana. (O conceito de pontos vem do fluxo de trabalho ágil)

Se ocorrerem mudanças no meio da semana, pronuncie estas palavras mágicas:

Eu posso fazer [esse novo recurso], [essa nova alteração], [etc], mas o que você não quer que seja feito ?

Ou seja, você é um recurso limitado, só pode levar tanto trabalho. Se um novo item de trabalho chegar, você poderá ser o recurso limitado que você é e atribuir pontos ao novo item e soltar / alterar outros itens no lugar dessa nova alteração de entrada. Priorize novamente sua lista de iterações junto com o proprietário do projeto e você deverá lidar melhor com as mudanças.

Se os requisitos mudarem com mais frequência do que isso, talvez seja necessário negociar mais estabilidade em seu ambiente.

A frase "Alteração de requisitos" às vezes é abusada pelas pessoas de TI. O que você está descrevendo é de fato alteração de requisitos, mas isso pode ocorrer devido a um ou mais dos seguintes itens (não sei o suficiente sobre o seu caso, portanto, o seguinte pode ou não se aplicar):

1. A ambição da gerência de fazer o usuário final feliz o mais rápido possível e mostrar rápido progresso.

2. Falta de análise detalhada. Lembre-se de que os analistas precisam fazer perguntas sobre por que não apenas o que. Os analistas precisam "pensar" com o usuário final sobre uma "solução", não apenas para receber pedidos.

3. Falta de um processo formal para verificação e confirmação de requisitos, seguido de aprovação.

4. Solicitando que a pessoa incorreta desempenhe uma ou mais funções para as quais não é necessariamente treinada, como analista de negócios ou analista de sistemas.

5. Prototipagem limitada.

6. A suposição / medo de que isso deva ser feito rapidamente e, se não é de sua responsabilidade, é a TI.

A menos que se lide com todos os itens acima corretamente, o relacionamento entre a TI e o negócio / usuário final será estressante. Observe que isso não implica que o ponto acima seja conclusivo. Existem outros fatores que levam a situações estressantes semelhantes à sua, mas acho que essa lista deve ajudá-lo.

Eu acho que você deve abordar isso de algumas direções:

1. Faça com que todos os interessados ​​(incluindo toda a equipe de desenvolvimento) se encontrem (offline / online) com o consultor de negócios e tentem entender o domínio, a visão e, em seguida, debater juntos os requisitos.

2. Formalize os requisitos / histórias de usuários, classificando cada um deles:
   a. Prioridade (urgência / importância)
   b. Maturidade (quão bem definido é - compreendido e acordado pela maioria das partes interessadas *)
   c. Complexidade (estimativa aproximada)
   
   Ao escolher em quais requisitos / histórico do usuário trabalhar a seguir, leve em consideração os três fatores. Se o requisito tiver baixa maturidade, inclua uma missão de pesquisa à sua frente, na qual você contate todos os interessados, investigue o raciocínio por trás do requisito e defina-o melhor (escreva casos de uso e / ou crie estruturas metálicas e apresente-os) antes de agir sobre isso.

3. Tente pensar alguns passos à frente ao projetar antes de cada implementação - projete uma arquitetura flexível que tenha espaço para acomodar mudanças.

4. Tente adaptar um processo de desenvolvimento ágil, por exemplo, SCRUM ou Kanban - isso fornecerá um kit de ferramentas para o desenvolvimento de um produto com requisitos variáveis.

Você também deve solicitar aos moderadores que movam esta pergunta para PM.stackexchange.com (sinalizando-a), pois, mesmo que essa pergunta se encaixe aqui, ela se encaixaria melhor lá.

(*) Stakeholders para acordo: negócios, marketing, gerenciamento de projetos, desenvolvimento e controle de qualidade.