Custos

(pré-requisito: saber como funcionar o Planning Game do Extreme Programming)

Problema que vejo frequentemente por aí: o sistema está indo razoavelmente bem, então o cliente começa a pedir coisas e mais coisas. Algumas delas fazem sentido, outras são puramente cosméticas ou desnecessárias. O sistema começa a atrasar e o cliente fica bravo porque as funcionalidades agendadas não foram implementadas em tempo... Mas não conta que as coisas que ele pediu consumiram tempo.

Moral da história: um pouco mais de má fama para o nosso lado.

Caso 2: O cliente não tem a menor noção de quanto custa implementar uma funcionalidade. E o pior, não sabemos como mostrar ao cliente esse custo.

Moral da história: o cliente pede e não percebe que está pagando. Efeito colateral: a empresa de desenvolvimento é quem acaba pagando boa parte das funcionalidades. No mínimo, desgastando a equipe com horas extras que poderiam ser facilmente evitadas.

E aí? Como resolver?

Tirei uma boa experiência do XP nesse ponto. Como cada funcionalidade recebe uma estimativa em "unidades de tempo relativo". Bastou medir quantas dessas unidades a equipe fazia por mês e dividir o quanto o cliente pagava no período. Isso dá o custo por unidade. A partir desse momento, cada funcionalidade passa a ter automaticamente o custo assim que recebe a estimativa.

Aí, é questão de receber a requisição, estimar e devolver para o cliente com o custo. Resolve bem:

Exemplo:
Unidades mensais no projeto: 100.
Pagamento mensal (ou parcela): 8.000,00

Qto custa cada unidade? 8K / 100 = 80,00

Chega uma requisição, estimamos ela em 3 unidades. Custo = 80,00 x 3 = 240,00. Uau! Caro!

Simples demais pra servir pra algo? Talvez, mas a precisão é suficientemente boa para dar ao cliente uma noção de custo e simples o suficiente para eu não precisar implementar um processo somente para isso. Um bom custo benefício, diria eu.

Se você pensar um pouco, consegue estrapolar a idéia, calculando seu custo por unidade ou então o custo por hora (baseado em unidades/hora). E, é óbvio, o melhor é que isso dá automaticamente o seu custo por projeto no momento em que a estimativa inicial fica pronta.

Achou falhas na idéia? Ótimo, posta aí. Pra mim, anda funcionando particularmente bem. Posso ser simplório, mas acho que nossa área reclama de barriga cheia, é bastante simples calcular o custo de 90% das coisas que fazemos. O que dá um pouco de trabalho é o ROI, mas com um pouco mais de estimativas dá pra ter uma excelente noção.

Mas aí é outro post.

Dividir para conquistar

Qualquer especificação de sistema ("A especificação"), costuma ser grande e cheia de furos, faltando detalhes importantes, explicando parcialmente o processo, assumindo conhecimento comum em partes que somente um especialista de negócio saberia entre outros horrores.

Particularmente, penso que o problema está no tamanho da coisa. É meio simplória a idéia, mas veja:
1 - Qto maior, naturalmente mais complexo (senão é encheção de linguiça), portanto, mais difícil de estimar. É por isso que costumamos quebrar em funcionalidades primeiro.
2 - Em uma massaroca de detalhes, é fácil deixar escapar alguns importantes, tb é fácil deixar de incluir algum importante inadvertidamente.
3 - O mesmo texto frequentemente mistura overview do sistema com detalhes dos módulos, quando mal redigido (e frequentemente é), causa uma tremenda confusão. Já vi especificações que não seguiam uma linha de pensamento, descrevendo módulos e funcionalidades ao léu.

Pois bem, parte do problema seria resolvido se a mesma pessoa que redige a especificação fosse um especialista no sistema E um bom escritor. Porém, mais frequentemente do que eu gostaria, é um analista de sistema que não é nem uma coisa, nem outra.

Inspirado em User Stories e Use Cases, fico imaginando se "A" especificação não deveria na verdade ser toda picotada. Textos menores descrevendo casos de uso ou funcionalidades, mais um overview que juntasse as partes. Fica mais fácil avaliar e pensar em cada parte e verificar os detalhes, tudo porque um texto menor e mais focado é menos em que se pensar.

Será que consigo fazer um teste com isso?

Programming as a Theory Building

Sempre fiz parte daqueles que acham que o conceito de "fábrica" de software segue um modelo pouco adequado, pra não dizer completamente sem noção. Software não se produz em linha de produção: "Entra requisito, sai programa". Tentativas de fazer isso, principalmente com o objetivo de baratear o "peão-programador", costumam dar muita dor de cabeça (ou não?).

Acredito que, se fosse possível uma comparação, talvez a programação fosse o desenvolvimento do projeto do carro. A produção do carro em si, como tudo mais na informática, é compilação e cópia.

Opinião pessoal: acho que software é o paraíso pra essas coisas. O problema é que a "produção" é tão simples que é difícil evitar que qualquer um faça. E vive la piraterie!

Bom, de volta ao assunto, ontem um colega apresentou um trabalho interessante e se baseou em um artigo de 1985 de Peter Naur (Turing-award 2005, é fraco?!) que expressa a mesma linha de raciocínio.

Então eu fiquei feliz, além de outra meia dúzia de retardado mental com a mesma opinião, tem doutor que pensa a mesma coisa desde o tempo que microcomputador era um teclado conectado na televisão.

O artigo chama-se "Programming as a Theory Building", achei várias referências ao seu conteúdo, mas nada de achar ele online. Finalmente, achei uma referência dizendo que o Agile Software Development do Alistair Cockburn tem uma cópia dele. Maravilha! Dureza é comprar um livro de US$38 + taxa de entrega por que você tem interesse real só em um artigo. Não que o livro seja ruim, deve ser bom, mas comprar ele ia ser efeito colateral do que eu quero.

O ponto agora é tentar juntar todas as referências que eu puder sobre a mesma linha de pensamento e ver o que eu consigo montar. Vamos ver :D