Governança de TI: a importância da Gestão do Conhecimento

Documentação tem valor? - Apresentação

Olá, sou o Roberto Sabino, instrutor da Alura, e estou aqui para falarmos de governança de TI e de gestão do conhecimento.

#acessibilidade: Eu sou um homem de pele clara, cabelo e barba escuros, já um pouco grisalhos, e olhos castanhos. Está de camiseta básica preta e à sua frente, está posicionado um microfone preto. Ao fundo, uma parede lisa com um degradê em tons de azul.

Gestão do conhecimento é um tema muito importante e muito esquecido, às vezes. Afinal, o que é a gestão do conhecimento? Como podemos, no dia a dia, fazer a governança dos documentos que criamos, dos conhecimentos sobre os produtos da empresa? O que será que a documentação dos projetos ágeis tem a ver com gestão do conhecimento?

Além disso, será que podemos utilizar a inteligência artificial para nos ajudar a gerir esse conhecimento e até a criar novos conhecimentos dentro da empresa? Que papel os treinamentos, os cursos, têm dentro da gestão de conhecimento de uma empresa?

São temas importantes e, por vezes, não valorizados dentro da governança de TI. É por isso que falaremos deles aqui e perceberemos como é importante utilizar a tecnologia para que esse conhecimento, vivo na cabeça das pessoas, também possa estar presente no dia a dia da empresa.

Esse curso foi desenvolvido para você ter uma aprendizagem ativa. Você poderá aplicar os conhecimentos dentro da sua realidade e compartilhar isso conosco através do Discord e do fórum, para que esse conhecimento seja ainda mais bem absorvido.

Agora, o que temos que fazer é começar a nossa gestão do conhecimento — já na primeira aula!

Documentação tem valor? - Qual o valor da documentação?

Vamos começar a falar sobre a gestão do conhecimento. Esse tema é fundamental para a governança corporativa e para a governança de TI, mas muitas vezes é deixado de lado ou tratado de forma incorreta.

Deixamos para o final para chamar atenção para algo que é tão importante quanto gestão do conhecimento: a documentação.

Lembrando que estamos trabalhando sempre com o exemplo de desenvolvimento de sistemas, porque ele é um dos trabalhos mais intangíveis da TI. Se você sabe fazer uma governança para desenvolvimento de sistemas, você vai conseguir adaptar essa governança para outros trabalhos mais tangíveis e, normalmente, mais fáceis de governar.

A documentação não é a única forma de gestão do conhecimento, mas é uma das ferramentas mais importantes. Ela causa a polêmica: fazer ou não fazer documentação?

Para que serve a documentação?

Tudo o que falarmos aqui serve apenas se estivermos nos referindo a uma documentação útil, correta, na medida certa. Nem pouco, nem muito. Esse equilíbrio é muito difícil de conseguir, mas possível.

O que uma documentação útil e equilibrada faz?

Linguagem comum

Ela serve para criar uma linguagem comum, facilitando a compreensão de todos os envolvidos: pessoas desenvolvedoras, desenvolvedoras mais técnicas, de banco de dados, gestoras de projeto, product owners, scrum masters, clientes, pessoas usuárias e pessoas afetadas pelo sistema, por exemplo, já que o nosso exemplo é desenvolvimento de sistemas.

Resumindo: precisamos facilitar a compreensão de todos estabelecendo uma linguagem comum que todos possam compreender.

Manter históricos e registrar mudanças

Com a documentação, conseguimos manter o histórico dos acordos que foram feitos, das resoluções, do passo a passo, do avanço. Conseguimos registrar as mudanças que ocorreram; por exemplo: "estávamos pensando em fazer uma funcionalidade de determinada forma, mas agora será dessa outra forma".

Rastrear atividades

Além disso, também conseguimos fazer um rastreamento das atividades com a documentação. E aqui não falamos de cronograma, mas de como essas atividades nasceram, por exemplo.

