Como você gerenciar clientes com relação aos requisitos de mudança? [fechadas]

Question

href="http://steve-yegge.blogspot.com/2008/08/business-requirements-are-bullshit.html" rel="nofollow noreferrer"> Steve Yegge, não obstante, a maioria dos desenvolvedores são confrontados com exigências que foram recolhidos a partir de clientes não-técnicos. Às vezes, há gerentes de projetos que lidam com os clientes e traduzir as suas necessidades, outras vezes não. Em qualquer caso, o fato de que os requisitos vai mudar é uma inevitabilidade.

A maioria do que consititues "boa prática de programação" tem a ver com sistemas em desenvolvimento que são adaptáveis ?? para que eles possam suportar requisitos mudando. Princípios como YAGNI, seco, baixo acoplamento, etc. contribuem para isso. O desenvolvimento iterativo processos como Agile também tentam abordar a preocupação de tentar acertar um alvo em movimento, e, claro, ter um sistema em teste torna infinitamente mais viável para fazer alterações.

No entanto, parece que para muitos de nós mudanças de requisitos pode não só prejudicar a qualidade do nosso software, mas também pode drenar a nossa motivação e nos fazem querer facada alguém.

Esta questão é sobre como gerenciar o cliente para torná-lo possível para que eles mudem suas necessidades da maneira que eles precisam, enquanto desencoraja mudanças arbitrárias ou frívolas. Como você faz isso?

• Você tem gerentes de projeto para isolar os devs do cliente?
• Você tem um processo formal de gerenciamento de mudança? gerentes de mudança?
• Como é que é difícil para o cliente para obter uma mudança quando eles realmente precisam dele?
• Por outro lado, como é que é fácil para um cliente para obter uma mudança quando é "frívola"?
• Como muitos detalhes que você dar ao cliente ao explicar o custo de uma mudança?
• Como rapidamente você é capaz de dar ao cliente esta informação depois de receber um pedido de mudança?
• Que fatores podem torpedear o processo (por exemplo PM é quem não pode dizer não para o cliente? )
• O que funciona para você?

Answer 1

Se você estiver olhando para o mundo ideal onde o cliente nunca muda sua mente ou você recebe a especificação ideal - você está no negócio errado . Dito isto, o mecanismo mais eficaz que eu encontrei para gerenciar as expectativas do cliente e solicitações de mudança é instituir um sistema preciso de medição.

Isto é como eu executar o meu time:

1) Começamos com histórias de usuários. O cliente está envolvido em escrevê-las e as estimativas da equipe de desenvolvimento quanto tempo cada história de usuário levará de forma relativa.

2) Com experiência anterior eu tomo essas estimativas relativos (pontos da história) e criar uma agenda intensa para quando principais marcos do projeto estará completo.

3) Dentro destes marcos corremos iterações de 2 semanas. O cliente está envolvido na definição dos critérios de aprovação e se ou não a história tenha sido aprovado. Um simples queimar gráfico mostra ao cliente o quão perto estamos de cumprir a meta de lançamento.

4) Muitas vezes o tempo durante as sessões de aprovação do cliente irá solicitar uma alteração porque o recurso não saiu como ele esperava que (apesar de ele encontrou seus critérios de aprovação originais). Neste momento você gerar uma nova história com uma nova estimativa. Você também pode ajustar as datas marcantes de forma adequada. Isso, então, coloca a bola de volta para a quadra de clientes:

• Muitas vezes eles percebem a sua solicitação de mudança não vale a pena (eles teriam que obter a aprovação do seu chefe) e nós vamos matar o novo recurso
• Às vezes é importante, então vamos adiar a data de vencimento para obter o recurso no
• E, finalmente, há sempre a opção de matar outra característica não tão importante, que terá uma quantidade equivalente de tempo.

A chave não é para fugir de solicitações de mudança, mas para estabelecer que cada solicitação de mudança tem consequências sobre o produto. Não há tal coisa como um almoço grátis.

Answer 2

Eu trabalho como desenvolvedor indpenedent e assim o contato com os clientes diretamente. É normal que a maioria das vezes eles não têm idéia do que eles realmente querem. Então, vamos começar devagar e eu dar-lhes protótipo cedo para brincar e, em seguida, as alterações serão gradativamente feita. Se eu pensar que os clientes quer mudança "frívola", então eu dizer-lhe que esta mudança não funciona ou não é necessário. Se for 5 min de trabalho, então eu poderia até mesmo fazê-lo de qualquer maneira.

