Blog de Mudança

Em função da existência de um projeto com o nome inicialmente escolhido, as publicações não mais serão feitas aqui. O novo local incorpora o novo nome do projeto: smaraNa.

Espero sua visita!

Transferência de Conhecimento?

Lá vai a primeira provocação... rs.

Parece senso comum a definição de que conhecimento é uma construção individual e subjetiva localizada na mente de uma pessoa.

Considerando os mesmos autores que assim definem conhecimento vejo, por outro lado, discursos direcionados a uma "transferência de conhecimento". Não seria isso uma contradição? Afinal, a transferência indica um transporte de algo estático, dotado de uma essência com certo grau de rigidez. Em outras palavras, se eu transmito um conhecimento X, o outro interlocutor teria, ao final do diálogo, um conhecimento X adicionado ao seu estoque.

Mas é isso que acontece? Ou, seguindo o senso comum, o que estamos fazendo é promover estímulos, esperando que o sujeito construa um conhecimento que seja de alguma forma semelhante ao nosso, originário da informação - esta, de fato, transmitida - recombinada com suas próprias vivências?

Isso nos remete a uma outra discussão do que seria a informação... assunto controverso e longo. Por enquanto, quero ouvir opiniões - como disse antes, essa é uma provocação, não uma defesa de conceito.

Profissionalização da Gestão do Conhecimento

Lendo uma série de artigos sobre Gestão do Conhecimento (GC) intra e interprojetos de software eu percebi uma confusão enorme acerca de tópicos fundamentais cuja compreensão é imprescindível para o sucesso no desenvolvimento da GC nessas organizações. Provavelmente por isso que muito se vem falando e pouco (ou quase nada) é, de fato, percebido em termos de valor agregado quando entramos nesse assunto.

Enquanto desenvolvo e amadureço o projeto Akangatu - uma espécie de framework para GC em organizações de desenvolvimento de software - vou tecer alguns comentários sobre conceitos básicos normalmente mal-compreendidos ou usados.

É importante, antes de mais nada, compreender que GC é um assunto muito sério. Ler meia dúzia de artigos ou autores, ainda que renomados, não faz de uma pessoa um especialista em GC. Deve-se compreender que essa área possui uma forte característica transdisciplinar - daí a grande dificuldade. Em meus estudos, por exemplo, incluem-se tópicos originários das áreas de filosofia, educação, administração e comunicação, além, obviamente, de Gestão de Projetos e Conhecimento per se.

Ao enveredar-se por tão diversas áreas, é preciso equalizar conceitos, para formação de um Discurso coeso e que possa embasar decisões acertadas. O que vejo, entretanto, é uma série de contradições e sofismas que, replicados e referenciados por outros autores, promovem a desinformação e a desarticulação de uma área que pode trazer benefícios significativos, se bem estudada e aplicada.

Quero deixar claro que não tenho a pretensão de ser portador da verdade absoluta. Acredito, no entanto, que o raciocínio crítico deve revelar incongruências e promover a formação de teoria e praxis mais verossímeis, aplicáveis e vantajosas para todos.

Mãos-à-obra!!

Os indianos dizem que você não pode mudar a natureza das coisas... um tigre será sempre um tigre, mesmo se criado por cabras. Como Analista de Sistemas, portanto, não poderia deixar de realizar esses anseios e divagações, tornando-os algo tangível, capaz de produzir ganho real à comunidade.

Assim sendo, dentro em breve estarei lançando um projeto em alguma dessas comunidades de Software Livre (ou dessa, para os que, como eu, acreditam estarem todas conectadas). Será um sistema composto de módulos versando sobre cada item do modelo levantado nos últimos posts.

Em breve retornarei com mais notícias e, espero, um link.

Retorno à trilha

Peço desculpas a todos que acompanham este blog. Ultimamente alguns acontecimentos me fizeram desviar dessa busca por uma melhor forma de gerir o conhecimento em organizações de desenvolvimento de software.

Retornando à superfície e podendo respirar, volto com fôlego renovado para não apenas discutir, mas construir uma solução que atenda às necessidades aqui expostas.

Além dos ramos de processo citados no tópico anterior, acredito que seja necessário um "algo mais", muito mais ligado à gestão interprojetos e à própria gestão organizacional. Medir e analisar os resultados alcançados em cada projeto deve compor o arcabouço que proponho - como diz um colega que certamente deve ler este post: "Quem não mede, não gerencia".

Pilar II - Processos

O primeiro pilar trazido à discussão - Pessoas - jamais será um assunto plenamente discutido. Acredito ter exposto questões fundamentais para melhorar o aprendizado da organização.