Se nos perguntarmos "de onde veio a ideia de fazer essa funcionalidade?", podemos responder: "há uma necessidade de determinada pessoa usuária, essa funcionalidade, que nós entendemos ser importante".

Ou seja, conseguimos fazer esse rastreamento até chegar no nível de atividade: "por que estamos fazendo essa atividade?", "por conta dessa funcionalidade, pedida pela pessoa usuária tendo em vista tal necessidade".

Benefícios da documentação

Identificar e solucionar problemas

A documentação também contribui para a melhoria da qualidade do software. De novo: não estamos falando de documentação extensiva, mas de documentação útil. Ela, sim, contribui para a melhoria da qualidade do software, porque nos ajuda a identificar e resolver problemas com maior facilidade.

É mais barato identificar um problema na hora de criar uma documentação que explique como fazer determinado software do que após ele estar pronto.

Mas, com a cultura de experimentação, precisamos equilibrar isso muito bem. Precisamos fazer muito menos documentos, mas precisamos fazer de toda forma; um documento rápido, um mapa de histórias de usuário, um fluxograma, algo rápido para tirar os erros mais absurdos e depois já entramos com a experimentação, fazendo o software.

Facilitar a colaboração e comunicação

A documentação permite a colaboração e a comunicação entre equipe e usuários finais. Muitas vezes, os usuários finais têm uma compreensão e um linguajar diferente do pessoal técnico, por exemplo. A documentação permite trazer essa comunicação para um nível um pouco mais intermediário: nem tão técnico, nem tão de negócios.

Não é um linguajar que vai privilegiar só quem está olhando para a parte técnica do sistema ou só quem está olhando para o negócio, porque também é difícil entender o linguajar de negócios, às vezes.

A ideia é conseguir, ao fazer essa atividade de criar documentações, trazer uma linguagem que ajude na colaboração e a comunicação entre os usuários finais e equipe técnica. Pegamos os extremos, mas o mesmo vale para todos os envolvidos no projeto.

Facilitar a manutenção do software

A documentação facilitar a manutenção e evolução do software a longo prazo é algo controverso. Mas, às vezes, a equipe que cria o software não é a mesma equipe que dá manutenção ao software.

Então, temos uma briga: quem está desenvolvendo quer desenvolver e entregar rápido para partir para o próximo projeto. Quem está fazendo manutenção quer muito mais documentação para que seu trabalho fique mais fácil.

Precisamos chegar no meio-termo e somente o dia a dia e a prática é que vão nos dizer qual é esse meio-termo. Mas a documentação, com certeza, ajuda na manutenção de longo prazo.

O nível de documentação que devemos colocar nos projetos e no ciclo de vida dos produtos, para que a manutenção a longo prazo seja privilegiada, não deve colocar uma dificuldade muito grande na hora de elaborar esse produto. E isso, com certeza, vai reduzir custo e tempo de desenvolvimento — se for equilibrado!

Permitir a identificação de dependências e requisitos

A documentação permite identificar dependências e requisitos de sistema, garantindo a integridade da solução. Para entender isso melhor, precisaríamos estudar um pouco mais a engenharia de requisitos.

Mesmo que na agilidade as pessoas não gostem de falar em engenharia de requisitos, é importante trazer o nome real das coisas. Sabemos que o trabalho de entender os requisitos do sistema deriva das necessidades da pessoa usuária. Quando fazemos uma documentação, é mais fácil identificar essas dependências. Então, conseguimos garantir a integridade da solução.

Repetindo, novamente, para fixar:

Não estamos falando de fazer um monte de documentação. Devemos fazer pouca documentação, mas equilibrada e assertiva, que realmente ajude e traga todos esses ganhos potenciais ao final.

O uso da documentação facilita:

Cumprimento de padrões e regulamentos

A documentação nos ajuda a seguir padrões e regulamentos estabelecidos. Por exemplo, normas CVM do mercado financeiro, resoluções do CONTRAN no mercado de trânsito, etc.

