Liberando a reutilização com as condições certas

Liberando a reutilização com as condições certas

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br


Algumas coisas na vida não podem ser perseguidas diretamente. Sucesso e felicidade, conforme observados em Man’s Search for Meaning, de Viktor Frankl, vêm à mente. A reutilização de software empresarial é outro resultado que não pode ser buscado diretamente. Reutilizar, como felicidade ou sucesso, acontece quando as condições são adequadas. Esse conceito é especialmente importante se sua empresa está procurando impulsionar a reutilização de software e, em última análise, com o objetivo de criar uma rede de aplicativos. Isso ocorre porque é instrutivo em dizer a você o que almejar; as condições certas.

A reutilização surge das condições certas

Ao visualizar e criar uma mudança cultural dentro de uma organização, pode-se buscar inspiração em eventos atuais, história, cinema, arte, obras de ficção e outras fontes. Para esforços de transformação, frequentemente olho para o Legado de Tron e como Flynn e seu filho, Sam, discutem o surgimento do Isos. “Você os criou?” Sam pergunta. Flynn ri em resposta: “Não, não. Eles se manifestaram, como uma chama. Eles realmente não eram de lugar nenhum. As condições eram adequadas e surgiram. ”

Um componente crítico deixado de fora dessa cena é o esforço feito para criar as condições “certas”. Este é o principal obstáculo em lojas onde a reutilização não é uma ocorrência natural. Não há um esforço focado para criar um conjunto de condições além de criar uma cultura de reutilização. Em minha experiência liderando e trabalhando com equipes de desenvolvimento de aplicativos em esforços transformacionais, líderes e organizações desenvolvem iniciativas para impulsionar a reutilização, mas frequentemente negligenciam a abordagem de cada uma das quatro condições críticas que permitiriam que a reutilização se tornasse o comportamento padrão:

  1. Ética e ideais: Quais são os valores e crenças da organização e dos indivíduos que conduzem e influenciam as decisões sobre a reutilização de ativos de software?
  2. Processo e cultura SDLC: Quais processos e rituais de ciclo de vida de desenvolvimento de sistemas (SDLC) padrão existem para levar as equipes a procurar ativos reutilizáveis ​​em vez de desenvolver novos ativos do zero?
  3. Ferramentas: Quais sistemas e ferramentas existem para ajudar na descoberta de ativos existentes e integração de novos usuários para esses ativos?
  4. Medição e implicações financeiras: Como a reutilização será medida em uma empresa? Como o esforço em fazer / aproveitar ativos reutilizáveis ​​será tratado financeiramente em custos de projeto, custo de computação, etc.?

Quando as empresas fazem um esforço concentrado em cada uma dessas áreas, o clima e as condições nas equipes de desenvolvimento começam a mudar. Assim que os novos incentivos e recursos forem definidos, as equipes começarão a seguir o caminho de menor resistência para sair da terra do “não inventado aqui” (NIH) e chegar ao novo mundo do “orgulhosamente encontrado em outro lugar” (PFE).

De “Não inventado aqui” para “Orgulhosamente encontrado em outro lugar”

Se suas equipes de tecnologia e desenvolvimento mostram uma forte tendência para lançar suas próprias soluções para recursos comoditizados que estão prontamente disponíveis e integráveis ​​em seus fluxos de valor (AKA – “levantamento pesado indiferenciado”), isso é um sinal de que você atualmente reside no município de NIH . Se, por outro lado, sua organização se irradia ritualisticamente com orgulho quando aproveita os recursos gerenciados de outros (AKA – “composição sobre codificação”) para acelerar o lançamento no mercado e permitir que os funcionários se concentrem em ampliar a diferenciação na borda, então você cheguei na paisagem urbana de PFE.

A jornada entre essas duas terras nem sempre é tranquila. Os obstáculos e desafios que você enfrentará no esforço para fabricar as condições certas variam de empresa para empresa e de equipe para equipe. Eles se enquadrarão em uma das quatro categorias listadas abaixo:

Desafio nº 1 – Mudando as crenças

