O que significa construir um software?
Bom, para responder essa pergunta, é necessário primeiro entender o básico — os first principles. Software é criado para resolver uma dor. Para isso, é preciso mapear o que precisa ser resolvido e desenhar uma possível solução. Muitos chamam isso, hoje, de produto.
Esse produto precisa ser utilizado por alguém, e será acessado por meio de alguma interface — pode ser o celular, o computador, uma Alexa ou qualquer outro dispositivo. Por isso, é preciso pensar nessa interface e desenhá-la com cuidado — entra aqui o design.
Com o design em mãos, é hora de criar o software. A programação entra como o centro de tudo — o produto final, tangível.
Essas competências não estão isoladas. Quando falamos em construir software, tudo precisa fluir em harmonia — tudo precisa conversar.
O super-homem sabe de tudo isso. Ele entende a dor que está sendo resolvida, sabe como o usuário vai interagir com o produto, sabe programar e colocar esse software no ar.
A departamentalização, por outro lado, transforma os profissionais em versões modernas do Charles Chaplin de Tempos Modernos: parafusando algo que nem sabem o que é. Como esperar que um bom software seja construído assim?
É fundamental entender toda a cadeia — principalmente o problema que está sendo resolvido.
Mas isso não é trivial de se alcançar. Cansei de brigar pelo protagonismo das pessoas engenheiras de software, para vê-las em reuniões de levantamento de hipóteses, caladas. Já desenhei estratégias para padronizar tecnologias, construir uma base de código com semântica e consistência — algo que caiba na cabeça das pessoas. E vi diretores jogarem tudo fora por conta de prazos.
Não existe bala de prata. Mas também não existe time de super-homens se não houver um esforço consciente e coletivo. Construir um bom software passa, antes de tudo, por ter boas pessoas. E isso é muito difícil.