/Desenvolvimento

voltar
/Desenvolvimento

Você não sabia que o suporte é a parte mais importante do trabalho de um desenvolvedor?

PorJim Bird em

Desenvolvimento ágil – o fato de você estar criando software funcional mais rapidamente e entregar de forma incremental – força os times de desenvolvimento a encarar um problema fundamental e comum: como equilibrar o trabalho de desenvolver software novo com a necessidade de dar suporte para um sistema que já está sendo utilizado em produção, seja ele um sistema legado que você está substituindo ou um sistema que você ainda está criando – e às vezes ambos.

Isso é um problema especialmente para times ágeis seguindo o Scrum. Por outro lado, para os times cumprirem os objetivos dos Sprint e se comprometerem a estabelecer uma velocidade para os planejamentos futuros, o time supostamente não deve ser interrompido enquanto estiver fazendo seu  trabalho. Por outro lado, a razão para se trabalhar de forma iterativa e incremental no Scrum é poder entregar software que funciona mais rápido e frequentemente ao cliente, que vai querer utilizar esse software o quanto antes e que necessitará de suporte e ajuda ao utilizar o software – ajuda e suporte que precisam vir das pessoas que escreveram o software.

Em algum ponto, quase sempre ainda no começo do desenvolvimento de um sistema, esses times precisam parar de trabalhar em uma bolha com seus clientes imaginários e começar a trabalhar no mundo real com clientes que possuem demandas reais.

Oferecer suporte para clientes e ainda assim desenvolver software novo

Isso significa que os times precisam achar uma forma de fazer o malabarismo de equilibrar suporte e manutenção com design e desenvolvimento, para lidar com prioridades que mudam rapidamente e com interrupções, reclamações, perguntas e o estresse de brigar com as coisas que quebram, ao mesmo tempo em que tentam entregar software de boa qualidade e ficar dentro dos prazos.

Não é fácil equilibrar dois tipos de trabalho completamente diferentes, com objetivos, incentivos e métricas em direções opostas. Como Don Schueler explica em “The Fragile Balance between Agile Development and Customer Support”, times de desenvolvimento – mesmo times ágeis que trabalham próximos de seus clientes – estão na maior parte do tempo voltados para si mesmos, focando em entrega, velocidade, custos, qualidade do código e questões técnicas. Times de suporte são voltados para fora, com foco nas relações com o cliente, na experiência deste e em minimizar os riscos operacionais.

Desenvolver é ser capaz de ser previsível e eficiente: entregar no prazo e manter o custo de desenvolvimento baixo. Dar suporte é ser responsivo e efetivo: ouvir o cliente, responder às suas perguntas, adequar um trabalho não planejado, pensar em problemas e resolvê-los prontamente. O trabalho de desenvolvimento é sobre fluxo, continuidade, previsibilidade, velocidade e, se gerenciado corretamente, está na maior parte das vezes sob o controle do próprio time. Suporte e trabalho de manutenção são guiados por interrupções, imediatistas, inconstantes e imprevisíveis – uma forma completamente diferente de trabalhar e de pensar. O trabalho de desenvolvimento exige que o time seja conduzido junto, para que possa colaborar em objetivos comuns e no projeto. A maior parte do trabalho de manutenção e suporte é separada e desconexa, tarefas menores que podem ser feitas por pessoas trabalhando independentemente. Desenvolvimento, mesmo em projetos com muita pressão, é medido em semanas ou meses. Suporte e manutenção precisam ser feitos em dias ou horas e, as vezes, até em minutos.

Modelos de suporte ágil: vítimas da manutenção

Uma forma com a qual os times tentam lidar com suporte e manutenção é sacrificar alguém do time: oferecendo uma “vítima da manutenção” que será encarregada temporariamente do fardo do suporte para o resto do time, permitindo que os outros foquem no design e no trabalho de desenvolvimento. Isso inclui receber as chamadas dos sysadmins e diretamente dos clientes, olhar os logs, resolver problemas, corrigir bugs. Isso pode significar permanecer depois do horário para ajudar a resolver e reparar um problema em produção ou em soltar uma correção e receber ligações tarde da noite ou nos finais de semana.

