Engenharia de Produto

Engenharia de Software é uma área evoluída com disciplinas consolidades de bastante maturidade nas ferramentas e processos desde a expansão da cultura DevOps, o conceitual do ProdOps é direcionar a arquitetura e engenharia para a gestão de produto, toda a análise de maturidade é agrupada em dimensões das características de produto digital, além das jornadas do seu ciclo de vida.

Momento do Negócio e do Produto

Existe um conjunto de boas práticas empíricas ao longo das últimas décadas na gestão de produtos digitais para cada momento do negócio, perseguimos a engenharia necessária para habilitar o suficiente de cada versão de produto correspondente.

É comum os times de arquitetura e engenharia trabalharem a evolução das plataformas para padronizar um modelo único para toda a companhia, na prática, isto é limitador e acaba misturando o mesmo modelo para compromissos diferentes.

Upstream e Downstream

Essa tentativa de centralização e padronização em um único formato acaba punindo o trabalho de validação frequente de hipoteses, criando barreiras para o código chegar em produção e prejudicando toda a jornada de Upstream, que pode e deve ter código acessado pelo cliente em diversos mecanismos de testes A/B, Fake Features e demais estratégias que são gerenciados sob demanda pelo time de produto.

Esta padronização de engenharia pela engenharia, cria um caminho único de colocar funcionalidades em produção apenas pela jornada de Downstream, com compromisso firmado. Além disso, parte do nosso mercado ainda implementa uma GMUD (gestão de mudanças) com má interpretação do ITIL v4 que deixa bem claro que o processo mais aderente é a filosofia de entrega contínua.

5 Dimensões de um Produto Digital

Trazemos na sequência a definição das dimensões de engenharia guiada por produtos digitais.

Cultura de Produtos Digitais

A primeira dimensão é mais conceitual, mas tem caractéristicas que demandam uma avaliação técnica.

  • Product-Led (Liderança por Produto): Não existir separação entre negócio e produto, negócio é o produto e o Roadmap é gerenciado pelo time de produto, mesmo em um cultura de grandes projetos ou iniciativas de negócio que abrangem diversas áreas da companhia, é o time de produto que gerencia a gestão do portfólio e desdobra nos Roadmaps cruzados com um controle de versionamento automatizado de cada peça e componente;
  • Customer First (cliente em primeiro lugar): Cada jornada das personas deve ter o mapeamento de suas Blueprints documentada, acompanhada e servir de guia para a criação das hipóteses.
  • Data Driven (Direcionado por Dados): Todas as hipóteses devem possuir um modelo detalhado para acompanhamento e verificação de sua eficiência com uma engenharia de dados que permite a automatização da geração das informações necessárias para o time de produto;
  • Continuous Delivery (Entrega Contínua): a entrega é totalmente automatizada e não depende de times externos ao time de produto para chegar em produção e ser acessado pelo cliente, seja código sem compromisso na jornada de Upstream ou código lançado e validado na jornada de Downstream
  • Scalability (Escalabildade): Crescer e diminuir sob demanda sem a necessidade de projetos adicionais e deve existir um plano de Roll-out automatizado para cada estratégia de promoção do produto para cada fase do negócio.

Maturidade das capabilidades de Produtos Digitais

Esta dimensão avalia a maturidade das capabilidades por cada etapa no ciclo de vida do produto que é composto pelas aplicações, serviços e componentes.

Qualidade é uma característica complexa que combina diversos atributos, cada atividade das etapas tem suas capabilidades, avaliamos do Planning ao Deploy e promoção ao cliente final.

Operação em Produção

  • Observability (Observabilidade): O time de produto possue Dashboard de Confiabilidade para cada serviço, além de um plano de visualização do MELT (métricas, eventos, logs e traces) das aplicações;
  • Incident Managment (Gestão de incidentes): O time de produto lidera o On-Call (acionamento automatizado) e tem um modelo de cultura Postmortem integrado com a jornada de Delivery;
  • Environment Management (Gestão dos ambientes): Boas práticas de tageamento e isolamento dos ambientes, plano de FinOps estruturado, autonomia com segurança e permissionamento para os times de produto promoverem seguindo as definições de governança;
  • Disaster Recovery (Recuperação de desastres): O time de produto consegue recuperar todos os dados de um ambiente degradado em uma nova estrutura dentro do tempo mínimo permitido pelo SLA do provedor de infraestrutura.

Gestão de Desenvolvimento Confiável

Entendemos nesta dimensão que a fase de desenvolvimento é bem mais do que apenas entregar um bom código, requer uma cultura de confiabilidade para suportar o time de produto com a melhor verificação possível sobre a qualidade do que será entregue.

  • Reliability Driven Development (Desenvolvimento guiado pela confiabilidade): Processo de Onboarding, plano de validação e gestão de erros, cultura Postmortem e DevX;
  • Informative Workspace (Ambiente Informativo): Documentação gerada automaticamente pelo código com um processo de Tech Writer organizado;
  • Isolated Environments (Ambientes isolados): O time de produto dispor de ambientes para validação, desenvolvimento e Sandbox para equipes explorarem os contratos e SLA sobre as APIs.

SLA e Contratos

  • Contract API (Contratos de API): Acordos de contrato das APIs documentado, gerado automaticamente e verificável pela especificação de cada versão ;
  • Service Level Agreements: (Acordos de Níveis de serviço): gestão convencional sobre SLA, SLO e SLI.

Este modelo não é exaustivo e continua em evolução, acompanhe regularmente a atualização do artigo para as novas definições complementares.


Publicado

em

por

Tags:

Comentários

5 respostas para “Engenharia de Produto”

  1. […] plano de confiabilidade é uma carta de intenções para habilitar a Engenharia de Produto com um Roadmap equilibrado de ações suficientes para o momento do produto e pelo momento do […]

  2. […] modelo de suporte para a gestão de produtos digitais baseado na cultura de SRE/DevOps guiada pela Engenharia de Produto com o método Kanban. Detalhes da história neste […]

  3. Avatar de Paulo Caroli

    Muito bom! Obrigado por compartilhar. Vamos seguir acompanhando a evolução desse super artigo.

  4. […] um pouco mais, seguindo os princípios de uma boa engenharia de produtos, podemos começar a estudar e especificar melhores contratos de API entre os produtos com […]

  5. […] idéia do C4E no Framework ProdOps é agregar os princípios de engenharia de produtos como direcionador da abordagem de atuação e acoplando as duas jornadas auxiliades do ProdOps ao […]

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *