O projeto final não começa agora
Ele começou quando Ana chegou com o notebook. Desde então, cada etapa respondeu a uma dúvida que apareceu no caminho.
Conte a história antes de olhar as siglas
Se você consegue contar essa história com suas palavras, as siglas deixam de ser o centro do aprendizado.
Agora recupere os nomes que usamos no caminho
| Nome | O que ele queria dizer no nosso caso |
|---|---|
| AS-IS | Como o atendimento funcionava antes das melhorias. |
| TO-BE | Como propusemos que o atendimento passasse a funcionar. |
| DFD | Um jeito de acompanhar por onde os dados circulam. |
| BPMN | Um jeito de enxergar o processo e as responsabilidades. |
| UML | Uma família de diagramas usada quando uma pergunta específica precisava de outra visão. |
| RF / RNF / RN | Requisitos funcionais, não funcionais e regras de negócio. |
| MVP | A menor versão coerente que já entrega valor e permite aprender. |
| PoC | Um experimento pequeno para reduzir uma dúvida técnica. |
O mais importante: por que cada artefato existe?
Um fluxograma só faz sentido porque precisávamos enxergar os caminhos. Um DFD só apareceu porque queríamos seguir a informação. O BPMN apareceu quando a responsabilidade entre pessoas ficou importante.
Essa é a regra que deve continuar com você: primeiro a pergunta, depois a ferramenta.
| Se a sua dúvida é... | Uma ferramenta que pode ajudar |
|---|---|
| Como o processo acontece hoje? | Fluxograma AS-IS |
| Por onde os dados circulam? | DFD |
| Quem faz cada parte do processo? | BPMN |
| Quem usa o sistema e para quê? | Casos de Uso |
| Como uma funcionalidade se comporta? | Diagrama de Atividades |
| Quem envia mensagens para quem? | Diagrama de Sequência |
| Quais conceitos existem e se relacionam? | Modelo de Domínio |
| Como algo muda de situação? | Diagrama de Estados |
| O que entra primeiro? | Backlog, Story Map e MVP |
| A pessoa consegue usar? | Wireframe e protótipo |
| O que pode dar errado? | Registro de riscos |
| O que muda se uma decisão mudar? | Rastreabilidade |
Também é importante saber quando parar
Se já está claro, por que desenhar mais?
Uma funcionalidade simples talvez já esteja bem explicada por requisito, regra e protótipo. Nesse caso, produzir DFD, Caso de Uso, Atividades e Sequência da mesma coisa pode apenas repetir informação.
Análise proporcional significa usar mais detalhe quando existe mais risco, complexidade, exceção ou dificuldade de comunicação.
Quando a análise já é suficiente para avançar?
Ainda há algo crítico escondido
- regra importante contraditória;
- pessoa essencial não foi ouvida;
- integração de alto risco ainda desconhecida;
- ninguém sabe como validar o comportamento.
Já temos base para seguir
- objetivo claro;
- regras essenciais conhecidas;
- critérios verificáveis;
- dependências importantes identificadas;
- dúvidas críticas tratadas.
Analisar bem não significa esperar saber absolutamente tudo. Significa saber o bastante para dar o próximo passo com risco consciente.
Depois da análise, o desenvolvimento pode seguir caminhos diferentes
Nem todo projeto precisa avançar da mesma maneira.
Cascata
Na abordagem em Cascata, o trabalho avança principalmente em sequência. Pode fazer sentido quando requisitos estão mais estáveis e mudanças tardias custam muito.
Iterativo e Incremental
Iterar é voltar e melhorar com o que aprendemos. Incrementar é acrescentar novas partes ao produto.
Modelo Espiral
O Modelo Espiral organiza o avanço em ciclos orientados por risco e aprendizado.
Leia uma volta antes de olhar o desenho
Planejar → analisar riscos → construir ou prototipar → avaliar → revisar → avançar.
Depois, uma nova volta repete esse raciocínio com mais conhecimento.
Ciclo: planejar → analisar riscos → construir/prototipar → avaliar → revisar → avançar.
Abordagem Ágil
Na Abordagem Ágil, o trabalho avança em pequenas entregas, com conversa frequente e possibilidade de rever prioridades conforme aparecem novas evidências. Isso não significa “não analisar”: significa analisar o necessário para tomar bem a próxima decisão.
Onde isso já apareceu na Conecta?
Quando o protótipo mostrou uma dúvida, voltamos aos requisitos. Quando as integrações ficaram concretas, revimos qualidade e riscos. Quando o risco mudou, o backlog também pôde ser questionado. Ou seja: o projeto já nos mostrou, na prática, que aprender pode fazer uma decisão anterior ser revisada.
Volte ao problema inicial
No começo, a Conecta sofria porque as informações estavam espalhadas e o cliente não sabia facilmente o andamento do equipamento.
Agora pergunte:
- o processo futuro realmente reduz esse problema?
- os requisitos nasceram de evidências?
- o protótipo permite acompanhar a ordem?
- os riscos importantes foram reconhecidos?
- conseguimos explicar por que cada decisão existe?
Se alguma resposta for “não”, volte à etapa de origem. Isso não significa que a análise falhou; significa que ela continua viva.
Dossiê Final da Assistência Técnica Conecta
O dossiê reúne a passagem do problema inicial para uma base organizada de desenvolvimento, sem copiar todos os artefatos novamente.
Fechamento
- Conte o projeto inteiro sem usar siglas.
- Escolha três ferramentas e explique qual pergunta fez cada uma aparecer.
- Mostre um ponto em que uma descoberta obrigou você a voltar e revisar algo anterior.
- Explique por que o MVP não contém tudo.
- Mostre uma ligação completa entre problema, requisito, interface e teste.
- Abra o dossiê final e confira se ele conta a mesma história.
Defesa da análise
O melhor sinal de aprendizado não é lembrar todas as siglas. É conseguir explicar por que cada decisão foi tomada e o que você faria se uma nova evidência aparecesse.