Primeiros passos em RPM (Rethinking Project Management): Zen e Arte da Gestão

Esse é o começo da minha jornada para entender a gestão ágil, que faz parte de uma nova vertente que busca modernizar o gerenciamento de projetos, o chamado Rethinking Project Management (RPM).

Nos últimos dois anos venho investindo algum tempo para o estudo da gestão de projetos e gestão de processos, quando inclusive me certifiquei em Project Management Professional (PMP) pelo PMI e em Certified Business Process Professional (CBPP) pela ABPMP. Obviamente a certificação agrega valor ao currículo, mas o importante é a busca pelo conhecimento. Por isso fui atrás de dois gurus dessas áreas. No tema de gestão de projetos de TI acabo de concluir o curso Zen e a Arte da Gestão, objeto desse post.

Nesse post pretendo pretendo resumir alguns conceitos que obtive no Zen a Arte da Gestão ministrado por Alisson Vale no Software Zen.

Sobre o curso

Participei da turma Brooks cuja frase tem tudo a ver com vários projetos que já participei:

“Como um projeto atrasa 1 ano? Um dia de cada vez…” Fred Brooks

A organização do curso é muito boa. Toda a ementa é construída sobre o conceito da jornada do herói (mindset, a estratégia, as armas, a batalha e a transformação) baseado no livro O Herói de Mil Faces de Joseph Campbell (vale a pena dar uma olhada na série de vídeos da NovaAcrópole com a interpretação desse material), daí já se pode identificar a preocupação do Alisson na construção do curso e com a profundidade dos temas tratados. Vale a pena acessar a bibliografia adotada no curso e a videoteca contendo vídeos e palestras dos chamados gurus.

O bom velhinho, Russel Ackoff

Logo de cara fui apresentado ao trabalho de Russel Ackoff, um grande consultor e pesquisador nos campos de pesquisa operacional e systems thinking. As frases dele são muito impactantes e sempre atuais. Vale a pena assistir ao vídeo da entrevista que fez ao Studio 1 em que ele diz algumas frases que para mim estão se tornando mantras:

“The more efficient you are at doing the wrong thing, the wronger you become. It is much better to do the right thing wronger than the wrong thing righter. If you do the right thing wrong and correct it, you get better.” Russell L. Ackoff

Outro campo que também fui iniciado nesse treinamento é o do Systems Thinking e aí vem mais uma frase do nosso bom velhinho:

“To manage a system effectively, you might focus on the interactions of the parts rather than their behavior taken separately.” (Russell L. Ackoff)

O conteúdo do curso é muito grande, mas a seguir vou tentar resumir os principais conceitos práticos com a visão de quem precisa modificar o mindset de uma empresa para a adoção de práticas mais ágeis no processo de desenvolvimento de software.

Como vender o projeto de mudança?

A sua primeira missão será apresentar ao board da sua empresa o novo mindset focado na eficácia e não na eficiência. Mas vamos devagar com isso, para não assustá-los. A melhor forma convencê-los é fazer com que eles pensem que são os responsáveis por essa nova estratégia.

Minha sugestão é investir um dia conversando com algumas pessoas chaves da sua nova equipe. É importante que você faça um primeiro contato com eles para entender melhor a maturidade da equipe e a situação em que se encontra o projeto, pois, pelo que entendi, você ainda não teve contato com a equipe e tudo que soube partiu do conhecimento do Diretor, que pode estar contaminado com algum viés, já que normalmente a realidade acaba sendo filtrada antes de chegar ao board da empresa. Depois disso, é possível aumentar seu conhecimento da situação atual do projeto de modo que você tenha mais munições para sua próxima etapa que é fazer uma reunião com o diretor da empresa. Essa reunião terá então como objetivo apresentar ao diretor um novo mindset a ser implementado na empresa. A seguir vou deixar 3 tópicos que você pode abordar nessa reunião para deixar claro seu diretor que um novo mindset poderá trazer ganhos significativos para o negócio (não se esqueça que o diretor está com o foco nos KPIs da empresa).

