“Devemos fazer um microsserviço na nuvem com um service mesh”. Outro dia, outra escolha de tecnologia. Mas quando pergunta “Por quê? Para fazer o que?” e tem apenas uma resposta confusa, é melhor parar a iniciativa.

Eu tive esse foco tecnológico vindo de uma formação em engenharia. Como engenheiros, gostamos de resolver problemas complexos por meio de design, criatividade e soluções elegantes. A questão é que o problema deve ser valioso para ser resolvido em primeiro lugar.

O porquê e o quê são elementos essenciais de qualquer iniciativa de software. A precipitação devido à impaciência, pressão para entregar e cultura organizacional pode criar atalhos perigosos, confundindo estar ocupado e entregar valor.

Este artigo compartilha os principais elementos de uma metodologia estruturada que pode aplicar a qualquer iniciativa de software. A entrega que produzirá deve ser compreensível por toda a equipe, inclusive para as partes interessadas do negócio:

• Um Como não tem sentido por si só
• Um Como deve começar com Por que
• Um Como se desdobra de um que
• Um Como é um dos possíveis
• Um Como de valor requer Métodos

Vamos começar esclarecendo por que não há tempo para iniciativas pouco claras.

Um Como não tem sentido por si só

Algumas pessoas argumentariam que algumas iniciativas de tecnologia sem um motivo comercial claro ainda são benéficas: “É melhor ter um software atualizado em vez de um antigo.” A questão é: usaria todo o seu salário apenas para “atualizar” seu carro?

A implementação requer tempo, energia e dinheiro. Mas não há tempo a perder em um mundo digital de competição acelerada e recursos limitados. Iniciativas pouco claras perdem a importância do custo de oportunidade: a perda de outras alternativas quando uma alternativa é escolhida.

Custo de oportunidade – a perda de outras alternativas quando uma alternativa é escolhida – requer priorizar os Comos na Engenharia da Qualidade.

Antoine Craske

As empresas precisam de economias de escala e velocidade para sobreviver. As coisas mudam rápidamente. Um ativo de software de valor hoje pode ser completamente substituído se a empresa pivotar. É por isso que iniciativas isoladas que carecem de clareza são provavelmente um desperdício de dinheiro.

O Quality Engineering não tem lugar para desperdício, apenas para valor.

Um como deve começar com o porquê

O porquê é essencial para qualquer atividade. Simon Senek popularizou a expressão Start With Why em seu livro best-seller. Também é encontrado em vários pontos dos 7 Hábitos das Pessoas Altamente Eficazes por Stephen R. Covey, também alcançando milhões em sua vida e conselhos sobre comportamento.

O Porquê nos dá significado, propósito e objetivos duradouros. O Por que impulsiona nossa ação em cascata sobre o quê, como e até mesmo sobre quem. O Porquê materializa o valor das nossas ações. Ao longo da história, por que permitir que as pessoas enfrentem períodos dramáticos como o Man’s search for meaning, de Viktor Frankl.

Um convincente Porque é um facilitador duma estendida colaboração . As pessoas foram capazes de construir catedrais e outros monumentos duradouros, acreditando na visão geral, missão e o porquê. As organizações precisam de um motivo impulsionador, liderado por seus gerentes, para manter um alinhamento de valores durante a implementação.

No Quality Engineering, o Porquê é a raison d’être e impulsiona a lacuna de valor que devemos fornecer continuamente aos nossos utilizadores. Criamos valor fazendo com que nossos utilizadores tenham sucesso no solucionamento de seus problemas. O software, por melhor que seja tecnicamente, não tem sentido se não for valioso para alguém que conta. 

Todas as razões para ter um porquê claro antes de passar para o quê.

Um Como surge a partir de um Quê

Um perímetro estruturado é essencial para uma implementação eficaz. Não há tempo a perder no Como até que o escopo seja definido. Isso provavelmente levaria a implementações parcialmente valiosas, complexas e demoradas, cheias de rework desnecessário.

O quê em cascata do por quê. Pode ser um experimento para avaliar o valor potencial de um recurso para nossos utilizadores. Pode ser um complemento para um recurso já bem-sucedido. Pode ser uma correção detectada em um incidente ou relatório de segurança. Seja o que for, deve ser claramente declarado.

Delimitar o perímetro de uma mudança de software é vital. Ele obriga a ser mais concreto sobre os casos de usos e funcionalidades esperadas. Ele começa a levantar elementos fora do escopo e requisitos não funcionais, como cobertura, desempenho ou segurança do dispositivos.

Um escopo claramente definido também é essencial para a colaboração de especialistas. Os product owners e engenheiros devem estar alinhados com o que estão tentando alcançar. A partir desse ponto, eles podem até mesmo priorizar o perímetro identificado.

Só então eles podem trabalhar nas diferentes implementações possíveis.

Um Como é um dos Comos possíveis

Não há um único Como. Existem várias soluções para o mesmo problema. Eles respondem de maneira diferente e, portanto, têm trade-offs associados. É por isso que um Como único não é suficiente, uma solução sem contras não é suficiente e o contexto é chave para a decisão.

Conhecer as possibilidades permite que escolha melhor. Um único Como é perigoso por falta de perspectiva sobre o problema a ser resolvido e pelos trade-offs envolvidos. Pode comer em uma pizzaria, um restaurante Michelin ou um fast food, todos respondendo à necessidade de comer. A experiência geral é diferente em termos de preço, momento e nutrição. Depois de ter várias opções, precisa escolher uma. Essa é a importância dos trade-offs.

Os trade-offs ajudam a articular os prós e os contras associados a uma determinada opção. Eles são necessários para superar vieses específicos de tomada de decisão, como confirmação ou recência. Eles também ajudam a factualizar as opções que facilitam a colaboração. Os trade-offs não devem ser misturados com a tomada de decisões. Todas as opções têm vantagens e desvantagens. Uma solução proposta sem contras deve ser desafiada para identificá-los. Mas decidir se eles são bons ou ruins depende do contexto.

O contexto orienta nossa tomada de decisão priorizando certos critérios em detrimento de outros. O contexto contém o Porquê e as possíveis evoluções da organização, elementos essenciais para a tomada de decisão. Comprar uma casa nem sempre é a solução. pode comprar casas diferentes se for solteiro, em casal ou construindo uma família. pode comprar, alugar ou alugar um evento com opção de compra.

O poder da estrutura é o resultado desse processo.

Um How de valor requer Métodos

O Por que assegura a real necessidade de trabalhar na iniciativa. O Quê desafia o que fazer, em que ordem e sob qual perímetro. O Como dá o poder de escolha para articular a trajetória mais valiosa do sistema.

Um processo estruturado é a base do desempenho organizacional. Uma abordagem sistemática permite uma maior produção e melhor escalabilidade. O desacoplamento de fases passo a passo acelera o resultado, reduz a complexidade e evita rework  desnecessários.

O Quality Engineering é a entrega contínua de software valioso para nossos utilizadores. É a conquista da Quality at Speed em um ecossistema sempre desafiador. Não há energia, tempo e dinheiro para desperdiçar em iniciativas pouco claras.

O Framework do Quality Engineering, MAMOS, começa com os Métodos. É a maneira de implementar processos estruturados de qualidade total, enxutos e outros valiosos para a entrega de software.

Então, quando começa com o Como, pare agora mesmo.