Você realmente sabe o que o seu time faz? Será que vocês fazem algo que não deveriam fazer? Saiba agora, como responder essas e outras perguntas

Um pouco de história

Em abril de 2021 entrei na Via, na Squad de Abastecimento de Lojas da Jornada Logística, com a "simples" missão de pensar, tecnicamente, em toda a modernização deste produto. O problema é que eu vinha de 15 anos de experiência em outro segmento e não entendia rigorosamente nada de varejo. Para completar, o time também tinha muitas pessoas recém chegadas na empresa então o conhecimento ficava completamente na cabeça do Tech Leader, que também não conseguia sair do operacional.

O Abastecimento de Lojas

A Via tem pouco mais de 1.100 lojas e 29 CDs espalhados pelas 5 regiões do Brasil. Quando nossos clientes chegam nas lojas, eles esperam ter produtos para comprar. Evitar a ruptura (o famoso: “Tem, mas acabou”) é a função do time de Abastecimento. Dentre outras coisas, eles garantem que a loja sempre esteja abastecida de mercadorias para vender.

Como dito anteriormente eu precisava pensar tecnicamente em uma modernização para o time, porém, sempre acreditei que toda modernização deve levar em consideração pessoas e processos além de tecnologia.

Pensando em pessoas era importante compartilhar o conhecimento com o resto do time, para que o Tech Leader pudesse sair do operacional e atuar mais na camada tática/estratégica e também para que os demais desenvolvedores entendessem do produto que estavam atuando.

Pensando em processos, bom, nesse caso, não dava pra pensar em nada, pois a maioria das pessoas do time (incluindo GPM, PM e UX) não conheciam os processos adotados pela Via. Foi daí que nasceu o Blueprint Funcional, que é a ferramenta que vai responder as perguntas do título deste artigo e gerar algumas outras.

A metodologia para criar o Blueprint

O objetivo principal era nivelar o conhecimento de todos sobre o produto Abastecimento, mas também queria aproveitar a oportunidade para nivelar o conhecimento técnico sobre o mesmo. Eu aindaprecisava descobrir se tudo que o time fazia, deveria ser mesmo feito pelo time, ou se nós deveríamos estar fazendo alguma coisa que outras pessoas estavam cuidando. Mas como fazer isso sem deixar chato para quem era de produto e desinteressante para os Engenheiros de Software? E principalmente como descobrir Gaps de funcionalidades sem entender todo o contexto da Logística e da Via?

Combinamos de reservar de uma hora e meia a duas diárias para reunir o time e fazer com que o Tech Leader contasse uma história: A história de como a mercadoria chegava na loja. Para que a história fosse contada, tínhamos quatro regras:

• Não entrar em muito "techniques", e não abrir código, pois não era um time só de Engenheiros.
• Como um dos objetivos era nivelar o conhecimento dos engenheiros, o Tech Leader podia ilustrar uma explicação com a tela do sistema e com alguma query no banco de dados
• Não se apegar muito a detalhes das regras de negócio
• A história pode conter personagens externos ao contexto de abastecimento, mesmo que não se tenha o detalhe do que eles fazem

Com isso durante mais ou menos duas semanas, fizemos algumas horas de reuniões, onde as pessoas ouviam o Tech Leader, faziam perguntas sobre o processo, sobre algum debug que tiveram que fazer para resolver um incidente e por aí vai. Importante dizer também que tudo foi feito de maneira remota e todos os papos foram gravados para consulta posterior.

Criando o Blueprint

História contada, este que vos escreve, maratonou o AbastecimentoFlix. Mais de 10 horas de reuniões onde tudo estava explicado ali, e mesmo com as regras que citei anteriormente, a riqueza de detalhes era enorme.

A primeira coisa que fiz foi identificar todos os "personagens" da história e no final desse processo tinha algumas áreas da Via mapeadas como stakeholders.

Na sequencia fui alocando as ações de cada personagem embaixo do seu nome e aconteceram três coisas curiosas:

• Alguns personagens, eram coadjuvantes, ou seja, eram apenas áreas ou sistemas que o Abastecimento interagia de alguma forma, mas não faziam parte da jornada do produto. Por exemplo, vou no estoque, saber se tal mercadoria está disponível.
• Algumas ações, não tinham personagem, estavam meio que perdidas.

E a terceira coisa Fábio? Continua lendo que daqui a pouco você vai descobrir 😉

Com isso nasceu a v1 do blueprint que é muito próxima da versão final que temos abaixo.

Blueprint Abastecimento

Mas aí, eu tinha aquelas duas situações que mencionei acima, e precisava fazer alguma coisa com elas.

Para os coadjuvantes, eu simplesmente coloquei em outro lugar o nome do sistema (ou área) e o que eu ia fazer lá. E essa lista me foi bem útil quando eu parti para a segunda etapa do processo que era o DDD.

Interfaces Sistemicas com Abastecimento

Para as ações sem personagem, revendo a explicação, percebi que na verdade eram processos que rodavam automaticamente, para gerar algum relatório ou para enviar alguma informação para alguém. Então criei a área de processos automáticos que existe na figura do Bluprint.

