Como funciona o desenvolvimento de software sob medida

O desenvolvimento de software sob medida começa pelo entendimento do problema, não pelo código. A necessidade é transformada em requisitos, prioridades, arquitetura, experiência e critérios de validação; depois, a solução é construída, testada, homologada e colocada em produção. O ciclo continua com monitoramento, correções e evolução.

Essa sequência responde à pergunta central — o que acontece entre “tenho uma ideia ou um problema” e “o software está funcionando em produção” —, mas não descreve uma esteira rígida. Descobertas, testes e feedback podem exigir que o time volte a uma decisão anterior, refine o escopo ou reorganize prioridades.

Na Hit, o processo documentado reúne sete blocos: entendimento e diagnóstico; definição funcional e técnica; UX/UI e prototipação; desenvolvimento; QA e validação; publicação e operação; sustentação e evolução. O formato e a profundidade de cada bloco variam conforme o projeto. Segurança, dados, riscos e decisões do cliente atravessam todo o ciclo.

O processo não começa no código

Uma solicitação como “precisamos de um portal” ainda não define o problema, os usuários nem o que precisa mudar na operação. Antes de escolher telas, tecnologia ou cronograma, é necessário entender o processo atual, as regras, as exceções, os dados, as integrações, os riscos e o resultado esperado.

Isso não significa que o cliente precise chegar com o escopo completo. A Hit pode partir de processos, fluxos, protótipos, documentação parcial ou de uma demanda já estruturada. O ponto indispensável é haver uma necessidade clara e pessoas do negócio disponíveis para completar as definições em aberto.

Também existe uma decisão anterior ao projeto: construir é realmente o melhor caminho? Se essa dúvida ainda não foi resolvida, compare software sob medida, SaaS e software pronto antes de iniciar a execução.

Mapa do processo de software sob medida

O mapa abaixo reflete o processo público documentado da Hit. Os entregáveis são exemplos possíveis, não um pacote obrigatório para todos os projetos. Cada gate responde à pergunta que precisa estar suficientemente resolvida para o trabalho avançar com segurança.

1. Entendimento e diagnóstico. Saída: problema, contexto, usuários, riscos e lacunas organizados. Gate: vale investigar ou construir?
2. Definição funcional e técnica. Saída: requisitos, prioridades, arquitetura, responsabilidades e critérios de validação. Gate: existe base suficiente para planejar e estimar?
3. UX/UI e prototipação. Saída: jornadas, telas, estados, permissões e interações validados quando aplicável. Gate: os fluxos críticos estão compreendidos antes de codificar?
4. Desenvolvimento. Saída: incrementos funcionais de front-end, back-end, dados, regras e integrações. Gate: o incremento cumpre os critérios definidos e está pronto para validação?
5. QA, validação e homologação. Saída: cenários executados, evidências, bugs, correções, retestes e aceite de negócio. Gate: os riscos conhecidos permitem liberar?
6. Publicação e operação. Saída: ambientes, acessos, dados e versão de produção preparados conforme o plano. Gate: a operação está pronta e há resposta para falhas?
7. Sustentação e evolução. Saída: backlog priorizado, correções, monitoramento e melhorias. Gate contínuo: o que o uso real pede para o próximo ciclo?

O fluxo pode avançar em paralelo. Arquitetura e UX podem evoluir juntas; QA pode começar antes de todo o desenvolvimento terminar; uma homologação pode devolver um requisito para refinamento. O que não deve acontecer é avançar escondendo uma decisão crítica como se ela estivesse resolvida.

Etapas, entregáveis, participação do cliente e gates

1. Entendimento, briefing e diagnóstico

A primeira etapa esclarece por que o projeto existe. O time investiga quem usa o processo, como ele funciona hoje, onde surgem atrasos ou erros, quais regras não podem ser ignoradas, que dados circulam e quais sistemas precisam participar.

O briefing é uma entrada para essa conversa, não uma especificação definitiva. Um bom material ajuda a registrar objetivo, público, fluxos, referências, integrações, restrições e responsáveis. Ainda assim, perguntas surgem durante o diagnóstico. Quando P29 estiver publicado, P27 receberá um link para o template sem transformar esta etapa em formulário.

