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

O Gestor de Projeto Moderno

O Gestor de Projeto Moderno

31
Mar19

Qual o teu mindset?

Luís Rito

Hoje quero falar-te sobre um tema que vai certamente dividir opiniões.

Vou falar-te de Growth Mindset e de Fixed Mindset.

 

Se ainda não ouviste falar sobre nada disto, ter uma Fixed Mindset significa que acreditamos que a nossa inteligência já nos foi "atribuída" quando nascemos. Tipicamente, pessoas com este tipo de mindset acreditam muito no talento, ou seja, é normal ouvirmos da sua boca que se um indivíduo alcançou muito sucesso na sua carreira profissional, provavelmente "nasceu para aquilo". Este tipo de pessoas normalmente tenta parecer muito inteligente em grupo, pois como acredita que cada um nasce com uma inteligência pré-definida, abomina que outros pensem que se trata de uma pessoa limitada.

 

Em contraste, uma pessoa com uma Growth Mindset acredita que pode aprender o que quer que seja, necessitando para isso de investir trabalho e esforço diário. Este tipo de pessoas não necessita de se mostrar inteligente perto dos outros, já que, sabe o seu valor e percebe também que embora não domine um tema, é uma questão de tempo até o fazer.

 

Feita esta pequena introdução, pessoalmente identifico-me como uma pessoa com Growth Mindset. Nem sempre fui assim, muitas vezes dei por mim a desistir de temas que não compreendia ou que achava difíceis. Nessa altura acreditava muito no talento ou em capacidade inatas. Hoje apercebo-me que não insisti suficientemente nesses temas, acabei por desistir ao deparar-me com as primeiras dificuldades. De à uns anos para cá mudei radicalmente a minha forma de pensar, e meti na cabeça que poderia alcançar tudo o que me predispusesse a aprender. Desde esse dia que posso afirmar que a minha vida mudou de forma radical, já que passei a assumir os fracassos como culpa minha. Se fui incapaz de passar num exame importante, a culpa não é da minha fraca inteligência nos temas apresentados no exame, apenas não investi o tempo necessário no seu estudo.

 

Não digo que somos todos iguais, na realidade existem coisas que nos fascinam mais que outras, mas isso nada tem a ver com talento. Significa apenas que nunca vamos ser fantásticos em algo que gostamos menos, já que não vamos conseguir investir centenas de horas na sua prática.

 

Recomendo-te dois livros onde podes ler mais sobre este tema, um deles do Matthew Syed, de nome Bounce: The Myth of talent and the power of practice e outro do Malcolm Gladwell chamado Outliers. Em ambos os livros os autores explicam em detalhe que o talento não passa de muitas horas de treino focado e direcionado, bem como do contexto onde nos encontramos.

 

Por exemplo, no livro de Matthew Syed, o autor fala de como numa única rua de uma cidade nasceram tantos campeões de ténis de mesa. Qual a probabilidade de teres vários campeões numa única cidade? Na realidade, nada tem a ver com talento, mas sim de existir um clube onde algumas pessoas se juntavam diariamente para jogar ténis de mesa durante várias horas. Dia após dia, ano após ano, todos eles foram ficando cada vez melhores, e por estarem todos ao mesmo nível incentivou-os a melhorar sempre um pouco mais para que pudessem vencer os seus adversários. Um dia quando se aperceberam eram uns dos melhores do mundo. Tratou-se nada mais nada menos que um contexto desafiante e prática diária durante vários anos.

 

Dou outro exemplo, quando em Silicon Valley de repente apareceram tantas startups inovadoras a nível tecnológico, pergunto, estariam todas as grandes mentes dos EUA em Silicon Valley? Claro que não. É mais um caso onde o contexto onde as pessoas estão inseridas as ajuda a florescer e a ambicionar por mais. Se o teu grupo de amigos é composto por 99% de pessoas empreendedoras, arrisco-me a dizer que mais dia menos dia te vais transformar também em um empreendedor.

 

Nunca penses que tens menos inteligência que alguém. Se queres ser melhor a fazer algo, identifica esse gap no teu conhecimento e traça um plano para diminuíres esse gap através de horas de prática bem direcionada. Quando o gap for inexistente, traça um novo objetivo e começa de novo. Ao preencheres pequenos gaps uma e outra vez, estás a tornar-te cada vez melhor e prometo que um dia te vais tornar um dos melhores.

 

crescimento_espiritual.jpg

 

Quando te falo em treino bem direcionado, refiro-me ao facto de te teres de colocar um pouco fora da tua zona de conforto e ires tentando alcançar o teu objetivo, sempre sem medo de falhar, já que uma pessoa com Growth mindset sabe que os falhanços são oportunidades fantásticas para aprender. Se com cada falha aprendermos algo, estamos a tornar-nos mais fortes, como um músculo após uma sessão árdua de treino no ginásio. Só depois de destruído o músculo cresce mais forte.

 

