Estudo de caso: Devo propor um novo sistema de gerenciamento de projetos?

Cynthia Ramos só queria pegar sua salada de macarrão na geladeira comum e comer em sua mesa, mas, em vez disso, foi sugada para outra conversa com Jim Miller. Desde que ela entrou na MainFrame como desenvolvedora de software, seis meses antes, todas as conversas com Jim tinham sido sobre como o sistema de gerenciamento de projetos da empresa era um obstáculo. Em seu primeiro dia - em uma sala cheia de novos colegas - ele perguntou se seu antigo empregador usava o Scrum.1 Quando ela respondeu que não, ele deu uma risadinha e disse: "A senhora pode se arrepender de ter vindo para cá!" Agora, Jim gritou uma saudação: "Ei, Ramos, como está indo o seu sprint?" Ele e seus companheiros de mesa - Adnan Persaud e Wai Quon - caíram na gargalhada. "Bem", respondeu Cynthia, sorrindo e pegando seu almoço. Ao sair da sala, ela ouviu Jim sussurrar: "Sei que ela odeia o Scrum tanto quanto eu". Cynthia não adorava o Scrum, mas gostava de trabalhar na MainFrame. Seu empregador anterior, a Ambitious Computing, um start-up focado em inteligência artificial, era mais avançado tecnologicamente e seus colegas eram mais felizes, mas a MainFrame era uma das três principais empresas de hardware e software do mundo. A TI estava no mercado há 40 anos e lhe pagava quase 50% a mais do que a Ambitious. A mudança mais difícil foi deixar de trabalhar de uma forma muito mais rápida e estruturada para se ajustar ao ritmo mais metódico e deliberado da MainFrame. A equipe de nove pessoas de Cynthia incluía desenvolvedores na Índia, Austrália, Reino Unido e Estados Unidos. Eles operavam em um modelo "follow-the-sun" (siga o sol) que maximizava a produtividade, garantindo que o trabalho prosseguisse continuamente, com os membros da equipe em um fuso horário passando o trabalho para os colegas em outro fuso horário, dia após dia. A comunicação clara entre as equipes era essencial. Seguindo o processoScrum2, o trabalho de cada equipe de software da MainFrame foi dividido em sprints de duas semanas, com um grande lançamento de código a cada trimestre. O código era testado e integrado aos sistemas críticos em tempo real dos clientes - como equipamentos militares, satélites, veículos autônomos e dispositivos médicos - que precisavam funcionar sem nenhuma falha. Ao final de cada sprint de duas semanas, Cynthia enviava um lote de código para uma equipe de testes e reunia sua própria equipe para refletir sobre como as coisas haviam corrido e o que gostariam de mudar para o próximo sprint.3 Ela também revisava o backlog - uma lista priorizada de projetos que a equipe de testes havia identificado para que sua equipe trabalhasse em seguida, como recursos a serem suportados ou bugs a serem corrigidos. A lista e o roteiro do produto associado eram gerados e aprovados por uma equipe de gerenciamento muito acima do seu nível salarial. A equipe de Cynthia normalmente concluía 10 histórias (ou tarefas) durante cada sprint. A MainFrame queria que todos completassem pelo menos 12. Apesar de suas reclamações, apenas Jim Miller atingia essa cota. Cynthia, Jim, Adnan, Wai e os outros "Scrum masters" se reportavam a Emma Burger, a gerente responsável por reunir os requisitos detalhados dos usuários do lado comercial e transmiti-los às equipes de software. Emma se reportava a Chris Patrick, o diretor de produção, que supervisionava 34 subordinados, incluindo gerentes de projetos técnicos, engenheiros de desenvolvimento de software e gerentes de liberação nos Estados Unidos e em todo o mundo. Cynthia gostava de trabalhar para Emma e queria tornar sua vida mais fácil, não mais difícil. Mas ela concordava com Jim: Os processos da MainFrame eram muito complicados. Por isso, quando Jim a seguiu da cantina até seu cubículo, sentou-se em sua mesa e pediu que ela o ajudasse a mudar as coisas, ela ouviu e, por fim, concordou em se encontrar com ele mais tarde para discutir um plano. Solicitação de Jim "Eu estava esperando que alguém como a senhora se juntasse à MainFrame", disse Jim. "Eles vão ouvir o senhor." "O que o senhor quer que eu faça?" "Trabalhando em pequenos lotes, com essas cadências apertadas, limitados pela gerência no que podemos fazer, nunca seremos tão produtivos quanto eles querem que sejamos", disse ele. "A TI leva muito tempo para finalmente lançar até mesmo a menor atualização. Precisamos de um sistema diferente. O senhor já usou o Flow? Minha filha também é desenvolvedora de software, e é assim que a equipe dela trabalha." Cynthia não só usou as ferramentas e técnicas analíticas do Flow quando estava na Ambitious Computing, como também obteve um diploma no método. Na verdade, ela não queria fazer o curso, mas seu chefe e mentor na época insistiu. "É para onde o setor está indo", disse ela. "Eu usei o Flow na Ambitious", disse Cynthia a Jim. "Então a senhora sabe que é melhor", disse ele. "Não há start-up e start-up contínuos e desnecessários, não há fluxos de trabalho em silos, mais liberdade.4 Não há mais reuniões redundantes diárias às 9 horas da manhã em que minha equipe em Mumbai tem que participar às 18h30 no horário deles. Definimos a data de lançamento. Aproveitamos a análise preditiva, usando IA, em vez de pedir prazos estendidos." Cynthia concordou com Jim nesses pontos, mas ela também sabia que nem todo mundo gostava de trabalhar com o Flow. Por exemplo, as ferramentas baseadas em IA mencionadas por Jim eram ótimas para prever erros e impedimentos ao fluxo suave do trabalho, mas isso só acontecia porque todo o trabalho estava sendo monitorado e gerenciado de forma transparente e em tempo real. As equipes que trabalhavam no Flow - e seus gerentes - podiam ver o processo de desenvolvimento apresentado em telas digitais em seus escritórios - o que talvez fosse ótimo para a colaboração em equipes distribuídas, mas era estressante para desenvolvedores menos confiantes.5 Além disso, a MainFrame era uma tecnologia robusta, uma das primeiras empresas a produzir software comercial. Cynthia não tinha certeza se, depois de apenas seis meses em uma empresa bem-sucedida há 40 anos, poderia pedir aos líderes que mudassem a forma como faziam negócios. "Como posso ajudar o senhor com isso?", perguntou ela. "Quero que a senhora apresente o Flow aos superiores", disse Jim.6 Um projeto piloto Contrariando seu bom senso, Cynthia concordou em participar de uma reunião com Emma e Jim. Ele falou a maior parte do tempo, explicando sua visão do que seria um programa piloto e como achava que Cynthia poderia apresentá-lo a Chris Patrick na revisão anual de melhoria de processos. Emma estava cética. "Cynthia, o que a senhora acha?" "O fluxo funcionou muito bem na Ambitious", disse Cynthia. "Não tenho certeza de que é o que precisamos aqui, mas ficarei feliz em ajudar a pilotá-lo." "A senhora estaria disposta a apresentar os resultados ao conselho?" perguntou Emma. Cynthia deu de ombros. "Cynthia tem um diploma da Ivy League", disse Jim. "Ela trabalhou para um futuro unicórnio. Ela tem um diploma em Fluxo. Se alguém pode demonstrar e comunicar ao senhor a necessidade dessa mudança, é a Cynthia." Cynthia ficou surpresa com o quanto Jim sabia sobre ela, mas também satisfeita com sua estima. Desde que entrou para a MainFrame, ela manteve a cabeça baixa e se esforçou ao máximo para cumprir os prazos irrealistas estabelecidos por seus supervisores. Talvez fosse a hora de ela se manifestar e assumir um risco. "Tudo bem, desde que todos os senhores cumpram suas cotas, não me importa como farão isso", disse Emma. "Mas se houver qualquer sinal de problemas, vou encerrar o trabalho." Nos meses seguintes, Cynthia analisou artigos de pesquisas acadêmicas e relatórios de consultoria para comparar as técnicas e os desafios do Flow com os do Scrum e outros métodos de desenvolvimento de software, como o Extreme Programming (XP) e o desenvolvimento orientado por recursos. Ela releu Stop Starting, Start Finishing e outros livros semelhantes. Em seguida, disse a Emma que estava pronta para trabalhar com um fornecedor para lançar um projeto piloto em seu software Flow alimentado por TI, que, ao contrário do sistema atual, tinha a funcionalidade de quadro Kanban digital para melhorar a comunicação da equipe e poderia gerar automaticamente métricas, como tempo de ciclo e tempo de espera, que as equipes no Scrum precisavam registrar e rastrear por conta própria. Nas reuniões de planejamento de sprint, agora agendadas para meio dia em vez de uma hora, a equipe de Cynthia discutia o backlog do produto, dividia os projetos em tarefas e planejava sprints futuros para atender aos requisitos priorizados. Em alguns casos, Cynthia teve de criar uma combinação de técnicas Scrum e Flow, especialmente no início dos projetos.7 A abordagem de entrega frequente de sprints de duas semanas era um requisito do MainFrame. Essa regra não poderia ser alterada até que todos estivessem trabalhando no Flow. O piloto era um assunto muito discutido na cantina. No dia em que Cynthia anunciou que sua equipe faria experiências com a coordenação do Flow, Wai falou com ela diretamente pela primeira vez. "Obrigado por fazer isso!", disse ele. "Mal posso esperar até que todos nós tenhamos o TI!" Um ano depois Após um ano de execução do piloto, Cynthia estava orgulhosa dos resultados. Sua equipe havia mantido a produção de 10 andares por impressão, mas agora estava implementando continuamente o código sem erros críticos, e o moral da equipe havia melhorado. Jim torceu por ela o tempo todo. "A senhora realmente conseguiu", disse ele a ela. "Temos a IA escolhendo e priorizando seus projetos em vez de um idiota corporativo que nunca escreveu uma linha de código. A TI está detectando defeitos e gargalos antes do seu pessoal. Os chefes podem ver exatamente onde a equipe está em seus projetos e exatamente o pouco tempo que estão dando aos senhores!"8 Notas de Aula do Estudo de Caso O termo "scrum" (em um contexto de desenvolvimento de produtos) foi introduzido na Harvard Business Review ("The New New Product Development Game", HBR, janeiro de 1986). O Scrum foi originalmente projetado para desenvolvedores de software que trabalham em equipes multifuncionais para fornecer produtos e serviços em ciclos curtos. Os objetivos eram feedback rápido, inovação mais rápida, melhoria contínua e outros benefícios. Tanto o Flow quanto o Scrum derivam da metodologia introduzida no Manifesto Ágil, publicado em fevereiro de 2001 por 17 desenvolvedores de software que o escreveram durante as férias de esqui. Os processos Scrum, que na maioria das vezes duram de duas a quatro semanas, têm datas claras de início e término, enquanto os projetos Flow são simplesmente trabalhados até serem concluídos. Quais são os prós e os contras de cada abordagem? Quais aspectos do Scrum ou do Flow o senhor introduziria no seu local de trabalho? Quais o senhor evitaria? Por quê? A Cynthia deve confiar nas intenções do Jim? Por que sim ou por que não? Os cinco valores do Scrum são compromisso, foco, abertura, respeito e coragem. Quais desses valores a Cynthia demonstrou? Como a introdução do Flow mudará a maneira como os funcionários e gerentes interagem entre si? Mas Emma logo estourou a bolha deles. "Eu mostrei uma prévia do que estamos fazendo para o Chris", disse ela em uma chamada de vídeo com Cynthia e Jim de Londres, para onde tinha viajado para uma reunião de planejamento sênior. "Tivemos uma grande discussão. Ele nunca usou Flow. A primeira coisa que ele perguntou foi quantas histórias a equipe da Cynthia tinha em média a cada sprint. Quando eu lhe disse que a produtividade permanecia basicamente a mesma, ele arregalou os olhos." "Então é isso?", perguntou a senhora. perguntou Cynthia. "Ainda vamos nos apresentar ao conselho de melhoria de processos? Podemos continuar com o piloto?" "O Chris disse que a decisão era nossa, mas ele está confiante de que seremos criticados pelo comitê - especialmente pelos membros mais antigos, que não têm experiência em software. Sinceramente, Cynthia, a senhora tem a experiência e dirigiu o piloto, portanto, a decisão é sua. A senhora acredita que isso aumentará nossa produtividade no longo prazo? E a senhora tem convicção suficiente para se levantar na frente desses caras e dizer isso?" Naquela noite, quando estava saindo do escritório, Cynthia entrou na cantina para pegar o recipiente fechado da Tupperware. Ela não tinha tido fome para almoçar naquela tarde. Seu estômago estava embrulhado em nós. Wai, Adnan e Jim estavam saindo do escritório para o happy hour e perguntaram se ela estava pronta para apresentar o Flow. Ela disse que estava com um mau pressentimento. "Não se preocupe, Ramos", disse Jim. "A senhora vai se sair muito bem." Os especialistas respondem: A Cynthia deve apresentar o Flow para a diretoria de melhoria de processos? Sonali Raut é cientista de dados sênior da Munich RE Automation Solutions. Cynthia deve esperar para apresentar o Flow ao conselho de aprimoramento de processos. Primeiro, ela deve elaborar meticulosamente uma proposta delineando a lógica por trás dessa iniciativa, incluindo dados bem pesquisados e argumentos baseados em evidências. Isso melhorará as perspectivas de sucesso na implementação da metodologia. Seu maior erro foi não ter incluído Chris Patrick no projeto Flow desde o início. Como uma empresa estabelecida com um histórico de sucesso, a MainFrame não introduzirá um novo sistema de gerenciamento de projetos sem o apoio dele. Mas não se engane: Acrescentar o Flow aos processos da empresa melhoraria absolutamente a estrutura do projeto, a adaptabilidade, a eficiência, a sobrecarga administrativa e a produtividade. É responsabilidade da Cynthia reforçar sua proposta com dados, resultados de pesquisas e estudos de caso pertinentes. Agora que o Chris finalmente sabe o que a Cynthia e a Emma estão fazendo, elas devem orientá-lo sobre tudo o que a equipe realizou. Sabendo que ele se concentrou nas histórias por impressão como uma métrica importante e que sua equipe não conseguiu melhorar isso durante o piloto, Cynthia deve destacar a transparência proporcionada pelo quadro Kanban digital, a melhoria do trabalho em equipe e o aumento do moral. Ela deve enfatizar que uma métrica de história por impressão inalterada é, na verdade, um indicador positivo: Sua equipe conseguiu manter a produtividade durante o piloto, mesmo com a transição para a integração e a implementação contínuas de código, melhorando a supervisão e deixando os desenvolvedores felizes. À medida que a equipe se tornar mais hábil com o novo sistema, a velocidade e a eficiência só aumentarão. Cynthia deve se esforçar para que Chris entenda que outras métricas - como recursos aprimorados do produto e custos de desenvolvimento reduzidos - também são importantes. Talvez ela possa oferecer um exemplo de uma melhoria feita durante o piloto que tenha encantado os clientes ou um erro detectado pelos desenvolvedores que teria passado despercebido sem o uso do Flow. A senhora também deve mostrar ao Chris estudos de caso de outras empresas que fizeram a transição para o Flow e explicar como o seu empregador anterior o utiliza. Por fim, ela terá de detalhar o caso de negócios para a mudança. Ela sabe quanto custará a transição? Ela tem um orçamento em mente para o projeto? Quanto tempo levará? Quanto dinheiro a empresa ganhará ou economizará com o aumento da produtividade, da colaboração e da transparência? Ou seja, qual é o ROI? Somente depois que Chris estiver a bordo, e ela, ele e Emma tiverem resolvido essas questões, ela deverá fazer sua apresentação ao conselho de melhoria de processos. Estou confiante de que Cynthia pode persuadir a MainFrame a mudar do Scrum para o Flow, mas ela ainda não está pronta para apresentar seu caso. Alex Estevam é gerente de programa técnico da Mastercard. Cynthia está pronta para apresentar. Um dos cinco valores-chave do Scrum é a coragem. O Guia do Scrum, que foi escrito e alterado pelos criadores da estrutura do Scrum, diz que as pessoas que usam os métodos do Scrum devem se sentir confortáveis o suficiente com os colegas para defender aquilo em que acreditam. É isso que Cynthia deve fazer aqui. Ela tem bons motivos para querer introduzir os processos de fluxo na MainFrame. Os métodos Scrum exigem uma abordagem de cima para baixo. A gerência sênior escolhe em que os desenvolvedores devem trabalhar e diz a eles quanto tempo devem trabalhar nisso, o que não agrada aos desenvolvedores. O Flow, por outro lado, dá aos desenvolvedores a capacidade de mostrar à gerência o que precisa ser corrigido e quando. Além disso, muitos de seus colegas querem o Flow - e a Cynthia também parece querer. Portanto, ela deve apresentá-lo. É claro que, por mais eficaz que seja a apresentação do fluxo à diretoria, alguns gerentes e até mesmo alguns desenvolvedores resistirão a ele. Embora eu conheça alguns desenvolvedores que detestam absolutamente as reuniões diárias de stand-up do Scrum - que eles consideram uma perda de tempo e acreditam que os gerentes realizam apenas porque são obrigados - outros acham que elas são essenciais, permitindo que todos se preparem coletivamente para o dia seguinte. No entanto, Cynthia sabe que a transição para o Flow é a medida certa a longo prazo para a MainFrame. É por isso que é fundamental que ela se apresente ao conselho. Seu sucesso provavelmente dependerá de quão bem ela instruir os membros do conselho. Ela já provou que sua equipe pode manter a produtividade, lançando continuamente novos códigos sem grandes erros. Isso é uma vitória. Ela também deve encontrar uma justificativa financeira para a mudança. Ela deve deixar claro que pode expandir o piloto e começar a coletar dados para demonstrar que os processos melhoraram e que essas melhorias acabarão por economizar muito dinheiro para a MainFrame. Se ninguém tiver a coragem de apresentar o fluxo, a gerência talvez nunca aprenda o suficiente sobre ele para entender como ele funciona bem. A colega de Cynthia está certa. Ela é a pessoa mais indicada para persuadir céticos como Chris. Outra coisa que gostaria de observar: o Guia do Scrum diz que a coragem deve ser bilateral. Isso significa que, se Cynthia for corajosa o suficiente para apresentar o Flow ao conselho, Chris deve ter a coragem de ouvir seus argumentos e, se ela os apresentar bem, admitir que estava errado sobre o Flow. Os estudos de caso ficcionais da HBR apresentam problemas enfrentados por líderes em empresas reais e oferecem soluções de especialistas. Este é baseado em um caso ensinado por Nien-hê Hsieh, Kim B. Clark Professor de Administração de Empresas da Harvard Business School.

Estudo de caso: Devo propor um novo sistema de gerenciamento de projetos?

Resumo.

Partner Center