Profissionais TI - Pra quem respira informação

Não é incomum hoje encontramos projetos, seja em nosso local de trabalho ou em projetos pessoais, onde o cliente faz uma exigência de qual tecnologia será utilizada para o desenvolvimento do projeto. Contudo, este assunto é pouco abordado ou mesmo pensado, levando a vários empecilhos, seja por parte do cliente “Dono do projeto” ou da equipe de desenvolvimento – “Mão de obra especializada”.

Existem incidências em vários projetos, alguns tive oportunidade de presenciar, onde o cliente solicitou que o projeto fosse feito em Java, porém, a equipe é especialista em PHP, ou o cliente solicitou que o site fosse feito utilizando WordPress, mas, os desenvolvedores utilizavam Drupal ou Joomla.

Nesses casos, foram elaboradas pesquisas por parte da equipe de desenvolvimento para mostrar para o patrocinador do projeto que a escolha dele nem sempre era a melhor, e posteriormente o resultado dos dados colhidos eram enviados para o gerente de projetos ou escolhido da equipe ou, no caso de um projeto pessoal, o próprio desenvolvedor que a fez.

Nem sempre o que a equipe apresenta é aceito pelo patrocinador

Em muitos casos os donos dos projetos exigem que o produto seja desenvolvido em uma plataforma específica ou um framework específico por familiaridade com o mesmo, com isso a resistência do mesmo é quase impossível de ser quebrada.

Uma abordagem que pode ser utilizada para esses casos, consiste em não mostrar um comparativo entre a tecnologia escolhida
pelo cliente e a que a equipe pretende. Este tipo de comparação pode ser desastrosa, segundo minha experiência em vários casos, afinal o cliente optou por uma tecnologia que o mesmo está acostumado ou familiarizado e pode passar a levar sua escolha como pessoal e defende-la até o final, não importando o quanto você ou sua equipe se esforcem para defender seu ponto de vista.

E o que pode ser feito?

Algo que pode ser feito é conversar de forma clara mostrando o que vocês podem fazer com a tecnologia que a equipe está propondo, os ganhos e benefícios e o quanto isso irá trazer de benefícios em diminuição em larga escala no desenvolvimento, na entrega e no tempo de resposta para as solicitações futuras.

Um ponto de vista que precisa ser deixado claro nas reuniões de projetos é que, embora o cliente seja o patrocinador, o mesmo tem que corroborar para que o projeto seja entregue e que o desenvolvimento do mesmo depende tanto da equipe como dele, os interesses dele devem ser maleáveis suficientes para que os interesses da equipe de desenvolvimento não sejam prejudicados. Nesse caso, aconselha-se o uso de gráficos de desempenho de projetos anteriores com os sucessos onde houve cooperação entre a equipe e o patrocinador.

Contudo, haverá casos onde o cliente não aceitará essas propostas, onde infelizmente não há mais o que ser feito: ou adere os requisitos não funcionais do patrocinador ou não há possibilidade que seja desenvolvido algo.

Existem situações onde a decisão do cliente fica fora de forma tão extrema que temos que utilizar o framework que o mesmo designou e a tecnologia que ele também solicitou, afinal de contas os requisitos não funcionais podem ser um fator decisivo para a aceitação do cliente.

Mesmo o cliente aceitando as propostas feitas pela equipe, começa uma preparação que, talvez, seja mais pesada, que é a adaptação do cliente com a nova tecnologia. Como sua experiência era com algo que talvez seja totalmente diferente, a frase “no outro eu fazia de tal jeito e achava melhor” poderá surgir com frequência.

Isso é algo que sempre irá acontecer, independente do quão seja boa sua proposta. Contudo, é algo a se esperar, pois a cultura do cliente era totalmente outra.

Fica a dica! Quem quiser entrar em contato, fico a disposição.