M1: Essa questão de sustentação é engraçada porque no fundo esses
assuntos convergem quando a gente fala de squads e de frentes digitais.
Fale um pouquinho sobre isso, Felipão.
M2: A experiência que eu já tive no assunto, eu dividi em dois aspectos, a
pergunta fala sobre como fazer a passagem do bastão de uma feature que
acaba de ser entregue pelo time que faz a sustentação. Eu já acho que não
deve haver essa passagem de bastão, porque se a gente está falando de um
produto, nessa primeira visão, se a gente está falando de um produto, o
squad tem que ser o responsável por novos features e por sustentar a
aplicação, é uma coisa que a gente já falou até em um episódio anterior,
que um backlog de um produto tem que ser composto por feature sim, mas
também por bugs, devs técnicos, então a sustentação é feita pelo próprio
time. Um bug passa a ser uma história comum do time daquele produto,
porque ninguém melhor de estar contextualizado no assunto, ter o
conhecimento de causa para sustentar o produto do que o próprio time do
produto. Agora quando a gente está falando de aplicações que são legados,
já estão em operação e não existe um squad atuando de forma contínua…
M1: Só um comentário, então eventuais aplicações talvez aposente…
M2: Ter um squad cuidando. Aí sim a gente vai para um ambiente de
sustentação centralizado. A experiência que eu já tive em um ambiente de
sustentação centralizado fazendo aí um paralelo com o agilismo, o que
melhor funcionou foi a gente colocar o time em operação de Lean Kanban,
o método mais próximo do Lean Kanban, em que se consiga limitar alguns
work in progress, que a gente sabe que na sustentação é às vezes inevitável,
mas tentar levar ali o bug, o chamado até o fim. Por que estou falando isso?
Porque no início dessa experiência que eu tive na sustentação centralizada
a gente elevou muito o número do nosso work in progress, e aí você acaba
se perdendo no contexto de um problema que você começou a analisar há
uma semana, e a gente convergiu bastante quando entramos em modo
Lean Kanban, em que a gente tinha um máximo de work in progress de três
por desenvolvedor, três chamados e a gente entrava em um ciclo de às
vezes estar parado em uma validação de um usuário, então a gente ficava
enchendo o saco do usuário até conseguir realmente colocar aquele…
M1: Ir até o fim.
M2: Ir até o fim.
M1: Não ficar cada um passando o bastão e com uma meta local, vamos
dizer assim.
M2: Exatamente.
M1: Fechar o chamado na perspectiva dele.
M2: Porque no fim acaba acontecendo…
M1: Fechar, para resolver o problema.
M2: Exato. Se a gente não tiver essa orientação forte em resolver o
problema, a gente começa a aumentar muito o work in progress, aumentar
muito a fila e começa a fazer fechamento de chamado…
M1: à força.
M2: À força. O problema não foi resolvido. Então eu vejo mais por esse lado.
M1: Só um comentário. Esse primeiro cenário que o Felipão disse, para um
squad poder de fato poder assumir a sustentação da frente, pela qual ele é
responsável, você tem que estar com o conceito do agilismo ali na veia
mesmo, porque primeiro esse squad vai ter que ter espaço para isso no
backlog, então alguém que cobra constantemente, alguém que quer uma
previsibilidade total e que não aceita que aquele…
M3: Não pode ter nenhuma variação em função de um novo problema.
M1: É, não pode ter variação, e se aquele time entregou menos… Pensa
bem, um time tem que fazer o mais importante, e se num dado momento
o mais importante é fazer uma pequena melhoria ou corrigir um bug crítico,
aquilo é o mais importante, e o time vai fazer aquilo. Isso exige uma
maturidade, vamos dizer assim, de gestão, para entender as variações, e na
minha visão também, para isso acontecer de verdade, você tem que estar
com uma série de ferramentas de devOps em ação para o time realmente…
porque assim, se é um fardo muito grande para aquele time cuidar, vamos
supor que se para acessar um ambiente é difícil, para fazer aquilo é difícil,
para botar um deploy é difícil. Aí aquilo atrapalha tanto o time que você fala
assim “deixa isso para alguém fazer” mesmo sendo mais eficiente,
concordam?
M2: Se o time está com esse tipo de problema de autonomia, de DevOp de
implantação, ele tem um problema até anterior à sustentação, porque
provavelmente eles vão estar com esse mesmo problema para poder
evoluir.
M1: Eu comento isso porque às vezes a causa raiz é essa, se o cara separa é
porque assim “é muito ineficiente isso ficar dentro do time”, mas a solução
às vezes não é separar, é ir à causa raiz dessas ineficiências.
M2: Eu não sei qual é o formato da sustentação aí no caso do Rodrigo, mas
um conselho que eu daria para ele é tentar identificar, se for uma
sustentação centralizada ele identificar o que é produto ali e começar a
transferir a responsabilidade desses chamados de produto para os times de
produto de fato.
M1: Engraçado, um conselho para o modo tradicional é ficar o mais limpo
possível.
M2: Exatamente.
M1: E para a frente de produto é trazer para dentro do contexto da frente
de produto.
M2: É claro que assim, em equipes descentralizadas existem métodos,
como o ITIL, que ajudam também a fazer a gestão. Mas acho que o principal
ponto é tentar identificar se tem produto ali no meio e tentar se tornar o
mais Lean possível quando a gente está falando de centralizada e quando a
gente está falando de produto, é colocar para o produto cuidar.
M1: Deixa eu só fazer alguns comentários. Na minha visão, a melhor
estrutura é a sustentação estar dentro do squad por um fator crucial que
aumenta a responsabilidade intrínseca do time, o time passa a ficar muito
mais responsável pelo que ele gera. E essas questões de evolução de
DevOps que a gente comentou aqui nascem até porque se a pessoa que faz
é a pessoa responsável por no final de semana atender ao chamado, ele vai
querer muito automatizar as coisas, melhorar a qualidade do que está
entregando, mas há divergências. Se você tem uma variabilidade muito
grande de algum produto, o que eu quero dizer com isso, vamos supor que
um produto de vez em quando não tem chamado nenhum, vários dias sem
chamado, mas de vez em quando tem uma rajada de chamados, ou
pequenas demandas. Como lidar com isso? Você vai montar um squad só
para isso? É um pouco complicado. Outro aspecto é o seguinte, quando está
dentro do squad normalmente há um rodízio, não tem uma pessoa só que
é a pessoa da sustentação, porque isso é muito frágil, então aspessoasvão
girando. Mas, por exemplo, o Google tem um papel que eles chamam de
SRE, que é Site Reliability Engineering, e às vezes têm times que são só desse
papel, e o que eles fazem é selecionar aspessoasquetêmumperfil
adequado para isso, porque normalmente é um papel muito estressante, é
o cara que gosta muito da emoção, então eles fazem uma seleção, já li em
alguns artigos, própria para isso, a pessoa tem aquele perfil, não liga de ser
acionada fora de hora, o cara até gosta. E o que eu estava falando voltando
sobre a questão da viabilidade, o que você pode fazer nesse modelo do
Google é um modelo mais centralizado, igual o Felipão estava falando.
Então talvez você possa acumular produtos que tenham grande
variabilidade e normalmente quando você junta muita variabilidade, a
variabilidade total diminui, então é uma saída.
