1. Descoberta
Nós descobrimos o que você está realmente tentando alcançar, o que normalmente não é o que o brief inicial descreve. É aqui que fazemos a maior parte das discussões e onde, ocasionalmente, falamos com alguém para sair de um projeto.Preferimos perder este e ser confiáveis para o próximo do que construir algo que pudéssemos ver que estava errado.
- Conversas com as pessoas que vão usar a coisa, não apenas as pessoas que a compram
- Ler os sistemas que já existem, incluindo as planilhas que ninguém menciona
- Uma avaliação honesta de se algo fora da prateleira serviria melhor para você
- Saída: um escopo escrito, um preço fixo e uma data
2. Âmbito e conceção
Estrutura, modelo de dados, interfaces e decisões técnicas que são caras de reverter.Permissões e auditoria são projetadas aqui em vez de serem adicionadas mais tarde, porque adaptar um modelo de permissão é o retrabalho mais caro em software.Para sites, é aqui que o conteúdo é trabalhado, porque o conteúdo é o caminho crítico e fingir o contrário é a razão pela qual os projetos escorregam.
- Modelo de dados e permissões projetados antes de qualquer coisa ser construída sobre eles
- Design de interface contra conteúdo real, não preenchimento
- Decisões técnicas escritas com o seu raciocínio, para quem herdar este
- Qualquer coisa sobre a qual não temos certeza é testada de forma barata antes de se tornar estrutural
3. Construção
O trabalho é enviado continuamente para um ambiente que você pode ver, e você o vê todas as semanas.Não há fase em que desaparecemos por três meses. Você conversa com as pessoas que escrevem o código — não há gerente de conta traduzindo entre você e elas, porque a tradução é onde os requisitos vão morrer.
- Um ambiente de execução que você pode usar desde as primeiras semanas, não uma demonstração no final
- Contacto semanal com as pessoas que o estão a construir
- Testes automatizados nos caminhos em que errar custa dinheiro
- Monitoramento e registro conectados durante a construção, não aparafusados no final
4. Lançamento
Para qualquer coisa que substitua um sistema existente, isso significa um rollback testado, uma migração de dados executada contra uma cópia de produção mais de uma vez e uma sequência de corte projetada em torno de seu negócio, em vez de nossa conveniência. Para sites, isso significa mapeamento de URL e redirecionamentos acordados antes do lançamento, porque o fracasso clássico do redesign é um colapso de tráfego quatro semanas depois.
- Um cutover ensaiado com um rollback que foi testado, não meramente escrito
- Redirecionamentos e mapeamento de URL no lugar antes do lançamento para qualquer coisa que substitua um site
- Monitoramento de erros, desempenho e os números que importam desde a primeira hora
- Alguém disponível durante e após a janela de lançamento, nomeado com antecedência
5. operar, ou entregar
Ou nós executamos ou sua equipe faz, e ambos estão bem.O que não faremos é deixá-lo com algo que ninguém entende.O runbook é escrito para uma pessoa competente que não estava no projeto, porque eventualmente é essa pessoa que vai lê-lo — e às vezes essa pessoa trabalha para você.
- Um runbook escrito para quem quer que o opere a seguir, incluindo o caso em que não sejamos nós
- Infraestrutura como código, para que o ambiente possa ser reconstruído em vez de lembrado
- Expectativas de resposta acordadas, por escrito, se estivermos operando
- Um caminho de entrega documentado, disponível sempre que você quiser levá-lo internamente
Diga-nos o que você está tentando fazer
Uma breve conversa geralmente é suficiente para dizer se somos as pessoas certas, se não formos, diremos isso e indicaremos um lugar melhor.