A relação com o usuário demanda cuidados. Qual Analista de Sistemas que nunca teve problemas com seus Usuários? E qual Usuário que nunca teve problemas com seus Analistas?
Essa relação é, culturalmente, carregada de pré-conceitos estabelecidos desde que se começou a desenvolvedor software neste mundo.
No fim, sempre o projeto paga a conta. Mas precisa ser assim?
A “culpa” é sempre do Usuário (conforme o ponto de vista do Analista), ou a “culpa” é sempre do Analista (conforme o ponto de vista do Usuário)?
8 Dicas para melhorar a relação com o Usuário
Vamos ver algumas dicas para mudar essa realidade, que podem fazer toda a diferença no dia a dia dos projetos de software. A relação com o Usuário, se positiva, pode fazer “mágica” no desempenho do Analista.
Dica 1 – Usuários não sabem o que querem
Usuários geralmente sabem o que querem, mas não pensam de maneira sistêmica e lógica como um Analista.
Se uma pessoa solicitar a um Engenheiro que construa uma casa para ela, essa pessoa talvez veja na casa alguns aspectos, como: conforto, funcionalidade, estética, segurança.
O Engenheiro precisa captar este desejo do seu cliente e transformar isso num projeto arquitetural/estrutural, em planta baixa, croquis etc.
O Usuário quer solução para o seu negócio, não um software. Mas a forma de viabilizar sua solução é através de um software. E entender o processo de forma sistêmica, de forma lógica, é função do Analista, que é o especialista em software, e não do Usuário, que é especialista no negócio.
Portanto, não quer dizer que os usuários não sabem o que querem. Isso até acontece, mas em muitos casos, sabem sim, mas do jeito deles.
Dica 2 – Usuários não sabem explicar direito o que querem
Salvo se o Usuário for um cientista, profissional técnico de exatas, ou algo semelhante, ele realmente não compreenderá o nível de detalhe que precisa descer quando estiver explicando uma necessidade sua para o Analista.
O Usuário pensa mais no “o que” do que no “como”.
Ele tem um problema e quer uma solução, mas sobre “como” a solução será implementada, muitos Usuários não querem saber, acham que isso deve ser responsabilidade do Analista.
Eu mesmo já trabalhei em projeto onde o Usuário dizia assim: “eu quero que o sistema faça isso, mas como o sistema vai fazer, aí é com vocês”.
/* Só para constar, não foi um projeto legal, o ciclo de validação foi quase eterno, e o nível de retrabalho foi altíssimo. */
Pensar o “como” a solução será implementada, do ponto de vista conceitual e funcional pode até ser feito pelo Analista, mas a responsabilidade por isso é do Usuário, e ele tem que saber disso.
Alguns Usuários até explicam em um nível mais detalhado o “como”, mas nunca é no nível de detalhamento que o Analista precisa para especificar o software.
Mas, o Usuário tem que saber explicar tudo isso no menor nível de detalhe?
O ideal é que tivesse, mas não tem. Isso é papel do Analista. O Analista tem que fazer análise, não apenas escutar, escrever, e executar o que é dito pelo Usuário.
Na análise tem que aplicar senso crítico, criticar o que Usuário solicitou, pensar de forma macro e micro todos os aspectos conceituais e funcionais da solução etc.
Analista faz análise! É como um médico no seu consultório: o paciente está com uma dor, mas detalhes dessa dor, e como resolvê-la, é com o médico, não com o paciente.
Dica 3 – Analista pensa em “modo cartesiano”
Se colocarmos um poeta conversando com um físico, sobre uma tarefa que eles têm em comum, qual a probabilidade deles se entenderem bem? Será que um entenderá perfeitamente o que o outro quer dizer?
O Analista, pela repetição do dia a dia e pela natureza de sua atividade, pensa de maneira “cartesiana”
/* Lembrando René Descartes, o maravilhoso Filosofo que nos trouxe contribuições espetaculares no campo da lógica e da matemática. */
O Analista deve pensar assim mesmo, é necessário para realizar suas atividades. Mas não é necessário pensar somente desta forma.
É difícil uma comunicação perfeita entre Usuário e Analista, mas tem que ser uma comunicação viável.
E para isso, o Analista tem que aprender a pensar, nos momentos de relacionamento com o Usuário, de maneira menos técnica, mais orientada ao negócio, se colocando sempre no lugar do Usuário.
Trabalhar a empatia neste contexto é fundamental.
Dica 4 – Analista sempre acha que “já entendeu”
Se você é Analista de sistemas, eu lhe pergunto: “você se acha um profissional excelente? Se acha um cara foda?”. Se no seu íntimo você disse sim, então faz parte do grupo predominante.
Eu sou um Analista de Sistemas. E me considero um bom Analista. Mas antes eu me considerava ótimo em tudo que eu fazia no meu dia a dia.
E demorou um pouco para eu entender que eu não era tão foda como eu pensava que era.
Quando alguém explica alguma coisa para um Analista de Sistemas é comum ele falar: “ok, ok, pode deixar que já entendi.”.
Após isso, o Analista especifica ou implementa a solução. Volta para validar e algo não saiu como esperado. O fato é: ele não entendeu direito o que era para fazer.
E quando o assunto é escopo conceitual e funcional, coisas mais voltadas para a solução do que para o software, este não é “não mesmo”. Não entendeu!
O Analista tem que trabalhar a paciência e os ouvidos, e entender que mesmo que sua autoconfiança seja acentuada, de software entende ele, mas do negócio quem entende é o Usuário.
Dica 5 – O Usuário sempre vai solicitar alteração de escopo
Quando você pede para alguém fazer alguma coisa, ele faz da primeira vez exatamente do jeito que você queria que fizesse?
Aposto todas as minhas fichas que da primeira vez não fica do jeito que você queria. E o que você vai fazer? Vai solicitar mudanças!
Tem um ditado que diz: “quer que fique do seu jeito, então faça você mesmo”. Mas na vida isso é inviável, sem colaboração as atividades empresariais são impossíveis de serem executadas.
Mudanças sempre ocorrem quando o assunto é software e Usuário. Mas mudanças tem impacto. E muitas mudanças geram muito impacto. O Usuário sempre vai querer alterar as coisas, não costuma ficar satisfeito de primeira.
É fundamental tentar fazer o melhor na primeira vez que algo está sendo produzido, e também aculturar o Usuário sobre os problemas que muitas alterações causam no projeto, pois às vezes ele não percebe isso.
Aculturar significa criar uma cultura, e isso se dá com dialogo-o, treinamento etc.
E ainda, havendo a possibilidade, em projetos de software, sempre tentar usar conceitos de ágil e lean, onde as mudanças são melhor acordadas com os Usuários e melhor gerenciadas pela equipe.
Dica 6 – Estabelecer fim para o ciclo de validação
Geralmente acontece o seguinte: o Usuário vai validar alguma coisa que o Analista fez, e pede uma alteração. O Analista realiza o que foi solicitado, volta para validar com o Usuário, e o Usuário pede nova alteração. É como vimos na dica anterior.
Mas quando os recursos acabam, quando o prazo estoura, aí fica todo mundo apavorado, acabam as alterações, e vai “do jeito que tá”.
Estabelecer regras e deadlines para fim das validações é imperativo, senão a validação nunca termina, e junto com ela, as mudanças também são intermináveis.
Isso não significa fazer um trabalho mediano. Temos sempre que buscar a excelência, mas temos que ter bom senso, equilibrar necessidades com as possibilidades.
Frases como “o ótimo é inimigo do bom”, na minha opinião, é coisa de quem não quer ter excelência. Esta frase seria mais adequada se fosse algo como “apenas fazer o bom, se não for possível fazer o ótimo”.
Dica 7 – Documentar sempre detalhando ao máximo
Em relações comerciais “normais”, não existe acordo verbal. Infelizmente, hoje o que não está escrito não tem muito validade.
Então, documentar o que foi acordado entre Usuário e Analista é premissa, deve ser regra. Não é uma questão de desconfiança, é uma boa prática que elimina uma série de problemas futuros.
Quando não se documenta um escopo, e os problemas aparecem, sempre fica o jogo de empurra e empurra, e isso é ruim para todos.
Mas algo mal documentado pode ser pior que algo não documentado. É melhor não se comprometer, do que se comprometer com algo errado.
Então, documentar é regra, e também é regra documentar com o maior nível de detalhe possível, para se ter o alinhamento de expectativas adequado entre Usuário e Analista.
Dica 8 – Formalizar para valer de verdade
Um contrato bem redigido, entendido por ambas as partes, mas sem estar assinado não tem validade, concorda?
Se você já participou de projetos de software, quantas vezes você já viu algo do tipo: “isso foi escrito em algum lugar, mas não sei onde está o documento, mas à época foi feito e alguém aceitou que fosse assim”.
Se formos procurar em diretórios na rede, sistemas de GED etc. vamos encontrar um monte de documentos contendo especificações, mas que estão perdidos, ninguém lembra onde está, para que serve exatamente etc.
Por isso, formalizar é fundamental.
A formalização, além de gerar um acordo legal, do ponto de vista de legislação, dá tranquilidade para o Usuário e o Analista, serve de linha de base para o que tem que fazer, e gera engajamento das partes, gera compromisso.
E formalizar não significa que deve haver um rito burocrático para isso. Através de e-mail ou atas de reunião, por exemplo, é possível formalizar o que foi documentado.
Concluindo
Nós, Analistas de Sistemas, precisamos entender que lidamos com pessoas, e não somente com máquinas.
Na relação com o Usuário é necessário exercitarmos algumas habilidades que vão além do código e modelagem, algumas delas voltadas ao comportamento e ao negócio.
Caso você queira ver o conteúdo deste post em vídeo, segue abaixo o link do Youtube:
Um grande abraço!