Você já ouviu falar de SCAMPER?

SCAMPER é o acrônimo de Substituir, Combinar, Adaptar, Modificar, Propor, Eliminar e Reorganizar.

A metodologia foi desenvolvida na década de 1970 por Bob Eberle inspirado nas ideias de Alex Osborn, um publicitário e autor que cunhou o termo “brainstorming“

Bob percebeu a importância de estimular a criatividade e a imaginação, principalmente em contextos educacionais. O SCAMPER pode ser caracterizado como um processo prático para ajudar as pessoas a trabalhar com problemas e desafios de forma inovadora. O processo que permite que as empresas criem, aprimorem ou desenvolvam produtos e serviços.

As tarefas do processo SCAMPER

Substituir: Essa é uma tarefa que se constitui em analisar o processo de desenvolvimento do produto ou serviço. Direcionamento para a tarefa Substituir: Durante o desenvolvimento do produto ou na prestação do serviço existe algo que possa a ser substituído com intuito de proporcionar uma melhoria contínua.

Combinar: Na segunda tarefa você deve levantar a possibilidade de ocorrer uma combinação entre artefatos, competências, ferramentas, etc. com o objetivo de buscar novas possibilidades ligadas ao desenvolvimento de produtos ou serviços. Toda a sua equipe é incentivada a pensar em junções fora dos padrões com o intuito de buscar a inovação.

Adaptar: Essa é uma tarefa que direciona você a pensar em outros contextos para seu produto ou serviço. O próprio SCAMPER é um exemplo, ele surgiu dentro do contexto educacional e o mesmo foi adaptado para a área de inovação em diversas empresas de vários setores de mercado.

Modificar: Questão direcionadora desta tarefa: Quais aspectos do seu produto ou serviço pode ser reduzido,  intensificado ou alterado? Exemplos: Cor, aroma, formato e até mesmo o significado dentro do segmento de mercado. As Sandálias Havaianas é um caso clássico de um reposicionamento de mercado.

Propor: A 5° tarefa consiste em questionar se todo o potencial do produto (ou serviço) está sendo explorado. Existe outro público-alvo que pode fazer uso do seu produto ou serviço? Pense fora da caixa. 

Eliminar: O objetivo desta fase é encontrar aspectos que estão majorados no desenvolvimento no processo para desenvolvimento do serviço ou do produto. O que pode ser simplificado?  Se o meu produto (ou serviço) deixasse de existir, faria falta para a empresa?

Se a resposta for positiva, para de fabricá-lo, reorganize seus colaboradores para outros segmentos.

Reorganizar: Na tarefa do SCAMPER, as soluções para os problemas identificados já foram materializadas, neste caso é necessário repensar a cadeia de produção e levantar hipóteses das consequências dessa reordenação.

Por questões ligadas a minha função de professor, vou exemplificar a aplicação do SCAMPER no contexto educacional.

Na área de educação o SCAMPER pode ser utilizado na:

1. Substituição de  métodos tradicionais de avaliação por abordagens mais inovadoras. Exemplo: baseadas em projetos ou portfólios.
2. Combinação de métodos no processo de ensino e aprendizado dentro de uma sala de aula. Exemplo: utilizar sala de aula invertida em alguns momentos e aprendizagem baseada em problemas em outros.
3. Adaptação do currículo para atender às necessidades específicas de um grupo de estudantes. Melhorar materiais para torná-los mais acessíveis.
4. Modificação da aula para incorporar métodos mais ativos e práticos. Exemplo: Ampliação de recursos tecnológicos para o enriquecimento das experiências de aprendizado.
5. Proposição espaços físicos alternativos para promover ambientes de aprendizado dinâmicos. Exemplo: aplicação da disciplina em um contexto real.
6. Eliminação das práticas pedagógicas desatualizadas que não contribuem efetivamente para o aprendizado. Exemplo: a aula não deve ser somente centrada no professor.
7. Reorganização da abordagem de ensino, permitindo que os alunos liderem discussões e projetos. Exemplo: A programação da disciplina pode incluir períodos mais longos de foco em projetos e atividades práticas.

Os exemplos de 1 a 7 podem variar de acordo com as necessidades específicas dos professores e das instituições de ensino.

Por fim surge a pergunta: O Scamper é eficaz?

Certamente alguns gestores ficam inseguros de aplicar o SCAMPER nas organizações, afinal, não é um método tão conhecido assim.

