Chegou um novo projeto trazido pela liderança. Um cliente enviou um e-mail indicando que uma funcionalidade precisa de uma evolução. Foi aberto um ticket com dúvidas dos usuários. Um diretor ligou dizendo que um cliente importante não conseguiu usar o sistema e vai ter prejuízos se um bug não for corrigido imediatamente. TUDO-AO-MESMO-TEMPO. Com o que isso se parece? Com um dia normal na vida de uma equipe que mantém um software em produção. E como as equipes lidam com isso? Tentam montar seus quadros, encaixando os itens de trabalho como é possível, com interrupções frequentes, fazendo a priorização do que atender por conta própria. Ou seja, tocam o trabalho como é possível. Falta amparo de um sistema de trabalho organizado e guiado por um propósito, isso porque a grande maioria das novidades no mundo dos processos de trabalho, técnicas,  metodologias de gestão e desenvolvimento de software surgem para organizar o trabalho “nobre” e “queridinho” da indústria e dos profissionais: o software novo. Muitos livros, conferências e cases focam nos processos de descoberta, inovação, criação, construção, gestão de times para o desenvolvimento de um novo produto. Mas, uma vez que o produto entrou em produção, já pode existir algum nível de manutenção e a equipe precisa lidar com problemas de gestão totalmente diferentes dos enfrentados durante o desenvolvimento.

Quando Entramos no “Modo Manutenção”?

Apesar do conceito de manutenção de software ter uma relação com o processo de modificar o software após sua entrega em produção (para correção de falhas, otimização, etc), em um modelo mais ágil, é muito provável que em um curtíssimo espaço de tempo já exista uma entrega. Seria correto dizer que logo após a primeira entrega o produto já está em uma etapa de manutenção? Não necessariamente. Gostamos muito da definição do Alisson Vale neste artigo pois ela parece responder de uma forma mais atualizada ao questionamento sobre quando o produto, de fato, entra em manutenção. Ele indica que o software entra neste “modo” quando o negócio é influenciado pelo software de uma forma tão intrínseca que um não existe sem o outro. Um bug, por exemplo, pode ocasionar a descontinuidade do negócio, grandes perdas financeiras, afastar clientes, etc.

Por este motivo, o trabalho de manutenção de um software precisa de resgate da nobreza, pois não trata-se apenas de correção de bugs ou pequenos problemas de codificação, mas a manutenção precisa ter um caráter pró-ativo e alinhado ao negócio. Em um cenário onde o mundo e as tecnologias mudam constantemente, também é preciso gerir a trinca negócio x software x riscos, permitindo que o software continue apoiando o negócio, crescendo de modo sustentável e evitando sua deterioração natural. A falta de resposta rápida, flexibilidade e percepção de novas necessidades para adaptação do software ao mercado pode ter graves consequências. Por este motivo, é preciso ter atenção ao que é relevante fazer. Quando a equipe de manutenção visualiza diversas demandas e percebe que há um horizonte de inúmeras possibilidades, não consegue priorizar o atendimento adequadamente – aplicando critérios como os primeiros acionamentos são atendidos primeiro. Eventualmente, a depender do demandante, o pedido ganha prioridade mas a verdade é que, de fato, não é usado um critério adequado para priorizar e reagir corretamente (e no tempo certo) aos acionamentos recebidos. A cobrança da liderança por eficiência (fazer mais e mais rápido) de modo a atender todas as demandas também favorece este cenário caótico. Muitas vezes o atendimento está focado em fazer o desenvolvedor trabalhar mais rápido e não nas falhas de processo de trabalho, ou seja, nas falhas sistêmicas, que implicam em atrasos e longas esperas dos itens, antes que o desenvolvimento de fato aconteça. Nesta situação, assim como no desenvolvimento de uma nova solução, é preciso realizar uma avaliação sobre o que é importante fazer para garantir uma tomada de decisão na direção de executar as coisas certas primeiro (busca pela eficácia).

Por Que Falhamos ao Organizar o Trabalho?

Os desafios de manter um software e de gerar um novo produto preconizam modelos de trabalho distintos pois possuem propósitos distintos. É comum reproduzirmos processos e metodologias de trabalho (ágeis, por exemplo) que foram pensadas para a construção de um novo software tentando aplicá-las ao contexto de manutenção. Essas práticas podem ajudar, mas não é através da aplicação de métodos crus que salvaremos nossas equipes. Sendo assim, como organizar o trabalho de manutenção se só conhecemos o formato de trabalho destinado a gerar novos produtos? Como parar de ter a sensação de que o software é muito ruim e estamos sempre apagando incêndios, simplesmente porque o processo de organização do trabalho não ajuda?

