BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos A TI em ambiente ultra dinâmico. Como lidar com conflitos entre departamentos?

A TI em ambiente ultra dinâmico. Como lidar com conflitos entre departamentos?

Favoritos

Sexta-feira, 18:10… você está sentado em sua mesa, fechando o browser, slack, sublime, quando de repente, alguém chega do seu lado e pergunta: "está tudo ok pra amanhã, né?"

Por um instante, vem à mente um churrasco ou uma partida de futebol, mas logo se lembra que não foi convidado para nenhum desses eventos épicos.

Timidamente e com medo da resposta, solta: "Como assim?"

Nos cinco minutos seguintes, alguns sentimentos invadem seu corpo: raiva, medo, tristeza, desespero, angústia, depressão, saudade… E logo descobre que precisa levantar uma infra, um hotsite, um projeto em questão de horas.

90% da empresa já foi embora e será preciso fazer quase tudo sozinho ou com mais 1 ou 2 pessoas para lhe ajudar. Um detalhe que não pode ser esquecido: trata-se de uma ação na qual a empresa espera lucrar muito, com rios de dinheiros já investidos. Portanto NADA, absolutamente NADA pode dar errado.

Como se fosse uma partida final de copa do mundo, você respira fundo e entra de cabeça pra entender todo o projeto, fazendo o impossível pra deixar tudo ok em produção.

Depois do caos, duas coisas podem acontecer: dar tudo certo ou tudo errado.

Tenho certeza que muitos já passaram por situações semelhantes ou até piores.

Mas deixa eu contar um segredo: não adianta sair reclamando, p… da vida (de vez em quando pode até adiantar). E digo mais, isso vai acontecer outras vezes.

Dando tudo certo ou tudo errado, aqui vai uma dica: FAÇA UM REVIEW depois de finalizar. E não só recapitulando desde o momento da solicitação que lhe fizeram. Vá além, entenda o porquê de ser notificado de última hora, se consegue evitar situações semelhantes, o que funcionou, o que não rolou e etc.

Mas o mais importante: descreva ações e faça algo!

Mesmo que sejam coisas pequenas. Adicione isso como uma rotina para você e sua equipe.

Adapte a sua arquitetura

O que chamo aqui de ambiente ultra dinâmico é aquele em que as coisas acontecem de forma muito mais rápida do que o natural. As decisões são tomadas do dia pra noite. Projetos são planejados em questão de minutos. Processos são incorporados na hora.

Sistemas são aprovados e reprovados a todo momento. Um sistema que parecia crucial, no mês que vem pode ser completamente substituído por outro. Algo em que estava pensando ontem, já mudou hoje e seu planejamento tem que ser adequado 2, 3 ou mais vezes durante uma mesma sprint.

Não há certo ou errado. Existe o que funciona e dá resultado. Fail and Learn Fast.

Ambientes ultra dinâmicos sem muitos processos burocráticos exigem que seus sistemas e soluções possam suportar essas mudanças bruscas, adaptações de última hora, construções de POCs e MVPs para validar e testar conceitos.

Absorva isso. Pode ser que consiga exigir mudanças nos workflows da empresa como um todo. Mas não pense que o mundo irá mudar por você. Sua arquitetura e metodologias precisam estar casadas com essa cultura.

Quando comecei a pensar no que escrever aqui, fiquei dias para achar o tópico certo mas acima de tudo queria que não parecesse algo que vemos em qualquer lugar, como palestras, artigos, etc. Não queria que fosse "mais do mesmo". Com certeza, essa é a parte mais difícil de achar em um emaranhado de ideias que voam pelas nossas cabeças.

Mesmo assim, entendo que pessoas que possam estar lendo isso possam nunca ter visto alguns dos conceitos/soluções que citarei mais abaixo. É uma ajuda para conseguir um pouco dessa visão arquitetural e de solução que funciona melhor para ambientes ultra dinâmicos (caso não tenham conhecimento de algo, sugiro que pesquisem sobre):

  • Infraestrutura cloud
  • Microservices
  • API based
  • Substituição de sistemas monolíticos
  • Metodologia ágil
  • Squads
  • MVP, POCs
  • Entre outras séries de siglas e palavras da moda que já deve ter ouvido por aí: docker, container, EC2, S3, SNS, SES, kubernetes, Elastic Search, CDN, CD, CI, AWS, GCP, Azure, NoSQL, Aurora, RDS, Vue, React, Kotlin, Go, etc etc etc…

Mas, e se eu disser que no aperto, na situação que descrevi acima, simplesmente se esquece de tudo isso e fazemos do jeito mais rápido possível? E detalhe, FUNCIONA!

Pode ser que depois de um tempo, ao olhar aquilo, sinta vergonha do que fez; pede desculpas a todos os seus professores de faculdade, apaga o código do repositório pra ninguém ver, e não comenta com ninguém com medo que seu diploma seja cassado.

O mais interessante é receber elogios porque simplesmente tudo deu certo e a empresa faturou alguns bocados de $$$. Isso na visão mais otimista possível. Obviamente, pode ser que na prática, você subiu uma página não otimizada, sem auto scaling e que fez tudo capotar…

