Arquitetura Corporativa para Todos

Artigo / Post

O termo “programador” foi cunhado há várias décadas e não é mais capaz de traduzir as complexidades das atividades que hoje são necessárias e requisitadas pelo mercado.

Um programador só precisa saber “codar” bem! Concorda? Discorda? Enfim… vamos a algumas provocações.


“A Matrix está em todo lugar. É tudo que nos rodeia. Mesmo agora, nesta sala. Você pode vê-la quando olha pela janela, ou quando você ligar sua televisão. Você pode sentir isso quando você vai para o trabalho, quando você vai à igreja, quando paga seus impostos. É o mundo que foi colocado diante dos seus olhos para cegá-lo da verdade.” Morpheus – Filme Matrix


Se você é do tipo que tomaria a pílula azul, e optou por retornar a sua vida normal criada dentro da ilusão da Matrix não precisa continuar a leitura deste artigo. Se você é do tipo que tomaria a pílula vermelha então a leitura vai proporcionar algumas provocações e você poderá retornar à Matrix com algumas reflexões que podem, ou não…, mudar sua percepção sobre um tema recorrente e muitas vezes “acalorado” nos fóruns técnicos.

A falta de contexto em algumas afirmações é a principal fonte de discórdia para colocações e opiniões divergentes e acaloradas. Em que contexto “programador” está sendo inserido?

Em um contexto de fluxo do tipo “Fábrica”, conhece? Vamos tentar “tipificar” … Seguem mais ou menos este fluxo:

  • Inicia no gerente de conta que promete tudo, sem consultar ninguém.
  • Passa para um gerente de times
  • Que Envia para um time de analistas de negócio
  • Que entrega para o time de arquitetura (quando o “custo” permite) e define os digramas, desenhos e interações sem consultar o cliente
  • Descarrega isso para um gestor “Master” que por sua vez observa qual grupo de “programadores” não estão “150% ocupados” , monta uma “squad” e faz a “planning”
  • Depois notificando o time que aquele projeto tem um prazo para entrega de “Y” e conta com todos para mais um “desafio” para ao final todos baterem palmas pelas entregas
    “Há faltou o time de Q.A.” fala alguém do time, meio sem jeito outro do time complementa: “Teremos testes unitários também?
  • “Se o custo permitir fazemos senão podemos confiar em vocês” diz o gerente de times. O gestor “Master” não fica atras e complementa “nosso time é vencedor, sei que posso contar com vocês”.

É este tipo de fluxo que desejo citar. Neste contexto a afirmação do título possa fazer mais sentido e “miseravelmente” é coerente com a “lei de Conway”. A lei de Conway é conhecida pela sua conclusão:


“Ao desenhar seus sistemas, as organizações estão fadadas a produzir cópias de suas estruturas de comunicação.”


Curiosamente algumas empresas que adotam este fluxo têm resultados operacionais relevantes! O que nos leva a outra reflexão :


Embora possa discordar, empresas que utilizam este modelo possuem destreza suficiente (independente do esforço/desgaste que possa ocorrer) para obter resultados relevantes ao ponto de mantem suas estruturas de comunicação inalteradas, enquanto perpetuar um equilíbrio das regras de oferta e demanda no mercado que ela atua.


Quando modificamos o contexto para empresas que precisam de novos “ingredientes” como conceitos serviços distribuídos, modernização de sistemas para nuvem, devops, finops, e afins as coisas começam a ficar bem mais difíceis e começa a não fazer sentido a afirmação inicial!

Neste novo contexto podemos ir além… o termo “programador” deixa de ser um “cargo” a ser requisitado/declarado, sendo apenas mais uma atividade (hard skill), essencial entre muitas outras, necessária para as empresas que desejam estar alinhadas com os novos (nem tanto) “ingredientes” do ecossistema corporativo.

Neste ponto uma reflexão “deliciosamente” desconcertante, feita por alguém que gosto muito, e nos leva a pensar que muitas empresas precisam “tomar a pílula vermelha” quando utilizam estes novos “ingredientes”. O comentário é mais ou menos este:


“Times monolíticos estão fadados a produzirem sistemas monolíticos, uma vez que segundo a lei de Conway produzem cópias de suas estruturas de comunicação.” (Elemar Jr. )

Parafraseando o Morpheus de Matrix, Há uma grande diferença entre saber o caminho (programar) e percorrer o caminho (exercer a atividade).


Pessoalmente, concordo que um “programador” só precisa saber “codar” bem! O que não concordo é que deva ainda existir “programador” para o ecossistema corporativo que vem se firmando nestes últimos anos.Olhando adiante, as empresas e profissionais da área de tecnologia deverão estar mais preocupadas em percorrer (exercer a atividade) e não mais em saber apenas o caminho (programar).