Este crescimento é sempre desconfortável. Ainda te lembras quando aprendeste a conduzir? Aposto que tinhas que pensar mil vezes sobre tudo o que tinhas que fazer em simultâneo. Colocar a embraiagem a fundo, com o pé esquerdo e manter o pé direito no travão para o carro não descair numa subida. Ao mesmo tempo com a mão direita colocas uma mudança e com a esquerda pegas no volante. Com tanta coisa até de esqueces que devias estar a olhar para o espelho retrovisor, não vá estar um carro colado a ti e se te descuidas bates nele. Aposto que durante tudo isto o teu cérebro estava a trabalhar furiosamente para conjugar todas estas ações. Com a prática, hoje em dia fazes tudo isso e nem precisas de pensar, muitas vezes damos por nós em "piloto automático" nas deslocações casa-trabalho e trabalho-casa.
Isto acontece porque te colocaste no desconforto de aprender algo novo, e praticaste até um nível onde executas sem pensar, estás a utilizar as centenas de horas de treino que já investiste na prática de conduzir um carro.

 

Se conseguires vencer esta parte desconfortável que é aprender algo novo, e fores consistente e perseverante, vais conseguir o tão ambicionado crescimento. Não existe nada que não consigas fazer, desde que queiras 🙂.

 

Por hoje é tudo e até à próxima!

 

23
Mar19

Afinal o que é um PMO e para que serve?

Luís Rito

Esta é uma questão que surge na cabeça de várias pessoas que têm um PMO na sua empresa. Infelizmente, existe uma grande confusão acerca do que é, e quais as suas responsabilidades.
Muitos vão afirmar com muita convicção que um PMO não serve para nada, afinal, quem necessita de indivíduos na sua empresa onde a sua principal função é verificar se o trabalho já está ou não feito?

 

Interessa desde já desmistificar o que é um PMO. Em algumas empresas trata-se de uma pessoa, enquanto em outras é um departamento inteiro. Segundo o Project Management Institute (PMI), um PMO pode ser descrito da seguinte forma:

 

"A management structure that standardizes the project-related governance processes and facilitates the sharing of resources, methodologies, tools, and techniques".

 

O PMO é também conhecido como "Project Management Office", e não "Project Management Officer". Isto significa que por norma deveria ser composto por um conjunto de profissionais com competências heterogéneas.

 

pmo-para-projetos-de-manufatura.jpg


Pessoalmente, acredito que um PMO deve estar localizado o mais próximo possível dos executivos da empresa, já que uma das suas principais responsabilidades deve ser ajudar na concretização da estratégia da empresa através da execução de projetos.

 

Considero ser esta a principal responsabilidade de um PMO, mas outras deverão ser:

 

  • Criar e desenvolver a metodologia e modelo de governo de projetos dentro da organização, atingindo assim standards comuns na gestão de projetos;
  • Desenvolver atividades de coaching, mentoring e formar as pessoas da empresa na prática de gestão de projetos;
  • Fornecer software de gestão de projetos adequado, para que os gestores consigam realizar o seu trabalho com o máximo de eficiência, dando ainda visibilidade às equipas e gestão acerca do estado de cada um dos projetos;
  • Gestão do portfólio de projetos, garantindo o seu alinhamento com os objetivos da empresa;
  • Coordenar e facilitar a comunicação entre projetos;
  • Gerir conflitos de recursos entre projetos concorrentes;
  • Comunicar de forma imparcial o estado do portfólio, e sugerir alterações de uma forma estruturada, por exemplo, terminar um projeto que já não se justifica ou que esteja com um mau desempenho;
  • Garantir que os standards de gestão de projetos são cumpridos;
  • Agilizar a gestão da mudança dentro da empresa.

 

Algumas das responsabilidades que referi acima podem não ser exclusivas de um Project Management Office, já que existem algumas empresas onde existe um Program Management Office e um Portfolio Management Office. Isto significa que em algumas realidades, um PMO não executa qualquer tipo de trabalho estratégico ao nível do portfólio, ficando essa tarefa a cargo do Portfolio Management Office. Considero que essa divisão apenas é necessária em empresas com uma grande dimensão, e acho benéfico centralizar todas essas responsabilidades numa única direção. Ao centralizar minimiza-se o risco de adoção de múltiplas metodologias de gestão de projeto, e ficam garantidos os standards.

 

Composição de um PMO de média/grande dimensão

 

Um PMO de uma grande empresa jamais poderá ser administrado por apenas umas pessoa. Quando falamos de milhões de euros de investimento em projetos e várias dezenas de projetos em curso, a composição de um PMO deveria assemelhar-se às funções descritas abaixo.

 

Diretor do PMO

 

Como em todas as direções, considero que a figura de um diretor é essencial. Esta figura deve acima de tudo assumir uma postura muito política dentro da empresa. Deve ter a capacidade de expandir uma gestão de portfólio na empresa, sempre alinhada com os objetivos estratégicos. Deve ser uma pessoa muito credível e com capacidade de apresentar resultados de uma forma consistente. Será sempre a pessoa que comunica diretamente com os quadros executivos.

 

Gestores de projetos & programas

 

Este ponto não obtém consenso junto da comunidade de gestão de projeto. Muitos consideram que um PMO não deve ter gestores de projetos/programas debaixo do seu chapéu. Na minha opinião é benéfico, pois é possível centralizar conhecimento e definir standards de trabalho. Para mim um PMO deve ter os melhores gestores de projeto na sua estrutura, sendo que devem ser posicionados nos projetos mais estratégicos da empresa. Para projetos com menor criticidade, considero que podem ser geridos pelos chamados gestores de projeto acidentais, ou seja, pessoas que mesmo sem formação prévia de gestão de projetos são destacadas para certas iniciativas. Em algumas empresas onde existem centenas de projetos em curso, a alocação dos poucos gestores de projeto do PMO deve ser cirurgicamente atribuída.

 

