Tácitos & Explícitos
Há uns 6 anos me 'cansei' do estudo de engenharia de requisitos. Técnicas e métodos mudavam, mas mantinham uma sensação de déjà vu. As mudanças eram cosméticas ou uma questão de nomenclatura. As propostas "ágeis" (aspas não tornam o termo pejorativo) colocaram o Conhecimento Tácito na "coluna esquerda" (leia-se: nomearam-no o mais importante). Essa talvez tenha sido a mudança mais significativa nos últimos 10 anos da disciplina. Mas, basta olhar os métodos e técnicas sem muita paixão para descobrir que tem muito 'revival' ali, pouca coisa original.
Foi quando decidi olhar a estranha disciplina "gestão do conhecimento" com um pouco menos de ceticismo. Pouquíssimos trabalhos fazem a relação desta com a engenharia de requisitos, o que acho estranho. Na época encontrei apenas uma excelente tese sobre "Gestão de Conhecimentos Inter-Projetos" [1], que acabou inspirando meu trabalho sobre "Aprendizado Inter-Projetos". Surrupiei algumas teorias para orientar também minha nova imersão na disciplina engenharia de requisitos.
O trabalho que me 'pegou' foi o clássico "Theory of Organizational Knowledge Creation", de Hirotaka Takeuchi e Ikujiro Nonaka [2]. Foi ali que conheci os 4 modelos de conversão de conhecimentos (figura acima). Prometo ser breve (na explicação das 4 formas):
* Observação: a comunicação também envolve o quadrante 'socialização'.
Está aqui uma daquelas idéias que chamo de bullshitagenzinhas das propostas "ágeis". É inocente ou, melhor dizendo, ingênuo pensar que apenas através da socialização nós aprendemos tudo o que precisamos para executar um projeto. Sei que o princípio, em sua origem, não diz "apenas". Mas, infelizmente, muitos interpretam assim.
Há tempos é raríssimo um projeto de software que não envolva algum tipo de integração com um sistema existente. E não aprenderemos as entranhas daquele sistema com um usuário sentado ao nosso lado. Ou seja, temos que aprender de uma forma diferente, com a chamada internalização. Estudaremos documentos e, na maioria das vezes, código-fonte mesmo. Em iniciativas SOA, onde a sobrevida aos sistemas legados é um grande objetivo, a internalização se faz obrigatória. Um método de análise recomendado é chamado "meet in the middle":
Enquanto uma parte da equipe interage com clientes e usuários, aprendendo o negócio e seus requisitos, outra parte analisa os sistemas existentes. Em um momento "mágico" eles "se encontram no meio do caminho", confrontando requisitos, realidades, verdades, mentiras e restrições.
Cada forma de aprendizado exige um conjunto bastante distinto de habilidades soft e hard. Uma distinção que, infelizmente, o BABoK (ainda) não faz. No próximo post falarei um pouco mais sobre socialização, internalização e as principais técnicas de levantamento e descoberta de requisitos de cada uma delas. Lógico, além das habilidades requeridas para executá-las. Habilidades que devem caracterizar um bom analista de negócios.
Notas:
Foi quando decidi olhar a estranha disciplina "gestão do conhecimento" com um pouco menos de ceticismo. Pouquíssimos trabalhos fazem a relação desta com a engenharia de requisitos, o que acho estranho. Na época encontrei apenas uma excelente tese sobre "Gestão de Conhecimentos Inter-Projetos" [1], que acabou inspirando meu trabalho sobre "Aprendizado Inter-Projetos". Surrupiei algumas teorias para orientar também minha nova imersão na disciplina engenharia de requisitos.
O trabalho que me 'pegou' foi o clássico "Theory of Organizational Knowledge Creation", de Hirotaka Takeuchi e Ikujiro Nonaka [2]. Foi ali que conheci os 4 modelos de conversão de conhecimentos (figura acima). Prometo ser breve (na explicação das 4 formas):
- Socialização: pessoas trocando idéias, de forma direta, conversando. É um canal rico, já que nossa comunicação não se limita a palavras, gestos e desenhos. Um sorriso pode ter n significados.
- Externalização: pessoas transferindo seus conhecimentos para o papel (ou disco rígido, não importa). Estamos registrando idéias e experiências, de forma que elas possam ser úteis para outras pessoas.
- Internalização: quando são (úteis), acontece a internalização. Ou seja, as pessoas aprendem ao ler um documento, diagrama ou rabisco.
- Combinação: por fim temos a combinação, a transformação de um conhecimento explícito (texto, por exemplo), em outra forma de conhecimento explícito (diagrama ou código, por exemplo).
* Observação: a comunicação também envolve o quadrante 'socialização'.
Está aqui uma daquelas idéias que chamo de bullshitagenzinhas das propostas "ágeis". É inocente ou, melhor dizendo, ingênuo pensar que apenas através da socialização nós aprendemos tudo o que precisamos para executar um projeto. Sei que o princípio, em sua origem, não diz "apenas". Mas, infelizmente, muitos interpretam assim.
Há tempos é raríssimo um projeto de software que não envolva algum tipo de integração com um sistema existente. E não aprenderemos as entranhas daquele sistema com um usuário sentado ao nosso lado. Ou seja, temos que aprender de uma forma diferente, com a chamada internalização. Estudaremos documentos e, na maioria das vezes, código-fonte mesmo. Em iniciativas SOA, onde a sobrevida aos sistemas legados é um grande objetivo, a internalização se faz obrigatória. Um método de análise recomendado é chamado "meet in the middle":
Enquanto uma parte da equipe interage com clientes e usuários, aprendendo o negócio e seus requisitos, outra parte analisa os sistemas existentes. Em um momento "mágico" eles "se encontram no meio do caminho", confrontando requisitos, realidades, verdades, mentiras e restrições.
Cada forma de aprendizado exige um conjunto bastante distinto de habilidades soft e hard. Uma distinção que, infelizmente, o BABoK (ainda) não faz. No próximo post falarei um pouco mais sobre socialização, internalização e as principais técnicas de levantamento e descoberta de requisitos de cada uma delas. Lógico, além das habilidades requeridas para executá-las. Habilidades que devem caracterizar um bom analista de negócios.
.:.
Notas:
- Knowledge Management in Inter-Project Learning
Daniel Fitzek. ITEM-HSG Universität St.Gallen (2002). - Theory of Organizational Knowledge Creation
Hirotaka Takeuchi e Ikurijo Nonaka.
Publicado em "Knowledge Management - Classic and Contemporary Works". MIT Press (2000).
.:.
Marcadores: analista_de_negócios, cursos_e_palestras, engenharia_de_requisitos
neste post
Qual é a sua opinião?