Devemos saber seguir essas regras e a documentação nos ajuda com isso porque alguém precisará estudar as leis que esbarram no software que estamos desenvolvendo, trazendo isso para a documentação de forma simples.

Gestão do conhecimento do sistema

Falaremos disso até o final desse curso, então trabalharemos esses conceitos mais a fundo. O software, ou qualquer outro produto de tecnologia que desenvolvermos, possui um conhecimento por trás. Só faz sentido usar tecnologia se realmente tivermos algum conhecimento para trazer, e a documentação ajuda bastante nisso.

Localização e acesso às informações

Não podemos confiar na nossa memória para lembrar de tudo. Devemos ter acesso fácil à documentação que possa servir como uma memória estendida da equipe do projeto ou produto.

Produtividade e eficiência da equipe

A documentação ajuda na produtividade e eficiência da equipe desde que saibamos fazer uma documentação equilibrada. É isso que aprenderemos fazer ao longo desse curso!

Documentação tem valor? - Agilidade acaba com a documentação?

Talvez esse seja o primeiro curso que você está fazendo comigo aqui na Alura. Por isso, preciso fazer uma ressalva bastante importante: você pode ter visto o primeiro vídeo e pensado "Sabino não gosta de agilidade". Isso não é verdade.

Eu não só gosto muito da agilidade, como acredito que a agilidade nos ajuda muito. Mas, nós não podemos cair no que normalmente chamo de "agilismo". Em outras palavras, pensar em agilidade por agilidade e assumir a posição de "não fazer documentação nenhuma porque o Ágil mandou acabar com a documentação". Isso também não é uma verdade, nunca foi.

Hoje em dia, está um pouco mais claro que a ideia da agilidade não é acabar com a documentação, mas fazer uma documentação útil e equilibrada. Por isso, vamos passar por alguns itens que nos ajudarão a entender isso melhor.

Quando devemos documentar?

Nosso exemplo trata de projetos de software, mas você pode extrapolar isso para outras atividades de tecnologia. Independentemente do método utilizado (tradicional ou ágil) precisaremos ter algum nível de documentação, pois basta você pensar que a sua memória não vai durar por muito tempo.

Imagine a seguinte situação: após o término de um projeto, você ficou três meses sem ver nada sobre ele. Em determinado momento, surge um problema e você tem que dar manutenção no software. Você vai se lembrar dos acordos, das regras, dos detalhes, das regras de interface? Não! Nós precisamos disso documentado em algum lugar.

Você pode dizer: "Sabino, o código é a melhor documentação". Se você fizer um código que realmente inclui a ideia de organização e documentação, talvez isso seja verdade. Mas, no dia a dia, dificilmente temos um código que serve como documentação, sejamos honestos. Tendo isso em vista, alguma documentação vai nos ajudar.

Mas, podemos dizer que o código é um documento. Se tivermos um código organizado, com comentários e sessões bem divididas, até poderíamos chamar isso de documentação. Mas, no dia a dia, isso está servindo como documentação? Realmente conseguimos fazer manutenção apenas consultando o código? É uma questão de experimentar. Eu diria que, provavelmente, não.

Por que é importante documentar?

É importante para garantir qualidade do software e sua manutenção a longo prazo. Essas são as duas principais funções da documentação, e falaremos disso muitas vezes.

Mas é importante entender que, no momento de desenvolvimento, a qualidade depende da documentação e, a longo prazo, a manutenção também dependerá. Nós precisamos saber balancear essas coisas para não fazer um monte de documentação, porque isso atrapalha na qualidade e, depois, para fazer a manutenção, você precisa de acesso rápido a isso.

Por que não fazer, por exemplo, um pequeno portal com perguntas mais frequentes, respostas rápidas e um item técnico embaixo? É uma documentação possível! Não precisamos pensar na especificação de requisitos antiga — pode esquecer isso, tirar da cabeça. Nós não precisamos seguir padrões antigos, fixos, muito engessados.