O resto do time tenta fazer de conta que a vítima não existe. Se a vítima não estiver ocupada trabalhando em questões de suporte ou corrigindo bugs encontrados na produção, eles talvez trabalhem na correção de outros bugs ou talvez com algum desenvolvimento de baixa prioridade, mas estão subtraídos da velocidade do time – ninguém depende deles para entregar alguma coisa importante.

Os times geralmente fazem um rodízio para as tarefas de triagem e suporte, por um ou dois Sprints. Dessa forma, todos “compartilham a dor” e se familiarizam com as tarefas de suporte e questões operacionais. Também há lados positivos de ser sacrificado para o suporte. Desenvolvedores ganham a chance de aprender mais sobre o sistema, de colocar em prática um pouco de suas habilidades técnicas e de sair um pouco da “roda de hamster” que é a entrega de software Sprint após Sprint. E eles ganham a chance de ser o herói da vez: tomar a frente e resolver algo importante, deixando o cliente feliz.

Kent Beck e Martin Fowler em Planning Extreme Programming estendem a ideia para empresas maiores ao criar um pequeno time de suporte para a produção: 2-4 desenvolvedores que se voluntariam a focar em correção de bugs e em lidar com problemas de produção. Desenvolvedores gastam alguns Sprints em suporte para a produção, então voltam ao trabalho de desenvolvimento. Beck e Fowler recomendam equilibrar as rotações, certificando-se de que pelo menos um desenvolvedor está na primeira rotação e outro na segunda, para que pelo menos um membro do time de suporte sempre saiba o que está acontecendo e em que problemas eles estão trabalhando.

Sacrificar uma vítima da manutenção ou um time torna possível para o resto da equipe continuar a desenvolver, ao mesmo tempo em que cumpre os compromissos de suporte. Essa abordagem assume que qualquer um no time é capaz de resolver e corrigir problemas no sistema – que todos são generalistas multifunções. E isso significa que qualquer um que esteja na vez do suporte precisa ser bom o suficiente para lidar com a maior parte das questões sem trazer o resto do time – você pode alternar novatos nas tarefas de suporte e manutenção, mas com pelo menos alguém sênior no apoio a eles.

E você também precisa estar preparado para problemas que são grandes e urgentes demais para a sua vítima da manutenção cuidar sozinha. Mesmo com um time dedicado, você vai precisar construir algum tipo de “colchão” ou aparato para lidar com emergências e ajuda em geral, de forma que você não acabe atrapalhando os Sprints. Você pode criar alguma autorização baseada na “experiência passada”, na quantidade de suporte que o time teve que dar nas últimas semanas ou meses. Se não conseguir fazer isso funcionar, se o time todo estiver perdendo muito tempo no suporte, apagando incêndios e enviando correções, então você está fazendo alguma coisa errada e precisa ter as coisas sob controle antes de começar a criar mais software novo.

Kanban em vez do – ou dentro do – Scrum

Em vez de tentarem forçar a manutenção e o suporte dentro de espaços de tempo, alguns times descobriram que o Kanban é muito melhor estruturado do que o Scrum ou o XP para equilibrar suporte, manutenção e operacional com trabalho de desenvolvimento novo.

O modelo de filas do Kanban e o uso de quadros de tarefas torna mais fácil visualizar o que precisa ser feito, o que está sendo feito, quem está fazendo o quê, o que está no caminho e quando algo muda.

O Kanban torna mais fácil seguir e administrar diferentes tipos de trabalho que necessitam de habilidades distintas e que nem sempre se enquadram bem em espaços de tempo de uma ou duas semanas.

Ele não pretende que você não seja ou não possa ser interrompido – em vez disso, te ajuda a gerenciar as interrupções e a minimizar o impacto no time. Primeiro, no Kanban, você define os limites de com quantos trabalhos diferentes o time pode lidar de uma vez só. Isso permite que o time tenha controle sobre o trabalho que chega e fique focado em resolver as coisas. O modelo de filas e tarefas do Kanban permite que emergências pré-esvaziem qualquer trabalho que estiver em progresso via linhas de prioridade/escalonamento. E as prioridades podem continuar mudando até o último minuto – membros do time simplesmente pegam o item que tem a maior prioridade da lista de pronto quando eles estão livres para pegar mais trabalho, seja ele o projeto e desenvolvimento de um novo recurso, correção de bug ou lidar com alguma questão de suporte.