A vantagem da utilização desse processo  é a sua duração. Ele é muito rápido, pois é um processo de geração de ideias, e não aplicação delas. Também é possível destacar que não é necessário a realização de altos investimentos para aplicação do processo. 

No cenário do mercado atual, tomar decisões assertivas e rápidas tornou-se fundamental para a sobrevivência de qualquer organização. O Scamper possibilita essa realidade.

Para saber mais sobre o SCAMPER:

SCAMPER: Creative Games and Activities for Imagination Development. Bob Eberle (1971).

Thinkertoys: A Handbook of Creative-Thinking Techniques. Michael Michalko (1991).

Cracking Creativity: The Secrets of Creative Genius. Michael Michalko (1998).

Vamos conversar um pouco sobre Lifelong Learning

Vamos conversar um pouco sobre Lifelong Learning. Vocês já ouviram falar sobre este termo?

É possível definir Lifelong Learning como uma modalidade de formação voluntária e ocorre na maior parte das vezes dentro de um contexto extracurricular. Um dos objetivos do Lifelong Learning é o desenvolvimento pessoal e na maioria das vezes esse desenvolvimento também é capitalizado pelas empresas. É possível traduzir Lifelong Learning como uma Aprendizagem Contínua dentro de domínio de conhecimento específico, por exemplo  a gestão. 

Alguns autores definem Lifelong Learning da seguinte forma: 

“O Lifelong learning se baseia no princípio fundamental de que sempre há algo novo para se aprender”

Geralmente a Aprendizagem Contínua ocorre fora das instituições de ensino, esta técnica de formação vem crescendo dentro das empresas.

As empresas podem implementar o Lifelong Learning de várias formas com o objetivo de proporcionar o aprendizado constante de seus colaboradores, vamos a uma proposta.

1 – Conceber ou adquirir uma base de conhecimento composta de objetos de aprendizado. Durante o processo de concepção você pode utilizar os conhecimentos de seus colaboradores com o objetivo de efetuar um processo de equalização das habilidades e competências dentro do ambiente empresarial. Uma outra técnica é termos o Lifelong Learning Motor, ou seja, o Motor da Aprendizagem Contínua. Um grupo de colaboradores que “inputam” o conhecimento na base. Em ambas as estratégias é necessária que tenhamos muito bem consolidado no ambiente questões inerentes sobre a materialização do conhecimento (aqui abrimos uma outra frente de discussão).

2 – Provocar, constantemente os seus colaboradores que eles busquem o conhecimento materializado na base e fora dela. A ideia é que os colaboradores percebam um valor agregado na sua perspectiva pessoal quando eles incorporam o objeto de aprendizagem.

3 – Compartilhar o conhecimento internalizado pelos colaboradores na solução de problemas dentro do ambiente empresarial.

• Desenvolvimento de cursos e treinamento;
• Desenvolvimento de webinar;
• Participação em conferências especializadas.

Lembre-se que o compartilhamento de conhecimento poderá realimentar a base.

Por fim, é importante salientar também que a implementação do Lifelong Learning provê uma sensação de pertencimento do colaborador ao ambiente. Garantir a constante qualificação da equipe, expandir oportunidades de negócio, aumentar a Employer Branding (Marca Empregadora) são benefícios gerados pelo Lifelong Learning.

Um abraço a todos e até a próxima.

Por José Augusto Fabri – fabri@utfpr.edu.br

Aplicando métricas e estimativas de software no framework Scrum – parte III

Olá Pessoal. 

Tudo bem com vocês?  

No mês passado, Iniciamos uma discussão sobre as métricas e estimativas de software e os processos ágeis. Acessem os posts 1, 2 e 3 para se inteirar de nossa proposta.

• No post 1 diferenciamos fortemente métricas e ágil.
• No post 2 posicionamos o eixo da gestão junto ao framework scrum, eixo que provê os dados que irão compor as métricas e estimativas em um projeto de software.
• No post 3 especificamos o eixo da gestão utilizando uma estrutura de dados implementável para que os envolvidos no projeto possam responder às seguintes questões:

• Quem?
• Está fazendo o que?
• Para quem?
• Em quanto tempo?
• Com qual valor?
• Com qual grau de qualidade?

Neste post vamos inserir atributos que configuram as métricas de software junto a entidades (vide figura abaixo).

Percebe que os atributos ligados às métricas estão circulados em amarelo. 

