“Na minha função, chego a frequentar várias conferências, reuniões com clientes, palestras e muitas discussões onde o tema principal é… DevOps. Posso afirmar que, embora tenha havido um declínio na quantidade de pessoas me perguntando: ‘O que é DevOps?’, há uma questão que ainda perdura. Para muitos, a conversa passou a ser os desafios que as pessoas encontraram em suas adaptações DevOps”, conta Curtis Yanko, desenvolvedor da Sonatype.
Para ele, essa mesma questão é frustrante, então busca abordá-la sob uma nova perspectiva: ao invés de tentar “definir” DevOps, ele descreve o que vem a caracterizá-lo como tal. Ou, ainda mais recentemente, Yanko conta que tentou comparar e contrastar o DevOps com todas as outras “balas de prata” da tecnologia que vieram antes disso.
Em algum momento da carreira, conta Yanko, ele chegou à conclusão de que tinha custado a justificar tudo na TI com a partir da violação do axioma clássico no qual só se pode escolher dois caminhos. A consequência, segundo ele, é que pedimos continuamente uma nova ferramenta e depois explicamos como ela irá acelerar as coisas e, assim, economizar tempo e dinheiro. Então, descobriríamos como esse novo brinquedo melhoraria a qualidade, adicionando algumas novas capacidades ou tornando-se um processo mais confiável em comparação com o processo atual. Esses argumentos geralmente eram simples e fáceis de emplacar no espaço de entrega de aplicativos, multiplicando essa economia no número de de Devs ou QAs, o que nos permitiria produzir números de grande “benefício” para justificar os custos.
É apenas matemática simples, certo? Ironicamente, tudo isso choca-se com o paradoxo da produtividade – não deixe de ver: Nicole Forsgren, Professora Assistente da Utah State University, no DevOps Enterprise Summit 2014. Em suma, não é possível obter vantagens competitivas desses investimentos porque, basicamente, seu concorrente pode fazer os mesmos investimentos. Portanto, quaisquer ganhos não serão sustentáveis, e em vez disso, você estará apenas “se mantendo“. O que Yanko acrescenta é que muitos desses investimentos foram feitos isoladamente, impactando frequentemente um determinado conjunto de pessoas.
Um exemplo simples dessa limitação é o seguinte: investimos em uma ferramenta para melhorar ou adicionar uma habilidade a uma pessoa que, por sua vez, melhora um processo. Grandes esforços são investidos no processo, como agile, e depois são adotadas ferramentas e pessoas são treinadas para as habilidades de que precisam para abranger um conjunto mais amplo de pessoas. O tema recorrente aqui é que as pessoas são todas suas “habilidades“. Elas entendem todas as ferramentas e processos necessários para que possam oferecer valor? Muitos desses investimentos de TI suscitaram preocupações de que as pessoas atualmente não possuíam as habilidades necessárias, então agora precisamos de treinamento ou precisamos contratar de fora.
Depois de um tempo, você começa a ver as pessoas sob a ótica taylorista – em referência ao engenheiro norte-americano Frederick Winslow Taylor, para quem é possível alcançar o máximo de produção e rendimento com o mínimo de tempo e de esforço. Ou seja, elas passam a representar uma coleção de habilidades que lhes permitem fazer seu trabalho em uma pequena seção da cadeia de valor, intencionalmente isolada do restante da cadeia.