Lidando com a incompatibilidade da cultura cliente / desenvolvedor em um projeto ágil

Um dos princípios do ágil é ...

Colaboração do cliente sobre negociação de contrato

... outro é ...

Indivíduos e interações sobre processos e ferramentas

Mas do jeito que eu vejo, pelo menos no que diz respeito à interação com o cliente, há um problema fundamental:

Como o cliente pensa é diferente de como um engenheiro de software pensa

Isso pode ser um pouco generalizado, sim. Pode-se argumentar que existem domínios de negócios nos quais isso não é necessariamente verdade - embora sejam poucos e distantes entre si. Em muitos domínios, porém, o cliente típico é:

1. Interessado em preocupações operacionais diárias - táticas de curto alcance ... não necessariamente estratégia;
2. Compreensivelmente, apenas preocupado com a solução imediata;
3. Pensadores práticos, não pensadores abstratos;
4. Muito mais interessado em "fazer o trabalho" do que considerar como a solução suportará preocupações futuras.

Por outro lado, no ideal , os engenheiros de software que praticam agilidade são:

1. Pessoas que pensam muito em qualidade;
2. Indivíduos que apreciam como um pouco de trabalho inicial podem economizar muito esforço;
3. Pensadores analíticos experientes.

Portanto, parece haver uma discrepância cultural que tende a inibir a "colaboração do cliente".

Qual é a melhor maneira de resolver isso?

Em muitos domínios, porém, o cliente típico é:

• Interessado em preocupações operacionais diárias - táticas de curto alcance ... não estratégia;
• Preocupado apenas com a solução imediata;
• Pensadores geralmente unidimensionais e não abstratos;
• Principalmente interessado em "fazer o trabalho", em vez de encontrar uma solução duradoura e de qualidade.

E para ser franco, eles geralmente têm boas razões para pensar assim. Antes de tudo, eles estão administrando um negócio, que deve gerar receita hoje e amanhã, não em um futuro distante. Em segundo lugar, eles não são especialistas técnicos - eles não sabem o que é possível e o que não é e quais são as consequências de escolhas específicas de arquitetura / design / implementação. Isto é o que sabemos.

Portanto, a resposta é - não surpreende - a comunicação .

Você precisa se comunicar muito, educar-se, fazer-se entender o ponto de vista da outra parte, pelo menos até um nível básico. Você precisa explicar a eles as conseqüências de curto e longo prazo de possíveis alternativas. E você precisa usar a linguagem que eles entendem .

• Se você disser "isso seria um hack, o que torna o código menos legível e extensível" , eles dizem "sim, tanto faz" .
• Se você disser "isso seria uma correção de curto prazo, o que tornaria o desenvolvimento e a manutenção de longo prazo mais dispendiosos e aumentaria o risco de introdução de bugs" , eles dizem "a ha, vamos considerar" .
• E se você disser "essa solução custaria US $ 100 agora, mas introduz US $ 500 em dívidas técnicas que você deverá pagar com juros mais cedo ou mais tarde; a OTOH esta outra solução custa US $ 400 agora e não deixa nenhuma dívida técnica; escolha a que você querem " , eles dizem " agora estamos conversando! " .

OTOH eles podem nos ensinar uma coisa ou duas sobre a perspectiva do negócio. As empresas querem soluções utilizáveis e boas o suficiente - dificilmente perfeitas -. E eles sabem provavelmente melhor do que ninguém que "perfeito é o inimigo do bem". Portanto, você deve ter em mente que nosso trabalho é fornecer soluções para os problemas de nossos clientes, em vez de produzir software tecnicamente perfeito. Às vezes, esses dois convergem para o mesmo, mas mais frequentemente não. Isso pode ser visto como triste por muitos, mas é a realidade dos negócios. Para mim, se eu consegui resolver o problema do meu cliente e vejo que isso tornou a vida deles visivelmente mais fácil, fico tão feliz quanto ele. OTOH, se eu conseguisse implementar o design perfeito que eu tinha em mente, mas a empresa faliu na semana seguinte, dificilmente será uma vitória para alguém, é?

