O que é Prova de Conceito?

A Prova de Conceito (Proof of Concept – PoC) se caracteriza como um teste  que tem como objetivo mapear a viabilidade de uma solução (produto, processo, ferramenta) que uma determinada organização pretende implementar.

A PoC é realizada em um ambiente controlado e em baixa escala (com conjunto pequeno de amostras). A ideia é verificar a viabilidade do investimento na produção em escala de uma solução.

A PoC pode ser considerada como uma abordagem estratégica que provê à empresa subsídios para perceber se é comercialmente viável transformar uma ideia em realidade. Este tipo de prova é amplamente utilizado nas áreas de: TI, Engenharia, Medicina, Marketing, Negócios e Inovação.

É importante ressaltar que após passar pela PoC, várias soluções são descartadas ou modificadas, evitando assim o risco de se ter uma ideia, partir para o seu desenvolvimento imediato, produzir em grande escala e o produto gerado não emplacar.

Etapas para realização da PoC

1. Defina os requisitos do Produto
2. Especifique os requisitos.
3. Construa um protótipo.
4. Especifique o que será testado na PoC.
5. Defina um cronograma com a equipe.
6. Mapeie os riscos, recursos financeiros e envolvidos no processo de teste.
7. Colecione os resultados.
8. Faça uma análise se vale a pena investir no projeto.

Enfim, uma ideia pode ter tudo para dar certo, mas enquanto ela não for testada, é apenas uma ideia. Por isso, implementar a PoC é de fundamental importância no desenvolvimento de novos produtos.

por José Augusto Fabri

fabri@utfpr.edu.br

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).

O Papel do PO

O Papel do PO

O Product Owner se caracteriza como um dos principais papéis dentro do processo Scrum. O PO tem a responsabilidade de representar os interesses dos stakeholders e maximizar o  valor do produto. O Product Owner pode ser o responsável por definir e priorizar as funcionalidades do produto, com base nas necessidades e objetivos do cliente e do negócio.

Responsabilidades do PO:

• Definir e manter o Product Backlog;
• Priorizar o Product Backlog de acordo com o valor e a necessidade de cada funcionalidade;
• Descrever as funcionalidades do produto de forma clara e detalhada;
• Trabalhar em colaboração com a equipe de desenvolvimento;
• Participar das reuniões diárias de acompanhamento do progresso do projeto;
• Participar das reuniões de planejamento de Sprint; 
• Participar das reuniões de revisão de Sprint;
• Garantir que o produto esteja sendo desenvolvido de forma eficiente e eficaz.

O papel do Product Owner é fundamental para o sucesso do projeto, pois ele é responsável por garantir que o produto final atenda às necessidades e expectativas dos stakeholders e gere valor para o negócio.

Perceba que PO é caracterizado como um papel, esse papel pode ser assumido por vários colaboradores dentro de um projeto. Isso facilita o balanceamento da carga frente a complexidade de um modelo de negócio. 

O PO não pode ser considerado o ser onisciente dentro da equipe, isto não é bom para ele nem para demais membros do time. O PO tem que exercer a liderança dentro da equipe, essa liderança não pode ser autocrática, liberal, democrática, situacional. O PO deve potencializar as qualidades, conhecimentos, experiências e trabalhar os gaps dos liderados.

Por fim, é importante que o PO tenha uma relação de confiança com toda equipe, incluído da alta gerência. Caso o PO não tenha uma liderança sólida, não possui a confiança de toda a gerência ele não pode ser PO.

Reflita, o PO é um papel, esse papel pode ser constituído por várias pessoas que possuem liderança e conhecimento.

por José Augusto Fabri

Projeto, processo e Adaptabilidade do Framework Scrum

Olá pessoal, recebi a pergunta abaixo de um aluno do curso de pós-graduação em Engenharia de Software, nosso MBA da UTFPR-CP.

Como iniciar um projeto SCRUM? Ou seja, o que seria o “Termo de Abertura do Projeto” em um projeto SCRUM?

Para responder a questão vamos primeiramente definir SCRUM

