1. DevOps
1.1. Alternativa ao Maicon
1.1.1. Quais são os Skills necessários
1.1.2. Qual o budget para a vaga
1.1.3. Quando
1.2. Nova proposta de alocação
1.2.1. Fazer uma proposta 160 horas/mês
1.2.2. Alocação
1.3. Escopo de Trabalho
1.3.1. Repasse do Maicon
2. Equipe
2.1. Interrupções
2.1.1. Equipe é constantemente interrompida das atividades de desenvolvimento
2.1.1.1. Questões de implantação
2.1.1.2. Bugs de entregas passadas
2.1.1.3. Questões de erros de versionamento
2.2. Produtividade
2.2.1. Tecnologia
2.2.1.1. Tempo de deploy local
2.2.1.2. Dificuldade Técnica
2.2.1.3. Ferramentas
2.2.1.4. Senioridade nas tecnologias
2.2.1.5. Arquitetura dos projetos
2.2.1.6. Ambientes de Teste e Desenvolvimento
2.2.2. Processo
2.2.2.1. Nível de detalhamento de negócio
2.2.2.2. Análise da solução técnica
2.2.2.3. Constante troca de prioridade
2.2.3. TurnOver/Rotatividade
2.2.3.1. Ritmo constantemente intenso
2.2.3.1.1. Mais antigos acabam não aguentando e saindo do projeto e da empresa
2.2.3.2. Equipe com pouca experiência no negócio do cliente e nos projetos
2.3. Estrutura
2.3.1. Back
2.3.1.1. Novo Tech Lead
2.3.1.2. Quantidade
2.3.1.3. Senioridade
2.3.2. Front
2.3.2.1. Papel de Tech Lead?
2.3.2.2. Quantidade
2.3.2.3. Senioridade
2.3.3. Teste
2.3.3.1. Interno ou teceiro?
2.3.3.2. Necessidade de estar fulltime
2.3.3.3. Skills necessários para atender RCI
2.3.3.4. Necessidade de baixa rotatividade
2.3.4. Negócio
2.3.4.1. PO/Analista de Negócio exclusiva
2.3.4.2. Apenas um PO é o suficiente?
2.3.5. Gestão
2.3.5.1. Ronaldo GP
2.3.5.1.1. Fazer a gestão funcional da equipe?
2.3.5.1.2. Definições de papeis e responsabilidades
2.3.5.1.3. Manter-se exclusivo RCI
2.3.5.2. Maicon Consultor
2.3.5.2.1. Dividir as atuais responsabilidades e conhecimentos
2.3.5.2.2. Fazer a gestão funcional da equipe?
3. Processo
3.1. Scrum
3.1.1. O que muda com a nova metodologia
3.1.1.1. Propostas
3.1.1.1.1. Documentação do projeto chegará mais madura para proposta
3.1.1.1.2. Documento de visão de negócio chegará mais estruturado e aberto a sugestões
3.1.1.1.3. Novo documento de proposta de solução técnica será feito pela RCI para auxiliar no momento da proposta
3.1.1.1.4. Prever na proposta as releases, e quantas sprints serão necessárias para serem finalizadas
3.1.1.2. Estrutura de Equipe
3.1.1.2.1. RCA deverá contar com um Scrum Team auto suficiente, capaz de produzir sua entrega do início ao fim
3.1.1.2.2. Scrum Team não deve ter rotatividade
3.1.1.3. Planejamento Financeiro
3.1.1.3.1. Teremos sempre duas entregas no mês
3.1.1.3.2. Faturamento deve ser dividido pelo número de Sprints, não condicionado ao escopo da Sprint
3.1.1.3.3. Se ao menos uma história for aceita, o faturamento da sprint deve ser liberado
3.1.1.3.4. Devemos contar com dois faturamentos no projeto dentro do mês
3.2. Tradicional
3.2.1. Montagem do Cronograma
3.2.2. Alocação da Equipe
4. Faturamento
4.1. Onde estamos
4.1.1. Saldo do Ano
4.1.2. Qual o nosso atual ponto de equilíbrio
4.2. Definir meta do semestre
4.2.1. Com a projeção da restruturação da equipe, qual nosso ponto de equilíbrio
4.2.2. Quanto precisamos faturar no mês para voltar ao positivo
4.3. Qual o orçamento do cliente e quanto podemos provisionar para a RCA
4.3.1. 19 Projetos com orçamento aprovado para este ano
4.3.2. 35 Projetos na fila por falta de braço para formular os projetos
5. Projetos
5.1. Roadmap dos projetos do semestre
5.1.1. Quais projetos temos em vista com RCI ainda neste semestre
5.2. Quantidade de projetos Java baixa
5.2.1. Projetos sendo passados para a Cinq
5.2.2. Quais os projetos estão em aprovação de proposta
5.2.3. O que podemos fazer para acelerar estas aprovações
5.3. Projetos de Migração
5.3.1. Propor projeto de migração de tecnologias
5.3.2. Ter proatividade para propor ao menos um projeto ainda neste ano
5.4. Projetos de Análise
5.4.1. Fazer um orçamento de um projeto de análise antecedendo o projeto Melhorias Técnicas
6. Orçamentos
6.1. Responsável
6.1.1. Revisão interna dos orçamentos antes da proposta para o cliente
6.1.2. Responsável pelo orçamento deve ser alguém com perfil acima da gerencia
6.2. Adequação ao novo processo
6.2.1. Contrato por alocação é uma alternativa?
6.2.2. Ter Sprints de contenção
6.2.3. Ter Sprints de hardening
6.3. Inclusão dos testes na proposta de projeto
6.3.1. Cobrir todo o trabalho que a Zero faz hoje
6.3.2. Quanto isto representa em custo
6.3.3. Quanto isto representa em prazo e liquidez de faturamento
6.4. Metodologia de Estimativa
6.4.1. Estimativa Análoga com base histórica
6.4.2. Inclusão das lideranças nas estimativas
6.4.3. Utilizar base histórica de horas como balizador
6.5. Provisionar custo de viagem
6.5.1. Demos devem ser feitas presencialmente
6.5.2. Levantamento e refinamento de requisitos devem ser feitos presencialmente
6.5.3. Estar presente nos dá uma série de ganhos frente ao cliente
7. Concorrentes
7.1. Cinq
7.1.1. Equipe Exclusiva RCI
7.1.1.1. Scrum Master
7.1.1.2. Analista de Negócios
7.1.1.3. Designer
7.1.1.4. Analista de Testes
7.1.1.5. Arquiteto de Soluções
7.1.1.6. Desenvolvedores Back e Front
7.1.2. Presença física na RCI
7.1.2.1. Refinamento de Backlog é feito junto ao usuário
7.1.2.2. KickOff é feito presencialmente
7.1.2.3. Demos, reviews e retrospectivas são feitas presencialmente
7.1.3. Participação junto a RCI ainda na fase de concepção dos projetos
7.1.3.1. Antes do projeto chegar para proposta, a Cinq está presenta proativamente na concepção da solução
7.1.3.2. A Cinq propões a melhor solução e imerge no negócio antes de qualquer proposta aprovada
7.2. Zero
7.2.1. Entregas
7.2.1.1. Teste Automatizado
7.2.1.2. Teste Funcional
7.2.1.3. Cenários de Testes
7.2.2. Custos
7.2.2.1. 30% do valor do projeto
7.2.2.2. Custo de gestão na integração de dois fornecedores
8. Gerência de Configuração
8.1. Processo de Versionamento
8.1.1. Problemas atuais
8.1.1.1. Merges quebrados
8.1.1.2. Dificuldades ao separar funcionalidades específicas de branchs
8.1.1.3. Branchs de desenvolvimento desatualizadas com prod
8.2. Processo de Aprovação de Merge
8.2.1. Falta de filtro de merge request
8.2.2. Falta de code review
8.3. Documentação Técnica
8.3.1. Falta de documentação técnica das APIs desenvolvidas
8.3.2. Documentação existente pouco detalhada ou não clara suficiente para o cliente