Desenvolvimento de produto
Seu roadmap não precisa de mais horas. Precisa de entregas.
Pods multidisciplinares sêniores — engenharia, QA, DevOps — que levam funcionalidades da especificação à produção dentro do seu código e dos seus padrões. Com preço por resultado, não por horas.
O que fazemos
- Entrega de funcionalidades, da especificação à produção
- Um pod, não um desfile: as mesmas pessoas sêniores do escopo à entrega
- QA e DevOps dentro do time, não tickets para outra fila
- Capacidade de entrega aumentada com IA — nossas ferramentas deixam o time mais rápido, e você compra o resultado
Provas
Auth0
Sete anos dentro do produto da Auth0 enquanto cresciam de startup a unicórnio — o widget de login, o Admin Panel e o Support Center, sete extensões, as bibliotecas de Python e Node.js.
Leia o casoEnvio360
Construímos a arquitetura multi-tenant que permite a uma plataforma de otimização ler o TMS que a empresa já usa.
Leia o caso- Auth0 · 7 anos dentro do produto
- Widget de login · Admin Panel · 7 extensões
Quando os times nos procuram
- Um roadmap que cresce mais rápido que o time
- Funcionalidades travadas no backlog há trimestres
- Um fornecedor que entregou horas em vez de funcionalidades
Evidência
Sete anos construindo funcionalidades centrais de produto dentro da Auth0 — bibliotecas, o widget de login, o produto em si — enquanto cresciam de startup a unicórnio.
Eles são muito inovadores e sempre trazem ideias novas.
Como construímos
Definir o escopo com quem constrói
os engenheiros que estimam são os que entregam
Entregar toda semana
cadência de demos desde o primeiro sprint
Qualidade dentro do pod
QA e DevOps no time, não em outra fila
Decidir com números
prioridades revisadas a cada sprint, com o board à sua frente
O que significa “resultados, não horas”
O escopo é o contrato
antes de um sprint começar, o que significa "pronto" fica escrito, com os estados e os casos-limite. Você não está comprando atenção; está comprando aquele documento, entregue.
Um pod, sem repasses
os engenheiros que definiram o escopo da funcionalidade a constroem, testam e colocam em produção. Nada espera na fila de outro time.
Uma demo toda semana
software funcionando desde o primeiro sprint, no seu ambiente, com os seus dados. Se não há nada para mostrar, esse é o sinal, e ele chega cedo.
Você pode parar em qualquer sprint
com preço por resultado, revisado toda semana: se o roadmap muda, o pod muda com ele; se deixa de fazer sentido, você para.
Horas medem esforço. Preferimos ser medidos pelo que foi entregue.
Como é um trabalho com a gente
A maioria dos pods começa com uma funcionalidade que o roadmap vem carregando há trimestres: aquela que todos concordam que importa e para a qual nunca houve time. Definimos o escopo com você, no seu código, em uma semana; esse escopo tem preço fixo. Dali em diante o pod roda em cadência semanal: demo, decidir, entregar. Um pod é tipicamente de três a cinco pessoas sêniores, engenharia mais QA mais DevOps, e são as mesmas pessoas durante todo o trabalho. Os times que seguem construindo passam a uma assinatura mensal com preço por resultado, não por horas. Em qualquer dos dois casos, o trabalho fica no seu repositório, sob os seus padrões, com um nome em cada release.
Funciona bem com
Perguntas frequentes
Qual a diferença em relação à ampliação de equipes?
Você compra resultados, não vagas: o pod responde por entregar, não por horas.
Vocês conseguem trabalhar dentro do nosso código e dos nossos padrões?
É o nosso hábito mais característico — sete anos dentro do da Auth0.
E se as prioridades mudarem no meio do projeto?
Os pontos de decisão semanais existem exatamente para isso.
Quem forma um pod?
Engenheiros sêniores, e só sêniores. Um pod típico é de três a cinco pessoas: engenheiros que assumem a funcionalidade de ponta a ponta, QA integrado ao time e DevOps para os ambientes e o pipeline. As mesmas pessoas do primeiro ao último sprint.
Como vocês usam IA no trabalho?
Como um colaborador que digita mais rápido do que qualquer um de nós, dentro de uma disciplina que não muda: especificações no repositório, cada linha revisada por uma pessoa, os testes como contrato, verificações automáticas antes de qualquer publicação e o nome de um engenheiro em cada release. Deixa o pod mais rápido; não o deixa menos responsável.
O que acontece com o código quando o trabalho termina?
É seu desde o primeiro commit: no seu repositório, documentado, com os testes e o runbook. A passagem de bastão é escrita para funcionar sem nós.