Se você tem algum tipo de influência nas decisões arquiteturais de software program no native onde trabalha, e a empresa ou instituição não tem dinheiro infinito, aqui vão 10 insights e lições aprendidas da minha parte tendo tido alguma experiência nesta indústria important.
💰 O dinheiro não é infinito
Principalmente se a empresa está em early stage ou não tem muito investimento alavancado.
Qualquer decisão técnica precisa ser baseada nesta premissa, o que a torna mais importante do que as demais a seguir.
💻 Tecnologia deve acompanhar o negócio
É necessário saber quando dizer não, mas por outro lado, recusar tudo o que o negócio pede pode colocar o próprio negócio em risco.
Se coloque no lugar do interessado no produto de software program.
🌐 Arquitetura simples
Não importa o modelo, a necessidade, a escala e a promessa, sempre haverá uma forma mais simples e menos custosa de resolver o problema.
É teu papel sempre tentar garantir isto. Escolha stacks e arquiteturas simples, padronizadas e que facilitem onboarding.
🕸️ Complexidade sufoca o negócio
É muito mais fácil implementar algo complexo, quer a nível arquitetural ou em um determinado componente de software program. Geralmente buscamos o complexo de forma inconsciente para valorizar o ego e narrativa.
Mas ao longo do tempo, isto estrangula o negócio de tal forma que fica impossível tornar o complexo simples novamente, pelo que a empresa precisa de um golpe de sorte e entrada de dinheiro para contratar mais pessoas e manter a complexidade funcionando.
É difícil mas não é impossível fazer o simples. Muito provavelmente teu projeto não é tão especial assim pra justificar muita complexidade.
👶 Pequenos passos
Decisões ruins eventualmente acontecem, por isto é importante dividir as decisões e experimentos em pequenas entregas para validar se determinada solução faz sentido ou não para o negócio.
Entregar tudo de uma vez mata pequenos negócios aos poucos. E entrega é em produção, não em ambiente de homologação.
🏆 Confiança na equipe
É preciso promover a confiança entre todos na equipe, de modo a não boicotar ideias que as pessoas trazem tampouco ficar fazendo micro-gerenciamento de código.
Você não é um linter.
❤️ Transparência
O processo de desenvolvimento deve refletir o trabalho e resultado, e não o relatório de horas de trabalho da equipe ou uma pessoa específica.
Fomentando transparência, perde-se a necessidade de reportar o que cada um faz, pelo que também evita aqueles Pull/Change Requests de 3 meses que nunca saem do ambiente de homologação.
O processo deve gritar.
⚽ Experimentação != Playground
Uma cultura de experimentação é essential para o negócio, mas não podemos deixar a coisa desandar de modo a virar um playground de coisas inacabadas em ambiente de produção.
Não brinque com o dinheiro dos outros.
👍 Contrate iniciantes na carreira
E potencialize esta cultura com pair-programming e ambiente de testes automatizados.
Projeto cheio de pessoas “ninjas” e pseudo-líderes não sai do lugar. E se sai, é pq deu sorte de algum endinheirado acreditar na promessa do negócio.
Promova cultura de aprendizado constante.
🍀 Não conte com a sorte
Pra finalizar, se possível conte apenas com o dinheiro em caixa.
Deixe a sorte para os imprudentes, faça uso consciente do dinheiro da empresa e promova cultura de experimentação e partilha de conhecimento.
O dinheiro acaba, não conte com a sorte e não brinque com o dinheiro dos outros!