Outra saída comum, adicionalmente aos processos, são os controles: formas para administrar a comunicação (listas de e-mail), sistemas de ticket, formatos padronizados para criação de demandas, etc. É possível que isso ajude mas, provavelmente, também não resolverá o problema.

A resposta para a pergunta “por que falhamos?” é porque não costumamos alterar aspectos que de fato alavancam nossos sistemas de trabalho. Para gerir o trabalho de manutenção de software, é preciso criar um sistema que garanta flexibilidade, reação em tempo adequado e permita lidar com o risco. O grande desafio a ser tratado pelos sistemas de trabalho não é (embora o senso comum nos leve a crer) a natureza dos problemas – se ele é um bug, um pedido de usuário, um pedido do diretor, etc. Na manutenção de um software, diferente do desenvolvimento onde há uma constante validação de hipóteses, o aspecto chave é o risco. Há riscos de vários tipos como perdas financeiras, de confiança, geração de transtorno e ineficiência, tudo isso por funcionamento incorreto, ou até mesmo o risco de não se adaptar às novas necessidades do mercado e não inovar, além do próprio risco de deterioração do software e dos processos a longo prazo.

Adicionalmente aos riscos, a quantidade de coisas a fazer, seja para adaptação, seja para correção, tornam o processo de evolução do software algo caótico e insano. A equipe, por vezes, se sente desmotivada e sem clareza de suas prioridades quando entra no modo “ganha atendimento e atenção se chegar primeiro ou falar mais alto”. Obviamente, um software mal projetado e mal escrito tem sua parcela na dificuldade de adaptação e evolução mas, na maioria das vezes, problemas de gestão são responsáveis pela sensação de caos, muito mais do que o próprio software.

Então, uma alternativa que permite endereçar as questões da manutenção de software de modo adequado é categorizar o risco (e não a natureza do problema) e garantir que este problema possua um sistema de trabalho adequado para seu tratamento. Se estamos falando de gerenciar riscos e fazer uma triagem dos problemas que serão tratados com base nestes riscos, podemos recorrer a sistemas já conhecidos para fazê-lo. Um dos modelos que mais estamos acostumados é o modelo de triagem usado nos hospitais – o Protocolo de Manchester.

Então a Área de Saúde Pode Ajudar a TI?

Sim! Escrevemos este artigo em nosso 60° dia de quarentena. Vivemos no Rio de Janeiro e estamos preocupados com a situação dos hospitais. Foi divulgado em 24 de Março de 2020 pelo Grupo Brasileiro de Classificação de Risco um documento sobre a Associação entre Protocolo Manchester de Classificação de Risco e Covid-19. Caso você não conheça o Protocolo de Manchester, é uma forma de realizar triagem baseada no grau do risco do paciente, determinando o tempo de espera para atendimento. Veja uma simplificação na Figura 1.

Procotolo de Manchester
Figura 1 – Simplificação do Protocolo de Manchester

Da mesma maneira que no Protocolo de Manchester, uma equipe de manutenção de software precisa classificar os problemas conforme o risco ou o custo causado pela lentidão no atendimento e criar sistemas de trabalho que permitam endereçar os problemas corretamente. Muitas vezes, a resolução do problema (o tempo que o desenvolvedor leva para realizar uma ação corretiva, por exemplo) é rápido. Entretanto, o tempo que o problema demora para ter seu atendimento iniciado frente a todas as outras demandas, é alto. Como resultado, um problema emergencial que demandaria atendimento prioritário devido ao risco de não fazê-lo rapidamente, pode ser deixado de lado, em detrimento de algo menos prioritário cujo risco é baixo. O custo deste atraso pode ser muito significativo para o negócio – muito mais significativo do que o tempo de implementação e testes.

Assim como em um protocolo médico, é preciso definir critérios objetivos para identificar e classificar o risco, direcionando a demanda para o sistema de trabalho correto. Cada sistema de trabalho possui uma função (propósito) e este deve ser medido e acompanhado. Para garantir a fluidez e o funcionamento dos sistemas, há necessidade que algumas pessoas desempenhem papéis específicos pois é através deles que o sistema se manterá alinhado ao seu propósito.

