Construindo processos melhores - Parte I: Os processos devem ser orientados por ferramentas ou por requisitos?

Este artigo analisará por que, conceitualmente, os processos devem ser orientados por requisitos. Também abordará como definir metas para alcançar processos que reflitam os requisitos, de modo a trabalhar de trás para frente em direção a um resultado ideal. A Parte 2 fornecerá algumas orientações sobre como ponderar os requisitos e incorporá-los à sua visão de como os processos devem, em última análise, ser.

Ao construir processos Agile para DevOps Em organizações em processo de transformação digital, os líderes de TI querem se concentrar na otimização. Os processos ideais contemplam todas as entregas necessárias, incorporam prioridades como governança e buscam a criação de valor mais eficiente possível — tudo isso permitindo melhorias iterativas tanto no produto quanto no próprio processo. 

No entanto, muitos líderes de TI podem se deparar com um obstáculo: as ferramentas. DevOps As equipes tendem a ditar o fluxo de trabalho e a arquitetura do pipeline de ponta a ponta. Isso as deixa com a seguinte dúvida: devo ceder e deixar que os ambientes de ferramentas ditem nossa estrutura de processos? Ou essa estrutura deve ser continuamente avaliada à luz dos nossos requisitos reais de objetivo?

Para responder diretamente à pergunta do título: os processos devem ser orientados por requisitos, ponto final. Se os requisitos não forem atendidos, isso pode afetar negativamente o produto e impedir que a organização alcance seu pleno potencial produtivo. Os funcionários enfrentarão frustrações e muita energia será gasta simplesmente interagindo com o processo, em vez de criar valor mensurável para os clientes finais e as partes interessadas internas.

Chegar ao ponto em que os requisitos podem direcionar o processo.

Dizer que “tudo deve ser orientado por requisitos” é fácil, mas isso significa que as organizações precisam dedicar tempo a fazer brainstorming, pesquisar e desenvolver um método para quantificar os requisitos de fato. Os requisitos também devem ser baseados em critérios que, em última análise, garantam a criação de produtos de maior valor agregado e que o trabalho interno possa produzir resultados de qualidade de forma eficiente e consistente.

Insistir que os processos reflitam os requisitos não impede o uso de ferramentas específicas. Isso é especialmente verdadeiro em setores que podem precisar de ferramentas específicas, como uma ferramenta de monitoramento de conformidade para o desenvolvimento de software aeroespacial e de defesa. Nesses casos, porém, as próprias ferramentas importam porque não há outros meios disponíveis para atender aos requisitos.

Outro desafio que as organizações podem enfrentar é que é mais fácil navegar pelas soluções produto por produto do que procurar critérios ou funcionalidades que atendam a requisitos específicos. Muitas vezes, as organizações precisam trabalhar de trás para frente, partindo de um requisito para descobrir quais funcionalidades e critérios da ferramenta são necessários para que seus requisitos sejam atendidos. Por fim, uma organização pode ter que abrir mão de alguns requisitos para atender a outros. 

Mesmo com esses desafios reconhecidos, o objetivo geral de criar um novo processo ou revisar um existente deve ser não deixar que as ferramentas (ou seus recursos atraentes) ditem a arquitetura do seu processo. DevOps pipeline. Em vez disso, deixe que os requisitos controlem essa arquitetura e concentre-se intensamente nos resultados que suas equipes desejam. Em seguida, faça perguntas difíceis sobre quais mudanças de processo precisam ser feitas para descobrir quais ferramentas podem melhor atender às necessidades das equipes.

As organizações enfrentam opções limitadas, o que as força a trabalhar de trás para frente, partindo dos requisitos para a comparação de ferramentas.

Garantir que seus processos sejam totalmente orientados por requisitos pode não parecer realista em um mundo orientado a produtos. Soluções pré-fabricadas e prontas para uso geralmente oferecem apenas um conjunto específico de recursos e funcionalidades. Nos casos em que uma solução pode ser personalizada, as organizações normalmente ficam limitadas a um menu de opções.

As organizações também podem optar por criar soluções personalizadas do zero, mas isso pode ser caro se implementado em todos os processos. A organização pode se sentir obrigada a "reinventar a roda" e construir um pipeline peça por peça quando, em vez disso, deveria estar construindo um produto que agregue valor. 