Suporte administrativo

 

Na minha opinião, os gestores de projetos e programas devem estar totalmente focados na própria gestão dos seus projetos, ou seja, gerir riscos, gerir expectativas, resolver problemas, motivar a equipa, etc. Para garantir isso, as tarefas mais administrativas devem estar a cargo de pessoas responsáveis pelo suporte administrativo.

 

Algumas das tarefas que podem cair nestre grupo são:

 

  • Construção de relatórios de ponto de situação;
  • Recolha de informação analítica de projetos;
  • Suporte ao software de gestão de projetos;
  • Formação;
  • Quality assurance;
  • Desenvolvimento da metodologia de projetos;
  • Gestão de informação histórica, como por exemplo lições aprendidas;
  • Gestão de recursos, de forma a informar o gestor de projeto quando pode ou não ter pessoas disponíveis para os seus projetos.

 

Deixo a nota que a estrutura que apresentei acima é mais adequada para grandes empresas. Pequenas empresas com um pequeno número de projetos em curso poderá juntar várias funções em uma pessoa apenas. Por exemplo, o gestor de projeto tem também sob a sua responsabilidade executar todas as tarefas administrativas, com todos os riscos que daí advém, como por exemplo, falta de tempo para executar tarefas de valor acrescentado.

 

Por agora é tudo, espero que tenhas ficado com uma ideia mais clara do que deve fazer um PMO, e qual a sua composição. Até à próxima, e até lá, boas leituras!

 

18
Mar19

To SCRUM or not to SCRUM

Luís Rito

“Não está nos requisitos”, tornou-se uma das frases mais faladas por um gestor de projetos nos dias que correm, principalmente se este utiliza Waterfall como metodologia de gestão de projetos. Para quem não sabe, a metodologia Waterfall pressupõe que antes de começar qualquer tipo de desenvolvimento, todos os requisitos devem estar perfeitamente fechados e aceites pelo cliente. Trata-se portanto de um processo linear, isto é, primeiro são definidos requisitos, é depois criada uma work breakdown structure (WBS), as equipas de projeto elaboram estimativas para as tarefas a serem executadas e por fim o gestor de projetos constrói o plano de projeto com tarefas, durações, precedências, atribui recursos e calcula quando é que o projeto vai terminar e quanto vai custar. De uma forma muito simplista, é isto que acontece num típico projeto Waterfall. Deixo só a nota que nem sempre é assim, pois podemos utilizar técnicas de planeamento como por exemplo elaboração progressiva ou rolling-wave, mas deixo a explicação dessas técnicas para outras núpcias. 

 

Hoje quero falar-vos de outro tipo de projetos, os projetos de software. Normalmente, e salvo algumas exceções onde os projetos podem ser críticos (por exemplo software de uma central nuclear, ou de um foguetão da NASA), a grande maioria do software produzido não apresenta graus elevados de criticidade. Isto faz com que os requisitos sejam alterados à medida que o projeto vai decorrendo, seja porque o negócio ou o mercado evoluiram, seja porque deixam de fazer sentido algumas funcionalidades que inicialmente se achavam fundamentais.

 

O ciclo de vida de um software é cada vez mais curto, impõe-se mudança constante, e as empresas têm que se adaptar continuamente de modo a não ficarem para trás. Não faz sentido que o desenvolvimento de um software leve tanto tempo como leva nos dias de hoje. É recorrente empresas gastarem meses ou anos na atualização ou construção de um software. Isso torna-as mais frágeis comparativamente aos seus adversários.

 

É por isso que muitas empresas se voltam para metodologias mais ágeis na gestão dos seus projetos. A gestão de projetos ágil transforma o processo em algo não linear, e por via de múltiplas iterações vai-se melhorando ao longo do tempo. Assim, fará sentido adoptar metodologias ágeis quando existe muita incerteza nos requisitos, quando é necessário realizar entregas de uma forma incremental ou quando é muito importante obter um experiência de utilizador verdadeiramente adaptada às necessidades do cliente. A metodologia que vos vou falar hoje é uma das mais famosas em todo o mundo, vou falar-vos de SCRUM.

 

agile.png

 

Outra forma de trabalhar?


O SCRUM baseia-se em três grandes pilares, a transparência, inspeção e adaptação:

 

Transparência – Este pilar dita que deve existir uma visão clara e comum de quais os objetivos do projeto por todos os interessados neste. Um grande exemplo de transparência seria a criação de uma definição comum do que significa “tarefa realizada”, já que por vezes um stakeholder entende que uma tarefa já se encontra realizada enquando outro não concorda com essa mesma definição.

 

Inspeção – Este pilar dita que durante o decorrer do projeto sejam realizadas inspeções ao trabalho numa base regular, com o grande objetivo de perceber como o projeto se encontra a evoluir, e se existem desvios a considerar ou possíveis alterações aos objetivos do projeto.

 

Adaptação – Este pilar dita que é fundamental ajustar e adaptar o processo. Se numa inspeção se detetar que existem problemas que podem ser corrigidos, ou se verifique por exemplo que o objetivo do projeto mudou devido a alteração de tendências no mercado, deve-se refletir essa nova realidade.


