Saltar para: Posts [1], Pesquisa [2]

Profissional Moderno

Profissional Moderno

01
Set20

Ganhos Marginais e porque são tão importantes

Luís Rito

No meu último artigo, mergulhámos um pouco numa série de características que fazem a equipa de F1 da Mercedes-Benz tão especial. Um dos conceitos abordados no artigo, foi o conceito de ganhos marginais, introduzido de uma forma superficial no texto. Para que possas ter algum contexto nesta leitura, dá uma olhadela no artigo Aprender com a equipa Mercedes de Fórmula 1. Hoje abordaremos de uma forma mais aprofundada o conceito de ganhos marginais, recorrendo a alguns exemplos para ilustrar melhor as suas vantagens. O que são então ganhos marginais? Uma excelente definição, é a capacidade que uma entidade tem de subdividir um grande objetivo em pedaços bem pequenos, e aplicar melhorias a cada um deles, por mais pequenas que sejam. Ao juntar todas essas pequenas melhorias, de todos os pedaços previamente identificados, o incremento será enorme. É muito fácil descartarmos pequenas melhorias por acharmos que não vão ter qualquer tipo de impacto no resultado final. Tendemos a achar que para atingir uma mudança radical são necessárias ações radicais, o que não é a realidade. Seja na perca de peso, acumulação de riqueza, criação de um negócio, etc, o segredo está sempre na consistência com que aplicamos pequenas melhorias no nosso dia-a-dia, na capacidade de partir um grande objetivo em objetivos mais pequenos que podemos seguir e avaliar. De um ponto de vista matemático, se conseguires incrementar algo, nem que seja em 1%, no final de um ano vais ter um ganho muito considerável. Senão vejam, 1,01^365 = 37,78, ou seja, se melhorares 1% todos os dias, vais acabar o ano 37 vezes melhor do que quando iniciaste. Repetindo estes pequenos ganhos marginais ao longo de vários anos, facilmente percebes que é possível chegar a um nível de excelência. Decerto entendes que nem sempre será fácil obter uma melhoria, mas o segredo está em realizar ciclos constantes, dando muita relevância ao feedback. Em cada um destes ciclos é testada uma hipótese de melhoria. Através do fornecimento de feedback, toma-se então a decisão de considerar a hipótese como um sucesso, ou como uma tentativa falhada. Este método de constatação de hipóteses nada mais é que a aplicação de um verdadeiro método científico (observação, realização de perguntas, criação de hipóteses, experimentação de hipóteses, análise e conclusão). Relembro que ainda que uma hipótese resulte num resultado menos positivo, ainda assim o verdadeiro ganho é a capacidade de aprendizagem, já que no próximo ciclo pode-se optar por uma hipótese ligeiramente diferente que poderá vir a dar ganhos fenomenais. Talvez o caso mais conhecido desta corrente de pensamento é o de Thomas Edison. Até obter sucesso na criação da primeira lâmpada, passou por cerca de 700 tentativas falhadas. Chegou a ser questionado pelos seus assistentes sobre se valeria a pena continuar a insistir, já que não tinham avançado um único passo. A resposta foi fenomenal:

 

"Não avançamos um único passo? Avançamos 700 passos na direção do sucesso. Sabemos de 700 coisas que não funcionaram. Estamos muito além de 700 ilusões que mantínhamos no passado e que hoje não nos iludem mais. Ainda chamas a isto perda de tempo?"

 

A constatação das hipóteses deve ser sempre acompanhada por medições muito precisas e fidedignas, já que só assim é possível afirmar que uma hipótese foi ou não um sucesso. Este ónus não pode ficar apenas na opinião de um conjunto de pessoas, mas sim de métricas bem definidas. A opinião das pessoas está normalmente sujeita a um conjunto de variáveis que nada têm que ver com a análise da hipótese. Podem por exemplo entrar em jogo fatores emocionais, ou por exemplo casos em que alguém muda a sua opinião para que se torne similar à opinião dos demais. É por isso que este tipo de decisões deve recair sobretudo na análise de variáveis mais quantitativas. Por exemplo, quando o objetivo de uma pessoa é perder gordura, uma das medidas que utilizamos para medir progresso é um número representado em Kg, o peso. Existem outro tipo de medidas, como a % de massa magra, % de massa gorda, perímetro abdominal, etc. Este tipo de medidas é sempre mais precisa que olhar para um espelho e tentar adivinhar se estamos ou não a fazer progressos.

Recorrendo uma vez mais ao exemplo da Mercedes-Benz e da F1, é comum a equipa utilizar ciclos iterativos de melhoria apenas para otimizar a forma como recolhem e medem os KPI´s que interessam. Isto acontece, pois, estamos a lidar com problemas complexos, portanto a primeira tentativa para os otimizar deverá ser bem longe do ideal. Com recurso a sensores, podem testar as hipóteses e decidir se esta é ou não um sucesso. Acontece que com a primeira iteração são feitas descobertas que não estavam a ser tidas em conta, daí a necessidade de muitas vezes realizarem um novo ciclo apenas para melhorar a forma como recolhem KPI´s e estatísticas. Apenas quando sabem que os KPI´s estão corretos, avançam para o processo propriamente dito de melhoria. Reparem na diferença e no contraste com outras realidades, onde hipóteses são escolhidas por "feeling" e não por evidências. Para que possam ter uma ideia, a Mercedes-Benz chega a colocar cerca de 8 sensores em cada uma das pistolas que removem as porcas que prendem as rodas, para que assim possam otimizar as paragens nas boxes. Apenas ao olhar para os dados (e não a falar com o mecânico que as coloca), é possível obter informação sobre por exemplo, um desvio de 15 graus da posição correta em que se deve introduzir a pistola, quando foi iniciada a sua rotação, a velocidade com que o mecânico se afastou, quanto tempo demorou a colocar um pneu, quando tempo o demorou a aparafusar, etc. Toda esta fonte de dados, alimenta KPI´s que são utilizados para melhorar o tal 1% em cada ciclo de otimização. Esta metodologia aplicada a centenas de pequenas partes de um todo, resulta num efeito composto. Tal como o dinheiro no banco sob o efeito de juros composto tende a crescer de forma exponencial ao longo do tempo (juros dos juros originam ganhos cada vez maiores), as pequenas melhorias de 1% ao longo do tempo vão transformar um indivíduo, uma equipa, uma empresa numa das melhores na sua área de atuação.

 

Marginal Gains

 

O segredo da Fórmula 1 nos dias de hoje não tem que ver com desenvolver algo que seja revolucionário, o segredo é aplicar melhorias em todos os milhares de pequenos items, e otimizá-los a um nível de excelência. As pessoas tendem a pensar que um motor é algo que evolui com base em decisões estratégicas, mas na realidade o que é um motor senão um conjunto de pequenos componentes? O objetivo é começar com um desenho simples e funcional, e através de um processo iterativo chegar a uma solução o mais ideal possível, já que será praticamente impossível atingir a perfeição. O sucesso depende de ter um ciclo iterativo de melhorias enraizado na organização. Realizar melhorias não é algo fácil, é necessária criatividade e muito esforço para obter ganhos de algo que já é muito bom. Olhar para o que os dados nos estão a dizer, para os KPI´s e encontrar soluções para os melhorar exige uma equipa a trabalhar no seu melhor. Criatividade que não é guiada por um mecanismo de feedback não passa de esforço que se dissipa e se perde. Devemos ambicionar falhar mais, porque apenas quando falhamos nos é dada a hipótese de fazer melhor, evoluir. Ganhos marginais são quase invisíveis no curto prazo, melhorar 1% não é lá grande coisa. Mas é no médio e no longo-prazo que essas pequenas melhorias e escolhas começam a separar os que têm sucesso dos que não têm. Bons hábitos devem ser incentivados. Curiosamente, os bons hábitos são difíceis no imediato e trazem grandes benefícios no futuro, enquanto maus hábitos são fáceis no imediato, mas trazem grandes perdas no futuro. É sempre mais difícil seguir uma alimentação cuidada e fazer exercício hoje, já que apenas vamos ver benefícios alguns dias ou meses depois. Por contraste, sentar-me agora a ver televisão e a comer comida prejudicial dá-me uma recompensa imediata, mas castiga-me mais tarde sob a forma de gordura e problemas de saúde.

É fundamental fazer uso desta poderosa forma de estar na vida, e utilizá-la quer dum ponto de vista pessoal como de um ponto de vista profissional. As empresas devem também manter um olho na forma como trabalham, cultivar um ambiente onde não se espera ter tudo perfeito desde o momento zero é fundamental. Fazer uso de ciclos de melhoria deve estar no ADN das suas pessoas. Nem todas elas se vão identificar com esta forma de trabalhar, afinal procurar constantemente a melhoria exige perfis que não se dão bem com a rotina e com o conformismo. É fundamental incorporar mais pessoas com este perfil, para que consigam em conjunto construir uma cultura que possa "contagiar" todos os outros elementos. Parte do segredo das grandes empresas começa na sua cultura, e é por isso que uma empresa deve batalhar. Mudar e evoluir é algo positivo, procurar pequenas melhorias ainda mais, e são essas pequenas melhorias que te vão levar para o próximo nível. O relógio nunca vai parar, o que vais escolher? Ser hoje 1% melhor ou 1% pior?

 