Um proprietário sensato da empresa entenderá - se você os explicar usando seu próprio idioma - por que é importante manter o software limpo, escrever testes de unidade, refatorar etc. Mesmo que eles pareçam não contribuir diretamente com nada no curto prazo, eles são essenciais para manutenção a longo prazo. E os clientes sensatos se preocupam com a manutenção de longo prazo de seus negócios, de modo que certamente estão dispostos a investir nele quando virem o valor que seu investimento gera. No entanto, tanto os recursos quanto o tempo são limitados, você precisa priorizar e se concentrar nas coisas mais importantes. Mas é importante apenas se for importante para vocês dois .

Você pode refatorar o módulo A porque o código é horrível e você tem uma idéia estupenda de como refatorar o código para ser conciso, elegante e limpo, usando um padrão de design que você acabou de ler. No entanto, se esse módulo não for tocado há anos e funcionar de maneira confiável, é mais provável que você se concentre mais no módulo B, que será estendido na próxima semana com um novo recurso muito importante e contém muitos erros já.

Como seu cliente se vê:

• Tenho um projeto que preciso concluir o mais rápido possível
• Eu sei que minhas necessidades de negócios
• Preciso resolver o problema de uma maneira que não seja prejudicial às práticas comerciais atuais
• Eu tenho um orçamento limitado para fazer isso.

Por outro lado, eles veem seu grupo como:

• Caras que não entendem que estão sugando dinheiro do meu orçamento.
• Não entendemos as necessidades de nossos negócios
• Deseja reprojetar tudo, mesmo que isso dificulte a implementação nos negócios.
• Deseja ter uma solução inteligente e inteligente quando tudo o que tenho para o orçamento é funcional e eficaz.

Seu principal problema parece não estar entendendo o que eles precisam da outra parte.

Bem, acima de tudo, o Agile não é a solução para todos os problemas que você tem no seu projeto.

Como o cliente pensa é fundamentalmente diferente de como um engenheiro de software pensa

Sim. Às vezes é verdade. Há até casos em que os clientes não sabem o que e como querem (ou seja, os requisitos não são claros). Seja como for , se você é ágil, obtém o resultado após cada corrida (digamos, 2 semanas) e tem a oportunidade de receber feedback dos clientes e garantir que todos estejam na mesma página. Isso ajuda a identificar e corrigir os problemas mais cedo, o que internamente ajudará a criar confiança.

Também existe um ditado: os usuários são como crianças loucas; portanto, quando pedem uma arma e você sabe que ela não é segura, considere dar uma arma de brinquedo para acalmá-las .

Qual é a melhor maneira de resolver isso?

Como já disse, não há um bastão mágico que possa resolver todos os problemas dessas teses . Você precisa se envolver mais com seus clientes para que haja um bom entendimento sobre o que os outros fazem. Promova a visita ao site, abra comentários etc.

Certifique-se de que o proprietário do produto e as partes interessadas participem das demos do sprint e dê sugestões valiosas para melhorar o produto .

Se você não tem o buy-in do cliente, o Agile pode ser quase impossível.

Com a compra, quero dizer obter uma porcentagem garantida de um representante do cliente, por semana ou mês. Essa porcentagem varia de acordo com o projeto.

Obviamente, eles têm o trabalho do dia-a-dia; portanto, não cabe apenas ao representante do cliente, cabe à gerência deles reservar um tempo para eles.

Portanto, obter o acordo da gerência do lado do cliente é a chave para esse problema

Lembre-se de que o ágil não significa que o cliente esteja envolvido em standups diários ou em alguns dos outros aspectos do dia a dia do ágil. Ágil, da perspectiva do cliente, é sobre comunicação. Isso não significa que eles estejam se comunicando com os engenheiros sobre os detalhes da implementação.

Os clientes colaboram com o proprietário do produto para obter e fornecer feedback constante. O tópico são recursos, mas não como eles são implementados. Você está entregando os recursos adequados? Você está dentro do cronograma? Eles têm requisitos de mudança aos quais você precisa se adaptar?

O Agile ajuda você e seu cliente a responder a essas perguntas.