Gate: existe um problema relevante, um resultado esperado e acesso a quem conhece o processo? Se não, iniciar desenvolvimento apenas transforma suposições em código.

2. Definição funcional, arquitetura, escopo e estimativa

Depois do diagnóstico, a equipe organiza requisitos e prioridades, avalia arquitetura, dados, autenticação, integrações, infraestrutura, riscos e critérios de validação. O objetivo não é documentar tudo em detalhe infinito; é retirar ambiguidade suficiente para planejar a próxima decisão.

Essa etapa pode gerar um escopo inicial, backlog priorizado, mapa de integrações, responsabilidades, premissas, exclusões e critérios de aceite. O formato depende do tipo e da maturidade do projeto.

É aqui que uma estimativa ganha base. Na Hit, ela considera escopo, regras de negócio, usuários, integrações, dados, requisitos de segurança, infraestrutura, QA e o nível de definição atual. Uma avaliação inicial pode ser refinada após diagnóstico e detalhamento técnico. Para entender esses fatores, consulte quanto custa desenvolver um software sob medida.

Gate: as prioridades, dependências e incertezas estão visíveis o bastante para estimar e planejar? Se uma informação crítica continua ausente, a saída responsável pode ser mais investigação — não falsa precisão.

3. UX/UI e prototipação quando fazem sentido

UX/UI não é apenas escolher cores. Em software operacional, a etapa precisa representar jornadas, estados, permissões, erros, exceções e decisões que uma pessoa encontrará ao executar o processo.

Na Hit, UX/UI e prototipação podem estruturar jornadas, telas, estados, permissões e interações para validação progressiva. Nem todo projeto exige o mesmo nível de protótipo. Uma integração sem interface e um portal usado diariamente possuem necessidades diferentes.

Gate: usuários e responsáveis entendem como os fluxos críticos deverão funcionar? Aprovar somente a aparência, sem validar regras e estados, adia problemas para a fase mais cara de corrigir.

4. Desenvolvimento em incrementos verificáveis

Com decisões suficientes, o time constrói front-end, back-end, dados, autenticação, regras de negócio e integrações conforme a arquitetura definida. Em vez de esperar que tudo fique pronto para mostrar, o trabalho pode ser dividido em incrementos que permitam feedback e teste.

Iteração não significa escopo sem controle. Uma solicitação nova precisa ser tratada como decisão: qual problema resolve, que prioridade possui, o que desloca, que dependências cria e como afeta esforço, risco e aceite. Algumas mudanças entram no ciclo atual; outras vão para o backlog ou exigem reestimativa.

A prática de mudanças menores e reversíveis reduz o impacto de uma falha e facilita a recuperação, segundo o AWS Well-Architected Framework. Isso é uma referência geral de engenharia, não uma promessa de que toda entrega usa o mesmo pipeline.

Gate: o incremento cumpre os critérios acordados, possui dependências conhecidas e está pronto para validação?

5. QA, validação e homologação não são a mesma coisa

QA verifica o comportamento do software contra critérios e cenários: fluxos, regras, permissões, integrações, responsividade e outros aspectos previstos no escopo. Na Hit, o processo pode incluir entendimento do que será validado, plano ou checklist, execução, registro de bugs com evidências, correções, retestes e apoio à homologação.

Homologação confirma se a solução atende ao processo e aos critérios de negócio. O parceiro ajuda a preparar ambiente, dados, roteiro e evidências; o cliente precisa envolver pessoas capazes de testar casos representativos e decidir o aceite. Um fluxo pode passar no teste técnico e ainda falhar em uma regra operacional que apenas o negócio conhece.

Testar cedo e repetir ao longo do ciclo evita concentrar descobertas no fim. O Azure Well-Architected Framework recomenda começar os testes nas primeiras fases e integrar QA ao processo de desenvolvimento.

Gate: os critérios de liberação foram atendidos? Pendências e riscos residuais possuem responsável e decisão explícita? Sem isso, “aprovado” vira uma percepção, não uma condição verificável.

6. Implantação, go-live e início da operação

Implantar não é apenas copiar código para produção. Conforme o projeto, a preparação pode envolver ambientes, acessos, configurações, dados, integrações, treinamento, comunicação, monitoramento e uma janela de mudança.