Ao mudar de NIH para PFE, o primeiro conjunto de desafios surgirá na necessidade de mudar as atitudes e crenças dos indivíduos e equipes que visualizam, desenvolvem, gerenciam e governam soluções de software de trabalho de forma colaborativa:

  • As equipes do NIH habitam o mundo como se seus requisitos e contexto fossem flocos de neve únicos. Ajudar essas equipes a ultrapassar a dicotomia preto e branco de “comprar versus construir” em uma nova maneira de pensar ao longo das linhas de “compor e aprimorar” é mais fácil quando você os lembra que as empresas de maior sucesso construíram seus negócios em cima frameworks e APIs que foram construídos e operados por grupos de pessoas diferentes daqueles que os usam.
  • As equipes de PFE entendem que “pisar nos ombros de gigantes” em vez de buscar “autossuficiência” não é apenas o caminho mais rápido para o mercado, mas também o único caminho que permite o crescimento em escala no mercado de hoje que evoluiu de “grande bate pequeno ”a“ bate rápido lento ”a“ grande e rápido ganha sempre ”.
  • Muitos defensores da arquitetura evitam dependências sob a bandeira de controlar seu próprio destino. O controle local é uma coisa boa. Existe, no entanto, um terreno mais elevado lá fora; não ter que se preocupar com suas dependências porque sua resiliência e simplicidade se aproximam do status de “dispositivo” (por exemplo, plataformas baseadas em nuvem como Twilio, Salesforce, AWS, MuleSoft e New Relic dependências frágeis ou alavancas altamente disponíveis?)

Desafio nº 2 – Mudando a cultura

Separados das atitudes e crenças da equipe estão os rituais e processos que constituem a cultura SDLC. Fazer uma mudança de cultura nas “formas de trabalhar” criará desafios para indivíduos e equipes que participam e gerenciam o desenvolvimento de software e a fábrica de operações.

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br
  • Novas formas de trabalhar foram se formando à medida que as equipes mudaram de cascata para agile, mas essas novas formas não se estenderam totalmente para “planejamento para reutilização” ou “levantamento de ativos existentes”. Para ajudar suas equipes a fazer essa mudança, comece uma mudança e mude o ônus da prova. Em vez de ter que provar que a reutilização é possível, exija que suas equipes de desenvolvedor e arquitetura façam esforços explícitos e os documentem.
  • Pode não ser possível provar uma negativa, mas é possível provar que você se esforçou em sua busca por ativos disponíveis (por exemplo, APIs, artefatos de design, testes automatizados, configurações de pipeline, fragmentos, documentação de integração, etc.).
  • Levando essa prática para o próximo nível, você pode exigir que as equipes confirmem, por meio da revisão por pares, que todos os novos componentes propostos não têm ativos existentes que possam ser aproveitados e aprimorados.
  • A última etapa dessa mudança seria formalizar um “relatório de reutilização”, onde as equipes de sprint devem articular um resumo de quais ativos estão reutilizando em um sprint. Ter que articular e validar um zero nos levantamentos e retrospectivas criará pressão social para colocar um esforço real nos processos de pesquisa.

Desafio nº 3 – Mudança de ferramentas

Esperar mudanças em crenças e práticas sem investir em ferramentas avançadas para apoiar as mudanças não é uma estratégia vencedora. Por alguma razão, muitas empresas caem em um dos dois campos 1) Vá direto para as ferramentas com a ideia de que “ferramentas resolvem problemas” ou 2) Ignore completamente as ferramentas com a ideia de que “processo resolve problemas”. No entanto, nenhuma dessas abordagens funciona e o caminho para criar as “condições certas” inclui a realização de vários investimentos complementares em pessoas, processos e tecnologia:

  • A descoberta de APIs em catálogos compartilhados é uma questão importante aqui. Usar o Anypoint Exchange ou Anypoint Community Manager da MuleSoft são bons exemplos de catálogos compartilhados com funcionalidade rica em recursos.
  • Lembre-se de que os catálogos são tão bons quanto seu conteúdo, o que significa que você terá que voltar para os conjuntos de desafios um e dois para ajudar as pessoas a entender dois conceitos-chave:
    • Eles têm a responsabilidade de criar e publicar ativos reutilizáveis ​​de maneiras que sejam fáceis de localizar e compreender.
    • Os processos SDLC devem dar espaço para criar e publicar conteúdo, assim como devem contabilizar o tempo de busca de conteúdo.

Desafio nº 4 – Mudando os modelos financeiros