06
Ago20

Aprender com a equipa Mercedes de Fórmula 1

Luís Rito

Sendo um fã incondicional de F1 desde pequeno, não deixo de ficar espantado como a equipa Mercedes tem vindo a dominar o desporto nos últimos anos. Este tipo de domínio não é por acaso, e sendo uma pessoa altamente curiosa sobre como uma empresa se organiza, levou-me a explorar melhor o porquê de uma única equipa ser tão dominante em relação a todas as outras. Para quem não conhece bem o desporto, a Mercedes tem vindo a ganhar campeonatos desde o ano 2014, continuando em 2020 a exercer um domínio claro sobre toda a concorrência. Porque serão tão bons? Terá a ver apenas com os pilotos ou também com a grande equipa que está por detrás? Bom, na F1 onde se luta por milésimos de segundo, considero que tem que existir um misto entre mestria de um piloto e de excelência por parte de toda a equipa. Na fábrica onde são produzidos os carros, toda uma equipa de centenas de pessoas trabalha em sincronia como um relógio suíço. Apesar de toda a forma como trabalham ser um segredo bem guardado, podemos através de alguns excertos identificar a cultura que se vive dentro da equipa. Transcrevo abaixo palavras de Toto Wolf, Team Principal da Mercedes:

 

“It’s about the marginal gains,” said Wolff of their success. “It’s about putting everything together and not leaving one stone unturned, having a no-blame culture, empowering [people], even when it’s difficult sometimes when you would rather control things. I think the strengths go very deep, values that are engrained in the teams that you can’t put on a Powerpoint and say ‘now we are empowered’.”

 

Não posso deixar de falar das primeiras palavras do Toto Wolff, tem tudo a ver com ganhos marginais. Ora, como já referi acima, na F1 luta-se por milésimos de segundo, temos na grande maioria das pistas 2 a 2,5 segundos a separar o carro mais rápido do carro mais lento, são margens muito pequenas. A atenção ao detalhe tem que ser levada a outro nível. É por isso que a equipa tem que investir enormes esforços na perseguição da perfeição, mesmo quando já são os melhores. Fazendo o paralelismo com o mundo da alta cozinha, por exemplo, a diferença entre um restaurante muito bom e outro com várias estrelas Michelin são os detalhes e a procura pela excelência. A quantidade e qualidade das pessoas necessárias para assegurar um restaurante com estrela Michelin tem que ser superior. Em alguns casos chegam a pôr a mesa com uma régua para que a distância entre os talheres seja a mesma em todo o restaurante.

Ora, analisando as palavras do Toto Wolff transcritas acima, e fazendo alguma pesquisa na internet, facilmente percebemos algumas características fantásticas da equipa Mercedes. Faço um resumo de algumas delas que considero serem uma verdadeira vantagem competitiva em relação aos seus concorrentes.

 

Não são complacentes

 

Uma equipa que ganha desde 2014 e continua a evoluir ano após ano é tudo menos complacente. O foco na melhoria é contínuo, a procura pelos ganhos marginais é constante, principalmente num desporto onde se discutem milésimos de segundo. Tudo conta, desde o mais pequeno pormenor até ao maior. Quando se é o melhor durante vários anos pode-se tender a achar que se é superior, que provavelmente não é necessário trabalhar tanto para obter bons resultados. Com a Mercedes nada poderia estar mais longe da realidade, existe humildade e respeito pela concorrência, o que faz com que não exista desleixe. Apesar de todos os outros não chegarem ao seu nível de performance, a equipa continua a sua jornada constante e interminável pela procura de melhorias. A não complacência e fome de continuar, mesmo depois de se chegar ao topo é uma grande vantagem. Tudo tem que funcionar de forma sincronizada, as equipas que fabricam a unidade motriz (motor) têm que estar alinhadas com a equipa de chassis, com a equipa de aerodinâmica, com as equipas de fabrico, com os próprios pilotos, etc...é um mundo muito complexo. Este tipo de performance é extremamente raro, tanto mais quando estamos a falar de uma empresa composta por centenas de pessoas.

 

Cultura de empowerment

 

Dito pelo próprio Toto Wolff, uma cultura de empowerment é fundamental numa organização de alto desempenho. Em empresas de conhecimento, onde imperam pessoas inteligentes e ambiciosas, aplicar estratégias de microgestão e controlo apertado não funcionam. Esse tipo de estratégias só fará as pessoas retraírem-se em situações onde deveriam estar a colaborar. Numa empresa como a Mercedes não existem umas dezenas de cérebros que decidem tudo, mas sim centenas de cérebros inteligentes que compõem uma espécie de mastermind. Apenas com este tipo de estratégias se consegue que 1+1 seja igual a 3, 4 ou quem sabe mais ainda. Objetivos e valores são muito bem definidos, toda a equipa tem de saber em que direção se está a dirigir. Fechando e alinhando os objetivos, deve-se dar autonomia e liberdade para a equipa os perseguir da forma que achar melhor. Na Mercedes todos sabem o que se espera deles, ganhar os campeonatos de pilotos e de construtores.

 

Mercedes AMG

 

Lealdade da equipa

 

Quando se dá excelentes condições às pessoas, e quando se é o melhor, existem poucos motivos para se querer sair. A equipa Mercedes tem pessoas com elevada lealdade, muitas delas desde o início da própria equipa. Começando pelas excelentes instalações, pela qualidade da comida que servem, pelas bebidas gratuitas, pelo café de qualidade superior, pelo brinde com champanhe para toda a equipa sempre que uma corrida é ganha, nada é deixado ao acaso. A Mercedes chega a enviar as almofadas pessoais dos colaboradores que estão deslocados numa corrida, para que todos descansem convenientemente e estejam prontos para dar o seu melhor. Na fábrica/sede todos os colaboradores têm lugar pra estacionar o carro, para assim evitar que comecem o dia stressados ou chateados. Todos sem exceção, desde os escalões mais baixos até aos mais altos recebem um bónus sempre que a equipa ganha o campeonato de construtores. A equipa percebeu que ter pessoas leais faz aumentar a sua produtividade e empenho, e é por isso que não olha a custos na hora de dar todas as condições às suas equipas.

 

Erros são oportunidades de melhorar

 

Erros são sempre vistos como oportunidades. Existe uma cultura de não-culpabilização. Quando se analisa um erro não é para apontar o dedo a alguém, mas sim para melhorar e garantir que não torna a acontecer. A Mercedes recolhe dados de uma grande variedade de fontes, da telemetria até à performance da equipa numa paragem na box. Várias sessões são realizadas com os engenheiros e pilotos, sempre com o objetivo de corrigir possíveis erros que se possam ter cometido. Fazendo um paralelismo com a indústria aeronáutica, quando começaram a existir aviões a probabilidade de queda era bastante mais alta do que é agora. Por mais horrível que seja, cada avião que caiu contribuiu de forma considerável para a evolução dos processos, materiais, formas de construção, etc. É por isso que hoje em dia, os aviões que caem são tão escassos. É resultado de uma evolução constante ao longo de vários anos. A Mercedes faz uso da mesma estratégia, e é por isso que raramente vemos a equipa a cometer o mesmo erro duas vezes. Sebastian Vettel, piloto da Ferrari, admitiu publicamente que a Mercedes está perto da perfeição, realçando a sua consistência e a quase ausência de erros. Isto apenas é possível com uma vontade enorme de aprender sempre que se erra.

 

Acima listei algumas das características que fazem a equipa de F1 da Mercedes tão fenomenal. A beleza é que todos os pontos podem ser aplicados em qualquer outra empresa. Não digo que seja fácil, a transformação é na grande maioria dos casos difícil. Mas como todos os grandes esforços, deve-se sempre começar pelo ponto lógico, pelo início :). Espero num post futuro conseguir aprofundar mais este tema, nomeadamente como pode uma empresa fazer uso destas e de outras estratégias para se reinventar e elevar-se para o próximo nível.

 

 

19
Jul20

Velocidade organizacional

Luís Rito

