Os capitulos a seguir sucedem o encontro inicial entre Erik e Bill. E nessa parte do livro veremos os problemas da empresa se agravarem. Os autores vão expandir os e aprofundar os problemas técnicos, gerenciais e pessoais.

Outras capitulos:

Nem todos estão disponiveis ainda.

Capitulo 8

Bill passou o final de semana preparando uma apresentacao no PowerPoint para uma reunião com Steve. Ele espera uma discussão dificil e acredita que o sucesso ou o fracasso da empresa depende da sua capacidade de transmitir a mensagem.

Bil, divide com Steve sua preocupação com a sobrecarga de trabalho do time de TI. Ele argumenta que precisam de mais pessoas e de um foco mais direcionado nos projetos, pois tanto o projeto Fenix quanto de auditoria requerem atenção e segundo Bill só é possivel atender a um deles com eficiencia.

Steve, num tom rispido menospreza o pedido de Bill, dizendo: Que merda é essa de priorização? Se eu fosse à diretoria e dissesse a eles que preciso ou fazer vendas ou marketing, e perguntasse a eles qual dos dois deveria fazer, sairia da sala com eles rindo de mim. Eu preciso fazer ambos, assim como você precisa fazer ambos! A vida é dura. O Fênix é a prioridade da empresa, mas isso não significa que você possa deixar a auditoria de refém.”

Bill insiste que a falta de pessoal dificulta a execução de qualquer um dos projetos de maneira eficiente. Steve argumenta que ele precisa trabalhar com os recursos existentes, ainda mais porque o o projeto Fênix já excedeu o orçamento em 10 milhões de dólares. Bill ainda tenta contra argumentar, mas sem sucesso, Steve mantem sua posição. Saindo de lá Steve vai para uma reunião com Patty e Wes.

Chegando na reunião se depara com a equipe enfrentando o desafio de revisar e aprovar 437 mudanças. Há papeis e lousas por todos os lados. Conscientes da impossibilidade aprovar as mudanças em uma única reunião, após muito esforço eles decidem que parte das mudanças de aplicações criticas ficaram sob a responsabilidade deles e outra parte será compartilhada com os gerentes de cada área.

Capitulo 9

Bill está numa reunião importante de orçamento, quando recebe um telefone a respeito de um problema de severidade 1. Chegando na sala de War Room, o problema é resolvido inesperadamente por Brent. Bill, complemente insatisfeito com a dependencia que a empresa tem de Brent, além da maneira desorganizada como o incidente foi abordado. Pasa a exigir um processo mais estruturado para lidar com futuros problemas. Delega a Patty para coordenar as chamadas de incidentes. Bill inicialmente acredita que Brent poderia estar sabotando a empresa. Depois de uma série de reuniões, Patty apresenta um novo método de gestão de mudanças, onde todas as mudanças futuras são cuidadosamente registradas, categorizadas e agendadas. O fim da reunião termina com aplausos para Patty por sua organização

Capitulo 10

No início do dia, a equipe se reúne para um resumo das tarefas cruciais do projeto Fênix. Apesar de as tarefas serem reportadas como concluídas, existe a preocupação de que muitos problemas ainda estão surgindo e não estão sendo corrigidos tão rapidamente quanto deveriam. Durante a reunião, Kirsten, chama Brent diversas vezes para explicar por que tarefas não foram concluídas. Sarah então questiona a capacidade de Brent de realizar seu trabalho, então Bill intervém e vai verificar o que está acontecendo com Brent. Bill vai até Brent e observa discretamente seu trabalho, que inclui vários telefonemas e ao mesmo tempo que mexe nos sistemas. Bill percebe que Brent é muito acionado e por isso não consegue dar foco ao projeto Fenix. Bill decide acompanhar o dia de trabalho de Brent para entender melhor a situação. Brent é muito hábil e eficaz na resolução de problemas, mas essa sobrecarga de demandas está prejudicando o projeto Fênix.

Bill intervem e instrui Brent focar apenas no projeto Fênix e que qualque ligação deveria ser redicionado para Wes e em último caso para ele.

E para suprir a ausencia de Brent, Wes, Patty e Bill propõe criar um grupo de engenheiros de nível 3 que podem lidar com os incidentes, e se não conseguirem, apenas eles pode contatar Brent, desde que tenha a aprovação de Bill ou de Wes. A ideia é que esse grupo aprenda com Brent.

Capitulo 11

Bill, recebe uma chamada de Patty. Ela diz que está preocupada com alguns problemas no calendário de mudanças. Aparentemente, 60% das mudanças agendadas não estão sendo implementadas. Muitas razões são apresentadas para as mudanças não implementadas, a principal delas é a necessidade do envolvimento de Brent. A menção frequente de Brent faz com que Bill se preocupe, pois parece que a política de focar Brent somente no projeto Fênix pode estar causando problemas.

