Time de sustentação junto ou separado do time de desenvolvimento? · clebsf

Hoje venho aqui compartilhar um processo que (em minha opinião) foi a melhor coisa que aconteceu para o projeto do qual faço parte.

Já faz alguns anos que faço parte do projeto de uma das maiores empresas de comunicação e streaming do Brasil, e isso é simplesmente incrível, pois venho aprendendo e evoluindo muito desde então. Lidar com desafios técnicos e de negócio que envolve milhões de usuários é algo realmente que muda a visão de um software e de seu impacto na vida das pessoas.

Logo que entrei no projeto fui designado para o famoso time de sustentação (bom, famoso entre eles, pois nunca trabalhei com sustentação na vida, ou achava que não). Após algum período de onboarding ficou claro qual seria o meu papel, e fiquei bastante animado com isso, pois era algo completamente novo, com diversos desafios jamais explorados.

O meu papel era bem simples: Solucionar o problema de dezenas, centenas ou milhares de clientes o mais rápido possível. Quanto maior a quantidade de clientes impactados, maior é a prioridade.

Podemos dividir "problema" em 2 categorias:

Backlog: É quando temos 1 ou mais clientes impactados que precisam ser corrigidos de alguma maneira;
Causa Raiz: É o que de fato está causando o problema. É aqui onde a torneira esta pingando e você precisa fazer ela parar de pingar, caso contrário você sempre terá um backlog para tratar.
Já sabe qual a prioridade, né?! TUDO!!

Aqui temos que ter trabalho em equipe, pois enquanto tem alguém focado no tratamento do backlog, o outro está investigando onde danado está a causa raiz, e não é nada tão simples o quanto parece, pois estamos lidando com DEZENAS de aplicações interligadas, onde uma depende da outra. É um trabalho bastante árduo essa investigação.

Com isso já da pra imaginar que precisamos de uma coisa muito importante: Entender o NEGÓCIO!
E em minha humilde opinião, está é a maior vantagem de se trabalhar em um time de sustentação, pois você acaba precisando de fato lidar na prática com o negócio.

Um exemplo simples: Vários clientes não estão conseguindo comprar algum produto e um aviso de "você tem outra compra em andamento!" é exibido.

Neste exemplo você tem uma percepção do negócio, e passa a matutar (pensar) quais seriam as aplicações que podem estar resultando naquele problema para o cliente.

Agora que você já conhece um pouco do mundo da sustentação, vou compartilhar algo que para mim pareceu um problema.

Na imagem abaixo coloquei como os times estavam trabalhando, onde o time de sustentação é completamente separado do time de desenvolvimento.

Imgur

Consegue enxergar o mesmo problema que eu?

Na imagem é possível observar que o time de sustentação é "responsável" por todas as aplicações de todos os times. Ou seja, quem está na sustentação precisa ter sempre uma atualização de tudo o que pode ter de mudanças nas aplicações, pois isso afeta diretamente sua análise diante de um problema em produção. E bom, não é algo fácil manter essa sincronia entre os times.

O principal problema que consigo enxergar com este modelo é a sobrecarga que o time de sustentação tem, com essa grande responsabilidade de olhar para todas as aplicações para identificar um problema real em produção. Além de todo o conhecimento técnico que precisa ter é necessário ainda entender muito bem do negócio.

Agora veja como sustentação está hoje:

Imgur

Hoje sustentação encontra-se dentro do time de desenvolvimento, o que (posso estar enganado) melhora e muito a resolução de problemas, principalmente os críticos, pois o time está sempre de olho nas aplicações pelas quais são responsáveis e agora também olhando com olhos de sustentação.

Isso, do meu ponto de vista, melhora e muito a atuação na resolução de problemas, pois imagine a seguinte situação: Hoje subiu para produção um novo fluxo de vendas e foi observado via monitoramento que existem clientes sendo impactados. Quem você acha que seria a melhor pessoa para analisar este problema e encontrar de forma quase imediata a causa raiz? Bom, não sei sua resposta, mas a minha é "o desenvolvedor que desenvolveu o fluxo". Faz sentido pra você?

Bom, era isso que queria compartilhar, pois nunca encontro conteúdos sobre sustentação com experiências reais, dai achei que seria uma boa.

E você, já trabalhou com sustentação?

O conteúdo deste post também está no blog que estou tentando movimentar: https://blog.clebertfigueiredo.com/time-de-sustentacao-junto-ou-separado-do-time-de-desenvolvimento

esse modelp de time de sustentação é horrível, acaba criando gargalos porque é impossível um time só saver de regras de negócio de n projetos, o time de dev não se preocupa em fazer boas entregas e nem de pensar em forma de melhores de monitoramento e até de uso de logs afinal a bucha não fica na mão deles, fora que nas empresas em que trabalhei que tinham esse modelp blindavam o time de dev então você não tinha nem como tirar dúvidas com eles, o que claro era o que causava na maioria das vezes o estouro do sla, porque tinhamos que entender o problema, descobrir a raiz e corrigir garantindo que não ia ter conflitos com outras regras de negócio e não ia quebrar nada, o que acabava tomando muito mais tempo, nas raras vezes que tinhamos apoio do time de dev, em 5 minutos tinhamos uma decisão do que fazer porque eles tinham todo o contexto do projeto.

rodizio dentro do proprio time de dev é a estratégia mais apropriada, todos do time aprendem sobre o projeto, quem tem o contexto resolve muito mais rápido e como o time vai precisar analizar problemas em produçãoeles acabam prezando por qualidade, logs estratégicos pra facilitar o troubleshooting e por ai vai.