Ela ajuda a adicionar mais tarde, para o contrato alguma cláusula de manutenção para conseguir dinheiro para essas pequenas mudanças que virão mais tarde. Para mudanças maiores que você acabou de cobrar por hora.

Answer 3

Gerenciando o cliente é difícil, e é algo que muito facilmente pode dar errado.

Eu acho que o mais cedo possível você precisa ganhar a confiança do cliente. Para mim, eu acho que você pode fazer isso:

• Peça ao cliente para nomear um gerente de produto -. Que é suficiente clara pensamento para comunicar os requisitos que ele / ela quer, e olhar para construir uma forte relação de trabalho com ele / ela
• realmente tentar entender o seu negócio -. Você não precisa ser um especialista de domínio, mas você precisa saber onde o cliente está vindo
• Faça perguntas pertinentes sobre o que eles querem - não assuma que eles pedem (no início) é o que eles realmente querem
.
• Na primeira boas-vindas a todas as alterações . Este não é o cliente ser chato e inconstante, como uma oportunidade para entender melhor o que o cliente realmente quer. Se Isto custa-lhe tempo / dinheiro, então você pode precisar de aceitá-lo como um líder de perda .
• Entregar um protótipo , e incorporar o máximo de feedback dos clientes quanto possível.
• Dê ao cliente um produto kick ass .

Depois de ter feito isso, e as relações de confiança do cliente, então você vai estar em uma posição para começar a bater de volta mudanças irracionais, ou pedir pagamentos extra / tempo para as coisas que foram anteriormente considerados fora do escopo.

É claro, você não será capaz de construir este tipo de relacionamento com cada cliente, alguns são idiotas (neste caso, veja se você pode ter um gerente de produto diferente nomeado), mas você deve sempre fazer o máximo que você pode construir uma relação de trabalho.

Answer 4

Você não pode esperar que os clientes sabem o que querem no início, para que você deve ser adaptável. Mas também é preciso parar a mudança para mudanças bem.

Esta é para os clientes ‘internos’.

Eu descobri que a negociação com o cliente é uma forma eficaz de ir. Eles podem ter o que têm eles querem se esperar por ele, ou se sacrificar algum outro (ainda a ser implementado) apresenta. Esta obriga-os a pensar sobre o valor da mudança que eles estão pedindo em relação ao sistema como um todo.

Às vezes, isso funciona bem e um bom compromisso é alcançado. Outras vezes o cliente joga seus brinquedos para fora do carrinho e vai por mais alto que eles têm para fazer o recurso implementado e qualidade é reduzida.

Se o cliente está pagando, é um jogo diferente. Eles precisam estar cientes de que os custos de mudança, e que o custo aumenta à medida que o produto se aproxima da conclusão. Isso significa que você tem que fazer um monte de até análise de frente sobre o que você vai entregar e certifique-se a especificação é acordado. Então você pode medir o que mudou. Isto pode não ser a solução mais eficaz para ambas as partes, mas ele faz manter as coisas cortada e seca. Assim, eles não estão insatisfeitos e você não acabar fazendo cargas de trabalho de graça.

Answer 5

Em engenharia de software, a mudança é apenas um fato. Isso vai acontecer. Para nós, tudo tem um preço. Vamos fazer apenas sobre qualquer alteração dos clientes quer, mas há sempre uma estimativa de tempo e um custo associado a ele. Será que alguma vez dizer ao cliente não - não normalmente, mas às vezes o pedido de mudanças vem em um custo muito elevado. Fazemos chamar a linha de potenciais ameaças à segurança etc. caso em que calmamente explicar-lhes que não podemos acomodar o pedido.

Quanto é que vamos explicar para o cliente, vamos explicar onde o dinheiro está indo a ser alocado, tanto para o desenvolvimento, tanto para análise etc. Nós não lhes diga explicitamente porque algo custa da maneira que faz. Agora vou admitir, isso faz variar um pouco com alguns de nossos clientes. Alguns deles ficam muito detalhado faturamento como a exatamente quantas horas são gastas onde. Para obter o contrato que tinha que concordar com ele, embora isso seja muito raro para nós.

Temos pessoas de vendas que não pode dizer não às vezes, e que pode causar problemas. Nós passamos muito tempo trabalhando nisso, mas, infelizmente, ainda surge. Nós combatê-lo, explicando quanto dinheiro eles nos custam citando algo sem pesquisar o que vai demorar. A transparência é fundamental em todos os níveis. Todo mundo tem que saber como suas decisões afetam a linha de fundo.