As equipas de um projeto SCRUM são normalmente compostas por uma Development Team, um Product Owner e um ScrumMaster.

 

Development Team – De uma forma simples, é a equipa responsável por realizar todas as tarefas necessárias para completar o trabalho necessário (análise, desenvolvimento e testes);


Product Owner – É a pessoa responsável por gerir o product backlog (explicado mais à frente), incluindo a sua priorização, precisão, visibilidade e compreensão comum por toda a equipa;


ScrumMaster – Responsável por assegurar que as boas práticas de SCRUM estão asseguradas e que são realizadas. Normalmente deve ser um líder para a Development Team, removendo obstáculos, facilitando eventos e fornecendo coaching. Para além disso, também deve auxiliar o Product Owner na gestão do backlog, comunicando sempre ao máximo a visão e objetivos à Development Team.


Eventos


A metodologia SCRUM é composta por várias atividades, também chamadas de eventos. Alguns exemplos são os sprints, as sprint planning meetings, os daily scrums, as sprint review meetings e as sprint retrospectives.

 

1) Sprints


Um sprint pode ser considerado um mini projeto dentro do projeto global. Tem uma duração limitada (por exemplo duas ou três semanas), sendo que durante o sprint não existe rotação da development team. No fim do sprint, tem que existir sempre um produto final (por exemplo um módulo do projeto global). O próprio sprint inclui a sprint planning meeting, daily scrums, a sprint review meeting e a sprint retrospective.

 

2) Sprint Planning Meeting


A sprint planning meeting tem como principal objetivo determinar o que será entregue no fim do sprint, e de que forma será realizado o trabalho. O product owner apresenta todos os items ainda em backlog, e toda a equipa os discute a fim de obter um entendimento comum do que falta realizar. A development team deve então estimar o que poderá ser entregue no sprint para que se consiga obter os seus objetivos. Por fim a development team deve ainda definir como vai ser atingido o objetivo, e como se vai organizar para o atingir.

 

3) Daily Scrum


A daily scrum trata-se de uma reunião diária de 15 minutos. Durante esta sessão a development team deve trocar informação acerca das atividades e dos problemas que possam ter surgido. Normalmente, cada membro da equipa deve responder às seguintes três perguntas:

 

O que realizei desde a última reunião?
O que será realizado até à próxima reunião?
Que obstáculos encontrei?

 

O ScrumMaster deve-se certificar que esta reunião acontece diariamente, e que é útil na resolução de problemas.

 

4) Sprint Review


Trata-se da reunião que decorre no fim do sprint, com o objetivo de verificar o impacto deste no projeto global, bem como realizar alterações ao backlog se necessário. Normalmente a development team demonstra o que foi realizado no sprint, e o product owner em conjunto com o cliente verificam se vai de encontro às suas necessidades. Seguidamente, o product owner e a development team devem olhar para os restantes items em backlog e determinar de uma forma macro o que fazer no próximo sprint.

 

5) Sprint Retrospective


É nesta sessão que existe oportunidade para melhorias dentro do próprio processo. No fim de cada sprint a equipa deve refletir sobre o processo, por exemplo, o que correu bem ou o que podia ser melhorado. A equipa deve ainda focar-se nos stakeholders, relações, processos e ferramentas. Caso existam oportunidades que mereçam ser exploradas, é aqui que devem ser levantadas.

 

Artifacts


Discutidas as atividades existentes na metodologia, resta referir ainda os entregáveis, isto é os artifacts. Existem vários tipos de artifacts, como por exemplo o product backlog, o sprint backlog e a definition of done

 

1) Product Backlog


Trata-se de uma lista ordenada de tudo o que ainda é necessário realizar para a conclusão do projeto, e funciona como uma fonte única de requisitos. O backlog pode evoluir consoante o projeto evolui, isto é, caso as necessidades do cliente ou do mercado mudem. Desta forma deixamos de ter um âmbito tão fechado e existe abertura para adaptar o produto às reais necessidades do cliente. O backlog deve ainda conter melhorias e correções que foram sendo identificadas ao longo do projeto. Items com prioridade mais alta devem ter mais detalhe, com estimativas mais precisas. Items com menor prioridade podem ser desenvolvidos ao longo do tempo.

 

2) Sprint Backlog


Tratam-se de todos o items do backlog que são selecionados para um determinado sprint.

 

3) Definition of Done


Toda a equipa tem que concordar no que significa “tarefa realizada”. Para que não exista ambiguidade entre os elementos da equipa, deve ser trabalhada a noção do que significa “tarefa realizada”. Essa definição deve ser definida por toda a equipa, e antes do trabalho iniciar.

 

Conclusões


A mensagem que se pretende passar com este artigo é que nem sempre é adequado optar pela metodologia Waterfall. Existe uma frase muito famosa de Henry Ford que diz:

 

“If you always do what you’ve always done, you’ll always get what you’ve always got.”

 

Sendo que a grande maioria dos projetos de software derrapa, pode ser proveitoso dar uma oportunidade a este tipo de metodologias mais ágeis e verificar os resultados. Dei-te uma visão muito superficial do que é o SCRUM, mas existem muitas outras que merecem ser exploradas, como por exemplo, Extreme Programming (XP), Feature-Driven Development (FDD), Dynamic Systems Development Method (DSDM), Crystal ou Lean Software Development.

 

