O Technology Radar da Thoughtworks identifica alguns temas de destaque em cada edição, mas tende a se concentrar em recomendações bastante específicas. As discussões que temos ao decidir sobre essas recomendações, entretanto, geralmente sugerem coisas maiores acontecendo no setor de tecnologia. Então, vou, neste artigo, expandir essa conversa. .
Nós, da indústria de software, estamos em uma posição confortável para lidar com o trabalho em casa, mas não estamos imunes à realidade de escolas fechadas, de creches indisponíveis e de estresse generalizado induzido pela pandemia. É especialmente importante ser tolerante com as circunstâncias individuais, pois nem todas as pessoas têm o privilégio de ter um escritório em casa, ou crianças que já são capazes de cuidar de si próprias.
Nas primeiras semanas, houve uma corrida por infraestrutura básica, acessos e ferramentas, mas agora o básico já está em vigor. A colaboração remota está mudando de "conseguimos fazer isso?" para "qual é o caminho certo para fazer isso?" e há muito a ser aprendido aqui. Muitas pessoas estão se dando conta que estar disponível em vídeo o dia inteiro é desgastante, e que traduzir técnicas de colaboração presencial para o mundo digital não é uma prática muito efetiva. Em vez disso, devemos pensar cuidadosamente em quando as equipes realmente precisam estar online, quando a colaboração assíncrona pode ser usada e quais ferramentas de facilitação digital funcionam melhor para o nosso contexto. Produzimos o Radar remotamente devido à pandemia e aprendemos muito no processo; se você se interessar em saber mais, gravamos um podcast detalhado sobre nossas experiências.
A Thoughtworks é uma forte defensora da programação em pares e incluímos o "pareamento remoto pragmático" nesta edição do Radar.
A pandemia mostrou a cada CIO as falhas em sua infraestrutura digital, seja a resiliência e a escala à medida que clientes se migraram para o online, ou a capacidade de fazer mudanças rapidamente, adicionar recursos e colocá-los em produção. A maioria das organizações se deu conta da verdade inconveniente: elas estão muito atrás do estado da arte e estão lutando para executar a "transformação digital" (seja lá o que isso significar) para alcançá-lo.
Como consultoria, temos uma visão bastante ampla do setor e algumas das mudanças foram bastante positivas. Clientes que diziam anteriormente “vocês devem trabalhar no escritório, com nosso hardware” flexibilizaram sua posição. O tempo presencial foi substituído pelo tempo de face-a-face virtual. Em alguns casos, esse é um enorme benefício: nossas clientes podem acessar uma rede global de especialistas e não importa onde essa pessoa esteja localizada (respeitando fusos horários, evidentemente). O interessante é que, embora em teoria nossas clientes pudessem acessar essas pessoas antes da pandemia, há muito menos resistência em fazê-lo agora. Não há expectativa de que alguém apareça pessoalmente; portanto, não temos nenhuma relutância em sugerir uma especialista não-local para ajudar uma cliente. Espero que, em todo o setor, possamos trabalhar mais remotamente no futuro, em vez de embarcar em aviões o tempo todo.
O Prof. Tom Malone (MIT) acredita que a atual crise nos acelerou em uma década em termos de aceitação do trabalho remoto, e que não há como voltar atrás. O espaço para escritórios no centro da cidade se tornará menos valioso, pois as pessoas vão decidir que preferem trabalhar em casa ou em um pequeno escritório no bairro do que gastar uma hora até o trabalho. As empresas de tecnologia esperam ter uma grande parcela de profissionais trabalhando remotamente mesmo após a crise, talvez até 70% da equipe permanentemente.
As conferências de tecnologia também se tornaram totalmente virtuais e estão inovando de maneiras realmente interessantes. Um exemplo é o Deserted Island DevOps, uma conferência de um dia organizada inteiramente dentro do jogo Animal Crossing New Horizons. Palestrantes e participantes usaram avatares no jogo para visitar as ilhas da conferência e conseguiram criar algumas das interações em grupos menores que tanto valorizamos nas conferências físicas.
Um aspecto positivo de todo mundo ficar em casa e das indústrias fechadas é que, embora temporariamente, reduzimos a poluição. Algumas estimativas dizem que as emissões de carbono em 2020 podem ser reduzidas em até 8%. As energias renováveis continuam aumentando sua participação de mercado, superando pela primeira vez o carvão na geração de energia nos EUA. Estamos dirigindo menos, com as cidades vendo fluxos de tráfego aprimorados e acidentes reduzidos. O estado da Califórnia reduziu pela metade os acidentes de trânsito, economizando US$ 40 milhões por dia, ou cerca de US$ 1 bilhão desde o início do pedido de distanciamento no local. É possível que o coletivismo e a confiança na ciência necessários para combater um vírus invisível também possam nos ajudar a fazer mais para combater as mudanças climáticas no futuro.
Embora os custos humanos e econômicos da pandemia continuem sendo muito sérios, espero que a indústria de tecnologia possa usá-la como uma oportunidade para acelerar, reduzir o consumo excessivo de carbono com viagens e aumentar a inclusão e a inovação.
Um bom exemplo disso é "infraestrutura como código". Esse é um conselho bastante antigo, originalmente adicionado ao Radar em 2011. Nosso colega Kief Morris publicou um livro detalhado sobre o assunto em 2016, com uma cópia atualizada a ser lançada ainda este ano. Hoje, estamos vendo muitas organizações enfrentando problemas com suas migrações para nuvem, em parte porque não estão aplicando rigor suficiente às definições, gerenciamento e automação da infraestrutura de nuvem. Portanto, em vez de colocar "modelos de nuvem criados à mão" ou "falhar ao estabelecer controle de versão para as definições de infraestrutura de nuvem" em "Evite", aproveitamos a oportunidade para atualizar e reforçar nossos conselhos sobre o assunto. Da mesma forma, alteramos e atualizamos novamente pipelines como código.
Muito disso ocorre porque uma das principais narrativas da década passada foi a ascensão do software, a ascensão da nuvem e a ascensão do “como serviço”. Tudo isso nos permite usar software facilmente maleável, ou descrições de algo, em vez de uma instanciação física ou codificada que é mais lenta para mudar. Como resultado, todas as práticas importantes que aprendemos sobre como criar software — modularidade, controle de versão, testes automatizados — podem e devem ser aplicadas nesses contextos mais amplos "alimentados por software".
Em primeiro lugar, costuma haver o que eu chamaria de economia de custos "altamente otimista" e projeções de ROI para migração na nuvem. Sim, possuir e operar um data center é caro, mas a hospedagem na nuvem também não é barata. É improvável que você realmente economize algo em custos de pessoal. E quando o limite de uso é a rapidez com a qual as equipes podem clicar no botão "criar uma instância", em vez de provisionar um servidor para TI, a expansão geral do ambiente pode se tornar um problema enorme e caro.
Em segundo lugar, a abordagem de "lift and shift" é frequentemente usada como uma estratégia deliberada de migração, em vez de um comentário depreciativo de que alguém não está pensando cuidadosamente sobre sua migração. As propriedades corporativas de TI têm muitas centenas, e geralmente milhares, de sistemas individuais que precisam ser executados em algum lugar. A reengenharia de todos eles para entender e operar adequadamente em um ambiente de nuvem é obviamente custo proibitivo. Mas a hospedagem na nuvem não é como a hospedagem local — os servidores falham, as cargas de trabalho são constantemente deslocadas. Conseguir que uma carga de trabalho tradicional seja executada de forma confiável na nuvem também não é um empreendimento de custo zero. A realidade é que a melhor resposta para uma organização é altamente complexa e varia para cada aplicação ou grupo de aplicações, e quanto mais podemos reprojetar para nuvem, mais podemos melhorar a confiabilidade e reduzir os custos.
E terceiro lugar, e muito relacionado com os dois primeiros pontos, é que ainda há muito a aprender sobre a maneira correta de criar e executar sistemas na nuvem. Muitas organizações estão descobrindo que "estar na nuvem" não as ajudou a lidar com o aumento da demanda devido à pandemia e às medidas de isolamento associadas, não as ajudou a liberar novos recursos mais rapidamente. A arquitetura em nuvem é um novo e difícil campo de especialização, e as equipes precisam aprender como implantar, evoluir, manter e melhorar seus sistemas baseados em nuvem. Isso é algo que leva tempo e muito mais reflexão do que simplesmente "basta jogar as coisas na Amazon".
O termo com significado mais subjetivo hoje é provavelmente "transformação digital". Dependendo de quem o está usando, pode significar qualquer uma das seguintes coisas:
Espero que você tenha gostado desse resumo das tendências do setor de tecnologia, e que esteja se mantendo em segurança e saudável. Gostaria de agradecer a Andy Yates, Fausto de la Torres, Gareth Morgan, Kief Morris e Rebecca Parsons por suas sugestões nos rascunhos deste artigo.
Tudo remoto, em um futuro próximo
Como eu, você provavelmente não aguenta mais ler comentários exagerados relacionados à pandemia. Mas as implicações da COVID-19 para a indústria de tecnologia são grandes, e as coisas jamais voltarão a ser como eram antes da crise. Estes são o que considero os fatos mais importantes e possíveis mudanças.Nós, da indústria de software, estamos em uma posição confortável para lidar com o trabalho em casa, mas não estamos imunes à realidade de escolas fechadas, de creches indisponíveis e de estresse generalizado induzido pela pandemia. É especialmente importante ser tolerante com as circunstâncias individuais, pois nem todas as pessoas têm o privilégio de ter um escritório em casa, ou crianças que já são capazes de cuidar de si próprias.
Nas primeiras semanas, houve uma corrida por infraestrutura básica, acessos e ferramentas, mas agora o básico já está em vigor. A colaboração remota está mudando de "conseguimos fazer isso?" para "qual é o caminho certo para fazer isso?" e há muito a ser aprendido aqui. Muitas pessoas estão se dando conta que estar disponível em vídeo o dia inteiro é desgastante, e que traduzir técnicas de colaboração presencial para o mundo digital não é uma prática muito efetiva. Em vez disso, devemos pensar cuidadosamente em quando as equipes realmente precisam estar online, quando a colaboração assíncrona pode ser usada e quais ferramentas de facilitação digital funcionam melhor para o nosso contexto. Produzimos o Radar remotamente devido à pandemia e aprendemos muito no processo; se você se interessar em saber mais, gravamos um podcast detalhado sobre nossas experiências.
A Thoughtworks é uma forte defensora da programação em pares e incluímos o "pareamento remoto pragmático" nesta edição do Radar.
Resumidamente, o pareamento pode absolutamente ser feito em um mundo remoto, mas você precisa considerar ferramentas, largura de banda e fusos horários.
A pandemia mostrou a cada CIO as falhas em sua infraestrutura digital, seja a resiliência e a escala à medida que clientes se migraram para o online, ou a capacidade de fazer mudanças rapidamente, adicionar recursos e colocá-los em produção. A maioria das organizações se deu conta da verdade inconveniente: elas estão muito atrás do estado da arte e estão lutando para executar a "transformação digital" (seja lá o que isso significar) para alcançá-lo.
Como consultoria, temos uma visão bastante ampla do setor e algumas das mudanças foram bastante positivas. Clientes que diziam anteriormente “vocês devem trabalhar no escritório, com nosso hardware” flexibilizaram sua posição. O tempo presencial foi substituído pelo tempo de face-a-face virtual. Em alguns casos, esse é um enorme benefício: nossas clientes podem acessar uma rede global de especialistas e não importa onde essa pessoa esteja localizada (respeitando fusos horários, evidentemente). O interessante é que, embora em teoria nossas clientes pudessem acessar essas pessoas antes da pandemia, há muito menos resistência em fazê-lo agora. Não há expectativa de que alguém apareça pessoalmente; portanto, não temos nenhuma relutância em sugerir uma especialista não-local para ajudar uma cliente. Espero que, em todo o setor, possamos trabalhar mais remotamente no futuro, em vez de embarcar em aviões o tempo todo.
O Prof. Tom Malone (MIT) acredita que a atual crise nos acelerou em uma década em termos de aceitação do trabalho remoto, e que não há como voltar atrás. O espaço para escritórios no centro da cidade se tornará menos valioso, pois as pessoas vão decidir que preferem trabalhar em casa ou em um pequeno escritório no bairro do que gastar uma hora até o trabalho. As empresas de tecnologia esperam ter uma grande parcela de profissionais trabalhando remotamente mesmo após a crise, talvez até 70% da equipe permanentemente.
As conferências de tecnologia também se tornaram totalmente virtuais e estão inovando de maneiras realmente interessantes. Um exemplo é o Deserted Island DevOps, uma conferência de um dia organizada inteiramente dentro do jogo Animal Crossing New Horizons. Palestrantes e participantes usaram avatares no jogo para visitar as ilhas da conferência e conseguiram criar algumas das interações em grupos menores que tanto valorizamos nas conferências físicas.
Um aspecto positivo de todo mundo ficar em casa e das indústrias fechadas é que, embora temporariamente, reduzimos a poluição. Algumas estimativas dizem que as emissões de carbono em 2020 podem ser reduzidas em até 8%. As energias renováveis continuam aumentando sua participação de mercado, superando pela primeira vez o carvão na geração de energia nos EUA. Estamos dirigindo menos, com as cidades vendo fluxos de tráfego aprimorados e acidentes reduzidos. O estado da Califórnia reduziu pela metade os acidentes de trânsito, economizando US$ 40 milhões por dia, ou cerca de US$ 1 bilhão desde o início do pedido de distanciamento no local. É possível que o coletivismo e a confiança na ciência necessários para combater um vírus invisível também possam nos ajudar a fazer mais para combater as mudanças climáticas no futuro.
Embora os custos humanos e econômicos da pandemia continuem sendo muito sérios, espero que a indústria de tecnologia possa usá-la como uma oportunidade para acelerar, reduzir o consumo excessivo de carbono com viagens e aumentar a inclusão e a inovação.
X também é software
Para mim, algumas das discussões mais interessantes (e divertidas!) ao redor do Radar são sobre o que colocar no anel "Evite". Thoughtworkers de todo o mundo levantam coisas que consideram problemas e, se concluirmos que algo é uma preocupação intersetorial, nós adicionamos no Radar como "Evite". Mas, ao analisarmos o raciocínio e as preocupações em torno de vários blips sugeridos como "Evite", ficou evidente para nós que alguns desses problemas não são novos, são um problema mais antigos que surgem em um contexto novo (ou mais amplo). Em muitos casos, nosso conselho anterior sobre a coisa certa a fazer — a prática positiva a ser "adotada" — ainda é relevante hoje.Um bom exemplo disso é "infraestrutura como código". Esse é um conselho bastante antigo, originalmente adicionado ao Radar em 2011. Nosso colega Kief Morris publicou um livro detalhado sobre o assunto em 2016, com uma cópia atualizada a ser lançada ainda este ano. Hoje, estamos vendo muitas organizações enfrentando problemas com suas migrações para nuvem, em parte porque não estão aplicando rigor suficiente às definições, gerenciamento e automação da infraestrutura de nuvem. Portanto, em vez de colocar "modelos de nuvem criados à mão" ou "falhar ao estabelecer controle de versão para as definições de infraestrutura de nuvem" em "Evite", aproveitamos a oportunidade para atualizar e reforçar nossos conselhos sobre o assunto. Da mesma forma, alteramos e atualizamos novamente pipelines como código.
Muito disso ocorre porque uma das principais narrativas da década passada foi a ascensão do software, a ascensão da nuvem e a ascensão do “como serviço”. Tudo isso nos permite usar software facilmente maleável, ou descrições de algo, em vez de uma instanciação física ou codificada que é mais lenta para mudar. Como resultado, todas as práticas importantes que aprendemos sobre como criar software — modularidade, controle de versão, testes automatizados — podem e devem ser aplicadas nesses contextos mais amplos "alimentados por software".
A nuvem é a nova bola de neve legada
Todas as organizações do mundo estão migrando para algum tipo de hospedagem em nuvem, privada, pública ou híbrida, e a grande maioria está escolhendo entre as "Big 4" - AWS, Azure, GCP e Alicloud. Mas, em sua exuberância em hospedar os sistemas fora da empresa e na nuvem, muitas podem estar criando problemas para o futuro. Existem várias questões a se considerar.Em primeiro lugar, costuma haver o que eu chamaria de economia de custos "altamente otimista" e projeções de ROI para migração na nuvem. Sim, possuir e operar um data center é caro, mas a hospedagem na nuvem também não é barata. É improvável que você realmente economize algo em custos de pessoal. E quando o limite de uso é a rapidez com a qual as equipes podem clicar no botão "criar uma instância", em vez de provisionar um servidor para TI, a expansão geral do ambiente pode se tornar um problema enorme e caro.
Em segundo lugar, a abordagem de "lift and shift" é frequentemente usada como uma estratégia deliberada de migração, em vez de um comentário depreciativo de que alguém não está pensando cuidadosamente sobre sua migração. As propriedades corporativas de TI têm muitas centenas, e geralmente milhares, de sistemas individuais que precisam ser executados em algum lugar. A reengenharia de todos eles para entender e operar adequadamente em um ambiente de nuvem é obviamente custo proibitivo. Mas a hospedagem na nuvem não é como a hospedagem local — os servidores falham, as cargas de trabalho são constantemente deslocadas. Conseguir que uma carga de trabalho tradicional seja executada de forma confiável na nuvem também não é um empreendimento de custo zero. A realidade é que a melhor resposta para uma organização é altamente complexa e varia para cada aplicação ou grupo de aplicações, e quanto mais podemos reprojetar para nuvem, mais podemos melhorar a confiabilidade e reduzir os custos.
E terceiro lugar, e muito relacionado com os dois primeiros pontos, é que ainda há muito a aprender sobre a maneira correta de criar e executar sistemas na nuvem. Muitas organizações estão descobrindo que "estar na nuvem" não as ajudou a lidar com o aumento da demanda devido à pandemia e às medidas de isolamento associadas, não as ajudou a liberar novos recursos mais rapidamente. A arquitetura em nuvem é um novo e difícil campo de especialização, e as equipes precisam aprender como implantar, evoluir, manter e melhorar seus sistemas baseados em nuvem. Isso é algo que leva tempo e muito mais reflexão do que simplesmente "basta jogar as coisas na Amazon".
A difusão semântica continua se expandindo
Sem querer parecer muito um velho gritando com as nuvens, devo salientar que a indústria continua adotando e usando indevidamente termos com significados específicos. Há muito tempo fico irritado com as pessoas desenvolvedoras que usam "refatoração" no sentido de "consertar algo", e hoje vemos o mesmo com termos como "CI/CD" (as duas são coisas diferentes!), "DevOps" (por favor, não crie um "time de DevOps"), "microsserviços" (no que diferente de SOA?) e "como código" (é assim que você trataria seu código?).O termo com significado mais subjetivo hoje é provavelmente "transformação digital". Dependendo de quem o está usando, pode significar qualquer uma das seguintes coisas:
- Aprimorar o conhecimento digital de pessoas da empresa
- Adotar melhores ferramentas de colaboração, como Zoom, Teams, Trello e Slack
- TI Ágil
- Transformação holística dos negócios, alavancando o poder da tecnologia para criar mais valor para clientes e responder a mudanças com rapidez em um cenário competitivo
Espero que você tenha gostado desse resumo das tendências do setor de tecnologia, e que esteja se mantendo em segurança e saudável. Gostaria de agradecer a Andy Yates, Fausto de la Torres, Gareth Morgan, Kief Morris e Rebecca Parsons por suas sugestões nos rascunhos deste artigo.
Aviso: As afirmações e opiniões expressas neste artigo são de responsabilidade de quem o assina, e não necessariamente refletem as posições da Thoughtworks.