Os seres humanos são máquinas imperfeitas. Aborrecem, têm processadores (e, por vezes, UIs) que não são muito bem compreendidos, e não são muito eficientes. Reconhecer o elemento humano como “Trabalhando como se pretende” e tentar trabalhar em torno ou melhorar a forma como os humanos trabalham poderia preencher um espaço muito maior do que o aqui previsto; no momento, algumas ideias básicas podem ser úteis para determinar como as interrupções devem funcionar.

Estado de Fluxo Cognitivo

O conceito de estado de fluxo é amplamente aceito e pode ser reconhecido empiricamente por praticamente todos os que trabalham em Engenharia de Software, Sysadmin, SRE, ou na maioria das outras disciplinas que requerem períodos focalizados de concentração. Estar na “zona” pode aumentar a produtividade, mas também pode aumentar a criatividade artística e científica. Atingir este estado encoraja as pessoas a realmente dominar e melhorar a tarefa ou projeto em que estão trabalhando. Estar interrompido pode expulsá-lo deste estado, se a interrupção for suficientemente perturbadora. Pretende-se maximizar a quantidade de tempo gasto neste estado.

O fluxo cognitivo pode também aplicar-se a atividades menos criativas onde o nível de habilidade requerido é menor, e os elementos essenciais do fluxo ainda são cumpridos (objetivos claros, feedback imediato, uma sensação de controle, e a distorção de tempo associada); exemplos incluem o trabalho doméstico ou a condução.

Pode-se entrar na zona trabalhando em problemas de baixa habilidade e de baixa dificuldade, como por exemplo jogar um videogame repetitivo. Também se pode chegar lá com a mesma facilidade, fazendo trabalhos de alta habilidade, problemas de alta dificuldade, tais como os que um engenheiro pode enfrentar. Os métodos para chegar a um estado de fluxo cognitivo são diferentes, mas o resultado é essencialmente o mesmo. 

Estado de fluxo cognitivo: criativo e empenhado

Esta é a zona: alguém trabalha num problema durante algum tempo, está consciente e confortável com os parâmetros do problema, e sente que pode corrigi-lo ou resolvê-lo. A pessoa trabalha intensamente no problema, perdendo a noção do tempo e ignorando as interrupções, tanto quanto possível. Maximizar o tempo que uma pessoa pode passar neste estado é muito desejável – eles vão produzir resultados criativos e fazer um bom trabalho por volume. Vão ficar mais felizes no trabalho que estão fazendo.

Infelizmente, muitas pessoas em funções do tipo SRE passam muito do seu tempo tentando e falhando em entrar nesse modo e ficando frustradas quando não conseguem, ou nunca sequer tentam chegar a este modo, definhando em vez disso no estado interrompido.

Estado de fluxo cognitivo: Angry birds

As pessoas gostam de executar tarefas que sabem como fazer. De fato, a execução de tais tarefas é um dos caminhos mais claros para o fluxo cognitivo. Alguns SREs estão de plantão quando atingem um estado de fluxo cognitivo. Pode ser muito gratificante perseguir as causas dos problemas, trabalhar com outros e melhorar a saúde geral do sistema de uma forma tão tangível. Pelo contrário, para a maioria dos engenheiros de plantão estressados, o estresse é causado ou pelo volume de alertas, ou porque estão tratando o plantão como uma interrupção. Estão tentando codificar ou trabalhar em projetos ao mesmo tempo que estão de plantão ou em interrupções em tempo integral. Estes engenheiros existem num estado de interrupção constante, ou de interruptibilidade. Este ambiente de trabalho é extremamente estressante.

Por outro lado, quando uma pessoa está concentrada em tempo integral nas interrupções, as interrupções deixam de ser interrupções. A um nível muito visceral, fazer melhorias incrementais no sistema, eliminar tickets, e corrigir problemas e interrupções torna-se um conjunto claro de objetivos, limites, e feedback claro: você fecha X bugs, ou você deixa de ser alertado. Tudo o que resta são distrações. Quando se faz interrupções, os seus projetos são uma distração. Mesmo que as interrupções possam ser uma utilização satisfatória do tempo a curto prazo, num ambiente misto de projeto/de plantão, as pessoas acabam por ser mais felizes com um equilíbrio entre estes dois tipos de trabalho. O equilíbrio ideal varia de engenheiro para engenheiro. É importante estar ciente de que alguns engenheiros podem não saber qual o melhor equilíbrio que os motiva (ou podem pensar que sabem, mas podem discordar). 

