Glossário de Termos em Projetos de Software

Glossário de Termos em Projetos de Software

No passado tudo era arquivo chm

Me lembro de quando tínhamos como sistema operacional “default” o Windows 95 e logo após o Office 97, eu costumava procurar no help do Windows e do Office por significados de termos técnicos, para entender melhor algumas coisas.

O F1 (atalho para a ajuda) eu teclava muito. Mal havia internet, e para aprender mais era ou com colegas, apostilas ou os arquivos .chm (arquivos de ajuda).

/* Para exemplo segue um link para o glossário do Windows XP  https://www.microsoft.com/brasil/windowsxp/experiences/glossary.mspx */

Com o tempo estes recursos foram caindo em desuso, pois a internet nasceu pra valer aqui no Brasil.

Mas em projetos de software eu quase nunca via um “help on-line”, um documento que tratava dos termos de negócio envolvidos no escopo de um projeto.

Então era perguntar para os profissionais “sêniores” envolvidos sobre o que era “Segunda via de Conta”, “Protocolo de entrega”, “Termo de Jurisprudência”, “Tarifa amarela” etc. E muito frequentemente eu ouvia definições diferentes de profissionais de uma mesma equipe, e isso me confundia muito.

O que é e para que serve um glossário de termos num projeto de software

Glossário de termos é uma coisa absurdamente simples de se fazer. Rusticamente falando, é criar um arquivo e nele colocar os termos utilizados no escopo de um projeto e os significados destes termos. Abaixo um exemplo do glossário que citei do antigo Windows XP:

Aerógrafo n. Uma ferramenta artística no Paintbrush ou de outra aplicação gráfica, para aplicação de um padrão de pontos a uma imagem.”

Glossário de Termos em Projetos de Software - eBook sobre Requisitos de Software

Com um glossário de termos em mãos, o “help” pertinente ao escopo do projeto fica a um clique de distância, e para saber o que significa algo, ao invés de tomar o tempo de alguém da equipe, ligar para o cliente para discutir conceitos elementares do escopo, sair pesquisando na internet loucamente ou ficar na dúvida e assumir que é qualquer coisa que falaram etc. basta procurar no documento pelo termo e ver seu significado.

Recentemente trabalhei num projeto de um sistema utilizado por bancos, e um termo gerava dúvida em quase qualquer membro da equipe: “Accrual”. Vejamos o que significa:

“Acréscimo  – A palavra “Accrual” quer dizer em nossa língua “acréscimo”. O “accrual” é na verdade todo aquele valor provindo dos lucros, porém, que não se transforma em liquidez imediata. É como se fosse a relação das disponibilidades produzidas pelos lucros.  Acréscimo proporcional ou a cobrança dos prêmios sobre operações cambiais a prazo (ordens) que estão diretamente relacionados com operações de depósito swap (ver “Arbitragem de Juros“), pelo período de um negócio específico.”

Já vi discussões sobre o que é “Accrual” que se tivessem o tempo somado facilmente teríamos umas 20 horas (equipe de 8 profissionais, discussões envolvendo 4 ou 5 durante 20/30 minutos). Supondo uma hora de R$ 120,00, teoricamente pela ausência de um glossário gerou-se o prejuízo de R$ 2.400,00.

Mas como falei, é algo inacreditavelmente simples de se fazer/manter, mas que é também inacreditavelmente subestimado.

A justificativa de alguns para não tê-lo é como o cafezinho que todo mundo toma após o almoço, no fim do mês dá uma despesa de R$ 100,00, no fim do ano R$ 1.200,00, mas a maioria pensa “é só um cafezinho”, se cortar não fará nenhuma diferença.

O problema da comunicação em projetos

Em análise de sistemas é sabido que a comunicação é um problema gravíssimo, que gera milhões em prejuízos anuais para empresas que fabricam e que compram software.

Uma forma simples de minimizar este prejuízo é com um glossário de termos (ou terminologias) do projeto.

“Mas uma listinha com palavras e seus significados pode gerar grande economia?