O plano também precisa responder quem acompanha o go-live, como um problema será detectado, quais decisões podem ser revertidas e quem comunica usuários. Mudanças pequenas e controladas, quando a arquitetura permite, reduzem o alcance de uma falha.

Na Hit, a etapa pública de “Publicação e operação” inclui preparar ambientes, acessos, dados, monitoramento e entrada em produção de acordo com o plano do projeto. Os itens concretos dependem do escopo; não existe um checklist único aplicável a qualquer sistema.

Gate: a versão foi validada no ambiente correto, a operação está pronta e existem responsáveis para acompanhar o início do uso?

7. O projeto não termina no go-live

Produção revela padrões que nenhum ambiente de teste reproduz por completo: comportamento real dos usuários, volume, exceções, pontos de suporte e novas prioridades. Por isso, monitoramento e evolução precisam ser considerados antes do lançamento, mesmo que sejam contratados ou operados de formas diferentes.

A Hit pode continuar com suporte, correções, monitoramento, melhorias, novas funcionalidades e evolução técnica. Em sustentação, o cliente prioriza o backlog, e a execução segue o escopo e a capacidade contratados.

Monitoramento não é apenas receber alertas. A orientação do Azure Well-Architected Framework trata essa capacidade como parte da arquitetura, conectando telemetria ao estado do sistema e aos resultados operacionais.

Gate contínuo: o que precisa ser corrigido, medido, melhorado ou priorizado no próximo ciclo?

Quem participa de um projeto de software sob medida

Os papéis variam, mas quatro responsabilidades precisam existir:

• Responsável de negócio: explica regras, decide prioridades e aceita resultados.
• Usuários ou representantes: mostram o trabalho real, inclusive exceções, e validam usabilidade.
• Parceiro de produto e tecnologia: transforma contexto em alternativas, arquitetura, experiência, software e evidências de qualidade.
• Responsável por operação: prepara acessos, dados, suporte, monitoramento e continuidade depois do lançamento.

Uma pessoa pode acumular papéis; o problema é deixar uma responsabilidade sem dono. O cliente não precisa acompanhar cada decisão técnica, mas precisa estar disponível quando a escolha muda regra, prioridade, risco ou aceite.

Quanto tempo leva para desenvolver um software?

Sem diagnóstico, qualquer prazo total seria uma suposição. O tempo muda com amplitude do escopo, quantidade de fluxos e perfis, integrações, migração de dados, requisitos de segurança, disponibilidade dos decisores, velocidade de homologação e capacidade de dividir a entrega.

Também existe relação direta entre decisão e espera. Quando regras ficam sem responsável, acessos não chegam ou a homologação usa dados pouco representativos, o projeto pode parar mesmo com a equipe de desenvolvimento disponível.

Uma estimativa responsável deve declarar premissas, dependências e o que ainda não foi confirmado. Quanto maior a incerteza, mais útil é estimar uma fase de diagnóstico ou um primeiro recorte verificável em vez de prometer o sistema completo.

Cinco falhas de processo que geram retrabalho

1. Começar pela solução. A equipe recebe uma lista de telas, mas ninguém confirmou o problema e o resultado. Prevenção: definir contexto, usuários e critério de sucesso.
2. Tratar aprovação visual como aceite funcional. O protótipo parece correto, porém regras e exceções continuam vagas. Prevenção: revisar estados, dados, permissões e casos críticos.
3. Esconder mudanças no fluxo normal. Novos requisitos entram sem decisão de impacto. Prevenção: registrar prioridade, dependências, efeito no escopo e responsável.
4. Deixar QA e homologação para o fim. Problemas de requisito aparecem quando há mais trabalho pronto para refazer. Prevenção: testar incrementos e preparar cenários antes da reta final.
5. Planejar o lançamento sem operação. Há código em produção, mas faltam responsáveis, monitoramento, suporte ou backlog. Prevenção: tratar go-live como início de uma fase, não encerramento administrativo.

Exemplo hipotético: um portal de pedidos percorrendo o ciclo

Considere uma distribuidora que recebe pedidos por e-mail e planilha. Este é um cenário fictício, não um case da Hit.

