Habilidades de vida DevOps: Compreendendo e gerenciando o processo de aquisição
Em um blog anterior, falei sobre por que é importante adotar uma abordagem de "pensamento sistêmico" para a entrega de aplicativos, operando mais como uma fábrica bem ajustada e otimizada para entrega de valor eficiente. Chegar lá significa avaliar as ferramentas nas quais você confia, bem como o processo pelo qual você as seleciona e adquire. A eficiência exige priorizar padrões reutilizáveis sempre que possível, bem como selecionar ferramentas e processos que sejam consistentes entre equipes e ambientes. Isso faz sentido em teoria para a maioria das pessoas, especialmente quando as ferramentas em questão são relacionadas à infraestrutura ou segurança, com impacto mínimo na função do aplicativo. No entanto, uma barreira subestimada à construção de tais padrões muitas vezes atrapalha: O fornecedor e o processo de aquisição.
Atualmente, não é incomum que engenheiros de DevOps usem ferramentas nativas da nuvem, soluções de código aberto ou outros tipos de recursos baratos (ou gratuitos) que não exigem investimento significativo ou interação com a equipe de compras. Mas e se você precisar defender um investimento em TI mais rico para impulsionar as eficiências necessárias, bem como garantir melhor segurança e desempenho para seus aplicativos?
Apresentando o caso para investimento em TI
Aqui estão algumas coisas que os profissionais de DevOps devem ter em mente enquanto navegam pelas águas desconhecidas do processo de aquisição.
- Foco no valor
Se você está lendo este blog, provavelmente prefere se concentrar nas capacidades tecnológicas do que é necessário, pode falar sobre APIs o dia todo e é obcecado por otimização. Mas adivinhe: seus colegas responsáveis por assinar os cheques grandes provavelmente não dão a mínima para nada disso. É por isso que a coisa mais importante que você pode fazer para apoiar a compra de uma nova ferramenta ou recurso é articular — nos termos deles — o valor comercial que isso trará.
Muitas vezes, isso começa com a identificação do que está faltando ou faltando no momento. Pedir para comprar uma nova ferramenta simplesmente porque ela já está disponível não é tão convincente quanto destacar uma falha ou responsabilidade significativa, descrevendo as maneiras pelas quais essa falha cria problemas (retarda a produção, expõe vulnerabilidades, etc.) e, então, propor uma nova ferramenta que resolverá tudo.
Os três elementos principais nos quais se deve focar são custo, valor e risco. É importante falar sobre isso em termos comerciais — como uma solução específica resolve o problema identificado por:
- Redução de custos em um período de curto, médio ou longo prazo
- Como o negócio pode aumentar a agilidade, acelerar o tempo de colocação no mercado ou atrair novos clientes
- Como o risco empresarial é reduzido com melhor conformidade regulatória, risco reduzido de ataque ou mesmo algo que reduza a exposição competitiva
Em todos eles, é muito importante quantificar cada um deles da melhor forma possível. Ninguém quer opiniões puramente qualitativas. Dados concretos são importantes.
Para seus colegas de Compras (e mais amplamente nas equipes de Finanças), tudo tem um custo e um valor. Isso inclui o custo de não fazer nada (diante de problemas conhecidos), bem como o valor de libertar os trabalhadores de lidar com esses problemas. Esteja ciente de que, embora o NetOps possa encontrar valor na eliminação de tarefas mundanas simplesmente porque isso torna o trabalho menos tedioso, as equipes financeiras veem valor em liberar esses mesmos engenheiros para se concentrarem em iniciativas estratégicas de geração de receita.
Will Marken, gerente de soluções técnicas da F5, sugere que você “ se posicione como um solucionador de problemas; ao se concentrar em entregar valor, vincule a solução proposta às aspirações corporativas — isso mostra que você pode interagir com a gerência nos termos dela e falar sobre suas necessidades”.
- Conheça o jargão: CapEx vs. assinatura
- Seja persistente
- Divida em pedaços
- Junte-se a uma equipe
Sua equipe pode estar totalmente interessada em comprar uma solução por meio de um modelo de assinatura e então descobrir que sua organização está alinhada a grandes despesas de CapEx e não tem um processo para financiar investimentos em TI com base em assinatura. Nesse caso, você tem algum trabalho adicional a fazer. Pode ser mais fácil mudar para uma solicitação de orçamento de despesas de capital (por exemplo, uma única compra grande que será amortizada ao longo do tempo). Por outro lado, mesmo as empresas que demoraram a adotar modelos de assinatura estão descobrindo como dar suporte a eles. Talvez você só precise reservar um tempo extra enquanto seus colegas de finanças trabalham em seus próprios desafios de processos organizacionais.
Por mais clichê que pareça, este é realmente um daqueles momentos em que o que importa é a jornada, não o destino. Justificar grandes compras geralmente exige várias tentativas. Na verdade, sua solicitação pode muito bem estar competindo com outras que já estão circulando há dois ou três ciclos orçamentários, refinando o foco e reunindo apoio ao longo do caminho. Não desista quando ouvir "Não". Em vez disso, planeje-se, aceite-o quando chegar e siga em frente com os ajustes a partir daí.
Encare a aquisição como você faria com qualquer outra tarefa no seu fluxo de trabalho Agile. Identifique os problemas; resolva-os um por um; e repita, repita, repita.
Para grandes solicitações de orçamento, geralmente é útil dividir seu projeto em partes mais digeríveis. Isso pode ser útil por dois motivos: a) É mais fácil criar uma POC (prova de conceito) plausível e identificar valor no mundo real quando há um foco mais específico; e b) é simplesmente mais fácil para os responsáveis aprovarem solicitações menores.
Há todo tipo de razões pelas quais é uma boa ideia pedir ajuda a outras pessoas na organização. Para começar, seus colegas diretos ou de outras equipes podem estar mais familiarizados com o processo de aquisição em geral — e com o valor das soluções F5 em particular — e, portanto, podem ajudá-lo a enquadrar a solicitação (e evitar riscos conhecidos). Você também pode reduzir o risco percebido mostrando como sua solução proposta impactará positivamente vários departamentos. Por fim, não é incomum (especialmente em organizações muito grandes) descobrir que outro grupo já tentou uma solicitação semelhante à sua (nesse caso, você pode aprender com eles) ou pode até ter começado a implementar uma solução semelhante (nesse caso, você pode fazer parceria com eles).
Uma nota sobre a estrutura
Ao assumir a criação de uma solicitação de orçamento, você pode contar com muitas das mesmas táticas que usaria para criar documentos mais típicos para sua área, como white papers e planilhas de dados. Isso começa com a descoberta do modelo apropriado para que você tenha certeza de que sua solicitação terá a mesma aparência e leitura de outras solicitações com as quais o gerente está familiarizado. Também inclui apresentá-lo a vários colegas para obter informações e feedback durante o processo. Jon Gross, gerente de desenvolvimento de produtos da F5, acrescenta que “ assim como acontece com planilhas de dados e white papers, o sucesso geralmente depende da descrição ou do parágrafo de abertura”. Ele sugere que você “ procure arquiteturas de referência e casos de uso existentes que possam reforçar seu roteiro de implementação com pontos de dados do mundo real”.