Não existe segredo: desenvolvedores e designers precisam colaborar entre si

Durante o desenvolvimento “Enterprisey” de aplicações web temos dois papéis realmente importantes dentro da equipe: o desenvolvedor e o [web] designer. Cada um possui suas atividades bem definidas durante o desenvolvimento do software, mas em algum momento será necessário que eles sentem juntos e colaborem para definir os detalhes da GUI.

Eles não irão colaborar entre si para definir a identidade visual da aplicação [não que não seja possível], mas sim para acertarem os detalhes “baixo nível” da interface ou mesmo como definir melhor a experiência do usuário. No final das contas, eles podem discutir sobre css, javascript, tags de marcação XHTML ou uma melhor disposição dos componentes visuais.

E isso é comum com qualquer tecnologia para web, seja ela PHP, RubyOnRails, .Net ou mesmo Java.

Mas o que eu realmente não entendo é porque muitos profissionais (desenvolvedores, gerentes, designers etc) encaram que desenvolvedor e designer não precisam -ou mesmo não deveriam- discutir sobre o design da interface da aplicação.

O que difere a comunicação entre um desenvolvedor e um analista de negócios que tentam definir ou acertar detalhes sobre o modelo de domínio da aplicação, e a comunicação entre um desenvolvedor (ou analista) e um designer que tentam acertar detalhes da interface com o usuário?

Nenhuma! Não há qualquer diferença, eles conversam e colaboram entre si com a mesma finalidade: terem software funcionando e que agregue valor ao cliente.

O que leva tantos profissionais a pensarem que desenvolvedor e designer são “peças” isoladas durante o desenvolvimento do software? Um modelo em cascata, talvez. Por estarem trabalhando num processo fabril de fábrica de software, talvez.

Não sei ao certo o motivo, mas sei que uma boa parte da culpa está na “balela” que algumas empresas-de-três-letrinhas tentam empurrar sobre seus clientes e/ou desenvolvedores que utilizam suas tecnologias/ferramentas. Um bom exemplo disso é a tecnologia JSF, na qual temos a descrição abaixo dada pela Sun:

Ease-of-use being the primary goal, the JavaServer Faces architecture clearly defines a separation between application logic and presentation while making it easy to connect the presentation layer to the application code. This design enables each member of a web application development team to focus on his or her piece of the development process, and it also provides a simple programming model to link the pieces together. For example, web page developers with no programming expertise can use JavaServer Faces UI component tags to link to application code from within a web page without writing any scripts.

Por mais bonito que isto pareça ser, eu tenho o dever de alertar aos mais desavisados: isso dificilmente irá funcionar durante o desenvolvimento com JSF – para falar a verdade, eu acho muito dificil que qualquer tecnologia hoje em dia consiga prover tamanha separação de responsabilidade (entre designer e desenvolvedor) de forma transparente e produtiva.

Qualquer desenvolvedor web que se preze possui, ao menos, os conhecimentos mínimos sobre XHTML, css e javascript para entender e manter algum código escrito por outra pessoa ou mesmo por um web designer. Se você é um desenvolvedor web e não possui qualquer conhecimento sobre o que eu disse acima então já está mais do que na hora de você aprender.

Não subestimando os designers, pois eu conheço alguns muito bons, mas se levássemos essa separação de responsabilidades ao pé da letra você acha mesmo que eles conseguiriam desenhar excelentes interfaces utilizando apenas as taglibs dos componentes ou conjuntos de componentes JSF?

Alias, você acha mesmo que um designer teria produtividade ou conseguiria expressar sua criatividade limitado apenas a algumas dezenas de tags, por mais ricos que sejam os componentes, visualmente falando? Isso pode piorar ainda mais se este designer for obrigado a utilizar algum editor -com o qual ele nunca trabalhou- apenas por causa do suporte a code-completion para as tags dos componentes.

JSF é uma boa tecnologia, e por mais que ela nos forneça centenas de componentes, frameworks para templating de páginas e estes componentes possuam um sistema de skinning ainda assim no final das contas teremos XHTML (css e javascript também) gerado. Sendo, de duas, uma: ou o designer deve ter conhecimento sobre o código gerado pelos componentes ou ele deve ter conhecimento de como trabalhar com o suporte a skinnking dos componentes.

Qualquer que seja a opção acima, o designer estará com mais responsabilidades do que o necessário. Por isso é tão importante a interação entre um designer e um desenvolvedor para solucionar problemas decorrentes da tecnologia adotada.