Alguns papéis relevantes neste ecossistema são:

  • Gestor de Entregas (Delivery Manager), responsável por acompanhar as métricas e reportá-las, garantir que a meta de cada sistema está sendo atingida, coordenar a operação.
  • Líder Técnico, responsável por garantir o trabalho da equipe técnica, removendo impedimentos, alocando especialistas de um sistema para outro quando necessário, coordena e esclarece quem são os técnicos responsáveis por qual sistema no período.
  • Equipe técnica, responsável por tratar os problemas do software.
  • Líder de Suporte, responsável por facilitar a comunicação, liderar as reuniões de follow up, ajudar na triagem e classificação, mantém atenção especial ao atendimento emergencial e urgente (inclusive endereçando o problema deste sistema para o técnico adequado), acompanha o retorno e satisfação dos clientes, etc.
  • Equipe de Suporte, responsável por compreender o problema e a necessidade, realizar a comunicação com o usuário, executar testes e realizar a entrega.
  • Gatekeeper (Comitê de Decisão sobre a Seleção, geralmente composto por stakeholders e um único PO). Enquanto os stakeholders elencam necessidades e defendem as prioridades, o PO é o responsável por tomar a frente no papel de decisão sobre a seleção dos itens que serão priorizados. Desse modo, o PO tem um papel de forte comunicação e resolução de conflitos entre clientes (e também com a equipe técnica). É o principal responsável por assegurar que serão priorizadas as demandas de melhoria frente ao conjunto total de necessidades.

Nem todos estes papéis desempenharão funções em todos os sistemas e nem todos eles precisam ser executados exclusivamente por uma pessoa. Isso dependerá do contexto e da quantidade de pessoas na equipe. De uma forma ou de outra, as funções mencionadas são executadas pelas equipes, ainda que de forma desestruturada e sem denominação.

Atendimento de Emergências e Urgências

Neste sistema de trabalho a principal meta é o tempo de resposta. Para perseguir esta meta deve ser definido e acordado com os clientes um SLA (Service Level Agreement ou Acordo de Nível de Serviço). É importante medir, dos itens que surgiram ao longo do tempo, quantos foram aderente ou não ao SLA definido para cada categoria. Isso implica em acompanhar a taxa de itens atendidos dentro do SLA previsto. Este indicador é chamado de DDP (Due Date Performance). Na prática, problemas emergenciais em um software, precisariam ser atendidos em poucas horas.

Neste mesmo sistema de trabalho deve-se tratar problemas que são emergenciais e urgentes (estes, que suportam alguma espera). A equipe precisará lidar com estes problemas fazendo uma triagem com base em critérios objetivos, reagindo em um tempo considerado adequado, medindo e acompanhando este processo ao longo do tempo. A diferença dos problemas emergenciais e urgentes é uma pequena variação no tempo de resposta necessário dado o risco do problema.

Neste sistema o Gestor de Entregas tem a função de ajudar na definição objetiva de critérios de triagem e verificar se estão sendo respeitados no dia a dia. Atuam também os Líderes Técnico e de Suporte, bem como a Equipe Técnica e de Suporte.

O ciclo de acompanhamento deste sistema pode ter periodicidade semanal, onde no início da semana é apresentada a visão geral sobre itens não tratados ao final da semana anterior, alinhamento dos combinados (critérios de classificação), bem como fazer divulgações sobre o negócio que normalmente perpassam os demais sistemas de trabalho. Ao final do ciclo os indicadores mencionados anteriormente devem ser acompanhados e devem estar visíveis para todo o time.

Sob o aspecto da motivação da equipe é desejável que as pessoas não fiquem neste sistema por um longo período de tempo, mas façam um rodízio, para que não percam uma visão mais ampla sobre o negócio.

Atendimento de Mudanças Programadas

Em um nível de risco menos crítico estão as demandas programadas, que possuem algum prazo ou agendamento, onde há uma expectativa de entrega e um risco de não fazê-la, mas o custo de não atendê-la em poucas horas ou dias não é o mesmo dos dois casos anteriores. Neste cenário, é possível fazer uma priorização e entregas que possuem cadência, preferencialmente priorizadas e planejadas frequentemente com os stakeholders que tenham gabarito para realizar esta ação – jamais pela equipe de desenvolvimento que vai executar as entregas. Entendendo que, novamente, não deve-se categorizar a natureza do problema e sim seu risco. Por exemplo, um bug poderia ser tratado pelo sistema de trabalho programado, contanto que o risco trazido para o negócio não se encaixe nos dois primeiros cenários.