Fazer uma coisa bem

Você pode estar se perguntando sobre as implicações práticas do que você leu até agora.

As seguintes sugestões, baseadas no que tem funcionado para várias equipes SRE que tenho gerido no Google, são principalmente para o benefício dos gestores de equipe ou influenciadores. Este documento é agnóstico dos hábitos pessoais – as pessoas são livres para gerenciar seu próprio tempo como acharem melhor. A concentração aqui é em dirigir a estrutura de como a própria equipe gere as interrupções, de modo que as pessoas não sejam preparadas para falhar por causa da função ou estrutura da equipe.

Distração

As formas como um engenheiro pode ser distraído e, portanto, impedido de alcançar um estado de fluxo cognitivo são numerosas. Por exemplo: considere um SRE aleatório chamado Fred. Fred chega ao trabalho na segunda-feira de manhã. Fred não está de plantão ou em interrupções hoje, por isso Fred gostaria claramente de trabalhar nos seus projetos. Ele pega um café, coloca seus fones de ouvido “não perturbe” e se senta em sua mesa. Tempo da zona, certo?

Exceto, a qualquer momento, qualquer uma das seguintes coisas pode acontecer:

• A equipe de Fred utiliza um sistema automatizado de tickets para atribuir tickets à equipe de forma aleatória. Um ticket é atribuído a ele, com vencimento hoje.

• O colega de Fred está de plantão e recebe um alerta sobre um componente em que Fred é especialista, e interrompe-o para perguntar sobre ele.

• Um usuário do serviço de Fred levanta a prioridade de um ticket que lhe tem sido atribuído desde a semana passada, quando estava de plantão.

• Um lançamento de sinalizador que está sendo implementado ao longo de 3 a 4 semanas e é atribuído a Fred dá errado, forçando o Fred a largar tudo para examinar o lançamento, reverter a alteração, e assim por diante.

• Um usuário do serviço de Fred o contacta para fazer uma pergunta, porque Fred é um sujeito muito útil.

• E assim por diante.

O resultado final é que, embora Fred tenha todo o dia de calendário livre para trabalhar em projetos, ele continua a ser extremamente distraído. Algumas destas distrações ele próprio pode gerir fechando o e-mail, desligando o IM, ou tomando outras medidas semelhantes. Algumas distrações são causadas pela política, ou por suposições em torno de interrupções e responsabilidades contínuas.

Você pode afirmar que algum nível de distração é inevitável e intencional. Esta suposição é correta: as pessoas agarram-se a bugs para os quais são o principal contato, e as pessoas também acumulam outras responsabilidades e obrigações. No entanto, há formas de uma equipe poder gerir a resposta de interrupção para que mais pessoas (em média) possam entrar no trabalho pela manhã e sentir-se imperturbáveis.

Tempo de polarização

A fim de limitar a sua distração, deve tentar minimizar as mudanças de contexto. Algumas interrupções são inevitáveis. No entanto, ver um engenheiro como uma unidade de trabalho que pode ser interrompida, cujas interrupções de contexto são livres, não é ideal se você deseja que as pessoas sejam felizes e produtivas.  Atribua um custo às trocas de contexto. Uma interrupção de 20 minutos enquanto se trabalha num projeto implica duas interrupções de contexto; realisticamente, esta interrupção resulta na perda de algumas horas de trabalho verdadeiramente produtivo. Para evitar ocorrências constantes de perda de produtividade, visar um tempo polarizado entre estilos de trabalho, com cada período de trabalho o mais longo possível. Idealmente, este período de tempo é de uma semana, mas um dia ou mesmo um meio dia pode ser mais prático. Esta estratégia também se enquadra no conceito complementar de fazer tempo.

O tempo de polarização significa que quando uma pessoa chega ao trabalho todos os dias, ela deve saber se está fazendo apenas um trabalho de projeto ou apenas interrompendo. Polarizar seu tempo dessa maneira significa que eles se concentram por períodos mais longos na tarefa em questão. Não ficam estressados porque estão sendo amarrados a tarefas que os afastam do trabalho que deveriam estar fazendo.