O Scrum se caracteriza como um framework ágil que possibilita a customização de um processo e que visa a entrega de produtos de forma iterativa e incremental. É baseado em três pilares principais: transparência, inspeção e adaptação.

O Scrum é composto por diversos papéis, incluindo o Product Owner, Scrum Master e a equipe de desenvolvimento, que trabalham juntos para criar um plano detalhado para cada iteração do projeto. Essas iterações são conhecidas como Sprints, que geralmente duram de 2 a 4 semanas.

O Scrum é altamente adaptável e pode ser aplicado a projetos de diferentes tamanhos e complexidades. É amplamente utilizado na indústria de desenvolvimento de software, mas também pode ser aplicado a outras áreas de negócios que envolvem a entrega de produtos ou serviços complexos.

Perceba que o Scrum não é caracterizado como um projeto, Scrum é um Framework adaptável e aplicável a qualquer projeto.

Vamos as questões

Como iniciar o desenvolvimento de um projeto dentro de uma empresa que utiliza Scrum? O que seria o “Termo de Abertura do Projeto” em um projeto SCRUM?

Tendo como base que a empresa possui um processo institucionalizado a partir do Framework Scrum, você pode realizar uma primeira reunião aplicando a técnica de brainstorming e compilar todas as ideias do projeto em mapa mental (aqui temos o mapeamento de escopo). Posteriormente você também pode delimitar usuários chaves e realizar diversos refinamentos sobre as características do projeto. Neste contexto estamos falando sobre os aspectos ligados a levantamento de requisitos, delineados por várias áreas da engenharia, inclusive a de software. Você pode trabalhar com um termo de abertura de projetos como ponto de partida de um projeto, não existe impedimento para isso.

Eu apresentei uma das formas de delimitar as fronteiras de um projeto (com Mapas Mentais ou com o Termo de Abertura do Projeto). Não iremos, em hipótese alguma, abandonar as práticas da engenharia de software ligadas ao levantamento de requisitos.

Scrum é um framework. Diante deste fato destacar um dos pilares do Scrum, a adaptação. Analise as características do projeto e implemente o work no seu frame. Reflita sobre a amplitude destas palavras. 

O Scrum por si só não é a tábua da salvação, ele necessita de customizações.

Por José Augusto Fabri

FrameWork

Pessoal, vários interlocutores deste blog sempre me questionam: Fabri como você enxerga o conceito de FrameWork?

Vou separar a expressão FrameWork em duas palavras.

Frame e Work 

Entendo que a palavra Frame pode ser caracterizada como as paredes de uma casa levantada. Estas paredes aguardam o Work, ou seja a massa corrida, pintura da casa ou o assentamento do piso.

Quando você utiliza um FrameWork, você instancia a casa toda sem ela estar customizada. Cabe a você customizá-la Ao instanciar a casa toda, você pratica aquilo que chamamos reuso. 

Você também pode delinear no seu FrameWork quais partes da casa podem ser customizadas, por exemplo: 

• Algumas paredes já vem com massa corrida e pintura.
• A cozinha já está com piso assentado.

Perceba que neste caso você minimiza o nível de customização e maximiza o conceito de reuso. O delineamento das ações que serão customizadas (cômodos, paredes) depende do nível de padronização que você pretende ter dentro de sua organização.

por José Augusto Fabri

fabri@utfpr.edu.br

Capacity Squad.

Capacity Squad.

O Squad se caracteriza como a equipe que irá trabalhar em um determinado projeto. São os programadores ou desenvolvedores que irão executar as tarefas caracterizadas no Backlog.

No Scrum o Squad se constitui em uma equipe mais enxuta, ou seja, ela possui entre 4 a 8 pessoas, dependendo do tamanho da Backlog. Eu já vi Squad com 10.

Uma vertente importante e já implementada pelo proponente deste blog é trabalhar com várias Squads, implementando o Scrum de Scrums.

Já o Capacity Planning (gestão de capacidade) por ser caracterizado pelo mapeamento e alocação de um conjunto de boas práticas, inerentes aos colaboradores de um determinado time.

Nesse caso: Capacity Squad  = “Os caras” são bons em que. (Na zaga ou no ataque? Onde  escalar o quarteto fantástico?)