É sempre bom começar uma reunião com uma metáfora. Sugiro que você faça seu diretor sentir o mesmo que eu quando escutei a metáfora do chefe de cozinha e do cozinheiro. Deixa eu explicar melhor isso. As naturezas do trabalho incluenciam de forma significativa qual forma de organização e gestão devemos adotar. Compare, por exemplo, um cozinheiro e um chefe de cozinha. Quando um cozinheiro começa seu dia de trabalho ele deve acessar uma receita, buscar e preparar os ingredientes, seguir essa receita quanto a temperatura e tempo de cozimento além de temperar e combinar cada ingrediente para compor um prato. Esse cozinheiro deve atender a uma demanda dos garçons em função da quantidade de clientes no salão, deve replicar cada receita seguindo o mais próximo possível de suas instrições e a qualidade do seu trabalho é medida pela velocidade do preparo, pela baixa variabililidade e pela baixa perda de meterial e consumo de energia. Um boa forma de gerenciar o processo de trabalho do cozinheiro é através de uma descrição detalhada do processo de trabalho e utilização de POp’s (planos operacionais), ou seja, utilizando as mesmas ferramentas de gestão da indústria de manufatura. Quando um chefe de cozinha trabalha, seu enfoque é outro. Ele é quem combina o conhecimento da culinária para criar novos pratos e construir as novas receitas. O processo criativo do chefe deve implicar em uma variabilidade inerente. A cada receita o chefe aumenta sua capacidade. Seu processo é empírico e retroalimentado. Pergunte então para seu chefe, se ele acha que a gestão do trabalho de um chefe de cozinha deve ser igual a de um cozinheiro. Pois bem, essa é a hora de reforçar que uma empresa que desenvolve soluções, mais especificamente soluções baseadas em programas de computador, é formada por chefes de cozinha.

Chegou a hora de você evocar os bons e velhinhos Peter Drucker que dizia “há uma diferença entre fazer as coisas do jeito certo e fazer a coisa certa” e o Russel Ackoff que dizia “quando mais certo você faz a coisa errada, mais errado você se torna” e “é melhor fazer a coisa certa do jeito errado do que fazer a coisa errada do jeito certo”. Com essas três frases você pode introduzir os conceitos de eficácia e eficiência e como as visões tradicional e nova abordam esses conceitos. Chegou a hora de fazer um link com os problemas atuais do projeto. Diga que o projeto coloca a eficácia como sendo um pressuposto e que a eficiência é atualmente a meta que as pessoas estão sendo forçadas a buscar. Mostre que em um projeto de software torna-se muito difícil planejar de forma exautiva como as abordagens tradicionais fazem, já que a causa e efeito é complexa e muitas vezes imprevisível. Nesse ponto, aborde o conceito de mecanismo e organismo. Descreva o projeto atual como um mecanismo com ordem imposta e a busca pelo controle. Diga que devemos considerar o projeto como um organismo dotado de auto-organização dentro de um sistema complexo, ou seja, é necessário utilizar um pensamento sistêmico para garantir eficácia e eficiência em um projeto de desenvolvimento de software.

Nessa hora você quase convenceu seu diretor de que é preciso mudar o mindset da empresa, mas lembre-se que ele é um executivo e precisa ter conhecimento da estratégia que você vai adotar. Não prenda-se a ferramentas nessa hora, não é o momento de falar de Lean, Kanban, relatórios A3. Para ganharmos nosso jogo, diga que vamos usar cinco estratégias:
1. Começar pelo trabalho em progresso: vamos focar no presente usando uma ferramenta de feedback visual, administrando a capacidade e adotando coordenação tática.
2. Minimizar o tamanho dos entregáveis: com isso vamos diminuir a variabilidade do lead time e aumentar a liquidez do sistema.
3. Colaborar com o cliente para priorizar, alinhar expectativa e integrar.
4. Buscar eficácia (fazer a coisa certa e somente a coisa certa): temos que fazer entrega de valor para o cliente de forma frequente.
5. Tangibilizar os resultados por meio de métricas, celebração e disseminação.

Como começar?