Sério, me diga o que fazer

Se o modelo geral apresentado neste capítulo não funcionar para você, aqui estão algumas sugestões específicas de componentes que pode implementar aos poucos.

Sugestões gerais

Para uma determinada classe de interrupção, se o volume de interrupções for muito alto para uma pessoa, adicione outra pessoa. Este conceito aplica-se mais obviamente aos tickets, mas também pode se aplicar a páginas – o plantão pode começar a transferir coisas para suas páginas secundárias ou fazer downgrade para tickets.

De plantão

O engenheiro de plantão primário deve se concentrar apenas no trabalho de plantão. Se a página for silenciosa para o seu serviço, tickets ou outro trabalho baseado em interrupções que podem ser abandonados rapidamente devem fazer parte das tarefas de plantão. Quando um engenheiro está de plantão durante uma semana, essa semana deve ser anulada no que diz respeito ao trabalho do projeto. Se um projeto for demasiado importante para ser abandonado por uma semana, essa pessoa não deve estar de plantão. Escale para designar outra pessoa para o turno de plantão. Nunca se deve esperar que uma pessoa esteja de plantão e também faça progressos em projetos (ou qualquer outra coisa com um custo elevado de mudança de contexto). 

Os deveres secundários dependem de quão onerosos são esses deveres. Se a função do secundário é apoiar o primário no caso de uma falha, então talvez se possa assumir com segurança que o secundário também pode realizar o trabalho de projeto. Se alguém que não seja o secundário for designado para tratar dos tickets, considere a fusão dos papéis. Se se espera que o secundário ajude realmente o primário no caso de um volume elevado de alertas, ele também deve interromper o trabalho.

(Além disso: Nunca se fica sem trabalho de limpeza. A sua contagem de tickets pode estar em zero, mas há sempre documentação que precisa ser atualizada, configurações que precisam de limpeza, etc. Os seus futuros engenheiros de plantão lhe agradecerão, e isso significa que é menos provável que eles o interrompam durante o seu precioso tempo de espera).

Tickets 

Se atualmente atribui tickets aleatoriamente às vítimas da sua equipe, pare. Fazer isso é extremamente desrespeitoso com o tempo de sua equipe e funciona completamente contra o princípio de não ser o mais interrompível possível.

Os tickets devem ser uma função em tempo integral, durante um período de tempo que seja gerenciável para uma pessoa. Se você estiver na posição nada invejável de ter mais tickets do que os que podem ser fechados pelos engenheiros de plantão primários e secundários combinados, então estruture a sua rotação de tickets para ter duas pessoas lidando com tickets num determinado momento. Não espalhe a carga por toda a equipe. As pessoas não são máquinas e você está apenas causando mudanças de contexto que afetam o valioso tempo de fluxo.

Responsabilidades em curso

Na medida do possível, defina papéis que permitam a qualquer pessoa da equipe assumir a responsabilidade. Se houver um procedimento bem definido para executar e verificar pushs ou flag flips, então não há razão para que uma pessoa tenha que conduzir essa mudança durante toda a sua vida, mesmo depois de deixar de estar de plantão ou em interrupções. Defina uma função de gerente de push que possa fazer malabarismos com push durante seu tempo de plantão ou em interrupções. Formalize o processo de entrega – é um pequeno preço a pagar para que as pessoas que não estão de plantão disponham de tempo sem interrupções.

Estar em interrupções, ou não estar

Por vezes, quando uma pessoa não está em interrupções, a equipe recebe uma interrupção que a pessoa está excepcionalmente qualificada para tratar. Embora idealmente este cenário nunca deva acontecer, às vezes acontece. Deve-se trabalhar para que tais ocorrências sejam raras.

Por vezes, as pessoas trabalham com tickets quando não são designadas para lidar com tickets, porque é uma forma fácil de parecer ocupado. Tal comportamento não é útil. Significa que a pessoa é menos eficaz do que deveria ser. Eles distorcem os números em termos de quão gerenciável é a carga de tickets. Se uma pessoa for designada para os tickets, mas duas ou três outras pessoas também tentarem a fila de tickets, você ainda poderá ter uma fila de tickets incontrolável, mesmo que não perceba.