Vamos pensar agora nos processos importantes para esse crescimento.

Evidentemente, toda experiência provoca a modificação do estoque de conhecimento em nível pessoal. Para uma entidade composta de diversos indivíduos (atuadores), porém, registrar qualquer experiência é inviável, pois exige esforço para registro de eventos irrelevantes ou repetitivos e para a recuperação sobre um estoque demasiadamente extenso de informações. Então, é necessário reconhecer que eventos são realmente relevantes, para registrar e permitir a recuperação de informações que agreguem maior valor.

Além disso, como as pessoas não possuem uma especialização tão restritiva como os órgãos, eles devem ser observados diante do papel que realizam em cada experiência registrada. Em outras palavras, a participação do atuador deve ser categorizada diante do papel que ele exerceu no evento.

Fazendo uma analogia, para usar um martelo, o cérebro deve recuperar a experiência apenas do braço (atuador) - esquerdo ou direito, indiferentemente - para que o outro braço possa realizar o movimento recuperado, atingindo o objetivo desejado.

Sem me delongar muito nesse preâmbulo, identifico alguns pontos dignos de registro na mente organizacional ("hipercortex" definido por Levy em seu livro Tecnologias da Inteligência) em uma entidade de desenvolvimento de software:

1. Lições Aprendidas
2. Riscos de Projeto
3. Análises de Decisão
   
4. Componentes
5. Competências

Os 3 primeiros itens tratam de EVENTOS experimentados durante o desenvolvimento do projeto. Componentes, embora decorrentes da consecução de eventos no projeto, são produtos que podem ser recuperados para reuso.

O último item merece uma observação, por destacar-se dos demais. Para ativar o atuador correto, uma mente precisa saber as capacidades e a identidade de cada um deles. Isso ocorre tanto no corpo - a mente precisa saber o que é um braço e do que ele é capaz - quanto em uma organização. Então, é preciso saber (ou estar disponível) quem sabe fazer o que - por isso as competências devem ser registradas.

Voltaremos a tratar desse assunto - e demais pontos - nos próximos tópicos.

O pavor da língua Portuguesa

Ainda falando sobre o aspecto Pessoas, gostaria de falar um pouco sobre um fenômeno que tenho observado nas pessoas que trabalham com desenvolvimento de sistemas. A maioria não tem paciência ou conhecimento na língua portuguesa - raros são os que prezam pelo desenvolvimento dos textos que servem principalmente para a Gestão do Projeto, Elicitação de Requisitos e Comunicação interna da equipe.

Esse pavor afeta as duas extremidades da comunicação (emissor e receptor). O primeiro, por não querer elaborar um bom texto, capaz de ser compreendido por qualquer leitor, tende a transformar todo texto produzido em tabelas ou itens. Essa "solução" promove edição e leitura rápidas, mas esquece o principal objetivo da comunicação - o entendimento.

Isso nos remete ao pavor que o leitor tem. Ele normalmente não quer aprender. Ele espera que o texto traga uma solução pronta, tal qual um componente buscado na internet. Não podemos esquecer, no entanto, que nem esses componentes são 100% aderentes aos nossos problemas - precisamos compreendê-los para saber como aplicá-los (ou alterá-los), tornando-os ideais para a resolução de nossos problemas.

Esse pavor do leitor "casa" perfeitamente com o do autor, pois a redução de tudo a tabelas ou listas permite rápidas edição e leitura. Ao ler esse texto (se é que podemos chamá-lo assim), o leitor assume que entendeu a realidade. No entanto, ele não possui o contexto em que aquele arremedo de texto surgiu, pois a coesão e a ambientação são elementos desprezados pelo autor. Em outras palavras, o lido não corresponde ao escrito - mas todo mundo acha que está tudo bem.

Ao aplicar o resultado desse processo de comunicação truncado e idiotizado pelo reducionismo radical, o leitor não adquire o discernimento necessário para flexibilizar a [suposta] solução ao seu problema atual - ou pior, para replicar essa flexibilização em problemas futuros, diferentes (em sua essência) do atual.

Resta então o apelo que sempre faço: vamos lembrar das lições do ensino fundamental/médio e escrever textos coesos, com início, meio e fim e que agreguem valor ao leitor, promovendo seu aprendizado e não apenas "empurrando-lhe" uma espécie de fórmula que não poderia (na maioria absoluta dos casos) ser generalizada. Não se trata de falar difícil, usando vocabulário obscuro, mas de escrever algo que traga crescimento ao leitor.