quarta-feira, 11 de agosto de 2010

Reformar a casa e desenvolver software: Tudo igual

Fonte: http://assessoriaemreformas.blog.terra.com.br

Dá gosto ver o resultado de uma boa reforma – ainda mais se teve um bom projeto de um arquiteto ou decorador. Do contrário, é um desgosto sem tamanho ver que, ao final, após tanto dinheiro, tempo e trabalho gastos, aquela reforma dos seus sonhos não ficou exatamente como você imaginava. Pior ainda é descobrir que para ajustar tudo talvez você gaste mais do que para fazê-lo.
Reformar ou construir uma casa é como desenvolver software. Inclusive, essa é a metáfora mais comum que se utiliza para racionalizar o desenvolvimento de um software. Você parte de uma idéia abstrata e depois se esforça para materializá-la. Como todo trabalho de engenharia, o resultado final depende de uma boa definição do escopo, comunicação, colaboração e controle.
Assim, se você nunca passou por uma reforma antes e está pensando em iniciar uma empreitada, ou pensa em desenvolver software :), aqui vão algumas dicas de quem conviveu com uma reforma bem abrangente, cometeu vários erros, quase morreu de desgosto, mas pelo menos aprendeu algumas boas lições para a próxima vez. Em cada dica, eu faço uma analogia com o desenvolvimento de software. Confira!

Tenha uma idéia MUITA clara do que será feito ANTES de iniciar a obra
Esta é provavelmente a dica mais importante: Só inicie a obra quando você souber exatamente o quê e como será feito. Estamos aqui falando de definição do escopo e levantamento de requisitos. Não pense que tudo se resume ao projeto do arquiteto ou decorador. Nem basta saber os tipos de materiais que serão usados. Você precisa saber EXATAMENTE o quê será feito. Qual será a cor do piso? Onde será utilizado? Como serão feitas as emendas e os recortes? Se algo der errado, quais as alternativas? Você verificou se as instalações hidráulica e elétrica propostas no modelo são realmente viáveis? Tem certeza que aquele registro importante ou o painel de disjuntores não vão ficar atrás de algum armário? O armário planejado vai mesmo comportar aquilo que você pretende guardar nele? Considerou o espaço para ventilação que alguns eletroeletrônicos precisam?
Analise bastante o projeto e confronte-o com o local. Cruze as plantas que você já tem com as do projeto. Estude os possíveis cenários de uso. Faça algumas simulações com recortes de papelão. Quanto mais tempo você gastar confirmando o projeto e tomando decisões, menos tempo, dinheiro e trabalho você vai perder contornando restrições durante a obra. Muito faz-desfaz será evitado com uma boa análise e planejamento e comunicação com aqueles que vão executar a obra.
Em desenvolvimento de software é a mesma coisa. O escopo precisa estar muito bem definido antes do início do projeto. E, uma vez iniciado, a coisa mais importante a fazer é definir os requisitos e promover o entendimento claro deles por todos os interessados. Entregar algumas funcionalidades logo cedo, como prega o desenvolvimento ágil, pode contribuir para esclarecer os requisitos no início do desenvolvimento, que é muito mais barato. Se isso não for possível, prototipar pode ser de ajuda. É claro que podem ocorrer mudanças no decorrer da empreitada. Mas quanto mais tempo de análise você gastar com isso no início, menores serão os aborrecimentos depois.

Não inicie a obra sem ter providenciado todos os materiais
Entenda que nem tudo em uma obra pode ser feito de uma vez só. Assim, é prudente providenciar todo o material necessário à obra, para o caso do pedreiro precisar aproveitar o tempo para fazer uma ou outra coisa enquanto espera ‘aquela massa’ ou ‘aquela tinta’ secarem. Providenciar com antecedência todos os materiais vai também possibilitar que você contrate a mão-de-obra por empreitada e o pedreiro, ao ver que todo o material está disponível, vai concordar com isso. Ganha você que provavelmente vai gastar menos dinheiro com mão-de-obra e provavelmente vai receber a obra antes, e ganha o pedreiro que vai poder aproveitar ao máximo o seu tempo e ganhar dinheiro ao assumir outra obra o quanto antes.
Em desenvolvimento de software os ‘materiais’ são informação e os programadores assumem o papel de ‘arquiteto’ e ‘pedreiro’. Escopo e requisitos são as informações que eles precisam para modelar e desenvolver o software. Não caia no erro de alocar essas pessoas sem ter essas informações prontas. No início do projeto, você não precisa alocar toda a equipe de programadores para levantar requisitos. A equipe de requisitos e talvez um programador mais experiente são, em geral, suficientes para uma boa análise de requisitos e definição da iterações. Deixe para alocar programadores depois, quando você tiver pelo menos uma iteração bem definida para ser construída, do contrário eles ficarão ociosos.
Essa dica também é importante por causa da próxima dica.