Caso se deparem com projetos em que a mudança é constante ou onde os requisitos não se encontram perfeitamente definidos, pode ser uma oportunidade para introduzir uma metodologia ágil. Nunca esquecer ainda que é vital o envolvimento do cliente, principalmente no fim de cada sprint, de forma a verificar se o que foi realizado vai de encontro ao que é esperado. 

 

Em breve falo-vos mais sobre agile, temos muito para aprofundar :).

 

 

13
Mar19

Guiar a inovação

Luís Rito

Inovar é considerado por muitos como uma forma de criar novos produtos e serviços. Durante alguns anos foi essa a definição de inovação mais conhecida pelo público em geral. Contudo, inovar é mais que lançar um novo produto para o mercado, ou redefinir um serviço de uma forma diferente. A inovação já não é unicamente da responsabilidade dos departamentos de I&D, mas sim de toda a organização e meio envolvente relevante.

 

Assim, é normal que a definição de como inovar tenha evoluído. É certo que a inovação ligada ao desenvolvimento de novos produtos e serviços continua a ser relevante e importante, contudo é possível inovar também ao nível dos processos, mercados e modelo de negócio.

 

Inovar em produtos e serviços


Uma das formas mais tradicionais de inovar é em produtos e serviços. Lançar um novo modelo automóvel após alterar o seu design, ou um novo modelo de computador com um processador mais rápido são formas de inovar ao nível do produto. Já a inovação ligada ao serviço, pressupõe que existe algum tipo de incremento de valor ao nível dos serviços que a empresa oferece. Por exemplo, a forma como os serviços de televisão nos oferecem a possibilidade de ver programas do passado, isto é que já foram transmitidos, resulta numa grande inovação relativamente ao serviço que anteriormente existia. Desta forma o utilizador tem total controlo sobre o que deseja ver e quando quer ver. A maioria das empresas realiza este tipo de inovação com muita regularidade e de forma incremental.

 

Inovar em processos


Inovar ao nível de processos é uma boa forma de conseguir aumentar a produtividade ou reduzir os custos. Um exemplo perfeito de inovação ao nível de processos é o Walmart. É considerada uma das maiores empresas de retalho do mundo, com 11000 lojas espalhadas em 28 países. Durante vários anos o Walmart tem executado um conjunto de inovações ao nível dos seus processos, com o grande objetivo de aumentar a eficiência e reduzir os seus custos. O Walmart consegue criar previsibilidade na procura dos seus produtos, garantindo que estes se encontram no lugar certo, à hora certa, na quantidade certa e com o menor custo possível. Ao utilizar de uma forma intensiva as tecnologias de informação o Walmart consegue uma maior integração entre o fornecedor e cliente, permitindo assim grandes trocas de informação e redução de risco ao nível da tomada de decisão. Este processo foi continuamente aperfeiçoado via centenas de inovações que foram sendo implementadas ao longo dos anos.

 

Inovar em mercados


Inovar ao nível do mercado pode ser feito de várias formas. Alguns exempos são, inovar ao nível da marca, ao nível do Customer Experience, ou por exemplo satisfazer novas necessidades com os produtos que a empresa já dispõe.

 

Ao nível da marca, tudo se resume à forma como a empresa transmite o benefício que oferece aos seus clientes. A Nike fez um excelente trabalho nesse sentido quando decidiu reposicionar a sua marca para o mercado feminino. Com esta inovação ao nível da marca, a Nike conseguiu aumentar em muito as suas receitas, sendo ao mesmo tempo percepcionada como uma marca para todos os desportistas, homens e mulheres.

 

Inovar ao nível do Customer Experience, resume-se a criar uma experiência o mais completa possível para os seus clientes. Um exemplo perfeito foi o que a Lego fez a um menino. Luka, de 7 anos de idade, gastou todo o seu dinheiro ao comprar um “Ninjago” da Lego (boneco especial). Contra a vontade do seu pai, Luka levou o boneco numa ida ao supermercado, e caiu do seu casaco, perdendo-o para sempre. Luka decidiu enviar uma carta para a Lego a explicar a sua história, e a prometer que se tivesse outro boneco nunca mais o levaria para as compras, jurando protegê-lo todos os dias. A resposta da Lego foi criativa e fascinante, não só lhe deram um novo boneco como responderam impersonando uma figura “Ninjago” (Sensei Wu), dizendo ainda:

 

“Just remember, what Sensei Wu said: keep your minifigures protected like the Weapons of Spinjitzu! And of course, always listen to your dad”.

 

5bf144311aeaba6fa29c7f0fea237f6b.jpg

 

Quanto a satisfazer novas necessidades com os produtos atuais, um bom exemplo é o caso da Nintendo, que em tempos com a sua Wii fitness conseguiu através de um produto já existente satisfazer necessidades de um conjunto de indivíduos que se interessam em manter uma boa forma física, ao mesmo tempo que se preocupam com a sua saúde.

 

Inovar em modelo de negócio


