O que é a cultura blameless em torno de incidentes de tecnologia

Profissionais de tecnologia precisam se sentir à vontade para trabalhar e tocar projetos sem temer a ocorrência de incidentes e as repercussões negativas que eles podem trazer para suas carreiras. A solução para um incidente tem que ser bloquear ações inoportunas, e não impedir as pessoas de trabalhar e de criar. 

Se um desenvolvedor não fizer nada, não botar nada em produção, ele não corre o risco de provocar incidentes, mas também a empresa ou instituição não produz inovação. É o pior dos cenários para todos as partes.

Daí ser necessário criar um ambiente de trabalho blameless ou sem culpabilização, onde haja segurança para se testar novas ideias e também segurança para errar. É a chamada mentalidade de fearless execution, segundo a qual uma pessoa executa suas tarefas sem medo de falhar ou de destruir alguma coisa. 

E é vital para um profissional de tecnologia poder trabalhar dessa forma, porque é ela que permite que a criatividade e a inovação se manifestem. Mas, para que se possa agir sem medo, são necessários processos e controles secundários. 

Se um desenvolvedor não fizer nada, não botar nada em produção, ele não corre o risco de provocar incidentes, mas também a empresa ou instituição não produz inovação.

Como cultivar um ambiente de trabalho inovador e blameless 

Quem escreve um código precisa ser cauteloso e criterioso, testar o máximo possível, com a segurança de que todos na organização sabem que em qualquer área existem falhas de sistema, falhas humanas e falhas de outras naturezas, e não dá para se proteger de todas elas.

Basicamente é preciso assumir que um incidente vai acontecer em algum momento e tomar providências para proteger a instituição ou empresa da melhor forma, minimizando o tempo de mitigação, que é algo bastante relevante. A cultura blameless gira em torno disso também.

Como quase sempre o componente humano está presente em um incidente de tecnologia, o ideal é:

• Ter a cultura de revisão de código enraizada nos diferentes níveis da hierarquia das equipes de engenharia.
• Conduzir testes periódicos antes de colocar mudanças de código em produção.
• Contar com um sistema de gestão de mudanças que dificulte que ele seja burlado por atalhos humanos.
• Oferecer diretrizes claras sobre deploys e apostar em deploys contínuos e frequentes que possam gerar microincidentes, em vez de deploys esporádicos, com possibilidade maior de gerar macroincidentes.
• Reiterar que ninguém da equipe é super-herói para resolver problemas sozinho.

Além disso, cabe à liderança apontar que em todo incidente existe chance de aprendizado para as diversas partes da cadeia de envolvidos, inclusive para a própria liderança, que muitas vezes superestima sua capacidade de comunicar políticas como a da cultura blameless. Difundir a cultura é fundamental para que as pessoas não queiram fazer coisas escondido e para que realmente abracem a filosofia do trabalho colaborativo. Se tudo isso não fica transparente, a chance de novos incidentes só aumenta.

Demissões em decorrência de incidentes não deveriam acontecer em organizações de tecnologia, porque errar/assumir/consertar precisa ser uma cultura estabelecida. Reuniões sobre incidentes tendem a ser duras, mas cabe à liderança reforçar que o objetivo é o aprendizado, e não botar a culpa em ninguém. 

O propósito das reuniões tem que ser evitar que problemas semelhantes aconteçam e, ao mesmo tempo, arquitetar soluções, melhores de ferramentas, processos etc. no longo prazo.