Para os responsáveis por Ops
Treinamento Ops
O treinamento ajuda as equipes que viabilizam o trabalho dos Product Builders a tornar utilizáveis os serviços compartilhados que oferecem.
Formato e preço
A partir de € 4.500 por grupo, IVA não incluso
- Dois dias (14 horas), em inglês ou em francês, até oito participantes
- Inclui uma chamada de preparação de 60 a 90 minutos e uma revisão de acompanhamento de 90 minutos, duas a três semanas depois
ou escreva para lcnlechevaliernoir@gmail.com
Para quem é
Design Ops, Frontend Ops, Backend/API Ops, Data Ops, e os responsáveis por acessos, entrega, observabilidade e revisão de cujos serviços um Product Builder depende.
O que não é
Não é um exercício guiado de Claude Design nem de programação de uma funcionalidade.
O que cada capacidade estabelece
A mesma ordem da linha horizontal em “O princípio”, para que a linha que você reconhece lá seja a linha em que você chega aqui.
| Capacidade | Recursos de trabalho para os Product Builders |
|---|---|
| Design Ops | Padrões e componentes revisados, orientações sobre interação e estados, um processo de revisão de design, e uma forma clara de preservar o design aceito para a implementação. |
| Frontend Ops | Um repositório starter aprovado e mantido, ou uma configuração equivalente, com versão conhecida, responsável e instruções para clonar e começar, além de convenções de estrutura, componentes, estado, roteamento, acessibilidade, localização, testes e integração. |
| Backend e API Ops | Padrões de referência para autenticação, permissões, migrações e testes; contratos de API fáceis de encontrar, com seu significado de negócio; versionamento, convenções de erro, ambientes de testes, convenções de backend escritas como critérios com os quais uma mudança pode ser confrontada, começando pela receita para as mudanças mais comuns e mantidas em dia com o que as revisões encontram, com um revisor designado, e um processo para pedir ou construir uma API que falta. |
| Data Ops | Definições e contratos de eventos claros, dados de teste adequados, regras de acesso e de qualidade, e uma forma de responder a uma pergunta de aprendizado concreta. |
| Acessos e entrega | Um responsável designado e um prazo de resposta para acessos com o escopo adequado; branches protegidas, verificações obrigatórias, ambientes identificados e evidências de qual versão está rodando. |
| Observabilidade e revisão | Acesso somente leitura aos logs úteis, aos erros e à saúde das integrações; um processo de diagnóstico e de incidentes; e um processo de revisão técnica confiável, com um responsável designado. |
Quando falta algo
O Product Builder envia um pedido delimitado
Contexto, restrições, um prazo de resposta e um critério de aceitação.
O responsável por Ops decide
Ampliar o serviço compartilhado, ou conceder uma exceção.
Os dois lados verificam o resultado
No produto integrado, não no documento.
Como funciona o treinamento
Dois dias, 14 horas, em inglês ou em francês, para até oito participantes das equipes de Ops, com pelo menos um Product Builder e um sponsor que possa resolver as questões de responsabilidade.
Preparação
Uma chamada de 60 a 90 minutos para escolher uma jornada real de um Product Builder, reunir as orientações existentes e identificar os responsáveis por Ops que podem decidir durante o workshop.
Dia 1 — ver o trabalho do lado do Product Builder
Acompanhar como um Product Builder começaria essa iniciativa, testar se cada serviço é operacional e não apenas documentado, e definir o serviço mínimo que cada equipe precisa oferecer.
Dia 2 — construir o primeiro pacote de partida
Cada equipe redige a sua primeira contribuição utilizável, combina como as capacidades que faltam são pedidas e verificadas, e pede a um Product Builder que percorra o pacote e marque o que é utilizável, o que não está claro e o que está bloqueado.
Revisão de acompanhamento
Uma revisão de 90 minutos, duas a três semanas depois, para verificar se um Product Builder conseguiu usar os primeiros recursos em uma iniciativa real.
O que o grupo leva
Um pacote de partida para Product Builders, versão 0
Um mapa da jornada escolhida, com os bloqueios atuais.
Responsáveis designados e um pequeno catálogo dos serviços compartilhados de que essa jornada precisa.
Rascunhos de convenções de frontend e de backend/API, com o repositório starter aprovado ou um plano identificado para construir um.
Um mapa de APIs e de acessos: o que existe, quem é o responsável, como obter acessos com o escopo adequado e o que falta.
Orientações de design e de dados onde essa jornada precisar.
Uma verificação de prontidão das verificações obrigatórias, das branches implantáveis, dos ambientes, das evidências de qual versão está rodando, dos diagnósticos e da revisão técnica.
Um contrato de pedido e resposta entre Product Builders e responsáveis por Ops, com tempos de resposta, evidências de aceitação e escalonamento.
Um plano de 30/60/90 dias com responsáveis que prestam contas.
O kit gratuito continua completo.
Nada de que um Product Builder precisa para uma primeira execução está reservado ao treinamento.
O workshop produz um pacote inicial e um plano priorizado. Escrever um conjunto completo de convenções de produção, construir novas APIs, provisionar acessos e fazer mudanças de plataforma são trabalho posterior das equipes responsáveis.