Vivemos na era da velocidade. Cada vez mais as empresas necessitam de "fazer coisas" a uma velocidade maior. Em muitos sectores a concorrência ataca de todos os lados, empresas que reagem de forma lenta podem perder oportunidades fantásticas ou na pior das hipóteses falir. Para tornar tudo ainda pior, algumas startups que hoje em dia fazem concorrência às grandes empresas têm a capacidade de se reinventar num período de tempo muito curto. A sua agilidade é vertiginosa e assustadora. Por outro lado, na sua maioria, as empresas gigantes tornam-se lentas e demasiado complexas, uma mudança de direção pode levar vários anos. Normalmente a burocracia apodera-se destas grandes empresas, começamos a ter pessoas demasiado cristalizadas e acomodadas, com muito pouca vontade de incutir mudança, vemos as típicas "quintinhas" defendidas com unhas e dentes pelas suas chefias que há muito tempo colocaram os seus interesses na frente dos interesses da organização. Tudo isto é praticamente nulo nas startups, já que têm poucas pessoas, têm estruturas mais simples e estão normalmente muito focadas nos objetivos de crescimento da empresa. É certo e sabido que quanto mais pessoas tem uma organização mais complexo vai ser realizar o que quer que seja, principalmente quando carece de uma cultura de partilha, de entreajuda e de foco apenas nos objetivos da empresa em prol de objetivos pessoais obscuros. Diria que apenas em situações de crise as pessoas são capazes de se mobilizar e empreender mudança de uma forma muito rápida. A pandemia que atravessamos é uma demonstração viva desta afirmação, empresas foram capazes de se reinventar de uma forma completamente radical numa questão de semanas. Pessoas que nunca se imaginaram a trabalhar de casa ou empresas que nunca acreditaram no que muitos já diziam desde há vários anos, que a produtividade tende a aumentar em teletrabalho, puderam comprovar essa realidade. Segundo um artigo da McKinsey, muitos CEO´s durante esta pandemia experimentaram um grande conjunto de medidas ágeis, conseguindo aumentar a velocidade das suas empresas. Alguns exemplos:

 

"Tomada de decisão acelerou, em situação de crise não nos focamos demasiado nos detalhes, mas sim na execução rápida de uma ideia. Muitos limitaram as reuniões de tomada de decisão a 9 pessoas e baniram o PowerPoint"

"Foco na construção rápida de protótipos em detrimento da busca pela solução perfeita"

"Aumento de canais diretos entre equipas"

"Adoção de novas tecnologias de uma semana para a outra (ao invés de meses ou anos), já que existe uma maior tolerância a erros, desde que não ameacem a continuidade do negócio"

"Criação de equipas multidisciplinares compostas pelas suas melhores pessoas como forma de atacar problemas complexos e difíceis"

 

Se nestas situações de crise já percebemos que a mudança pode acontecer de forma bastante rápida, como o fazer em situação normal? Como cortar os tentáculos da burocracia nas empresas? Como fazer a mudança acontecer de forma mais rápida? Acredito que dois vetores muito importantes são a cultura e a organização. As pessoas que as empresas devem procurar são aquelas que procuram constantemente melhores formas de fazer o seu trabalho, que lidem bem com a responsabilização, que não precisem de muita microgestão, que gostem de estar inseridas em meios onde cometer erros é visto como uma forma de evoluir, de aumentar a excelência. Este tipo de pessoas normalmente sente-se bem a trabalhar com pessoas que partilhem os mesmos princípios, pelo que uma das áreas mais importantes hoje em dia em qualquer empresa são os RH. A contratação de novo talento não deve ser levada de forma leviana, já que a incorporação de alguém que não se identifique com este tipo de cultura nunca vai dar resultado, podendo até "contagiar" negativamente algumas das pessoas que já lá trabalham. A nível de organização, profissionais de alto-rendimento tendem a gostar mais de velocidade, tomada rápida de decisão, estruturas mais planas e chefias que não adotem uma postura de comand & control. Vou-me focar nestes pontos e explicá-los um pouco melhor, apesar de parecerem na sua essência bastante simples, existe muita resistência na sua implementação na grande maioria das empresas.

 

Velocidade

 

Aumentar a velocidade de tomada de decisão

 

Na prática, muitos dos tempos de espera que hoje presenciamos nas empresas estão relacionados com processos de tomada de decisão muito lentos. Uma forma eficaz de reduzir este tempo de espera passa por realizar menos reuniões de tomada de decisão (foco máximo em fechar temas com uma iteração ao invés de várias) e que o número de decisores seja mais reduzido. Muitas empresas falam num máximo de 9 decisores ao invés de dezenas. Devemos evitar ao máximo estar numa reunião a decidir que temos que marcar outra reunião para avançar com o tema. Uma técnica que tem sido também utilizada passa por banir apresentações de PowerPoint (ou similares), e sempre que seja possível substituí-las por documentos de briefing que são lidos em silêncio no início das reuniões, como um documento de texto ou uma folha de cálculo. O CEO da Amazon Jeff Bezos baniu as apresentações da empresa, e afirma ter sido uma das decisões mais inteligentes que tomou. As apresentações obrigam a pessoa que prepara a reunião a despender muito tempo na sua realização (o que em alguns casos se pode chamar de desperdício de tempo), e trazem algumas desvantagens para quem está a assistir, como por exemplo:

 

1. Com apresentações, a informação é partilhada na velocidade em que a pessoa faz o seu discurso (muitas vezes com informação não relevante). Com documentos de briefing a informação é partilhada à velocidade que as pessoas leem. 

2. Um documento de briefing partilha a informação com todos no início da reunião, evitando perguntas que surgem nas apresentações e que muitas vezes poderão estar endereçadas em slides mais à frente. 

3. Evita-se algumas das coisas mais chatas das apresentações, como por exemplo informação não relevante, oradores com tons de voz monocórdicos e aborrecidos, ou casos em que se leva muito tempo a chegar ao ponto chave da reunião.

 

Não estou com isto a dizer que devemos acabar com todas e quaisquer apresentações, até porque para alguns casos continua a ser o mais eficaz, como por exemplo para apresentações a clientes ou à gestão da empresa. Devem sim ser ponderadas todas as reuniões para que se entenda se são ou não necessárias, ou se, em alternativa, um documento de briefing é suficiente (em reuniões mais táticas & operacionais deveria ser o suficiente).

 

Criação de uma estrutura mais plana

 

Uma empresa rápida e ágil tem mais pessoas a executar e menos pessoas a alimentar a burocracia. Estruturas rígidas têm normalmente muitas reuniões pouco produtivas, existe muita gestão de egos & expectativas, reporting excessivo, etc. Neste tipo de estruturas excessivamente hierarquizadas, a tomada de decisão é lenta e a reação a oportunidades normalmente baixa. É por isso que as empresas devem ter a capacidade de se reinventar, procurar estruturas mais planas, onde existem mais pessoas a executar e a efetuar tomada de decisão. O número de gestores intermédios deve também ser amplamente reduzido, e substituído por uma rede de equipas multidisciplinares, como um organismo vivo que se adapta e evolui. É nesta fase que se percebe a importância das pessoas que se tem a bordo, pois devem ser muito autónomas e devem conviver bem com serem elas a tomar muitas das decisões do dia-a-dia. As equipas multidisciplinares removem dependências que muitas vezes existem entre equipas diferentes e que causam lentidão nos processos. Por exemplo, ao realizar um desenvolvimento informático, normalmente este é transferido para uma equipa de testes e correndo tudo bem para outra equipa que irá realizar o roll-out em produção. Se uma equipa multidisciplinar estiver focada numa determinada área de negócio ou aplicação, pode conter uma pessoa de desenvolvimento, uma de testes e uma de operações IT, removendo todas as dependências que existiam antes. Passa a ser uma prioridade de toda a equipa, ao invés de lidarmos com 3 equipas com 3 prioridades diferentes.

A colaboração em tempo real deve também ser a norma, devemos abandonar gradualmente o uso de emails já que nos esgota horas e horas do nosso dia. Por vezes vejo o email como algo já crónico em muitas empresas, onde temos pessoas aprisionadas no seu envio & resposta, causando níveis de produtividade muito baixos. Deve ser cultivada a máxima, se é urgente não me envies email porque só o vejo uma ou duas vezes por dia. Em alternativa, utiliza o telemóvel, chat ou videochamada. Podem também ser criados centros de excelência dentro da empresa, compostos por uma ou mais equipas multidisciplinares. Alguns exemplos de centros de excelência podem ser, Agilidade & Metodologia de trabalho, BI, Inteligência Artificial, etc. A ideia é ligar um grupo de pessoas que partilham os mesmos gostos e procurar continuamente inovações ou formas mais eficazes de fazer as coisas.

 

Deixo-te abaixo um vídeo da Apple muito elucidativo de uma equipa multidisciplinar a trabalhar em pleno, apesar das dificuldades :)

 

 

Repensar e reinventar o papel dos líderes

 

Se o objetivo é ter estruturas mais planas, qual deve então ser o papel do líder dentro da organização? Bom, em primeiro lugar deve abandonar as abordagens de Command & Control, é algo que não funciona bem em empresas de conhecimento. O papel dos líderes deve ser definir a direção, energizar as equipas, desbloquear problemas, fazer crescer as pessoas e garantir que existe confiança entre todas as partes. O grande papel de um líder é criar equipas vencedoras, ou como alguns dizem, o dia em que este se poder ausentar e as suas equipas continuarem a trabalhar a 100% significa que está a fazer um trabalho fenomenal. O líder não pode ter medo de ter dúvidas e de não saber tudo, não pode ter medo de contratar pessoas mais inteligentes que ele, pois significa que detém humildade para se necessário, mudar a sua opinião e procurar continuamente mais conhecimento. Na minha opinião, as funções de liderança devem ser asseguradas por especialistas em pessoas e comportamento humano, devem também ser mais desempenhadas por visionários e menos por comandantes. Após partilhada a visão com todas as equipas, o líder deve deixar as pessoas das suas equipas definir como chegar lá, evitando ao máximo práticas de microgestão, pois é algo que profissionais de alto-rendimento odeiam e que os pode fazer sair da empresa.

 