Inovar ao nível do modelo de negócio pode ser uma forma muito proveitosa de conseguir resultados nunca antes obtidos pela empresa. A forma como a Google começou a disponibilizar muitos dos seus serviços e produtos de uma forma completamente gratuita, agitou por completo o mercado. Hoje em dia é normal uma empresa não cobrar nada pelo seu produto, mas em contrapartida conseguir gerar resultados através de serviços. Também é possível inovar ao nível do canal, isto é, como ligar a oferta com os clientes. A Amazon fez um trabalho brilhante ao possibilitar ao cliente o acesso a um número quase ilimitado de livros através do conforto do seu lar. De uma forma semelhante, a Dell ao contrário da sua concorrência, permitiu aos seus clientes configurar cada um dos componentes do seu futuro PC, tudo isto a um preço mais baixo, devido à excelente gestão de stocks que a empresa dispunha (just-in-time).

 

Conclusões

 

A inovação já não é algo específico do departamento de I&D, e já não se trata apenas de criar novos produtos & serviços. As empresas podem inovar de múltiplas formas, sendo que estar suficientemente atento ao que os seus clientes pretendem é uma das melhores formas de direcionar a inovação para o lugar certo. É possível inovar ao nível dos produtos, serviços, processos, modelo de negócio e mercados. Resta à empresa perceber quanto da sua inovação deve direcionar para cada um destes quadrantes.

 

Nos dias que correm não existe opção, ou se inova ou se é ultrapassado pela concorrência, e todas as empresas têm pontos onde podem melhorar. Resta fazer acontecer!

 

10
Mar19

Focar na excelência

Luís Rito

Quantos de nós já ouvimos a célebre frase "Quais as suas fraquezas, e como as podemos melhorar"?

 

Grande parte de nós já ouviu pelo menos uma vez esta frase, seja em contexto académico, seja em contexto profissional. A realidade é que a maioria dos processos de avaliação de desempenho se focam no que fazemos menos bem, somos constantemente incentivados a trabalhar nas nossas fraquezas.

Não digo que isso esteja de todo errado, é absolutamente necessário fazer mais e melhor, evoluir um pouco todos os dias. Contudo, deixo a questão, e se estivermos a investir o nosso bem mais preciso (tempo) em algo que vai acabar por não nos compensar?

 

E se ao invés da pergunta "Quais as suas fraquezas, e como as podemos melhorar", fizéssemos a seguinte, "Quais os seus pontos fortes e como os podemos amplificar"?

 

Ao inverter o foco, evoluímos de um profissional que eventualmente irá melhorar em algo onde é menos bom, situando-se futuramente na média, para um profissional que amplificou um skill onde já era forte e atingiu um grau de expertise muito superior à maioria dos profissionais. Acabamos com o perfil de profissional mediano para um especialista num determinado assunto, obtemos profissionais que são procuradas por outras pessoas pelo valor que acrescentam sobre um determinado tema.

 

se-banner.jpg

 

Com esta abordagem, consegue-se ainda colaboradores fiéis à empresa onde trabalham. Arrisco-me a dizer que vamos conseguir pessoas mais felizes e realizadas por fazerem aquilo que realmente gostam. Com isto, não digo que seja possível durante 100% do nosso tempo realizar tarefas que nos agradam e em que brilhamos, mas o objectivo é que essa percentagem seja superior à percentagem de tarefas que não nos dão aquela sensação de estarmos vivos.

 

Primeiros passos para a mudança


Agora que sabemos que focar nos nossos pontos fortes poderá ser mais benéfico que focar nas nossas fraquezas, que fazer?

 

O primeiro desafio passa por perceber e identificar como os seus pontos fortes o podem ajudar na sua função actual. Já utiliza os seus pontos fortes várias vezes por semana? Utiliza-os apenas numa fracção do seu tempo? Contabilize, é o primeiro sintoma que algo está ou não errado. Tente realizar mais tarefas onde vai brilhar.

 

O segundo desafio consiste em procurar novos sistemas e técnicas que podem cimentar ainda mais os seus pontos fortes. Já é óptimo em gestão de projecto? Vá mais longe, aprenda novas formas de aperfeiçoar a gestão de projectos, fale com pessoas mais experientes, experimente novas metodologias, o importante é nunca achar que já se sabe tudo sobre um determinado tema.

 

No terceiro desafio proponho que partilhe todo esse conhecimento em que é realmente bom. Este é talvez o passo mais complicado, mas também o mais desafiante. Deve perder o medo de transmitir o seu expertise. Um profissional confiante das suas capacidades sabe que não deve temer um maior conhecimento por parte dos seus pares/equipa, sabe que só com equipas de alto rendimento se obtêm resultados extraordinários e sabe que apenas nessas equipas se sente motivado.

 

Esse tipo de interacção vai ainda puxar por si e obrigá-lo a exercitar constantemente aquilo onde já é muito bom, vai tornar-se num especialista reconhecido por outras pessoas, vai atingir a sua excelência.

 

08
Mar19

Mas afinal o que é o Agile?

Luís Rito

Não sei se é por estar na moda, mas hoje em dia todos falam de Agile.

 

