Até aí beleza, mas um dia ouvi um colega meu falando do 80-20 em outro contexto na área de TI: que quando 80% do projeto está feito os outros 20% são deixados de lado (é como aquela casa que está a 10 anos ainda no emboço, ou o famoso "deixa pra depois").
Assim temos 2 tipos de "80/20", um que visa a melhor utilização do tempo e um outro que explica trabalhos inacabados! Então o que devemos fazer? Resposta: devemos aplicar o lado bom e evitar o lado ruim do 80/20. Agora vamos ver como fazer isso se tratando da área de desenvolvimento de software:
Aplicando o Princípio 80/20 (o lado bom)
Se você tiver várias tarefas, ordene-as em nível de importância e resultados e pegue primeiro as tarefas mais importantes que vão dar mais resultados (acreditem, isso não é redundante)*. Vamos imaginar o cenário em que sua equipe precise desenvolver um sistema J2EE gerenciamento de consultas médicas on-line para um grupo de hospitais (já tendo o modelo especificado e toda a infraestrutura preparada) e fazer uma apresentação dele em 2 meses e seu gerente quer uma versão rodando até a apresentação. Ao menos que os membro de sua equipe trabalhe 20 horas/dia, não vai dar tempo! Aí e que entra o tal do Princípio 80/20: já que só vai dar para fazer uma parte do trabalho, faça a que vai gerar mais resultados! Que resultados? Um sistema testado, rodando e apresentável! Neste cenário o cliente quer que o paciente entre no site, cadastre-se de acordo com o convênio, agende uma consulta, daí o médico pegue a lista de pacientes agendados para o dia de serviço e possa colocar alguma observação e dar a consulta como encerrada. Vejamos algumas dicas:
1º - Não dê idéias mirabolantes do tipo "eu posso fazer uma funcionalidade que o médico poderá colocar as imagens dos exames de terceiros apresentados na consulta dentro do sistema", faça o mais simples para o mais complexo.
2º - Evite fazer um "canivete suiço" (classes Megazord, etc,
3º - Faça os CRUDs que serão realmente utilizados no momento, os CRUDS das tabelas que serão pouco utilizadas podem ficar para a 2ª fase (Ex: Cadastro de Tipo de Pagamento).
4º - Concentre-se no funcionamento da regra de negócio, neste caso é criar o processo de cadastramento, agendamento e realização da consulta, o processo deve estar bem definido e de fácil utilização, nesta fase talvez seja aceitável relatórios com fraca apresentação, porém funcionais.
5º - Não deixe para testar por último: se não quiser usar TDD ou JUnit (que são altamente recomendados), faça mesmo assim testes a cada finalização de tarefa. E depois faça um teste geral só p/ garantir.
6º - No seu planejamento, não distribua as tarefas esperando que a equipe renda sempre 100% e reserve uma porcentagem (20%, por exemplo) do tempo para imprevistos. O Scrum usa algo do tipo porcentagem de produtividade da equipe, que eu não vou abordar aqui.
7º - Aplique o mesmo princípio para cada tarefa, se dedicando ao máximo nos dias e períodos em que é mais produtivo.
8º - Não teste novos métodos e frameworks nos sistemas dos clientes, principalmente numa situação dessas!
Fazendo isso é provável que terminará o que precisa antes do prazo e terá tempo para implementar mais coisas e assim surpreender seu cliente e seu gerente também!
Evitando a Sindrome 80-20 (o lado ruim)
Já aconteceu com você algo do tipo de ver uma aplicação em produção, olhar para um caso de uso que você fez e daí sentir um frio na espinha pensando "Caramba! Esqueci de implementar isso aqui!"? Não é nada agradável. Isso acontece porque quando vemos que uma tarefa está quase concluída
nosso cérebro já conclui que já terminamos, ou que "isso pode ficar para depois". O mesmo acontece em nível sistêmico, que quando um sistema está
1º - Faça sempre uma lista de sub-tarefas de cada grande tarefa e a marque como feita ou não-feita. Ex: Para o cadastro de Médico podemos ter as sub-tarefas: Criar a infraestrutura(entity, persistência, etc), Criar as regras de negócio(validações, assinaturas de métodos), Criar o controlador de ação, Criar o front-end(jsp, javascript), etc. Podendo o teste ficar como uma sub-tarefa e talvez testando cada sub-tarefa quando possível.
2º - Coloque a lista de tarefas e sub-tarefas bem acessível (de preferência ao alcance dos olhos e das mãos)
3º - Não pule para outra tarefa ao menos que tenha terminado a tarefa anterior ou que aja uma necessidade excepcional para isso (ex: seu colega faltou e terá que terminar a parte dele para fazer o deploy no final do dia)
4º - A equipe deve estar ciente do que os membros estão fazendo, isso ajuda a diminuir a competição, e cada um fica mais concentrado na sua tarefa sabendo da importancia dela para o projeto como um todo.
5º - Se não der para fazer tudo até o prazo, procure entregar o que tem se possível, marque um novo prazo para entregar o restante e esforce-se em cumprí-lo.
6º - Se "travar" peça ajuda, pesquise, e só deixe para depois se ver que poderá ser produtivo em outras tarefas. Nota: esse "depois" é no mesmo dia ou no dia seguinte! Não deixe para o acaso, senão você poderá esquecer de fazer ou fazer de qualquer jeito
7º - Não faça de "qualquer jeito" as tarefas só para cumprir com o prazo, retrabalho ou correr no final requer o dobro do esforço do que fazer certo na 1ª vez!
Enfim é isso!
Conclusão
Temos muitas distrações hoje em dia e o nosso tempo é muito corrido devido a vida dinâmica que levamos, aplicando o Princípio 80/20 e evitando a Síndrome do 80-20 conseguiremos produzir melhor e teremos menos estresse ao lidar com a difícil tarefa se tornar o mundo mais fácil para nossos usuários.
Abraços,
Rogick
-------
* Nem todos os casos dá para aplicar esse princípio,