Bill, discute com Patty e Wes, como melhorar a situação, sugerindo diferentes formas de redistribuir o conhecimento de Brent e tentar desvincular a implementação das mudanças dele. Bill também pensa em envolver engenheiros de nível 3 para ajudar a resolver os problemas com as mudanças. Muitas mudanças planejadas não estão sendo concluídas. Bill então lembra das palavras de Erik quando ele comparou a situação da sua área de Operações com o chão de fábrica, onde o trabalho acumulado (o chamado "trabalho em andamento" ou WIP) pode indicar problemas de prazo e qualidade.

Bill se pergunta se os princípios de gestão do chão de fábrica, onde o controle do WIP é crucial, poderiam ser aplicados às Operações de TI. Após muito pensar, ele propõe que eles registrem e rastreiem as mudanças que envolvem Brent para ajudar a entender melhor e gerenciar a situação. Isso cria uma nova abordagem para lidar com os problemas, embora diferente de tudo que eles já fizeram antes.

Capitulo 12

O capitulo inicia na sexta-feira, dia de implantar o projeto Fenix. A implantação iria começar as 16h, mas não começou pois ainda está sendo realizado alterações de última hora, muitos problema estão ocorrendo. Atrasado em duas horas, o time de operações está paralisado aguardando instruções da equipe de desenvolvimento. O ambiente de teste está apresentando falhas críticas, com partes não funcionando conforme o esperado. A comunicação entre as equipes é complicada e a falta de coordenação e controle de versão está causando confusão e desorganização.

Enquanto isso, a equipe de Bill trabalha em conjunto com a equipe de testes para tentar solucionar os problemas encontrados. A falta de progresso está desgastando a paciência e a energia de todos os envolvidos. Brent, um dos engenheiros, sugere que precisarão de pelo menos mais 20 servidores para lidar com a carga do Fênix, um problema logístico adicional. Ao notar a gravidade da situação, Bill decide convocar uma reunião com Wes, Patty e William para discutir a situação.

William expressa seu receio com a implantação e relata muitos problemas com o desenvolvimento e desencoraja Bill a seguir com plano, pois teme que pode impactar toda operação no dia seguinte. Bill decide então que o projeto Fênix precisa ser adiado, para não correr o risco de afetar os sistemas atuais de POS nas lojas.

Bill escreve um email urgente para Steve, pedindo para adiar a implementação por uma semana devido ao alto risco de falha. No entanto, Steve responde que a decisão de adiamento cabe a Sarah. Em sua visão, já é tarde demais para recuar, pois as estratégias de marketing para o lançamento do Fênix já foram implementadas.

Frustrado, Bill desliga na cara de Steve. Agora ele precisa confrontar Sarah, a responsável por essa "missão suicida", para tentar adiar a implementação. Ao chegar para conversar com Sarah, ela relata já ter lido e respondido o e-mail que ele acabou de enviar para Steve. Bill, então lê o e-mail de Sarah que diz: “Nós todos nos esforçamos muito para que o Fênix chegasse até aqui. O Marketing está pronto, o Desenvolvimento está pronto. Todo mundo está pronto, menos você. Eu falei antes, mas aparentemente você não escutou: a perfeição é a inimiga do bom. Precisamos continuar.”

O problema se agrava com a execução de um script de banco de dados, onde não é possivel cancelar para evitar perda de dados e a estimativa que antes era de algumas horas, só ira terminar após mais de 3 dias. E como consequencia os sistemas de POS não irão funcionar. O dia amanhece, todos ainda acordados e são convocados para uma reunião com Maggie Lee. Na reunião revela que os sistemas POS em todas as lojas não estão funcionando, levando a um funcionamento manual dos caixas e leitores de cartões. Além disso, o site do Fênix não está funcionando adequadamente, gerando ainda mais reclamações dos clientes. A equipe concorda que precisa se comunicar proativamente com as lojas para orientar suas operações sem os sistemas POS.

O problema continua a agravar, foi descoberto que o sistema Fênix estava apresentando falhas graves, perdendo transações aleatoriamente e multiplicando cobranças no cartão de crédito dos clientes. além disso estava havendo vazamento de dados de cartões de crédito dos clientes no site e o problema estava sendo amplamente divulgado no Twitter. E o capitulo finaliza com Bill conversando com sua esposa expressando sua insatisfação com a recente promoção que aparentemente trouxe mais trabalho e problemas.

Sign here

Analise