Fico sempre na dúvida se sabem de facto o que significa uma gestão de projetos verdadeiramente ágil, e na grande maioria das vezes percebo que não. Dou um exemplo, existe muito a crença que assim que começamos a utilizar uma gestão de projetos agile, todos os nossos problemas passam a fazer parte do passado. Afinal, não precisamos de planear, não precisamos de produzir documentação e passamos a poder colar post-its na parede, o que nos faz parecer de repente que pertencemos a uma start-up e que somos muito "Cool". Se pensas assim, lamento mas o agile não é nada disto!

 

paddleboard_agile_-_beachcottagephotography_thumb1

 

 

Na realidade, o agile são um conjunto de princípios e valores que foram criados por um conjunto de 17 pessoas em 2001! Pois, aquilo que pensas que é muito recente já leva uns anos de vida. Ao conjunto de valores que foram criados chamamos "Agile Manifesto".

 

Os valores são (vou deixar em inglês, tal como o original):

 

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

 

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

 

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

 

Mas afinal o que é que significa tudo isto? Significa que para abraçamos o agile, temos que guiar as nossas ações do dia a dia de acordo com estes valores. Sempre que nos deparamos com uma decisão difícil, devemos pensar se estamos ou não a ir de encontro ao que está escrito naquelas 4 linhas que referi acima. Passo a explicar uma a uma.

 

Individuals and interactions over processes and tools

 

Na prática, isto significa que em agile se dá muita prioridade às pessoas, e à forma como se comunica. Comunicação cara a cara é muito valorizada, e existe o conceito de equipas multidisciplinares, onde facilmente todos os membros da equipa têm acesso a um conjunto amplo de conhecimento. Conheço casos em que se dá demasiado valor aos processos e ferramentas, o que origina muitas vezes tempos de espera grandes em cada fase do processo. Quanto mais complexo o processo, maior o tempo até à sua conclusão, resultando em lead times elevados. Sempre que possível, levanta o rabo da cadeira e fala diretamente com quem precisas, envia email somente quando necessário.

 

Working software over comprehensive documentation

 

Isto não significa que em agile vamos deixar de produzir documentação, não é nada disso. Mas pode significar que por exemplo a equipa pode avançar com o desenvolvimento de forma paralela à criação da documentação, não é necessário esperar que tudo esteja perfeitamente especificado para avançar. Em agile a medida real de progresso é trabalho realizado. De nada adianta ter toda a documentação bem realizada e bonita se depois falhámos completamente a data de entrega do projeto.

 

Customer collaboration over contract negotiation

 

Quem conhece a gestão de projeto tradicional, sabe que o gestor de projeto tenta no início do projeto fechar o seu âmbito o mais rápido possível. Isto permite-lhe fazer um plano de projeto e segui-lo passo a passo até ao seu final. Arrisco-me a dizer que em 99% das vezes existem alterações inevitáveis ao âmbito do projeto. Sejamos realistas, para conseguir planear com 100% de rigor teríamos de dispender muito tempo nesta fase, o que colide com o valor que falámos atrás. Hoje em dia os projetos têm que ver a luz do dia bem rápido, as empresas não se podem dar ao luxo de passar vários meses a fazer somente análise e planeamento. Dito isto, o que normalmente acontece na gestão de projetos tradicional é uma negociação constante entre o gestor do projeto e o cliente, ou seja, o cliente tenta incluir mais âmbito e o gestor de projeto tenta restringir ao máximo a entrada de alterações ao plano inicial. O agile defende que se deve colaborar com o nosso cliente, e não estar constantemente a negociar. Quanto mais envolvido estiver o cliente mais hipóteses do projeto ser um caso de sucesso. Ninguém vai destruir aquilo que ajudou a construir!

 

Responding to change over following a plan

 

Outra grande diferença entre uma gestão de projetos tradicional e o agile, é que na segunda, mudanças ao âmbito não são vistas como um risco ou como um custo. O agile abraça a adição de alterações no projeto, mesmo quando introduzidas numa fase tardia. Mais uma vez, isto deve-se ao facto do ritmo de mudança ser nos dias que correm muito rápido. Algo que era dado como adquirido à 6 meses atrás pode ser completamente diferente hoje. Os projetos têm que ter a capacidade de se adaptar a novas realidades. De nada serve acabar um projeto dentro do prazo e dentro do custo, se depois o produto final não vai de encontro ao que a empresa necessita. Muitas vezes são situações tão simples como, uma empresa concorrente inclui uma nova inovação, e a empresa onde estamos a executar o projeto tem que se adaptar rapidamente, sob pena de perder uma fatia da sua quota de mercado. No agile, a restrição mais importante é sempre o tempo, e nunca o âmbito. A grande luta é acabar o projeto on time, mesmo que tenhamos que excluir algum âmbito inicialmente definido para incluirmos novas funcionalidades não planeadas.

 

Para além dos valores descritos acima, existem ainda 12 princípios que funcionam como uma espécie de credo para os agilistas.

 

1) Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

 

2) Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

 

3) Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

 

4) Business people and developers must work
together daily throughout the project.

 

5) Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

 

6) The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

 

7) Working software is the primary measure of progress.

 

8) Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

 

9) Continuous attention to technical excellence
and good design enhances agility.

 

10) Simplicity--the art of maximizing the amount
of work not done--is essential.

 

11) The best architectures, requirements, and designs
emerge from self-organizing teams.

 

12) At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

 

Se tiveres mais curiosidade sobre este tema, dá uma vista de olhos no site do Agile Manifesto.

Podes encontrá-lo aqui:

