“Isso leva só um instante”
Quem trabalha na criação ou manutenção de um site, aplicação ou sistema conhece essa frase.
“Podem só mudar esse botão?”
“É mesmo uma correção pequena.”
“Por favor, só movam esse elemento.”
“Isso dá para fazer rápido?”
“Deve ser cinco minutos de trabalho, né?”
E às vezes realmente é.
Às vezes mudar a cor de um botão leva alguns minutos. Às vezes corrigir um erro de digitação exige um clique. Às vezes o desenvolvedor abre o código, olha, altera uma linha e pronto.
O problema é que nem toda alteração que parece pequena do ponto de vista do usuário é pequena do ponto de vista do sistema.
E um problema ainda maior surge quando há várias dessas “pequenas alterações”: dezenas, dezenas ou centenas por mês. Aí começa a acontecer algo interessante.
A empresa pode ter a impressão de que praticamente não está solicitando nada grande. Ao mesmo tempo, a equipe de TI passa uma parte significativa do tempo realizando exatamente essas pequenas tarefas.
E aqui surge a pergunta: Quanto custa realmente um botão “Corrijam isso rápido”?
Comecemos por um exemplo simples
Imagine que o departamento de marketing envia para a software house a mensagem:
“Ei, precisamos só trocar o texto do botão. Em vez de “Ver oferta” deveria ser “Conheça a oferta”. É uma coisinha, por favor façam rápido.”
Parece banal. Mas do ponto de vista técnico pode ser muito diferente.
O desenvolvedor precisa:
1. Analisar o pedido
Onde está esse botão?
Está só num lugar?
Aparece em várias versões da página?
O texto está escrito diretamente no código?
É gerenciado por um CMS?
A alteração afetará a versão desktop e mobile?
O botão faz parte de um componente usado em outros lugares?
2. Implementar a mudança
Mudar o texto.
Refatorar o componente.
Atualizar o conteúdo no CMS.
Ou modificar o código.
3. Verificar o resultado
O botão ainda parece correto?
O texto não ultrapassa sua área?
No celular tudo funciona?
A alteração não afetou outros lugares?
4. Testar
É possível clicar?
O link leva para onde deve?
Não surgiu nenhum erro?
5. Fazer o deploy
Se a alteração requer deploy, é preciso colocá-la no ambiente de produção.
E de repente percebe-se que: “Só mudar o texto”
não necessariamente significa: “Só 5 minutos de trabalho”.
Quanto pode custar uma pequena alteração?
Vamos assumir um cenário muito conservador.
O desenvolvedor dedica:
- 15 minutos para a análise,
- 20 minutos para a implementação,
- 15 minutos para os testes,
- 10 minutos para preparação e deploy.
Total: 60 minutos de trabalho.
E aqui chegamos a um ponto importante. Se a taxa horária da equipe for, por exemplo, 200 zł líquidos, uma alteração aparentemente pequena custa cerca de: 200 zł líquidos.
Mas ainda não acabou. No processo real podem aparecer:
- transferência da tarefa,
- especificação do escopo,
- perguntas ao cliente,
- espera por resposta,
- verificação do resultado pela pessoa que reportou,
- correção após feedback,
- re-deploy.
Uma hora pode facilmente se transformar em duas. E uma pequena alteração pode virar várias horas de trabalho de toda a equipe.
O mais caro nem sempre é executar a mudança
Isso pode parecer paradoxal. Às vezes a execução em si leva 10 minutos. Mas preparar-se para ela leva mais 20. Depois vêm os testes, o deploy, a comunicação e o custo de troca de contexto.
E justamente esse último ponto costuma ser o mais subestimado.
Troca de contexto - o custo oculto das pequenas tarefas
O desenvolvedor está trabalhando numa funcionalidade grande. Tem o código aberto. Está concentrado.
De repente chega a mensagem: “Ei, é só uma coisinha. Pode corrigir o botão?”
O desenvolvedor interrompe o trabalho. Abre o chamado. Checa a página. Procura o lugar no código. Implementa a mudança. Testa. Faz o deploy. Volta à tarefa anterior...
E então precisa se lembrar: “Em que eu estava mesmo?”
Isso é exatamente o context switching, ou troca de contexto. E pode ser muito custoso. Não porque cada mudança isolada exija muita mão de obra, mas porque cada interrupção quebra o processo mental.
Quanto mais complexa a tarefa, maior o custo para voltar a ela. Por isso 10 micro-tarefas nem sempre significam 10 × 10 minutos. Na prática, pode significar muito mais.
Um botão é nada. Cem botões já são um processo.
Suponha que a empresa envie para a equipe técnica:
- 20 pequenas alterações por mês,
- cada uma leva em média 45 minutos.
Isso dá: 15 horas de trabalho por mês.
Com taxa de 200 zł líquidos: 3000 zł líquidos por mês.
Por ano: 36.000 zł líquidos.
E estamos falando apenas de 20 pequenas tarefas por mês. Sem grandes funcionalidades. Sem desenvolvimento de produto. Sem novos módulos. Sem integrações. Sem design.
Apenas: “mudem”, “corrijam”, “movam”, “adicionem”, “removam”.
Agora imagine uma organização onde esses pedidos são 50 por mês. Ou 100.
A escala começa a parecer totalmente diferente...
Micro-tarefas têm outro custo: bloqueiam o desenvolvimento
Este é um dos elementos mais importantes de todo o quebra-cabeça.
Se a equipe de desenvolvimento passa 20% do tempo em pequenas correções, não pode dedicar esses 20% ao desenvolvimento do produto. Parece óbvio. Mas na prática muitas vezes não é visível.
A empresa pergunta: “Por que a nova funcionalidade ainda não está pronta?”
O desenvolvedor responde: “Porque tivemos muitos assuntos correntes.”
“Quais?”
“Correções, pequenas mudanças, atualizações, micro-tarefas.”
Cada uma foi pequena. Mas juntas criaram um grande bloqueio. É um pouco como notificações no telefone. Uma notificação não atrapalha. Dez já incomodam. Cem?... De repente passamos o dia inteiro reagindo.
Com micro-tarefas é parecido.
“Pequena tarefa” nem sempre é uma tarefa pequena
Também vale entender que nem toda alteração é igual. Mudar um texto no CMS pode realmente levar alguns minutos.
Mas mudar um texto na aplicação pode exigir:
- encontrar o componente,
- alterar o código,
- atualizar traduções,
- testes,
- reconstruir a aplicação,
- deploy.
Mudar um campo pode exigir modificações no:
- front-end,
- back-end,
- banco de dados,
- API.
A alteração de um elemento no sistema pode impactar outros elementos.
Por isso a pergunta: “Quanto tempo leva mudar esse botão?”
sem conhecer a arquitetura do sistema muitas vezes não tem resposta sensata.
Primeiro é preciso verificar. Só depois é possível estimar.
Por que o desenvolvedor às vezes diz: “Preciso verificar”?
Não é para evitar responder. Frequentemente é sinal de profissionalismo.
Um bom desenvolvedor não deveria prometer: “Claro, cinco minutos.”
se não sabe o que há por baixo.
Deveria dizer: “Vou checar onde esse elemento é usado e te aviso.”
Isso pode levar 10 minutos. Mas esses 10 minutos podem poupar várias horas de problemas. Porque a mudança mais cara nem sempre é a que leva uma hora.
A mais cara é a que:
- quebra outra funcionalidade,
- provoca um erro em produção,
- exige rollback urgente,
- gera novos chamados,
- exige intervenção de várias pessoas.
Por isso a análise antes da mudança é parte do trabalho, não perda de tempo.
Como o cliente pode reduzir os custos das micro-tarefas?
Não se trata de parar de solicitar pequenas mudanças. Pequenas mudanças são parte normal do desenvolvimento de produto. Trata-se de gerenciá-las bem.
1. Agrupe pequenas tarefas
Em vez de enviar:
“Mudem o botão.”
“Corrijam o título também.”
“Aproveitem e adicionem este link.”
“E também movam esse elemento.”
Melhor juntá-las num único pacote.
A equipe pode então fazer várias mudanças num único ciclo de trabalho.
Menos troca de contexto.
Menos comunicação.
Menos deploys.
Menor custo.
2. Defina prioridades
Nem tudo é urgente.
Se tudo tem o status:
URGENTE
então nada é realmente urgente.
Vale dividir as tarefas em:
- críticas,
- importantes,
- planejadas,
- cosméticas.
Assim a equipe consegue trabalhar com mais eficiência.
3. Pense se precisa mesmo de alteração no código
Se a empresa muda regularmente:
- textos,
- imagens,
- banners,
- links,
- comunicados,
o problema pode não ser a velocidade do desenvolvedor.
Pode ser a arquitetura.
Se cada alteração de conteúdo exige um programador, vale considerar um CMS ou painel administrativo.
Um sistema bem desenhado deve permitir que pessoas de negócio gerenciem aquilo que realmente não precisa da intervenção de um desenvolvedor.
Um bom sistema deve responder: quem deve executar esta mudança?
Essa é uma importante regra de design. Nem toda mudança deve ir para o desenvolvedor.
Se o marketing consegue autonomamente:
- mudar textos,
- substituir imagens,
- adicionar artigos,
- alterar a ordem de seções,
não faz sentido envolver um programador.
O desenvolvedor deve se ocupar daquilo que exige suas competências.
Ou seja, entre outras coisas:
- criar novas funcionalidades,
- desenvolver o sistema,
- integrações,
- otimização,
- segurança,
- arquitetura,
- resolver problemas técnicos.
Caso contrário a empresa começa a pagar a um programador por trabalho que um usuário do sistema poderia fazer.
É um pouco como contratar um mecânico para abastecer o carro. Ele sabe fazer, mas será que é realmente necessário?
Quando vale a pena dizer: “Façamos de outro modo”?
Se o mesmo pedido aparece regularmente, vale parar e perguntar:
Por que precisamos fazer isso manualmente cada vez?
Se toda semana pedimos a alteração do mesmo elemento, talvez devêssemos criar:
- uma configuração no CMS,
- uma opção de configuração,
- um painel administrativo,
- automatização,
- um mecanismo de self-service.
O custo único de criar essa solução pode ser maior. Mas depois cada alteração pode levar segundos em vez de horas.
Essa é a diferença entre Pagar por cada alteração e investir num sistema que permite realizar alterações de forma independente.
Micro-tarefas e o modelo de colaboração com a software house
Também é importante para os clientes.
Se a colaboração com a software house se baseia apenas no modelo: “vocês solicitam - nós orçamos - vocês aprovam - nós executamos”, cada pequena mudança pode gerar sobrecarga organizacional adicional.
Por isso, numa colaboração contínua costumam funcionar melhor:
- pacotes de horas,
- assinatura de manutenção,
- equipe dedicada,
- backlog de tarefas,
- sprints regulares,
- janelas de deploy estabelecidas.
Não significa que todo cliente deva escolher o mesmo modelo. Trata-se de ajustar a forma de trabalho ao caráter do projeto.
Se a empresa precisa de uma mudança por mês, um processo grande pode ser desnecessário. Se a empresa envia 50 pedidos por mês, a falta de processo pode ser muito custosa.
Vale a pena contabilizar cada alteração?
Depende.
Em alguns projetos é sensato contabilizar cada minuto. Em outros isso pode gerar mais administração do que economia.
Por isso é preciso olhar para a colaboração de forma ampla.
A questão mais importante não é: “Quanto custou essa mudança?”
A melhor pergunta é: “Quanto nos custa a maneira como gerenciamos todas as mudanças?”
Se a empresa paga 200 zł por uma mudança, mas evita erros e tem a garantia de que tudo funciona corretamente, pode ser um custo razoável.
Se, por outro lado, todo mês paga alguns milhares de zlotys por dezenas de micro-tarefas semelhantes, vale pensar se o problema não pode ser resolvido de forma sistêmica.
As palavras mais caras em TI?
Talvez sejam: “Isso é só uma pequena mudança.”
Não porque mudanças pequenas sejam ruins. Elas são necessárias.
Um produto digital vive. As necessidades dos clientes mudam. O mercado muda. O marketing muda. A tecnologia muda. Mudanças são naturais.
O problema é quando a organização não vê o custo acumulado.
Uma pequena mudança? - Nada demais.
Dez? - Ainda pouco.
Cem? - Isso já é um processo.
E se houver vários desses processos? De repente a empresa não investe em desenvolvimento de produto. Gasta em consertar pequenos detalhes o tempo todo.
Em vez de contar botões, vamos contar tempo
Um desenvolvimento de produto digital bem gerido não significa proibir o cliente de solicitar pequenas mudanças.
Significa saber:
- quais mudanças realmente exigem um programador,
- quais podem ser feitas internamente,
- quais valem a pena automatizar,
- quais devem ser agrupadas,
- quais são realmente urgentes,
- quais podem ser planejadas,
- quais vale a pena resolver sistematicamente.
Porque às vezes a melhor resposta a: “Corrijam isso rápido.”
não é: “Ok, faremos.”
mas: “Vamos refletir por que daqui a um mês teremos que corrigir isso de novo.”
É aí que a software house deixa de ser apenas um executor de tarefas e passa a ser um parceiro tecnológico. Um bom parceiro não só realiza os chamados.
Ajuda também a ver que, às vezes, a mudança mais barata não é aquela que faremos mais rápido. A mais barata é aquela que não precisaremos fazer pela centésima vez.
E por isso um botão “Corrijam isso rápido” pode custar uma hora.
Mas um sistema bem projetado pode fazer com que as próximas cem mudanças semelhantes sejam feitas por si próprio em alguns minutos.
Não se trata de economizar nos programadores. Trata-se de investir em um processo melhor, em uma arquitetura melhor e em um uso mais inteligente do tempo de toda a equipe.
