Como Trabalhamos

Aprendemos o problema real: o processo atual, as suas restrições, quem utiliza o sistema no dia a dia, e como é o sucesso. Isto inclui falar com as pessoas que realmente vão utilizar aquilo que construirmos.

O que recebe: Um documento de levantamento escrito que documenta o problema, as restrições e os objetivos acordados: o ponto de referência com que tudo o resto é medido.

As conclusões do levantamento tornam-se um plano com âmbito definido: o que está a ser construído, em que ordem, e quanto custa. É também aqui que dizemos não a tudo o que não pertence a uma primeira versão.

O que recebe: Uma proposta de âmbito fixo com marcos, cronograma e preços, um documento que pode levar à sua própria liderança antes de se comprometer.

Mapeamos como uma pessoa realmente se move pelo sistema (os fluxos, as decisões, os estados) antes de tocar num único detalhe visual.

O que recebe: Wireframes e diagramas de fluxo de utilizador para cada percurso principal do produto, revistos consigo antes de o design visual começar.

Os fluxos aprovados ganham uma linguagem visual real (tipografia, cor, espaçamento e componentes) construída como um sistema, não como ecrãs isolados.

O que recebe: Designs de alta fidelidade para cada ecrã principal, além de uma biblioteca de componentes a partir da qual qualquer uma das equipas pode construir diretamente.

Antes de qualquer linha de código ser escrita, decidimos como o sistema está estruturado: modelos de dados, limites de serviços, dependências, e como se sustenta depois do lançamento.

O que recebe: Um documento de arquitetura técnica: modelo de dados, diagrama do sistema, e o raciocínio por detrás das decisões-chave.

O sistema é construído sobre um ambiente de staging que pode acompanhar em qualquer momento, em marcos definidos em vez de uma única revelação no final.

O que recebe: Builds funcionais e revisáveis em pontos de controlo regulares, e visibilidade do progresso face aos marcos definidos no Planeamento.

Antes de algo chegar à produção, é testado face aos requisitos originais, casos limite, e condições que uma demonstração nunca mostra.

O que recebe: Um resumo de testes cobrindo o que foi verificado e o que não foi, e uma lista de erros a zero, ou uma razão documentada para o que tenha sido adiado.

O lançamento é planeado, não improvisado: etapas de migração, uma janela de entrada em produção definida, e um percurso de reversão caso algo precise de ser revertido.

O que recebe: Um plano de implementação que já viu com antecedência, e um lançamento executado de acordo com ele, connosco presentes na entrada em produção.

As primeiras semanas depois do lançamento são quando as suposições encontram a utilização real. Observamos taxas de erro, desempenho e comportamento real.

O que recebe: Monitorização e alertas implementados desde o primeiro dia, e um relatório breve sobre como o sistema está realmente a desempenhar-se.

O software precisa de atenção depois do lançamento. As dependências envelhecem, os requisitos mudam. Isto é uma relação contínua, não um projeto que termina silenciosamente.

O que recebe: Um acordo de apoio definido com tempos de resposta reais, e acesso completo ao código-fonte, documentação e infraestrutura.