Esta mudança de “eixo” induz por parte das empresas, a repensar suas estruturas de comunicação. Já por parte dos profissionais de tecnologia, a expandirem suas habilidades para serem capazes de atender outros skills que só “programar”.

O termo “programador” foi cunhado há várias décadas e não é mais capaz de traduzir as complexidades das atividades que hoje são necessárias e requisitadas pelo mercado. Isso parece refletir também nas “reclamações” do público de primeiro emprego/estágios que encontram dificuldades em serem aceitos devido as exigências de várias habilidades (muitas delas, concordo, exageradas). Infelizmente, é fato que as habilidades para entrar no mercado de tecnologia da informação estão cada vez maiores e não são apenas “hard skill”.

As habilidades de “soft skill” estão crescendo mesmo para quem está iniciando. Este fenômeno de complexidade crescente, precisa ser refletido nas instituições de ensino (ensino médio, técnico e superior) para mitigar a frustação por parte de quem quer e precisa entrar e por quem quer e precisa contratar.

Se você chegou até aqui, optou pela “pílula vermelha”, então não vou falar sobre um mundo colorido e feliz. Na maioria das empresa tem tecnologia de ponta, porém também temos legados. Microsserviços é uma necessidade, porém aparecem monolíticos distribuídos. Ambiente cloud pode ser um dos focos , porém precisamos manter também o “on-premiss”. O “Stack de desenvolvimento” esta em constante evolição , ou seja, zona de conforto não é uma opção.

Com isso dito, agora podemos agora voltar a “matrix”! mas antes deixa ua dica : O mercado não contrata mais “Programador”! Avalia “hard skill” e “soft skill”,  se preocupe  em evoluir e/ou adquirirem habilidades para seu crescimento profissional e pessoal.


Tenham um excelente dia! Eu sou Fernando Cerqueira e entrego estratégias digitais para os desafios do presente, com propostas de inovação para um futuro sustentável.

Compatilhe

0 0 votos
Avaliação Global
0 Comentários
Feedbacks embutidos
Ver todos os comentários
Categorias

Sobre o Autor

Picture of Fernando Cerqueira

Fernando Cerqueira

Eu sou Fernando Cerqueira e entrego estratégias digitais para os desafios do presente, com propostas de inovação para um futuro sustentável. Como arquiteto sênior, aproveito meus mais de 20 anos de experiência em arquitetura e desenvolvimento de software para projetar e implementar soluções baseadas em nuvem que ajudam os clientes a transformar seus negócios com tecnologia.

Outros Posts

Categorias

CancellationToken – O que você precisa e deveria saber antes de usar

No mundo moderno da engenharia de software os processos , atividades e dependências ocorrem a todo o momento de forma concorrente! Falar de concorrência é ter consciência que várias tarefas são executadas simultaneamente e/ou concorrentes com os ciclos/processadores disponíveis e que estes recursos são finitos e/ou tem custos associados à

Documentação moderna centrada em estímulos contextuais

Introdução Essa frase provocativa abaixo “Documentos escritos que não são lidos, não vale os bytes que ocupam – Elemar Júnior” serve como ponto de partida para uma reflexão mais crítica frente aos desafios de uma documentação moderna, que exige novas abordagens e uma mudança cultural para agregar valor. O desafio

Os 13 fatores de desenvolvimento de software!

Os 13 fatores de desenvolvimento de software! Não, você não leu errado😁. São 13 mesmo, adicionei um fator extra 😮 , mas antes de falar dele, vamos relembrar os **12** fatores que ajudam a criar aplicações mais resilientes, portáveis e fáceis de gerenciar: Código Base : Uma única base de

O que é preciso para ser um arquiteto corporativo?

O que é preciso para ser um arquiteto corporativo? Antes de continuar a leitura, um aviso : Já se perguntou o que está por trás (o famoso porquê) da adoção de ADR´S, C4-Models, designs patterns, Zachman, FEAF, DoDAF, MODAF e BIAN, TOGAF, CMMI e afins? 🔥 Arquitetura corporativa NÃO é

"Arquitetura NÃO é somente sobre tecnologia é essencialmente sobre pessoas! No dia a dia como arquitetos é avaliar e implementar propósitos, com tomadas de decisões tecnológicas fundamentadas (pelo menos na maioria dos casos) na engenharia de software."

Fernando Cerqueira | Arquiteto Corporativo

Sua Reflexão

0
Adoraria saber sua opinião, comente.x