• pf: pontos por função.
• pcu: pontos por caso de uso.
• ponto: métrica inserida nos cartões de estórias.
• métrica: qualquer métrica que você queira utilizar, ou seja busque a mais lhe agrade.
• linguagem: linguagem de programação que o software foi desenvolvido.

Perceba que você possui um leque de atributos, você escolhe aquele que mais se adeque ao seu projeto. Por exemplo, se sua empresa trabalha com análise de pontos por função como métricas, então o atributo utilizado será pf.

Os atributos podem ser inseridos na tabela de projetos ou na tabela de produtos ou na tabela de produção.

Se você optar por inserir os atributos na tabela de produção, você terá um dado mais refinado, sabendo a produtividade no âmbito da produção. 

Caso opte por inserir os atributos na tabela de projetos, teremos dados menos refinado, mapeamento a produtividade no âmbito da do projeto, você não terás as métricas em relação a produção de um determinado produto.

As estimativas são caracterizadas com o tempo necessário para implementar 1 ponto por função, 1 ponto por caso de uso ou 1 ponto.

Ao mapear a linguagem de programação como atributo, você poderá levantar a quantidade de linhas de código, o total de pontos por função delineado no projeto e gerar mais uma métrica de suma importância – line of code (loc).

Para finaliza. Verifique o nível de refinamento que você deseja e inseri um atributo ligado a métricas (pf ou pcu ou métricas) e o atributo linguagem na estrutura de dados.

Acredito que fechamos o ciclo de texto sobre métricas e aglidade.

por José Augusto Fabri – fabri@utfpr.edu.br 

Aplicando métricas e estimativas de software no framework Scrum – parte II

Olá Pessoal. 

Tudo bem com vocês?  

Nesta semana continuaremos nossas discussões sobre as métricas e estimativas de software e os processos ágeis. Acessem o post 1 e o post 2 para se inteirar de nossa proposta.

No último post defendemos a ideia que o framework scrum possui um eixo oculto. Isso mesmo, o eixo de gestão. Esse eixo tem como objetivo mapear:

Quem?

Está fazendo o que?

Para quem?

Em quanto tempo?

Com qual valor?

Com qual grau de qualidade?

A pergunta agora passa a ser: O que tem dentro deste eixo? 

No meu ponto de vista esse eixo internaliza uma estrutura de dados que possibilita que você realize o planejamento, a execução e controle de seu processo de produção de software.Na figura abaixo você verifica qual é o formato da referida estrutura de dados.

Perceba que estrutura proposta possui 6 tabelas:

• Projetos;
• Produtos;
• Atividades;
• Produções: Tabela que interliga as atividades do processo aos produtos;
• Colaboradores;
• Colaborações: Tabela que interliga as produções aos colaboradores.

Alimentar de forma automática e dinâmica essa tabela pode facilitar ao máximo a gestão de seu processo.

Por fim, perceba que alguns campos das tabela de produções já realizam uma certa intersecção com o conceito de estimativas e métricas, o campo tempo é um exemplo.

No próximo post iremos inserir as métricas na estrutura de dados e posteriormente, para que possamos realizar estimativas consistentes.

Até a próxima

por José Augusto Fabri – fabri@utfpr.edu.br 

Aplicando métricas e estimativas de software no framework Scrum (1)

Olá Pessoal. 

Tudo bem com vocês?  

Ontem iniciamos uma discussão sobre Agile e Métricas de Software. No post deixei claro que não me sinto confortável em conjuntar o termo Métrica Ágeis. Minha proposta é aplicar as métricas e estimativas dentro do processos/frameworks ágeis. Este texto tem como objetivo iniciar a referida aplicação.

Vamos retomar a figura clássica dos Scrum. 

Ao analisar a referida figura é possível perceber que presença da

• product backlog
• sprint backlog
• sprint
• Reuniões diárias
• …

Nas consultorias, cursos, treinamentos e palestras sempre defendi que existe um eixo oculto junto ao Framework Scrum – O EIXO DA GESTÃO (grafado em vermelho na figura). Este eixo encontra-se paralelo à execução da Sprint, ele tem como objetivo mapear:

Quem?

Está fazendo o que?

Para quem?

Em quanto tempo?

Com qual valor?

Com qual grau de qualidade?

Perceba que as 3 últimas perguntas, grafadas em negrito, estão intimamente ligadas ao conceito de métricas e estimativas. Correto?

