As arquiteturas sem servidor afetam fundamentalmente os fatores limitantes que restringem o desenvolvimento do produto.Os gerentes de produto da organização atuam em várias funções. Às vezes, eles são chamados de "voz do cliente"; outras, desempenham o papel de
"risco corporativo para gatos" . São irmãos de pele gorda, pessoas que inexoravelmente o levam a entregar o produto, apesar de qualquer ética ou desculpa. Um bom gerente de produto raramente se torna o ídolo de alguém, mas é graças ao trabalho dessas pessoas que a maioria das soluções tecnológicas que você já usou foi incorporada.
A PM está sempre procurando as ferramentas da mais alta qualidade para resolver o problema. Sabemos que os concorrentes estão constantemente pisando em seus calcanhares, os clientes estão cansados de esperar, por isso precisamos constantemente agir de forma mais inteligente, rápida e eficiente. Com o advento das tecnologias sem servidor, não ficou claro imediatamente como elas se encaixariam na lista de desejos de gerenciamento de produtos. No entanto, depois de trabalhar com essas tecnologias por um ano, vejo que elas resolvem alguns problemas de desenvolvimento de software que pareciam para sempre.
Paradoxo: tamanho e desempenho da equipe
A primeira regra do gerenciamento de produtos diz: a quantidade de trabalho a ser executado está em constante crescimento. A lista de pendências continua a aumentar e cai para zero em apenas um caso: quando o produto é eliminado. O mais difícil é transformar os elementos mais importantes do seu backlog em um produto pronto para entrega. Sendo todas as outras coisas iguais, acredita-se que a seguinte relação deva ser observada:
Se um escavador puder reciclar 1 tonelada de solo por dia - presume-se que 10 escavadores possam reciclar 10 toneladas. Como regra, o gerenciamento de recursos nas empresas é baseado neste princípio: se você deseja aumentar as vendas - contrate mais vendedores. Ao desenvolver software, quando a carteira de pedidos cresce, a tentação é simplesmente aumentar a equipe. No entanto, em casos com produtos e serviços complexos, aproximadamente o seguinte cronograma geralmente aparece com o tempo:
É raro ver como uma grande equipe trabalha no ritmo Stakhanov; mas muitas vezes acontece que uma pequena equipe com constância invejável progride aos trancos e barrancos.
Muitas startups têm esse tipo de erro: assim que o produto se torna bem-sucedido, mais novos desenvolvedores e gerentes são adicionados à equipe. Logo, de repente acontece que a velocidade começa a cair. Qual é o problema? Que os primeiros desenvolvedores eram mais talentosos, que a burocracia cresceu na empresa e como a arquitetura foi planejada?
Eu acho que todos esses são apenas sintomas, não a raiz do problema. O problema em si se resume à interação de três fatores críticos, dos quais apenas dois podem ser diretamente controlados:
- Fragilidade é o efeito de novas mudanças. Se um novo recurso afeta apenas parte da máquina, é fácil testar e implementar. Se isso afeta todos os elementos da máquina, o teste se torna mais difícil e ao mesmo tempo mais importante, e a implementação exige uma ordem de magnitude mais tempo.
- O volume de trabalho é o menor trabalho que pode ser realizado por uma equipe e fornece um recurso produtivo na saída. Por exemplo, o resultado é "Pague com Alexa" em vez de "se reunir e discutir como fazer pagamentos com Alexa".
- Complexidade - quanto conhecimento é necessário para implementar um recurso. Um desenvolvedor que sabe como escrever um recurso é capaz de fazer o mesmo na organização? Que mudanças adicionais devem ocorrer para que o progresso desacelere gradualmente e o produto deixe de crescer com recursos valiosos do ponto de vista do cliente?
Estou especialmente interessado em saber por que, no início da existência, todos esses fatores são equilibrados de maneira ideal: não há nada frágil, a quantidade de trabalho não é particularmente grande (e geralmente você pode concordar com o cliente), e a complexidade é praticamente ausente. Portanto, se uma equipe precisar criar um site compatível com o GDPR, terá tempo para pesquisar esse problema, uma decisão será tomada rapidamente e a equipe garantirá que o site funcione exatamente como planejado.
Nas empresas maiores, esses fatores são combinados, resultando em um tamanho crescente da equipe e o volume de trabalho realizado é reduzido. Para criar um site compatível com GDPR em uma empresa, você precisará da assinatura de um advogado, aprovação dos profissionais de marketing, aprovação do projeto no nível do conselho de administração, teste A / B da implementação menos disruptiva, coordenação das interrupções do desenvolvimento com a equipe de administradores, coordenação com os planos de implantação adotados por outras equipes - a lista continua. Mesmo com essa quantidade de controle e o número de processos, a equipe está muito menos confiante de que será bem-sucedida, devido à fragilidade de todo o sistema e muitas incógnitas no ecossistema.
Expandindo este exemplo para o tamanho de um projeto real, no qual pode haver dezenas de recursos e centenas de alterações, é fácil entender como, devido à influência desses fatores, o gráfico da proporção "tamanho da equipe / volume de trabalho" passa do primeiro para o segundo. À medida que a equipe cresce, você está fadado a fazer menos trabalho por unidade de tempo, não importa como tente superar o colosso organizacional. Ou parece que sim - mas o que, então, deve ser feito?
Como hackear todos os três fatores
Esse problema vem me assombrando há muitos anos, o que me levou a estudar as possíveis causas. É possível que as startups progridam rapidamente? Por um tempo, pensei assim, diante das dificuldades do gerenciamento de produtos em grandes organizações. No entanto, observei os três fatores mais de perto.
A fragilidade está sempre em seu prejuízo - provoca uma dívida técnica sempre crescente em qualquer projeto de qualquer tamanho. A situação lembra a "meia-vida, pelo contrário": qualquer elemento do programa cresce com o tempo e, por causa disso (durante o desenvolvimento), torna-se mais frágil, e tudo isso é composto a cada nova linha de código.
A quantidade de trabalho não está relacionada a um recurso específico do produto ("Pagar com Alexa"), mas a diferenças nos contornos da infraestrutura, se compararmos os estados "antes" e "depois". Quanto mais difícil o "depois" se torna, mais a quantidade de trabalho realizado é reduzida. É por isso que em muitas empresas, ao planejar o trabalho, a ênfase passa das necessidades do cliente ("Pague com Alexa") para as necessidades da organização ("Conheça e discuta quem deve estar envolvido na implementação do recurso" Pague com Alexa ").
Complexidade é uma combinação de fatores sociais, organizacionais e técnicos que afetam diretamente a duração de uma busca por um desenvolvedor adequado, a capacidade de tratar os programadores como pessoas multitarefas que podem ser encarregadas de qualquer trabalho. Além disso, é complexidade - o próprio aspecto que provavelmente permanecerá invisível, indocumentado e incompreendido. Um desenvolvedor pode escrever um aplicativo React em casa e liberá-lo, mas na organização ele precisará executar uma dúzia de etapas extras que levarão tempo, e os recursos interessantes para o usuário não serão alterados. O programador passará a maior parte do dia neles.
Juntos, esses três fatores formam um círculo vicioso, para que a quantidade de trabalho executado diminua, a fragilidade aumente, o desenvolvedor consiga concluir cada vez menos recursos e seu produto fique cheio de complexidade como uma lama invisível. Consequentemente, o crescimento da equipe não ajuda, e a velocidade só pode ser aumentada conscientemente com astúcia com números e indicadores. Um sintoma clássico: a posição "reunião realizada" aparece nos relatórios do sprint.
Nas grandes empresas, eu tive que observar algumas abordagens falhas, projetadas para quebrar esse ciclo. O primeiro é o "Agile em larga escala", resultando em grandes reuniões nas quais absolutamente todos os participantes no desenvolvimento de um determinado recurso participam e são feitas tentativas para coordenar o trabalho. Portanto, tente coordenar o trabalho e entender a complexidade. Essa abordagem é boa para empresas de distribuição de alimentos que oferecem almoços encantadores, mas, no nosso caso, não funciona. O fato é que, à medida que o tamanho do grupo de projetos prioritários aumenta, ele se torna cada vez mais e eles mesmos diminuem. Portanto, não é possível resolver fundamentalmente os problemas de fragilidade e complexidade. Com o tempo, o Agile em grande escala fornece uma lista tática de tarefas que se assemelham a uma lista de compras e são cada vez menos um caminho holístico de um recurso pensativo para outro.
Em segundo lugar, os “grupos de inovação” intra-corporativos geralmente tentam promover mudanças periféricas, na esperança de que esse trabalho se enraíze em uma máquina frágil e que toda a estrutura mude para melhor. Essa abordagem dá um efeito colateral bizarro: consolida-se a crença de que apenas esses "grupos de inovadores" têm o direito de fazer alterações no processo. Portanto, um método semelhante também não resolve problemas com a complexidade organizacional.
Tendo visto muitos anos de várias falhas, cheguei à conclusão de que é necessário hackear todos os três fatores, a fim de evitar o efeito combinado sobre o trabalho que está sendo realizado e lidar com a inércia:
- A fragilidade não deve aumentar em versões futuras ou à medida que o produto envelhece.
- O trabalho não deve ser menor do que o necessário para criar um recurso significativo do ponto de vista do usuário.
- A complexidade não deve afetar o trabalho de um único desenvolvedor.
Se você conseguir adotar essas idéias, estará protegido do rock, que persegue todos os produtos de software na história da humanidade. Parece ótimo, mas como isso pode ser alcançado?
Se você conseguir adotar essas idéias, estará protegido do rock, que persegue todos os produtos de software na história da humanidade. Parece ótimo, mas como isso pode ser alcançado?
Limitações de quebra de tecnologias sem servidor
Graças ao advento da tecnologia em nuvem, foi possível pavimentar trilhas importantes para um novo estado "hackeado". Em geral, com o advento das nuvens, o processo de entrega de um produto de software tornou-se mais compacto, pois um provedor começou a fazer muitas coisas rotineiras para você. Antes que as nuvens aparecessem, se você precisava implementar um novo recurso de usuário, era necessário solicitar um servidor, instalar equipamentos em racks, concordar em instalar redes em um data center e depois manter esse equipamento, que se desgasta com o tempo. Na nuvem, tudo isso pode ser alugado, eliminando dezenas de itens organizacionais e economizando meses inteiros.
Além disso, ao eliminar a necessidade de atualizar o equipamento em um data center e fornecer acesso ao hardware sob demanda, reduzimos a fragilidade e a complexidade. Colocar os programas em uso é muito mais fácil do que antigamente. No entanto, com o tempo, o ônus de administrar uma extensa infraestrutura virtual aumentou significativamente e muitos métodos de entrega desatualizados permaneceram inalterados. Usando as nuvens, a equipe pode aumentar significativamente antes que o trabalho comece a desacelerar - no entanto, começa a desacelerar, de um jeito ou de outro.
As tecnologias sem servidor alteram radicalmente essa dinâmica. O aplicativo sem servidor consiste em pequenos pedaços de código escritos por sua equipe (a chamada "cola") e "caixas pretas" funcionais que são gerenciadas pelo provedor de nuvem. A caixa preta simplesmente aceita uma configuração e reage às alterações. Em um aplicativo com uma arquitetura de alta qualidade, uma parte padrão do trabalho operacional associado à operação do aplicativo fica nas caixas-pretas padrão. O aplicativo em si não é mais uma função monolítica, mas uma estrutura federal de funções e caixas-pretas.
Na prática, isso afeta drasticamente os três fatores que mencionei acima:
- A fragilidade é reduzida devido a zero custo de gerenciamento de infraestrutura e fraca ligação. Em nossos próprios projetos, observou-se que a base de código como resultado de tais mudanças às vezes pode ser reduzida em dez vezes.
- O tamanho da "peça de trabalho" geralmente é comparável ao custo de criação de um novo recurso, pois torna-se trivial criar novas versões de funções ou funções completamente novas que não eram necessárias anteriormente.
- A complexidade não afeta o desenvolvedor - se ele pode escrever uma função que processa pagamentos com cartão de crédito, praticamente não há nada a fazer além desse código no aplicativo sem servidor, sem invólucros organizacionais e sem considerar o ecossistema, por causa do qual o trabalho pode desacelerar.
Ao gerenciar aplicativos muito grandes, sem servidor, é fácil para o gerente de produto examinar com mais atenção os poucos elementos que foram afetados pelas alterações feitas. Além disso, é fácil lançar duas versões competitivamente, colocando sinalizadores de recursos. Além disso, geralmente nem é necessário demolir versões antigas de código.
Em aplicativos sem servidor, a infraestrutura é sempre construída na periferia e você escreve apenas o código mínimo necessário que combina serviços totalmente gerenciados. Você nunca precisa pensar neles do ponto de vista operacional. Não estamos tentando controlar o monólito, limpar o código antigo ou visualizar o sistema inteiro do ponto de vista de um pássaro.
Por que é imensamente importante
À medida que o ritmo da mudança aumenta, fica cada vez mais difícil prever como o seu programa ficará no futuro ou o que os usuários desejarão de você. Portanto, as tentativas de escrever código "por séculos", de forma que ele funcione no futuro, apesar de quaisquer mudanças, tornam-se cada vez mais fúteis. Vimos como a reutilização de código é ruim na maioria das empresas e como a adesão a plataformas obsoletas diminui o progresso.
Agora, tudo está organizado para que o sistema antigo seja desenvolvido e mantido pelo maior tempo possível, até que o suporte comece a afastar o programador quase o tempo todo. Depois disso, a empresa recomeça com o novo sistema, prometendo solenemente não repetir os erros cometidos no antigo. Quando três fatores, mais cedo ou mais tarde, estrangulam o novo sistema, há um “incêndio florestal” tecnológico, após o qual novamente você precisa começar tudo de novo.
Estamos empolgados na luta contra os sintomas da complexidade, e é por isso que tantos paradigmas vêm e vão, sem deixar vestígios significativos na história do gerenciamento de produtos. O desenvolvimento sem servidor, por sua vez, permite que a equipe minimize o aumento da complexidade e continue a entregar um produto valioso em um ritmo bastante uniforme, sem cair nas armadilhas clássicas que durante décadas permaneceram o flagelo de qualquer desenvolvimento de software.
O paradigma sem servidor está apenas começando a se desenvolver, mas já parece extremamente promissor. No momento em que o cliente exige que você tenha novos recursos como nunca antes, os gerentes de produto podem finalmente adquirir uma plataforma que permite pensar com precisão com base na preparação de novos recursos. Esse processo não é dificultado pelo aumento da complexidade organizacional e também não para devido à fragilidade excessiva.