Documentar Projetos de TI: Fardo ou Necessidade?
Esse caso acontece sempre de forma semelhante, com algumas peculiaridades de cada empresa ou projeto, mas em linhas gerais, é sempre o mesmo.
O Gerente Noçãoless™ (GN) ou <figura-que-não-entende-como-produzir-software-mas-acha-que-sabe> convoca os desenvolvedores para uma reunião onde um novo projetinho (calafrios nos desenvs) está se formando. Você já ouviu essa história antes, não é mesmo? Um projetinho, pequenino, baratinho, rapidinho de se fazer e manter. Tudo o que precisa ser feito já foi "levantado" em algumas atas de reunião e tudo são flores…
… até que a equipe de desenvolvimento começa a perguntar.
- Ahn, esse item aqui, "Criar um cadastro de clientes físicos e jurídicos.", o que exatamente o cliente quer?
- O GN™ volta com a resposta: são uns 20 campinhos, com pesquisa de CEP dinâmica, 18 campos de preenchimento, sendo dos quais 11 são obrigatórios e tem umas regrinhas de validação que eles querem também e… [mais algumas dúzias de requisitos entram].
Documentar é preciso, todos sabem disso, mas devido ao tamanho de alguns projetos, parece impraticável, um fardo burocrático e sem necessidade. Uma barreira para se chegar ao produto final, o conjunto de códigos que irá funcionar de forma coordenada e atender aos desejos do cliente.
De uma forma ou de outra, pessoas envolvidas com tecnologia entendem a necessidade de criar documentos, evidências, histórico e a indústria exige cada vez mais metodologias para gerar esse material de forma organizada. O maior problema atualmente enfrentado é justamente o custo da documentação.
Uma pessoa, ao encomedar o projeto de uma casa, entende perfeitamente os custos de um engenheiro ou arquiteto, ao projetar as plantas, calcular as quantidades de materiais, mão-de-obra, prestação dos serviços e obviamente, execução da obra. Tudo isso é documentado e o contratante paga por isso porque entende que sem esse plano e sem as plantas, nada irá sair do chão.
Agora o mesmo não é verdade para criar um aplicativo. Para reduzir custos, normalmente são cortados documentação e testes, justamente os dois pilares da qualidade. No final, ficamos, se muito, com um diagrama de base de dados mal feito. As atas de reunião dizem apenas linhas gerais como: quero uma casa de dois andares, com 3 quartos e cozinha ampla. A documentação verdadeira especifica quantos azulejos devem ser comprados para cobrir as paredes da cozinha, por exemplo. Em software, é isso que normalmente é cortado: a especificação, os casos de uso. Confia-se demais apenas em protótipos visuais e o cliente começa a mudar o escopo (scope creep, já falamos disso) porque ele disse na reunião que gostaria de uma interface divina.
Então, por falta de documentação, surgem falhas na comunicação entre as partes. O desenvolvedor pode criar algo formidável, mas que não era o foco do usuário: ele não precisava de um super cadastro, mas de um super relatório. Hoje em dia, testes de software ainda são propostos e projetados como um anexo ao desenvolvimento, como se fosse possível separar um do outro. Vejamos um exemplo simples abaixo:
Projeto XPTO
Planejamento e Documentação: Plano de Projeto, Casos de Uso, Diagramas de Classe, Base de Dados – 2000 horas
Desenvolvimento: Criar códigos, interface, montagem das telas, validações e toda a funcionalidade e correções – 5000 horas
Testes: 3000 horas
É claro que estou simplificando enormemente a divisão de tarefas, mas normalmente cortam-se horas de testes e de documentação para economizar e no final, todos saem perdendo:
- O sistema possui funcionalidades demais, que serão pouco ou nunca usadas;
- Há um alto índice de defeitos e erros;
- Os prazos foram todos estourados;
- O cliente perde a confiança na empresa desenvolvedora;
- A equipe fica desmotivada com o retrabalho e horas extras (muitas vezes não remuneradas);
- O cliente fica sem um produto necessário ao seu crescimento.
Mesmo em metodologias ágeis, alguma documentação é necessária. A forma de se usar o tempo e nível de detalhamento mudam de acordo com cada projeto. Mesmo o Extreme Programming, Scrum e Iconix exigem algum planejamento, mas é bastante comum o desenvolvimento iniciar com rascunhos em papel, linhas gerais do que a pessoa quer e alguns links para websites com funcionalidades que o cliente deseja.
Para se ter uma idéia de como um projeto pode sair do controle se não houver uma boa dose de planejamento e boa comunicação, certa vez, eu estava ministrando o treinamento de uma ferramenta que havíamos desenvolvolvido. O Analista de Negócios/Requisitos acompanhava e anotava as observações dos usuários. O treinamento essencialmente transformou-se em 3 semanas de levantamento de requisitos com literalmente dezenas de pessoas. Um dos usuários abriu o GMail e disse: queria que o sistema funcionasse assim. Outro foi mais longe: bem que podia ter aquelas ferramentas de desenho e edição do Word.
O sistema era para Web e tínhamos 2 semanas para colocar em produção. No final, tudo deu certo e algumas funcionalidades do GMail foram criadas, como o autosave e a parte de edição também foi criada, usando um componente comercial. A empresa levou prejuízo porque não houve um planejamento prévio e a documentação era bastante escassa e quase inexistente. Melhorou quando começamos a congelar os requisitos e aplicamos princípios do Scrum, já que o RUP sairia 40% mais caro… ou não?
O fato é que com a experiência, percebe-se que documentação é chato de se fazer e atualizar. Não há sensação de conquista, mas quando um projeto começa a dar errado, é muito bom olhar para o cliente e dizer: olha aqui, você aprovou exatamente o que fizemos, está escrito. Podemos mudar, mas o novo prazo será xyz. E acredite, a visão que esse cliente terá não é de um chato mercenário, mas de uma pessoa altamente profissional, organizada e que sabe o que está fazendo, mesmo que ele tenha que pagar mais por isso.
Moral do Post
- Defenda o projeto com a palavra escrita.
- Acordos verbais e camaradagem só funcionam quando tudo vai bem. Quando o tempo fechar, aquele que possuir evidências é que sairá vencedor.
- O cliente sempre tem razão, exceto quando o que ele se contradiz com o que foi escrito e aprovado 2 meses antes.
- Cortar documentação é o mesmo que cortar qualidade. Lembre-se que mesmo a metodologia mais ágil ainda exige o mínimo, como um e-mail.
- O fardo de levantar requisitos detalhadamente e fazer protótipos antes de começar a construir telas é recompensado depois, com menos retrabalho e mais prazo para alterações que serão pedidas fora dos acordos iniciais.
Fonte: Bicalho’s Memory About Fuck3d Projects
-
http://www.contraditorium.com Carlos Cardoso
-
garoa
-
Rodrigo8
-
http://br.groups.yahoo.com/group/ChannelTI/ JulianaPrado
-
http://pietra@hotmail.com Anônimo
-
http://melinka.net Rocky
-
TheDarkMaster
-
http://www.eucomotapioca.com abnerneves
-
xultz
-
http://www.eucomotapioca.com abnerneves
-
http://ciberculturabr.com.br/ lfiore01
-
gugaime
-
http://flybywire.librian.net/ Tango
-
http://www.eucomotapioca.com abnerneves
-
http://www.mamendex.com mamendes
-
http://reevolucao.net/ Klbr
-
robsonhermes
-
rod.stuchi
-
ironman_br
-
garoa