Todo mundo sabe o que é o termo “XXX”, para que documentar e ter que ficar atualizando?”

Engana-se quem pensa assim. Como alguns sabem, os maiores problemas em projetos de software estão nas coisas mais simples de serem resolvidas, mas muitos não enxergam o óbvio.

Neste contexto aplica-se por exemplo uma Declaração de Escopo ou um Plano de Comunicações de um projeto, que são ferramentas para minimizar o problema da comunicação deficiente, mas que alguns Gerentes de Projeto escrevem no início do projeto e depois abandonam.

Quando um termo no glossário poderia ter economizado R$ 17.850,00

O glossário de termos é uma ferramenta super útil e simples, que gera em potencial uma grande economia ao projeto.

Porém, nem sempre esta ferramenta é utilizada, e sua ausência em alguns casos causa grandes prejuízos.

A seguir, uma estória breve e interessante sobre um problema causado em função de um conceito dúbio em um projeto, referente a um termo do escopo que não ficou claro e gerou uma funcionalidade que para nada serviu.

O projeto em que o fato ocorreu era de um ERP para supermercados, no projeto não havia glossário. Havia uma funcionalidade de Pagamentos a Fornecedores que envolvia pagamentos referentes a Ordens de Compra de produtos a serem vendidos.

Alguns tipos de pagamento eram mais complexos, tinham várias integrações (com outros sistemas) e não eram tecnicamente viáveis de serem feitos online pelo sistema, sendo estes gravados pelo usuário como Ordem de Pagamento e processados em modo batch (em lote durante janelas de produção da madrugada).

Enquanto a Ordem de Pagamento ainda não havia sido processada havia era gerada uma Ordem de Pagamento, sem valor contábil nem financeiro (não era considerado um Pagamento “de verdade”). Para cancelar um pagamento processado (Ordem de Pagamento realizada) mas errado, foi pensada uma funcionalidade de estorno de pagamento.

Haviam três POs (Product Owner) e em alguns pontos eles não estavam alinhados (em outros desalinhados até demais), muito pela cultura do ambiente.

Um dos POs percebia a necessidade de se ter uma funcionalidade para cancelar uma Ordem de Pagamento que ainda não havia sido processada; um outro também do mesmo grupo achava que o estorno já era o cancelamento da ordem de pagamento, e um terceiro (que também era patrocinador) nem sabia sobre a discussão.

Porém, no momento do levantamento de requisitos concluiu-se sobre ter uma funcionalidade de cancelamento de Ordem de Pagamento, que serviria para “desfazer” pagamentos “ainda não processados” que estavam errados em função de erros do usuário.

Esta funcionalidade media 21 Pontos de Função e cada ponto custava R$ 850,00 (total de R$ 17.850,00e demandava 9 horas para ser produzido. Ao final da fase de testes, quando o profissional que achava que estorno era cancelamento viu a funcionalidade de cancelamento pronta logo começou a questionar a razão de tal funcionalidade, e quando o patrocinador e profissional do projeto viu a mesma funcionalidade, mandou retirá-la do sistema.

Mas neste momento, a funcionalidade já estava construída e testada. 189 horas de trabalho e um valor total de R$ 17.850,00 já haviam sido desperdiçados.

Se neste projeto houvesse um glossário de termos que deixasse claro o que era Estorno de Ordem de Pagamento, este glossário fosse constantemente institucionalizado pelo gerente do projeto na equipe envolvida e todos os envolvidos tivessem “estudado” tal documento, talvez o projeto poderia ter ficado R$ 17.850,00 mais barato e ter sido concluído com menos 189 horas de trabalho.

Concluindo

Nas soluções mais simples encontramos muitas surpresas. E este tipo de contexto tem que ser mudado. E glossário de termos é algo totalmente inerente aos requisitos do software.

Se você quiser tornar-se um Expert em Engenharia de Requisitos e sair na frente no mercado, conheça nosso curso on-line super diferenciado, vamos abrir uma nova turma em breve.

Glossário de Termos - Curso de Engenharia de Requisitos

Abraço!

Glossário de Termos