O Kanban ajuda os times a focarem mais nas questões imediatas e estratégicas. É um modelo melhor para seguir quando você tem mais trabalho de manutenção e suporte, do que projeto e desenvolvimento novos, ou quando você precisa de controle assertivo sobre um grande problema, para administrar algo com muitas mudanças, como o lançamento de um novo sistema.

Devops muda tudo

Devops, da forma seguida por empresas como o Etsy, Facebook e Netflix (onde eles vão tão longe a ponto de chamar NoOps) tenta quebrar completamente as fronteiras entre desenvolvimento, manutenção, suporte e operações. Devops engaja os desenvolvedores diretamente e de forma mais próxima ao suporte e operações. Devops que trabalham nessas organizações não estão apenas escrevendo código – eles são parte de um time que coloca para funcionar um negócio baseado num serviço online, o que significa que trabalho de suporte é tão importante, e às vezes mais importante, do que projetar e escrever mais software.

Nessas empresas, desenvolvedores têm responsabilidade pessoal sobre seus softwares, por colocá-los em produção e por certificar-se de que eles funcionam. Eles são chamados quando há problemas em softwares nos quais eles trabalharam. Eles estão ativamente envolvidos na administração do sistema, fornecendo ideias sobre como o sistema funciona e como está em produção, em testes, configurações, ajustes e nas resolução de problemas.

Devops muda aquilo em que os desenvolvedores trabalham e a forma como eles fazem isso. Eles se afastam do trabalho em projetos e se aproximam mais do desenvolvimento rápido de features, correções, ajustes e hardening. Disponibilidade, confiabilidade, segurança e outros fatores operacionais se tornam mais importantes do que calendários de entregas e velocidade. Desenvolvedores gastam mais horas pensando em como fazer o sistema funcionar, como simplificar o deployment e a configuração e sobre as informações que as pessoas precisam entender sobre o que está acontecendo “dentro” do sistema, que medições e ferramentas podem ser úteis, como lidar com dados ruins e falhas de infraestrutura, o que pode dar errado quando eles fazem uma alteração, com quem eles precisam conversar e o que necessita de testes.

Manutenção e suporte – Responsabilidade e feedback

Se os desenvolvedores precisam – ou mesmo devem – estar no primeiro nível de chamados de suporte dos usuários, eles precisam, pelo menos, ser parte do segundo e terceiro nível de suporte, nos quais os problemas são investigados e resolvidos.

Isso não é apenas porque eles normalmente são as únicas pessoas que podem compreender e resolver muitos problemas.

Colocando de lado argumentos morais perigosos sobre se é ético ou não aceitar que desenvolvedores não se responsabilizem totalmente pelas consequências de suas decisões e pela qualidade de seu trabalho, há vantagens convincentes para que os desenvolvedores estejam diretamente envolvidos no suporte e na manutenção do software no qual eles trabalham.

O mais importante é a qualidade do feedback que os desenvolvedores conseguem a partir do suporte a um sistema real – feedback é valioso demais para ser ignorado.

Feedback real em relação ao que você fez certo na criação do sistema e o que deu errado. Feedback sobre aquilo que você achou que o cliente precisava versus o que ele precisa de verdade. Que recursos os clientes realmente acham úteis (e quais eles não acham). Onde o projeto está fraco. De onde a maioria dos problemas está vindo (os 20% do código onde 80% dos bugs estão escondidos), onde estão os pontos fracos nos seus testes e revisões, onde você precisa focar e onde precisa evoluir. Informações valiosas sobre o que você está criando e como você está criando; como planeja e prioriza e como pode ficar melhor.

