Em busca de um certo fator X

Há basicamente dois tipos de organizações que procuram uma certificação de qualidade de processo: aquelas que querem mudar seus processos (de preferência para melhor) como efeito colateral e aquelas que não querem mudar nada, mas querem a certificação como diferencial competitivo.

O interessante é que certificações de processo só dizem respeito a – adivinhem só – processos. As organizações que emitem os certificados não se comprometem com a qualidade do produto. Um certificado desses quer dizer somente que alguém é organizado. O problema é que você pode saber que alguém é altamente organizado e nunca conseguir arrancar um bom produto dele. Ele pode te vender os piores pesadelos que sua imaginação possa conceber, mas vai fazer isso de modo completamente controlado.

Sério, é verdade. O grande trunfo das certificações de processo é que acreditamos que um processo de qualidade produz resultados de qualidade. Não há nada de estranho nisso. Em alguns casos isso realmente acontece.

Em outros não.

O diferencial competitivo verdadeiro, a qualidade de produto, não é alcançado por certificações. Talvez elas não cheguem nem perto disso. A melhor forma de avaliar a qualidade de um produto ou serviço é perguntar a seus clientes. Para eles o processo é um pequeno detalhe, um fator mínimo. Talvez isso seja decepcionante para quem está à procura do processo ou metodologia perfeita, mas é verdade.

Ao invés disso, o verdadeiro fator de sucesso pode estar em locais quase inexplorados, como um tesouro escondido no lugar mais óbvio. Um desses fatores por muitas vezes ignorado é a equipe. Bons profissionais bem motivados podem operar milagres. Uma equipe de profissionais bons e motivados sem nenhum processo formal é capaz de fazer produtos de alta qualidade. Isto pode não acontecer com muita freqüência, mas é possível. Porém é muito mais raro uma equipe de profissionais ruins ou desmotivados com um ótimo processo fazer algo de qualidade. Ainda não foi inventado nenhum processo capaz de conduzir esta última espécie ao sucesso. E se eu tivesse que apostar, diria que nunca vai ser.

Cada vez mais me convenço que estes são dois ingredientes essenciais dentro do caldeirão que produz o sucesso. A má notícia é que nenhum dos dois é fácil de se conseguir.

Bons profissionais são artigos raros e valiosos, tão disputados quanto um copo de água no deserto e criar motivação é um desafio por si só. Motivar bons profissionais é uma tarefa apenas para os mais insanamente destemidos.

Estes times de elite não vão trabalhar só por dinheiro. Claro que é preciso remunerá-los bem, mas esta é a menor parte da questão. Bons profissionais vão querer superar desafios, tomar decisões estratégicas e resolver problemas interessantes. Eles não vão ser seduzidos por escritórios luxuosos nem por algumas palavras da moda espalhadas a esmo em propostas de emprego.

Pelo menos não os verdadeiramente bons.

(re)Construindo

Você começaria a construir um prédio sem antes ter uma especificação detalhada?

Eu com certeza não me arriscaria. Mas tenho mais uma pergunta: se você pudesse construir um prédio e reconstruir partes dele livremente a custo quase zero, você esperaria uma especificação detalhada para começar a construir?

Eu também não.

Desenvolver software é muito mais parecido com a segunda do que com a primeira situação e é por isso que esta metáfora de construção não pode ser levada muito longe. Ao contrário dos produtos da construção civil, é fácil e barato mudar uma parte ou outra de um sistema mesmo que ele já esteja em produção, é fácil até trocar a ordem dos andares. Claro que é mais barato fazê-lo em fase de desenvolvimento, mas a diferença de custo pode ser controlada e mantida a níveis razoáveis. A principal razão deste baixo custo não é nenhum segredo: software não é construído por pessoas.

Ao invés disso, as pessoas apenas especificam software utilizando coisas chamadas de linguagens de programação. A parte da construção propriamente dita -- a montagem a partir de uma especificação -- é feita automaticamente por ferramentas como compiladores e interpretadores. No mundo do software, os construtores são coisas como estas e o tempo de trabalho deles é muito mais barato que o dos construtores humanos. Na verdade, pode-se encontrar alguns excelentes a custo zero.

É como se houvesse máquinas distribuídas gratuitamente que fossem capazes de receber um conjunto de plantas e construir rapidamente um prédio ou uma ponte sem nenhuma intervenção humana. Infelizmente, os engenheiros civis não têm essa sorte. Mas seria estupidez se os engenheiros de software não se aproveitassem dela para fazer seus produtos e colocá-los rapidamente à disposição dos clientes.

Ainda bem que eles fazem isso.

Bom, pelo menos alguns fazem.

Pagando as dívidas

Estou lendo O valor do amanhã de Eduardo Giannetti. Ele é um economista (não um programador, como a maioria dos autores que leio) e este livro em particular é sobre trocas e negociações intertemporais. Quando escuto dizer que um economista está falando de trocas intertemporais, não consigo evitar pensar em juros aplicados ao mercado financeiro. O que achei interessante é que Giannetti vê os juros em um contexto maior, identificando-os, por exemplo, na biologia. Aparentemente isto não tem nada a ver com software ou tecnologia, mas é por isso que o subtítulo do blog fala em devaneios.

Acontece que existe no cérebro dos programadores um mecanismo que faz ele relacionar (quase) qualquer coisa que lê com seu trabalho. Talvez os mais antenados já tenham identificado aonde quero chegar: o conceito de dívida de projeto, que talvez você já conheça pelo termo em inglês design debt.

Giannetti destaca a diferença entre envelhecimento e a senescência, dois mecanismos geralmente referenciados apenas pelo primeiro termo. Envelhecimento é o simples passar do tempo, o mecanismo pelo qual avançamos em idade e experiência. Senescência é o mecanismo que debilita um organismo com o passar do tempo. A senescência é o custo pago pelo vigor da juventude. Assim como os juros financeiros, a senescência é um custo pago na velhice (futuro) em troca de um benefício na juventude (presente). O organismo dispõe de tanta energia na juventude justamente porque vai pagar por ela na velhice.

O universo do desenvolvimento de software não está livre dos juros. Para cada atalho que tomamos no presente, cada "jeitinho" que damos, serão cobrados juros no futuro. Assim como no mercado financeiro, a quantidade de juros envolvidos na transação depende do tamanho do empréstimo que tomamos. Assim como não se deve rolar muito as dívidas financeiras, não se deve postergar demais o pagamento das dívidas de projeto. Quanto mais tempo correr, mais juros terão que ser pagos. Isso é um bom negócio para quem empresta dinheiro, mas não para quem produz software.

Todos nós queremos sistemas que durem bastante tempo e que continuem gerando dividendos: sistemas velhos. Mas ninguém quer um sistema senil, um no qual a receita não compense o esforço gasto com o pagamento de juros. Então é melhor consertar hoje aquelas pequenas gambiarras que você fez ontem. Cada vez que pensar "puxa, isso deveria mesmo ser feito de outro jeito, mas vou fazer desse jeito aqui para ir mais rápido", não pare na parte do pensamento. Uma abordagem muito mais indicada é fazer do jeito rápido, ter testes que comprovem o funcionamento e consertar para o jeito certo.

Nota: O Motiro foi oficialmente lançado nesta segunda-feira. Pensei em fazer um post para anunciar isso, mas este blog já está tão infectado com notícias sobre Motiro que preferi fazer somente esta notinha aqui. Maiores informações (e links para o código-fonte e downloads) no blog do projeto.