Usando conceitos de produto em arquitetura para ajudar times de engenharia

Como times de arquitetura podem usar os conceitos de produto para entregar valor aos times de engenharia

Cada vez mais empresas estão adotando áreas de arquitetura para gerar output e acelerar o trabalho dos times de produto/engenharia. Porém, quando começamos a buscar soluções para acelerar o trabalho dos engenheiros, é comum encontrar cenários onde o output de arquitetura, não é exatamente o que os engenheiros gostariam ou a necessidade dos times de engenharia acabam sendo atendidas por eles mesmos, de forma a não aproveitar componentes pré existentes para gerar reaproveitamento entre os diferentes times. E é ai que podemos encontrar soluções para problemas que não sabemos que existem, entregar valor real para os engenheiros e consequentemente torná-los mais produtivos enquanto minimizamos as chances de retrabalho.

Os modelos

Existem diversos modelos de processos que as empresas adotam, bem como a forma como montam os times (atualmente o modelo spotify tem sido largamente adotado por focar no valor gerado pelo produto e não apenas na quantidade de demandas concluídas - o que faz muito sentido). Mas como arquitetura atua dentro desses diversos modelos? Já tive a oportunidade de conhecer, estruturar e vivenciar alguns modelos e vou apresentá-los aqui.

Arquitetura junto da engenharia

Esse modelo geralmente existe em times de produto bem maduros onde arquitetura é um capítulo, da mesma forma que engenharia. O importante desse modelo é o alinhamento constante das interfaces de arquitetura com todo o capítulo para promover reaproveitamento e definir padrões entre os times.

Arquitetura oferecendo suporte passivo para engenharia

Aqui é um modelo um pouco mais passivo. Arquitetura busca necessidade nos times de produto oportunidades de gerar valor para acelerar os times de produto. O problema desse modelo é a complexidade de manter sincronizado o output de arquitetura com a prioridade dos times de produto, e ocorre que os times de produto acabam não seguindo as definições de arquitetura pois precisam atender prazos de seus roadmaps. 

Arquitetura independente de engenharia

Esse modelo é muito adotado por bancos ou grandes empresas. É um modelo onde o time de arquitetura define como os times de engenharia devem trabalhar. Definem padrões, linguagens, frameworks e como os componentes da aplicação ou recursos de infraestrutura serão integrados.

O modelo ideal

Bom, não existe certo ou errado. As empresas possuem restrições ou necessidades que fazem com que a arquitetura seja desenhada para atender essas necessidades ou trabalhar de acordo com as restrições. Por exemplo: Um banco que precisa seguir regras restritas e ter muito controle do que está sendo entregue para o usuário, não pode dar a liberdade que uma empresa voltada para marketing digital poderia. Simplesmente porque precisa existir uma área que vai validar e definir um modelo, de acordo com necessidades da empresa e essa área precisa ter alinhamento constante. Jogar isso para os times de engenharia, poderia gerar um grande consumo de tempo com alinhamentos que nem sempre seriam necessários e iria apenas elevar o prazo e custo dos projetos. Enquanto uma área de arquitetura pode ser responsável por manter esses padrões e output para os times. Por outro lado, esse modelo seria complicado para uma startup que precisa entregar valor constante para garantir atender as expectativas de investidores.

Se eu tivesse que eleger um modelo errado. Eu diria que errado é não ter arquitetura.

O problema

Bom, como mencionei anteriormente. Não existe um certo ou errado, no entanto, independente do formato, uma coisa deve estar claro: Arquitetura precisa entender as necessidades dos engenheiros para gerar valor real para os times de produto. Mas como?

Bom, da mesma forma que um time de produto olha para seu usuário, faz etapas de discovery para entender o que ele precisa (na maioria das vezes, o que o usuário quer, é diferente do que o que ele precisa). Um time de arquitetura, pode fazer o mesmo.

A solução

As empresas que adotam conceitos de produto já conhecem a solução para esse problema. Entender que o engenheiro do time de produto é cliente/usuário de arquitetura, acrescentando etapas de discovey, buscando entender a necessidade (não o desejo) dos engenheiros, gerar discussões e cerimonias de decisão para gerar backlog para arquitetura, é uma forma segura de gerar output em arquitetura alinhado com as expectativas dos engenheiros e mais importante, comprado por eles.

Um ponto importante aqui é que sempre teremos de manter o roadmap de arquitetura alinhado com os principais interessados. Dessa forma vamos entregar o valor, a solução será adotada e podemos documentar a solução para os outros times que venham a ter a mesma necessidade.

Lembre-se que é perfeitamente possível adotar os conceitos de produto em arquitetura, da mesma forma que os times de produtos fazem pesquisa com usuários, usam modelos ágeis para garantir que o usuário está envolvido em cada etapa de validação, até a entrega de cada release. Isso gera engajamento e reduz as chances de arquitetura criar componentes, documentações ou estabelecer padrões que não serão adotados pelos engenheiros no times de produto.

Dica 1: use OKRs olhando para o resultado que buscamos atingir nos times de produto, também ajudam bastante.

Dica 2: participe das cerimônias dos times de produto (principalmente as de refinamento), assim Arquitetura terá oportunidade apresentar soluções mais ativamente ou colher insights para gerar backlog em Arquitetura.