AgileFAQ #2: E o cliente?

Seguindo essa ótima idéia do Agile FAQ, acho que essa é realmente a segunda pergunta que mais recebemos em apresentações. Na verdade ela aparece em diversos formatos:

  • E se meu cliente não for técnico?
  • E se meu cliente não quiser participar da equipe?
  • E se meu cliente estiver longe?
  • E por aí vai…

Quando ouço essas perguntas, me dá a maior vontade de fazer outra pergunta na hora: então como é que vocês fazem??? É sério! Porque sem alguém que entenda do negócio, como é que vocês sabem o que fazer? Bola de cristal? Tentativa e erro? Como essa galera faz?

Na verdade, muitas vezes alguns analistas heróis tentam cumprir esse papel de adivinhos, com a pouca informação que extraem rodando a empresa ou de sua documentação (legislação, estatuto, processo, enfim…). Muitas vezes isso vira outra documentação extensa, e aí, menos gente ainda passa a dar bola pra ela.

Ou cliente não lê, ou lê sem entender, ou lê, entende mas não consegue abstrair toda complexidade, a galera desenvolve baseado nos protótipos de tela ou nos modelos de dados e assim segue. Altos investimentos são feitos para que ao final, quando forem apresentar (se é que há algo pra apresentar) o produto (ou parte) “pronto”, o que se ouve é a famosa frase: “não era nada disso que eu queria”.
Preciso mencionar quem diz isso?

É claro que eu pintei um quadro bem feio. Nem todo cliente é assim, nem todo projeto dá nisso. Mas não está muito diferente da realidade de muita gente por aí (da minha inclusive, há poucos anos atrás). Mas fica bem claro que não estamos lidando com um problema de uma metodologia X ou Y, mas de um problema cultural (e gravíssimo para projetos, diga-se de passagem). Como poderia dar certo desse jeito? Na verdade, está apenas se postergando o inevitável.

O problema é que muitos clientes ainda pensam que desenvolvimento de software é como compra de geladeira. Você encomenda uma, escolhe a cor, espera uma semana e ela chega do jeito que você queria. Onde passamos, isso ocorre principalmente quando os clientes são: autoridades, executivos sem tempo, pessoas sem experiência em desenvolvimento ou não-técnicos em geral.
Mas, como lidamos com isso?

Não conheço um argumento certeiro contra esse problema, que funcione pra qualquer um. Fala-se muito em educar o cliente (ou Product Owner). Isso pode ser feito explicando-se a natureza da atividade, apresentando livros para ele ler, fazendo apresentações na empresa, mostrando a realidade de um projeto, chamando o cliente pra participar de um bom projeto de perto, convidando alguém que ele ouça e respeite (que tenha autoridade no assunto) pra falar com ele sobre isso, enfim, diversas maneiras. Na verdade, existem diversos estudos de padrões para introduzir novas idéias. Vocês podem estudar alguns no Blog do Daniel Cukier, que fez um mestrado sobre isso.

O pior é o seguinte: mesmo assim, todas as suas tentativas podem dar errado. Mas não se frustre por isso. É que entender isso depende um bocado do seu cliente. É um processo interno de aprendizagem. Muitas vezes, serão necessários alguns fracassos para que ele SE CONVENÇA de que algo precisa ser feito de outra forma. O que também pode não ocorrer, dependendo do “grau de rigidez da cabeça” dele.

Nada animador esse post, não? Ainda piora um pouquinho antes de acabar. Isso porque não basta o cliente participar pra você ter um software de sucesso. Essa é só uma parte do caminho. O software pode ser tudo que ele queria, mas mesmo assim não ter nada a ver com o que os demais usuários realmente precisavam. Por isso, façam releases curtas e liberem em produção o sistema o quanto antes para seus verdadeiros usuários. (Com qualidade!) Obtenha feedback real de quem vai usá-lo. Os usuários também são clientes, e esse feedback é precioso!

Por melhor e mais empenhado que seja seu cliente, ele dificilmente vai conseguir absorver e processar os entendimentos e necessidades de toda população de usuários do seu sistema. Seria outro nível de uso da bola de cristal. Salvo se forem muito poucos. Inclusive, esse tipo de atitude pode mudar totalmente o caminho previsto para o software, como já vi inúmeras vezes, ou até mesmo livrá-los de investir ainda mais numa furada. Pensem nisso.

Enfim, este é um problemão de que não dá pra fugir. Lidar com gente é complicado mesmo. Como diria um amigo: “é que nem mulher bonita! Se fosse fácil, cada um tinha uma!”


Normalmente essa é a parte mais frágil. Não a tecnologia ou a metodologia. Se fosse fácil, seu trabalho como Líder/Coach/Scrum Master/X não teria todo valor que tem. Por isso repito: não desanime. Vá avançando em outras práticas, outros aspectos da equipe e do código que esse desafio inevitavelmente vai surgir e você estará cada vez mais preparado para superá-lo. Isso se ele não se resolver sozinho, o que também é possível.

Abraços,

 

Trabalha como gerente dos projetos de desenvolvimento de software da SEA Tecnologia utilizando metodologias ágeis.
Formado em Computação na UnB, Pós-Graduado em Software Livre pela UNISUL e cursando MBA em Projetos pela FGV. Certificado como PMP, ITIL, SCJP, IBM RMUC e IBM RUP Specialist.

About these ads

11 thoughts on “AgileFAQ #2: E o cliente?

  1. Cara, sintetizou boa parte do que venho dizendo aqui na empresa. Sem cliente não dá, mas se não temos um, vamos ter que achar um jeito de preencher esse papel!

  2. Excelente Post! Alguns clientes esperam apenas a entrega da geladeira. Como se o projeto fosse totalmente da TI. O uso de releases curtas ajuda muito nestes casos em conjunto com outras medidas. Principalmente, a mudança de cultura.

    “É sério! Porque sem alguém que entenda do negócio, como é que vocês sabem o que fazer? Bola de cristal? Tentativa e erro? Como essa galera faz?”

    com certeza, bola de cristal….hehehe

  3. Olá Renato,

    como vc descreveu costumo tb apontar um paper ou estudo (seguindo a negociação por princípios) que sirva como critério justo para a “negociação”. No mês passado saiu um artigo na harvard business review BR chamado “Quando um processo deve ser arte e não ciência?”. O peso da HBR tá fazendo diferença nesse trabalho de convencimento.

    sds

  4. Willi, comecei a rir quando li as perguntas que o pessoal faz porque me fez lembrar uma situação que eu vivi: eu já tive que começar a desenvolver um sistema que não tinha usuário!

    Outro dia eu conversava sobre isso com o Edu e com o Ema.
    kkkkkkkkkkkk

    Sabe qual foi minha solução para o problema? Não desenvolvi o sistema.

    Em outras palavras: não há necessidade de solução quando não há quem te diga qual é o problema! rsrsrs


    [ ]
    Vinicius Assef

  5. Olá Willi,

    Acho que a idéia é essa mesma: se o cliente não é acessível, temos que encontrar caminhos. Afinal, encontramos caminhos ou mudamos de profissão. :)

  6. Acho que também é péssimo quando o cliente simplesmente não quer acompanhar as entregas no final das iterações, ou apenas quer ver o sistema depois de algumas iterações ou no fechamento de realeases, ou, no pior caso, ao término do projeto. Como ter o feedback para se nortear adequadamente nesse cenário? Não dá, né? Fatalmente haverá retrabalho, stresses e etc.

    Como vc disse, sem o cliente não rola…

    Ótimo post!

    PS: Linkei seu post, ok?

  7. [..] O cliente é contra vc. Ele não acredita, que vc vai entregar tudo o que ele acha que precisa nesse modelo. Ou ele simplesmente não acredita em agilidade, entregas pequenas e etc. Recebe o resultado do seu sprint, mas nem olha nada pois “vai olhar quando tiver tudo pronto”. Normalmente são traumatizados por experiências ruins de fracassos anteriores. [..]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s