1. No diagnóstico, a equipe descobre que o problema central não é digitar pedidos, mas validar limite, preço, estoque e aprovação entre áreas.
2. Na definição, registra regras, perfis, integrações com ERP, prioridades e critérios de aceite. A primeira versão cobre pedido e aprovação; relatórios avançados ficam no backlog.
3. Em UX/UI, compradores e aprovadores validam o fluxo, inclusive recusa, correção e falta de estoque.
4. No desenvolvimento, o portal e a integração são construídos em incrementos testáveis.
5. Em QA, os times executam cenários de permissão, regra e falha de integração. Na homologação, o cliente usa pedidos representativos e aprova o processo.
6. No go-live, acessos, dados, comunicação, suporte e acompanhamento inicial são preparados.
7. Com o uso real, o backlog passa a incluir alertas, relatórios e melhorias de integração.

O exemplo mostra por que “construir um portal” não é escopo suficiente. A solução só ganha forma quando decisões, entregáveis e gates tornam o processo observável.

Como chegar preparado para a primeira conversa

Você não precisa levar um documento perfeito. Reúna o que já existe e deixe as lacunas visíveis:

• problema e resultado esperado;
• quem usa e quem decide;
• como o processo funciona hoje;
• regras e exceções críticas;
• sistemas, dados e integrações envolvidos;
• restrições de prazo, segurança ou operação;
• referências e documentos disponíveis;
• como o resultado poderá ser aceito.

O briefing futuro de P29 aprofundará esses campos em um ativo próprio. Aqui, a função da lista é mostrar o que alimenta o diagnóstico — não substituir a conversa nem fechar o escopo antes da investigação.

Perguntas frequentes

Preciso ter o escopo pronto para procurar uma empresa de software?

Não. É possível começar com uma necessidade operacional clara, documentação parcial e pessoas disponíveis para explicar o processo. O diagnóstico existe justamente para transformar informação dispersa em decisões e lacunas explícitas.

UX vem sempre antes do desenvolvimento?

Não como regra rígida. Fluxos e interações críticas precisam ser compreendidos antes da implementação correspondente, mas UX, arquitetura e desenvolvimento podem se sobrepor conforme o projeto. Uma integração sem interface também exige outro tipo de trabalho.

Quem aprova a homologação?

O cliente precisa indicar quem possui autoridade e conhecimento do processo para aceitar o resultado de negócio. O parceiro prepara ambientes, cenários e evidências e corrige problemas conforme o fluxo acordado. QA técnico e aceite de negócio são complementares.

O projeto acaba quando o software entra no ar?

Não necessariamente. Go-live inicia a operação real. Correções, monitoramento, suporte, novas necessidades e evolução podem continuar em sustentação, projeto por fases ou outro formato definido entre as partes.

Do problema à evolução

Um processo confiável não elimina incerteza; ele torna a incerteza visível e cria decisões proporcionais a ela. Antes de avançar, pergunte o que saiu da etapa, quem aprovou e o que ainda pode bloquear a próxima.

Conheça a capacidade da Hit em software sob medida. A página apresenta os cenários em que uma solução própria pode fazer sentido e os caminhos para discutir o projeto.

Fontes consultadas

• Hit Digital. Softwares sob medida. Processo e capacidades públicas consultados em 19 ago. 2026. Página institucional.
• Government Digital Service. How the discovery phase works. Atualizado em 21 jun. 2021; consultado em 19 ago. 2026. GOV.UK Service Manual.
• IBM. What is the software development lifecycle?. Consultado em 19 ago. 2026. IBM Think.
• National Institute of Standards and Technology. Secure Software Development Framework (SSDF) Version 1.1. Consultado em 19 ago. 2026. NIST CSRC.
• Microsoft. Architecture strategies for testing. Atualizado em 31 mar. 2026; consultado em 19 ago. 2026. Azure Well-Architected Framework.
• Microsoft. How to build a monitoring system for Azure workloads. Consultado em 19 ago. 2026. Azure Well-Architected Framework.
• Amazon Web Services. Make frequent, small, reversible changes. Consultado em 19 ago. 2026. AWS Well-Architected Framework.