A velocidade é nos dias de hoje algo fundamental, não se trata apenas de uma mais-valia, é algo obrigatório. As empresas devem ter a capacidade de se reinventar, de procurar novas e melhores formas de atingir os seus objetivos, mesmo que isso implique causar muita disrupção ao que é o seu dia-a-dia atual. É necessária coragem da gestão de topo para empreender em revoluções a nível de organização, mas os resultados podem ser bastante benéficos garantindo a sua continuidade no tecido empresarial.

 

 

21
Jun20

Ainda compensa investir na carreira de gestão de projetos?

Luís Rito

A eterna pergunta de alguém que está prestes a investir longas horas em aprender uma nova skill. Será que compensa todo o esforço que estou a colocar neste objetivo? Será o caminho certo? Muitas pessoas fazem esta pergunta a elas mesmas, e os futuros gestores de projeto não são exceção. Afinal de contas, ainda existe mercado para esta profissão? Irá esta proliferar ou o futuro reserva-nos algo bem diferente? Enquanto escrevo este artigo, cada vez mais o universo agile ganha terreno face a gestão de projetos tradicional. Em estruturas e metodologias agile, o gestor de projeto perde um pouco a sua relevância, sendo esta figura substituída por uma espécie de Team Leader/Scrum Master. A estrutura das equipas também é bem diferente, o grande objetivo passa por assegurar equipas multidisciplinares que sejam self-managed, ou seja, que se organizem espontaneamente de forma natural, sem necessidade que exista uma figura a orquestrar o trabalho. Toda a equipa acaba por fazer esse trabalho de orquestração. Se assim o é, espera-se que esta tendência roube muitos postos de trabalho que outrora pertenciam aos gestores de projeto certo?

 

Apesar do que referi no parágrafo acima, deixo já a minha opinião, acredito que pessoas com excelentes competências em gestão de projetos vão continuar a dar cartas no mercado. O PMI (Project Management Institute) lançou um estudo que estima que por volta do ano 2027, vão existir certa de 87.7 milhões de vagas disponíveis para funções relacionadas com gestão de projetos. Isto deve-se em grande parte a um aumento considerável de empregos relacionados com projetos nos últimos anos. Para além disso, existe toda uma geração de gestores de projeto que se vai reformar, abrindo espaço para os profissionais que estão no ativo. A realidade é que se te deres conta, nos últimos anos as empresas começaram a aprender qual o valor dos projetos. Na minha opinião cada vez mais empresas entendem que os projetos são o principal meio para atingir os seus objetivos estratégicos e para trazer inovação. Felizmente os projetos proliferam nas empresas, o que significa que o número de profissionais envolvidos nestes também tem que aumentar. Segundo o mesmo estudo do PMI, por ano espera-se que exista uma procura de cerca de 2.2 milhões de cargos relacionados com projetos. Deixo-vos uma nota, este gap que existe e que vai continuar a existir refere-se a profissionais com capacidade de trabalhar em ambiente de projeto. Quero com isto dizer que neste bolo podem estar incluídos gestores de projeto, scrum masters, agile coaches, team leaders, portfolio managers, program managers, PMO managers e muito mais. Um bom gestor de projetos tem uma grande probabilidade de se tornar também um bom team leader ou um bom scrum master, já que muitas das competências podem ser facilmente transferidas de um role para outro. Não é necessário ter receio de abraçar o mundo Agile, aliás, diria que é fundamental pois em certos sectores como o IT é cada vez mais adotado.

Outro fator a favor da profissão é a variedade de indústrias em que se insere. Algumas das indústrias com maior necessidade de gestores de projeto são por exemplo o sector da construção e do IT, mas diria que hoje em dia existem projetos em praticamente todas as indústrias.

 

workflow

 

Para além de que se estime que a procura continue a aumentar, a carreira de gestão de projetos oferece-te algo único, a possibilidade de criar. O grande objetivo dos projetos é entregar algo que a empresa ainda não tem, algo único no contexto da organização. Se este tipo de desafios te agrada, e se tens vontade de aprender sobre uma grande variedade de temas, então vais adorar a gestão de projetos. Ao longo de uma carreira é possível que um profissional nesta área venha a aprender sobre várias indústrias e sobre dezenas de processos, produtos, tecnologias, etc. A aprendizagem contínua tem que estar nos genes das pessoas que sigam uma carreira em gestão de projetos. Para além disso, é uma profissão que coloca em prática um vasto leque de competências. Desde a capacidade de planeamento, negociação, liderança, gestão do tempo, gestão do risco, capacidade de execução, controlo financeiro e forte capacidade de comunicação são só algumas das competências que um excelente gestor de projetos deve ter.

 

Para quem vai investir numa aprendizagem em gestão de projetos, o caminho pode parecer longo, mas garanto-te que é quando estiveres a gerir projetos no terreno que vais aprender mais. É claro que os conhecimentos técnicos são fundamentais, esses tens que os aprender, mas considero que são as soft skills que fazem um gestor de projeto de alta performance. Se fosse fácil todos aqueles que aprendessem tecnicamente a gerir projetos seriam altamente bem-sucedidos, o que infelizmente não é o caso. Isto porque não nos podemos esquecer que quem executa os projetos são pessoas e não o processo em si. Claro que as boas práticas vão sem dúvida ser uma ajuda, e é por isso que são reconhecidas como boas práticas, mas no final, a equipa ou te escolhe seguir ou não te escolhe seguir, e se não te seguir vais ter imensa dificuldade em levar o projeto a bom porto.

 

Em jeito de conclusão, e respondendo à pergunta inicial, na minha opinião continua a compensar muito investir numa carreira de gestão de projetos. Os verdadeiros profissionais nesta área são uma minoria e vão continuar a ser muito procurados para a gestão dos projetos mais críticos e complexos das organizações. Se tivesse que investir novamente numa carreira não iria pensar duas vezes :).

 

 

 

14
Jun20

Porque é que muito WIP vai matar o teu departamento de IT?

Luís Rito

WIP é um acrónimo que significa "Work in Progress" ou "Work in Process", e basicamente representa trabalho que se encontra a ser executado dentro de um determinado sistema. Este acrónimo é bastante conhecido junto da comunidade Lean, sendo muito utilizado em processos de produção fabril, como por exemplo na montagem de um automóvel, desde o momento em que entra na linha de montagem até ao momento em que sai. Apesar do sucesso que as práticas Lean têm tido nesse tipo de ambientes, junto de processos onde o trabalho é considerado mais invisível, como por exemplo, num departamento de IT, a sua utilização não tem sido adotada. Os argumentos variam, alguns afirmam que não se pode comparar trabalho altamente especializado e complexo como por exemplo desenvolvimento de software com a montagem de um automóvel. Contudo, quanto mais leio e investigo sobre o assunto mais similaridades encontro. Na linha de montagem de um automóvel, existem várias estações de trabalho, por exemplo, montagem de motor, montagem de componentes elétricos, pintura, etc. O automóvel, o qual vou passar a chamar unidade de trabalho, desloca-se desde o início do processo até ao seu final, saltando de estação de trabalho em estação de trabalho, até chegar finalmente ao final do processo e ser considerado pronto. Cada estação de trabalho tem um número máximo de unidades de trabalho que pode aceitar, e durante por exemplo 8h, passam pelo processo várias unidades de trabalho (automóveis). Isto significa que a data altura, se parássemos o sistema, teríamos x automóveis dentro do sistema, chegando assim ao nosso WIP. Todo o sistema é continuamente otimizado, e atividades que permitam melhorá-lo são rapidamente implementadas pelos seus trabalhadores. Em sistemas deste género, é também fácil perceber que não podemos aumentar o WIP sem antes realizarmos otimizações ao nosso processo. Por exemplo, se apenas temos uma câmara de pintura, então não podemos pintar dois automóveis ao mesmo tempo, estando o WIP nessa estação de trabalho limitado a 1 unidade.

 

Ora, se olharmos com atenção para um departamento de IT, mais concretamente uma equipa de desenvolvimento, encontramos muitas similaridades. De forma análoga ao que acontece com a linha de montagem, no desenvolvimento de determinada funcionalidade de software (para facilitar, chamada também unidade de trabalho), também se devem seguir determinados passos até que esta seja considerada concluída. Em organizações com hierarquias mais tradicionais, não existe o conceito de equipas multidisciplinares, logo uma unidade de trabalho tem que saltar de estação de trabalho em estação de trabalho, tal como acontece na linha de montagem. Estas estações de trabalho podem ser por exemplo, análise funcional, desenvolvimento da solução, testes de integração e de utilizador, deployment, acompanhamento ou service desk, entre outras que não coloco para não tornar o exemplo demasiado complexo. Em determinada altura, cada uma destas estações de trabalho tem um WIP específico, muitas vezes a tender para infinito, já que não existe qualquer bloqueio ao nível de trabalho em curso. Como o tipo de trabalho acaba por ser mais invisível, é possível cada estação de trabalho ter um número incrivelmente alto de temas em curso, e outro tanto em espera para ser iniciado. Ou seja, seria o equivalente a termos uma câmara de pintura e 10 automóveis em espera para serem pintados, não faz sentido.