Nesta parte do livro, parece que o "manto sagrado" de Steve está caindo, fica evidente através de seu linguajar e desprezo por Bill. Este comportamento é mais coerente com o ecossistema da empresa Parts Unlimited, que não é um ambiente cooperativo, mas sim um local onde todos parecem estar em conflito.

É interessante notar a mudança de tom ao longo do livro. Se anteriormente Patty e Wes eram vistos como o problema, agora eles são parte da solução. Bill encontra apoio e força neles, que não apenas endossam e ajudam em suas decisões, mas também acatam suas ordens sem hesitação. Embora existam momentos em que Bill percebe alguma discordância, Patty e Wes não demonstram resistência.

Steve, que antes era visto como um ser intocável no início, agora também se mostra hostil. Isso faz mais sentido de acordo com a imagem de empresa caótica. E mais uma vez, vemos a fórmula do caos sendo exposta capítulo a capítulo. Todos esses problemas poderiam ser resolvidos com abordagens baseadas na cultura Agile e DevOps. Apesar do autor não deixar isso explicito, a relação de causalidade é inegável.

O Capítulo 8, além do conflito com Steve, aborda o problema de priorização das tarefas. Já o Capítulo 9 introduz a questão da falta de compartilhamento de conhecimento, Brent é uma ilha, a ausência de padrões para a implantação de sistemas, e a excessiva dependência de um único profissional para resolver quase todos os problemas da área.

Em desenvolvimento de software, abordamos questões como essa através de práticas do Extreme Programming (XP), incluindo estratégias como pair programming. No entanto, quando se trata da área de operações, nossas soluções atuais incluem a implementação de pipelines de Integração Contínua (CI) e Entrega Contínua (CD) para padronizar os processos de deploy. Também utilizamos um conjunto de ferramentas, como Docker e Kubernetes, para criar ambientes isolados.

Essas ferramentas foram desenvolvidas para solucionar um problema comum na área de operações, que é personificado pela história do Brent.

Existem outras estratégias em consideração, como o uso de ferramentas para a gestão do conhecimento. Bill adotou outra abordagem, simples, mas que também dá resultados, que envolve criar uma base de conhecimento com base na experiência Brent. Dessa forma, o conhecimento de Brent pode ser compartilhado e aproveitado por toda a equipe.

O Capítulo 10 aprofunda a dependência de Brent e mostra Bill tentando solucionar o problema. Porém, a solução adotada por Bill não poderia ser pior: ele simplesmente "cortou o cordão umbilical" e retirou o acesso de todos a Brent. E para a surpresa de 0 pessoas, essa prática se revela ineficiente, pois o conhecimento dele não estava compartilhado.

Um problema evidente no livro é a progressão temporal. Há uma passagem de tempo à medida que os capítulos avançam. A ação de Bill de não permitir ninguém incomodar a Brent e a consequência direta dessa ação ocorre no mesmo dia. Isso induz a uma análise errônea, pois ao saber que Bill cortou o acesso a Brent pela manhã e à tarde as mudanças caíram para 40%, pode-se pensar inicialmente que esse problema não é devido a Bill e que pode estar relacionado a outras ações.

O Capítulo 12 certamente vai criar uma identificação maior com aqueles que têm mais de 30 anos. Servidores físicos, implementação de correções de bugs faltando apenas cinco minutos para a entrega do projeto, ausência de um sistema de controle de versões, grandes implantações não testadas - tudo isso retrata os dias sombrios da área de TI. É triste perceber o quão tóxico eram esses ambientes, pois apesar de metade da equipe técnica ter certeza de que tudo daria errado, dois ou três VPs mobilizavam as equipes noite adentro para fazer um trabalho fadado ao fracasso. Muitos se lembrarão de ações que tomaram no passado, como uma carga no banco ou um script sabendo que corromperia os dados, mas fizeram mesmo assim por livre e espontanea pressão.

O lançamento de um novo sistema, porém completamente ultrapassado e que só funciona na máquina de dois ou três desenvolvedores, outros problemas sérios de de segurança. O autor foi bastante generoso ao incluir a equipe de segurança nesta narrativa. Isso nem mesmo existia na época, se é que existe hoje, né? Aqui cabe a frase: "La garantia soy yo". Estes capítulos guiam o livro na direção certa: como falhar miseravelmente em um projeto.

Tenha em mente

O que estou fazendo é uma analise critica, adicionando novos pontos de vista ao livro, novas dimensões não exploradas. Não significa que não gostei do livro, ao contrário, fazer esse trabalho significa ampliar o debate.

Gostou dos novos sabores adicionado ao livro? Tem algum ponto novo a acrescentar? Gostaria de ouvir sua opinião.