Estas entregas frequentes (semanais, quinzenais, etc) também podem ser medidas, porém não por SLA, mas por outras métricas que permitam começar a avaliar a previsibilidade de entrega, acompanhando o planejado versus entregue, como vazão, tempo de entrega, trabalho feito ao longo do tempo rumo à uma meta (throughput, leadtime, burndown, etc).

Diferente do sistema anterior, neste sistema atuam o Gestor de Entrega, o Líder Técnico e a Equipe Técnica e, adicionalmente, o Gatekeeper, papel fundamental para a correta execução do fluxo e manutenção do propósito do sistema.

Metodologias de trabalho como Scrum e Kanban são mais usuais neste sistema de trabalho. O ciclo de acompanhamento pode ocorrer semanalmente, quinzenalmente, a depender dos combinados. Inicia-se com a apresentação do trabalho priorizado pelo Gatekeeper, pode-se falar sobre aprendizados, discussão sobre riscos e alinhamento de acordos. É um bom hábito realizar uma coordenação diária e, ao final, divulgar os resultados do ciclo bem como realizar alguma retrospectiva. Uma atenção ao que NÃO é executado neste sistema: criação de novas features que demandem descoberta e execução de histórias de usuário. Este sistema endereça demandas simples, tickets, etc. O sistema a seguir será o responsável por pensar em novas funcionalidades para resolver problemas e expandir a capacidade do software.

Atendimento de Ampliação de Capacidade

Até então, tratou-se o risco de perder receita, clientes, credibilidade, ou seja, o custo de deixar de operar corretamente. Neste cenário é tratado o risco de “não ganhar”, ao invés do risco de perder. Isso pode ser traduzido em ausência de inovação, não aproveitar uma oportunidade de mercado, não otimizar o processo e reduzir o custo, não expandir as operações, etc. Demorar a endereçar a ampliação de capacidade também tem um risco e é preciso tratá-lo, mas as demandas podem ser atendidas como projetos. São projetos novos, com maior valor agregado e maior tempo de duração – provavelmente, em uma ordem de grandeza de alguns (poucos) meses.

Atuam neste sistema o Gatekeeper, o Gestor de Entrega, o Líder Técnico e a Equipe Técnica. Diferente dos demais sistemas que tem como uma boa prática a realização do rodízio entre os participantes da Equipe Técnica, neste sistema isso não é adequado, pois acaba promovendo perda de conhecimento e consequentemente baixa produtividade. Deste modo, para que um projeto não dure muito tempo e permita uma equipe “fixa”, o projeto deve ser pequeno e focado no atingimento de apenas um item de valor para o negócio por vez – foco em entregar a Mínima Funcionalidade Comercializável (Minimum Marketable Feature).

O ciclo de acompanhamento deste sistema começa com a definição da solução em alto nível (provavelmente usando alguma técnica de descoberta do Design Thinking, Lean Inception, Design Sprint, etc). Após isso, o produto vai sendo detalhado em unidades menores (histórias de usuário) e construído, com coordenação diária e acompanhamento semanal, preferencialmente abordando não só o produto, mas também melhorias no processo de trabalho. Esse processo ocorre diversas vezes até a homologação e publicação do software em produção.

Atendimento de Melhoria Continuada

Por fim, há o risco de deterioração, onde entram as questões relativas à melhoria contínua. Neste caso, o risco de não tratar os problemas em um tempo adequado é o impacto que a própria deterioração pode causar, gerando mais emergências e urgências, afetando a dinâmica do atendimento e os sistemas de trabalho. A entrada de questões a tratar neste cenário são, provavelmente, oriundas dos cenários anteriores cujos problemas possuem riscos mais críticos, ou seja, a partir de questões percebidas quando problemas dos outros níveis foram tratados, ou até mesmo pela quantidade de problemas de algum tipo (muitas urgências de um mesmo tipo em um curto período de tempo, por exemplo).

