…e, sim, o valor que o software irá agregar – se for entregue.

Esse artigo será dividido em três partes, com muitas verdades inconvenientes sobre código versus produto, “PO imaginário” x “PO real” e documentação versus conhecimento.

Código versus produto

Ao redor do mundo, milhares de softwares rodam nesse momento. Feitos nas mais diversas tecnologias, com as mais diversas abordagem e linguagens, eles resolvem problemas de milhões de pessoas. Pessoas que solenemente ignoram o que ocorre dentro de seus computadores e cujo foco diário é somente tocar suas vidas com o auxilio dessas ferramentas geradas pelo profissionais de T.I.

São softwares que foram para produção, atendem necessidades reais e que são testados na mais dura prova que um programa pode ser submetido que é o uso diário.

Aonde eu quero chegar com essa história? Bem, a despeito de qualquer conversa (importante, é claro) sobre qualidade de código, técnicas de desenvolvimento e o que mais se quiser colocar na mesa, a maior prova de sucesso de um sistema de informação é o uso em produção.

Nada adianta um sistema ser de fácil manutenção, feito na tecnologia mais cutting edge e cujo código faria Turing chorar de tão bem escrito. Seu sucesso, ou fracasso está na percepção do usuário de que o mesmo atende suas necessidades. Resumindo, não basta atender as necessidades e agregar valor, é necessário que o usuário perceba isso.

Gostaria de destacar aqui, que não estou defendendo o código spaguetti: embolado, esquisito, ruim, ou feioso. Estou defendendo o pragmatismo do desenvolvimento, e mais: o controle da paixão da codificação pela codificação.

Boa parte das grandes discussões sobre desenvolvimento atuais tem perdido o foco. Ao invés de discutirmos “como desenvolver softwares melhores” ou “como desenvolver softwares que atendam melhor as necessidades de nossos clientes”, temos discutido “como desenvolver melhor”.

Como disse Marko Taipaleem um artigo :

“It is more important to build the right thing than build the thing right.”
Isto é : “é mais importante construir a coisa certa, do que construir do jeito certo”.

A verdade é que os desenvolvedores chegaram ao século XXI muito maltratados. Depois de décadas padecendo nas mãos de gestores que nada entendiam de tecnologia e que impunham pesados processos de desenvolvimento cheios de documentos a serem preenchidos e que nada agregavam, os desenvolvedores vislumbraram a terra prometida: o manifesto ágil.

Nele o foco era o resultado, a entrega e o valor agregado. Porém, o tempo (e a má interpretação do manifesto) foi criando uma leva de programadores apaixonados (demais) pelo próprio trabalho. Mais até do que pelos resultados práticos do mesmo.

A questão não era mais o número de projetos de sucesso em que já se tinha atuado, e sim a qualidade intrínseca da coisa. Isto nos levou ao desenvolvedor o superstar, aquele que está mais ligado no software sexy, do que no software do dia a dia. Aquele que só quer desenvolver em tecnologia de ponta.

Mais uma vez: o código não vai nos salvar. Seu código pode ser lindo, uma maravilha, uma ode a Dijkstra. Mas se ele não resultar em um produto que atenda as necessidades do usuário, ELE NÃO SERVE PARA NADA. Se ele não for entregue dentro do prazo, ele também não serve para nada. E mais do que isso, se ele atender, mas não conseguir passar pelo teste do uso em produção, ele REALMENTE NÃO SERVE PARA NADA.

O equilíbrio entre qualidade de código e os custos de construção é uma variável importantíssima e que não pode ser negligenciada no decorrer de um projeto de desenvolvimento. Isto é, devemos achar um equilíbrio entre o estado da arte e a tríade possibilidade – tempo – custo.

Fechando a verdade inconveniente número um deste artigo, já encontramos diversas maneiras excelentes de desenvolver software, mas ainda estamos devendo aos clientes o desenvolvimento de maneiras melhores de concluir o que devemos desenvolver, isto é, o que lhes agrega mais valor.

Sabemos COMO FAZER, mas temos grandes problemas em determinar O QUE FAZER.

Obviamente muitos vão dizer que a responsabilidade de dizer o que agrega valor e dessa forma deve ser desenvolvido é o Product Owner. E é aí que vamos para segunda verdade inconveniente no próximo artigo. Aguardem!