Vamos começar a reestruturar o trabalho dentro do seu projeto. Vencido o desafio de apresentar à diretoria e agora tendo o apoio da camada de cima, você vai trabalhar esses conceitos junto com sua equipe do projeto. Seu trabalho nas próximas semanas é mostrar como esse novo mindset será benéfico para a equipe. Eles vão se tornar um time que colabora entre si e possui motivação para gerar os resultados já que todos perceberão que seu trabalho estará trazendo retorno frequente. É importante destacar que todo o processo de mudança pode gerar uma certa rejeição por parte da equipe, seu papel é gerir a mudança passando para a equipe o máximo de informação sobre o processo de trabalho que você propõe. Quanto mais incerteza, maior a barreira à mudança. Seja clara sobre suas ideias e mostre que o que você propõe trará benefícios a todos. Não tente de início criar um processo perfeito. Sei que é chato ficar fazendo reunião longa com a equipe, mas é preciso fazer uma reunião inicial para explicar os conceitos de controlar o WIP, medir o Lead Time, trabalhar com entregáveis pequenos e explicar o conceito de eficiência e eficácia. Como o trabalho atual está focado em cada desenvolvedor trabalhar em um módulo distinto, seria interessante passar um dever de casa para a equipe. Cada um deverá pegar seu módulo extrair os entregáveis de business de seu respectivo módulo, os entregáveis de produto e as tarefas que já concluiu, que está fazendo ou que estão em seu backlog. Não esqueça de pedir para todo mundo trazer o seu avatar impresso. Para o desenvolvedor sênior que está responsável pelo Framework, peça que ele organize um workshop para que ele na próxima semana para explicar para a equipe o Framework do sistema. Explique para ele que ele será o lider da processo de melhoria contínua e que deverá assumir novas responsabilidades dentro do projeto. No dia seguinte, tendo havido tempo para todos identificarem seus entregáveis, é hora de construir o quadro visual atual da equipe que pelo que entendo é focado em filas individuais sem handoffs – um desenho TEAM VIEW. Comece pelo trabalho em progresso atual de cada membro da equipe. Cole um grande papel na parede da sala e esqueva o nome do seu time no topo. Tente já forçar nesse mapa o conceito de em progresso e interrompido. Deixe então que o time cole seus post-its. Agora é a hora de tentar construir o TO-BE do processo. Faça um novo mapa e crie uma única raia nessa primeira iteração e coloque à esquerda a sua área de input. Veja com sua equipe quais são os handoffs atuais e reproduza em diferentes colunas. Por fim coloque à direita uma coluna de output.  Eu sugiro começar pelo mais simples: backlog, desenvolvimento, teste/esperando, teste/testando, avaliando e em produção. Como sua equipe não faz manutenção, acredito que a raia única irá atender perfeitamente. Depois disso peça para que todos colem suas tarefas dentro do quadro. Caso se sinta a vontade, explore o expand collapse com estregáveis de negócio e de produto. Para essa reunião não ficar muito longo talvez seja a hora de parar por aí e continuar individualmente. Acho que esse é um bom início. Você está começando a usar a técnica gestão visual para maperar e acompanhar o processo. No dia seguinte fará uma reunião com a equipe em frente ao quadro para dar inícion aos Katas Diários e em seguida começar a implantar de fato do controledo WIP e a medição do Lead Time.

Como melhorar a sua coordenação tática?

O desafio de garantir a qualidade das reuniões é bem grande, mas se você adotar algumas medidas, tenho certeza que dará certo. Antes de mais nada você deve evitar controlar o seu tempo e da sua equipe e passar a controlar a energia. Não tente fazer com que todos trabalhem no máximo o tempo todo, isso não funciona. O certo é garantir que as pessoas trabalhem por períodos curtos em estado de FLOW até atingir um objetivo curto mas dentro de um propósito maior. Tente primeiro adotar isso para você e vai notar que se sentirá ainda mais motivada. Agora voltando para o tema principal da corodenação tática. Eu acredito que a principal dica para você é construir uma disciplina com uma frequência diária. No Software Zen chamamos isso de Kata diário e é basicamente consolidado por meio de uma reunião diária em frente ao mapa (Kanban). As pessoas precisam conversar em frente a esse mapa, se organizar e se alinhar de modo que isso se torne um hábito. Não podem deixar de fazer isso um dia, mesmo que haja quórum baixo. Faça todos os dias no mesmo horario (sugere-se a hora do lanche da tarde) com uma duracao de 15 minutos. A reunião precisa ser de pé para evitar que se prolongue muito. Foque a reunião na ideia de falar sobre o que mudou do dia anterior com foco no trabalho e não nas pessoas. Sugiro que você conduza a reunião. No começo, lembre do contexto da equipe e da meta com uma introdução rápida de 1 minuto. Em seguida, procure no quadro tudo o que está bloqueado para pegar a posição e determinar o próximo passo ou o próximo passo para desbloquear. O que você souber que mudou de um dia por outro você pode apontar. As coisas que você não se lembra, pergunte para as pessoas. Quem não mudou nada, pergunte rapidamente se tem algum problema e se tem alguma previsão. Tente sempre manter as pessoas com a linha de chegada visível. Por fim, faça as considerações finais e organize o follow-up de coisas que têm que se seguir após a reunião.

A luta contra o gargalo

Não existe uma fórmula para definir o WIP ideal. É bem provável que você terá que fazer ajustes ao longo do tempo até que você perceba que um equilíbrio.  Agora quanto às regras, explique ao usuário que a prioridade é olhar o quadro kanban da direita para esquerda e puxar as histórias apenas quando o respectivo kanban ficar abaixo do limite.

A hora de apresentar para o cliente