Quando desenvolvedores são chamados para apagar incêndios de incidentes em produção e descobrir a causa de algo, eles podem aprender muita coisa sobre o que é necessário para construir software no mundo real. Pensar seriamente sobre como problemas aconteceram e como prevê-los pode mudar a forma como você planeja, projeta, constrói, testa e faz deploy de software; e como as pessoas trabalham juntas em um time.

Delegar tudo isso para outra pessoa, filtrando através de um help desk ou um time de manutenção terceirizado quebra o ciclo desses valiosos feedbacks com efeitos negativos em todos os envolvidos.

Peter Gillard-Moss explica como isso acontece:

Em uma startup, desenvolvedores tomam conta dos problemas eles mesmos, bem, porque não há mais alguém para isso. Mas em algum ponto as coisas mudam:

…gerentes decidem que estamos gastando muito tempo investigando os problemas dos usuários, e não o suficiente criando os novos recursos que os negócios desejam. Desenvolvedores precisam ser mais produtivos, e mais produtivo significa desenvolvedores desenvolvendo mais features. Para fazer com que os desenvolvedores desenvolvam, eles precisam estar “focados”. Eles precisam de fones de ouvido e grandes telas para fixar seus olhares. Eles não precisam de interrupções insignificantes como as de usuários estúpidos ligando porque eles viram um popup dizendo que seus detalhes serão reenviados quando eles tentaram recarregar a página.

Mas, ao fazer isso, o time de desenvolvimento tornou-se desconectado dos resultados de seu trabalho e de seus clientes…

Uma pessoa que reflete sobre o assunto diria que isso é errado. Você foi de um sistema que conectava seus usuários com o time responsável com um grau de separação, para um que possui três graus de separação. Ou pense de outra forma: o time produzindo o produto e responsável pelas melhorias e correções costumava ficar a um grau de distância dos usuários que utilizam seus produtos e que estão fornecendo feedback dos defeitos e de questões relativas ao produto, mas agora se encontra a três graus de distância. E nem ao menos são três graus o tempo todo. Na maior parte do tempo, o time não irá nem ouvir a maioria das questões que chega até o suporte. Na maior parte do tempo, o time de desenvolvimento não terá muita interação com o time que escuta a grande parte dos problemas de suporte.

O resultado: os clientes não recebem o suporte que necessitam, e desenvolvedores não recebem as informações de que precisam para entender como melhorar o sistema em que trabalham. Um time de suporte espremido no meio, com pessoas que tentam apenas evitar que as coisas piorem e que esperam encontrar um trabalho melhor algum dia. É uma espiral negativa que se retroalimenta.

Em nossa empresa, o suporte tem prioridade em relação ao desenvolvimento – sempre. Nossos desenvolvedores seniores trabalham com o time de operações para dar suporte ao sistema e estão acessíveis por telefone quando lançamos um software novo e também se algo der errado logo em seguida. Eles podem trazer qualquer pessoa, de qualquer time, se precisarem de ajuda. Como resultado, temos muito poucos problemas sérios, e esses problemas são corrigidos rapidamente e da forma correta. A experiência que todos ganham ao trabalhar no suporte ajuda com que eles projetem e escrevam código melhor e mais seguro. Isso tornou o sistema mais resiliente, mais fácil, mais barato de dar suporte, mais seguro de configurar, executar e modificar. Isso também tornou a nossa empresa melhor. Trouxe os desenvolvedores para mais perto do time de operações e mais próximo do que é importante para o nosso negócio.

Se chamam isso de “ágil” ou não, não há nada mais ágil do que um time que trabalha diretamente com os clientes, respondendo imediatamente aos problemas e mudando as especificações em um sistema vivo. Enquanto alguns desenvolvedores e gerentes pensam nisso como uma despesa desnecessária, com um time de desenvolvimento e tentando empurrar isso para outras pessoas para que possam focar num trabalho “mais estratégico”, outros reconhecem isso como a verdadeira vanguarda do desenvolvimento de software e a única forma de colocar uma empresa de software para funcionar, a única forma de criar software e desenvolvedores melhores.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://swreflections.blogspot.com.br/2013/10/dont-you-know-that-support-is-most.html

Deixe um comentário! 0

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Comentando como Anônimo

leia mais