Photo by Sara Kurfeß on Unsplash

O primeiro mandamento

Douglas Bianchezzi
5 min readMar 14, 2021

poucos dias recebi um pedido para escrever uma instrução sobre algo recorrente dentro de qualquer organização que trabalha com conhecimento: Manuais. E mais especificamente, a efetiva construção e absorção de conhecimento que deles costuma-se derivar(ou espera-se).

Quando me sentei para desenrolar esse pedido, um turbilhão me acometeu e me senti no dever de compartilhar estes pensamentos.

Então lá vai…

Tentarei lançar luz a esta situação recorrente e simples de ser resolvida, a respeito de manuais institucionais e documentações no mundo de software de forma mais ampla. Pois estamos tratando basicamente das documentações de processos e atividades das organizações, além de seus sistemas internos.

E aí eu já te digo de antemão: Não tem nada de simples nisso. Não tem nada de básico nessa atividade.

Porém, observem que na pequena instrução acima, já fica claro o propósito e utilidade dos manuais: padronização de procedimentos e processos internos. Estes aspectos são o assunto chave. Pois percebam o quão complexo é o processo de documentar atividades institucionais para efetivamente garantirmos a perpetuação de conhecimento dentro de qualquer segmento de negócio.

Acho importante voltarmos algumas casas nesse nosso tabuleiro da história, e aplicarmos um olhar crítico no modus operandi das empresas que tem seu maior ativo nos dados e informações: — A maior problemática sempre serão as interações derivadas das pessoas. Pois apesar de nos esforçarmos para sempre mantermos colaboradores engajados e com potencial de desenvolvimento para a companhia, as pessoas vêm e vão, e os negócios permanecem.

E por conta principalmente de uma eventual rotatividade de pessoas, ou ainda um ambiente em constante transformação, onde processos dormem de uma forma, e acordam de outra, temos de considerar o desenvolvimento de manuais que sirvam de referência para as novas gerações de indivíduos responsáveis pelas atividades.

Tendo isto em vista, e já conseguindo observar a big-Picture em nosso cenário, notem o gatilho para a discussão:

Quem acompanha meus textos, sabe que sou um evangelista do método ágil de desenvolvimento de software. E apesar de entender que tudo o que foi construído a partir de 2001, com a publicação do Manifesto, já comece a ficar datado, e apresente novos GAPs considerando os novos cenários de mercado, o primeiro “mandamento” ainda cai como uma luva em toda e qualquer empresa que presta principalmente serviços em software:

“Indivíduos e Interações, mais do que processos e ferramentas”

Aí você vai me dizer: “Pô Douglas, mas aí tu vais matar os manuais então? Especialmente se você ler o segundo mandamento, aí sim vai tocar fogo em todas as documentações conhecidas da organização”.

Não. Não vou. Eu vou fazer justamente o contrário. Vou enaltecê-las.

A documentação no processo de construção de sistemas é essencial. E este é um ponto que até hoje gera discussão de Agilistas, sobre o entendimento pleno de o que é documentação em software. Documentação relevante, na minha concepção, é aquela que consegue justificar uma implementação.

Simples.

E agora, partindo desta definição, podemos voltar aos manuais… pois percebam a significativa contribuição que conseguimos absorver sobre documentações, ao considerarmos esse ponto sobre software, em nossos processos e ferramentaria internas.

Nos idos de 2001 o cenário de utilização de ferramentas internas era significativamente diferente do que vivemos hoje, 20 anos depois.

Tão diferente, que algumas pessoas chegam a acreditar que por utilizarem o JIRA para gerir os projetos estão sendo ágeis.

JIRA = agilidade em 300%

Vamos nos ater a concepção que expus sobre justificar implementações.

Em processos internos isso é ainda mais notório, pois desconheço empresa de software que não controle suas demandas atendendo requisitos de services.

De forma direta, o argumento principal é: documentar como utilizar as ferramentas que sustentam sua operação, não é criar manuais de conhecimento.

Lembrem-se de justificar mesmo que de forma sucinta o que motivou a criação daquele processo, e como ele está desenhado no momento.

Num ambiente efervescente como o do mercado de software, por mais que os processos estejam em constante mudança, sempre chegaremos num ponto onde faz-se necessário o entendimento das demandas, de seus fluxos e naturalmente crie-se sua documentação para utilização interna e externa.

Não entendam de forma equivocada quando digo que documentar a ferramentaria não é gerar inteligência sobre os processos. Toda empresa precisa ter métodos para repassar conhecimento sobre os recursos internos para colaboradores novos, parceiros e inclusive trabalhar com melhoria contínua…, mas o que não se pode permitir é que o entendimento pleno do PORQUÊ determinado método funciona de X forma, permaneça exclusivamente no subconsciente de algumas pessoas.

Criam-se métodos inclusive para prever a recursividade e revisão destas atividades internamente. Afinal, “rodar um PDCA” das documentações internas, faz-se basicamente necessário.

O pequeno framework que tenho a recomendar neste momento é extremamente fácil de ser complementado em qualquer documentação:

· Quem fez;

· Quando fez;

· Parecer de negócio (justificativa sob o viés de entregas e importancia para a empresa na visão dos clientes, usuários… que corrobora para o método adotado);

· Parecer interno (justificativa e forma como isso deve ser entendido pelos colaboradores. E de que forma será divulgado);

· Definir datas para retorno e reanálise do método considerando a tendência de mudanças estruturais e internas.

Naturalmente o parecer de negócios e interno são às grandes estrelas destes itens.

Acho que pra fechar, quero deixar explícito ainda os pontos mais importantes na minha concepção:

· Não exija de colaboradores posicionamentos e justificativas quando você não consegue garantir que eles foram devidamente treinados para suas funções (aqui entram uma série de táticas e técnicas sobre desenvolvimento complementar a respeito das atribuições);

· Por mais que as ferramentas internas possam ser phod@s, elas podem mudar da noite para o dia. Documente procedimentos que são relevantes para o seu negócio. Quando a ferramenta interna adotada for um ponto relevante para o seu negócio… bom, reveja a estabilidade do seu negócio;

· Procure dar um jeito de extrair a sabedoria e conhecimentos que estão na cabeça somente de algumas pessoas(principalmente se houver relevância direta para o negócio), não deixe de compartilhar com todo mundo o porquê daquela adoção;

Transparência pode ser um coringa no bolso para ajudar nisso.

Por hoje é só. Me sigam para mais ver mais polêmicas, e releituras sobre o manifesto.

Um abraço, usem máscara, fiquem em casa se possível, e até mais.

--

--

Douglas Bianchezzi

College Teacher at @FaculdadeMaterDei. @EXIN Instructor Brazil; Executive at @DB1