Mudanças no modelo financeiro são a fronteira final e, para muitas equipes, pode ser o conjunto de desafios mais difícil, porque são esses tipos de mudanças que exigem uma abordagem de pensamento sistêmico. Lembre-se de que existem provavelmente outros exemplos recentes de reformulação financeira que você pode consultar ao tentar instituir essa mudança (por exemplo, agile, DevOps, etc.):

  • Assim como CI / CD (Integração Contínua / Entrega Contínua) e outros projetos de automação, iniciativas para criar as condições que permitem o surgimento de uma cultura de reutilização exigem investimentos, mas isso não significa que seja correto falar sobre elas como “geradores de custos . ” Reutilizar, como a automação, só custa dinheiro quando sua janela de tempo é pequena. Fornecer um intervalo de tempo mais amplo ao seu modelo economiza dinheiro em vez de custar dinheiro.
  • As equipes do NIH podem pensar que têm vantagem quando analisam o custo do uso de software pré-fabricado e testado em comparação com o software “sem custo” que desejam construir, mas essa abordagem desmente a verdade do TCO. Todos os componentes do tipo “faça você mesmo” têm um custo de transporte além do desenvolvimento (ou seja, manutenção e conservação). Em um ecossistema de reutilização, seus fornecedores gerenciam versões, patches e manutenção para você. Essas mudanças podem causar custos intermitentes para você também, mas esses custos são pequenos quando comparados à manutenção e operações autodirigidas e são mitigáveis ​​se você tiver sido sábio o suficiente para investir em testes automatizados (outra grande fonte de dinheiro e tempo- salvando a reutilização).
  • Na infraestrutura de aplicativos compartilhados, pode surgir um ponto crítico em relação ao custo de computação, onde a equipe que cria o item reutilizável pode ter que pagar cada vez que o item reutilizável é chamado. Ajudar as equipes a compreender e adotar novos modelos (por exemplo, chargeback, true-ups / downs, reutilizar créditos / incentivos na capacidade para equipes que fazem ativos altamente reutilizáveis, etc.) é um esforço necessário para fazer a reutilização do “caminho de menor resistência”.
  • A liderança deve “inicializar novos modelos por meio de carve-outs” para transcender o atual jogo de soma zero que é o gerenciamento de escopo / recursos. Por exemplo:
    • As equipes de treinamento de lançamento podem ter uma expectativa de nível básico para arquitetar seus sistemas para criar componentes reutilizáveis, alavancar componentes reutilizáveis ​​ou, na melhor das hipóteses, fazer ambos.
    • As métricas de sucesso do projeto podem ir além dos critérios padrão “dentro do prazo, dentro do orçamento, dentro do alvo” e chegar ao mundo onde “dentro do prazo, dentro do orçamento, dentro do alvo” é necessário passar (ou seja, você obtém um “C”), mas é insuficiente para elogios. Obter um A pode incluir “melhorar as condições para aqueles que vêm depois de você” e “adicionar ao ecossistema de métricas de relatórios” que são necessárias para dimensionar e gerenciar com sucesso uma fábrica de software.

Gerando os ventos da mudança

Embora as fontes de atrito e as mudanças necessárias acima possam parecer assustadoras, há um ponto de alavancagem que tornará a jornada mais administrável: a pressão social. Assim como nas transformações Agile ou DevOps, uma vez que a equipe X vê o valor que está sendo gerado e capturado pela equipe Y, a pressão social para se alinhar com o novo modelo começa a surgir.

No conjunto, o que isso significa para a plataforma de API e líderes de produto que tentam criar uma cultura de reutilização:

  1. Foco na vontade: identifique as equipes que estão dispostas e motivadas a se apoiar nas mudanças necessárias para mudar o ambiente operacional de como o trabalho de software é feito.
  2. Medir e capturar valor: garantir que as equipes estabeleçam linhas de base e comecem a medir os benefícios recebidos da reutilização.
  3. Complemente de baixo para cima com de cima para baixo: Estabeleça uma parceria entre equipes que estão se inclinando para a mudança e patrocinadores executivos para entender e evangelizar os benefícios do novo modelo.

Quando sua organização pode fabricar sistematicamente o novo conjunto de condições, ao mesmo tempo em que cria uma visão transparente dos benefícios que estão sendo recebidos, o efeito volante assume o controle. As condições que você criou permitirão o pivô entre a subida íngreme (que envolve empurrar) e a descida (que é mais sobre governança e propriedade) e você acabará como o Flynn de Tron admirando o novo mundo que você criou .

Se você quiser saber mais sobre os sistemas de reutilização e os benefícios da metodologia baseada em API, verifique a série de três partes sobre reutilização.


cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br
Luiz Presso
Luiz Presso