É a partir do eixo da gestão que aplicaremos as métricas e estimativas dentro do framework Scrum.

No próximo post caminharemos mais um pouco neste sentido.

por José Augusto Fabri – fabri@utfpr.edu.br 

Métricas Software Ágeis?

Olá Pessoal. 

Tudo bem com vocês?  

Vários alunos e interlocutores do blog Engenharia de Software sempre me questionam:

Professor, você não vai abordar as Métricas Ágeis nos textos e nos cursos ligados a Engenharia de Software?

Para responder a questão, vou apresentar algumas definições importantes?

1 – Métricas

2 – Paradigma Ágil

3 – Scrum 

1 – Métricas

As métricas são caracterizadas como medidas quantificáveis. As métricas são essenciais para toda e qualquer empresa, pois possibilitam o seu crescimento e melhoria.  As métricas estão relacionadas ao tamanho de algo. Podemos citar alguns exemplos:

• Retorno sobre investimento (ROI) – Tamanho do seu retorno após a aplicação de seu investimento;
• Taxa de venda – Tamanho da sua venda.
• Taxa de rejeição – Tamanho da sua rejeição.
• Quantidade de cliques;
• Quantidade de visualizações;
• Quantidade de downloads;
• Life value, o quanto que uma empresa pode ganhar com um cliente;
• Ticket médio, divisão do valor total de vendas pelo número de vendas realizadas;
• Índice de satisfação do cliente;
• Linha de código;
• Pontos por função;
• Pontos por caso de uso.

2 – Paradigma Ágil

A agilidade pode se caracterizar como um paradigma. Etimologicamente, o termo paradigma vem do grego parádeigma e significa modelo, padrão, algo a ser seguido em situações distintas.

A agilidade não pode ser confundida com velocidade. Lembre-se, você pode dirigir um carro em uma rodovia a 200 km/hora e nunca chegar ao seu destino. E se chegar, o tempo que você economizou no percurso, não vale o risco que correu. A velocidade utilizada de forma incorreta pode te levar a construir algo que não tenha valor agregado algum. A velocidade pode ser importante em alguns momentos, mas não é essencial.

A assertividade é essencial. Ter foco, firmeza, capacidade de comunicação direta e elegante são conceitos assertivos. Agilidade e assertividade andam de mãos dadas. A agilidade está ligada à ideia de ser eficaz e efetivo. Agilidade deve despertar o sentimento da confiança e da empatia nas pessoas. A agilidade gera Resultado, com R maiúsculo, para todas as pessoas de uma equipe (o cliente é o principal ator da equipe). Colaboração, feedback, flexibilidade são características ágeis de um bom time.

3 – Scrum 

O Scrum pode ser encarado como um framework com objetivo de organizar um conjunto de tarefas a ser realizadas objetivando a execução de um projeto.

Respondendo a questão: Por que não abordar as Métricas Ágeis nos textos e nos cursos ligados a Engenharia de Software?

Porque métrica é conceito que pode ser aplicado a qualquer projeto independente do processo ou framework utilizado. As métricas podem ser aplicadas aos processos tradicionais assim como aos processos ágeis.  Métricas ágeis é um termo que não me sinto confortável em conjugar. O que existe são as métricas, cabe a nós customizá-las dentro de nosso ambiente de produção, respeitando nossos processos.

Nos próximos posts iniciaremos uma discussão de como trabalhar as métricas dentro dos frameworks ágeis. Perceba o grifo na palavra dentro. Escolha uma métrica, ou um conjunto delas, e trabalhe dentro de seus frameworks.

Até a próxima.

por José Augusto Fabri – fabri@utfpr.edu.br 

Refinement Scrum

Pessoal, nessa semana recebi diversas dúvidas sobre Grooming Scrum. Neste post vou definir a referida técnica, apresentar um processo simples e elegante que proporciona a qualquer profissional da área de processos e executar essa técnica. Importante, eu vou apresentar, eu não vou descrever, institucionalizar o processo.

Antes de iniciar a definição é necessário substituirmos o termo Grooming por Refinement. Grooming na nossa língua portuguesa receba a tradução de aliciamento de crianças na Internet.

Refinement é definido como o ato de preparação de sua Product Backlog (PB). Lembre-se que a PB se caracteriza como tudo aquilo que você necessita executar para construir um determinado produto. Na Engenharia de Software, a PB acondiciona as características ou requisitos de um determinado Software.

