Orientação das Equipes de Trabalho
Versão do documento: 1.2, 01/05/2018
Estrutura organizacional
Missão, Visão e Valores da Organização
A missão, visão e valores da organização estão definidas no site da Basis e consolidada no parágrafo abaixo:
“Ser um grupo empresarial próspero no segmento de TI proporcionando sucesso
aos clientes, colaboradores e acionistas, mediante uma visão inovadora,
verdadeira e possível.”
Estrutura das áreas de desenvolvimento
Gerência e Operações da Fábrica de Software
Responsabilidades do Gerente de Projeto
-
Definir o escopo do projeto;
-
Estimar o tamanho do projeto, esforço, custo e tempo, com o apoio do Analista de Métricas;
-
Planejar cronograma, treinamentos, riscos, métricas, gerência de configuração, plano de comunicação e recursos de hardware e software;
-
Apoiar a revisão e obter o comprometimento ao plano do projeto por parte dos envolvidos;
-
Acompanhar o andamento dos projetos com base no planejamento aprovado;
-
Registrar os problemas encontrados nos acompanhamentos do projeto;
-
Ajustar o plano do projeto para tratar os problemas encontrados;
-
Apoiar a revisão e obter novo comprometimento ao plano do projeto por parte dos envolvidos, sempre que houver mudança no plano do projeto;
-
Apoiar a revisão e obter novo comprometimento aos requisitos por parte dos envolvidos, sempre que houver mudança;
-
Planejar e Monitorar todo o treinamento necessário para a equipe dos projetos, seja de processo ou técnico. Informar ao RH;
-
Informar os mentorings realizados ao RH;
-
Gerenciar as permissões de acesso e restrições ao repositório do sistema de gerência de configuração e baselines;
-
Reportar à Diretoria o andamento do projeto, dependências críticas internas e externas;
-
Distribuir as baselines aos interessados;
-
Comunicar ao cliente o progresso do projeto.
-
Planejar testes no contexto dos projetos de desenvolvimento;
Responsabilidades do Analista de Requisitos
-
Levantar os requisitos do produto;
-
Apoiar a avaliação e aceitação dos requisitos do produto;
-
Analisar o impacto de mudanças nos requisitos;
-
Realizar revisões técnicas formais nos produtos do projeto de desenvolvimento;
-
Elaborar abordagens de integração do produto;
-
Reporta-se ao Gerente do Projeto.
Responsabilidades do Programador
-
Identificar os itens de software que implementam cada requisito;
-
Estabelecer um relacionamento de dependência entre os requisitos e os itens de software;
-
Analisar o impacto de mudanças nos requisitos;
-
Realizar revisões técnicas formais nos produtos do projeto de desenvolvimento;
-
Elaborar abordagens de integração do produto;
-
Construir o produto;
-
Reporta-se ao Gerente da Fábrica de Desenvolvimento.
Responsabilidades do Arquiteto
-
Estabelecer a arquitetura do software;
-
Projetar o software;
-
Analisar o impacto de mudanças nos requisitos;
-
Conduzir análises decisórias para questões técnicas dos projetos de desenvolvimento, tanto para solução técnica dos produtos quanto para * análises DAS/MBR;
-
Elaborar abordagens de integração do produto;
-
Construir o produto;
-
É responsável pela análise e modelagem dos dados, sendo alocado de forma parcial nos projetos;
-
Reporta-se ao Gerente de Arquitetura.
-
Definir e implementar uma estratégia de testes automatizados de software na organização;
Responsabilidades do Testador (Pool de Testes)
-
Realizar testes de unidade, integração, aceitação e de sistema nos produtos desenvolvidos;
-
Registrar erros encontrados durante os testes.
-
Reporta-se ao Gerente do Pool de Testes.
Responsabilidades do Analista de Métricas
-
Estimar o tamanho do produto;
-
Realizar revisões por pares de requisitos;
-
Durante o projeto, reporta-se à Diretoria de Contratos.
Responsabilidades do Gerente de Fábrica
-
Disponibilizar recursos humanos e infraestrutura para FSW;
-
Solicitar a complementação de capacitação da equipe quando necessário;
-
Ser o canal de comunicação entre a FSW e as Fábricas de desenvolvimento;
-
Reportar ao Diretor o andamento dos projetos e dependências críticas internas e externas;
-
Monitorar as áreas de apoio de Medição e Análise, e Gerência de Configuração, garantindo que as atividades e pendências sejam concluídas.
Equipes de suporte
Responsabilidade da Equipe Medição e Análise
-
Identificar os objetivos de medição a partir dos objetivos e necessidades da organização,
-
Planejar as medidas dos processos a partir dos objetivos de medição;
-
Apoiar a coleta das medidas dos processos;
-
Analisar as medidas coletadas e gerar um relatório dessa análise;
-
Reportar o relatório de análise das medidas coletadas para os interessados;
-
Planejar e executar ações corretivas para tratar problemas identificados na análise das medidas coletadas;
-
Participa das reuniões de análise crítica apresentando os indicadores de processos da FSW.
-
Reporta diretamente a Diretoria ou o Gestor da FSW nas atividades organizacionais e nas coletas de projeto.
Responsabilidade da Equipe SGO
-
Manter o Sistema de Gestão de Ocorrências;
-
Gerenciar as permissões de acesso e restrições ao SGO;
Responsabilidade da Equipe de Gerência de Configuração
-
Elaborar uma estratégia de gerência de configuração tanto no nível organizacional, quanto no nível de projeto;
-
Gerenciar as permissões de acesso e restrições ao repositório do sistema de gerência de configuração e baselines;
-
Avaliar a integridade e consistência das baselines.
-
Reporta diretamente ao Gerente de qualidade;
-
Controlam as mudanças nos itens de configuração;
-
Distribuem as baselines aos interessados.
Área de Processos
Responsabilidade do Líder do EPG
-
Ser o ponto focal no relacionamento com as consultorias e com os profissionais da área escopo;
-
Identificar junto ao Diretor os principais objetivos de negócios e metas do projeto e acompanhá-los;
-
Acompanhar as ações planejadas e atuais nos cronogramas dos projetos em andamento, bem como o envolvimento dos principais integrantes dos * projetos e o cumprimento de suas responsabilidades;
-
Dar visibilidade e informar constantemente ao Diretor sobre andamento de todas as atividades da área da Qualidade, principais riscos e desvios * em curso;
-
Conduzir as análises críticas dos processos
Responsabilidade do EPG
-
Apoiar e acompanhar a utilização dos ativos de processo e melhorias nos projetos;
-
Identificar melhorias nos ativos de processo;
-
Apoiar a elaboração dos ativos de processos (descrições dos processos, roteiros, guias, políticas, diretrizes organizacionais e templates);
-
Apoiar a execução de treinamentos e mentoring para a equipe dos projetos;
-
Apoiar a execução de melhorias que ainda não foram publicadas e estão sendo pilotadas nos projetos.
-
Reportar ao Líder do EPG sobre o andamento das tarefas, dificuldades e outras informações relevantes ao andamento do projeto.
Responsabilidade da Diretoria
-
Definir os rumos da área da Qualidade;
-
Definir expectativas da Basis em relação à área da Qualidade;
-
Definir os objetivos de negócios que envolvem a área da Qualidade;
-
Revisar periodicamente as atividades da área da Qualidade, visando adequá-las às expectativas do Patrocinador;
-
Acompanhar e aprovar as principais ações adotadas pelo EPG da Basis;
-
Tomar as ações corretivas cabíveis oriundas dos desvios encontrados em relação ao que foi planejado para a área da Qualidade;
Regras para Estabelecimento de equipes funcionais
Identificar, documentar e designar as funções, responsabilidades e relacionamentos de reporte dentro do projeto no Plano do Projeto, incluindo a interface formal com o cliente, quando for diferente da definida no item 2 deste documento. As funções, responsabilidades e relacionamentos de reporte podem ser atribuídos a indivíduos ou a grupos do projeto. Os indivíduos ou grupos podem ser parte da organização do projeto ou externos a ela.
Deve registrar, também, a matriz de responsabilidades da equipe de projeto, incluindo os profissionais de parceiros e do cliente, quando diferentes do definido no item 2 deste plano.
Orientações para Teambuilding
Nos projetos incluindo todas as fases a equipe mínima será composta de:
-
Gerente de Projetos
-
Analista de Requisito
-
Codificador
-
Testador
-
Grupo de Métricas
-
Grupo de Configuração
-
Grupo de Arquitetura
No caso dos grupos, os profissionais serão alocados de acordo com a disponibilidade no decorrer dos projetos.
As fases de Projeto poderão ser contratadas separadamente, podendo inclusive, todo projeto ser a execução de uma determinada fase, conforme declarado na OS. Não havendo assim definição de equipe mínima, além do Gerente de Projeto para a execução. Demais profissionais serão alocados de acordo com a necessidade para as fases contratadas.
As equipes serão montadas em função das disciplinas, tamanho e prazo de entrega, considerando a produtividade definida, podendo ainda um mesmo recurso exercer mais de um papel no projeto.
Procedimento de Resolução de Conflitos
Sempre que existirem conflitos entre recursos compartilhados de Apoio, serão repassados para o Diretor de Contratos e poderão ser discutidos durante a reunião mensal de gerentes.
O mesmo procedimento deve ser adotado quando existirem problemas de comprometimento e cumprimento de prazos e escopo internos.
Externamente, o Gestor da Fábrica deve em primeiro lugar acionar o Gestor do Cliente na Basis, que tentará resolver o conflito. A Diretoria de Contratos deve ser acionada sempre que não for possível a resolução nesta instância.
Regras para comunicação entre equipes
A comunicação no projeto será executada primordialmente em formato eletrônico, utilizando-se o Sistema de Gerenciamento de Ocorrências (SGO).
Reuniões devem ser realizadas ao longo do projeto para garantir que os grupos saibam das suas responsabilidades e que as mesmas estão sendo exercidas:
-
Reunião de Abertura do Projeto com a Equipe e as Áreas de Apoio e Qualidade (kick-off);
-
Apresentação dos papéis e responsabilidades no projeto deve ser realizada nas atas de Reunião de Kick-off e confirmadas nas reuniões de progresso ou técnicas com o time;
-
Repasse de informações entre fases do projeto ao final dos marcos.
Orientações para comunicação entre equipes
| Objetivo | Mecanismos Sugeridos | Orientações |
|---|---|---|
Entendimento técnico |
|
|
Obtenção de informações com cliente |
|
|
Acompanhamento de progresso |
|
|
Alinhamento entre equipes |
|
|
Aceite/Aprovações de produtos |
|
|
Regras para condução de reuniões
As seguintes regras devem ser observadas durante as reuniões:
-
Duração máxima: 30 minutos. Caso todos os assuntos previstos não podem ser tratados nesse tempo, deve ser feito uma pausa antes de continuar a reunião.
-
Sempre estabelecer e enviar uma pauta pré-definida antes da reunião. Existem pautas definidas no próprio processo em momentos específicos do ciclo de vida que devem ser utilizadas.
-
Facilitador: Gerente do Projeto ou quem estiver conduzindo a reunião.
-
Documentador (ata): Gerente do Projeto ou designado no início da reunião.
-
Registro da reunião: Deve conter o que foi discutido, participantes e data. Os responsáveis pelos planos de ação, quando aplicável, devem ser identificados e o prazo de resolução acordado e registrado no SGO.
Histórico de Revisões
Data |
Versão |
Autor |
Revisor |
Observação |
29/01/2015 |
1.0 |
Marcelle Mirsky |
Miguel Negrelli |
Versão inicial |
24/04/2018 |
1.1 |
Cédric Lamalle |
Miguel Negrelli |
Ajustar os itens 2.3, 2.4, 2.5, 3, 4, 5, 6.1 e 6.4 de acordo com a nova estrutura organizacional |
01/05/2018 |
1.2 |
Cédric Lamalle |
Miguel Negrelli |
Ajustar layout do item 'Estrutura das áreas de Desenvolvimento' (2.3, 2.4, 2.5) para facilitar a leitura |
Guia de Gerenciamento de Riscos
Versão do documento: 2.2, 24/04/2018
Introdução
Identificar riscos que têm sempre como premissa “verificar tudo aquilo que pode dar errado” na execução de uma atividade. Riscos são fatores que podem vir a constituir barreiras para a condução de um projeto, para a execução de alguma atividade ou mesmo imposições da organização sobre os projetos e atividades.
Classificação dos riscos
Os riscos identificados na Base de Riscos no SGO estão separados em duas categorias principais de acordo com o histórico de projetos da BASIS: Custo e Cronograma. Riscos categorizados como “custo” são todos aqueles que podem incorrer em desvios de custos para o projeto e consequentemente à margem de contribuição do mesmo para a empresa. Já riscos categorizados como “cronograma” são fatores que poderão ocasionar desvios de prazo no projeto, o que consequentemente afetará o faturamento dos projetos e balanço mensal da organização.
Parâmetros e priorização dos riscos
Além das categorias nos riscos devem ser acrescentados outros parâmetros: Probabilidade e Impacto.
A probabilidade define a possibilidade de um risco ocorrer. A probabilidade pode ter três valores possíveis: baixa, média e alta.
O impacto de um risco permite medir o tamanho do estrago que ele pode provocar dentro de um projeto. Aqui temos três possibilidades: Impacto no Custo, Impacto no Prazo e Impacto na Qualidade. Se impactar em um deles, o Impacto é 1. Se impactar em dois deles, o Impacto é 2. Se impactar nos três, o Impacto é 3.
A partir da probabilidade e do impacto deve ser calculada a prioridade do risco (probabilidade somada com impacto). O resultado desse cálculo pode ser visto na tabela abaixo:
| Probabilidade | ||||
|---|---|---|---|---|
Baixa (1) |
Média (2) |
Alta (3) |
||
Impacto |
Alto (3) |
Médio (4) |
Alto (5) |
Alto (6) |
Médio (2) |
Baixo (3) |
Médio (4) |
Alto (5) |
|
Baixo (1) |
Baixo (2) |
Baixo (3) |
Médio (4) |
|
-
Prioridade Baixa: 2 ou 3
-
Prioridade Média: 4
-
Prioridade Alta: 5 ou 6
Por exemplo, um risco de impacto alto com probabilidade média tem uma prioridade classificada como alta.
Com a prioridade calculada, os riscos podem ser priorizados. Riscos com prioridade 5 ou 6 devem ser monitorados e ações para mitigação e contingência devem ser tomadas.
Estratégias de gestão de riscos
A prioridade calculada vai nos permitir determinar quais ações devem ser tomadas para cada risco.
As ações a serem tomadas para cada valor da prioridade:
-
Alta:
Devem ser tratados, seja por mitigação ou resolução. Devem ser criadas ações de mitigação, e os riscos e ações devem ser supervisionados na periodicidade da monitoração do projeto (deve ser monitorado no mesmo momento).
-
Médio:
Deve ser analisada e decidida pelo gerente de projeto a estratégia mais adequada, entre mitigação e contingência. Caso seja decidido pela mitigação, uma ação deve ser criada para monitoração das mitigações;
-
Baixo:
Deve aceitar os riscos com esse valor de prioridade. Esses riscos não serão monitorados já que estão aceitos pela gerência.
Controle e tratamento de Riscos
Planejamento da gestão de risco
Inicialmente, deve-se instanciar os riscos inerentes ao projeto a partir da Base de Riscos registrados no SGO. As colunas Impacto e Probabilidade devem ser preenchidas para todos os Riscos listados. Riscos com prioridade Alta e Média devem ser mantidos em aberto, até que sejam tratados e não mais viáveis de ocorrência. Estes riscos deverão ser monitorados continuamente com as ações realizadas para sua mitigação e/ou contingência. Riscos de prioridade baixa podem ser fechados no momento de sua criação e não necessitarão de monitoração contínua.
Resolução de risco
Para resolver ou mitigar um risco, é possível:
-
Reduzir a probabilidade de acontecer o risco;
-
Diminuir o impacto do mesmo.
Dessa maneira, a prioridade pode ser reduzida. A Base de Riscos deve ser atualizada caso a probabilidade ou impacto mudem.
Monitoração de risco
A monitoração de riscos consiste em uma programação constante da atualização dos mesmos. A probabilidade e o impacto de um risco podem mudar no decorrer do tempo. Por exemplo, a probabilidade de um aumento de escopo pode reduzir à medida que o sistema está sendo desenvolvido.
A monitoração deve ser feita usando a Base de Risco criada a partir de ocorrências no SGO. A monitoração dos riscos será formalizada no relatório de monitoração elaborado periodicamente pelos gestores, juntamente com as ocorrências de mitigação ou contingência criadas. Caso necessário, a base de riscos poderá ser atualiza e a probabilidade e/ou impacto dos riscos poderão ser modificados se a ação de mitigação e/ou contingência tiver resultados positivos.
Gatilho para Mitigação dos Riscos
Gatilho para riscos é uma estratégia utilizada para orientar e melhorar o gerenciamento dos riscos dos projetos. Ele consiste na criação de um gatilho (trigger) para cada risco. Esse gatilho representa o possível momento em que a estratégia de mitigação deve ser acionada. Por exemplo: se o risco levantado é o servidor alcançar 100% de armazenamento, um gatilho interessante seria que, aos 80% do armazenamento, fosse lançanda a estratégia de mitigação (diminuir as chances do risco acontecer). Quando o gerente de projeto monitorar os riscos de seu projeto, ele deve atentar para se algum risco alcançou algum gatilho, e caso positivo, iniciar a estratégia de mitigação descrita para o risco.
Histórico de Revisões
| Data | Versão | Autor | Revisor | Observação |
|---|---|---|---|---|
08/05/2013 |
1.0 |
Cédric Lamalle |
Miguel Negrelli |
Versão inicial |
06/10/2014 |
2.0 |
Marcelle Mirsky |
Miguel Negrelli |
Revisão da política por conta de uma mudança na forma de gerenciamento dos riscos. |
22/05/2015 |
2.1 |
Marcelle Mirsky |
Miguel Negrelli |
Alterações de pequeno porte para ajustar ao processo executado |
24/04/2018 |
2.2 |
Cedric Lamalle |
Miguel Negrelli |
Alterações de pequeno porte para ajustar a forma de criação e monitoração dos riscos pelo SGO |
Base de Riscos
Versão do documento: 3.0, 08/05/2018
Identificação dos Riscos
| Fator de Risco | ID | Risco | Descrição |
|---|---|---|---|
Inviabilidade dos prazos de entrega |
1.1 |
Projeto Complexo |
O projeto é complexo demais e pode ser que não seja entregue dentro do prazo solicitado pelo cliente. |
1.2 |
Muitas Mudanças |
Muitas mudanças partindo do cliente durante o curso do projeto. |
|
1.3 |
Prazo curto |
Data de entrega, acordada para o projeto, é muito curta. |
|
1.4 |
Conhecimento tecnológico |
Os recursos não têm experiência e/ou conhecimento na tecnologia e/ou ferramenta para poder entregar a tempo. |
|
Possibilidades de cancelamento de projeto |
2.1 |
Pagamentos Pendentes |
Questões financeiras devido a pagamentos pendentes por parte do cliente. |
2.2 |
Insatisfação do Cliente |
Cliente insatisfeito com o produto. |
|
Desconhecimento do negócio pelos usuários e equipe de projeto. |
3.1 |
Qualidade dos Requisitos |
Especificação de Requisitos passada pelo cliente ruim, não implementável e com falta de qualidade. |
Variação de cronograma no projeto. |
4.1 |
Indisponibilidade de Recursos |
Indisponibilidade de Recursos Humanos. |
| Todos os riscos têm por categoria: Cronograma. |
Análise
| ID | Risco | Causas | Consequências | Impacto | ||
|---|---|---|---|---|---|---|
Custo |
Prazo |
Qualidade |
||||
1.1 |
Projeto Complexo |
Restrição legal e/ou necessidade do cliente de uma data de entrega limite. |
Atraso na Entrega |
|||
1.2 |
Muitas Mudanças |
Mudanças surgindo que aumentam a complexidade e/ou tamanho do projeto. |
||||
1.3 |
Prazo curto |
Restrição legal e/ou necessidade do cliente de uma data de entrega limite. |
||||
1.4 |
Conhecimento tecnológico |
Aceite de demandas sem experiência técnica por razões políticas. |
||||
2.1 |
Pagamentos Pendentes |
Acompanhamento indevido do cliente. |
Glosas administrativas e punições |
|||
2.2 |
Insatisfação do Cliente |
O projeto realizou aquilo que foi especificado na OS, mas mesmo assim não atendeu ao usuário |
Insatisfação do cliente |
|||
3.1 |
Qualidade dos Requisitos |
O cliente não tem domínio da área de atuação e, por conseguinte, os requisitos não são claros. |
Atrasos, produto com baixa qualidade |
|||
4.1 |
Indisponibilidade de Recursos |
Indisponibilidade de profissionais no mercado. |
Aumento do nível salarial |
|||
Planejamento
| ID | Fator de Risco | Estratégia de Mitigação | Gatilho | Estratégia de Contingência |
|---|---|---|---|---|
1 |
Inviabilidade dos prazos de entrega |
Identificar tarefas paralelas que podem ser completadas em menos tempo. |
Data de entrega do projeto ou dos marcos de entrega for(em) superior à data limite de entrega. |
Realizar uma visita gerencial e manter o cliente ciente e informado. |
2 |
Possibilidades de cancelamento de projeto |
Ter reuniões frequentes com o cliente, inclusive na fase de desenvolvimento, para evitar um conflito entre as partes interessadas. |
Atraso no pagamento superior a 60 (sessenta) dias. |
|
3 |
Desconhecimento do negócio pelos usuários e equipe de projeto. |
Utilizar um roteiro de entrevistas para direcionar a elicitação de requisitos. |
Fase de requisitos superior a 20% do prazo do projeto. |
|
4 |
Variação de cronograma no projeto. |
Descentralizar a produção por localidades diversas. |
Falta de recurso técnico aprovado 2 semanas antes do início do projeto. |
Histórico de Revisões
| Data | Versão | Autor | Revisor | Observação |
|---|---|---|---|---|
07/10/2014 |
1.0 |
Marcelle Mirsky |
Miguel Negrelli |
Versão Inicial |
22/05/2015 |
2.0 |
Marcelle Mirsky |
Miguel Negrelli |
Segunda versão para adequação da monitoração que não será mais feita pela planilha |
08/05/2018 |
3.0 |
Cédric Lamalle |
Miguel Negrelli |
Atualização da base retirando riscos 2.1, 3.3 e 5.1 que não se aplicam mais. Os itens com numeração superior a 2 tiveram a numeração deles decrementada de um (3.x virou 2.x, etc.) |
Guia de Análise Estatística para Alta Maturidade
Versão do documento: 1.1, 23/09/2021
Gerar a Planilha de Análise de Desempenho
Gerar planilha de dados das tarefas
Acessar o aplicativo https://pearson.basis.com.br e no menu principal, escolher a opção "Análise de Desempenho".
Selecione o Contrato a ser analisado e o período no qual os dados devem ser extraídos.
Gerar os gráficos no Minitab
Nomeação das colunas com nomenclatura padrão
A planilha gerada pelo Pearson cria um conjunto de 2 colunas para cada "Subprocesso ProcessoAlternativo Subgrupo Tipo" contendo o identificador da tarefa e o valor apurado (produtividade ou densidade de defeitos). Exemplo: para o subprocesso Codificação - Programador Junior - Java - Produtividade Nomenclatura: CO JA PJ P e CO JA PJ PP
| RQ | Requisitos |
|---|---|
AP |
Análise e Projeto |
CO |
Construção |
TS |
Teste |
UC |
Caso de Uso |
EP |
EPE |
DE |
Delphi |
JA |
Java |
PH |
PHP |
CS |
C# |
OL |
Outras Linguagens |
GP |
Gerente de projetos |
AJ |
Analista Júnior |
AP |
Analista Pleno |
AS |
Analista Sênior |
ES |
Estagiário |
FE |
Fábrica Externa |
PJ |
Programador Júnior |
PP |
Programador Pleno |
PS |
Programador Sênior |
TJ |
Testador Júnior |
TP |
Testador PLeno |
TS |
Testador Sênior |
AU |
Automático |
MN |
Manual |
Q |
Tarefa da Qualidade |
Valor apurado da Qualidade |
|
P |
Tarefa da Produtividade |
PP |
Valor apurado da Produtividade |
Acessar o menu: Estat >Ferramentas de Qualidade > Capability Sixpack > Normal
Preencher o campo "Espec. superior"
-
Este valor deve ser preenchido com a meta organizacional. Obs.: caso o cliente em específico possua uma meta, priorizar a meta do cliente. Caso contrário, utilizar a meta organizacional.
Para buscar a meta organizacional: - Acessar o filtro "Basis Qualidade - Metas Organizacionais" no SGO: https://sgo.basis.com.br/issues/?filter=77345 - Localizar e abrir a ocorrência da qualidade mais recente e que data de vigência seja superior à data da análise.
Exemplo: Como obter a meta organizacional do Subprocesso: Requisito > Caso de Uso > Analista Pleno - Seleciona a aba "Requisito" na ocorrência da qualidade e obter os Limites de Especificação da Produtividade e Qualidade para realizar as análises.
-
Localizar o limite de especificação superior
-
Preencher valor no minitab e clicar em "OK"
Análise do gráfico
Analisar os ponto que estão fora da curva
Exemplo de ponto fora da curva:
Obs.: com a experiência, é possível identificar os pontos que sairão fora da curva e retirá-los antes de gerar o gráfico. Porém, é recomendável retirar somente os pontos que estão ao extremo. Lembrando que nenhum ponto pode ser retirado sem fazer análise de causa antes. Para realizar a análise da causa, seguir Passo H
Primeira análise: P value maior que 0,05
P value maior que 0,05 indica que os processos estão dentro da normalidade e sob controle
Segunda análise - Limites de especificação superior e inferior
Devem estar dentro do limite informado no campo "Espec. superior" ao gerar a análise.
Terceira análise - CPk > 1
-
O Cpk deve ser maior que 1
-
A indústria atualmente utiliza a média de Cpk = 1,33
-
Para o CPk menor que 1, os pontos não devem ser retirados (pois o processo está no controle e não há pontos pontos fora da curva, somente o Cpk está menor que 1)
-
Porém, é necessário realizar uma análise dos pontos que estão resultando no Cpk menor que 1 e registrar o motivo da exclusão destes dados
Análise da Causa Raíz
O Robô SGO irá gerar tarefas do tipo "Causa Raíz" de acordo com as análises que estão fora da curva
Para gerar a análise de causa manualmente: image::guia_alta_maturidade/h1.png[]
Analisar os pontos fora da curva e classificar na tarefa a causa raíz
-
Utilizar o template como comentário no SGO para análise da causa raíz
Template 1 - Para registro da análise/técnica aplicada
TEMPLATE
BASIS-35276 / BASIS-35277 / BASIS-35278 (pontos analisados)
BASIS-36243 Template para "Brainstorm" Problema # Sistema legado # Ambiente do Cliente # Má uso do SGO # Erro de cálculo
Template para "Cinco Por ques"
Problema: Produtividade abaixo do esperado # Por que? Desconhecimento do sistema # Por que? Sistema desenvolvido por outra empresa # Por que? Sistema precisa de token e só funciona em uma versão de browser # Por que? Tecnologia Obsoleta # Por que? Gera mais tempo para a execução dos testes
Ação: - Revisão do cálculo da produtividade. - Orientação no uso do SGO. - Repasse técnico e Negocial por parte do MDIC
Template 2 - Para registro do resultado/acompanhamento ||Análise de causa|| |TS MA TP x TS MA TP P|
||Causa Raiz||Resultado da Análise das Causas||Participantes||Data||Técnica|| |Inexperiência na tecnologia|Retirar pontos da análise|Pedro Sena e Eduardo Lobo|14/08/2018|Brainstorming + 5 por quês|
||Ação||Responsável||Data||Status|| |Orientar equipe no uso do SGO|Eduardo Lobo|14/08/2018|Concluido| |Repasse técnico e Negocial por parte do MDIC|Eduardo Lobo|14/08/2018|Concluído|
Tomar a decisão a partir da análise, de manter e tratar com uma ação o ponto fora da curva ou excluir
observações: - nenhum ponto fora da curva deverá ser excluído sem análise de causa raíz - pontos fora da curva que serão analisados, deverão ser acompanhados com uma ação - analisar junto ao recurso e entender a causa raíz - registrar tudo na tarefa
Simulação de Monte Carlo
A simulação de Monte Carlo analisa se a composição (equipe) do projeto é capaz de atender a produtividade esperada dentro do prazo esperado. Deve ser realizada ao iniciar o projeto ou a cada alteração da composição ou para realizar simulações de novas composições com diferentes subprocessos para validar se continuaria atendendo o cliente. Segue passo-a-passo para simulação Monte Carlo
Identificar os subprocessos da sua composição atual
Periodicidade para realizar simulação de Monte Carlo: Sempre ao início dos projetos e sempre que sua composição (equipe) for alterada ou necessitar ser alterada. A simulação Monte Carlo deve ser feita por produtividade e qualidade para cada processo (Requisito, Análise e Projeto, Codificação e Teste) Exemplo de subprocesso identificado na sua composição: Requisitos - EPE - Jr Construção - C# - Jr Teste - Manual - Jr
Local do documento:
Fazer uma cópia deste documento e salvar para seu projeto, mantendo somente a simulação de Monte Carlo da sua composição.
Verificar se sua composição está nos slides do documento padrão
Observação: - caso sua composição esteja neste documento e a meta utilizada é a meta organizacional, não é necessário realizar a simulação Monte Carlo. Somente copie os slides da sua composição e cole no documento do seu projeto.
Realizar a simulação de Monte Carlo
Baixar a Planilha para Simulação de Monte Carlo*
Localização do arquivo: Relatório de Monte Carlo ==== Abrir a planilha com o Crystal Ball*
ATENÇÃO: os dados desta planilha não podem ser alterados ou sobrescritos com suas versões.
Ir na opção: Objetivos
MARCAR o checkbox Excluir dos objetivos que não serão analisados para o momento. Por exemplo: Para analisar produtividade para Java, somente a opção "Produtividade Java Total" fica DESMARCADA, ou seja, o que será analisado. O restante fica marcado, ou seja, que serão excluídos.
Ir na opção: Variáveis de decisão
Identificar o que será avaliado. obs.: para as variáveis de decisão que não possuem alias é para análise de produtividade
As opções DESMARCADAS são as opções que serão analisadas. Para o nosso exemplo de análise da produtividade Java, desmarcar as opções: - S1 Requisitos Produtividade - S2 Análise e Projeto Produtividade - S3 Construção Java - S4 Teste Produtividade
Registro e Consolidação das análises no SGO
-
Após todas análises realizadas, mensalmente até o 5º dia útil do mês seguinte, o gestor deverá criar no SGO uma tarefa de Análise de Desempenho. (Está em aprimoramento, para que o SGO gere a tarefa automaticamente)
-
Todos os gestores devem anexar a esta tarefa os gráficos do Minitab, o Excel de Monte Carlo e o Power Point com os gráficos e conclusão do Monte Carlo.
Glossário
| Termo | Definição |
|---|---|
Baseline 1 |
Análise de desempenho baseado por OS’s (aplicar análise até 30/04/2018) |
Baseline 2 |
Análise de desempenho baseado por tarefas (aplicar análise a partir de setembro/2018 |
Baseline 3 |
Análise de desempenho baseado por tarefas (aplicar análise a partir de outubro/2021 |
Informações adicionais
Curso de Estatística - Certificação White Belt Link: https://ead.escolaedti.com.br/curso/white-belt/
Template Ata Kick-off / Planning
Versão do documento: 1.0, 21/05/2018
Pauta
-
Discussão do escopo da iteração/sprint
-
Discussão sobre os requisitos técnicos e sua priorização
-
Discussão sobre as datas previstas para a iteração/sprint
Itens discutidos
-
[foram discutidos os requisitos do projeto, bem como sua viabilidade técnica e gerencial para a Sprint]
-
[A equipe ponderou que (…)]
-
[foram discutidas as datas da iteração/sprint e decidou-se que (…)]
-
[foram debatidos os riscos do projeto/iteração/sprint]
-
Todos os participantes concordam com a viabilidade técnica e gerencial da iteração/sprint e estão dispostos a seguir com o
Histórico de Revisões
| Data | Versão | Autor | Revisor | Observação |
|---|---|---|---|---|
21/05/2018 |
1.0 |
Cédric Lamalle |
Geraldo Palmeira |
Versão inicial |