Em IT, existirem inúmeras unidades em curso em cada uma das estações de trabalho leva a atrasos cada vez maiores. Está mais que provado que o multitasking não funciona, ter inúmeros temas em curso significa que nenhum deles será realizado com velocidade, e pior, fará com que unidades que venham de outras estações de trabalho fiquem muito tempo em espera até serem realmente realizadas. O segredo para que isto não aconteça é não incluir trabalho no sistema até ele rebentar. Uma linha de montagem de automóveis tem um limite, e de forma similar, as equipas de IT têm igualmente um limite de pedidos que conseguem realizar. Se assim é, porque continuam as empresas a inserir mais unidades de trabalho num sistema que já está a rebentar pelas costuras? Cada estação de trabalho tem um número de pessoas, com uma capacidade finita para realizar pedidos. Por exemplo, se tens uma equipa de 4 pessoas numa estação de trabalho, e se definires que cada uma delas pode laborar em simultâneo em 2 temas, então a tua capacidade de unidades máxima que deves aceitar nessa estação de trabalho é de 8 e não mais que isso. Ou seja, para adicionar mais 1 unidade, esta estação deve retirar do seu WIP igualmente 1 unidade.

 

Kanban Board

Nota: E como podes controlar o WIP no teu processo? Os quadros Kanban são ótimos aliados, através deles é possível saber a dada altura qual o WIP em cada estação de trabalho e consequentemente qual o WIP total do processo. Noutro artigo prometo falar-te mais dos quadros Kanban.

 

Todos sabemos o quão difícil é gerir um departamento de IT, existe constantemente trabalho "urgente" e não planeado que aparece no caminho. O maior desafio passa por escolher muito bem o trabalho que é realizado, distinguir o que são urgências verdadeiras de urgências sem fundamento. É que muitas vezes essas urgências servem apenas para beneficiar uma área, ou pior, uma pessoa específica (portanto para essa pessoa é a atividade mais urgente que a empresa tem para fazer). O trabalho não planeado é o verdadeiro cancro de um departamento de IT. Quando uma equipa passa todo o tempo a combater incêndios, sobra muito pouco tempo e energia para planear e para pensar. Ao estar constantemente a reagir não existe energia para fazer o trabalho mental difícil de escolher muito bem o que se deve ou não aceitar. A consequência disto é que mais trabalho entra no sistema, o que significa mais multitasking, mais trabalho "feito à pressa", mais atalhos e mais débito técnico. É uma bola de neve e uma espiral descendente. Fazendo a analogia com uma autoestrada, se a sua capacidade estiver perto dos 100%, existe um engarrafamento gigante, e consequentemente, ninguém anda 1 metro que seja. Se a capacidade estiver um pouco mais baixa, o trânsito fluirá com maior facilidade. Se a capacidade das equipas está perto dos 100%, todo o sistema terminará unidades de trabalho a um ritmo quase nulo.

A melhor forma de exemplificar este conceito é com uma fórmula bastante simples:

 

Wait Time = % Busy / % Idle

 

O que esta fórmula significa? Se a % de tempo de ocupação de determinada estação de trabalho é igual a 50%, então a % de tempo disponível é igualmente de 50%. Dividindo uma pela outra obtemos 1, por motivos de exercício poderemos considerar 1 hora de tempo de espera.

Se a % de tempo de ocupação de uma estação de trabalho é igual a 90%, então a % de tempo disponível é de 10%, logo o tempo de espera é igual a 9 (9 vezes mais tempo que no exemplo que dei acima).

Agora vem a parte interessante, se a ocupação de uma estação de trabalho é igual a 99%, significa que a % de tempo disponível é de 1%, logo o tempo de espera é igual a 99 (99 vezes mais que o primeiro exemplo que te dei).

 

Na prática, isto significa que quando menos % de capacidade disponível a estação de trabalho tiver, mais tempo as unidades de trabalho ficam em espera até serem realizadas. Isto é tão mais grave quanto maior a quantidade de estações de trabalho que uma unidade deve percorrer até ser dada como concluída. A título de exemplo, se o sistema fosse composto por 3 estações de trabalho, todas elas a trabalhar a uma capacidade de 99%, cada unidade de trabalho teria de esperar 99h em cada uma delas até ser concluída, ou seja, 297h! Não admira que digam que o departamento de IT leva 6 meses a entregar um desenvolvimento. Deve ser reservada capacidade das equipas para trabalho não planeado e para pensarem em melhores formas de otimizar o processo. Trabalho com a finalidade de melhorar o processo como um todo é tão ou mais importante que o trabalho atual. A capacidade de as equipas introduzirem melhoria contínua nos seus processos e nas suas formas de trabalhar permitirá reduzir muitas dores de cabeça no futuro. Por exemplo, se em 75% das vezes obtemos bugs em desenvolvimentos de determinada funcionalidade porque o código está complexo e não estruturado, então deve ser reservado tempo para o melhorar, esperando com esta ação reduzir a percentagem de bugs, permitindo que a equipa ganhe ainda mais tempo no futuro. Isto não é teoria, é a realidade, equipas com esta capacidade de se melhorar têm maiores hipóteses de se tornar numa equipa de alto rendimento. No espectro contrário, equipas em que não exista melhoria, rapidamente vão tornar-se obsoletas por efeito da entropia. Dou um exemplo muito simples, um cubo de gelo num copo com água. Com o tempo a entropia aumenta, e o calor faz com que o gelo fique mais desordenado e consequentemente líquido. Para que o gelo possa manter-se no estado sólido será necessário fornecer mais energia para que ele mantenha a sua temperatura, caso contrário e devido à entropia este irá ser transformado em água. O mesmo acontece nas organizações e nas equipas. Deve ser aplicada mais energia ao sistema para que este se mantenha em pleno funcionamento, caso contrário a entropia encarregar-se-á de o transformar em algo caótico e desordenado. É aí que entra a melhoria contínua, é a energia que uma organização/equipa necessita para se manter forte.

Em jeito de conclusão, é fundamental que os departamentos de IT saibam escolher muito bem o trabalho que têm que realizar, sempre alinhado com o que são para a empresa os seus objetivos estratégicos. É fundamental que reduzam o seu WIP, deixando margem para outras atividades como melhoria contínua e otimização de todo o sistema, e é fundamental que se deixe de pensar em ter os recursos o mais ocupados possível, pois isso irá diminuir o fluxo de todo o processo.

 

Qual a tua opinião?

 

 

31
Mai20

Agile Mindset

Luís Rito

Muito se tem falado de Agile nos últimos anos. Equipas e estruturas organizacionais mais tradicionais têm estado sobre fogo, o mundo atual exige uma capacidade de trabalho completamente diferente da que existia no passado. Eu pessoalmente sou um adepto tanto de metodologias ágeis como de metodologias mais tradicionais. Falo desta forma porque independentemente da metodologia que escolhes, o que interessa é que a tua equipa tenha uma mentalidade ágil. Mas afinal, do que se trata isto? Bem, uma mentalidade ágil começa no tão conhecido manifesto ágil. O manifesto ágil foi criado em 2001 por um grupo de pessoas muito ligada ao desenvolvimento de software, daí os seus valores serem muito voltados para essa área. Pessoalmente prefiro o manifesto que foi mais tarde adaptado pela organização "Disciplined Agile".

 

We are uncovering better ways of working (WoW) by doing it and helping others to do it. Through this work we have come to value:

 

  • Individuals and iteractions over processes and tools
  • Consumable solutions over comprehensive documentation
  • Stakeholder collaboration over contract negociation
  • Responding to feedback over following a plan
  • Transparency over false predictability

 

That is, while there is value in the items on the right, disciplined agilists value the items on the left more.

 

O que significam então todos estes valores que te enumero acima? Segui-los vai transformar-te num profissional mais ágil? A resposta é sim, seguindo estes valores vais mudar o teu estilo de trabalhar. Se direcionares as decisões que tens que tomar no teu dia-a-dia de acordo com estes valores, ao longo do tempo vais perceber que coisas que fazias no passado e que tomavas como garantidas são na realidade bastante ineficientes e contraproducentes. Para que possas entender a profundidade que estas simples frases podem ter, explico uma por uma.

 

Individuals and iteractions over processes and tools

 

