The Phoenix Project e os 4 tipos de trabalho

Um livro que todos os envolvidos com projetos de TI deveriam ler é o The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win.

Ele narra a história de Bill, um VP de Operações que cai nesse cargo em meio ao desenvolvimento do projeto mais importante da empresa: O Projeto Phoenix.

Já no primeiro dia nesse novo cargo, nós temos uma visão de como a vida de Bill não vai ser nada fácil nas próximas páginas. Assim que ele acaba de ser promovido, o Sistema de Pagamentos da empresa apresenta um problema e adivinhem só: no dia de realizar o pagamento dos funcionários.

Nesse momento começa uma correria generalizada que se repete em outros pontos do livro para descobrir o que causa os problemas e como corrigir. Mantendo esse exemplo do Sistema de Pagamentos, Bill descobre que no dia anterior houve um upgrade do SAN (Storage Area Network), que apesar de ser uma mudança significativa, não justificaria o problema encontrado no sistema em questão. Depois de muito correr pela TI, ele descobre - meio que sem querer - que o campo que apresentou problemas no sistema havia sido alvo de questionamentos por parte de um desenvolvedor horas antes do problema acontecer. Indo a fundo nas investigações, ele encontrou o desenvolvedor responsável pelo questionamento e descobriu que o time de Segurança havia pedido que o tipo de criptografia daquele campo fosse alterado a fim de se adequar ao PCI que faria uma auditoria na semana seguinte.

Isso soa familiar?

A experiência de Bill no decorrer do livro traz exemplos bem familiares a todas as empresas que utilizam sistemas. Como na falha do Sistema de Pagamento, muitas mudanças são realizadas em ambiente de produção sem que todos os envolvidos fiquem sabendo. Gerando falhas que consomem tempo de investigação e correção, além do impacto ao cliente e perda de competitividade da empresa.

Muitas são as desculpas pra que esse ambiente caótico se mantenha:

  • “Nós até temos um processo de Gestão de Mudanças, mas se formos seguir esse processo a próxima janela de deploy só estaria disponível daqui a 4 meses e nós precisamos dessa mudança agora!”
  • “Nós não tivemos tempo suficiente para testar essa mudança, vamos colocar em produção assim mesmo e ver o que acontece”
  • “Nós até tinhamos tempo para testar mas o ambiente de teste não ficou pronto”
  • “O formulário de solicitação de mudanças tem muitos campos, levamos mais tempo o preenchendo do que executando a mudança”
  • Entre outras desculpas.

Continuando a falar sobre as desventuras de Bill, em meio a todos esses problemas rotineiros em sistemas já existentes, acrescenta-se o desafio de entregar um novo projeto (Phoenix) que tem nas mãos a responsabilidade de reerguer os negócios da empresa e vai para produção em 2 semanas. Isso mesmo, Bill acabou de chegar na bagunça e tem 2 semanas para colocar um sistema que ele não faz ideia do andamento em produção.

Não precisamos pensar muito para saber que não deu certo e que a culpa caiu sobre a TI, que prometeu e não cumpriu. Na verdade cumpriu pela metade, colocou o sistema em produção mas ele não funcionou, e pior que isso, afetou todos os sistemas de venda da empresa obrigando assim aos vendedores a trabalharem com recibos de papel. E também acrescentou uma falha de segurança ao processo, exibindo o CVC dos cartões de créditos dos clientes que fizessem compras on-line.

Nas reflexões para entender a fundo o porquê de tudo dar errado, chegamos ao ponto do livro que eu mais achei interessante que são os 4 tipos de trabalho. Se você não sabe o que precisa fazer, não vai saber estimar quanto tempo vai levar e nem quantas pessoas vai precisar. E isso acontece bastante no decorrer do livro, são muitas demandas com prazos que chegam todo tempo e muitas vezes dependem de uma única pessoa para ser resolvida (nesse caso Brent, o analista de operações que estava em todos os projetos e demandas - de verdade).

Para começar a organizar essa bagunça, Bill levanta quais são esses tipos de trabalho:

  • Projetos de Negócio - são os projetos alinhados as iniciativas de negócio da empresa;
  • Projetos Internos de TI - por exemplo criação de um novo ambiente, que são atividades demandadas para suportar os Projetos de Negócio;
  • Mudanças - são geradas a partir dos outros dois tipos de trabalho citados acima, geralmente são controladas por um sistema de Tickets;
  • Trabalho não planejado - problemas que precisam ser resolvidos na hora ou demandas que não passam por nenhuma priorização e caem diretamente no colo do executor.

De todos esses trabalhos, o grande vilão é o trabalho não planejado, que cresce cada vez mais e mata a capacidade de fazer o que está planejado. Quanto mais as coisas dão errado nos Projetos que são planejados, mais trabalho não planejado aparece - a partir dos erros gerados - e menos tempo se tem para atuar no que verdadeiramente traz valor para a empresa.

O livro é focado na parte de Operações de TI, mas parei para refletir sobre esses tipos de trabalho em todo ciclo de desenvolvimento do software.

E você, o quanto de trabalho não planejado tem atrapalhado o andamento dos seus projetos e o que você tem feito para melhorar isso?

Samy

Usamos também uma classificação parecida: Demandas de Negócio, Demandas de Melhoria e Trabalho não planejado.
Nos projetos que tenho trabalhado são poucos os trabalhos não planejados.
Para evitar isso nós trabalhamos com pouco trabalho em execução (WIP), e um limite de quantas demandas é suportada por time.
Assim temos controle para trabalhar com qualidade em cada demanda em execução.
“Pare de começar e comesse a terminar” esse é o nosso lema.

@Paulo-Tiago-Mariano no livro eles adotam Kanban pra melhorar o fluxo de trabalho :)

Samy

Log in to reply

Looks like your connection to Agile Testers was lost, please wait while we try to reconnect.