Quanto cobrar por um sistema (e outras perguntas que todo programador tem)

Esse post responde cinco perguntas práticas sobre a vida de programador. Design, segurança, precificação e planejamento de sistemas. Vamos direto ao ponto.

Dá para ser bom em design e em programação ao mesmo tempo?

Dá. Não é mito, não é exceção. Conheço várias pessoas que são boas nas duas coisas e isso derruba aquela ideia de que programador não tem senso estético ou que designer não consegue pensar em lógica.

A questão é simples: o que você estuda e pratica, você fica bom. Design é uma habilidade como qualquer outra. Você pode passar um período focado em programação, ficar bom nisso, depois dedicar um tempo ao design, ficar bom nisso também. E aí você une as duas coisas.

É verdade que quem gosta mais de lógica e resolução de problemas tende a dar menos atenção para a parte visual. Acontece. Mas isso é preferência, não limitação. Não existe uma regra biológica que diz que programador não pode aprender design. Esqueça esse mito.

Vale a pena estudar segurança?

Vale. Estudar segurança como programador abre a mente de um jeito que poucos assuntos conseguem. Você entende como sistemas são atacados e, com isso, você consegue construir sistemas mais difíceis de atacar.

Tem uma categoria de ataque que vem de dentro, pelo próprio sistema: arquivos enviados onde não deveriam, registros inseridos de formas que não deveriam, acessos concedidos a quem não deveria ter. Conhecendo esses vetores, você cria validações, filtros e permissões no lugar certo.

Tem outra categoria que vem de fora: brechas no servidor, hospedagens compartilhadas mal configuradas onde um cliente compromete os demais. Já vi isso acontecer com sites que eu mesmo coloquei em hospedagem compartilhada. Um cliente da mesma máquina teve problema e arrastou os outros junto. Para esse tipo de situação, a solução passa por usar servidores dedicados ou hospedagens confiáveis.

Só tem um cuidado a tomar ao estudar segurança: cuidado para não entrar em modo paranoia. Quando você mergulha nesse universo você se depara com técnicas, ferramentas e cenários que podem fazer você querer usar VPN em tudo, navegar só em modo anônimo, acessar a internet só via VPS e por aí vai. Isso é paranoia, não segurança. Estude o assunto com calma e com foco em proteger o que você constrói.

O que é a caixa de ferramentas do programador?

Literalmente o que o nome diz. Uma caixa com ferramentas reutilizáveis para resolver problemas recorrentes.

Um programador experiente percebe que certos problemas aparecem em todo projeto: sistema de login, galeria de fotos, painel de configurações, envio de e-mail, integração com pagamento. Em vez de recriar tudo do zero toda vez, ele mantém versões funcionais dessas soluções e reutiliza quando o próximo projeto precisa.

O trabalho que sobra é só a personalização para aquele cliente ou contexto específico. Com o tempo, a sua caixa de ferramentas vai crescendo, os projetos ficam mais rápidos e o retrabalho cai muito.

Quanto cobrar por um sistema?

Essa é uma pergunta que daria um curso inteiro. Mas existe um conceito central que precisa estar na cabeça de todo programador antes de qualquer cálculo: a diferença entre valor real e valor intrínseco.

Valor real é o custo de fazer aquele sistema. Suas horas, seu tempo de desenvolvimento, os custos operacionais. Existe um cálculo para isso e ele é relativamente direto.

Valor intrínseco é o quanto aquele sistema vale para o cliente. O quanto ele vai gerar de retorno, direto ou indireto.

Pense assim: um sistema de estoque e uma loja virtual podem ter o mesmo custo de desenvolvimento para você. Mesmo esforço, mesmo tempo, mesmo valor real. Mas o valor intrínseco é completamente diferente.

O sistema de estoque ajuda o cliente a organizar melhor os produtos, reduzir perdas, economizar tempo. Ótimo, mas o retorno é indireto. A loja virtual é a empresa do cliente. Ela gera faturamento direto todo dia. Em muitos casos é o negócio inteiro do cliente rodando em cima daquele sistema.

Esse valor intrínseco diferente faz com que dois projetos com o mesmo custo de R$ 2.000 possam ter preços finais completamente diferentes. A loja pode chegar em R$ 10.000, R$ 50.000 ou mais dependendo do porte do negócio e do retorno esperado. Não porque é mais difícil de fazer, mas porque vale mais para quem contrata.

Precificar sem pensar no valor intrínseco é deixar dinheiro na mesa. Pensar só no valor intrínseco sem calcular o custo real é trabalhar no prejuízo. Os dois precisam entrar na conta.

Qual o primeiro passo para criar um sistema?

Não é digitar código. Digitar código é o quarto passo.

Antes de escrever qualquer linha, existem três etapas que definem se o projeto vai ser construído de forma sólida ou vai virar um ciclo de retrabalho.

Passo 1: levantamento de requisitos. O que o sistema precisa ter? Como cada funcionalidade vai funcionar? Quem vai usar? Isso envolve entrevistas com o cliente, anotações, discussões. Nenhuma linha de código aqui.

Passo 2: desenho do sistema. Com os requisitos na mão, você desenha as telas. Pode ser no papel, pode ser em software de wireframe. O objetivo é visualizar como o sistema vai funcionar antes de construir qualquer coisa. Esse rascunho vai para aprovação do cliente antes de avançar.

Passo 3: planejamento de dados. Se o sistema usa banco de dados, você define a estrutura agora. Diagrama de banco de dados, diagrama de casos de uso, o que for necessário para ter clareza sobre como os dados vão se relacionar.

Passo 4: código. Agora sim você abre o editor e começa a construir.

Pular direto para o código causa dois problemas clássicos. Primeiro: retrabalho. Você cria funcionalidades sem ter pensado como elas se conectam, avança setenta por cento do projeto e descobre que duas peças importantes não funcionam juntas. Você apaga tudo e recomeça. Segundo: travamento. Uma tela em branco sem planejamento nenhum é paralisante. Não sai nada. Tendo uma estrutura mesmo que básica, você tem por onde começar e avançar com mais velocidade.

Planejamento não atrasa o projeto. Planejamento é o que evita que você precise refazer o projeto no meio do caminho.