Os projetos são feitos por pessoas, e não por processos e ferramentas. É sempre uma mais valia interagir com as pessoas, se possível cara a cara ou por videochamada. Essas são as formas mais eficazes de comunicar e de resolver problemas. O email NÃO é uma ferramenta para fazer chat nem para resolver problemas. Para agravar tudo isto, a comunicação escrita é bastante fraca, já que entre duas pessoas não existe uma perceção se a mensagem enviada ou recebida vai ter o mesmo entendimento do lado da outra pessoa. O email tornou-se no que gosto de chamar o jogo da batata quente. Tenho um problema, está-me a queimar as mãos, portanto escrevo um email para outra pessoa e passo a batata quente. Se alguém me perguntar, a responsabilidade já não é minha, afinal já enviei um email para alguém, esse alguém é que não me respondeu, portanto, não é problema meu. Este tipo de pensamento dentro de uma equipa é meio caminho andado para a sua decadência. As pessoas ainda não entenderam que as ameaças não estão dentro da empresa, mas sim fora. Se enquanto equipa, e ultimamente enquanto organização não evoluirmos para modelos mais colaborativos, podemos estar todos condenados a assistir ao declínio da empresa. O mesmo vale para processos altamente burocráticos, cheios de aprovações, validações e possibilidades de andarem para trás e para a frente, incrementando o seu lead time e a frustração de todos os envolvidos. É por isso que para mudares para uma mentalidade mais ágil, te deves focar em interações mais ricas como conversas cara-a-cara. A tecnologia hoje permite-nos fazê-lo de forma bastante fácil através de videochamadas. O que muitos não entendem, é que uma videochamada de 10m pode poupar 1h de escrita de emails e muitas chatices e mal-entendidos. Fico doente quando vejo trocas de emails onde estão 10 pessoas em cópia e apenas 2 estão a "bater bolas" uma com a outra, originando um chorrilho de spam nas caixas de correio de todos os outros. Também não entendo bem os emails com respostas que parecem autênticos livros. Levam imenso tempo a escrever e imenso tempo a ler, é desperdício por todos os lados. É por isso que deves sempre procurar formas de comunicar mais eficazes, só dessa forma podes dar um primeiro passo para uma mentalidade ágil.

 

Consumable solutions over comprehensive documentation

 

Existe uma ideia generalizada que em metodologias ágeis não é necessário produzir documentação. Essa ideia está muito longe da realidade, documentação continua a ser algo muito importante, e este valor que te apresento acima não pretende tirar o protagonismo a atividades de documentação. Contudo, a principal medida de valor são soluções em funcionamento e não documentos. De nada adianta ter documentação perfeita se a equipa tarda em apresentar soluções aos principais stakeholders do projeto. É por isso que a documentação deve ser realizada just in time, ou seja, não adianta estar a detalhar todas as funcionalidades exaustivamente, porque existe uma forte possibilidade de durante a duração do projeto existirem bastantes alterações. Em projetos mais tradicionais, é no início que se executa toda a especificação do trabalho a ser executado, o que resulta na grande maioria dos casos em fases de análise muito extensas e carregadas de validações & aprovações. Esta demora acontece porque as equipas sabem que alterações não são bem-vindas em projetos tradicionais, e tentam ao máximo detalhar todo o trabalho a ser realizado. O ridículo da situação é que estas fases de análise são pesadas e demoradas, sendo que existe uma forte possibilidade de muitas funcionalidades terem de vir a ser alteradas no futuro. Uma abordagem mais prática é planear, especificar e desenvolver just in time, ou seja, detalhar muito bem o trabalho a realizar no curto prazo, e manter um detalhe Qb para o restante, e há medida que se vai avançando no projeto o detalhe vai sendo construído, possibilitando aos stakeholders irem introduzindo alterações se necessário.

 

Alta performance

 

Stakeholder collaboration over contract negociation

 

Em metodologias tradicionais, é comum definir todo o âmbito do projeto no início do projeto. Isto origina a que exista quase uma missão por parte do gestor de projeto em defender com unhas e dentes esse âmbito. O resultado é muita negociação ao longo do projeto e a uma deterioração da relação entre equipa de projeto e cliente. Equipas ágeis gostam de colaboração e gostam de construir em conjunto, mesmo que isso implique não seguir rigorosamente o plano de projeto. É a colaboração entre pessoas que transforma uma equipa mediana numa equipa de alto rendimento, e é uma cultura de partilha que permite a uma organização criar uma verdadeira vantagem competitiva sustentada. 

 

Responding to feedback over following a plan

 

Alterações em metodologias ágeis são bem-vindas. Uma empresa moderna entende que é normal existirem mudanças de rumo, seja porque o mercado assim o exige, seja porque internamente faz mais sentido ir por outro caminho. Entregar um projeto on-time mas que não disponibiliza as funcionalidades que a empresa necessita é um fracasso. Os gestores de projeto devem ter isto em mente, têm que deixar de ser escravos do prazo, do custo e do âmbito e passar a olhar para o que cria efetivamente valor para os stakeholders. É por isso que ser ágil significa ter elasticidade para se adaptar a mudanças durante o curso do projeto. Apesar de seguir um plano ser algo muito importante, o que não deve acontecer é existir inibição por parte do cliente em solicitar alterações que vão trazer mais valor ao output do projeto. Ou seja, seguir o plano de forma meticulosa e inflexível só vai fazer com que exista mais fricção entre as pessoas e fazer com que o projeto entregue não seja exatamente aquilo que o cliente pretende.

 

Transparency over false predictability

 

Muitos projetos pelo mundo fora são autênticas melancias, verdes por fora e vermelhos por dentro. É comum os gestores de projeto esconderem informação do seu cliente final e passar uma imagem que está tudo controlado. O profissional moderno e ágil não deve ter medo de partilhar os obstáculos e deve promover a transparência o máximo possível. Durante muitas vezes vi profissionais apresentarem planos de projeto que nada têm que ver com a realidade, mas que junto dos executivos fazem um verdadeiro brilharete! Do que adianta investir horas num planeamento perfeito, se a realidade muda diariamente? A isto chama-se falsa previsibilidade, já que na realidade se está a passar uma imagem de controlo e planeamento que não corresponde de todo ao que acontece. A transparência é preferível, é sempre melhor levantar os problemas mais cedo do que mais tarde, e contar com a inteligência da nossa equipa para ultrapassar tudo o que aparecer no caminho. Se existe um problema, se vão existir atrasos, deves levantar a bandeira e fornecer cenários para ajudar a tomada de decisão dos decisores. Se necessário, corta âmbito e cinge-te a atividades que acrescentam realmente valor ao cliente final. Segue a regra dos 80-20, 20% das funcionalidades vão fornecer 80% do valor. A equipa deve ser ainda brutalmente transparente, nada de esconder informação, o feedback é algo de extrema importância para uma equipa de alto rendimento.

 

Como podes ver, ser ágil não é apenas utilizar a metodologia X ou Y, não é por fazeres uma versão adaptada de SCRUM que te vai transformar num agilista. Na realidade é um modo de encarar o trabalho e também uma cultura que se pratica todos os dias. Uma equipa que é transparente, que encara todas as oportunidades para se melhorar continuamente e que procura constantemente a excelência é uma equipa ágil. Temos todos de começar a pensar como uma equipa e não como indivíduos donos do nosso pequeno mundo. Só assim poderemos aspirar a ser verdadeiramente ágeis.

 

 

01
Mai20

Definition of Done, porque é tão importante em projetos agile?

Luís Rito

Definition of Done (DoD) é uma expressão que muitos que já estiveram envolvidos em projetos Agile reconhecem. Mas afinal o que é e para que serve?

DoD é na realidade uma checklist definida pela equipa de projeto, onde são descritas todas as tarefas necessárias para que uma story (desenvolvimento) seja concluído. Em metodologias Agile obtém-se progresso através de iterações, também chamadas de sprints se estivermos a falar de scrum. Em cada iteração a equipa executa blocos de trabalho ou stories que vão contribuir para a conclusão do projeto (caso se trate de um projeto). Dependendo da metodologia que a equipa estiver a utilizar, poderá estar a registar as atividades num quadro Kanban para que todo o fluxo de trabalho seja mais visual. O Kanban tanto pode ser virtual como físico, ambos funcionam, mas o virtual torna a partilha de informação entre várias equipas mais simples, principalmente se estiverem colocadas em localizações físicas diferentes. Os quadros kanban estão sempre divididos em fluxos de trabalho, que representam todos os estágios que um desenvolvimento tem que ultrapassar até ser dado como concluído. Uma divisão muito simples que normalmente se vê muito é: Por Realizar, Em Curso e Concluído. Esta é a divisão mais simples, sendo que na maioria das empresas acabará por ser um pouco mais complexo, como por exemplo: Backlog, Em Análise, Pronto para desenvolvimento, Em Desenvolvimento, Pronto para testes, Em testes e Concluído.

É justamente na passagem de um desenvolvimento para concluído que uma DoD deverá entrar. Algo que normalmente acontece nas empresas é dar-se uma story como concluída após o seu desenvolvimento ter terminado. Acontece que após o desenvolvimento ter terminado, existem ainda um conjunto de atividades que devem ser asseguradas para que a story se considere bem feita. Dou vários exemplos, a story foi documentada? A story foi testada de uma forma integrada e não apenas unitariamente? Foi realizada uma análise ao código por um colega? Como podem ver, existem muitas atividades que à primeira vista são invisíveis, mas que têm que ser realizadas, o que resulta claro em menos tempo da equipa para a execução de outras tarefas.

 

