Jeremy Freeman
Jeremy Freeman começou a sua carreira na indústria de software através de um curso de licenciatura em Informática. Teve a sorte de se envolver num pequeno programa de empreendedorismo na área da engenharia através da North Carolina State University. Enquanto estudava no programa, conheceu o seu atual cofundador, Hersh Tapadia, e esta apresentação mudou o rumo da sua carreira.
Um emprego “a sério” e três startups mais tarde, lidera uma equipa de engenharia na Allstacks e sente-se entusiasmado com os desafios de não só conceber um ótimo produto, mas também construir uma ótima equipa e uma empresa sólida.
P: Tem um mentor que o tenha inspirado ou ajudado no seu percurso profissional até agora?
Há tantos. Fazer parte da comunidade de startups em Raleigh, na Carolina do Norte, tem sido maravilhoso, e há dezenas de pessoas que me ajudaram de formas que talvez nem imaginem. Embora pudesse mencionar nomes específicos, foram algumas histórias cruciais que moldaram a minha visão do mundo.
Uma dessas histórias vem de um líder de vendas que falou numa das minhas aulas de empreendedorismo durante a licenciatura. Enquanto estudante de engenharia focado em escrever código e desenvolver competências técnicas, as vendas eram-me estranhas e pouco interessantes. No entanto, essa pessoa partilhou uma história que me ajudou a ver as coisas de forma diferente.
Recordou uma conversa com um dos seus colegas de trabalho da área técnica. O colega disse: “Não percebo como consegue fazê-lo.” O vendedor respondeu: “Fazer o quê?” O colega respondeu: “Cumprir uma quota. Deve ser muito stressante ser obrigado a vender para poder comer.” Pensou nisto durante um minuto e respondeu simplesmente: “É, mas se eu não vender, também não comes.”
Esta história ajudou-me realmente a contextualizar a engenharia.
Pode construir o produto ou serviço mais incrível, mas se não conseguir demonstrar o seu valor às pessoas que irá ajudar, estará apenas a fazer engenharia no vazio.
Outra pessoa que me ajudou foi um mentor que tinha liderado empresas e divisões de engenharia e que depois mudou o rumo da sua carreira para ajudar as pessoas a desenvolver as suas ideias e a encontrar funções em diferentes startups. Orientou-me ao longo de muitos desafios, mas uma das ideias fundamentais que me transmitiu foi que a maioria dos líderes de organizações técnicas se destaca numa de três áreas:
O “Cérebro Técnico”, o gestor de excelência ou a pessoa fundamental do produto. Continuou, dizendo que uma empresa bem-sucedida precisa dos três e que um grande líder precisa de identificar qual deles é, para depois contratar as competências que lhe faltam. Isto ajudou-me a compreender o meu crescimento enquanto líder de engenharia e a perceber quando devo assumir uma posição mais ativa ou recuar.
P: Pode indicar três pontos fortes ou competências que tenham sido importantes no seu percurso?
Um lema que sigo é: “Integra-te e depois destaca-te.” Embora seja uma frase espirituosa, lembra-me que, quando trabalho com uma equipa nova, preciso primeiro de conhecer a equipa. Compreender por que razão as coisas são como são é fundamental para criar confiança.
Por exemplo, se aparecer no primeiro dia e tentar implementar ou defender uma mudança importante, a reação habitual será de resistência e terei tornado o meu trabalho mais difícil daí em diante. É importante procurar semelhanças e áreas de concordância dentro de uma equipa nova antes de tentar desafiar o status quo ou fazer grandes mudanças. Esta abordagem aplica-se à construção de novas relações em qualquer área da vida.
Outra máxima que me orienta é: “O que as pessoas dizem e fazem está apenas relacionado com aquilo que pensam e sentem.” Embora possa parecer pessimista, gosto da ideia de que os seres humanos estão muitas vezes sujeitos a uma enorme pressão para agir ou falar de determinada forma.
Por exemplo, quando perguntamos a alguém como está a correr o seu dia, essa pessoa responde quase sempre: “Bem”, em vez de se abrir e falar verdadeiramente sobre como se sente. Ao trabalhar com equipas e grupos, é importante prestar atenção a essas pressões para compreender e demonstrar empatia. Por exemplo, se alguém lhe reportar, pode ser difícil assumir a responsabilidade por um erro se essa pessoa recear sofrer consequências.
Enquanto líder, é essencial construir e avaliar constantemente o nosso ambiente para promover a abertura. Caso contrário, podemos inadvertidamente criar uma cultura onde os problemas se acumulam dentro da equipa sem serem abordados.
No que diz respeito à gestão de equipas, as pessoas precisam de praticar persistentemente a introspeção e a análise retrospetiva para desenvolver competências sólidas. Embora “olhar para dentro” funcione comigo, pode não funcionar bem para todos, e um bom líder precisa de reconhecer as diferentes formas como cada pessoa aprende e cresce.
Um líder eficaz concentra-se em equilibrar a realização e a empatia, refletindo constantemente sobre os seus próprios pontos fortes e fracos, bem como sobre os da equipa em geral.
Have an account? Log In
P: Que competências continua a tentar desenvolver atualmente?
Retomando os conselhos de um dos meus mentores, estou constantemente a trabalhar no pilar da gestão dos três papéis de um líder técnico. Tive a sorte de trabalhar com um colega que é excelente nesse aspeto e que me mostrou algumas formas fundamentais de crescer e melhorar.
Como cofundador de uma startup tecnológica, tenho-me concentrado sobretudo na tecnologia e nos produtos e tenho trabalhado com equipas pequenas. Agora que a nossa organização está a crescer, tenho de crescer com ela. A prática da gestão é uma competência tão importante como o desenvolvimento de software.
P: Falemos sobre como ter uma equipa DevOps bem-sucedida. Quais são os principais objetivos que uma equipa DevOps poderá identificar numa jornada de transformação digital?
Uma das coisas mais importantes que ouço de outros líderes é a existência de uma compreensão partilhada do que DevOps significa para a sua organização. Já vi organizações em que “DevOps” significa contratar um SRE, chamar-lhe engenheiro DevOps e celebrar.
Começar pelos componentes fundamentais do ciclo DevOps e identificar como o trabalho e as ideias fluem pelo seu processo de desenvolvimento é um bom ponto de partida. Pegue numa única tarefa de desenvolvimento desde o início e acompanhe-a até ao momento em que dá origem à tarefa seguinte, e poderá identificar algumas lacunas importantes.
Por exemplo, poderá descobrir que a sua equipa de QA está segregada e que existe uma mentalidade de “atirar por cima do muro” que está a afetar a sua capacidade de avançar rapidamente. Assim que começar a definir esse fluxo de processo na sua organização, poderá procurar ferramentas que o ajudem.
Muitas organizações começam pelas ferramentas e, a partir daí, conduzem a mudança organizacional de forma lenta e dolorosa. É uma forma invertida de começar.
P: Existem desafios ou armadilhas comuns que as equipas DevOps devam considerar?
DevOps é uma forma de trabalhar. Em muitos aspetos, é a sequela da transformação ágil que varreu a indústria do desenvolvimento de software há várias décadas. É importante pensar dessa forma. Muitas organizações tiveram dificuldades com a transformação ágil devido à falta de compreensão e adesão por parte da liderança. Os líderes pensavam que começaríamos a fazer reuniões diárias e que concluiríamos mais 50 por cento das tarefas. Em retrospetiva, isso estava obviamente errado.
Da mesma forma, atualmente, os líderes pensam que só precisamos de um pipeline de CI/CD para superar as métricas Dora e que veremos uma produtividade de 50 por cento. A mudança de mentalidade é fundamental. O DevOps permite assumir total responsabilidade pelo ciclo de vida da entrega de software, o que permite às equipas criar sistemas melhores. O DevOps dá às equipas autonomia para identificar como melhorar e implementar essas melhorias, pelo que os líderes têm de criar esse espaço e dar esse apoio para conseguirem realmente observar os impactos organizacionais.
P: Como podem a colaboração e a comunicação eficazes entre os membros da equipa melhorar a produtividade e o sucesso de uma equipa DevOps, e que práticas podem facilitar isso?
A comunicação é fundamental na engenharia. Quase todos os problemas se resumem a uma comunicação deficiente, e o DevOps não é diferente. Retomando a importância de uma compreensão partilhada do que DevOps significa para a sua organização, é necessário compreender verdadeiramente para onde se dirige e ter essa visão partilhada para ter alguma hipótese de sucesso.
Algumas das práticas fundamentais que tenho observado passam por definir pontos de controlo simples no seu processo. Estes devem dizer respeito ao trabalho, e não às pessoas que o executam. Ter processos definidos para a forma como as tarefas e as informações circulam pela sua equipa permite-lhe ser eficiente na mudança de contexto, especialmente quando surgem interrupções no trabalho, e permite-lhe aumentar ou reduzir diferentes partes da sua equipa de forma independente.
Cada equipa e produto têm necessidades ligeiramente diferentes, e definir esses pontos de controlo e o que tem de acontecer em cada um deles ajudá-lo-á a perceber onde estão as suas ineficiências.
P: Que papel desempenha o CI/CD no DevOps e quais são as melhores práticas para implementar fluxos de CI/CD que garantam um processo de lançamento de software simples e fiável?
É fundamental levar as alterações de software da ideia à produção o mais rapidamente possível. Os processos manuais são extremamente lentos e estão à mercê dos seres humanos. Embora sejam excelentes em aspetos como a resolução de problemas e a criatividade, os seres humanos são frequentemente maus a percorrer exaustivamente listas de verificação centenas de vezes por dia. Automatizar as tarefas enfadonhas permite realmente que a sua equipa se concentre naquilo em que se destaca. Além disso, os computadores são excecionalmente rápidos e podem escalar rapidamente. Criar um fluxo que tire partido dessas capacidades é a principal vantagem de adotar um processo de CI/CD.
Um aspeto fundamental a ter em conta ao criar um processo deste tipo é equilibrar a velocidade com a segurança. Embora possa automatizar totalmente cada submissão de código de um programador diretamente para a produção, isso não oferece qualquer segurança. Criar o seu fluxo de modo a permitir esse nível de velocidade e adicionar gradualmente verificações pode ajudá-lo no futuro. Talvez, inicialmente, tudo tenha de ser explicitamente aprovado por um engenheiro de QA e por um engenheiro de lançamento, mas o processo em si pode consistir apenas no premir de um botão.
Depois de implementar os testes automatizados, poderá conseguir eliminar a aprovação do QA.
P: De que forma o desenvolvimento de uma cultura e de uma mentalidade DevOps contribui para o sucesso global de uma equipa DevOps e que estratégias podem as organizações utilizar para promover esta cultura entre as suas equipas de desenvolvimento e operações?
A principal batalha nesta transformação consiste em combater a mentalidade de “atirar para o outro lado do muro“. Se é novo nesta jornada, poderá ter cinco ou seis equipas que têm de tocar em cada parte do trabalho antes de este chegar à produção. À medida que avança para o DevOps, está a promover uma responsabilidade partilhada por todo o ciclo de vida desse produto.
Poderá ser necessário efetuar mudanças significativas na forma como concebe, cria e implementa a sua solução. Embora muitas pessoas estejam familiarizadas com a criação de software que seja mais fácil de testar, adotar uma cultura DevOps exige a criação de sistemas e plataformas pelos quais pequenas equipas assumam a responsabilidade de ponta a ponta.
P: Quais são os “5 componentes essenciais de uma equipa DevOps bem-sucedida”? Partilhe uma história ou um exemplo para cada um.
1. Uma compreensão partilhada do que o DevOps significa para a sua organização. – Uma das iniciativas DevOps mais contraproducentes ocorre quando a gestão e a equipa não estão alinhadas quanto aos resultados. O DevOps é muito mais do que simplesmente contratar engenheiros de “DevOps” e comprar uma ferramenta de CI/CD. Quando existe alinhamento quanto ao facto de se tratar de uma mudança de mentalidade, capacita as equipas para assumirem verdadeiramente a responsabilidade pela entrega de valor ao cliente de ponta a ponta
2. Espaço e apoio para identificar e implementar mudanças – As equipas DevOps identificam frequentemente muitas formas de melhorar a entrega e a eficiência da equipa. Não permitir espaço para esta exploração limita bastante o impacto que a sua equipa pode ter na promoção da mudança.
3. Formas de medir e identificar o sucesso através de dados – Todos estão familiarizados com as métricas DORA e com as quatro medidas fundamentais utilizadas para avaliar a maturidade DevOps da sua organização de desenvolvimento. Embora estas constituam um excelente ponto de partida, é necessário identificar o que significa ser uma organização DevOps para a sua empresa — e isso deve ser feito através de dados.
4. Um produto criado para apoiar a responsabilidade e o desenvolvimento desta filosofia – O DevOps é uma excelente filosofia para muitas organizações, mas as empresas frequentemente não estão preparadas para aceitar a transformação. É necessário garantir que o seu produto pode ser suportado por uma equipa conjunta de operações e desenvolvimento. Os produtos instalados nas instalações do cliente, os produtos com ciclos de lançamento rígidos e os produtos que simplesmente ainda não atingiram o nível de maturidade necessário para suportar uma equipa deste tipo podem não ser adequados. Irá observar alguns benefícios à medida que a sua equipa adota uma mentalidade mais operacional, mas os impactos serão limitados.
5. Automatização e ferramentas - Garanta que as tarefas acontecem de forma consistente e rápida e assegure a responsabilização pelo cumprimento dos acordos de trabalho. Uma das principais mudanças numa organização DevOps consiste nos acordos de trabalho que estabelece com a sua equipa e entre as suas equipas. Se estiver a estabelecer um processo de testes que exige que todo o código seja submetido a testes de regressão antes da implementação, deve automatizá-lo. Deve estabelecer verificações e barreiras automatizadas para garantir esse processo. Depois de estabelecer estas ferramentas e práticas, irá frequentemente descobrir que objetivos ambiciosos, como a implementação contínua, estão apenas a mais alguns passos de distância.
Certifique-se de que os testes não são apenas executados, mas também cumprem os seus padrões de qualidade.
More Articles
P: Que tendências emergentes prevê que possam ter um impacto significativo nas estratégias de transformação digital no futuro?
A maioria das grandes promessas de coisas como a transição para DevOps baseia-se em dados de alto nível e resultados abrangentes. Muitas vezes, estes números de destaque, como “a sua organização é 50 por cento mais eficiente”, são praticamente impossíveis de medir, e pode ser difícil verificar se alcançou esse tipo de resultados.
Espero ver um esforço mais direcionado para identificar resultados específicos para cada organização antes de iniciar uma jornada de transformação digital plurianual. Isto não só está alinhado com o maior enfoque na eficiência empresarial dos últimos anos, como também garante o sucesso. Em vez de objetivos abrangentes como os mencionados, objetivos específicos (mas impactantes), como “Resolvemos os problemas dos clientes 25 por cento mais depressa”, são mais direcionados.
Promover o crescimento através da mentoria
O poder da mentoria e da comunicação aberta é evidente na trajetória de Jeremy Freeman. Ao aprenderem ativamente com os outros e promoverem um ambiente colaborativo, os líderes podem capacitar as suas equipas de DevOps para alcançarem grandes resultados.
Subscreva a newsletter do The CTO Club para obter mais entrevistas, perspetivas sobre DevOps e dicas de mentoria!
