Peco desculpas a todos que acompanham este blog. Ultimamente alguns acontecimentos me fizeram desviar dessa busca por uma melhor forma de gerir o conhecimento em organizacoes de desenvolvimento de software.Retornando a superficie e podendo respirar, volto com folego renovado para nao apenas discutir, mas construir uma solucao que atenda as necessidades aqui expostas.Alem dos ramos de processo citados no topico anterior, acredito que seja necessario um "algo mais", muito mais ligado a gestao interprojetos e a propria gestao organizacional. Medir e analisar os resultados alcancados em cada projeto deve compor o arcabouco que proponho - como diz um colega que certamente deve ler este post: "Quem nao mede, nao gerencia". Basta o "chao de fabrica" ter interesse em compartilhar conhecimento? Claro que nao! A ideia disposta sobre a vontade de os associados "da linha de frente" trocar informacoes, serem ouvidos e tomar decisoes pode lembrar o discurso de Jan Carlzon. No entanto, ha uma pequena diferenca entre seu discurso e a minha percepcao.A experencia do dia-a-dia permite ao colaborador do "chao de fabrica" ter uma percepcao diferente e intuicoes acertadas sobre como as coisas deveriam ser feitas para uma maior geracao de valor. Quando o objeto do trabalho e software integrado a processos organizacionais, o cenario muda a cada oportunidade de construcao de novo sistema. Surge, nesse momento, uma grande quantidade de variaveis que precisam ser estudadas.Essas variaveis provavelmente ja foram estudadas em contextos diferentes, por outras pessoas, dentro da organizacao. Ha grande dificuldade em se descobrir o que, como, por quem e porque foi tomado determinado rumo no desenvolvimento de um software de caracteristicas semelhantes ao problema atual.Para que isso seja disponibilizado nao basta a vontade de quem ja viveu a experiencia, mas um direcionamento comum, compartilhado por todos, independente da hierarquia - um "achatamento da piramide". E preciso haver disciplina no processo de ensino-aprendizagem, para que nao seja passado apenas um produto-solucao, mas sim um contexto no qual uma solucao surgiu, de forma que aquele que busca uma solucao possa se guiar (e desviar, conforme julgue necessario, a partir das particularidades de seu contexto).Thomas Edison, ao ser indagado sobre as tentativas sem sucesso de construir uma lampada, disse:We now know a thousand ways not to build a light bulbHoje, temos diversos tipos de lampada cuja forma de funcionamento pode variar. No entanto, sabemos que todos os estudos posteriores ao de Edison que resultaram nessa vairedade de lampadas certamente nao percorreram os 1000 caminhos de insucesso que ele ja percorrera.Quero ratificar com isso, a necessidade de compartilhamento nao de solucoes, mas de historias de aprendizado, de licoes contextualizadas onde se verifique os erros cometidos no processo de aprendizagem - divulgar o que, como, por quem e porque uma coisa foi feita, desde o seu surgimento (identificacao do problema) ate a sua solucao. Para que isso seja feito, e preciso vontade, disciplina, processos e [preferencialmente] sistemas computacionais. Os indianos dizem que voce nao pode mudar a natureza das coisas... um tigre sera sempre um tigre, mesmo se criado por cabras. Como Analista de Sistemas, portanto, nao poderia deixar de realizar esses anseios