Interrupções redutoras

A carga de interrupção de sua equipe pode ser incontrolável se exigir que muitos membros da equipe façam interrupções de equipe simultaneamente a qualquer momento. Há uma série de técnicas que pode utilizar para reduzir a sua carga de tickets em geral.

Analisar de fato os tickets

Muitas rotações de tickets ou rotações de plantão funcionam como uma luva. Isso é especialmente verdadeiro para rotações em equipes maiores. Se estiver apenas em interrupções de dois em dois meses, é fácil enfrentar o desafio,144 dar um suspiro de alívio e depois retornar às suas tarefas normais. O seu sucessor faz então o mesmo, e as causas raiz dos tickets nunca são investigadas. Em vez de conseguir avançar, a sua equipe fica atolada por uma sucessão de pessoas que se aborrecem com as mesmas questões.

Deve haver uma transferência para tickets, bem como para trabalho de plantão. Um processo de transferência mantém um estado partilhado entre os responsáveis pelos tickets, à medida que a responsabilidade muda. Mesmo alguma introspecção básica nas causas de raiz das interrupções pode fornecer boas soluções para reduzir a taxa global. Muitas equipes realizam transferências de plantão e revisões de alertas. Muito poucas equipes fazem o mesmo para os tickets.

A sua equipe deve realizar uma limpeza regular para tickets e alertas, na qual você examina classes de interrupções para ver se consegue identificar uma causa raiz. Se você acha que a causa raiz pode ser corrigida em um período de tempo razoável, silencie as interrupções até que se espere que a causa raiz seja corrigida. Fazer isso fornece alívio para a pessoa que está lidando com interrupções e cria uma aplicação de prazo útil para a pessoa que está corrigindo a causa raiz.

Respeite-se a si próprio, bem como aos seus clientes

Esta máxima aplica-se mais às interrupções do usuário do que às interrupções automáticas, embora os princípios representem ambos os cenários. Se os tickets forem particularmente incômodos ou onerosos de resolver, é possível utilizar eficazmente a política para mitigar a carga.

Lembre-se:

• A sua equipe define o nível de serviço prestado pelo seu serviço.

• Não há problema em empurrar parte do esforço para seus clientes.

Se a sua equipe for responsável por lidar com tickets ou interrupções para clientes, pode frequentemente utilizar a política para tornar a sua carga de trabalho mais controlável. Uma política pode ser temporária ou permanente, dependendo do que faz sentido. Essa correção deve encontrar um bom equilíbrio entre respeito pelo cliente e respeito por si mesmo. A política pode ser uma ferramenta tão poderosa como o código.

Por exemplo, se apoia uma ferramenta particularmente frágil que não tem muitos recursos de desenvolvimento, e um pequeno número de clientes necessitados a utilizam, considere outras opções. Pense no valor do tempo que gasta fazendo interrupções para este sistema, e se gasta este tempo de forma sensata. Em algum momento, se você não conseguir a atenção necessária para corrigir a causa raiz dos problemas que causam interrupções, talvez o componente que você está dando suporte não seja tão importante. Deve considerar devolver o alerta, depreciando-o, substituindo-o, ou outra estratégia nesse sentido que possa fazer sentido.

Se houver passos particulares para uma interrupção que sejam demorados ou complicados, mas que não exijam que os seus privilégios sejam cumpridos, considere a utilização de uma política para empurrar o pedido de volta para o solicitante. Por exemplo, se as pessoas precisarem doar recursos de computação, prepare uma alteração de código ou configuração ou alguma etapa semelhante e instrua o cliente a executar essa etapa e enviá-la para sua revisão. Lembre-se que se o cliente quiser que uma determinada tarefa seja realizada, deve estar preparado para gastar algum esforço para obter o que deseja.

Uma ressalva para as soluções anteriores é que é necessário encontrar um equilíbrio entre o respeito pelo cliente e por si próprio. O seu princípio orientador na construção de uma estratégia para lidar com os pedidos dos clientes é que o pedido deve ser significativo, ser racional, e forneça todas as informações e todo o trabalho necessário para atender à solicitação. Em troca, a sua resposta deve ser útil e oportuna.

Fonte: Google SRE Book