Após as definições vamos a questão delineada por um de nossos interlocutores:

No momento de definir o Capacity de uma Squad rodando Scrum, é necessário considerar o Capacity Planning ou apenas o tempo produtivo de desenvolvimento/testes?

Vou responder a questão dentro de minha experiência em lidar com equipe em vários tipos de projetos, inclusive de software.

Geralmente, em um ambiente de produção de software, quanto maior o conhecimento de um colaborador, mais produtivo ele será.

Na engenharia de software dois fatores influenciam diretamente na produtividade:

1 – conhecimento sobre o modelo de negócio na qual a aplicação está sendo desenvolvida. Programadores não podem ser considerados como meros construtores de código (isso é uma outra discussão que podemos alinhavar)

2 – conhecimento sobre a tecnologia implementada na aplicação.

Perceba pela figura que o quadrante preto é o desejável para definir o Capacity Squad.

Porém o desejável nem sempre é aplicável. Correto?

O estado atual do projeto, a capacidade e a maturidade da equipe em relação ao processo, serão de fundamental importância no Capacity Squad.

Outro fato que implica no Capacity Squad é a gestão de conhecimento.Compor equipe com pessoas experientes e com novatos. Fato esse que vai ao encontro da racionalidade e equalização do conhecimento no modelo de negócio e na tecnologia.

O que eu faria então?

Analisaria:

a) o momento na qual a empresa se encontra em relação ao processo e maturidade de seus colaboradores;

b) o estado atual do projeto em relação a expectativas das entregas.

Para mapear o meu Capacity Squad.

A composição depende do momento, não tem uma fórmula, é dinâmica.

Claro que o time tem que possibilitar que eu construa soluções distintas para as diversas situações atravessadas pelo processo.

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

É possível customizar uma métricas de software tradicional?

Uma excelente questão apresentada no título deste post.

Verifique o posicionamento de alguns profissionais da área de engenharia de software.

Apenas 26,3% acreditam que sim.

Para respondê-la, vamos apresentar formalmente duas métricas tradicionais:

1. Pontos por Função
2. Pontos por Caso de Uso

A técnica para mapear a complexidade de um software por Pontos de Caso de Uso foi proposta em 1993 por Gustav Karner. Ela é baseada em duas outras técnicas – Pontos de Função e o Mk II (adaptação da técnica dos pontos por função, comumente utilizada pelos ingleses). A técnica mapeia a complexidade dos atores e dos casos de uso. Aprofunde-se nessa métrica por meio deste link.

Pontos por Função é uma das técnicas (ou métodos) que proporcionam estimar a complexidade de um software. Formalmente, FPA é caracterizado como um método que busca medir a complexidade de um software pela quantificação das funcionalidades. É importante ressaltar que tal método foi criado em 1974 pela IBM e foi, posteriormente, desenvolvido por Caper Jones e pelo International Function Point Users Group. Você encontra mais informações sobre Pontos por Função neste link.

Após a definição de duas métricas tradicionais da área de engenharia de software, vamos a customização customização de uma delas.

Vamos partir da métrica de pontos por função, mais precisamente dos Arquivos Lógicos Aritméticos – os ALIs. Na métrica em questão um arquivo nativo da aplicação é classificado dentro de 3 parâmetros:

• Complexidade Baixa;
• Complexidade Média;
• Complexidade Alta.

Os parâmetros de complexidade são mapeados a partir da quantidade de campos, presente no arquivo, e da forma de organização das tuplas (ou linhas) que os compõem. Quanto maior o número de campos e quanto maior as formas de organização das tuplas, mais complexo é o arquivo. Veja só:

Arquivos que possuem a quantidade de campos entre 1 a 19 e uma forma de organização de registro (ou tupla) possuem uma complexidade baixa.

Arquivos que possuem a quantidade de campos entre 20 a 50 e uma forma de organização de registro (ou tupla) possuem uma complexidade baixa.

Arquivos que possuem mais de 50 campos e uma forma de organização de registro (ou tupla) possuem uma complexidade média.