Não confie nos prazos de entrega dos materiais
A postura mais ingênua que você pode ter é acreditar que os prazos de entrega dos materiais prometidos serão cumpridos pelas lojas. Pode colocar o dobro ou, dependendo do caso, o triplo. Isso se a loja não te ligar para dizer que aquele piso que você contava para amanhã na verdade está em falta no depósito e só será entregue daqui a um mês ou mais. É por isso que é tão importante providenciar todos os materiais antes de iniciar a obra. Do contrário você corre o sério risco de deixar o seu pedreiro ocioso. Ele vai acabar assumindo outra obra para não ficar parado e isso vai dar início a um ciclo vicioso de enrola-enrola da sua parte e da parte dele. E aí, caro leitor, esqueça aquele prazo de um mês para terminar a reforma.
No desenvolvimento de software esse problema geralmente ocorre quando você terceiriza a construção do software. Se você contrata uma empresa para construir seu software, mas não entrega as informações de que ela precisa, essa empresa vai acabar assumindo uma outra construção – afinal ela precisa trabalhar para receber – e isso pode acabar gerando o famigerado ciclo vicioso de enrola-enrola. Percebe-se que os clientes, em geral, são rápidos para definir o escopo, mas muito lentos para ajudar na especificação de requisitos e homologar os entregáveis que muitas vezes ocorrem cedo no projeto. Assim, minha dica é: Não assuma compromissos se o cliente não estiver disposto a assumir compromissos (contratuais) para o fornecimento dos requisitos e prazos para homologação.

Não trabalhe no limite
Essa dica vale para todos os aspectos de uma construção ou reforma. Cuidado com tudo aquilo que parece estar no limite. Contar com o limite dos prazos, limite dos espaços, limite dos materiais, em fim, todos os limites. Pense nisso também quando pensar nos seus armários planejados. Criar aquela divisória que cabe ‘exatamente’ aquele microondas ou o receiver  do seu home theater pode não ser uma boa idéia, afinal, esses eletroeletrônicos precisam de uma área de folga para circulação de ar e passagem dos cabos e tomadas. Quando o assunto é limites, é interessante trabalhar sempre com uma margem de tolerância de pelo menos 10% em todas as dimensões.
Os limites também devem ser evitados no desenvolvimento de software. Se você tem um prazo, por exemplo, não conte com o limite dele para entregar algum produto. Algo pode sair errado e aí você vai ficar mal visto. Planeje sempre com pelo menos 10% de folga. Evitar limites vale também para aspectos relacionados com recursos de processamento. Digamos que você precise desenvolver algum software que vai ficar no limite da capacidade de uma infraestrutura qualquer – rede, armazenamento ou processamento em geral –, muito cuidado! Trabalhar no limite não te dá margem para errar. E errar, caro leitor, é inerente ao ser humano (sem falar que algumas máquinas falham também!).

 ‘O gado só engorda com o olho do dono’
Essa frase é uma máxima que todos deveriam levar para o resto da vida. É como se diz: Se você quer um trabalho bem feito, faça você mesmo. Infelizmente, não podemos fazer tudo aquilo que precisamos. Mas em geral podemos pelo menos ver e acompanhar aquilo que está sendo feito para nós.
No caso de uma reforma, isso é importantíssimo. Como já foi dito no início deste artigo, há muitos detalhes que vão além do projeto. Por isso, é vital que você acompanhe de perto a obra. Caso você trabalhe o dia inteiro, converse com o seu chefe para flexibilizar de alguma forma o seu horário para que você possa passar pelo menos uma ou duas horas por dia acompanhando a execução da reforma. Você não vai se arrepender. Além de evitar muitos erros e supresas, esse controle vai diminuir a probabilidade de erros serem cometidos em cima de outros erros. Em outras palavras, menos retrabalho. Estamos falando aqui de boa comunicação e feedback constante.
Isso é evidente no desenvolvimento de software. O manifesto ágil deixa isso bem claro quando fala da colaboração com o cliente. Inclusive, alguns modelos ágeis sugerem que um representante do cliente ou usuário fique constantemente com a equipe de construção. A idéia é obter informações do cliente em tempo de execução (desculpe o trocadilho), evitar surpresas na hora de apresentar os entregáveis e, com isso, evitar retrabalho.

Entenda que refazer desmotiva
As pessoas em geral levam numa boa concertar seus próprios erros. Já quando o assunto é concertar erros dos outros... Ninguém gosta de refazer algo por culpa de outra pessoa. Em reformas isso é muito comum. Você diz para o pedreiro colocar a pia naquele lugar, depois muda de idéia e pede para ele refazer tudo e mudar a posição. A chance de ele ficar com má vontade e fazer pior é muito grande, pois isso é do ser humano. O que fazer nesses casos?
Mesmo com bom planejamento, é comum ter que fazer um ou outro ajuste. Assim, entender que refazer desmotiva é vital para o sucesso. Ao pedir que alguém refaça um trabalho por uma culpa que não seja dessa pessoa, explique com tato que entende que a culpa é sua (ou de seja lá quem) e que você reconhece que refazer aquilo pode acabar atrasando a entrega total e assim por diante. Talvez seja interessante até combinar um pagamento extra para esses casos – é justo!
Em desenvolvimento de software é a mesma coisa. Programadores em geral gostam de ‘escovar bits’ atrás de seus próprios erros, mas detestam refazer algo por culpa dos outros. Entenda que isso pode desmotivá-los a fazer a coisa com a mesma qualidade do original e reconheça de quem é a culpa. É interessante que esses casos estejam previstos em contrato com a devida compensação financeira.

Espero que essa dica ajude a todos que estão pensando em fazer uma reforma e também àqueles que lideram equipes de desenvolvimento de software.
E você? Tem alguma dica para nós?

2 comentários:

Ramon_dsb disse...

Ótimo artigo!

Anônimo disse...

Obrigado pela grande informação! Eu não teria descoberto este o contrário!