Não fazemos mudanças frívolas? Sim. O que você tem que lembrar é que quando você cobrar por hora na maioria das vezes uma mudança de 5 minutos é cobrado a uma hora, de modo que é bastante lucrativa. Nós explicamos tudo isso antes, como fazemos com qualquer solicitação de mudança que eles estão conscientes disso, mas ele tende a ajudar a desencorajar tal comportamento a menos que seja realmente importante. O fato é que nós tratamos todas as alterações ao mesmo. Nós não assumir que sabemos o que é considerado frívolo para eles não importa o quão absurdo que nós pensamos que poderia ser. Temos um processo de mudança formal, onde o cliente pede algo que anotá-la e levá-los a assinar que é o que nós avaliá-la e apresentar um custo de Trabalho Estimativa. Ou eles concordam caso em que formalmente assinar um documento deixando-nos saber que é ok para começar, ou rescindir o pedido. Tentamos ser diligente, mas nós deixá-los saber que vai demorar alguns dias para nós para obter uma resposta ao seu pedido.

Um colega meu me deu o melhor conselho que já ouvi sobre o gerenciamento de navios relações com os clientes. É um dar e receber. Para fazer o cliente feliz, você tem que estar disposto a ajudá-los quando eles precisam de algo, mas, ao mesmo tempo, você tem que ser capaz de dizer não. Ao lidar com pessoas que eles querem que você para ajudá-los, mas eles também querem que você tem uma espinha e levantar-se para si mesmo. Torna-se uma situação ganha-ganha dessa forma.

Answer 6

Eu prefiro um termo de requisitos evoluindo para “novas exigências”. Professor MMLehman ( http://www.doc.ic.ac.uk/~mml / e http://en.wikipedia.org/wiki/Meir_Manny_Lehman ) tem feito uma contribuição considerável para a pesquisa sobre a evolução software; Seus trabalhos também sugerem que nem todos os tipos de requisitos evoluir. Pode-se considerar-se com sorte, se acontecer de trabalho em um desses sistemas, onde os requisitos permanecem as mesmas (ou seja, matemática bibliotecas etc).

Para o resto de nós a experiência sugere que os desenvolvedores preferem o máximo de informações sobre os requisitos na frente quanto possível, enquanto os clientes ou usuários finais valorizam a capacidade de especificar ou ajustar exigências o mais tarde possível no processo de desenvolvimento. O ex necessidade a informação detalhada para o planejamento ajuda e projetar a solução, o último pode ganhar uma vantagem estratégica através da mudança de uma exigência tarde, porque dá ao cliente alguma margem de manobra para responder ao meio ambiente ou informações mudando ganhou como um resultado da anteriores estágios / iterações do projeto. Um trade-off entre a capacidade de ter um plano detalhado e mudar as coisas determina em grande parte o próprio processo de desenvolvimento (cachoeira, ágil, espiral etc).

Alguns conselhos práticos gestão da evolução dos requisitos:

• construir em algum quarto para o plano inicial para a conta para os requisitos, múltiplos pontos de verificação ou iterações evolução.

• De qualquer colocar requisitos voláteis no início do projeto para que algum tipo de prototipagem ou estudo de viabilidade é provável que esclarecê-los ou plano para a mudança tardia para o projeto.

• Monitor de que as exigências são ainda relevantes.

• Você possui uma até à data, lista priorizada de requisitos atuais acessíveis. Nada mais ajuda a manter a evolução em controle como uma boa visibilidade a todos os interessados ??das actuais “must haves”, incluindo sua prioridade relativa e custo.

• Mantenha gerir as expectativas dos clientes em quanto tempo as coisas vão tomar; Isso também ajuda a manter o foco.

• Apresente um processo formal de alteração ou adição de requisitos, se você precisa. A descrição do processo necessidades para especificar papéis desses envolvidos, a frequência de comentários etc. Poderia servir como uma boa proteção contra alguns requisitos essenciais políticos e mais oportunistas, mas não.

• construir em algum tempo para refatorar mesmo para a primeira versão. Você é muito provável que jogue toda ou parte da solução, como resultado de ganho de conhecimento adicional durante o desenvolvimento.

Answer 7

O cliente vem até você fazer alguma coisa, porque eles não quer ter o tempo para fazê-lo ou eles não sabem o que fazer (e quer pagar-lhe para fazer isso por eles) . Se você tiver requisitos mudar, é porque deste último. Em outras palavras, eles estão pagando para descobrir os detalhes! E eles sabem que eles gostam e não gostam, mas eles não sabem como funciona.

Reconhecer isso e sejam quais forem as necessidades solução a quedas no lugar.