Para conferir toda a complexidade dos arquivos, das entradas, das saídas e das consultas você pode consultar essa planilha.

Você pode alterar as faixas para mapeamento da complexidade, sempre respeitando os parâmetros de sua base histórica de projetos. Uma proposta:

Arquivos que possuem a quantidade de campos entre 1 a 9 e uma forma de organização de registro (ou tupla) possuem uma complexidade baixa.

Arquivos que possuem a quantidade de campos entre 10 a 20 e uma forma de organização de registro (ou tupla) possuem uma complexidade baixa.

Arquivos que possuem mais de 20 campos e uma forma de organização de registro (ou tupla) possuem uma complexidade média.

Perceba que você está mexendo na linha 8 da planilha.

Para finalizar nossa resposta. É possível customizar uma métricas de software tradicional desde que você tenha parâmetros em sua base histórica de projetos muito bem definidos. Para ter parâmetros bem definidos é necessário possuir um processo de software institucionalizado. 

Mas lembre-se de uma premissa, quando você tiver que participar de uma concorrência ou licitação para vender um software, e essa licitação estabelecer como métrica pontos por função, você deverá utilizar a forma tradicional da métrica.

Fica uma  provocação: Vamos criar uma métrica de software para sua empresa? A sua métrica!

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.

Gestão de projetos. Treinamento e Brinquedos.

Pessoal, hoje vamos falar de um tema importante que venho estudando há alguns anos, o treinamento em gestão de projetos com a utilização de brinquedos.

O termo brinquedo se caracteriza como um vocábulo do século XIX e sua derivação vem de brinco ou brincar. É importante ressaltar que para brincar não necessitamos de um brinquedo ou objeto lúdico – brincar de pega pega é um exemplo. Alguns historiadores relacionam o sufixo edo com a madeira. A madeira foi utilizada na confecção dos primeiros artefatos que foram utilizados na ação de brincar.

Ao utilizar um brinquedo durante o contato com um determinado conceito abstrato, o aluno pode tornar o processo de aprendizado mais atraente e interessante, gerando uma positividade no desenvolvimento cognitivo. Quando combinamos os brinquedos com as aulas, certamente o processo de absorção do conhecimento pode ser potencializado.

Dado o pressuposto que: Brincar pode ser positivo em um treinamento. Um questionamento surge: Como o aluno pode aprender o conceito de Gestão de Projetos a partir da utilização de um brinquedo ou de uma brincadeira?

Vamos tentar responder o questionamento com um exemplo prático.

Vamos trabalhar a Introdução a Gestão de Projetos utilizando um brinquedo. Definir as grandes atividades de gestão – Planejamento, Execução e Controle de Projetos – será o nosso foco. Vamos trabalhar também o conceito de Base Histórica de Projetos e inserir a técnica Kanban dentro de tudo isso.

A brincadeira e o Brinquedo

Solicite que cada aluno ou colaborador tenha em mãos 6 folhas de papel sulfite e uma caneta azul ou preta.

Cada aluno ou colaborador deve gerar uma folha Kanban (vide figura abaixo).

Cada aluno ou colaborador deve recortar uma folha com 3 post-its. Cada post-it deve conter as seguintes informações: Produto a ser gerado, nome, data, tempo planejado e tempo de execução (vide figura abaixo).

Cada aluno ou colaborador vai construir 3 aviões – seguindo as orientações do vídeo abaixo:

Solicite que cada aluno ou colaborador preencha as informações no primeiro post-it.

_______________________________

Produto a ser gerado: Avião 1

Nome: José Augusto Fabri

Data: 21/04/2021

Tempo planejado: 4 minutos.

Tempo realizado: Deixe em branco. Essa informação será preenchida somente quando o post-it atingir o quadro pronto.

_______________________________

Solicite que cada aluno ou colaborador preencha as informações nos próximos post-it.

_______________________________

Produto a ser gerado: Avião 2

Nome: José Augusto Fabri

Data: 21/04/2021

Tempo planejado: Deixar em branco. Essa informação será preenchida com base no tempo realizado do primeiro post-it.

Tempo realizado: Deixe em branco. Essa informação será preenchida somente quando o post-it atingir o quadro pronto.