O ideal seria fazer entregas menores e, se possível, semanais para evitar surpresas e o risco de o cliente dizer qu “não era bem isso que ele queria”. Sendo assim, você terá que se preparar para mostrar para o cliente o que já foi feito e se preparar para a possibilidade dele dizer que existe algum descolamento com a necessidade dele. O principal ponto para conquistar o cliente é gerar uma versão funcional. Nada de slides mostrando as funcionalidades ou qualquer demostração de como foi o andamento do projeto. O que o cliente quer ver é o sistema funcionando. Sendo assim, construa um ambiente funcional e, preferenciamente, acessível ao cliente para que ele mesmo possa operar o sistema. Alimente a base de dados com dados fictícios mas suficientes para descrever a utilização de todas as features já implementadas. Para aquelas features que ainda não foram concluídas tenha em mente as limitações que a falta dela poderia trazer ao sistema e prepare-se para saber quando elas estarão disponíveis. Procure mensurar o business value que o sistema já entrega, mesmo que nem todas as features estejam prontas. Crie um compromisso de fazer as próximas entregas e subir os deploys para esse ambiente de homologação para que o cliente possa ter acesso a essas features o mais rápido possível. Se você não se sentir confortável para descrever alguma funcionalidade, leve um membro do seu time para lhe dar suporte. Receba o feedback do cliente e aproveite suas sugestões e críticas para melhorar cada vez mais em seus projetos.

Mapas mentais

Seguem alguns mapas mentais construídos a partir do conteúdo do curso:

Mastermind

No dia 25 de novembro de 2017 participei pela primeira vez de um evento de mastermind. Tratava-se do último compromisso do curso. O termo mastermind foi cunhado pelo escritor americano Napoleon Hill e é definido como uma aliança de mentes em perfeita hamonia e com atitude positiva na busca de um objetivo comum.

Normalmente os eventos de mastermind organizados aqui no Brasil estão focados no Board das empresas e custam uma fortuna. A ideia é simples, mas requer um comprometimento de todos os indivíduos a cumprirem uma agenda comum.

Obviamente a ideia do Alisson foi de criar essa semente do Mastermind no participantes do treinamento pela reunião de grupos menores de 4 a cinco pessoas para desempenharem uma tarefa comum. A dinâmica utilizada foi a construção do chamado Canvas da Transformação cujo objetivo era definir o que queremos, as condições, os obstáculos e as cpmétências para sair da situação atual (ponto A) para uma nova situação (ponto B) após um período de 1 a 2 anos concretizada em um evento futuro.

“If you don’t know what you want,” the doorman said, “you end up with a lot you don’t.” Chuck Palahniuk, Fight Club

A ideia básica era definir o ponto B e em seguida imaginar, de forma retroativa, quais as etapas que deveriam ser vencidas para atingir esse objetivo. A mensagem principal era de que devemos conhecer o ponto B antes de planejar.

“One day Alice came to a fork in the road and saw a Cheshire cat in a tree. ‘Which road do I take?’ she asked. ‘Where do you want to go?’ was his response. ‘I don’t know,’ Alice answered. ‘Then,’ said the cat, ‘it doesn’t matter.” Lewis Carroll, Alice in Wonderland

Conclusão

O principal aprendizado que obtive é que gerenciar projetos de software é muito diferente de gerenciar projetos de construção. O planejamento detalhado torna-se muito mais custoso e ineficiente que um ciclo incremental e iterativo.

Em relação a visão de gerenciamento de processos, o desenvolvimento de softwares é baseado em conhecimento e dessa forma é muito mais complexo do que processos de manufatura. Deve-se priorizar os processos Ad hoc e fugir da fixação por um sequenciamento amarrado.

Um conceito que já trazia mas que ficou reforçado nesse treinamento é que não existe um framework padrão de gestão de projetos. Se cada projeto é um empreendimento único, como seria possível haver uma única forma de executar um projeto? Essa mesma linha de raciocínio é seguida pelo treinamento. Diversas vezes somos forçados a implantar uma metodologia da moda simplesmente para atender a uma política ou mesmo porque alguém precisa destacar uma “qualidade” de gestão. A onda agilista que vem se espalhando pelo mundo da gestão é benéfica quando a ferramenta adotada gera um resultado positivo, e não para estampam uma marca ou um framework.

Pude observar o emprego de metodologias Lean para o gerenciamento de projetos e processos baseados em conhecimento, mas que devemos ter bastante cuidado ao transferir conceitos do Sistema Toyota de Produção para além dos processos de manufatura.

Deixo, então, a minha recomendação para esse excelente treinamento.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s