https://agilemanifesto.org/ 

 

Até à próxima!

 

07
Mar19

Procurar por categoria

Luís Rito

Abaixo podes encontrar a lista de todos os posts que foram sendo publicados ao longo do tempo. Faz a pesquisa com a função de procura do teu browser para encontrares o que pretendes mais rápido.

 

Gestão de Projetos

 

Afinal o que é um PMO e para que serve?

A importância do business case nos projetos

Agilizar a transformação digital

A carreira de gestão de projetos é indicada para mim?

Bright Challenge 2019

Caos na gestão de projetos

Como medir a saúde de um projeto?

Como pode o Lean adaptar-se à gestão de projetos?

Extreme Programming - O que é?

Fases de desenvolvimento de uma equipa

Frágil vs Antifrágil

Gestão de conflitos na gestão de projetos

Mas afinal o que é o agile?

Mas afinal qual a melhor metodologia de gestão de projetos?

O agile como cura para todos os males

O teu projeto precisa mesmo de gestão de risco?

Os 7 hábitos dos gestores de projeto brilhantes

Qual a diferença entre projeto e operação?

Qual o papel de um bom gestor de projetos?

Tipos de liderança de um gestor de projetos

To Scrum or not to Scrum

Três níveis de precisão em estimativas de projetos

Retira o máximo da tua reunião de kick-off

 

Produtividade

 

Boa gestão do tempo, utopia ou realidade?

Como combater o hábito da preguiça?

Como geres a tua atenção?

Comunicação eficaz por email

Consistência

E se tivesses um cérebro extra?

Focar na excelência

Gere a tua carreira , ninguém o vai fazer por ti

Hábitos do profissional de excelência

Liderar reuniões eficazes

Pensa bem quando dizes que não tens tempo

Qual o teu mindset?

 

Inovação

 

Como ser uma pessoa mais criativa

Finito vs Infinito

Guiar a inovação

 

Finanças Pessoais

 

Ativos vs Passivos

Poupar para libertar

 

Empreendedorismo / Startups

 

12 formas de fornecer valor

Os 5 processos básicos na criação de uma startup

 

 

06
Mar19

Sobre mim

Luís Rito

17_Luis Rito_111 - Copy.JPG

 

Nascido em Vila Franca de Xira e criado em Azambuja (não muito longe de Lisboa), cedo me interessei por tudo o que está relacionado com computadores..bem..talvez mais pelos jogos. Foram horas a jogar aqueles belos jogos do antigamente, e quem não se lembra do "Space Invaders"?

 

Não sei se foi por isso, mas quando cheguei ao 12 ano achei por bem ir para um curso de informática. Olhando para trás, foi uma decisão de que nunca me arrependi. Durante alguns anos (mais concretamente 6) dediquei-me à programação informática, e foi durante esse tempo que nasceu o bichinho dos projetos. Apesar de na altura ainda não saber, o facto de participar em muitos projetos veio cultivar em mim uma grande vontade de seguir a carreira de gestor de projetos.

 

Foi através de uma empresa de consultoria de gestão que essa oportunidade chegou. Tirei algumas certificações do PMI (Project Management Institute), e nos últimos 5 anos tenho-me dedicado na íntegra à gestão de projetos. Os projetos que me dão mais gozo são aqueles verdadeiramente transformadores e que estão relacionados com a estratégia e transformação digital das empresas.

 

Mais recentemente, exerço funções de PMO numa grande empresa de transportes e logística, onde o grande objetivo é dotar a empresa de metodologia e boas práticas de gestão de projetos, formar as pessoas e mudar a cultura organizacional, fornecer software que permita aos gestores de projeto fazer o seu trabalho, partilhar informação acerca da saúde dos projetos e portfólio e alinhar os projetos com a estratégia da empresa.

 

Adoro fazer desporto, gosto de fazer caminhadas, gosto de natação, faço ginásio regularmente e tenho uma daquelas bicicletas de cycling em casa. Acredito que devemos estimular o nosso corpo tanto a nível intelectual como a nível físico. Acredito muito no auto-melhoramento, e penso que todos os dias temos que tentar ser um pouco melhores do que éramos no dia anterior.

 

Finalmente, gosto muito do tema "Finanças Pessoais". Tenho um livro escrito sobre esse assunto, porque acredito que nós Portugueses temos que ser mais cautelosos com o nosso dinheiro. Enquanto povo latino gostamos de gastar mais do que o que temos, e a médio/longo prazo isso torna-se desastroso.

 

Esta apresentação já vai longa, portanto fico por aqui, acredito que me vais conseguir conhecer melhor ao longo do tempo :).

 

CONTACTOS/LINKS

e-mail

ldrito@gmail.com 

 

LinkedIn

https://www.linkedin.com/in/luisrito/ 

 

Livro "Liberdade Financeira"

https://www.amazon.es/Liberdade-Financeira-financeiramente-Livre-Portuguese-ebook/dp/B079137J4C 

 

 

Subscrever por e-mail

A subscrição é anónima e gera, no máximo, um e-mail por dia.

Arquivo

  1. 2019
  2. J
  3. F
  4. M
  5. A
  6. M
  7. J
  8. J
  9. A
  10. S
  11. O
  12. N
  13. D

Livro Liberdade Financeira