Eu, particularmente, relaciono o ato de preparação com o ato de cuidar. Isso mesmo, cuidar. O cuidado com algo ou alguém remete a ideia de zelo e proteção. Neste caso o Refinement se refere ao zelo com as características ou requisitos de seu produto de software.

Diante do contexto apresentado, podemos elencar algumas questões para serem respondidas:

I – Como proteger e zelar a sua PB?

O zelo e a proteção nesse caso refere-se ao entendimento, detalhamento (componentização), descoberta (e não especulação) de novos itens e estimativas de tempo de produção de um determinado requisito de software.

II – Existem boas práticas para proteger e zelar a sua PB? Existem boas práticas para implementar o Refinement?

Não existe uma fórmula pronta para implementar o Refinement durante a construção de um software, podemos elencar aqui algumas ações que executamos dadas as características de projetos que gerenciamos. Vamos a elas:

1. Priorize: Reúna o Scrum Team e o Product Owner. A reunião tem como pauta a priorização dos requisitos. O que deve ser implementado primeiro? O que é mais importante? Qual a relação de dependência dos requisitos? É possível quebrar essa relação de dependência?

2. Componentize: Scrum Team e Product Owner (PO) devem ter a capacidade de dividir as grandes pedras e pedras menores. Certamente será muito mais fácil carregar pedras menores durante a Sprint. O saciamento da sede da equipe de usuários também será melhor gerenciada com as entregas constantes. Você pode utilizar o velho e bom diagrama de componentes proposto, nas décadas de 1970 e 1980, pelo Edward Yourdon. 

3. Descubra: Isso mesmo, descubra novos itens, novas características, novos requisitos de software. Eu escrevi descubra, eu não escrevi especule. Durante o processo de componentização você pode descobrir junto ao PO novos componentes de software. Quando partirmos para uma maior granularidade, vamos percebemos características que não tínhamos percebido antes.

4. Estime: Qual é o tempo e esforço para a construção de um determinado componente? Qual é o tempo e esforço para executar um determinada Sprint? Você consegue responder essas questões com uma base histórica de projetos institucionalizada. Já publiquei vários textos dentro deste tema no blog.

O processo apresentado é simples e não traz nenhuma inovação conceitual para a engenharia de software. Priorizar, Componentizar, Descubrir requisitos e Estimar tempo e esforço já é realizado pelos Engenheiros de Software a décadas. Neste caso, no meu ponto de vista, Refinement é um termo novo na boa e “velha” Engenharia de Software.  

por José Augusto Fabri – fabri@utfpr.edu.br

A Atividade de Refactoring

Embora esta atividade proponha apenas exercitar o refactoring de um código feito por outra pessoa e expor a experência, eu gostaria de expor uma ocasião real que tive quando trabalhei como programador para um projeto especifico.

O projeto era de uma aplicação que pretendia organizar o fluxo de aprovação de novos produtos de uma empresa de cartão de crédito.

Foi escolhido o Lotus Notes/Domino como plataforma, pela facilidade que o software apresentava na criação de sistemas com fluxo, aprovações e integração com sistemas de email.

Eramos 2 programadores, eu (programador1) ficava responsável por criar os módulos, formularios e eventos, enquanto o outro (programador2) era responsavel por acoplar os “objetos” que eu criava no sistema principal. Claro, alteração e refinamento do meu trabalho, era parte da responsabilidade do outro programador.

Então de certa forma, eu entendo que faziamos uma especie de refactoring, já que o meu códio era refatorado imediatamente ao ser implementado no sistema final, portanto listo algumas das caracteristicas do refactoring, que colaboram com a minha afirmação.

Reestruturação do Código: a reestruturação do código era inerente neste caso, pois o programador1 nem sempre tinha visibilidade do sistema como um todo, e o programador2 precisava entender o código para acopla-lo no sistema principal.

Manter o Comportamento: O programador2, precisava manter o comportamento dos modulos feitos pelo programador1, caso contrário o modulo era devolvido ao programador1 para reescrita.

Melhorar a Forma e Estrutura: O programador2 era responsável por adaptar o codigo que recebia ao sistema principal.

Preservar a funcionalidade: durante a integração dos modulos novos, o programador2 precisava garantir a preservação das funcionalidade oferecidas originalmente.

Melhorar a Leitura e manutanção: O programador1, precisava escrever o código de forma que fosse possivel o trabalho do programador2 sem ajuda, enquanto que o segundo precisava fazer o mesmo ao acoplar no sistema principal.

