Como trabalhamos, do primeiro contato à evolução

O prazo sai do escopo, e por isso o cronograma é fechado depois do diagnóstico, junto com a proposta. Qualquer número dado antes disso é palpite, e palpite de prazo em software costuma errar para menos.

O que pesa no cronograma é parecido com o que pesa no investimento: quantidade de fluxos, integrações com outros sistemas, complexidade das regras e disponibilidade de quem valida do seu lado.

O que podemos garantir desde o começo é a forma: o projeto é dividido em fases, e cada iteração termina com uma entrega utilizável. Você acompanha o avanço em software rodando, não em porcentagem de relatório.

Quatro etapas. Diagnóstico: entender o problema, o contexto técnico e as restrições. Desenho da solução: arquitetura, escopo dividido em fases e proposta. Construção: ciclos curtos, cada um terminando com uma entrega funcional que você pode testar. Transferência: documentação, treinamento e acesso completo a tudo o que foi construído.

Em todas elas você fala direto com quem escreve o código, sem gerente de conta no meio traduzindo o que você disse. Isso encurta o caminho entre uma dúvida e a resposta, e evita que detalhes importantes se percam no telefone sem fio.

Discovery é a etapa em que descobrimos o que realmente precisa ser construído. Conversamos com quem usa o processo no dia a dia, mapeamos os fluxos atuais, levantamos as exceções que ninguém lembra de mencionar na primeira reunião e identificamos as integrações e os riscos técnicos.

Ela vem antes do código porque é muito mais barato mudar uma decisão num quadro do que num sistema pronto. A maior parte dos projetos que dão errado não falha por falta de técnica, e sim porque construiu com capricho a coisa errada.

O resultado é um escopo priorizado, um desenho da solução e um cronograma que dá para defender.

Sim, quando o projeto tem interface relevante. O protótipo navegável mostra os fluxos principais antes de qualquer linha de código de produção, e é nele que você e quem vai usar o sistema apontam o que está confuso, o que falta e o que sobra.

Ajustar um protótipo leva minutos; ajustar uma tela já integrada ao banco de dados e às regras de negócio leva bem mais. Por isso validamos primeiro os fluxos de maior risco ou de maior uso.

Para sistemas sem interface, como integrações e automações, o equivalente é validar o contrato de dados e um fluxo de ponta a ponta com dados de exemplo.

Na maioria dos casos, sim. MVP é a menor versão do sistema que resolve o problema principal para usuários de verdade. Não é uma versão malfeita: é uma versão com menos funcionalidades, construída com a mesma qualidade de código, testes e infraestrutura do sistema final.

A vantagem é aprender cedo. Funcionalidades que pareciam essenciais no papel muitas vezes não são usadas, e necessidades que ninguém previu aparecem logo nos primeiros dias de uso. Com um MVP, você decide as próximas fases com base no uso concreto, não em suposição.

O risco a evitar é o MVP descartável, que precisa ser jogado fora para o produto crescer.

O trabalho é dividido em ciclos curtos, as sprints. No início de cada uma, combinamos com você o que entra, a partir de uma lista priorizada. No fim, apresentamos o que foi feito funcionando num ambiente de homologação, onde você mesmo pode testar.

Isso muda a dinâmica do projeto. Em vez de esperar até o final para descobrir se o sistema faz o que você imaginava, você valida pedaço por pedaço e corrige o rumo cedo. Se uma prioridade muda no seu negócio, ela entra na sprint seguinte, sem precisar replanejar tudo.

A lista de prioridades é sua. Nós opinamos sobre ordem técnica e riscos.

Por três caminhos. Reuniões de acompanhamento em cadência combinada no início do projeto, curtas e com pauta, para mostrar o que foi entregue e decidir o que vem a seguir. Um ambiente de homologação sempre atualizado, onde você testa as funcionalidades assim que ficam prontas. E acesso direto ao quadro de tarefas e ao repositório, para ver o que está em andamento sem precisar perguntar.

Fora das reuniões, a comunicação é por um canal direto com a equipe técnica. Problemas e bloqueios são avisados quando aparecem, não guardados para a reunião seguinte. Surpresa no fim do projeto quase sempre é informação que alguém segurou no meio.

Pelo menos uma pessoa com poder de decisão sobre o escopo, que chamamos de dono do produto. Ela prioriza, responde dúvidas de regra de negócio e valida as entregas. Não precisa ser técnica, mas precisa ter tempo reservado para isso: a disponibilidade dessa pessoa é um dos fatores que mais influenciam o ritmo do projeto.

Além dela, envolvemos pontualmente quem usa o processo no dia a dia, porque é quem conhece as exceções, e, quando há integrações, alguém que tenha acesso aos sistemas atuais ou ao fornecedor deles. Se sua empresa tem time de TI, ele participa das decisões de arquitetura e infraestrutura.

As causas mais comuns são conhecidas: validações que demoram do lado do cliente, integrações com sistemas de terceiros cuja documentação não bate com o comportamento de verdade, regras de negócio descobertas no meio do caminho e escopo que cresce sem que nada saia.

Como lidamos: atacamos primeiro as partes de maior risco técnico, em especial as integrações, para descobrir problemas cedo; escrevemos as premissas na proposta, para que fique claro o que depende de cada lado; e avisamos assim que um risco se materializa, junto com as opções. Atraso comunicado no dia em que aparece é gerenciável. Atraso descoberto na véspera da entrega, não.

Mudança de escopo é normal e esperada: você vai aprender coisas sobre o seu próprio processo ao ver o sistema funcionando. A questão é tratar a mudança de forma explícita.

No time dedicado, é simples: a mudança entra na lista de prioridades e disputa espaço com o resto na próxima sprint. No escopo fechado, avaliamos o impacto e apresentamos as opções antes de fazer qualquer coisa: trocar por algo de peso parecido que ainda não foi construído, deixar para uma fase seguinte ou formalizar um ajuste no contrato.

O que não fazemos é absorver mudanças em silêncio e apresentar a conta depois. Você decide sempre sabendo o impacto.