Eu falo tudo isso por experiência própria, pois há alguns meses eu tive uma razoável dificuldade para aplicar o css, definido no prótotipo do sistema, nos componentes JSF da aplicação, atividade esta que deveria ser relativamente simples. Sim, o conjunto de componentes que eu utilizei suportava skinning, mas quem disse que isso é suficiente quando o XHTML gerado por alguns componentes mais complexos é totalmente diferente do XHTML escrito pelo designer?

Foram vários dias adaptando o css da aplicação e, ao mesmo tempo, discutindo e redefinindo com os designers alguns pontos do css do prótotipo para que no final tivessemos o resultado ideal. E com certeza eu não teria sucesso nesta atividade se não fosse pelos dois grandes designers da equipe, Carlinhos e Anderson, que sentaram ao meu lado algumas longas horas durante a semana para me ajudar.

Certamente que há casos onde não podemos contar com um designer na equipe, como:

  • projetos em que a presença do designer é inexistente na equipe e algum desenvolvedor precisa assumir mais este papel;
  • o designer faz parte da equipe, mas por algum motivo ele sempre encontra-se impossibilitado de interagir com ela nos momentos de maior necessidade;
  • ou nos piores casos, o protótipo da aplicação foi criado por outra empresa.

Para cada situação é possível chegarmos a uma solução milhares de vezes melhor do que apenas ignorar o problema de que não há um designer na equipe – mas não é esta a questão do post.

Enfim, é muita ingenuidade (ou falta de conhecimento) destas pessoas que acreditam que desenvolvedores e designers [ou quaisquer membros da equipe] não precisam colaborar entre si para alcançar um resultado ideal que agrade o cliente.

Desenvolvedores não pensam, desenvolvedores seguem casos de uso

Há algum tempo atrás eu participei de um projeto que se encontrava dentro de um processo absolutamente waterfall, para falar a verdade, a maioria dos softwares desenvolvidos aqui no mercado local seguem o processo em cascata, em sua grande maioria, através de fábricas de software. Bem, durante um certo dia na fase de codificação eu acabei tendo uma dúvida num caso de uso que me foi entregue, para ser mais exato a dúvida era em relação ao negócio da aplicação, ótimo, mesmo dentro de um processo em cascata ainda assim o analista de sistemas (negócios?) estava próximo da equipe de desenvolvedores, fui até ele conversar sobre o que não havia entendido no caso de uso, e ao debater com ele sobre o problema que não estava claro -pelo simples fato de não haver uma linguagem comum entre a equipe- eu ouço da boca do analista o seguinte comentário:

Para que tu quer entender isso? Desenvolvedores não pensam, desenvolvedores seguem casos de uso. Programadores só deveriam pegar o caso de uso, ler e seguir o que ele diz, nada mais. Não há porquê entender as regras de negócio, o caso de uso tem tudo que se precisa saber. Blah blah blah..

Wow! Depois de ouvir isso eu me calei por alguns segundos e pensei comigo mesmo, “Será que ele tem noção do que acabara de me dizer?”, e o pior é que este analista disse isso com uma certa arrogância, na frente de outros analistas (que calados pareciam concordar), logo começamos a discutir, eu tentando dizer que não havia fundamentos no comentário dele e que eu não entendia como ele acreditava naquilo.. depois de alguns minutos eu resolvi encerrar a discussão para evitar constrangimentos para ambos (pois estávamos no cliente).

Parece brincadeira, mas aquilo aconteceu mesmo (eu deveria estar realmente surpreso?!). Pergunto-me como em pleno ano da graça de 2008 um analista com anos de experiência em diversos projetos, formado em uma das melhores universidades do estado, e com certeza com mais alguns (ou até vários) diplomas e certificados debaixo do braço consegue verbalizar tamanha asneira. Mais incrível ainda é como um analista desses consegue acreditar tão fervorosamente que está certo, como ele consegue acreditar que um desenvolvedor é apenas mais um recurso comum para um trabalho manual, e facilmente substituível dentro da famigerada fábrica de software que ele tanto venera, alias, qual é a dificuldade em compreender que um programador não é um “digitador de luxo”? Será que depois de tanto tempo de profissão ele ainda não entendeu que desenvolver software é essencialmente um ato de criação? É, parece que não.

Um desenvolvedor mais do que ninguém deve entender sobre o negócio do cliente, um desenvolvedor deve estar mergulhado no negócio na qual pretende desenvolver o software ou parte dele, de fato, como será que este analista imagina que um desenvolvedor pode implementar algo minimamente decente sem entender o problema? Através da ajuda de alguma entidade sobrenatural?

