Cadeia de felicidade

Esses dias atrás tivemos uma tremenda carga de trabalho aqui. Horas estressantes cheias de "não dá", "estamos perdidos" e outras frases que não dá pra publicar em um blog inocente.

Passada a carga, sistema entregue, o cliente sorri de orelha a orelha. Então o gerente sorri e faz piada, aí eu sorrio e me sinto bem. Toda a pressão se foi, consigo até endireitar as costas na cadeira.

Essa é mais uma das vezes que vejo esse efeito "cadeia de felicidade", cliente feliz, gerente feliz, desenvolvedor feliz. Não sei se é pelo alívio de pressão, se é pelo prazer de ouvir o cliente elogiar ou o quê. Ignoro a causa, mas percebo o efeito.

Resultado, meu lema últimamente virou: "Mantenha o cliente feliz". Isso não tem nada de altruísta ou profissional, é completamente egoísta: EU sou o cara que fica feliz no fim dessa cadeia.

Em tempo... o contrário também costuma verdadeiro.

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

Contra as patéticas Universidades

Eu fico de cara no chão o quanto as universidades desse nosso Brasil querido são completamente ineficientes em formar profissionais da área de informática, especialmente programadores. Cursos que ninguém sabe sobre o que são, currículo "abrangente" que não abrange nada que interesssa. Vai mal.

Temos curso de "Engenharia da Computação", o desgastado "Análise de Sistemas" e o antigo mas ainda com prestígio "Ciências da Computação", sem falar em uma infinidade de variantes novas como "Tecnologia da Informação" e sei lá mais qual nome andam inventando. Agora, se você perguntar a qualquer pré ou pós universitário qual a diferença entre um em outro você vai receber um tímido "não sei muito bem" bastante insípido de se engolir.

Bonito né? Quer melhor, pergunte a alguns _professores_ do curso qual a diferença entre os cursos e me diga quantos souberam responder certo e sem embromation. O único cara que deve saber com certeza é o coordenador do seu curso.

Agora vou pegar mais embaixo. Qual desses cursos ensina programação? Uh... todos...
Jóia, então já dá pra entender porque as empresas todas colocam nos anúncios de emprego "curso superior em informática", sem especificar qual. Pra quê? Todos sabem informática e é tudo uma coisa só.

E qual desses cursos forma "programadores" (é.. programador; não cientista, nem analista: eu disse "p r o g r a m a d o r")? Nenhum??? É... como eu desconfiava, pra programação não precisa estudo, é coisa de peão mesmo. Programador é igual pedreiro. (O que me lembra uma frase de um cara num concurso pra lixeiro: "Não sei se é bendito ou maldito o país que exige pelo menos segundo grau para lixeiro mas não para Presidente da República").

Ah... Cientista da Computação, Analista de Sistema e afins todos sabem programar, é o mínimo, não é? Correto... aprenderam técnicas de debug? Conseguem fazer um teste automatizado? Sabem pelo menos o que são idiomas, certo? Ahhh... não... mas sabem fazer um programinha. Esses tópicos são avançados, talvez mestrado. Ou talvez dia a dia no mercado de trabalho.

Ops, esqueci. Universidade ensina teoria, e essas técnicas e conceitos não tem respaldo científico. Hmmm... será que RUP, XP ou qq dessas técnicas têm?

Bom, então já sei, é que o mercado não precisa de programadores. Só de pessoas que saibam analisar a ordem de um algoritmo ou descobrir os casos de uso de um sistema. Ambos muito úteis, infelizmente só atacam um pedaço muito pequeno do que se faz numa empresa.

Não adianta, programador é peão mesmo. Já entendi, segundo grau completo e boa. Se tiver um certificado melhor

(Vixi... Isso ficou com cara de desabafo. Mas deixando a brincadeira do rabugento de lado, não é de hoje que as Universidades da área de TI formam pessoas completamente despreparadas para o mercado de trabalho. Depois reclamam que o mercado é "pouco seletivo" na hora de contratar pessoas na área, quer dizer, frequentemente não exigem ou aceitam qualquer curso superior)

Software enterprise vs open source

Um colega no mestrado soltou uma que me fez pensar na última terça:

"Mas o pessoal usa teste de unidade?"

Bom... quem eu vejo usando teste de unidade? Quase todo projeto open source que se preze. Hoje ficou raro você ver bons projetos open source sem teste de unidade. Pelo menos para Java e Ruby. Só olhar no sourceforge e no rubyforge.

E no ambiente corporativo (leia-se "enterprise software"), é muito raro, praticamente inexistente. A prática tem que ser "provada" para entrar em um ambiente enterprise :p

Conclusão: Você paga caríssimo por um "software enterprise" e ele não tem o mínimo de qualidade que um open source (frequentemente gratuito) pode ter... :|

Ah tem? Me mostrem seus testes então. :) Ahhhh... sei... QA, teste manual, claro, claro, muito confiável, completamente independente de falha humana, executado do começo ao fim sempre que existem alterações. É... como não pensei nisso, bobo eu.

Trabalho em paralelo

Engraçado, não sei o que passa na cabeça do pessoal de TI às vezes.

Quantos de vocês trabalham eme paralelo? Quero dizer, fazem duas ou três coisas "ao mesmo tempo" ou trabalham em mais de um projeto ao mesmo tempo?

Acho que a gente acostuma tanto que o computador consegue lidar com várias coisas ao mesmo tempo que a gente acha que consegue fazer o mesmo. Só que enquanto o processador de um micro fica a maior parte do tempo ocioso, não é nosso caso. Se vc pegar um computador que está trabalhando a 100% de CPU e colocar outra coisa pra rodar junto, ambos os serviços vão demorar o dobro do tempo (ou mais) para serem concluídos. O mesmo ocorre conosco porque, via de regra, não temos tempo "ocioso".

Me lembra um caso que eu gosto de contar: Um antigo chefe meu me chamou na sala dele, me deu um escopo e disse:
"Por alto, quanto tempo você acha que dá pra fazer isso?"...

Perdi uns 15 minutos olhando e falei:
"De um a dois meses".

Ele:
"E esse?"

Gastei mais um tempo olhando e disse:
"É parecido com o primeiro, deve levar mais ou menos o mesmo tempo".

O olho dele brilhou:
"Ótimo! Isso significa que no próximo mês temos tudo pronto, certo?"

Eu:
"???... Não... se cada projeto leva 1 a 2 meses, daqui 2 meses temos um pronto e daqui a 4 meses temos o segundo pronto!"

Ele:
"Mas e se você trabalhar nos dois ao mesmo tempo?"

...

Não sei o que passa na cabeça das pessoas pra conseguir formular uma lógica dessas.