Sobre tomar decisões em TI

Um cenário bastante comum em pequenas empresas é a tomada de decisão por pessoas que também são responsáveis pelas operações. Em ambientes onde os processos não são formais e muitas vezes ainda estão sendo construídos é comum encontrar equipes optando por soluções apenas por serem as mais populares do momento.

Nesse contexto, de que forma podemos ajudar esses profissionais a tomarem boas decisões?

Me acompanhe…

• Que linguagem de programação utilizar?
• Qual framework adotar?
• Como armazenar os dados?
• Quais ferramentas DevOps usar?

Essas são questões recorrentes em diversas fases de qualquer projeto de T.I. Nenhuma dessas questões pode ser considerada mais importante que outra, mas você certamente encontrará uma que faz mais sentido do que as outras para os envolvidos no escopo do seu projeto.

O que tem funcionado para mim é, num primeiro momento, com seu time de colaboradores pre-definido, faça um levantamento do perfil de cada um dos integrantes. Verifique em quais linguagens e frameworks eles possuem experiência, sem deixar de lado tecnologias que eles têm vontade de aprender. Seu time pode ter ampla experiência em PHP e Laravel por exemplo, mas eles também podem ter uma grande vontade de aprender Go. Se algum integrante possuir ampla experiência nessa nova tecnologia, pode valer a pena aproveitar a paixão da equipe como catalizador no processo de desenvolvimento. No entanto, deixe bem claro que esse conjunto de ferramentas envolvendo linguagem, framework, técnicas e soluções DevOps, são apenas o meio para se chegar no objetivo final, resolver algum problema da empresa ou do cliente.

Não há nada melhor do que uma conversa franca entre o gestor e o time para levantar essas informações e decidir, em conjunto, quais tecnologias farão parte da pilha de soluções da empresa — o Stack de soluções. Cuidado para não cair na armadilha de escolher uma tecnologia só porque parece bacana e é popular num dado momento. A escolha deve ser guiada por tecnologias que proporcionem vantagens competitivas para sua empresa. Tenha em mente o seguinte:

Um bom Stack é aquele capaz de escalar mais rápido do que o capital humano necessário para mantê-lo.

O objetivo aqui é ser capaz de escalar sua pilha de soluções de acordo com a quantidade de usuários, tráfego, dados e código, apenas injetando dinheiro ou hardware ao invés de pessoas.

Se toda vez que sua base de usuários dobrar, você puder simplesmente pagar por mais servidores e tudo continuar funcionando, você está no caminho certo.

Veja por exemplo o time do WhatsApp, que construiu seu Stack em torno da linguagem Erlang e agora suporta 70 milhões de mensagens por segundo e 450 milhões de usuários. O equivalente a 50 bilhões de mensagens por dia ou 7,2 trilhões de mensagens por ano. E eles fizeram tudo isso com um time de apenas 32 engenheiros [hoff-2014].

Além disso, na hora de escolher seu Stack de infraestrutura e operações, não subestime a complexidade. Num primeiro momento você pode achar que ter um servidor Linux na AWS para seu time começar a desenvolver e entregar soluções seja suficiente. No entanto, essa solução se tornará rapidamente complexa de manter manualmente. Assim que começarem a surgir necessidades de um balanceador de carga na frente dos servidores web, um balanceador interno na frente dos bancos de dados, atualizar os sistemas, controlar os acessos, realizar backups, entregar alta disponibilidade, redundância, etc., você vai notar que disponibilizar essa infraestrutura “na mão” é inviável. Portanto, ao invés de começar com uma infra manual, tenha um conjunto padrão bem definido, enxuto e automatizado. Uma vez que seus desenvolvedores acostumarem com o workflow de desenvolvimento manual, será muito difícil mudar a cultura do time para um workflow baseado em uma infra automatizada e escalável — Infra as Code — como dizem.

Matriz de decisão

Procure engajar o seu time através da construção de uma matriz de decisão, enumerando os principais critérios para a escolha das possíveis tecnologias, dando peso para cada uma delas e avaliando cada uma em conjunto com seus colaboradores. Por exemplo:

Documente o processo de tomada de decisão detalhando os motivos que levaram a escolha de determinadas tecnologias. No decorrer do projeto vão surgir novos integrantes, novos desafios e com isso mais incertezas. Quando surgirem motivos para duvidar da stack escolhida, utilize esse documento como referência.

O que se espera do departamento de Infraestrutura e Operações?

Não há uma resposta simples e direta para essa pergunta, depende de quem pergunta.

Do ponto de vista do time de desenvolvimento

O time deve ser capaz de desenvolver e testar suas implementações de forma rápida e confiável, sem se preocupar com os detalhes da infra. O desenvolvedor não deve ser surpreendido por um código que se comporta de uma forma no ambiente local e de outra em produção. Para isso, é fundamental contar com testes automatizados.

Do ponto de vista do próprio time de operações

O ambiente deve ser o mais automatizado possível. Tarefas manuais e intervenções humanas devem ser evitadas ao máximo. O ambiente deve ser monitorado, escalável e a prova de falhas. Receber um chamado no meio da noite devido a um deploy que derrubou o sistema de produção deve ser exceção e não regra. O workflow deve contar com testes automatizados, escritos paralelamente a fase de desenvolvimento. Caso um deploy passe nos testes e ainda assim derrube o sistema, a infra deve ser capaz de reverter automaticamente para sua última versão estável.

Do ponto de vista do usuário

A solução contratada deve estar sempre disponível, a execução dos procedimentos deve ser a mais rápida possível. Manutenções devem ocorrer de forma planejada, onde os usuários são previamente notificados. Falhas são inevitáveis, mas a plataforma deve estar preparada para informar ao usuário sobre elas de forma amigável.

Conclusão

Minha sugestão é:

• comece de maneira simples com um escopo reduzido;
• Automatize tudo o que você puder;
• Procure manter o ambiente de desenvolvimento o mais próximo possível do seu ambiente de produção. Mesmo que você tenha uma simples aplicação web, você já pode começar utilizando containers nas estações de trabalho dos desenvolvedores.
• Uma boa prática é manter sua infraestrutura como código, geralmente no mesmo repositório do projeto.
• Não reinvente a roda, procure apoiar-se em boas práticas já estabelecidas e a partir delas fazer adaptações conforme a necessidade do seu time.

Referências:

• The Twelve-Factor App é um bom exemplo de especificações gerais a serem seguidas.
• O livro Infrastructure as Code — by Kiev Morris — O’Reilly é uma excelente introdução a este paradigma que está se estabelecendo.
• Alem disso, eu não poderia deixar de citar os livros do Gene Kim, The DevOps Handbook e The Phoenix Project.

Artigo originalmente publicado em:
https://www.linkedin.com/pulse/sobre-tomar-decisões-em-ti-rodrigo-vieira/