Conhecimento tácito: Uso de protótipos para materializar o conhecimento tácito (Parte 5)

Como trocar experiências de forma eficiente sobre algo abstrato

O conhecimento tácito advém da experiência em situações de trabalho e não pode ser verbalizado ou colocado em regras que permitam a utilização, com sucesso, por inexperientes.

Segundo Silva, Soffner e Pinhão (2004): DE TÁCITO PARA EXPLÍCITO: Externalização é processo de articular conhecimento tácito em conceitos explícitos. Geralmente, essa articulação é efetuada através de metáforas, analogias, conceitos, hipóteses ou modelos. 

Como podemos trocar experiências sobre algo muito abstrato, que está só na mente do criador de um negócio ou de um estudioso do assunto, escrevendo, falando, gesticulando, representado, desenhando etc.

Qual é a melhor forma de representar as funcionalidades de um sistema somadas a necessidade do usuário final? 

O conhecimento explícito pode ser prontamente transmitido para outras pessoas e é facilmente comunicado e compartilhado em dados, informações e modelos como os protótipos que evidenciam o conhecimento de uma forma mais realista, tangível e "testável".  

Todo conhecimento explícito acumulado

é passível de interação e poderá ser testado.

Um exemplo de conhecimento tácito é andar de bicicleta, trata-se de algo que é aprendido apenas a partir da experiência e tentativa.

Um outro exemplo de conhecimento tácito é a montagem de telas de um aplicativo (protótipos), atualmente criado por pessoas com conhecimento acumulado de forma individual e baseado em experiência e técnicas, vivência no mundo virtual, aprendizado acumulado e maturidade profissional. 

São dois tipos de conhecimento tácito: cognitivo e técnico. Nosso foco é o técnico, representado por habilidades informais do chamado know-how de cada indivíduo. As telas de aplicativos são recheadas de conhecimento tácito. Quando materializadas em protótipos se transformam no conhecimento explícito, podendo assim ser compartilhado para realização de testes. 

Obter, extrair ou organizar as necessidades dos demandantes de projetos e transformá-los em sistema ou em aplicativo que seja útil, com uma navegação intuitiva, simples e amigável, sempre foi um desafio e não deve depender do conhecimento individual de apenas um profissional. 

Estas indagações são corriqueiras: Como sistematizar as ideias em “Regras de Negócio” para desenvolvimento técnico de uma solução que realmente resolva a principal dificuldade/necessidade do usuário final? Como apresentar a ideia, antes do desenvolvimento técnico do sistema ou aplicativo para clientes internos ou externos e executivos da empresa, em especial quando as funcionalidades descritas são complexas?

As regras de negócio que devem resolver algum problema ou necessidade do usuário final vão refletir diretamente na criação de funcionalidades, normalmente pacificadas com as análises do negócio, estudos financeiros, definições estratégicas, estatísticas, pesquisas e debates em grupos, dentre outros.

De qualquer forma, quando utilizamos os processos ágeis, como o Scrum (1990) que é uma metodologia ágil para gestão e planejamento de projetos complexos de software, o preparo do dono do produto deve ser antecipado a iniciação da metodologia quando define a proposta de valor que deverá ser atendida.

O Dono do Produto (Product Owner) é o profissional responsável por diagnosticar as necessidades a serem atendidas, reconhecer o público que vai utilizar os serviços, os objetivos a serem alcançados. Em seguida ele deverá definir as funcionalidades (Criar o Product BackLog), priorizando as necessidades e discutindo possibilidades e limites com o usuário final, avalia também, o atendimento das expectativas e garante que o produto seja adequado às principais necessidades dele. 

O Dono do produto/serviço tem que entender as necessidades do usuário final para contemplá-las nos protótipos.