Desenvolvimento de software é o trabalho de transformar uma necessidade de negócio em um sistema que gente usa todo dia. Escrever código é uma parte dele, e não a maior: a maior parte do esforço está em decidir o que construir, em que ordem, e como saber se funcionou.
Este texto mostra as etapas do processo e o que cada uma produz, por que a estimativa escorrega, como distinguir um processo saudável de um teatro de processo, e o que muda depois que o software entra em uso.
As etapas e o que cada uma produz
| Etapa | O trabalho | O que precisa existir no fim |
|---|---|---|
| Descoberta | entender o problema com quem vive ele, e o custo de não resolver | o problema escrito em uma frase, com um número ao lado |
| Recorte | decidir o que entra na primeira versão e o que fica de fora | uma lista curta do que será feito e uma longa do que não será |
| Desenho | fluxo de uso, telas e as decisões técnicas de base | o caminho que a pessoa percorre, navegável antes de existir |
| Construção | escrever, revisar e testar em ciclos curtos | algo funcionando toda semana, ainda que incompleto |
| Entrada em uso | migração de dado, treino de quem usa, acompanhamento | gente usando de verdade, com suporte combinado |
| Evolução | corrigir, medir e melhorar com base em uso real | uma rotina de manutenção precificada |
As duas primeiras etapas decidem mais do resultado que todas as outras somadas, e são as que costumam ser atropeladas por pressa. O método de recorte está em como definir o escopo do primeiro produto digital, e a lógica da primeira versão em o que é MVP de produto digital.
Por que a estimativa escorrega
- O pedido muda quando a pessoa vê a tela. Isso não é falha: é a forma como requisito se descobre. Processo que não prevê essa mudança apenas empurra a surpresa para o fim.
- A integração é sempre pior que o previsto, porque depende de sistema de terceiro, documentação desatualizada e acesso que demora a chegar.
- Dado antigo vem sujo. Migração é a etapa mais subestimada de qualquer projeto que substitui um sistema existente.
- O caso de exceção multiplica. A regra principal leva um dia; as sete exceções que a empresa tem levam duas semanas.
- Aprovação demora, e o cronograma foi feito assumindo resposta no mesmo dia.
A resposta a isso não é estimar melhor, é estimar em faixa e reduzir o tamanho do lote: quanto menor o pedaço entregue por vez, menor o erro acumulado. As faixas por tipo de projeto estão em quanto custa desenvolver um produto digital.
Processo saudável e teatro de processo
| Saudável | Teatro |
|---|---|
| algo navegável para ver toda semana | relatório de percentual concluído |
| uma pessoa decide prioridade | comitê aprova, e ninguém remove nada |
| a lista do que ficou de fora é explícita | “tudo será feito na próxima fase” |
| estimativa em faixa, revisada quando muda | número cravado, revisado no fim |
| teste automatizado no que é crítico | teste manual na véspera |
| critério de sucesso escrito no começo | avaliação por sensação na entrega |
Nenhuma metodologia garante a coluna da esquerda. O que garante é ter alguém do lado do cliente disponível toda semana para decidir, e é justamente esse recurso que quase nenhum projeto reserva. As práticas de ciclo curto estão em Scrum na prática.
Cascata, ágil e o que se usa de verdade
A discussão entre modelos de processo rende menos do que parece, porque quase nenhuma empresa segue um deles à risca:
- Cascata faz cada etapa até o fim antes de começar a seguinte. Funciona quando o requisito é estável e a mudança é caríssima, como em sistema embarcado e obra regulada. Em software de negócio, garante descobrir o erro no fim.
- Iterativo e ágil repete o ciclo inteiro em pedaços pequenos, com entrega frequente e mudança prevista. É o que rende na maior parte dos projetos de empresa, e depende de disponibilidade do cliente para decidir a cada ciclo.
- Contínuo vai além, publicando várias vezes por semana. Exige teste automatizado maduro e é o modelo de quem opera produto próprio, não de quem entrega projeto fechado.
Na prática, a maioria dos projetos bons é híbrida: recorte e desenho com alguma antecipação, construção em ciclos curtos, e uma data de entrada em uso combinada. O que decide o resultado não é o nome do modelo, é o tamanho do lote entregue por vez e a frequência com que alguém de fora olha o que foi feito.
O que sustenta a qualidade
- Teste automatizado no que dói, começando por cálculo de dinheiro, permissão de acesso e integração. Cobrir tudo é desperdício; cobrir o crítico é o que permite mudar sem medo.
- Revisão de código por outra pessoa, que é o controle mais barato que existe e o primeiro a ser cortado sob pressão.
- Ambiente de teste separado do que está no ar, com dado parecido e sem dado real de cliente.
- Publicação frequente e pequena. Entrega grande concentra risco; entrega pequena permite voltar atrás em minutos.
- Registro e alerta, para descobrir o erro antes do usuário ligar.
- Acessibilidade tratada no componente, e não cobrada tela por tela, como está em acessibilidade em projetos digitais.
O que acontece depois de entrar em uso
A conta que surpreende quem contrata pela primeira vez: a maior parte do custo de um software acontece depois da entrega. Correção, mudança de regra do negócio, atualização de dependência, novo requisito legal e suporte a quem usa somam mais, ao longo dos anos, que a construção inicial.
Por isso manutenção precisa estar precificada no mesmo documento da construção, com prazo de resposta por gravidade. Contrato que só cobre construção não é mais barato: é um contrato que ainda não mostrou metade do custo. Quem assume esse papel depois da entrega está descrito em software house: o que faz e quando contratar. Trazer time de fora para essa continuidade tem quatro formatos possíveis, com preço e risco bem diferentes, comparados em terceirização de TI: os 4 modelos e como escolher.
Quem faz o quê
- Quem decide pelo negócio. Uma pessoa, com autoridade para priorizar e dizer não. É o papel mais importante e o menos preenchido.
- Quem desenha o uso, respondendo pelo caminho que a pessoa percorre.
- Quem constrói, respondendo por funcionar e por continuar funcionando.
- Quem testa, que em time pequeno é a própria pessoa que construiu, com apoio de teste automatizado.
- Quem opera, cuidando de ambiente, publicação, cópia de segurança e monitoramento.
Em projeto pequeno, duas ou três pessoas acumulam esses papéis, e isso funciona. O que não funciona é o primeiro papel ficar vago: sem alguém decidindo prioridade, a fila é preenchida por quem grita mais alto. A escolha das tecnologias envolvidas é uma decisão bem menos determinante do que parece, e o panorama está em linguagens de programação.
Os erros que mais custam
- Especificar tudo antes de qualquer uso real, o que garante construir o que foi imaginado em vez do que era necessário.
- Substituir um sistema inteiro de uma vez, quando trocar por partes teria permitido aprender no caminho.
- Deixar a migração de dado para o fim.
- Tratar treino de usuário como detalhe, e descobrir na virada que ninguém sabe usar.
- Não escrever o critério de sucesso, o que faz um projeto entregue ser considerado fracasso e vice-versa.
- Cortar teste e revisão para ganhar prazo, antecipando duas semanas e pagando dois meses depois.
Desenvolvimento de software dá certo quando o problema está claro, o pedaço entregue por vez é pequeno e existe alguém disponível para decidir. Nenhuma das três condições é técnica, e é por isso que projeto bem tocado se parece mais com gestão de decisão que com programação.
Perguntas frequentes
Quais são as etapas do desenvolvimento de software?
Seis: descoberta, entendendo o problema com quem vive ele e o custo de não resolver; recorte, decidindo o que entra na primeira versão; desenho, com fluxo de uso e decisões técnicas de base; construção, em ciclos curtos com algo funcionando toda semana; entrada em uso, com migração de dado e treino de quem usa; e evolução, com manutenção precificada. As duas primeiras decidem mais do resultado que todas as outras somadas.
O que é desenvolvimento de software?
É o trabalho de transformar uma necessidade de negócio em um sistema que gente usa todo dia. Escrever código é uma parte dele, e não a maior: a maior parte do esforço está em decidir o que construir, em que ordem, e como saber se funcionou. Por isso projeto bem tocado se parece mais com gestão de decisão do que com programação.
Por que os prazos de software sempre estouram?
Porque o pedido muda quando a pessoa vê a tela, e isso é como requisito se descobre. Porque integração com sistema de terceiro é sempre pior que o previsto. Porque dado antigo vem sujo e migração é a etapa mais subestimada. Porque a regra principal leva um dia e as sete exceções da empresa levam duas semanas. E porque o cronograma assumiu aprovação no mesmo dia.
Como reduzir o erro de estimativa?
Não estimando melhor, e sim reduzindo o tamanho do lote: quanto menor o pedaço entregue por vez, menor o erro acumulado. Além disso, estimar em faixa em vez de número cravado, e revisar a faixa na semana em que a informação muda, e não no fim do prazo. Número cravado na primeira reunião é sinal ruim, não sinal de confiança.
Como saber se o processo de desenvolvimento é saudável?
Processo saudável tem algo navegável para ver toda semana, uma pessoa decidindo prioridade, uma lista explícita do que ficou de fora, estimativa em faixa revisada quando muda, teste automatizado no que é crítico e critério de sucesso escrito no começo. Teatro de processo tem relatório de percentual concluído, aprovação por comitê, promessa de tudo na próxima fase e avaliação por sensação na entrega.
Cascata ou ágil: qual modelo usar?
Cascata funciona quando o requisito é estável e a mudança é caríssima, como em sistema embarcado; em software de negócio, garante descobrir o erro no fim. Iterativo e ágil rende na maior parte dos projetos de empresa, e depende de disponibilidade do cliente para decidir a cada ciclo. Na prática, os projetos bons são híbridos, e o que decide o resultado é o tamanho do lote entregue por vez.
O que sustenta a qualidade de um software?
Teste automatizado no que dói, começando por cálculo de dinheiro, permissão de acesso e integração, porque cobrir tudo é desperdício e cobrir o crítico permite mudar sem medo. Revisão de código por outra pessoa, o controle mais barato e o primeiro cortado sob pressão. Ambiente de teste separado, sem dado real de cliente. Publicação frequente e pequena. Registro e alerta. E acessibilidade tratada no componente.
Quanto custa manter um software depois da entrega?
A maior parte do custo total acontece depois da entrega. Correção, mudança de regra do negócio, atualização de dependência, novo requisito legal e suporte a quem usa somam mais, ao longo dos anos, que a construção inicial. Por isso manutenção precisa estar precificada no mesmo documento, com prazo de resposta por gravidade: contrato que só cobre construção não é mais barato, é um contrato que ainda não mostrou metade do custo.
Quais papéis são necessários em um projeto de software?
Quem decide pelo negócio, uma pessoa com autoridade para priorizar e dizer não, que é o papel mais importante e o menos preenchido. Quem desenha o uso. Quem constrói, respondendo por funcionar e continuar funcionando. Quem testa, que em time pequeno é quem construiu, com apoio de teste automatizado. E quem opera ambiente, publicação, cópia de segurança e monitoramento. Em projeto pequeno, duas ou três pessoas acumulam esses papéis.
Quais os erros que mais custam em um projeto de software?
Especificar tudo antes de qualquer uso real, o que garante construir o que foi imaginado em vez do necessário. Substituir um sistema inteiro de uma vez em lugar de trocar por partes. Deixar a migração de dado para o fim. Tratar treino de usuário como detalhe. Não escrever o critério de sucesso. E cortar teste e revisão para ganhar prazo, antecipando duas semanas e pagando dois meses depois.
