Carlos Brando

Nome do Jogo

Dê prioridade aos pequenos problemas

Durante o RejectConf’07 o Vinícius mostrava em sua palestra como estava sendo o desenvolvimento do projeto Lucidus, quando foi questionado sobre os testes unitários e funcionais do projeto. A pergunta refletia uma preocupação natural de qualquer desenvolvedor, era algo mais ou menos assim:

Como me assegurar de que todos os programadores irão realmente criar os testes necessários para cobrir 100% do projeto?

Gostei mesmo é da resposta, onde o Vinícius citou a teoria da janela quebrada.

A teoria da janela quebrada

Deixe-me explicar: Durante os anos 80 e 90, Nova Iorque batia altos recordes de criminalidade. A administração da cidade direcionava todas as forças para combater os grandes crimes, como homicídios, e deixava os pequenos delitos de escanteio, para resolver quando tivesse tempo.

Foi quando dois criminologistas, James Wilson e George Kelling, formularam a teoria da janela quebrada, logo depois de uma experiência realizada por um psicólogo. A experiência consistiu em deixar um carro estacionado em um bairro de classe alta da Califórnia durante uma semana. Uma semana depois o carro não apresentava nenhum dano. Novamente o psicólogo deixou o mesmo carro estacionado, mas desta vez com uma das janelas quebrada. Foi necessário apenas algumas horas para que o carro fosse totalmente destruído.

Concluiu-se que o mesmo ocorria com a cidade, se uma janela é quebrada em um prédio é apenas questão de tempo para que todas sejam quebradas também. Em outras palavras, eles tinham de resolver os problemas pequenos primeiro, antes que se tornassem grandes problemas.

Usando desta estratégia a policia local iniciou uma campanha para limpar a cidade, pegando pesado contra pichadores, inclusive limpando as pichações já existentes, consertando janelas, calçadas, faróis, enfim, tudo que deixasse a cidade com aparência de abandonada. O resultado é que Nova Iorque deixou de ser uma das capitais do crime para ser considerada a cidade mais segura do país por seis anos seguidos.

Consertando as janelas do seu software

No exemplo citado pelo Vinícius esta teoria se aplicava muito bem ao desenvolvimento do projeto, no sentido de que enquanto todos os testes estiverem sendo feitos corretamente, ninguém irá quebrá-los, mas no momento em que uma exceção for aberta, por menor que seja, os testes serão deixados de lado.

Me lembro muito bem de um projeto que participei na SKY, o projeto já estava sendo desenvolvido há dois anos, sem nenhum teste, quando foi implantada uma equipe de QA (Quality Assurance) na empresa. A equipe começou então a exigir que todos os novos desenvolvimento tivesses seus testes criados. Algumas semanas depois eles desistiram, porque ninguém criava teste algum, afinal de contas, já existia tanta coisa sem teste, porque criar um apenas para a minha minúscula alteração?

Por outro lado, quando se pega um projeto com todos os testes criados desde o começo, você se sente na obrigação de mantê-lo assim. “Eu é que não vou ser o culpado por quebrar isto”, é o que diria o programador.

Outras aplicações da teoria

A mesma teoria pode ser aplicada quando encontramos um bug em um software, se não o corrigirmos rapidamente e deixarmos para depois, corremos o risco deste problema crescer ou nunca ser corrigido.

Ou quando encontramos um código mal feito, ou uma gambiarra, no meio do código, se não corrigirmos logo, a próxima pessoa que precisar alterá-lo, pode simplesmente dizer: “Ah, já tem um monte de gambiarra mesmo… mais uma nem vai fazer diferença.”.

E o pior caso, é quando se deixa links quebrados ou pequenos erros no software na internet. Seu cliente precisa confiar em você, ele precisa acreditar que não será deixado na mão. Este pequenos problemas, embora simples de resolver, são os maiores vilões para impedir o sucesso de um software.

Resolvendo o problema

Antes de qualquer coisa, a dica é: Conserte as pequenas coisas primeiro. Não deixe que elas cresçam.

Outras duas dicas extraídas do Getting Real que também podem ajudar são:

Encolha Seu Tempo

Quebre

Estimativas que esticam em semanas ou meses são fantasias. A verdade é que simplesmente não sabemos o que vai acontecer daqui tanto tempo à frente.

Então encolha seu tempo. Continue quebrando seu cronograma em pedaços menores. Em vez de um projeto de 12 semanas, pense nele como 12 projetos semanais. Em vez de chutar tarefas que levam 30 ou mais horas, quebre em pedaços mais realistas de 6 a 10 horas. Então proceda, um passo de cada vez.

A mesma teoria se aplica para outros problemas também. Você está enfrentando um problema tão grande que não cabe na sua cabeça? Quebre. Continue dividindo os problemas em pedaços cada vez menores até que você seja capaz de digerí-los.

Um blog não mostra apenas que seu aplicativo está vivo, mas faz sua empresa parecer mais humana. Novamente, não tenha medo de manter o tom da conversa amigável e pessoal. Às vezes, equipes pequenas sentem que precisam soar grandes e ultra-profissionais o tempo todo. É quase como uma versão de negócios do Complexo de Napoleão. Não sue a camisa soando pequeno. Deleite-se com o fato de conseguir conversar com os clientes como amigos.

Mantenha os Posts Chegando

Mostre que seu produto está vivo mantendo um blog operacional do desenvolvimento do produto após o lançamento

Não pare de blogar depois de lançar. Mostre que seu produto é uma criatura viva mantendo um blog dedicado e atualizado freqüentemente (pelo menos uma vez por semana, e com mais freqüência se puder).

Coisas a incluir:

  • Faq (Perguntas e Respostas Freqüentes)
  • How-tos (Instruções passo-a-passo)
  • Dicas & Truques
  • Novas Funcionalidades, atualizações e correções
  • Burburinho/Imprensa

Fontes:

Comments