Mas, a verdade é que às vezes é necessário um nível um pouco maior de documentação. Somente o seu ambiente, as pessoas com as quais você está trabalhando e a complexidade do trabalho é que vão dizer como essa documentação precisa ser.

Documentação na metodologia ágil

Nós já sabemos que existem métodos, metodologias, frameworks. Aqui, trataremos de metodologia ágil de forma bastante genérica. Nela, a documentação deve:

Ser enxuta

Faremos o mínimo de documentação necessária.

Prover maior eficiência

Não apenas no trabalho, mas também no uso dessa documentação. Por exemplo: como apresentamos uma funcionalidade nova para o stakeholder? Com um PPT, um PowerPoint, um slide, algo assim? Talvez isso já seja a nossa documentação.

Por que fazer uma documentação e depois uma apresentação? É retrabalho. Será que não conseguimos juntar os dois, criando a documentação num formato possível de apresentar as informações, já com visualização? Talvez seja útil!

Como exemplo, citarei algo interessante que realizei muitas vezes e surpreendia a pessoa usuária: uma documentação-protótipo no Excel, com características de documentação, sem funcionalidade, mas com uma certa navegação e identidade visual. Isso depende, claro, de que tipo de sistema estamos desenvolvendo, mas é uma técnica bem bacana.

Manter a rapidez dos processos

Nós temos um processo ou metodologia de desenvolvimento de sistemas (ou qualquer trabalho). Uma documentação pode nos ajudar a cumprir essas etapas, como, por exemplo, o backlog no Scrum.

O backlog no Scrum nada mais é do que uma forma de especificação, e ele nos ajuda a trazer o Product Backlog para Sprint Backlog e trabalhar dentro da Sprint. Ou seja, é uma documentação útil que ajuda a manter a rapidez dos processos, porque você não vai precisar a todo momento lembrar das demandas, porque o Sprint Backlog está disponível.

Permitir a flexibilidade e adaptação

A documentação deve permitir a flexibilidade nos projetos ágeis. Não podemos inserir um monte de detalhes na documentação porque, se tivermos uma alteração, ela será pesada. Precisamos encontrar uma forma de documentar de maneira leve e flexível para permitir a adaptação à medida que o projeto evolui.

Isto é fundamental, porque senão perdemos a agilidade. Se o coach ágil, agilista, Scrum Master ou seja quem for nos ajudando com a agilidade disser que a documentação está atrapalhando, teremos que concordar. Precisamos de uma documentação flexível, leve e também muito adaptativa.

Exemplos de documentação em projetos ágeis

• Histórias de usuário, o primeiro que vem à cabeça;
• Cartões Kanban podem, de alguma forma, já ser a documentação;
• Testes automatizados também podem carregar algum tipo de documentação, principalmente para quem usa, por exemplo, TDD (Test Driven Development, ou "Desenvolvimento orientado por testes").

Documentação útil é aquela que realmente utilizamos. Se estamos utilizando uma apresentação, um teste automatizado, um quadro Kanban, por que não utilizar essas mesmas coisas como documentação? Podemos abrir a mente e pensar em documentações em outros formatos que não uma especificação corrida feita no Word.

Quebrando paradigmas

Comumente é associado que agilidade significa "ausência de documentação". Podemos dizer que, hoje em dia, nós já sabemos que não é isso, já se bateu muito nessa tecla. Mas, a documentação pode ser utilizada de forma ágil e eficiente.

Desta maneira, pensando em documentação útil, podemos colocá-la em ferramentas que nós já estamos usando no dia a dia, como o Trello, Jira, etc. Podemos criar uma maneira de exportar a documentação para o usuário final em um formato diferente, por exemplo. Não fique criando um monte de documentações em visões diferentes porque isso, sim, gasta tempo.