Mas entenda, nas duas situações, o pessoal de negócio não quer saber se:

  • Uma instância sua da AWS é fantástica OU se estava em North Virginia e deu um pepino geral por lá;
  • Sua API gateway é maravilhosa OU se parou estranhamente de funcionar;
  • A integração com as APIs é extremamente rápida OU se deu timeout em uma delas;
  • Tudo funcionava ontem OU se ainda tinha uma parte de um sistema legado que não é seu;
  • Seu time conseguiu fazer 20 pontos a mais nesse sprint OU se não estava planejado com essa demanda;
  • Sua solução está baseada nas melhores práticas devops OU se o cara de infra do seu time não estava na empresa na hora em que recebeu a demanda;
  • Seu time desenvolveu uma POC em 1 semana OU se a solução era temporária e alguns refactorings estavam planejados para serem feitos;
  • Você foi em um evento e já está implementando várias técnicas inovadoras que grandes empresas usam OU se não tinha ninguém às 2:24 da manhã que entendesse de um script em Go.

Aliás, esses exemplos são baseados em fatos reais. Lendo agora, parecem exemplos de documentários, mas na hora pareciam filmes de terror.

O que quero tentar deixar claro aqui é a necessidade de balancear entre robustez e rapidez em alguns momentos. Entenda se vale a pena demorar um pouco mais ou entregar uma solução o quanto antes. E acima de tudo, aceite que será preciso correr alguns riscos - mas sempre com bom senso. Feature toggles podem te ajudar muito nesses cenários caóticos.

Se estiver funcionando, não mexa

Nem sempre isso é verdade. Imagine que um sistema seu tem uma brecha de segurança e está perfeitamente estável. Dois anos depois, o sistema sofre um ataque e a reputação da empresa vai pro brejo.

Refactorings precisam ser incorporados ao macro planejamento em diversas situações. Não negligencie isso. Explique os motivos dessa necessidade e faça acontecer.

Software não é pastel

Essa frase é bem conhecida pelo pessoal de TI e odiada pelo pessoal de outras áreas. Antigamente fazia uso dessa frase, hoje chamo atenção de quem a fala pelos corredores.

Resumidamente, a TI reclama que nem tudo é tão simples quanto parece, que algumas coisas não são feitas em 5 minutos; e do outro lado, o discurso é que precisa ser o mais rápido possível, o quanto antes, pra ontem etc… e que também ficaram sabendo naquela hora.

Pronto: the treta has been planted.

Pedir que todos se abracem, cantem juntos cirandinha e vivam em paz é meio utópico. Claro que cada lado precisa entender um pouco mais do outro (pode parecer difícil mas pense como em um relacionamento). É preciso ceder em algumas situações e, além disso, a comunicação precisa funcionar como um todo.

Aliás, esse item é o que mais ouço por onde quer que eu vá. Diria que é o principal problema das organizações atuais, mesmo com toda a tecnologia que temos hoje. Se fosse pedir algo aos grandes gestores das empresas, seria: trabalhem na diminuição de problemas de comunicação interna. Os principais conflitos moram no fato de uma área não entender e conhecer a fundo o que a outra faz.

E para quem é de TI, não acredite que ninguém entende o que fazem. Sejam humildes, expliquem o contexto, exponham as suas opiniões sem criar atrito. Ao mesmo tempo, façam o exercício de se colocar na pele da outra área.

Em vários locais por onde passei, via com certa frequência uma situação. Pessoal técnico reclamando que as pessoas de outros departamentos não sabem o que falam, que não entendem nada da parte técnica, que os outros só fazem m..., que precisam corrigir os problemas que os outros fizeram, etc.

Do outro lado vejo os outros departamentos reclamarem que a TI não entrega, que falam difícil, que não entendem o negócio, que não sabem conversar, que são muito fechados, etc.

 

Esse clima de guerra é comum em vários lugares, porém, em ambientes ultra dinâmicos o efeito pode ser muito maior. A diferença é que nesse tipo de estrutura, processos perdem a sua relevância. O foco está nas pessoas.

Diante de situações de mudanças drásticas, crises, defeitos, lançamentos e novos projetos, as pessoas são as que sustentam isso tudo. Se há muitos conflitos permeando a organização, o sistema vai se rachando aos poucos e entrando em pequenos colapsos.

Absorva e aceite isso. O crescimento da empresa se baseou nisso. Use todos os seus neurônios para adaptar a parte técnica para resolver essas questões. Teste muito e aprenda com isso, evolua sempre.

Empatia. Essa é a palavra-chave. Crie esse sentimento em sua equipe. Faça entenderem que todos possuem problemas e que ficar apontando o dedo para tentar achar culpados gera um ambiente de disputa que será prejudicial a todos.

Se sua equipe acha que sempre tem a razão, que dominam o assunto e não tem espaço para discussão, isso vai gerar uma divergência, o que o levará a ter mais inimigos no seu trabalho do que parceiros.

Peça ajuda a todos da empresa. Construa um ambiente que, acima de tudo, é colaborativo e privilegia a pessoa. Na minha visão, este é o maior bem da empresa. São as pessoas que seguram as pontas quando algo dá errado ou que fazem alavancar o crescimento. São elas que trabalham para as máquinas funcionarem.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT