Para ser sincero, quando o principal produto da sua empresa é software, acaba por saber um pouco sobre desenvolvimento de software. Neste artigo, vou revelar a minha descoberta sobre como o processo de desenvolvimento de software pode ser aplicado a todos os outros aspetos do seu negócio (e da sua vida) — independentemente do seu setor, da sua função ou do seu departamento. [Alerta de spoiler: há um livro que não pode deixar de ler — «The Phoenix Project» — à sua espera!]
Escolhemos«The Phoenix Project»para o nosso clube de leitura interno. Não tinha a intenção de escrever uma crítica, mas este livro de gestão atípico proporciona tantos momentos de revelação que não podemos guardá-lo só para nós. Embora não seja programador (mas trabalho com alguns excelentes), aprendi como eles abordam o seu trabalho e conheci ferramentas fantásticas, comoo [Kanban], para a visualização e gestão do fluxo de trabalho. Ferramentas que podem funcionar e vão funcionar para qualquer pessoa!
«O Projeto Phoenix: Um romance sobre TI, DevOps e como ajudar a sua empresa a ter sucesso»
Por Gene Kim, Kevin Behr e George Spafford
Imagine um romance fictício sobre um grupo de indivíduos muito diferentes que se unem para derrotar um dragão e salvar uma aldeia, só que, nesta história, os «guerreiros» são profissionais do mundo dos negócios, a aldeia é uma empresa de produção em dificuldades (verticalmente integrada com componentes de comércio eletrónico e retalho) e o dragão representa os problemas que a empresa enfrenta, especialmente todos os inúmeros desafios das operações de TI (interligados com todos os outros departamentos, como vamos descobrir!).
Qualquer empresa — ou qualquer pessoa — que trabalhe com, em, para ou no âmbito do «DevOps» deve ler este romance humorístico, mas muitas vezes assustador. Tendo em conta o nosso atual ambiente empresarial e, mais especificamente, a força de trabalho global, isso significa que este livro é para TODOS.
Praticamente todas as empresas, literalmente, funcionam com — e são geridas por — DevOps. É um elemento central do sistema nervoso da organização. A menos que sejas uma criança a gerir uma banca de limonada que só aceita pagamentos em dinheiro no jardim da frente.
O que é o DevOps?
Em termos de tecnologias da informação, o DevOps é uma fusão entre desenvolvimento (Dev) e operações (Ops). Já não «isolada em silos», a cultura de software atual une estes profissionais numa única equipa, que trabalha ao longo de todo o ciclo de vida da aplicação, desde o desenvolvimento e os testes até à implementação, passando pelas operações, pela garantia de qualidade e pela segurança. A experiência ensina-nos que trabalhar isoladamente em qualquer área, ou seja, sem partilhar informação ou conhecimento com os outros, cria mais problemas do que aqueles que resolve.
A história do «Projeto Phoenix» e a importância do DevOps
O DevOps é a «revolução industrial» da nossa era. Através da empresa de tecnologia fictícia Parts Unlimited (PU), os autores ilustram como muitos ambientes empresariais funcionam normalmente (de forma disfuncional!) e como qualquer mudança — ou a ausência dela — pode ser transformadora, sendo o DevOps o elemento central. O software é parte integrante de todas as empresas, a todos os níveis. A história oferece excelentes perspetivas sob todos os ângulos e não se destina apenas a profissionais da área técnica.
A nossa história de PU (trocadilho intencional) começa com uma catástrofe prestes a acontecer. Um diretor de TI de nível médio (Bill), cujos chefes «se demitiram» misteriosamente, é promovido a vice-presidente de Operações de TI, um cargo que nem ambiciona nem quer aceitar. A sua missão (pense em «Missão Impossível») — atribuída diretamente pelo CEO, que à primeira vista parece encantador — consiste em restabelecer as operações críticas da empresa e evitar que esta apareça nas primeiras páginas dos jornais… tudo isto no meio de um novo produto, o Projeto Phoenix, com atrasos de anos e um âmbito demasiado vasto, e com a confiança financeira pública da empresa a vacilar.
A mensagem do Bill parece condenada ao fracasso; o Projeto Phoenix é a «aposta de vida ou morte» da PU. Há intrigas políticas na empresa em torno do projeto, e a diretora de marketing (e provável sucessora do CEO), Sarah, é a principal antagonista, com um talento incrível para culpar os outros pelos seus erros, pelo menos segundo o departamento de TI.
Então surge o primeiro problema… os sistemas de processamento salarial estão um caos total (FUBAR – Fouled Up Beyond All Recognition). A ordem do Bill é clara: salvar a empresa de si própria.
A Desconexão
A nossa equipa fictícia começa por apresentar todas as características de pessoas que não confiam nem têm qualquer consideração pelos seus colegas de equipa. A falta de comunicação é a menor — e, em última análise, a principal — das suas preocupações. Em vez de se unirem para resolver problemas, atribuem culpas uns aos outros e tiram conclusões precipitadas e inadequadas uns sobre os outros. As personalidades interferem com o profissionalismo. A condescendência e o «teatro» corporativo são generalizados.
A discórdia entre os departamentos é evidente. Os autores dão-nos uma ideia do que os colaboradores das Operações de TI pensam sobre o resto da empresa:
- Os profissionais de marketing são «licenciados em artes ou música, e não pessoas com formação em estratégias tecnológicas»
- Os vendedores prometem aos clientes o impossível e esperam que o departamento de TI simplesmente resolva tudo e cumpra o prometido; não são de confiança: «Conheces o ditado, certo? A forma de perceber que um fornecedor está a mentir é quando os lábios dele se mexem.»
- Os vice-presidentes passam basicamente o dia todo a fazer apresentações em PowerPoint — uns aos outros —
- Os programadores «deitam achas para a fogueira»; estão sempre a causar falhas nos sistemas; estão com a cabeça noutro lugar ou de férias; muitas vezes causam problemas e, depois, desaparecem, deixando que a equipa de Operações de TI resolva a confusão
- A segurança da informação na sala é a melhor forma de garantir que algo NÃO seja feito
Um colaborador comenta que a popular série de televisão britânica «The IT Crowd» (uma das minhas favoritas!) reflete com precisão a realidade do dia-a-dia das Operações de TI. A equipa de TI — que interpreta CIO como «Career Is Over» (a carreira acabou), em vez de Chief Information Officer — considera que uma promoção não é necessariamente algo positivo. Manter um perfil discreto ajuda a evitar a burocracia da empresa. Isso fez-me pensar nos «flutuantes» de alguns programas de reality shows.
À medida que a história da PU se desenrola, as suspeitas aumentam e surgem teorias da conspiração sobre a forma como os concorrentes continuam a ficar um passo à frente deles. Será que há alguém a falar demais?
E a situação agrava-se. As especificações escritas nem sequer são elaboradas. Apesar das necessidades de marketing de alta tecnologia da empresa, os departamentos de TI e Operações não são consultados de todo, e o departamento de marketing recorre frequentemente à subcontratação para as aquisições de TI, contornando completamente o departamento.
As transferências de responsabilidades, especialmente entre o Desenvolvimento e as Operações de TI, nunca são bem geridas. Há sempre os inevitáveis projetos «ROUND-TUIT»: atualizações e manutenção de TI que são constantemente adiadas, à medida que emergências imprevistas e outras prioridades passam à frente. É uma guerra entre clãs.
A Avaliação — O Sistema Não Funciona
O Bill encara a sua promoção — e todos os problemas que há para resolver — com naturalidade. O seu estilo de gestão, que consiste em circular pelas instalações (e fazer as perguntas difíceis), ajuda-o a colocar os problemas da empresa numa perspetiva mais ampla, no que diz respeito ao próprio negócio.
Ele sabe que, na realidade, o departamento de operações não deveria estar a funcionar como se fosse um corpo de bombeiros e, embora, por ser uma grande empresa, a PU tenha mais pessoal disponível para lidar com os «simulacros de incêndio» diários, que decorrem a um ritmo frenético, do que as empresas mais pequenas, os problemas continuam a ser os mesmos. Tudo é considerado urgente. No entanto, se tudo é urgente, será que alguma coisa pode ser tratada com urgência?
Existem processos, procedimentos e sistemas para a gestão da mudança, mas raramente são seguidos. A falta de um planeamento adequado, em que «todos estejam presentes», é a norma. Não existem os ambientes de teste necessários, alegadamente devido à falta de orçamento. São definidas datas arbitrárias para a entrada em produção, ignorando completamente o que realmente precisa de ser feito antes da implementação.
O apoio não vem do topo da hierarquia da empresa. Equipamento moderno e formação são luxos que a empresa não pode permitir-se. A empresa está, basicamente, a avançar às cegas. Não há perceção da situação. A mão esquerda não sabe o que a mão direita está a fazer.
Ser proativo é uma preocupação secundária. A transparência é extremamente necessária.
A execução do projeto é impulsionada por prazos arbitrários — mas sempre urgentes —, devido a compromissos externos assumidos pela direção executiva sem uma compreensão completa dos problemas internos. A equipa de desenvolvimento vê-se então obrigada a recorrer a atalhos escandalosos e inaceitáveis para cumprir os prazos. É quase certo que o produto ficará inutilizável, e aqueles que o reclamam ficarão seriamente desapontados. A experiência do cliente será tão má que os levará a recorrer à concorrência. As Operações de TI terão de fazer tudo o que estiver ao seu alcance para que o produto funcione — e esconder o que se passa nos bastidores.
A equipa esforça-se por não deixar que a perfeição seja inimiga do bom. No entanto, as consequências para o negócio serão devastadoras; a empresa não está a funcionar a nível empresarial.
O software Phoenix, recém-lançado, está a fazer furor.
Ponto único de falha — Quem é o teu Brent?
Depois, há o «ponto único de falha» — aquele colaborador indispensável que está no centro de todos os projetos importantes e que é puxado em um milhão de direções diferentes. Aparentemente, nada pode acontecer sem o seu envolvimento. Ele/ela não pode ser substituído(a) nem replicado(a). Em «The Phoenix Project», o nome dele é Brent.
A produção não pode ser gerida sem uma lista centralizada de projetos: a PU não tem conhecimento das suas prioridades em termos de procura e dos seus compromissos, nem do estado do trabalho em curso, nem da disponibilidade de recursos. As Operações de TI estão no centro de todos os fluxos de trabalho, criando um estrangulamento no trabalho em curso, nos resultados dos projetos, nas interrupções de serviço e na conformidade.
Na PU, dedicar tempo a planear prioridades era considerado um desperdício. Não seguem a regra geral de que, se algo ganha prioridade (em termos de urgência), então outra coisa tem de ser relegada para segundo plano. Ainda não descobriram como reduzir o volume de trabalho de reparação de avarias, para que os projetos geradores de receitas possam ser realizados.
Como resolver o ponto único de falha da sua empresa? O livro começa por explicar a Teoria das Restrições.
O que é a Teoria das Restrições?
A Teoria dos Condicionantes (TOC) é um conceito de gestão segundo o qual apenas alguns condicionantes (aquele único ponto de falha no pessoal ou gargalo, como numa linha de produção industrial) são o que o impede de atingir os seus objetivos. Se se concentrar, poderá identificar qual é o condicionante e contorná-lo. Pense na expressão «uma corrente não é mais forte do que o seu elo mais fraco».
No entanto, se se fizer uma melhoria em qualquer outro ponto, seja a montante ou a jusante do estrangulamento, essa restrição continua a existir. No nosso cenário de produção, o trabalho está a acumular-se a montante, enquanto o trabalho em curso (WIP) sofre de falta de material a jusante do estrangulamento.
A gestão de processos no DevOps não é muito diferente da produção industrial ou da gestão de uma fábrica, e vice-versa. Todos os departamentos podem aprender uns com os outros. As mesmas ferramentas e técnicas podem ser utilizadas para documentar processos, identificar desperdícios de tempo e/ou materiais e melhorar todo o sistema.
Um dos membros do conselho de administração da PU foi mentor do Bill. A sua personalidade proporcionou uma orientação útil para a tarefa em questão, ao delinear os Quatro Tipos de Trabalho e as Três Formas.
Compreender os Três Caminhos
«As Três Vias» descrevem os valores e as filosofias que orientam os processos, procedimentos e práticas de todos os sistemas. O objetivo de qualquer empresa, de qualquer departamento e de cada colaborador é compreender verdadeiramente — e valorizar — o sistema, de modo a melhorar o seu trabalho e a oferecer melhores produtos e serviços:
- Pensamento sistémico— Controlar as restrições e acelerar o fluxo de trabalho, trabalhando da esquerda para a direita (obter resultados mais rapidamente)
- Ampliar o feedback — Encurtar o ciclo de feedback, trabalhando da direita para a esquerda (oferecer melhor qualidade)
- Cultura de experimentação e aprendizagem— Aceitar e incentivar a realização de testes para aplicar mais rapidamente as lições aprendidas com os erros (mitigar riscos e promover a melhoria contínua)
Compreender os quatro tipos de trabalho
Compartimentar o que fazemos e atribuir métricas a cada tipo de trabalho ajuda-nos a identificar melhor os pontos de estrangulamento, ou seja, as restrições:
- Projetos empresariais— Trabalhar com impacto direto nos resultados financeiros, como novos produtos e novas funcionalidades
- Projetos internos de TI/Operações — Trabalho necessário para apoiar projetos empresariais, tais como I&D (investigação e desenvolvimento), novas arquiteturas, infraestruturas ou engenharia
- Alterações— Modificações ao trabalho programado dos «projetos internos» que apoiam os «projetos empresariais»
- Trabalho não planeado— erros, defeitos, retrabalho, gestão de crises, etc., que desviam recursos dos «projetos empresariais» geradores de receitas
É evidente que a conclusão é que os projetos internos bem executados têm um efeito positivo nos projetos empresariais e também reduzem a quantidade de trabalho não planeado.
Sem revelar o final do livro (Project Unicorn!), digamos apenas que as tensões se intensificam a um ponto que nenhum empresário, nem qualquer funcionário — seja gestor ou não —, quer chegar.
A solução está ao seu alcance
- Automatize os processos recorrentes tanto quanto possível, controle e documente o trabalho (especialmente as alterações) e reveja, reveja, reveja
- Identificar os problemas mais cedo, dividir o trabalho em partes mais fáceis de gerir, contactar todas as partes interessadas para verificar os resultados, fazer alterações sempre que necessário e entregar os resultados mais rapidamente
- Padronizar para obter resultados melhores, mais repetíveis, mais precisos e mais rápidos
- Comunicar
«O Projeto Phoenix» fez-me olhar para muitas coisas de uma nova perspetiva. Por exemplo, tudo é um sistema. Uma empresa, uma fábrica, o plano de transportes de uma cidade, até mesmo a tua família ou o teu próprio corpo. As soluções para gerir todos estes «sistemas» são assustadoramente semelhantes. Não me canso de recomendar a todos: leiam o livro.
Conclusões
- Conhecer os seus clientes a um nível mais profundo pode ser o que uma empresa pode fazer de mais valioso.
- A burocracia é inerente a qualquer empresa. À medida que a empresa cresce, são necessárias novas medidas de segurança para garantir que a comunicação decorra sem problemas. Se a sua empresa for pequena e houver rotatividade de pessoal, esses problemas de comunicação próprios das grandes empresas também ocorrem.
- O processo de gestão da mudança implica disciplina — é difícil de implementar, mas é muito pior se NÃO existir. «Não se consegue alcançar o estratégico sem primeiro dominar o tático.»
- Se alguém perguntar como resolveste um problema, não há nada pior do que responder «Não sei». Documenta! Da próxima vez que isso acontecer, já teremos a resposta. O conhecimento é poder. O conhecimento que não é partilhado não vale nada e, pior ainda, gera caos.
- Se um departamento atingir um marco importante, mas outro grupo da empresa for afetado negativamente, não organizes uma «festa de cerveja» nem envies um e-mail em massa. Isso é simplesmente falta de tacto. Provavelmente não gostaste quando toda a tua turma do 5.º ano — exceto tu — foi convidada para a festa de aniversário do miúdo mais popular. E se fosses tu o miúdo mais popular, devias ter vergonha. Lembra-te: ninguém é uma ilha. Ou nos afogamos ou nadamos juntos. Adia a festa até que todos possam celebrar juntos.
- Se tiveres notícias para partilhar, partilha-as. Talvez o novo processo de gestão da mudança que foi implementado te tenha acabado de salvar de um desastre — divulga a notícia! Reforça o facto de que algo está a funcionar. Elogios, palmadinhas nas costas e agradecimentos demoram pouco tempo e trazem enormes benefícios em termos de moral e entusiasmo. «Mais vale prevenir do que remediar», mas o problema da prevenção é que as pessoas raramente têm conhecimento dela. Comunica as vitórias!
- Se todos compreenderem de que forma o seu trabalho compromete os indicadores-chave de desempenho (KPI) da empresa, ou seja, os indicadores do desempenho global da empresa, em vez de ficarem desmotivados, é mais provável que se sintam capacitados e tomem melhores decisões empresariais e profissionais.
- Os problemas surgem sempre. Não tire conclusões precipitadas. Não aja de forma precipitada e agrave o problema. Não traia ninguém pelas costas, não passe a responsabilidade para outros nem entre no jogo das culpas. Certifique-se de que os processos estão em vigor. Siga o processo. Seja proativamente parte da solução e melhore o processo, conforme necessário.
- Conheçam-se — e compreendam-se — uns aos outros, tanto a nível pessoal como profissional. Isso promove o respeito, a confiança e melhores relações de trabalho. Quando estou a conhecer alguém, especialmente alguém com quem trabalho (ou que estou a entrevistar para contratar!), a minha nova pergunta preferida é: «O que distingue, para si, um bom dia de trabalho de um dia mau?»
Conclusão
Na nossa última reunião do clube de leitura, os meus colegas de trabalho deram algumas risadas, pois cada um de nós parecia identificar-se com uma ou mais das personagens, traços de comportamento e/ou ações. Depois, recompusemo-nos, sacudimos o pó das consequências e conversámos sobre o nosso próprio progresso interno no sentido de alcançar mais estrutura, melhores processos e uma maior abertura à mudança, para oferecermos melhores produtos e serviços aos nossos clientes.
A xTuple valoriza a inovação, bem como a interligação em toda a empresa e a partilha de diferentes perspetivas — a nível interno, com os colaboradores, e a nível externo, com os clientes e a comunidade tecnológica em geral.
Acabem com esta loucura e comuniquem-se. Criem um processo sustentável e bem definido com o qual todos concordem. As definições são importantes. A compreensão é importante. Continuem a ajustar o processo até que funcione. É possível.