Documentação Tradicional vs. Documentação Ágil

Esse quadro serve para pensarmos o seguinte: existem algumas características da documentação, como o foco, por exemplo, que podem ser diferentes em uma documentação de projeto tradicional e em uma documentação de um projeto ágil.

Numa metodologia ou formato mais tradicional, mais waterfall, nós temos uma documentação detalhada e extensa. Já nos projetos ágeis, nós temos uma documentação enxuta e suficiente. É mais ou menos isso, mesmo: ela é somente suficiente, nada mais do que isso.

Gostaria também de dizer que as pessoas que estão indo muito bem nos projetos, na verdade, já faziam essa documentação útil lá no waterfall. Já não faziam mais uma documentação extensiva que ninguém leria ler depois. Então, é só uma questão de ajuste.

Qual é o momento de criação de uma documentação? Quando eu estava nos projetos tradicionais, eu tinha uma fase logo no começo voltada para fazer toda a documentação, pensar em todos os detalhes. Isso era muito difícil. Hoje em dia, com agilidade, nós sabemos fazemos isso durante a execução do projeto. E você pode trazer isso para os projetos tradicionais atuais caso trabalhe com eles, num modelo mais cascata. Você pode ir documentando à medida que você está fazendo. Precisamos abrir um pouco a mente!

Já o prazo é definido para criação e atualização nas metodologias mais tradicionais, enquanto é continuamente atualizado nos projetos mais ágeis. A documentação trabalha ciclicamente nos projetos ágeis, agindo como o próprio desenvolvimento: eu vou criar a documentação, vou desenvolver uma funcionalidade, vou receber feedback, vou mudar a documentação, vou mudar essa funcionalidade, vou receber novo feedback, e ciclicamente faço isso até o final do meu desenvolvimento.

Também podemos pensar em flexibilidade. Obviamente, nos projetos tradicionais a documentação é menos flexível e, nos projetos ágeis, ela deve ser muito mais flexível. Lembrando que estamos falando de projetos, mas pode ser ciclo de vida dos produtos também.

Um item importante de ressaltar é o uso dessa documentação. No projeto tradicional, a documentação era usada como uma "receita de bolo" para desenvolver o projeto. Nos projetos ágeis, ela é uma forma de comunicação e colaboração da equipe.

No final das contas, temos que pensar também que nós temos um público-alvo. E esse público-alvo lá nos projetos tradicionais era, principalmente, o nosso cliente, o nosso usuário. Hoje em dia, nós sabemos que a documentação é para todo mundo, para toda a equipe de colaboradores do projeto, como um todo. Isso é muito importante e ajuda bastante a fazer a nossa documentação.

A estrutura, antigamente, era rígida e formal, e agora é mais adaptável e informal. O tipo de documentação, que antes era algo normalmente definido como manual ou especificação. Agora, são as próprias ferrramentas que usamos no dia a dia: stories, os cartões Kanban, os testes automatizados e assim por diante.

Por fim, qual o objetivo da documentação? Nos métodos tradicionais, reduzir riscos e garantir a conformidade. Era algo burocrático, de certa forma — um "contrato". Hoje, essa documentação vai garantir a qualidade do software e principalmente, auxiliar a gestão do conhecimento. Entenderemos isso melhor ao longo desse curso: o que exatamente é essa gestão do conhecimento e como que isso acontece dentro dos nossos projetos e produtos.

Sobre o curso Governança de TI: a importância da Gestão do Conhecimento

O curso Governança de TI: a importância da Gestão do Conhecimento possui 101 minutos de vídeos, em um total de 32 atividades. Gostou? Conheça nossos outros cursos de Administração e Gestão em Inovação & Gestão, ou leia nossos artigos de Inovação & Gestão.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Documentação tem valor?
• Ferramentas vs Conhecimento das pessoas
• Possibilidades para a Documentação Ágil
• Benefícios da Gestão do Conhecimento
• Dicas para Governança