Nosso processo - Como um projeto acontece de verdade
Três fases. Descobrir o que a gente vai construir, construir em ciclos curtos e então entregar com os testes, o pipeline e a documentação já no lugar.
Descobrir
Todo projeto começa com análise de requisitos e conversas com quem vai conviver com o resultado. Nessa altura as restrições costumam pesar mais que os objetivos — e são justamente a parte que a maioria dos briefings deixa de fora.
A gente olha os sistemas que já existem, descobre onde o trabalho novo precisa se conectar e verifica a viabilidade técnica antes que alguém comece a discutir stack.
O que sai daí é um roadmap do projeto: marcos, uma direção técnica e uma ordem de trabalho que você pode contestar.
Incluído nesta fase
- Análise de requisitos
- Estudos de viabilidade técnica
- Pesquisa de experiência do usuário
- Planejamento de arquitetura
- Avaliação de stack
- Criação do roadmap
Construir
O desenvolvimento roda em ciclos curtos, com integração contínua e feedback frequente. Código limpo e testes de verdade começam no primeiro commit, não na semana antes do lançamento.
Revisões regulares mantêm as prioridades à vista. Esse ciclo curto deixa espaço para o produto melhorar enquanto os objetivos, o orçamento e o prazo combinados na descoberta continuam de pé.
Testes de unidade, integração e aceitação são escritos ao longo do caminho. O objetivo é software que a próxima pessoa consiga ler e mudar.
Ciclo curto é menos sobre velocidade e mais sobre mudar de ideia barato. Uma suposição errada pega na segunda semana custa uma conversa. A mesma pega no quarto mês custa uma reescrita.
Entregar
A entrega começa com garantia de qualidade, checagem de performance e revisão de segurança nas plataformas e nos aparelhos em que o produto realmente vai rodar.
As releases passam por staging e produção em pipelines de CI/CD automatizados, com monitoramento no lugar e um caminho de rollback que a gente já executou pelo menos uma vez.
Depois do lançamento você recebe documentação, uma passagem de bastão de verdade e suporte contínuo pelo tempo que for útil. O objetivo é um time que não precise da gente.
Incluído nesta fase
- Garantia de qualidade. Testes de unidade, integração e aceitação, mais as checagens de acessibilidade e performance que costumam ser puladas.
- Deploy em produção. Releases automatizadas com ambiente de staging, monitoramento e um rollback que a gente testou de fato.
- Documentação e suporte. Documentação técnica escrita para quem herdar o código, uma sessão de passagem e suporte depois dela.
Nossos valores - No que a gente se segura
A gente gosta de ferramenta nova. Gosta mais de software funcionando — então qualquer novidade precisa continuar parecendo boa ideia daqui a um ano.
- Caprichoso. Arquitetura, código, acessibilidade e os últimos cinco por cento da interface recebem a mesma atenção.
- Eficiente. Padrões comprovados e um conjunto pequeno de ferramentas. Boa parte da complexidade de um código foi opcional em algum momento.
- Adaptável. Requisito muda. A gente monta a base para que mudar depois seja uma tarefa, e não uma reescrita.
- Transparente. Você vê o progresso e os trade-offs conforme eles acontecem, inclusive os que são inconvenientes para a gente.
- Colaborativo. A gente trabalha como parte do seu time, nas suas ferramentas, com o seu contexto.
- Inovador. Testamos ferramenta nova nos nossos próprios produtos primeiro. O que sobrevive a isso chega no seu.