Além disso, a organização pode não saber exatamente quais funcionalidades desenvolver nessas soluções proprietárias. A menos que sejam elas próprias fornecedoras de soluções, não podem inventar especificações do nada. Devem basear-se principalmente em soluções existentes para definir o rumo da configuração de suas alternativas internas. Há algumas exceções notáveis ​​em que uma equipe criou uma arquitetura completamente nova (veja o Slack), mas, em muitos casos, as empresas simplesmente tentam construir sua própria versão de soluções existentes, frequentemente com uma combinação de funcionalidades das ferramentas mais populares.

Portanto, os processos de uma organização inevitavelmente refletirão as ferramentas que ela utiliza, sejam elas compradas ou desenvolvidas internamente. Diante disso, torna-se uma batalha árdua manter os requisitos em primeiro plano nas decisões de aquisição ou nas mudanças de processo — mas essa é uma batalha crucial. Caso contrário, as ferramentas acabam ditando os fluxos de trabalho e definindo as expectativas de desempenho. As equipes acabam sentindo que o produto do seu trabalho está limitado às capacidades das ferramentas, em vez de uma visão final do resultado que seus processos produzem.

Torne seus processos orientados a requisitos, seja na busca por soluções ou na construção de um DevOps oleoduto, ou reformular seu oleoduto atual.

É inegavelmente difícil focar-se inteiramente nos requisitos quando as opções disponíveis obrigam a concentrar-se em conjuntos de funcionalidades ou capacidades específicas. Mesmo ao construir do zero ou ao personalizar, as organizações muitas vezes sentem-se limitadas a abordagens específicas ditadas pelo que está disponível — ou pelo que é considerado razoavelmente viável.

Problemas podem surgir quando a sensação de estar preso a um processo específico gera resultados insatisfatórios. Assim como um cozinheiro caseiro cujas opções de refeições se sentem limitadas a um conjunto restrito de ingredientes básicos, as organizações podem se sentir insatisfeitas quando permitem que as ferramentas ditem o que elas são capazes de criar.

Para garantir que os requisitos sejam reconhecidos, e não apenas atendidos, as organizações devem fazer um levantamento regular de suas necessidades e questionar as soluções atuais. Devem criar uma lista de funcionalidades e capacidades que atendam aos requisitos acordados e, em seguida, avaliar as soluções para, a partir daí, adquirir ou desenvolver ferramentas que ofereçam a melhor combinação das capacidades necessárias. Também devem reavaliar as opções regularmente para aprimorar os processos ou trocar de ferramentas conforme necessário. 

Os líderes organizacionais podem colaborar para desenvolver uma lista formalizada, uma estrutura ou uma matriz de requisitos e usá-los para avaliar se as soluções ou os processos são adequados. Exemplos de ferramentas de avaliação incluem: CMMI — Integração do Modelo de Maturidade de CapacidadeA organização também pode estabelecer uma estrutura semelhante a a ferramenta de avaliação de produtos baseada na regulamentação DO-178B da indústria aeroespacial.

Independentemente da abordagem, não se deixe deslumbrar pelas ferramentas em si. Afinal, qualquer organização pode pegar e usar as mesmas ferramentas. É como ir a uma feira de artesanato e todos oferecerem apenas os mesmos produtos, feitos com um único tipo de kit comprado em uma loja de artigos para hobby — sem diferenciação e sem inovação. Somente quando as ferramentas são montadas de forma a atender a requisitos específicos, alinhados a uma visão única, é que uma organização pode oferecer algo com valor precioso — e insubstituível.

A segunda parte deste artigo fornecerá informações sobre como elaborar uma lista de requisitos, priorizá-los e, em seguida, usá-los para formar uma visão de processos que reflitam melhor os resultados esperados.

Aprenda a avaliar as opções de ferramentas e a visualizar como suas escolhas afetam o processo de ponta a ponta. DevOps pipeline em nosso webinar recente: “Desmistificando o DevOps Paisagem com o Periodic Table of DevOps Ferramentas & DevOps Gerador de Diagramas"