Por este motivo, o Líder de Suporte e o Gatekeeper (PO) são importantes. O primeiro para agregar sua visão dos problemas recorrentes e necessidades de melhoria no produto. O segundo para garantir espaço para priorização dos itens de melhoria. Também participam o Líder Técnico e a Equipe Técnica.

O ciclo de acompanhamento deste sistema é bastante simples, onde inicia-se planejando qual será o esforço dedicado ao assunto, priorizando o que deve ser tratado e fazendo acordos. A equipe técnica, conforme os combinados de alocação de esforço implementa as melhorias. Define-se uma periodicidade de acompanhamento de entrega (pode ser de alguns meses – dois ou três) e, ao final do ciclo, apresenta-se o que foi realizado.

Relato de Experiência

No momento em que este artigo foi escrito, a autora deste blog gerenciava uma equipe de manutenção, então achamos que seria interessante trazer uma experiência prática como exemplo.

A realidade do sistema é um cadastro de âmbito nacional, utilizado por órgãos do governo, mercado privado e pelos cidadãos, com grande potencial de fornecimento de informações e integração com outros sistemas. Há duas equipes para manter o negócio, uma que cuida das necessidades e demandas de ampliação de capacidade e outra equipe que cuida especificamente de integrações e fornecimento de dados – por conta da abrangência deste sistema o volume deste tipo de demanda é altíssimo – além de demandas de manutenção.

Deste modo, a equipe de manutenção está submetida aos sistemas de trabalho citados no artigo, exceto ao sistema de ampliação de capacidade. Se em algum momento é necessário atender este sistema, destaca-se parte da equipe para que fique focada nele por um período.

De modo geral, parte dos conceitos citados aqui são aplicados e utiliza-se Kanban com quadro eletrônico para coordenação tática da equipe. Ainda é preciso aprimorar as medições pois há algumas restrições nas ferramentas utilizadas na organização e o custo de gestão para manter as informações das demandas em outra ferramenta também ainda é alto.

Entretanto, há um item que gostaríamos de destacar pois impacta fortemente o trabalho e, até o momento, não conseguimos endereçar porque não depende exclusivamente da equipe: o Gatekeeper. As demandas são recebidas de diversas fontes (clientes, áreas de negócio, lideranças, usuários, etc). Não há uma pessoa única com visão do todo – só a equipe possui visão sistêmica. Isso dificulta bastante a priorização. Atualmente, já conseguimos, em alto nível, apresentar alguns resultados (mensalmente, trimestralmente…) para partes interessadas que poderiam funcionar como Gatekeepers mas, na prática, este papel não existe, pois seria necessária a denominação de uma única pessoa e uma atuação mais frequente (especialmente no que tange mudanças programadas e melhoria contínua), ficando a cargo da própria equipe orquestrar a priorização. Isso é uma péssima prática, pois a equipe tem sua própria “ignorância sistêmica” e muitas vezes pode estar priorizando inadequadamente. A equipe também fica responsável por ter a disciplina de seleção de itens de melhoria continuada e, para tentar estar alinhada ao propósito da organização, sempre se volta para o planejamento estratégico da empresa no momento da seleção dos itens – embora isso não seja suficiente para garantir o alinhamento ao propósito do negócio. Há uma área de negócio que atua fazendo um direcionamento/alinhamento de expectativas em alto nível, mas isso não é suficiente para tratar uma programação periódica continuada.

Sendo assim, o primeiro conselho que podemos oferecer a vocês, independente do sistema de trabalho, é: “tenham um Gatekeeper”. #ficaadica

Quando conseguirmos aplicar mais práticas e isso nos possibilitar colher alguns frutos, voltaremos aqui para contar.

Como Resgatar o Valor do Trabalho de Manutenção?

Se você é gestor ou atua em uma equipe de manutenção, tem a oportunidade de resgatar o valor da sustentação do negócio. Embora seja muito interessante criar produtos para resolver problemas, também é fundamental manter a ordem e não deixar que os sistemas de trabalho sejam consumidos pelo caos. Manter o alinhamento do software com o propósito de negócio só é possível com reflexão, método, disciplina e organização.

#FICAADICA

Para conhecer este conteúdo de modo aprofundado, recomendamos o curso GESTÃO ÁGIL PARA SOFTWARES EM MANUTENÇÃO do Alisson Vale, que fala sobre toda a problemática da manutenção de software e mostra como aplicar esta dinâmica através de exemplos, estudo de caso e muita experiência.

Deixe uma resposta