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

Objetivos
  • Proporcionar aos acionistas alta remuneração pelo investimento.

  • Ter processos aderentes ao CMMi 3.

  • Direcionar a atenção à satisfação das necessidades e ao sucesso dos Clientes.

Princípios

principios

Valores

valores

Organograma da empresa

valores

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.

Responsabilidades do Fiscal Técnico - Cliente
  • Reportar ao Requisitante o andamento dos projetos da FSW;

  • Garantir o cumprimento dos acordos, por parte do requisitante, com a FSW;

  • Ser o canal de comunicação entre a FSW e os Requisitantes.

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

Tabela 1. Orientações para comunicação entre equipes
Objetivo Mecanismos Sugeridos Orientações

Entendimento técnico

  • Reunião

  • Discussões em grupos

  • Ocorrência no SGO

  • Quando envolver decisões técnicas, o resultado da comunicação deve ser registrado na respectiva ocorrência no SGO.

Obtenção de informações com cliente

  • Reunião

  • Ocorrência no SGO

  • Quando informações são contribuições para artefatos de projeto, devem ser registradas no SGO e/ou armazenadas no Git.

Acompanhamento de progresso

  • Ocorrência no SGO

  • Devem ser registradas no SGO e disponibilizadas aos envolvidos no Git ou SGO.

Alinhamento entre equipes

  • Reunião

  • Ocorrência no SGO

  • Sempre que alinhamento entre equipes for necessário, deve ser registrado em Ocorrência no SGO.

Aceite/Aprovações de produtos

  • Aceite em Ocorrência no SGO

  • Aceites e aprovações de produtos deverão ser registrados nas Ocorrência no SGO.

Orientações para troca de informações confidenciais

Não é possível divulgar o conteúdo, mesmo que em parte, de qualquer informação confidencial de cliente ou da própria Basis em qualquer meio de comunicação externo da empresa.

Orientações para comunicação eletrônica

Devem ser mantidas comunicações por meio de E-mail ou SGO.

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

Tabela 2. 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:

Tabela 3. Tabela de cálculo de prioridade de Riscos
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

Tabela 4. 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

Tabela 5. 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

Tabela 6. Análise dos Riscos
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.
Produto com Baixa de Qualidade e/ou artefato inexistente.
Decisão da Basis em cancelar o projeto.

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.
Analista de requisitos inexperiente envolvido no procedimento de levantamento de requisitos.

Atrasos, produto com baixa qualidade
Insatisfação do cliente

4.1

Indisponibilidade de Recursos

Indisponibilidade de profissionais no mercado.

Aumento do nível salarial
Alta Rotatividade
Nivel de exigência de qualidade do profissional é baixado.

Planejamento

Tabela 7. Planejamento dos Riscos
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.
Negociar aumento de escopo e prazo em uma atualização da PT ou nova PT.
Abrir processos seletivos para contratação, treinamento e/ou mentoring de consultores mais experientes.

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.
Negociar funcionalidades da versão atual para a próxima versão.

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.
Manter as ocorrências dos projetos com as informações atualizadas.
Realizar entregas parciais.

Atraso no pagamento superior a 60 (sessenta) dias.
Comunicado formal do cliente quanto à qualidade do projeto.

3

Desconhecimento do negócio pelos usuários e equipe de projeto.

Utilizar um roteiro de entrevistas para direcionar a elicitação de requisitos.
Ter um representante do cliente ou especialista que possa direcionar a equipe do projeto para os interesses do cliente.
Interromper o processo de levantamento de requisitos e solicitar ao cliente o levantamento e desenho dos processos de negócio para o pleno entendimento.

Fase de requisitos superior a 20% do prazo do projeto.

4

Variação de cronograma no projeto.

Descentralizar a produção por localidades diversas.
Treinamentos e mentorings de especialistas .
Busca de profissionais em outras áreas.

Falta de recurso técnico aprovado 2 semanas antes do início do projeto.

Histórico de Revisões

Tabela 8. 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

Baixar a última versão da 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.

pearson

Salvar uma cópia para o seu projeto

Gerar os gráficos no Minitab

Abrir o software 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

planilhaP
Tabela 9. Nomenclatura dos Subgrupos e Subprocessos
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

QQ

Valor apurado da Qualidade

P

Tarefa da Produtividade

PP

Valor apurado da Produtividade

Transpor os valores de Produtividade e Densidade de Defeitos para o Minitab

f3

Acessar o menu: Estat >Ferramentas de Qualidade > Capability Sixpack > Normal

f4
Selecionar as colunas para análise (gerar 1 gráfico por subprocesso)
f4 1
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.

q2

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.

q1
  • Localizar o limite de especificação superior

f4 2 1
  • Preencher valor no minitab e clicar em "OK"

f 4 2 2

Análise dos dados gerados

No exemplo dado, analisar os valores do gráfico conforme Power Point para Subprocesso: Requisito > EPE > Analista Júnior image::guia_alta_maturidade/f-5.png[]

Análise do gráfico

Analisar os ponto que estão fora da curva

Exemplo de ponto fora da curva:

g1

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

Após retirar os pontos fora da curva, gerar o gráfico para análise

Primeira análise: P value maior que 0,05

g2

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.

g4

Terceira análise - CPk > 1

g5
  • 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

Identificar sua composição no documento padrão

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

Ashampoo Snap 2018.08.06 18h55m09s 001

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

Instalar o Plugin do Excel chamado "Crystal Ball"*
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*

Ashampoo Snap 2018.08.06 19h14m08s 002

ATENÇÃO: os dados desta planilha não podem ser alterados ou sobrescritos com suas versões.

Ir em OptQuest
Ashampoo Snap 2018.08.06 19h20m38s 003
Ir na opção: Objetivos
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
variaveis

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

Ir em Restrições
restricoes
  • As restrições que serão analisadas, devem ser desmarcada a opção excluir

  • Após isso, será habilitado a opção para inserir o número da restrição conforme tabela Legenda Monte Carlo disponível em uma das abas da planilha de simulação.

Ir em Opções
opcoes
  • Altere a quantidade de simulações e avaliações.

  • Clicar no botão "Executar"

Realizar conclusão
  • Inserir o gráfico gerado na apresentação do seu projeto e inserir a conclusão de acordo com o valor de produtividade/qualidade gerado na simulação Monte Carlo. Identificar se a sua composição é capaz ou não de alcançar a meta definida pela Alta direção.

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/

Histórico de Revisões

Tabela 10. Histórico de Revisões

Data

Versão

Autor

Revisor

Observação

17/08/2018

1.0

Larissa Kikkawa

Geraldo Palmeira

Versão inicial

23/09/2021

1.1

Regina Costa

Geraldo Palmeira

Atualização do guia com a automatização do processo de coleta de dados para análise

Templates

Template Ata Kick-off / Planning

Versão do documento: 1.0, 21/05/2018

Participantes

Nome

Papel no Projeto

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

Ações

Ação

Responsável

Prazo

Histórico de Revisões

Tabela 11. 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

Template de Controle Financeiro

Template de Relatório de Status

Template de Relatório de Acompanhamento Periódico

Assistente virtual
Olá! Como posso te ajudar?