No fundo, acho que ouvir isso de qualquer profissional no ramo de desenvolvimento de software é um absurdo, e para mim está óbvio que esta pessoa precisa urgentemente voltar a estudar sobre o assunto (pois ela parou de estudar há muito tempo, 10 anos talvez), e claro, mais do nunca ela precisa de uma “reciclagem”.

Engraçado é que este fato me fez lembrar de um acontecimento um tanto quanto embaraçoso interessante que ocorreu no inicio da minha carreira como desenvolvedor, há mais de 3 anos, eu possuía menos que um ano de experiência na época, e havia enviado o currículo a uma empresa que estava ofertando uma oportunidade para desenvolvedor Java, parecia uma boa empresa, depois de enviado o currículo eu recebi uma ligação alguns dias mais tarde para uma entrevista, na época eu fiquei super excitado, e parei para rever meu currículo cuidadosamente, ao reler o currículo vi que não sabia exatamente sobre o que se tratava 2 (dois) projetos na qual havia participado na primeira empresa que trabalhei, eu tinha uma vaga e distante idéia do que havia desenvolvido (em termos do negócio do cliente), mas ainda assim eu não conseguiria explicar a alguém (principalmente a quem fosse me entrevistar) sobre a finalidade dos projetos.

Então durante a semana, eu -na minha mais pura ingenuidade- enviei um e-mail ao meu antigo chefe (que além de ser um empresário, ele também era um talentoso desenvolvedor e amigo) pedindo informações sobre o que se tratavam os projetos que eu havia participado. A resposta dele não foi bem a que eu esperava [rs], porém me abriu os olhos na época. Alguns trechos do e-mail seguem abaixo:

De:rponte@gmail.com Para:boss

Fala amegão,

[…] Seguinte, tu pode me passar um resumo pequeno mesmo, porém decente das aplicações que eu participei ai na empresa para que eu possa colocar no currículo, pode? :))) […]
De ante mão eu te agradeço, abraços.

De:boss Para:rponte@gmail.com

Você não sabe pra que serviam os projetos que participou? rs Então não vale a pena colocar no currículo né? Você coloca que nesses projetos só fez programação pura.

Depois desse e-mail eu fiquei realmente envergonhado, vi que por mais que gostasse de desenvolver software eu não me interessava pelo negócio do cliente, eu não me interessava em entender e aprender sobre ele, o que sempre me interessava eram as tecnologias e os frameworks mais “hypes” do mercado. Entendendo como funcionava o mais novo framework da época já valia a pena estar desenvolvendo algo.

A partir dai, eu resolvi mudar isso, foi um processo lento mas contínuo, graças a certos amigos, blogs (Shoes, Guilherme etc), discussões em listas e fóruns, e muitas linhas de código mal implementadas (claro, como eu poderia implementar algo decente sem entender o problema?) eu procurei compreender sobre o problema do cliente e como expressa-lo em código, eu procurei ler sobre metodologias agéis, abordagens e boas práticas de design de software, maneiras de melhorar a comunicação entre os membros da equipe e várias outras coisas que me ajudaram e me ajudam até hoje.

Depois de tudo que eu estudei e procurei aprender eu ainda tenho que ouvir de um analista que eu não preciso entender sobre o negócio do cliente? Ah, por favor, eu não sou um “programador” que não pensa e simplesmente segue algumas folhas de papel com vários diagramas UML e fluxos alternativos escritos por analistas de sistemas, eu -como desenvolvedor- devo estar tão próximo do negócio quanto for necessário, mas isso é bem complicado quando trabalhamos num modelo em cascata em que a comunicação entre os membros da equipe ocorre através da troca de documentos e diagramas, e pior, quando trabalhamos com “profissionais” que acreditam que isso funciona.

Enfim, já basta os softwares bolovos e sem testes que temos que manter, já basta os processos burocráticos que temos que participar, já basta estarmos rodeados de fábricas de software e code-monkeys preguiçosos, já basta a desvalorização e os péssimos salários pagos aos desenvolvedores, e agora me vêm com analistas de sistemas retrógrados (oops!, pareço redundante) ? Por favor, me perdoem, mas as vezes acho que o mercado local está caminhando para trás quando se fala em desenvolvimento de software, mesmo conhecendo algumas poucas empresas, grupos e bons profissionais dispostos a mudarem isso.