Definition of Done

 

Uma DoD correta permite ainda aumentar a qualidade do trabalho entregue, já que cada desenvolvimento deve passar por todas as fases descritas pela equipa até que seja considerada concluída. Para além da qualidade, dá também consistência a todo o trabalho e reduz em muito o rework. Pegando nos exemplos que te dei acima, deixo-te abaixo o que poderia ser uma DoD definida pela equipa:

 

  • Peer review ao código realizada?
  • Código testado unitariamente?
  • Código testado de forma integrada em ambiente de desenvolvimento?
  • Documentação técnica realizada?
  • UX (user interface & experience) consistente com solução global?

 

Quero só deixar a nota que uma DoD nada tem que ver com critérios de aceitação. Muitas vezes existe esta confusão, mas a grande diferença reside no facto dos critérios de aceitação se focarem mais na funcionalidade em si e não na qualidade do processo. Se olharem com atenção para os items que vos mostrei acima, estão mais relacionados com o facto de estarmos ou não a seguir um bom processo de desenvolvimento, testes e documentação, o que se vai refletir claro em aumento de qualidade. Já os critérios de aceitação visam definir se a funcionalidade que foi realizada faz aquilo que é suposto fazer e que foi solicitado pelo cliente. 

 

Uma DoD deve estar bem visível para todos os membros da equipa, para que quando chegue a altura de dar uma story como concluída se faça uma revisão se todos os pontos são cumpridos. Deixo apenas o alerta para não teres demasiados pontos, é suposto uma metodologia ágil ser...ágil, portanto nada de adicionar demasiada burocracia ao processo. Recomendo que sempre que a equipa faça retrospetivas (analisar a forma como trabalha para melhorar), que se foque também na dimensão da DoD. Devem analisar se todos os items fazem ou não sentido e se é ou não necessário remover ou adicionar novos.

 

Por hoje é tudo, tens dúvidas sobre algo que escrevi? Fala comigo sem problemas, podes responder a este artigo ou contactar-me diretamente via email.

 

Até à próxima!

 

22
Abr20

Scrum em projetos de grande dimensão

Luís Rito

Olá!

 

Ao longo do tempo, tenho-vos escrito alguns artigos sobre como pode uma empresa reinventar-se e começar a trabalhar de uma forma menos tradicional e mais ágil. A agilidade organizacional é hoje uma característica quase obrigatória em qualquer empresa que se queira destacar no século XXI. Claro que não se aplica a todo e qualquer tipo de projetos. Existem projetos onde a agilidade compensa largamente, enquanto noutros uma gestão de projetos mais tradicional continua a ser uma mais valia. Metodologias mais tradicionais favorecem muito a previsibilidade, enquanto metodologias mais ágeis favorecem a velocidade. Quanto a vocês não sei, mas na construção de um edifício ou de uma ponte prefiro sempre previsibilidade a velocidade. É por isso que neste tipo de projetos ainda se utiliza muito metodologias tradicionais de gestão de projetos (também conhecidas como waterfall). Contudo, diria que na esmagadora maioria dos projetos que hoje se iniciam, a velocidade é um fator determinante e obrigatório, seja porque o contexto muda constantemente, seja porque se quer ser mais rápido que um concorrente, seja porque os clientes assim o exigem. É por isso que nos últimos anos, metodologias ágeis como o Scrum têm florescido e prosperado junto dos gestores de projeto e organizações.

 

Uma das críticas que o Scrum é normalmente alvo, é que funciona muito bem em equipas e projetos pequenos, mas para aplicar em projetos de grande dimensão torna-se insuficiente. Esta afirmação revela algum desconhecimento, já que hoje em dia existem várias formas de utilizar metodologias ágeis mesmo em grandes projetos. Existem frameworks específicas para quem quer utilizar metodologias ágeis em organizações de grande dimensão ou em projetos/programas que envolvam centenas de pessoas. Algumas delas são:

 

 

Pela sua simplicidade e facilidade de implementação, hoje quero focar-me especificamente no scrum of scrums. Na realidade, trata-se de fazer algo muito semelhante ao que já acontece numa iteração normal de scrum. Para aprenderes mais sobre scrum, dá uma vista de olhos neste artigo.

De forma resumida, o trabalho é realizado por iterações (sprints), normalmente de 2 ou 3 semanas. Antes de cada sprint a equipa compromete-se com uma quantidade de trabalho que é retirado de um backlog (trabalho em falta) de acordo com as prioridades definidas pelo product owner (ponto de contacto com o cliente). Diariamente acontecem as daily scrums, que são reuniões de 15m com o objetivo da equipa partilhar o que fez, o que vai fazer e que impedimentos está a ter. No fim do sprint deve ser apresentado o seu output ao cliente, permitindo também obter feedback de uma forma constante e regular. Finalmente a equipa evolui na sua forma de trabalhar através das retrospetivas, onde se analisa o que correu bem, o que correu menos bem e coisas que a equipa pode melhorar na próxima iteração.

 

Scrum of Scrums

 

Se deres uma vista de olhos na imagem acima, encontras 4 equipas, equipa A, B, C e D. Cada uma dessas equipas tem um backlog específico que representa o trabalho que tem para executar (via sprints), e tem também um product owner e um scrum master. Já falámos que um Product Owner é o ponto de contacto com o cliente, efetuando ainda a gestão das prioridades de execução, enquanto o scrum master é a pessoa responsável por garantir as boas práticas do scrum e agir como um servant leader para a equipa, desbloqueando todo o tipo de problemas. Vamos assumir que todas as equipas da imagem têm responsabilidade sobre uma área específica do projeto, trabalhando cada uma delas dentro da sua própria bolha. Por se encontrarem de certa forma isoladas, as equipas selecionam uma pessoa que servirá como embaixador (normalmente o product owner ou o scrum master), que fará parte de outra equipa de scrum um nível acima. Essa equipa terá igualmente um backlog e uma daily scrum (que pode por exemplo ser semanal ao invés de diária) onde é partilhado o que foi feito, quais os próximos passos e quais os impedimentos com que a equipa se está a deparar. Normalmente nos níveis mais acima, os impedimentos são mais focados em temas relacionados com problemas de coordenação entre as equipas.

A ideia é que essas equipas mais acima tenham uma pessoa de cada equipa individual de scrum, para que com isso consigam ter uma ideia mais global do projeto como um todo. Isso ajudará com questões como dependências entre equipas ou desbloqueio de problemas. Caso necessário, ainda é possível ir mais níveis acima (uma espécie de pirâmide como podes ver na imagem acima), tudo depende da complexidade do projeto. Assumindo uma estrutura como a da imagem, e com reuniões diárias de 15m, seria possível comunicar com todas as partes em apenas 45m (15m por cada nível).

Reforço que em todos os níveis deve existir um backlog de trabalho a realizar. A grande diferença é que mais acima fala-se de features ou epics (grandes blocos de trabalho), e há medida que se vai descendo o trabalho é partido em blocos mais pequenos até chegar ao nível das equipas que o estão a executar.

 

Caso o número de pessoas que compõem o projeto seja muito elevado, deve-se aumentar o número de equipas de scrum, já que o tamanho ideal das equipas ronda as 6-8 pessoas. Assumindo que cada uma das equipas tem no máximo 7 pessoas, caso estejamos a falar de 10 equipas, teríamos 70 pessoas, o que já é um número considerável. Nestas estruturas começa a fazer sentido ter um chief product owner e um chief scrum master a quem reportam todos os outros product owners e scrum masters das equipas individuais. Dependendo da dimensão, pode também fazer sentido aplicar umas das metodologias que te falei acima (SAFe, DAD ou LeSS).

 

Em outros artigos espero vir a poder-te falar um pouco mais sobre todo este mundo.

 

Até à próxima :)

 

 

 

 

 

 

 

 

 

05
Fev20

Gestão de portfólios de projetos

Luís Rito

Olá :)!

 

Hoje voltamos a temas mais relacionados com projetos, neste caso, gestão de portfólios de projetos. Esta é uma disciplinina ainda pouco utilizada nas empresas, pelo menos quando aplicada da forma mais madura. A gestão de projetos banalizou-se muito nos últimos anos, qualquer empresa já percebeu que necessita de projetos, quer para manter uma excelência operacional, quer para preparar o seu futuro. Por outro lado, a gestão de portfólios de projetos ainda está a tentar acompanhar a evolução que ocorreu ao nível da gestão de projetos. Existe muita confusão nesta área, muitos pensam que uma gestão de portfólio é ter a capacidade de gerir múltiplos projetos e já está! Na realidade, uma correta gestão de portfólio de projetos ambiciona por muito mais. O seu grande objetivo é maximizar o contributo dos projetos de forma a perseguir e atingir com sucesso os objetivos da empresa. Isto significa o seguinte:

 

