Em seu último artigo publicado, Fabricio Vargas Matos, CEO da Qualidata, onde trabalho, falou da utilização de casos de uso em nossos projetos. E em um trecho ele fala dos ARCs (ARCs???)

“Além das descrições de casos de uso trabalhamos com outros tipos de artefatos que chamamos generalizadamente de ARCs – Artefatos de Representação do Conhecimento (evitamos propositalmente a palavra documentação) que utilizamos para construir e representar esse conhecimento que depois será mapeado em software pelos programadores, que obviamente precisarão tomar muitas decisões de construção, mas partirão de um problema discutido e mapeado previamente, consistente o suficiente para dar fluidez no planejamento da construção.”

Quero fechar o foco na parte entre parênteses “evitamos propositalmente a palavra documentação”.

Cheguei ao ponto: Sim amigos, aqui na Qualidata evitamos a palavra documentação. Eu particularmente corro dela como o diabo evita a cruz.

“Mas por quê?”, você, caro leitor, pode estar pensando. E por que isso é importante/relevante?

Porque esta palavra (documentação) foi corrompida pelo mau uso.

Geralmente, em um projeto de TI, todos os entregáveis (ou pelo menos a maioria deles) que não são código/software são geralmente chamados de documentação.

No passado, imaginava-se que um projeto de software começava com o mapeamento de tudo que o usuário iria necessitar. Tudo então era descrito em documentos, um monte de formulários que teoricamente captariam a essência do projeto. Estes deveriam ser analisados pelo usuário, aprovados e então construídos. Sim, sim, estou falando do Waterfall, velho de guerra, aquele que todo mundo adora jogar pedra. Pode jogar a sua agora.

A partir daí o software seria testado. Se algo não tivesse de acordo, isto é, se algo não funcionasse como deveria (um cálculo de impostos que não batesse, uma busca que não traz os resultados esperados, etc.) a documentação era checada. Se a necessidade não estivesse mapeada, tratava-se de uma falha de análise/desenvolvimento que não percebeu o requisito. Se estivesse lá, isto é, se tivesse sido aprovada pelo usuário o erro então era dele, afinal ele tinha (conferido e) autorizado que a funcionalidade fosse construída daquele jeito.

Estando pronto o projeto, o usuário (agora proprietário do software) poderia levar o mesmo para ser mantido em qualquer lugar, afinal ele possuía “documentação” descrevendo tudo.

Aparentemente todo mundo seria feliz no mundo da TI. O usuário se sentia mais seguro com essa proposta (afinal, vai estar tudo documentado), bem como o desenvolvedor (“O usuário confirmou que é desse jeito. Olha só a assinatura dele no documento”).

O problema é que além de todos os furos que essa metodologia tem (e que são comentados por aí faz anos), a documentação era tratada meramente como uma ordem de serviço. E isso quando o usuário se dignava em analisar e aprovar a mesma. No pior dos casos, burocracia pura e simples. O único momento em que ela era usada era na hora de determinar a culpa, dizer se quem errou foi o desenvolvedor ou o cliente.

Assim, a palavra documentação foi se transformando em sinônimo de inutilidade, como algo que não agregava valor ao projeto.

O agilismo foi a pá de cal. Agora todos eram livres para desenvolver sem escrever nada, sem preencher um formulário, sem elaborar um documento. Um PO (product owner) do seu lado o tempo inteiro para responder tudo o que você precisasse saber. E todos seriam felizes.

Só que não é bem assim que a coisa funciona.

Em tempo, citando mais um trecho do artigo do Fabricio, a realidade da qual estou partindo/da qual faço parte diz respeito a quem “desenvolve sistemas com complexidade de negócio e de cliente que exijam grande esforço para elicitação de requisitos”.

Tendo isso em vista, eu afirmo: representações do conhecimento são necessárias.

Não só para comunicação, mas para sua própria elicitação/compreensão.

Na Qualidata acreditamos que estas representações (daqui pra frente vou chamar de ARCs, ok?) servem não só para transmitir o que descobrimos sobre o domínio do cliente, mas servem também como ferramenta para entendermos MELHOR nosso objeto de estudo.

Quanto mais complexo um domínio, mais regras, mais cenários. E nada melhor do que tentar estabelecer uma narrativa para ver se a história faz sentido, se levamos todos os cenários em conta, se o que esta sendo feito é o que REALMENTE deve ser feito.

Ao elaborar um ARC colocamos em teste a compreensão que temos do negócio sobre o qual atuamos. Se algo não fecha, sinal de que deve ser mais pesquisado, mais investigado. E quando outra pessoa for ler/ver/ouvir seu ARC, mais uma vez esse conhecimento vai ser colocado em xeque, afinal se o conhecimento ali apresentado é coerente ele deve ser entendível por outros que não sejam seus elaboradores. Dessa forma, o conhecimento não só é validado como transmitido.

Notem que quando eu falei ler/ver/ouvir o ARC eu não estava brincando. Na Qualidata acreditamos que um ARC pode ser qualquer coisa. Um diagrama, um desenho, um vídeo, uma gravação. O importante é que toda essa informação esteja organizada de uma forma que ela flua naturalmente, como uma história transmitida através de várias formas de expressão.

Os benefícios: mais reflexão na elaboração, mais validação, mais facilidade de transmissão da informação, mais visibilidade para clientes.

Se a antiga documentação era somente uma forma de determinar quem errou, os ARCs são uma maneira de contar uma história, ou melhor, são mapas em constante melhoria. Um mapa do século XVI era incompleto se compararmos com os mapas do século XX, mas eles viabilizaram inúmeras viagens pelo mundo. E os mapas de hoje em dia (pense no Google Maps, e mais ainda, no Google Street View) são incrivelmente melhores e mais acessíveis do que os mapas do século XX.

Ainda usando a metáfora do mapa, acreditamos que um ARC deve ser uma ferramenta, um meio e não um fim, porque esta sempre sendo melhorado. Enquanto documento tem um ar de coisa morta, uma foto estática de um passado congelado, um ARC esta vivo e em constante evolução. Ou pelo menos deve estar, senão não se trata de um ARC.

Por isso evitamos a palavra documentação.