Rotineiramente, eu vejo vagas para programadores full stack ou currículos de profissionais que se declaram como tal artífice. Na minha formação como engenheiro de software, sempre aprendi que precisamos ter foco e aprender uma coisa por vez, me tornando bom em cada uma delas no seu tempo e, no mercado, à medida que preciso usar tais tecnologias. Mas, nos últimos anos, convivendo com as rápidas mudanças corporativas e desenvolvendo estudos sobre carreira na Universidade de São Paulo (USP), tenho me deparado com um cenário diferente: jovens formados ou formandos ansiosos para aprender absolutamente tudo, as inúmeras linguagens de programação, todos os frameworks de front end, ferramentas de automação, estruturas de servidor, plataformas de banco de dados, pré-processadores e gerenciadores de pacotes.
Com a chegada de metodologias ágeis, que pregam times multidisciplinares, é comum a errônea interpretação de multidisciplinaridade com o lema “tudo faço”.
Uma equipe multidisciplinar é um grupo de produção intelectual, material ou de ambos, composta por integrantes que atuam em áreas diferentes, mas que se completam para o desenvolvimento de um projeto específico. (REZENDE, 2018)
Quando o Scrum prega que o time é multidisciplinar, ele está dizendo que profissionais com diferentes skills conseguem abraçar diferentes necessidades para a conclusão de um projeto, e não que um único indivíduo daquele time deve saber sobre todas as tecnologias e executar qualquer atividade do squad, tampouco que todos devem fazer tudo. Respeitando as especialidades, o framework prega que diferentes habilidades juntas conseguem entregar produtos de tecnologia.
Mas e o tal full stack?
Uma vaga full stack não fala nada. É algo genérico. Não diz para um profissional qual é, realmente, a necessidade de um cargo, o que a empresa espera dele. E a mim, após mais de 10 anos na área, me parece irresponsável, já que fomenta uma impossibilidade que frustra profissionais que nunca atingirão um patamar quimérico.
Você programador já deve ter lido muitos artigos “como se tornar um profissional full stack”, e, certamente, saiu dessa leitura ainda mais inseguro. Nos deparamos com vagas que trazem para nós uma lista absurda de requisitos que não será atendida por ninguém. Essas vagas assustam os jovens profissionais (juniores) e despertam graça nos estudiosos da mente humana — sim, eu estou falando dos psicólogos.
Uma conversa com Antonio Euzébios Filho, professor Doutor do Instituto de Psicologia da USP, nos traz o seguinte questionamento: ser full stack implica em saber sobre tudo? Isso é questionável do ponto de vista da psicologia. No livro The Secret Life of the Mind: How Your Brain Thinks, Feels, and Decides, o físico e figura internacional, Mariano Sigman, líder na neurociência cognitiva da aprendizagem e tomada de decisões, nos trouxe algumas informações relevantes como a de que o cérebro humano tende a esquecer informações que não são ativadas (usadas frequentemente). Isso se dá pela necessidade de armazenar novas informações. Você poderia argumentar que algumas informações da sua vida, como a fórmula de Bhaskara ou do Cateto oposto/hipotenusa ainda estão presentes em sua memória, e eu te diria que sim. Isso se explica por uma questão lógica: as memórias mais ativadas (as que mais foram reforçadas ou praticadas ao longo da sua vida) são memórias de longo prazo e que envolveram mudanças estruturais no seu cérebro. Mas, mesmo essas memórias sofrem perdas, já que, certamente, você não saberia nesse exato momento de todas as variáveis e resolver uma equação do segundo grau com a mesma primazia de quando estava no colégio. Isso acontece porque você já não se lembra de vários macetes que utilizava naquele tempo. Saindo um pouco dessa analogia, entrando na questão científica, é sabido que o cérebro humano tem 100 bilhões de neurônios e que 1 bilhão deles são responsáveis por armazenar informações.
Se cada neurônio pudesse armazenar apenas uma “unidade” de memória, o cérebro estaria transbordando de informação. “A quantidade de neurônios existente não é suficiente para todas as informações adquiridas por um indivíduo”, explica Paul Reber, professor de psicologia da Northwestern University, dos Estados Unidos. (BBC Future)
E isso tem total relação com as tecnologias que utilizamos. Se um programador trabalhasse por 5 anos com uma linguagem de programação Ruby e depois fosse atuar como Analista de Infraestrutura, certamente, ao mudar de contexto, ele teria mais dificuldade com as tecnologias que já não usa mais, pois vários desses macetes que o cérebro nos dá como ferramenta para nos tornarmos produtivos, já não estariam mais ativos na memória. Logo, não conseguiriam ser processados da mesma forma pelos nossos neurônios, que são responsáveis por criar esse circuito de ideia mental no cérebro, pois os dendritos — uma das três partes que formam os neurônios — não estão recebendo estímulos para as suas terminações sobre aquele assunto há um bom tempo.
Variável Motivação
Um estudo feito pela Columbia Business School e encomendado pela Microsoft avaliou trinta empresas americanas, entre microempresas e empresas de pequeno porte, todas segmentadas na área da tecnologia. Esse estudo tinha como objetivo verificar as dificuldades dessas empresas em crescer, reter profissionais e escalonar seus serviços. O primeiro ponto observado foi que, em boa parte dessas empresas, elas possuíam grande planejamento estratégico e visão de futuro, mas não conseguiam evoluir nos seus negócios devido a débitos técnicos. Analisando melhor a questão, o que pode ser percebido é que, nessas empresas, todos os serviços tinham sido criados sem um planejamento técnico adequado, o que acarretou sistemas de difícil manutenção. Ao esbarrar nessas limitações e, consequentemente, não atenderem às demandas da organização, muitos profissionais acabaram se frustrando e desistindo dessas organizações, gerando uma rotatividade grande no quadro de funcionários.
Voltando para o contexto de trabalho, o mercado especializou pessoas pela necessidade de atender aspirações profissionais desses indivíduos, mas, também, devido à incapacidade de se saber sobre tudo. Quando um DBA era chamado para um time, planejava-se, intencionalmente, a criação de uma estrutura de dados que fosse robusta e tornasse a aplicação sustentável por longos anos. Talvez, em muitos contextos, esse profissional não se faça mais necessário devido à automatização e facilitação das arquiteturas de banco de dados, que acabaram tornando a vida dos programadores menos dependente de outros profissionais. Mas, perceba que até no meu discurso acima existe um pouco da ignorância que esse artigo visa combater. Eu estou assumindo que toda a atividade de um DBA é facilmente incorporada ao trabalho nosso como programador. Mas será mesmo que estamos aptos e qualificados para projetar e implementar processos e soluções para distribuição e arquivamento de dados, proteger os mesmos, monitorando constantemente o espaço em disco, a capacidade de armazenamento e o desempenho do servidor para evitar gargalos? E a pergunta mais importante: uma vez contratado como programador, gostaria eu de fazer esse trabalho? E aqui cabe o motivacional do indivíduo. Seu trabalho só envolve um propósito quando ele também te dá satisfação.
Vamos abordar melhor essa questão da motivação profissional. Nesse mundo tecnológico, não é difícil encontrar uma infinidade de linguagens de programação, estruturas de servidor diferentes e complexas, plataformas de banco de dados, pré-processadores e gerenciadores de pacotes, todos voltados para a solução de problemas específicos, que variam dependendo do tipo de aplicativo que você deseja criar. Por mais que você esteja interessado em conhecer como funciona cada uma dessas áreas, você pode ter suas aspirações profissionais e desejo de trabalhar com algo específico. Você pode ser um ótimo acadêmico que se formou em engenharia de software, mas quer atuar com programação GO, Rust e Node, ou ser um programador autodidata, que aprendeu sozinho a construir um formulário de uma aplicação, e gostaria de continuar trabalhando com javascript, html e CSS. E não há nada de errado nisso! Injusto seria comparar ambos os profissionais que possuem conhecimentos, desejos e projeções diferentes sobre a própria carreira. E, acredite, dentro de um mesmo time, esses podem agregar, atuando em suas fortalezas, desde que não sejam cobrados igualmente sobre a mesma proficiência de um mesmo código.
Quando empresas contratam profissionais que vão atuar com atividades que não lhes dão prazer, eles acabam se frustrando e buscando algo novo. Com o mercado de tecnologia aquecido, essa saída da organização se torna ainda mais rápida. Não estou falando que só temos que trabalhar com o que nos dá prazer. Isso ainda é trabalho! Mas sim, é preciso ter o mínimo de tesão pelas atividades que se executa no dia a dia para que o trabalho tenha um propósito. Exigir que um profissional que se dedica a estudar programação passe o dia resolvendo questões de infraestrutura, pode fazer com que ele se frustre com a área de atuação.
Falando em infraestrutura, vamos entrar num assunto polêmico: DevOps.
DevOps
Desde que Patrick Debois nos apresentou o termo, muitas empresas têm usado DevOps para os seus cargos “Programador DevOps”, “QA DevOps”, “SRE DevOps”. Com um objetivo válido, iniciado em 2007, quando se queria integrar melhor as áreas, permitindo que desenvolvedores e administradores de sistemas tivessem o conhecimento mínimo de infraestrutura para discutirem e desenvolverem, juntos, aplicações que suportem a estrutura arquitetada, tal gnose acaba criando uma sinergia entre DEVs, QAs e SREs. Uma boa prática que surge dessa cultura DevOps é a revisão de código diante de uma mudança de arquitetura implementada por um programador e que possa impactar os serviços de infraestrutura. Nesse caso, um profissional experiente na área (SRE, administrador de sistemas, DevOps Analyst) pode revisar as mudanças antes do código ser integrado a master. Mas isso não implica que todo desenvolvedor deva ser responsável por automatizar processos através de scripts de criação de infra, pipelines de deploy de código e monitoramento de disponibilidade, latência e desempenho dos serviços, tampouco administrar a infraestrutura de sistemas em ambiente Cloud (AWS, Azzure, GCP) e realização do planejamento da capacidade das aplicações.
Não estou defendendo que devemos ter dependências desses profissionais. Imagine ter que esperar por um DBA para obter uma informação da base de dados! Ou, ter que esperar um SRE fazer deploy no ambiente de homologação para que um QA comece a analisar uma funcionalidade! Não é esse tipo de dependência que queremos criar, mas, definitivamente, esses profissionais e seus anos de dedicação a essas especialidades são de fundamental importância para uma organização que pretende crescer de forma escalável.
Historicamente, o profissional full stack, pela própria natureza da coisa, necessita conhecer sobre o todo, não conseguindo se especializar em quase nada. Por essa ausência de domínio sobre determinadas tecnologias utilizadas no desenvolvimento de uma solução, o resultado final tende a ser de baixa qualidade. (MORIMOTO, 2018).
No Google, por exemplo, todos os profissionais de tecnologia fazem parte do time de desenvolvedores, mas cada um com sua especialidade. Os Test Engineers — como são conhecidos os analistas da qualidade — não são, exclusivamente, responsáveis pelos testes, posto que a quantidade de desenvolvedores entregando features é muito superior ao número de analistas da qualidade, mas são esses profissionais especialistas em garantir o levantamento dos cenários pertinentes às features desenvolvidas, além de estarem em total contato com representantes do cliente (PO, PM, áreas correlatas), promovendo a garantia fidedigna das necessidades do cliente em código, por meio de uma interface de comunicação que consegue transformar regras de negócio em produtos digitais. Além de serem os guardiões da qualidade dentro do time, fomentando boas práticas da engenharia de software, ativos no direcionamento dos testes unitários e de integração, ajudando os DEVs na revisão dos PRs destes testes. Esses também são responsáveis pelos testes de homologação e optam, dependendo do produto, pela aderência de testes de aceitação a fim de garantir que as features atendem ao planejado.
Conclui-se…
Bom, do ponto de vista de custos, quando apenas o financeiro é observado, se torna interessante para as organizações terem profissionais full stack. As empresas estão cada vez mais buscando reduzir os seus gastos, o que é extremamente louvável, mas em alguns casos essa redução pode ser embasada em falácias de mercado. A Revista Melhor, especializada em Gestão de Pessoas, trouxe um estudo que mostra que os profissionais especialistas tendem a custar de 30% a 60% mais caros que os profissionais generalistas, o que é naturalmente compreensível, pois esses, na maioria das vezes, despenderam tempo e dedicação a conhecer tecnologias, processos e soluções específicas, seja por meio de cursos, qualificações, treinamentos, MBAs ou experiência profissional. Um profissional full stack parece interessante, pois ele, normalmente, é alguém que não tem especialização em nenhuma área, custa menos que um profissional especialista, e vai acabar se adequando a qualquer squad, em razão dele “tudo saber e tudo solucionar” — balela!
A nomenclatura que o time dá a seus profissionais não importa muito. Existem times de tecnologia onde todos são chamados de desenvolvedores, mas, na prática, cada um atuando na sua especialidade, e, claro, quando necessário, integrando-se às necessidades de outros especialistas. O importante é ter a consciência de que se uma empresa deseja crescer e ter seu negócio construído de forma que consiga se adaptar a possíveis mudanças do mercado, entregando cada vez mais soluções, gerando impacto no mercado e garantindo a fidelização de seus clientes, é preciso ter um time de especialistas que ajude a construir um ecossistema sólido, adaptável, integrável e performático. Ter esses especialistas envolvidos nas decisões de mudança, acompanhando e ajudando a sanar possíveis gaps que venham a surgir nesse processo de desenvolvimento, e mais que isso, preocupados em disseminar o conhecimento para outros tantos profissionais ainda tão generalistas, cria uma cultura forte, entrega soluções adaptáveis, mantêm o negócio escalável, e ajuda a manter profissionais motivados.
Referências:
CARLOTTO, Mary Sandra; CAMARA, Sheila Gonçalves. O tecnoestresse em trabalhadores que atuam com tecnologia de informação e comunicação. Psicol. cienc. prof., Brasília, v. 30, n. 2, p. 308–317, 2010. Disponível em: <http://www.scielo.br/scielo.php?script=sci_arttext&pid=S1414-98932010000200007&lng=en&nrm=iso>. Acesso em: 30 de out. de 2019.
NASCIMENTO, Gustavo Vaz. Um modelo de referência para o desenvolvimento ágil de software. 2007. Dissertação (Mestrado em Ciências de Computação e Matemática Computacional) — Instituto de Ciências Matemáticas e de Computação, Universidade de São Paulo, São Carlos, 2007. doi:10.11606/D.55.2007.tde-07052008–170413. Acesso em: 2019–10–30.
REZENDE, DENIS ALCIDES. Planejamento Estratégico Público Ou Privado — Um Guia Para Projetos Em Organizações. 2. ed. Rio de Janeiro: Brasport, 2008.
BARKER, Tom. Full Stack Web Performance. Sebastopol: O’Reilly Media, 2017.
SIGMAN, Mariano. The Secret Life of the Mind: How Your Brain Thinks, Feels, and Decides. Boston: Little, Brown and Company, 2017.
BARTEL, Ann. Betterment: People Management at a Start-up. Columbia Business School, 2014. Disponível em: <https://www8.gsb.columbia.edu/caseworks/node/495/Betterment%253A%2BPeople%2BManagement%2Bat%2Ba%2BStart-up>. Acesso em: 30 de out. de 2019.
LUCIEN, Dustin. Organizational Management Key to Scaling a Tech Company. Betterment, 2014. Disponível em: <https://www.betterment.com/resources/organizational-management-key-to-scaling-a-tech-company/>. Acesso em: 30 de out. de 2019.
HADHAZY, Adam. Até onde vai nossa capacidade de memória? BBC, 2015. Disponível em: <https://www.bbc.com/portuguese/noticias/2015/04/150408_vert_fut_capacidade_cerebro_ml>. Acesso em: 30 de out. de 2019.
KIM, Gene; HUMBLE, Jez; DEBOIS, Patrick; WILLIS, John; TORTELLO, João. Manual de Devops. Como Obter Agilidade, Confiabilidade e Segurança em Organizações Tecnológicas. Las Vegas: IT Revolution Press, 2018.
KIM, Gene; BEHR, Kevin; SPAFFORD, George. The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win. Las Vegas: IT Revolution Press, 2018.
QUEIROZ, Flávia. Pós-Millennials: como atrair esses talentos. Revista Melhor, 2019. Disponível em: <https://revistamelhor.com.br/pos-millennials-como-atrair-esses-talentos/>.Acesso em: 31 de out. de 2019.
ZOLET, Marco. Cultura da empresa é, na base, crescer juntos. Revista Melhor, 2019. Disponível em: <https://revistamelhor.com.br/cultura-da-empresa-e-na-base-crescer-juntos>.Acesso em: 31 de out. de 2019.
ANDRADE, Susanne. O lado humano da tecnologia. Revista Melhor, 2019. Disponível em: <https://revistamelhor.com.br/o-lado-humano-da-tecnologia/>.Acesso em: 31 de out. de 2019.