Projectos devem estar alinhados com os objetivos e estratégia da empresa - Se por exemplo uma empresa define um objetivo de trabalhar na sua experiência cliente, então é óbvio que vai tentar maximizar projetos que contribuam diretamente para o incremento desse objetivo. Ao existir uma correta gestão de portfólio, projetos candidatos a serem realizados são confrontados com o que é a estratégia da empresa, e os que não estão alinhados não chegam a ser iniciados. É preferível ter um pipeline anual de projetos curto do que ter múltiplos projetos que não estão alinhados ou que ficam "meio-feitos".  

 

Projetos devem ser consistentes com a cultura e valores da empresa - Muito semelhante ao ponto de cima. Já vivi experiências em grandes empresas onde um projeto arranca e segue para a frente porque um executivo assim o exige (mesmo quando o projeto não está alinhado com os objetivos da empresa). O processo de seleção de projetos deve conter critérios que permitem atribuir classificações a cada projeto candidato, facilitando assim a escolha de em quais a empresa se deve focar em primeiro lugar.

 

Projetos devem contribuir (direta ou indiretamente) para um cash-flow positivo na empresa - Os projetos existem para criar valor na empresa, portanto é fundamental que todos eles tragam alguma espécie de valor acrescentado relativamente ao que já existe. Os projetos devem conter um business case onde se perceba qual o benefício que a empresa terá na sua implementação, bem como quais os custos de CAPEX (custos de investimento) e OPEX (custos de operação) que terá de suportar. Alguns projetos podem ter benefícios mais intangíveis como por exemplo a notoriedade da marca ou a satisfação dos colaboradores. No livro da bibliografia de Tim Cook, este fala muito de projetos que visam aumentar a sustentabilidade da empresa, e nesses casos não se olha para ROI´s e afins, faz-se apenas o que está certo para a melhoria do nosso meio ambiente. Claro que neste caso um dos objetivos estratégicos da Apple é exatamente melhorar a sustentabilidade da empresa, pelo que projetos que encaixam nessa categoria têm uma probabilidade mais elevada de serem aprovados. Todos os demais, necessitam de um business case que justifique quanto a empresa vai lucrar com a sua execução. É por isso fundamental medir em quanto o cash-flow da empresa melhorou com a execução do projeto, obrigando assim à realização de medições após a sua implementação. Não se pode implementar um projeto e assumir que já deu benefício, é vital medir quanto foi na realidade.

 

Múltiplos caminhos para o sucesso de um portfólio

 

Projetos devem utilizar da forma mais eficaz os recursos da empresa (quer pessoas quer outros recursos como dinheiro) - Todas as empresas têm recursos limitados, pelo que a lista de projetos que deve constar num portfólio deve ser escolhida de forma a maximizar a utilização dos recursos da empresa. Por exemplo, no caso de recursos financeiros, algumas empresas têm um budget anual definido para projetos, pelo que deve ser escolhido de uma forma muito criteriosa onde esse dinheiro será investido. De certa forma é muito similar a um portfólio financeiro, onde se investe o dinheiro na expectativa de o puder multiplicar quando aplicado nos ativos certos. Com os projetos é igual, no momento zero é definida uma lista de projetos onde se vai investir o budget, sendo que de seguida deve ser definido quanto se espera ganhar com a sua realização. Claro que durante o ciclo de vida do portfólio o mais provável é que as pessoas que o gerem tenham que iniciar projetos novos ou cancelar alguns onde se verifica que os benefícios atuais estão fora do que era esperado. Como podes ver, muito semelhante a um portfólio financeiro onde por vezes temos de vender posições menos boas para adquirir outras.

 

Projetos devem contribuir não apenas para a eficiência e saúde atual da empresa mas também para a preparação do futuro - Os portfólios têm que garantir a excelência atual da empresa mas também preparar o seu futuro. Isto significa que devem ser definidos limites para cada um desses tipos de projeto. Por exemplo, se uma empresa aposta num determinado ano em excelência operacional, pode escolher investir 70% do seu budget em projetos de melhoria contínua e apenas 30% em projetos transformadores. Já uma empresa que vive de inovação pode inverter e escolher mais projetos diferenciadores e menos projetos de "manter as luzes acessas". Um portfólio que apenas invista em projetos de melhoria contínua não se está a preparar para o futuro, sendo que a empresa que o está a executar corre um sério risco de ser ultrapassada pela concorrência nos anos seguintes. É por isso que deve existir um balanceamento saudável entre ambos os tipos de projetos. Ao longo do ano é possível rebalancear o portfólio, ou seja, reduzir um tipo de projetos em detrimento de outros, e aqui faço mais uma vez o paralelismo com um portfólio financeiro, onde podes por exemplo ter uma divisão entre ações e obrigações, e consoante a estratégia de investimento investe-se mais numa categoria de ativos do que noutra.

 

Bom, espero que tenha conseguido transmitir quais as bases do que deve ser uma correta gestão de portfólio. Em outros posts vou mergulhar mais neste tema.

 

Obrigado por leres e até à próxima!

 

 

 

 

29
Dez19

O PMP ainda vale a pena?

Luís Rito

Para quem não conhece, o PMP é um acrónimo de "Project Management Professional", e trata-se de uma das certificações em gestão de projetos mais reconhecida no mercado. Esta certificação é atualmente ministrada pelo PMI (Project Management Institute), instituto sem fins lucrativos que tem como objetivo a profissionalização e criação de standards na gestão de projetos.

 

A certificação PMP incide maioritariamente em projetos tradicionais, também conhecidos como projetos waterfall, motivo pelo qual tem sido alvo de algumas críticas, nomeadamente sobre se esta ainda se encontra adequada ao mundo real. Nos dias que correm a popularidade do agile tem sido exponencial, não existe empresa que apregoe agilidade que não fale em metodologias de gestão de projeto agile. O PMP baseia-se no PMBOK (Project Management Book of Knowledge), que é um conjunto de boas práticas de gestão de projetos, que apesar de bastante completo, é também bastante complexo e muito mal interpretado. O livro encontra-se dividido em diferentes áreas de conhecimento (prometo fazer um artigo mais à frente para falar disto), estando estas inseridas dentro do ciclo de vida de um projeto. Este ciclo de vida subdivide-se em cinco fases, iniciação, planeamento, execução, monitorização & controlo e encerramento. 

 

O primeiro erro que muitas pessoas comete é pensar que todas as fases que te falei acima ocorrem em sequência, ou seja, apenas podemos realizar planeamento após iniciação concluída, apenas podemos começar a execução após fecho do planeamento e por aí em diante. Essa não é a realidade, as fases podem e devem sobrepôr-se, por exemplo, podemos começar a executar um projeto ainda que todo o planeamento não esteja encerrado. Tudo vai depender do tipo de projeto, e não da metodologia em si. Por exemplo, se o projeto diz respeito à construção de uma ponte ou de um edifício, parece-me que faz sentido dispender mais tempo na fase de planeamento e apenas avançar para a execução após fechar grande parte do planeamento. Contudo se estamos a falar de projetos de software, esta prática já não deve ser aplicada, já que existe uma forte probabilidade das coisas mudarem durante a fase de execução. É portanto errado afirmar que a metodologia do PMI é rígida e pouco ágil, nada no PMBOK diz que temos que seguir todos os passos à risca. Um projeto gerido de acordo com as boas práticas do PMI pode ser ágil se o gestor de projeto assim o entender. 

 

PMI

 

Para terem ideia, para passares no PMP necessitas de realizar um exame com 200 perguntas e 4h de duração, onde te questionam sobre mil e um documentos que um projeto pode ter. O PMBOK prepara os gestores de projeto para os projetos mais complexos, mas dá ferramentas e incentiva a efetuar um processo de tailoring de forma a adaptar a metodologia ao tipo de projeto que estás a gerir. Se o PMP ainda vale a pena nos dias que correm? Sem dúvida que sim! Posso afirmar que pela dificuldade do exame, tive que estudar bastante, o que fez com que aos dias de hoje ainda me lembre da maior parte dos temas. O PMI na minha opinião faz um trabalho excecional na criação de standards, que permite aos gestores de projeto comunicarem e utilizarem os mesmos termos e expressões. O facto do PMBOK ser um conjunto de boas práticas reconhecidas amplamente pelo mercado significa que ao aplicares essas técnicas tens uma maior probabilidade de levar os teus projetos a bom porto. Outra grande vantagem é o facto de ser uma certificação altamente reconhecida no mercado, o que te pode ajudar a ter melhores oportunidades de emprego. Por enquanto ainda continua a ser a certificação de referência no que toca a gestão de projetos.

 

A minha recomendação é, não sejas demasiado rígido, encara o PMBOK como guidelines para poderes construir modelos de governo e metodologias específicas para os teus projetos. A mensagem que quero passar é que é possível seres ágil aplicando técnicas como por exemplo "Rolling-wave" (planear em waves, ou em pequenos incrementos) ou "Progressive Elaboration" (plano é continuamento atualizado e melhorado à medida que nova informação se revela). Se queres levar a tua gestão de projetos para um nível mais profissional aconselho vivamente a tirares a certificação PMP

 

Por hoje é tudo, até à próxima.