Escalabilidade: Ponto chave na maneira em que trabalhávamos, era importantíssimo que tivessemos esta caracteristica em mente o tempo todo, de outro modo não teria sido possivel aplicar nossa maneira de trabalho.

Concluindo, claro que tivemos momentos de incertezas e problemas no fluxo de nosso trabalho, mas funcionou e nós conseguimos entregar o que foi planejado usando este modelo de trabalho, que no caso foi aplicado por nós por questões logisticas que nos impediam de estar ao mesmo tempo executando este projeto.

por Thomaz Martins – Especialização em engenharia de software.

Lean digital é a melhor forma de conduzir a transformação da TI, dizem especialistas

A adoção de “digital first” é prioridade para a estratégia de negócios de 42% dos executivos líderes de empresas, de acordo com pesquisa recente do Gartner com CEOs. Para a Ci&T, fornecedora brasileira de serviços de TI e soluções digitais, o conceito lean digital é a melhor forma de conduzir essas transformações tecnológicas necessárias para atender às mudanças nas jornadas dos consumidores, que têm impactado negócios em todos os setores — de serviços, agricultura e indústria.

Seja enxuto, leve para transformar culturalmente a forma de produzir de sua empresa.

Texto completo em: https://computerworld.com.br/inovacao/lean-digital-e-melhor-forma-de-conduzir-transformacao-da-ti-dizem-especialistas/

Trabalhando em Rede: Topologia

Pessoal

Atualmente várias instituições trabalham de forma cooperativa desenvolvendo produtos ou serviços de forma distribuída.

Mas afinal o que é trabalhar em rede? Você sabe como construir uma rede de cooperação consistente?

Não!

Então leia o primeiro ensaio que o blog Engenharia de Software vai publicar.

O que é uma rede?

A divisão de um processo de produção entre vários(as):

• atores,
• empresas,
• filiais,
• câmpus
• (neste texto todos caracterizados como Players)

com o objetivo de gerar um produto ou serviço com alto padrão de qualidade caracteriza o conceito de rede.

Uma rede pode ser vista como um modelo de organização do trabalho, que executa um processo (ou parte dele) em dois ou mais Players. Uma rede bem configurada pode trazer um ganho enorme de produtividade e de qualidade.

A configuração de uma rede passa pela definição da sua topologia. Topologia é o termo usado para caracterizar como você estrutura a sua rede de cooperação para o desenvolvimento de um produto ou serviço (o processo). A topologia define a forma de conexão dos Players.

Existem várias topologias que são utilizadas na execução de um processo de forma distribuída. Vamos a elas:

Topologia Anel

A topologia de rede anel consiste em Players conectados por meio de um circuito fechado em série.

Um determinado Player se comunica diretamente com os Players da direita e da esquerda. Fato este que gera uma relação de proximidade entre os atores que atuam nestes Players. A topologia anel fortalece as relações entre os Players vizinhos e distancia Players de lados antagônicos do anel. A comunicação entre os Players de lados antagônicos depende dos Players intermediários.

Topologia estrela

Na topologia estrela, toda a informação passa obrigatoriamente por um Player central. Este Player é caracterizado como inteligente. O Player central deve conectar os demais e distribuir informações, treinamentos, artefatos, processos, etc.

A topologia estrela é excelente para franquias, na qual o franqueador delimita toda a forma e trabalho dos franqueados.

Topologia totalmente conectada

Nesta topologia todos os Players se conectam a todos os Players. A comunicação flui rapidamente entre os nós da rede, porém, o tráfego de informações pode ser intenso e a capacidade de processamento dos nós pode ficar comprometida se os protocolos não estiverem muito bem definidos e institucionalizados.

Topologia Barramento

Na topologia barramento todos os Players estão conectados ao mesmo barramento organizacional.  Esse barramento pode possuir vários dutos de informações, processos, treinamentos, habilidades e competências. Cada Player pode alimentar ou usufruir dos dutos com o objetivo de ter um problema minimizado ou solucionado e proporcionar a solução de um problema para outro Player. Neste tipo topologia o desafio é organizar os dutos do barramento com o objetivo de buscar a eficiência e a eficácia na solução dos problemas.

E aí, já escolheu a sua topologia?

Se sim, você necessita definir um protocolo.

por José Augusto Fabri.