Agência de software · Entrega
Kickoff de projeto de software
Comece a desenvolver no primeiro dia do primeiro sprint, em vez de esperar acessos. O cliente indica os responsáveis e libera os acessos por um link público, e o kickoff fica travado até o gerente de projeto aprovar o briefing.
- Duração: 1 a 2 semanas
- Frequência: Para cada projeto novo
- Etapas: 9 etapas
- Agentes de IA: 1 agente de IA
- Aprovações: 1 aprovação
Plano gratuito, sem cartão de crédito.
O que muda com este modelo
Sem o modelo
O primeiro sprint começa e metade da equipe ainda não tem acesso.
As senhas chegam por e-mail e ficam nas caixas de entrada.
Ninguém sabe quem aprova uma versão do lado do cliente.
As decisões do kickoff ficam nas anotações de uma só pessoa.
Com o modelo
Cada acesso é testado antes do kickoff, e um acesso que falta bloqueia a execução.
O cliente libera o acesso em cada sistema ou por um gerenciador de senhas.
O cliente indica quem decide o escopo, quem aceita as versões e quem aprova as faturas.
O cliente confirma as decisões do kickoff na execução.
O modelo, etapa por etapa
Cada etapa diz quem a faz: alguém da sua equipe, um agente de IA ou o cliente por um link público. Uma aprovação mantém todas as etapas seguintes travadas até ser dada.
- Feito pela sua equipe
- Feito por um agente de IA
- Feito pelo cliente, por um link público
Começa quando
O cliente assina o contrato ou o escopo de trabalho. O gerente de projeto inicia uma execução com o nome do cliente e o início previsto do primeiro sprint.
- 1
Preparar o projeto e compartilhar o link do kickoff
Dia 1Gerente de projeto · Equipe
Preencha os dados do projeto a partir do contrato, escreva o escopo e os marcos, e envie ao cliente o link público com o que você precisa dele.
Checklist
- Equipe definida
- Data do kickoff proposta
- Link público enviado ao contato do cliente
Campos a preencher
- Nome do cliente (obrigatório)
- Link para o escopo de trabalho assinado (obrigatório)
- Escopo e marcos (obrigatório)
- Início do primeiro sprint (obrigatório)
- 2
O cliente indica os responsáveis
Dias 1 a 3Contato do cliente · Link público
Pelo link público, o cliente indica quem decide o escopo, quem testa e aceita as versões e quem aprova as faturas.
Checklist
- Horário das demos de sprint combinado
- Canal preferido para falar com a equipe escolhido
Campos a preencher
- Product owner (obrigatório)
- E-mail do product owner (obrigatório)
- Quem testa e aceita as versões (obrigatório)
- E-mail de quem aprova as faturas
- 3
O cliente libera acesso a sistemas e contas
Dias 1 a 5Contato do cliente · Link público
Pelo link público, o cliente dá à equipe acesso a cada sistema da lista, no próprio sistema ou por um gerenciador de senhas. Senhas nunca vão em um campo.
Checklist
- Acesso ao repositório de código liberado
- Acesso à hospedagem ou conta de nuvem liberado
- Acesso ao domínio e ao DNS liberado
- Contas de serviços de terceiros compartilhadas
Campos a preencher
- Link para a documentação técnica existente
- Acessos que ainda faltam organizar
- 4
Testar cada acesso e preparar os ambientes
Dias 3 a 6Engenheiro de DevOps · Equipe
Teste cada acesso que o cliente liberou e prepare os ambientes de desenvolvimento e homologação e o pipeline de deploy. Se faltar um acesso, marque a execução como bloqueada e anote o que falta.
Checklist
- Cada acesso testado
- Ambiente de desenvolvimento pronto
- Ambiente de homologação pronto
- O pipeline de deploy funciona
Campos a preencher
- Acessos que faltam
- Link de homologação
- 5
Escrever o briefing do kickoff
Dia 6Redator do briefing de kickoff · Agente de IA
O redator do briefing de kickoff reúne o escopo, os marcos, os responsáveis e a situação dos acessos em um briefing de kickoff com pauta, seguindo a pauta das suas instruções.
Campos a preencher
- Rascunho do briefing do kickoff (obrigatório)
Revisão humana: O gerente de projeto corrige e aprova o briefing na etapa 6.
- 6
Revisar e aprovar o briefing do kickoff
Dia 7Gerente de projeto · Equipe
Corrija o briefing, confira se os marcos batem com o contrato e aprove.
Checklist
- Os marcos batem com o contrato
- Responsáveis e acessos corretos
- Cada ponto em aberto tem um responsável
Aprovação: O kickoff fica travado até o gerente de projeto aprovar o briefing.
- 7
Fazer o kickoff
Semana 2Gerente de projeto · Equipe
Repasse com o cliente o briefing, a forma de trabalho e o primeiro marco, registre as decisões e mande para o cliente por e-mail no mesmo dia.
Campos a preencher
- Decisões do kickoff (obrigatório)
- Data do primeiro marco (obrigatório)
- 8
O cliente confirma as decisões do kickoff
Semana 2Contato do cliente · Link público
O cliente lê as decisões do kickoff que o gerente de projeto enviou, e as confirma pelo link público ou anota o que entendeu de outro jeito.
Campos a preencher
- Decisão (obrigatório)
- O que entendemos de outro jeito
- 9
Planejar o primeiro sprint
Semana 2Líder de engenharia · Equipe
Planeje o primeiro sprint com base nas decisões confirmadas e confira se cada desenvolvedor consegue começar no primeiro dia.
Checklist
- Histórias do sprint prontas e estimadas
- Cada desenvolvedor tem acesso funcionando
- Data da demo do sprint combinada com o cliente
Campos a preencher
- Link para o quadro do sprint (obrigatório)
Termina quando
O kickoff aconteceu, o cliente confirmou o que foi combinado, a equipe tem acesso funcionando a todos os sistemas e o primeiro sprint está planejado.
Deixe do seu jeito. Renomeie etapas, troque responsáveis e adicione itens de checklist, campos ou aprovações. O modelo é um ponto de partida para o jeito de trabalhar da sua equipe.
Os agentes de IA deste modelo
Um agente só trabalha nas próprias etapas, e alguém da sua equipe confere o que ele fez. Tudo o que um agente grava em um app conectado aguarda aprovação, a menos que você permita.
Redator do briefing de kickoff
Reúne o escopo, os responsáveis e os pontos em aberto em um primeiro briefing de kickoff com pauta.
O que ele faz
- Lê o escopo, os marcos e os responsáveis na execução
- Anota quais acessos ainda faltam
- Segue a pauta de kickoff das suas instruções
- Conclui a sua etapa para o gerente de projeto revisar
Revisão humana: O gerente de projeto corrige e aprova o briefing na etapa 6.
Perguntas que este modelo responde
Reúna os responsáveis e os acessos antes do kickoff, e só comece o primeiro sprint quando o ambiente funcionar. Nas etapas 2 e 3 o cliente indica os responsáveis e libera os acessos pelo link público, e na etapa 4 o engenheiro de DevOps testa cada acesso.
Envie uma única lista com cada sistema de que você precisa, e deixe todo acesso que falta visível como um bloqueio. Na etapa 3 o cliente marca cada acesso pelo link público, e na etapa 4 o engenheiro de DevOps marca a execução como bloqueada e anota o que ainda falta.
Nunca por e-mail ou em um formulário: o cliente libera o acesso no próprio sistema ou compartilha por um gerenciador de senhas. A etapa 3 diz exatamente isso ao cliente, e os campos dela só pedem links e o que ainda falta organizar.
Os objetivos, o escopo e o primeiro marco, quem decide o quê do lado do cliente, como vocês vão trabalhar juntos e o que ainda está em aberto. Na etapa 5 o redator do briefing de kickoff prepara essa pauta, a etapa 6 é um controle de aprovação do gerente de projeto, e a etapa 7 é o kickoff em si.
Escreva as decisões no mesmo dia e peça ao cliente para confirmá-las. Na etapa 7 o gerente de projeto envia as decisões ao cliente, e na etapa 8 o cliente as confirma pelo link público ou anota o que entendeu de outro jeito.
Deixe a IA reunir o escopo, os responsáveis e os pontos em aberto em um primeiro briefing, e deixe o gerente de projeto decidir o que o cliente vê. O redator do briefing de kickoff prepara o rascunho na etapa 5, e o gerente de projeto corrige e aprova na etapa 6.
Execute este fluxo no OKiDO
Configure as etapas, os responsáveis e as aprovações uma vez e depois inicie uma execução para cada caso novo.