_______________________________

A Figura abaixo e o vídeo acima apresentam a configuração da brincadeira e a montagem do brinquedo.

Brincando

Agora é só brincar seguindo os passos abaixo:

1. Solicite que cada aluno ou colaborador coloque todos os post-its no quadro para fazer.
2. Assim que o aluno ou colaborador iniciar a construção do primeiro avião ele pode colocar o post-it no quadro fazendo.
3. Peça para cada aluno ou colaborador marcar o tempo que ele leva para construir o avião.
4. Terminada a construção, cada aluno ou colaborador deve movimentar o post-it para o quadro pronto e anotar o tempo realizado.
5. Solicite que cada aluno ou colaborador planeje o tempo de construção para o próximo avião.
6. Volte ao passo 2.
7. Após construir os 3 aviões, solicite que todos gerem a relação apresentada na tabela abaixo.

Produto	Nome	Data	Planejado	Realizado
Avião 1	José Augusto Fabri	21/04/2021	4 minutos	3 minutos
Avião 2	José Augusto Fabri	21/04/2021	3 minutos	2m30 segundos
Avião 3	José Augusto Fabri	21/04/2021	2m30 segundos	2m35 segundos

Trabalhando os conceitos

Agora vamos trabalhar alguns conceitos inerentes a Introdução a Gestão de Projetos.

1. Para construir o primeiro avião você fez o planejamento do tempo de construção. Perceba que você não possuía informação alguma sobre a sua capacidade produtiva.
2. No planejamento para a construção do segundo e o do terceiro avião, você utilizou a informação tempo realizado. Aqui já podemos abordar a importância de uma base histórica de projetos.
3. Com o Kanban você controla constantemente a execução do projeto. Perceba que na figura acima você possui 1/3 do projeto pronto.
4. A tabela acima já se configura como uma base histórica de projetos. Você pode utilizá-la em um próximo projeto para a construção de novos aviões.

Ah… Para encerrar, achou a construção do avião complexa, pode construir um mais simples.

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

Business Impact Analysis (BIA)

Pessoal, hoje vamos falar um pouco sobre Análise de Impacto no Negócio.

É importante ressaltar que toda organização pode ser impactada de forma negativa dada a efusão de um evento externo não programado ou dada a tomada de decisão incorreta na modelagem de um processo de negócio. Analisar este impacto e definir ações que minimizem o estrago é de extrema importância dentro de qualquer ambiente de negócio. É aí que entra o Business Impact Analysis (BIA).

Em resumo, a BIA tem como objetivo avaliar os riscos que um determinado projeto pode oferecer à sua organização. Desenvolver uma boa análise de impacto que um projeto pode trazer ao seu negócio pode evitar a execução de procedimentos que apresentem riscos à sua organização. 

Para realizar a Análise de Impacto em seu Negócio sob a luz da execução de um projeto qualquer execute os passos abaixo:

1. Selecione a unidade de negócio e verifique qual projeto você deseja executar dentro daquela unidade.
2. Faça o mapeamento das atividades do projeto que você quer executar.
3. Analise o impacto de cada atividade mapeada no projeto sob a luz de dois prisma:
   • Ocorrência de um evento externo durante a execução da atividade;
   • Problemas de modelagem ou concepção na sua atividade. Se problemas de modelagem ou concepção foram detectados, retorno ao passo 2.

A BIA deve gerar alguns artefatos importantes:

• Processo mapeado.
• Relato dos impactos mapeados.
• Plano de contingência caso algum evento externo ocorra.

Perceba que a BIA depende de diversas ações importantes dentro da atividade de gerenciamento. Destacamos aqui algumas delas:

• Definição do escopo do projeto.
• Mapeamento das atividades e tarefas do projeto.
• Modelagem do projeto em uma linguagem clara, concisa e consistente.
• Análise das variáveis que compõem o ambiente externo.
• Avaliação do projeto modelado.

Para finalizar, a figura abaixo tenta apresentar de forma simples e elegante os 3 passos da Análise de Impacto no Negócio.

por José Augusto Fabri