E no rodapé do desenho anotei as discrepâncias. Durante a explicação, fomos descobrindo que a squad fazia coisas que não deveriam estar ali, e que ela deveria fazer coisas que estavam em outras squads.

Os resultados desse trabalho

Com o Blueprint feito tivemos ganhos já de imediato:

• O time teve o seu conhecimento nivelado e a partir desse momento, os desenvolvedores conseguiram mais autonomia para realizar suas tarefas
• O Tech Leader começou a sair do operacional e conseguiu pensar em coisas mais estratégicas junto com o PM.
• Passamos a ter um excelente material de onboarding para novos membros do time, e de consulta para os engenheiros, pois como tudo foi gravado, eu publiquei os videos no nosso canal do Microsoft Streams (uma espécie de Youtube corporativo) e durante o meu processo de revisão eu acabei decupando os videos. Então eu tinha um documento, que compartilhei com o pessoal, que informava que o assunto X estava no vídeo Y no tempo Z.
• Você também descobre um tanto de coisas que o time faz e deveria estar em outro contexto e um outro tanto que vocês deveriam fazer e está perdido em outras squads.

Mas e aquela terceira coisa que aconteceu e eu não contei até agora? Pois é, nesse trabalho, confirmamos uma coisa que eu já tinha percebido, mas todo mundo achava que não era assim. Existiam duas squads dentro de uma. Dois assuntos completamente distintos que todos achavam que era "coisa boba" e na verdade era um assunto crítico e complexo.

Com o Blueprint conseguimos mostrar de forma visual, que fazia sentido aquela squad se dividir e assim, no segundo semestre do mesmo ano, esse segundo time foi oficialmente criado.

Esse trabalho acabou virando um padrão aqui na Logística e atualmente, praticamente todas as squads tem seus Blueprints mapeados. Essa atividade é direcionada pelo GPM e pelo Principal Enginner e executada pelo PM e Tech Leader.

Lições aprendidas e dicas

Durante esse processo fomos aprendendo algumas coisas e melhorando outras.

• Tente sempre fazer as reuniões de câmeras abertas. Isso vai gerar uma aproximação maior do time e principalmente, você vai perceber quando eles estiverem perdendo o interesse. Isso significa que é hora de parar e continuar no dia seguinte
• Duas horas de papo geralmente é muita coisa. Pela minha experiência, uma hora é o tempo ideal, desde que o time seja objetivo. Se possível combine previamente, com quem está contanto a história, que assunto será tratado naquele dia. Assim ele consegue se preparar e ser mais direto no assunto.
• Não deixe a conversa ser levada por lamentações do passado e não tente desenhar ali uma nova solução ou processo. Essas conversas são exclusivamente para entender o produto do time, e não os problemas e o futuro da empresa.
• Nem sempre você vai encontrar sakeholders na história. As vezes acontece do produto do time ser exclusivamente de backoffice ou de automação. Nesse caso, talvez valha substituir o stakeholder por contextos de negócio. A imagem abaixo ilustra uma squad onde essa situação ocorreu.

Blueprint Agrupado por Contextos de Negócio

• Durante a execução do trabalho, não se preocupe com a estética. Use um excel, bloco de notas ou qualquer outra ferramenta de rascunho. Você vai mexer muito na organização das coisas, e vai te dar muito trabalho se você já estiver utilizando a ferramenta final (acredite, eu passei por isso e tive um trabalhão).
• Não tenha apegos. Pode ser que a sua squad seja reestruturada, alguém precise ir com algum assunto para outro lugar e outra pessoa chegue com um assunto novo. Mas isso faz parte e no final até facilita o trabalho do time.

E a principal dica é: Não se preocupe em seguir à risca tudo que eu disse aqui. Cada squad é uma squad e cada pessoa é uma pessoa. Adapte essa ferramenta a sua necessidade, pois o que fizemos aqui não necessáriamente vai funcionar para você.

O passo seguinte ao Blueprint

Com o blueprint pronto e as descobertas feitas, o PM e o UX tiveram insumos para promover um discovery e realmente propor mudanças nos processos do abastecimento. E ainda conseguiram “fatiar” esse processo de discovery em fases, seguindo a jornada do abastecimento.

Já eu, no papel de Staff Engineer, converti todo aquele material de produto, para algo mais técnico e fiz o mapeamento de domínios e contextos do DDD. O Thiberio Menezes tem um excelente artigo sobre o tema. Na experiência dele, o DDD foi feito antes do blueprint, mas essa, nem sempre é uma boa estratégia, pois você pode enviesar o produto para o lado técnico. É o famoso “depende”. Se o seu time cuida de um produto que é específico ou muito particular da sua empresa, o ideal é começar pelo entendimento deste produto do ponto de vista de negócio. Assim, você consegue até mesmo validar se ainda faz sentido considera-lo algo diferenciado ou se o mesmo pode ser substituído por algum produto de mercado.

Aqui na Logística, tanto o Blueprint, quanto o DDD, se mostraram ferramentas indispensáveis para apoiar a modernização da nossa plataforma. Com eles, conseguimos justificar com dados uma determinada estratégia de modernização e entender quando teremos uma complexidade maior ou menor de migração, sem achismos.