Após um bom tempo, participei de um processo seletivo. Neste caso em específico, devo dizer que estava de certa forma lisonjeado, pois fui convidado. Eu não estava procurando um emprego. Acabei sendo descartado, pois segundo a pessoa que me entrevistou, hoje tenho um perfil mais sênior do que o que eles precisavam. Acho que ouvi uma seda se rasgando.

Num certo momento, o entrevistador foi explicar-me como o PMI funcionava tão bem em uma fábrica de software. As explicações iam desde um excelente modelo de planejamento até um detalhado processo de gerenciamento de projetos. No entanto, não me contive e por várias vezes disse não acreditar que esta metodologia fosse eficiente para desenvolvimento de software como um todo. Então, eis que o segredo foi revelado: nós garantimos que a especificação do cliente jamais será alterada, com documentos, contratos, assinaturas e testemunhas. Pensei estar numa fábrica de gesso.

Devo admitir que sou fruto de um ambiente fabril. Já trabalhei com fábricas de cimento, cal, calcário, vassouras, etc. Quando enveredei-me para o universo de TI quis seguir a risca o modelos conhecidos de gestão de processos fabris. Admito que por uma década acreditei e evangelizei práticas de gestão que tinham como foco a “serialização” do desenvolvimento de software. Não preciso descrever os fracassos que alcancei.

Quando há cinco anos iniciei minha jornada de conhecimento sobre práticas ágeis, passei por um processo de desconstrução de um pensamento fabril. Imputar em minha mente uma nova cultura que mais parecia a celebração de práticas proibidas era quase impossível.

Minha primeira reação foi a situação custo-benefício. Meu contato com a argumentação do desenvolvimento ágil foi quando, em uma certa empresa, precisamos decidir qual modelo de padrão de desenvolvimento deveríamos seguir. Alguém sugeriu que RUP seria a solução. Constatamos, porém, que levaríamos no mínimo três meses de treinamento e neste tempo o desenvolvimento em si da solução estaria parado.

Surge então uma pergunta bastante peculiar: se estamos decidindo qual padrão utilizar para um desenvolvimento que por consequência é de extrema importância e necessidade, esperar três meses para iniciá-lo não faz dele algo sem importância nenhuma?

Em meu pensamento a época, indaguei se seria de nossa responsabilidade definir se um sistema, é ou não importante, que deveríamos apenas executar. Descobrimos então que nenhum dos presentes teve ou teria contato com o cliente de fato. A função do analista era por divindade e consequência a resposta para qualquer questão ainda não feita. Essa pessoa tinha a responsabilidade de dominar em nível “level XXXVI”, mesmo que temporariamente, qualquer que fosse o processo de negócio. Deveria antecipar a reação do cliente e se preocupar com o gosto coletivo.

Quando se trabalha numa indústria qualquer, normalmente somos bombardeados por políticas de qualidade das mais diversas e variadas. Mas há sempre um ponto comum a todas as políticas: a satisfação do cliente. O que podemos dizer sobre satisfação do cliente? Algo do tipo: adivinhe o que estou pensando e faça pelo preço mais barato? Talvez seja.

Desta maneira, consideramos o cliente uma ponta final isolada do processo. Ele não precisa saber como se faz cimento, acredita que naquele saco exista cimento e jamais questionará seu modelo de produção. E está correto! A finalidade do cimento é comum a qualquer pessoa que possua a necessidade de construir ou reformar. Softwares, por sua vez, são a extensão de uma idea com a finalidade de resolver um problema ou gerar algum valor. Não é algo exato, pois carece da interpretação de quem o desenvolve. Aliás, quem o desenvolve, não quem o fabrica.

Acredito não ser possível serializar a criatividade no conjunto de desenvolvimento de uma aplicação. Se assim fosse, haveria um modo perfeito de código e este não mais precisaria de evolução. Seria como se a realidade dos problemas fosse estática e comum a qualquer indivíduo.

Quando um cliente tem uma necessidade, a nível de sistemas, esta necessidade é contaminada pela sua noção de resolução. De forma que sua solicitação ou especificação se baseie em sua experiência com o fato, e com sua criatividade e imaginação em definir como seria a resolução.

Quando programadores ou analistas constroem a sua interpretação de resolução, surge a máxima: o cliente não sabe o que quer.

Mais do que problemas de comunicação e interpretação, o fato de que um problemas pode ser resolvido de N maneiras faz com que as decisões sejam direcionadas a quem tem mais poder e não necessariamente a quem tem mais técnica. Se eu pedi e paguei eu sei o que é melhor. Se eu estou fazendo eu decido o que é melhor. Não quero esquecer que, em grande parte, desenvolvimentos são contratados no modelo de prestação de serviços e o cliente passa a enxergar o mesmo como um serviço contínuo e evolutivo e não como um produto. Tal possibilidade induz muitos desenvolvedores a buscarem táticas de previsão de problemas e acontecimentos que não foram solicitadas pelo cliente, mas que seriam cobradas como erro e não como definição mal estruturada.

Este pressuposto, no entanto, induz ao pensamento de que há uma forma eficaz de se definir um modelo eficazmente. E há: resolvendo apenas problemas que existem agora.

Modelos fabris partem da premissa de que é possível prever o comportamento do maquinário, do ser humano em função do maquinário e da variação comportamental decorrente de alguma surpresa no ambiente. Tal modelo é facilmente vistos em simulações em que por mais que hajam variáveis, as mesmas são previsíveis.

Como prever o comportamento de uma idea ou de uma esperança? Se o cliente espera que um sistema hoje faça A, pode perfeitamente querer que faça B em função de uma nova experiência adquirida ou promovida. O que não invalida a veracidade da necessidade do mesmo. Porém, ao longo dos anos, eu pessoalmente, descobri que não é possível o desenvolvimento baseado na esperança ou em idéias insólitas. É preciso apenas e simplesmente desenvolver por fatos.

Ainda assim não há subsídio para a “serialização” do desenvolvimento. Uma vez que o conjunto resultante é orientado a questões individuais e únicas, mesmo que para resolver problemas comuns.

Hoje entendo que há uma série de bons métodos, mas que estes estão limitados a sua contemporaneidade (palavra difícil), ou seja, foram criados para solucionar questões de um dado tempo tecnológico. Mas estamos em constante evolução e nem sempre as metodologias acompanham. O surgimento de novos frameworks de alta produtividade nos fazem rever conceitos de engessamento de escopo, iterações com clientes, mais tempo de dedicação a estudo e menos tempo desenvolvendo.

Nenhuma receita mágica ou fórmula fundamentalista será capaz de resolver todos os problemas. Assim como a indústria teve seu tempo, surge o momento da Tecnologia da Informação adaptar-se a incorporar-se ao ambiente tecendo suas diretrizes enquanto indústria. E rever conceitos é a “única rotina” que deveria ser aceitável em desenvolvimento de software.