Extreme Programming - O que é?
Hoje abordamos o tema Extreme Programming, vou dar-vos a conhecer o que é, e quais os seus valores.
O Extreme Programming (XP) é uma metodologia de desenvolvimento de software, que teve origem nos Estados Unidos da América durante a década de 90. O grande objetivo desta metodologia passa pela criação de sistemas de software com maior qualidade, numa timeframe mais reduzida e custando por acréscimo menos dinheiro.
Tudo isto é possível devido à forma com o XP foge à forma tradicional de realizar projetos, bem como à aplicação de uma série de valores, princípios e práticas.
O âmbito deste post passa por perceber quais os valores que estão envolvidos na prática desta metodologia, ficando os princípios e as práticas guardados para mais à frente.
Um dos maiores problemas que existe no desenvolvimento de software passa pelo facto das pessoas envolvidas neste processo se focarem muito em ações individuais. Uma equipa a funcionar em pleno sabe que o importante não são as ações individuais, mas a coesão que existe entre toda uma equipa.
Nesta metodologia dá-se especial atenção ao facto da equipa estar ou não concentrada no que realmente interessa, ou seja, se estão todos a "remar" para o mesmo sentido. Para que isso aconteça o XP baseia-se em cinco valores básicos:
Tipicamente um cliente que necessita de um sistema informático tem um conjunto de problemas que pretende resolver, tendo já inclusive algumas ideias sobre como o fazer. Por outro lado as equipas que desenvolvem o software têm o Know-How técnico que lhes permite construir um sistema tendo em conta as melhores práticas. Para que exista um entendimento entre o cliente que fala uma linguagem mais voltada para o négocio e os programadores que falam uma linguagem mais técnica é necessário que exista um bom canal de comunicação.
Quanto melhor for o canal de comunicação menos possibilidades existem de criação de problemas, ambiguidades e desentendimentos.
Por norma, os diálogos cara a cara são superiores a uma videoconferência, que é superior a um telefonema que por sua vez é mais expressivo que um email.
Uma das ferramentas que é utilizada no XP é o diálogo cara a cara, permitindo desta forma que o entendimento entre todas as partes seja o mais correto possível. Desta forma evitam-se problemas que possam surgir mais tarde, até porque quanto mais cedo os problemas forem detetados menos custos estarão envolvidos na sua resolução.
Um projeto de software está constantemente sujeito à mudança. Os clientes mudam de ideias com alguma frequência, seja porque as prioridades mudam, seja porque percebem que existem formas mais eficazes de resolver os seus problemas. Qualquer mudança não planeada realizada a meio de um projeto acarreta riscos, pois por vezes é necessário alterar blocos do sistemas que já estavam fechados, existindo a possibilidade de provocar bugs (erros informáticos).
O XP não tem uma fórmula mágica para resolver este problema, mas utiliza uma série de mecanismos de proteção que permite enfrentar a mudança com uma coragem renovada.
Assim ao invés de bloquear a criatividade do cliente, uma equipa XP enfrenta com segurança e coragem o desconhecido.
Alguns dos mecanismos de proteção utilizados são o desenvolvimento orientado a testes, o pair programming e a integração contínua (falarei noutro dia do que são).
Os projetos de software são normalmente iniciativas muito dispendiosas, arriscadas e com um histórico de falhas muito alto. As equipas XP sabem isso melhor que ninguém, e encaram todos os projetos como uma eventual potencialidade de problemas e falhas que possam advir.
Todas estas falhas podem ser minimizadas se forem identificadas rapidamente e numa fase inicial. É por isso que no XP estabelecem-se ciclos de desenvolvimento curtos, onde são apresentados pequenos pacotes de funcionalidades ao cliente. Assim é possível deste logo alinhar as expectativas do cliente com as expetativas da equipa de desenvolvimento, favorecendo ambas as partes. O cliente sai beneficiado pois desempenha um papel mais ativo na construção do sistema (aumentando a probabilidade de sucesso do projeto), e a equipa de desenvolvimento beneficia de uma menor probabilidade de falhas e problemas futuros (que originam muito rework).
Respeito é o valor mais importante de todos. Os membros de uma equipa só vão funcionar como "equipa" se existir respeito mútuo entre todos eles. Se não existir respeito mútuo no seio de uma equipa então não existe muito que se possa fazer para salvar um projeto de uma catástrofe.
Saber ouvir e saber compreender o ponto de vista de um colega é essencial para o sucesso de um projeto de software.
Estudos recentes demonstram que uma grande percentagem de todas as funcionalidades desenvolvidas num sistema informático não chegam sequer a ser utilizadas.
O XP baseia-se no princípio de simplicidade, onde se dá prioridade a funcionalidades realmente necessárias ao bom funcionamento do sistema, evitando funcionalidades que podem vir a ser necessárias no futuro, mas que ainda não o provaram ser.
Por outras palavras, primeiro construímos um automóvel capaz de circular, depois preocupamo-nos com a marca do auto-rádio e se o volante tem ou não botões que o controlam.
Por hoje é tudo, num post mais à frente prometo aprofundar um pouco mais sobre este tema.
Até à próxima :)
A carreira de gestão de projetos é indicada para mim?
Olá :) !
Hoje voltamos ao tema "Gestão de Projetos". Acima de tudo, vamos focar-nos na questão, a carreira de gestão de projetos é indicada para mim?
Após alguns anos de gestão de projetos, uma coisa que me saltou à vista foi o facto de existirem pessoas que acham que é uma profissão relativamente fácil, e que qualquer um a pode fazer. Até certo ponto é verdade, mas apenas se tens como objetivo exercer uma gestão de projetos básica ou medíocre. Na realidade, para se chegar a um nível de excelência é necessário muito mais que saber fazer planos e controlar o trabalho das pessoas. É sobre isto que te quero falar hoje. Uma gestão de projetos robusta necessita de pessoas com experiência e com um conjunto de skills muito específico. Claro que a capacidade de realizar bons planos, organizar o trabalho das outras pessoas ou efetuar um bom controlo é algo importante, mas não é isso que distingue um gestor de projeto mediano de um gestor de projeto excelente. Todas essas características são o básico que tens que aprender para começar a gerir projetos. A parte em que realmente te podes destacar vem depois, e é bem mais difícil de aprender. Uma percentagem muito grande de gestores de projeto estagna exatamente aí, já que como em qualquer profissão, se queres avançar para um nível de excelência necessitas de gostar realmente do que fazes e de te puxar para o próximo nível.
A primeira característica que necessitas de cultivar para seres um gestor de projeto de excelência é teres um interesse genuíno pelas pessoas e pelos seus interesses. Enquanto gestor de projeto terás muitas vezes de convencer as pessoas a fazer aquilo que queres, mesmo sem teres qualquer tipo de autoridade formal sobre elas. Para o conseguires, tens que conquistar a sua confiança e ganhar influência junto delas. Isso não se consegue de uma forma rápida nem se consegue a enviar emails da tua secretária. As pessoas são bem mais que recursos no teu plano de projetos, têm famílias, têm interesses, têm aspirações e objetivos. Se és o típico gestor de projetos que apenas envia emails a solicitar que o trabalho seja executado, nunca vais conseguir chegar à excelência. Precisas de te levantar, precisas de ir falar com as equipas, entender como está a sua moral, perceber se a pessoa certa está afeta à tarefa certa e de as convencer a irem contigo, mesmo quando tens dúvidas sobre se é o caminho certo. Por outras palavras, se fores um líder nato vais com certeza ser um gestor de projeto excepcional.
A segunda característica fundamental é ser um pouco cético em relação a tudo. Não digo isto de forma a desconfiares de tudo e de todos, mas teres uma curiosidade forte e perguntares sempre o porquê das coisas serem assim. Isto vale tanto para a equipa como para o cliente do teu projeto. Por exemplo, quando um membro da equipa te dá uma estimativa de 5 dias para algo que achas que leva 3, então deves perguntar o porquê da estimativa. Estarás a esquecer-te de algo ou a pessoa deu uma folga demasiado generosa? Deves manter-te cético e perguntar o porquê. Isto também vale para o cliente do teu projeto. Por exemplo, se numa reunião o teu cliente te exige mais âmbito mantendo o mesmo prazo de entrega, deves perguntar-te se o pedido é ou não irrealista. Existem muitos projetos que nascem já com o selo do fracasso, basta para isso que te digam que deves realizar um determinado âmbito num prazo impossível. Enquanto gestor de projetos deves sempre questionar e levantar pontos que ponham em causa o sucesso do projeto. Se achas que o prazo que te deram é irrealista, deves partilhar, ainda que o tenhas que dizer a um gestor sénior ou a um diretor.
A terceira característica é que deves aprender a aceitar a mudança. Não sejas o gestor de projeto que faz um plano de projeto e acha que não terá de o alterar mais. O principal benefício de fazer um plano de projeto é colocar as pessoas a planear, tornando o próprio ato de planeamento mais importante que o plano em si. Garanto-te que um plano apenas se mantém perfeito até ao primeiro dia do projeto :). A partir daí terás de começar a realizar ajustes e alterações para fazer face a todas as mudanças que vão certamente acontecer. Portanto, não sejas o gestor que compra guerras com o cliente apenas por ele querer algo um pouco diferente do que pediu inicialmente. Claro que se for uma mudança de âmbito drástica o planeamento como um todo deve ser reavaliado, mas se as alterações em causa são curtas e poucas, deves tentar acondicioná-las. Cuidado apenas para não cederes em tudo, se aceitas todas as pequenas alterações, no final o teu projeto não vai acabar dentro do prazo estimado. Deves aceitar algumas alterações que te dêem créditos para negar outras. Caso o teu cliente insista, apenas tens que referir que para realizar as alterações não vais conseguir garantir a data estimada de fim, e pede o seu consentimento para aumentar o prazo.
Existem muito mais características, mas deixo-te aqui 3 que considero muito importantes. Concordas com elas?
Gestão de conflitos na gestão de projetos
Hoje vamos falar de um tema muito importante. Em todas as organizações, e consequentemente em todos os projetos, existem conflitos. É algo normal, e deve até ser encarado como saudável. Uma equipa que não tem conflitos não se encontra a trabalhar na sua capacidade máxima, já que pode significar que as pessoas não se encontram a comunicar eficazmente, ou pior, que não querem saber do seu trabalho e dos seus projetos. Alguém que não se interessa tem uma maior capacidade em ignorar por completo os conflitos normais do dia-a-dia. O mesmo acontece em pessoas com alguma aversão a conflitos, talvez devido a traços de personalidade mais introvertidos. O conflito normalmente obriga a uma troca de ideias entre dois ou mais elementos da equipa, o que por vezes vai originar uma conjugação de ideais que levam a uma melhor solução do ponto de vista global.
Feita esta pequena introdução, passemos à mensagem que te quero transmitir. Abaixo listo-te 5 técnicas de gestão de conflitos. Acredito que muitas delas (ou mesmo todas) já as utilizaste. Também acredito que devido à tua personalidade utilizes mais umas que outras. As técnicas são:
Como o nome indica, neste caso a estratégia passa por evitar ou adiar o conflito. Pode ser uma excelente técnica quando necessitas de te preparar melhor para o conflito, ou quando achas que pode ser resolvido por outros. Ao evitar também te dá mais tempo para pensar melhor sobre a perspetiva da outra pessoa. Deixo apenas um alerta, se evitas um conflito para te preparares melhor para ele no futuro, então certifica-te que fazes isso mesmo, caso contrário o adiamento não será de todo proveitoso. Corres ainda o risco de ao adiar um conflito o ir tornando cada vez pior.
Acomodar um conflito significa focar em áreas em que existe acordo ao invés de áreas em que existe desacordo. Isto significa que nesta estratégia de conflito uma das partes cede a sua posição em benefício da outra parte. Com este tipo de técnica normalmente opta-se por favorecer a relação profissional ao invés de a fragilizar com conflitos. Assim, não deve existir foco nos pontos em que existe desacordo, a parte que acomoda tenta encontrar pontos de acordo entre ambas as partes para resolver o conflito (embora tenha que ceder na sua posição). Técnica muito utilizada quando a parte que acomoda quer manter a paz na equipa, quando sabe que não tem alternativa senão aceitar a outra parte ou quando num projeto de longa duração se opta por ceder num ponto para mais à frente ganhar noutro. Por exemplo, podes optar por acondicionar um novo desenvolvimento no teu projeto (desde que seja pequeno), para mais à frente dizer que já não te é possível realizar outro porque já esticaste o calendário.
Ao obter um compromisso, ambas as partes ganham, mas também têm que ceder em algo. Alguns conflitos não têm uma solução win-win, ou seja, em que todas as condições de todas as partes são completamente resolvidas ou cumpridas. Nestes casos usam-se técnicas de negociação para que ambas as partes ganhem, tendo cada uma delas que ceder em algumas condições iniciais. Para que esta técnica funcione, ambas as partes têm que saber o que a outra pretende. A dificuldade é que muitas vezes a real necessidade está camuflada, e quem negoceia nunca chega a entender o real interesse. Por exemplo, imagina um profissional que tem férias marcadas para a próxima semana. O gestor de um projeto propõe adiantar um bloco do projeto para a próxima semana a fim de recuperar calendário, e tenta negociar com a equipa a melhor forma de o fazer. Neste caso pode acontecer que o profissional que tem férias, tente boicotar o avanço do bloco do projeto, argumentando por exemplo que trás muito risco, quando na realidade o seu real interesse é ir de férias. Deve-se tentar sempre perceber qual a real necessidade para que se consiga resolver um conflito.
Como o nome indica, a estratégia de forçar impõe fazer valer a sua vontade acima da dos outros. Normalmente só é possível quando realizada por alguém com hierarquia superior dentro da organização. Neste tipo de técnica, normalmente acontecem situações win-lose, já que uma parte sai claramente beneficiada em relação à outra. Pode ser muito útil em alguns tipos de situação, como por exemplo no meio de uma crise onde decisões rápidas têm que ser tomadas. Outro bom exemplo é quando determinadas ações têm que acontecer, como por exemplo manter regras de segurança no trabalho. Ainda que um operário argumente e justifique o porquê de não querer utilizar um capacete enquanto trabalha, o seu chefe pode forçá-lo a fazê-lo, dado que se trata de uma obrigatoriedade. Convém só dizer que com esta estratégia, existe uma maior possibilidade de vires a ter colaboradores zangados e pouco satisfeitos.
A típica situação win-win. Neste tipo de estratégia ambas as partes estão recetivas a colaborar e a chegar a um consenso e compromisso. Por existir esta predisposição, normalmente o diálogo é algo normal, tentando-se obter e concretizar as condições de todas as partes. Para que isto aconteça, a equipa deve já ter um nível de confiança alto e devem ser aplicadas técnicas que estimulem a criatividade. Todos sabemos que por vezes os problemas e conflitos aparentam não ter solução, mas na realidade a grande maioria tem, bastando para isso pensar um pouco enquanto equipa. Esta técnica é a minha preferida, pois de uma discussão construtiva podem surgir melhorias ou soluções às quais nunca iríamos chegar sozinhos.
Agora que já conheces as 5 técnicas, com quais delas te identificas mais?
Tipos de liderança de um gestor de projetos
Hoje quero abordar um tema que por vezes é esquecido pelos gestores de projeto, a forma como lideram as suas equipas. Não existe um estilo de liderança único que funcione para todas as situações, motivo pelo qual vos vou falar de vários tipos que podem adotar no vosso dia a dia. A informação que partilho convosco foi recolhida do livro "PMP Exam Preparation", um livro especialmente escrito para ajudar pessoas a passar na certificação PMP (Project Management Professional) do PMI (Project Management Institute).
Avançando, para que possas escolher o estilo de gestão indicado deves sempre ter em conta fatores como o teu estilo de gestão pessoal, a experiência da equipa e quais as suas necessidades e também a complexidade do teu projeto. O mais normal é que no decorrer do projeto tenhas que utilizar vários tipos de gestão, consoante o contexto em que te vais encontrar. Por exemplo, no início do projeto é possível que tenhas que adotar uma postura mais diretiva de forma a providenciar direção para a equipa, mas durante a execução poderás assumir uma postura mais colaborativa e de coaching à equipa.
Alguns dos estilos que poderás adotar são os seguintes (vou manter os termos na língua inglesa por uma questão de facilidade):
Directing - Neste estilo basicamente o gestor diz à equipa o que tem que fazer.
Facilitating - Quando neste estilo, o gestor de projeto coordena os inputs da equipa e ajuda por exemplo no desbloqueio de problemas.
Coaching - Este estilo baseia-se muito em ajudar os membros da equipa a atingir os seus próprios objetivos.
Supporting - Este estilo significa que o gestor de projeto providencia assistência e apoio à equipa durante todo o ciclo de vida do projeto.
Autocratic - Método top-down, onde o gestor tem o poder para fazer o que quiser e a equipa realiza sem possibilidade de rebater.
Consultive - Método bottom-up, onde o gestor utiliza a influência que vai ganhando junto da equipa para obter resultados. O gestor ouve a opinião da equipa e atua mais como um servant-leader.
Consultive-Autocratic - Uma mistura dos dois últimos que referi acima. Nestes casos o gestor recolhe a opinião da equipa, mas depois recai sobre ele a decisão final.
Consensus - Como o nome indica, este estilo de liderança tem tudo a ver com obter o consenso da equipa na resolução de um problema ou na tomada de uma decisão.
Delegating - Neste estilo de liderança, o gestor define os objetivos mas depois transfere autoridade à equipa para os atingir e para os executar.
Bureaucratic - Este estilo foca-se muito em processo. Pode ser fundamental em situações onde ir ao detalhe é muito importante ou por exemplo em projetos de âmbito legal.
Charismatic - O motivador. Este estilo de liderança visa aumentar a energia da equipa, fazendo-a acreditar que tudo é possível. O principal objetivo é motivar a equipa.
Democratic ou Participative - Este estilo de gestão encoraja a equipa a participar em decisões importantes do projeto. Os membros da equipa ficam assim "donos" de tarefas específicas ou de certos objetivos.
Laissez-faire - Este estilo de liderança é basicamente deixar a equipa fazer o seu trabalho em paz. O gestor não está diretamente envolvido no trabalho, podendo no entanto ser consultado caso a equipa assim o entenda. Ideal para equipas muito experientes.
Anaytical - Este estilo depende muito das competências técnicas do gestor de projeto. Este tipo de gestores toma muitas vezes decisões de âmbito mais técnico que depois comunica à sua equipa. Tem também um grande foco em dados.
Driver - Gestor que se encontra constantemente a mostrar o caminho. Normalmente fornece muita informação à equipa e corrige o trajeto caso esta se desvie do objetivo.
Confesso que eu próprio utilizo muitos dos estilos que vos falo acima, mas aqueles com que me identifico mais são os que fomentam o trabalho em equipa e a colaboração.
E tu, com quais te identificas?
Fases de desenvolvimento de uma equipa
Hoje vamos falar sobre as fases que existem no desenvolvimento de uma equipa. Enquanto gestor de projeto, algo que terás de enfrentar muito durante a tua carreira é a criação de novas equipas. Decerto já reparaste que quando uma equipa se encontra formada à algum tempo torna-se tudo mais simples, as pessoas já se conhecem, já sabem com o que podem contar e acima de tudo têm claro qual o seu papel e responsabilidade dentro da própria equipa.
O modelo mais famoso que visa explicar a dinâmica de uma equipa, desde a sua criação até ao seu término é o modelo de Tuckman. É sobre este modelo que te quero falar hoje. Contudo quero incluir também um ponto extra ao modelo que considero que te vai ajudar enquanto gestor de projeto. Em cada uma das fases de desenvolvimento de equipas que compõem o modelo de Tuckman, vamos ainda perceber qual o papel do líder da equipa em cada uma delas, já que este é fundamental para o seu sucesso.
Sem mais demoras, as 5 fases que compõem o modelo são as seguintes (mantenho a língua original, ou seja o inglês): Forming, Storming, Norming, Performing e Adjourning. Detalho abaixo cada uma delas.
Fase em que os membros da equipa são reunidos e onde vão começar a trabalhar enquanto equipa. Geralmente nesta fase as pessoas são ainda muito cautelosas umas com as outras, já que ainda se estão a conhecer. Podem existir pessoas que vão acusar algum grau de ansiedade, pois vêem-se de repente rodeadas de outras pessoas que não conhecem e com o qual não se sentem à vontade. Nesta fase irá muito provavelmente também existir pouca definição de quais as responsabilidades de cada membro da equipa, o que pode levar a mais ansiedade e desilusão.
Papel do líder: Enquanto líder, terás de ter um papel dominante nesta fase. Devido ao facto de muito provavelmente não existir definição clara de responsabilidades entre todos os membros (seja porque não foi definida, seja porque as pessoas ainda não as interiorizaram), deves fazer reuniões individuais com cada um dos membros da equipa. Essas reuniões para além de serem muito importantes para clarificar as responsabilidades de cada um, são também ótimas para perceber quais os objetivos, ambições ou intereses dos membros da equipa. Essa informação é fundamental para que consigas colocar as pessoas certas a trabalhar nas tarefas certas.
Nesta fase começam a existir algumas discussões e desacordos no seio da equipa. Finda a fase de forming, as pessoas já ganharam confiança umas com as outras, o que lhes permite expôr a sua opinião de forma mais efusiva. É nesta fase que alguns pontos de vista contrários começam também a emergir, por exemplo, diferentes formas de trabalhar vão originar na maioria das vezes uma discussão sobre o que é certo e o que é errado. Não digo que discussão seja algo mau, tem é que ser feito de uma forma construtiva, o que muitas vezes não acontece. Interessa referir que a maioria das equipas falha na fase de storming, principalmente quando não consegue ultrapassar as diferenças que existem entre os seus membros. Outra situação que pode acontecer nesta fase é uma diferenciação entre volume de trabalho entre membros da equipa. Pode acontecer alguns elementos terem um volume de trabalho muito elevado enquanto outros não. Isto invariavelmente leva a descontentamento e desmotivação.
Papel do líder: Nesta fase o líder tem que estar muito presente e atento ao que se passa. Deve assumir uma postura mais diretiva e encaminhar a equipa para o caminho correto sempre que alguns membros se tentem desviar. Deve reduzir ainda a tensão que possa existir entre algumas pessoas. Caso ainda existam dúvidas relativamente à forma de trabalhar ou às responsabilidade de cada um, o líder deve atuar de imediato e clarificar ambos o pontos.
De uma forma gradual a equipa vai avançando da fase de storming para a fase de norming. As pessoas começam a respeitar-se umas às outras, começam a aceitar as diferenças de cada um, encarando-as inclusive como uma vantagem e aprendem a trabalhar em conjunto. É nesta fase que normalmente as pessoas se começam a conhecer melhor, seja na esfera profissional seja na esfera pessoal. Começam a ir beber café ou a almoçar em conjunto, e laços de amizade surgem. É também nesta fase que alguns resultados positivos poderão começar a emergir, trazendo motivação extra para toda a equipa. Deixo só um alerta, a transição da fase de storming para a fase de norming é talvez a mais difícil e demorada, enquanto líder não podes desmotivar. Tens que ser muito persistente e continuar a facilitar esta transição.
Papel do líder: Nesta fase o líder é mais um facilitador e motivador. Deve mostrar à equipa os bons resultados, deve desenvolver o processo de trabalho de forma a perseguir uma maior performance e deve ainda adequar as qualidades e interesses das pessoas às tarefas e responsabilidades existentes.
Esta é a fase ideal de uma equipa. Todos sabem claramente quais as suas responsabilidades dentro da equipa, todos se conhecem e respeitam-se enquanto pessoas e profissionais, o processo de trabalho está rotinado e otimizado e existe um flow de trabalho constante. Esta fase é caracterizada por uma elevada produtividade e performance. Existe ainda motivação e confiança entre membros da equipa, e por vezes até um sentimento de orgulho por fazer parte da equipa.
Papel do líder: Nesta fase a necessidade de supervisão é pequena, portanto o líder pode agora concentrar-se no desenvolvimento individual de cada uma das pessoas. É nesta fase que se costuma dizer que se o líder não estiver durante algumas semanas, a equipa conseguirá de forma sustentada continuar a produzir excelente trabalho. Deve portanto existir um foco maior em coaching individual a cada uma das pessoas, permitindo trabalhar nos pequenos detalhes que vão produzir grandes resultados no futuro.
Fase de separação da equipa. Esta terá de acontecer caso a tua equipa tenha sido formada no âmbito de um projeto, já que estes têm um início e fim bem definidos. Esta fase pode ser muito difícil para algumas pessoas, principalmente aquelas que criaram laços muito fortes com outros elementos da equipa, ou sempre que exista pouca visibilidade do sítio para onde irão trabalhar no futuro.
Papel do líder: Encorajar as pessoas a refletir sobre toda a experiência que foi o projeto.Tranquilizar quem esteja mais inseguro sobre o futuro e sobre o eventual afastamento com quem trabalhou nos últimos tempos. Fomentar o contacto futuro entre as pessoas, não é por um projeto ter terminado que vão deixar de ser amigos ou de estar em contacto.
E é isto. São estas as 5 fases do modelo de Tuckman. Se fazes parte de uma equipa decerto identificas-te com algumas das coisas que te fui escrevendo. Faço-te um desafio, sabes em que fase se encontra a tua equipa neste momento?
Por hoje é tudo, espero que tenhas gostado e até à próxima
Agilizar a transformação digital
Olá a todos, espero que se encontrem bem
Hoje quero partilhar convosco um artigo que escrevi no passado, mas que ainda considero estar atual. Transcrevo abaixo na íntegra, caso queiram aceder ao original, basta seguir este link.
Nunca como nos dias de hoje se falou tanto sobre transformação digital. Cerca de 91% das empresas afirmam que uma implementação rápida da sua estratégia de transformação digital irá trazer grandes benefícios para a sua organização, e 96% afirmam que realizar uma transformação digital no seu negócio é encarado como crítico para o sucesso futuro.
Um dos principais desafios encontrados pelas empresas que empreendem numa transformação digital do seu negócio passa pela sua execução no "time to market" pretendido e dentro dos parâmetros de qualidade exigidos pelos seus clientes.
Um dos métodos preferenciais das organizações passa pela redefinição das suas "customer journeys", isto é, os principais percursos realizados pelos seus clientes sempre que interagem com a empresa. O banco inglês Lloyds é um excelente exemplo de sucesso, tendo conseguido alterar 10 "customer journeys" estratégicas para o seu negócio, tornando-as e transformando-as de modo a serem mais digitais e com grande foco na experiência cliente. Isso permitiu por um lado uma redução de custos, um aumento de eficiência e um alinhamento com a forma como os seus clientes querem interagir com o banco (menos presencial e mais digital ou por telefone). As grandes necessidades dos clientes continuam a ser exatamente as mesmas do século passado, comprar uma casa, comprar um automóvel, realizar um projeto pessoal. O que alterou significativamente foi a forma como o cliente quer interagir com o seu banco. Tomando, por exemplo, o caso do Lloyds, um dos primeiros "customer journeys" a ser otimizado foi o processo de abertura de conta. Através de um processo de simplificação e digitalização, é agora mais simples do que nunca realizar este tipo de operação. Não é de estranhar que a quantidade de clientes ativos a utilizar meios digitais do banco tenha disparado, sendo hoje cerca de 12,5 milhões num total de 25, tornando o Lloyds no maior banco digital do Reino Unido.
É justamente neste tipo de cenários (e não só) que metodologias "agile" podem acrescentar grande valor. Uma transformação digital com grande foco na experiência de cliente exige um novo "mindset" na abordagem ao conceito de projeto. Palavras como "flexibilidade", "criação de valor", "melhoria contínua" ou "entrega rápida e incremental" devem fazer parte do vocabulário de um gestor de projetos moderno.
Em média, 45% das funcionalidades planeadas e implementadas em projetos de "software" nunca são utilizadas. Este tipo de situações representa um elevado custo para as organizações, já que os seus recursos estão a ser utilizados em algo que não vai criar valor futuro. Para agravar esta situação, existe ainda um outro custo que por vezes não é quantificado por parte das empresas, o custo de oportunidade. As empresas devem, portanto, fazer regularmente a seguinte questão: "O que não estamos a realizar ao investir o tempo dos recursos em algo que poderá nunca vir a ser utilizado?"
O grande desafio da gestão moderna passa por olhar para projetos como um conjunto de funcionalidades, isto é, ao invés de realizar somente uma entrega (projeto), a tendência passa pela realização de várias entregas ou funcionalidades ao longo do tempo. Esse princípio é amplamente defendido por metodologias "agile", o que permite um aumento de flexibilidade (permite decidir rapidamente se certas funcionalidades são ou não implementadas), criação de valor (desenvolver apenas as funcionalidades que criam valor para o negócio) e entrega rápida e incremental de valor para a organização.
Parafraseando o autor Howard Hughes que utiliza uma frase tão simples, mas ao mesmo tempo tão complexa, o grande desafio das empresas passa por "think big, act small". Cultivar um ambiente de start-up com uma elevada cultura enérgica e um aumento da velocidade na entrega de valor exige um elevado pragmatismo e foco no objetivo. A medição contínua do progresso em intervalos curtos permite a rápida implementação de ações corretivas sempre que tal seja necessário. A correção dos planos e a capacidade de agir em tempo real são uma poderosa ferramenta de gestão, que deve ser utilizada no dia a dia de um gestor.
Urge, portanto, dar uma oportunidade ao "agile", mas da forma correta. Para uma melhor implementação deste tipo de metodologias, a utilização de um conjunto de recursos com um elevado nível de formação em "agile" e alinhados com uma cultura de entrega de benefícios que criam valor real aos seus clientes é essencial. A necessidade da grande maioria das empresas ter de se reinventar e investir numa transformação digital é uma fantástica oportunidade para o fazer. Vivem-se tempos de mudança e é fundamental dar o primeiro passo e arriscar.
Espero que tenham gostado, por hoje é tudo, até à próxima
Como pode o Lean adaptar-se à gestão de projetos
Olá ! Espero que te encontres bem.
Como prometido no meu último post (Mas afinal qual a melhor metodologia de projetos?), hoje vamos falar um pouco sobre como o Lean se pode adaptar à gestão de projetos. Começando pela história do Lean, convém referir que não se trata de uma ferramenta mas sim de uma filosofia. Esta filosofia teve origem na Toyota, mais concretamente na Toyota Production System. De uma forma macro, o grande foco do Lean é o de reduzir desperdícios em todos os processos da empresa, resultando numa maior redução de custos a nível global, redução de lead-time e aumento da qualidade. Importa ainda definir o que se entende por lead-time, já que é o tempo desde que um projeto inicia (por exemplo desde que o projeto é solicitado) até que termina. Nota que o tempo é corrido, ou seja, mesmo que durante vários dias não seja efetuada qualquer atividade no projeto, a duração continua a contar para o lead-time. Se por outro lado estivermos a falar de obter todo o esforço do projeto, já estamos a falar de cycle-time.
Na grande maioria dos projetos é comum ter lead-times muito mais elevados que os cycle-times, já que existem tempos em que não se está a efetuar qualquer atividade, seja por indisponibilidade dos recursos seja por demoras em aprovações/validações. A ideia do lean é tentar diminuir esse fosso entre lead-time e cycle-time, já que se trata acima de tudo de desperdício existente no projeto. Por exemplo, se todos os teus projetos necessitam de aprovação de um CEO que apenas tem disponibilidade para reuniões uma vez por mês, então tens um grave problema no teu processo, estás a mandar fora uma quantidade considerável de tempo, já que terás sempre algo a aguardar validação (e portanto parado).
O lean tem 5 princípios basilares que suportam a sua filosofia.
Identificar o que significa valor
A noção de valor deve ser identificada pelo cliente do projeto, ou seja, corresponde ao valor que o cliente está disposto a pagar. Por vezes o próprio cliente não sabe a 100% o que pretende, principalmente se estivermos a falar de novas tecnologias ou processos. O desafio aqui é ajudá-lo na busca de uma solução, para que seja identificado o que significa criar valor.
Identificar e mapear value streams
O segundo princípio faz uso de um artefacto chamado value streams. Um value stream corresponde a todas as ações (que criam valor e que não criam valor) necessárias para dar ao cliente o que ele considera como valor, desde o momento do desenho, até ao desenvolvimento e terminando na implementação. O primeiro passo é desenhar o value stream atual, para depois se trabalhar num value stream futuro, que corresponde à forma como o novo processo deverá operar. A grande vantagem de desenhar um value stream, é que nos permite olhar para ele com uma visão helicóptero, facilitando a tarefa de encontrar formas de o melhorar, tendo também como foco uma constante perseguição na redução de desperdício. O value stream deve também ter informação acerca de quais os tempos gastos em cada atividade do processo, incluindo todos os tempos de espera entre atividades.
Criar flow e eliminar desperdícios
Depois de identificar o que significa valor, e após ser executado o desenho do value stream, o próximo passo é o de criar flow, ou seja, criar um fluxo contínuo de trabalho, eliminando desperdícios como tempos de espera, trabalho refeito, etc. Ao analisar um value stream vais verificar que existem 3 tipos de trabalho:
Value-Added Work - Trabalho que efetivamente cria valor. A estratégia passa sempre por tentar maximizar este tipo de trabalho.
Value-Enabling Work - Trabalho que tem potencial para ser removido no futuro (com melhorias ao processo), mas que ainda não pode ser eliminado atualmente. Trata-se de trabalho que é realizado por exemplo devido a fatores como tecnologia ou cultura. A estratégia para este tipo de trabalho passa por minimizá-lo.
Non Value-Added Work - Trabalho que não acrescenta qualquer tipo de valor. Deve ser eliminado logo que possível, já que ao contrário do Value-Enabling Work, não está dependente da melhoria de outras áreas do processo. Como se trata de puro desperdício, a estratégia para este tipo de trabalho é eliminá-lo definitivamente.
Em gestão de projetos, desperdícios podem por exemplo assumir a forma de documentos de projeto, que por vezes não são sequer necessários no contexto atual, ou tempos de espera, por exemplo a aguardar validações e aprovações. Já a nível processual, quantas vezes te deparaste com clássica resposta "Porque sempre fizemos assim" à pergunta "Porque fazes isso dessa forma?". Pois é, deves estar sempre na procura de otimização de processos e redução de desperdícios.
Estabelecer um sistema de pull
O grande desafio no lean passa por apenas dar valor ao cliente assim que ele o pede. A ideia por detrás de um sistema de pull é muito simples, apenas deves começar novo trabalho quando existe demanda por parte do cliente, e também quando a tua equipa tem capacidade para o fazer. Na lógica lean, isto permite evitar uma produção excessiva.
De forma a entenderes melhor o que te falo, ilustro abaixo a diferença entre um sistema de push e um sistema de pull.
Num sistema de push, sempre que uma tarefa é criada, é atribuída a alguem que a vai desenvolver. Normalmente esta atribuição é realizada por um gestor ou team leader. O trabalho é então alvo de um push para quem o vai realizar.
Já num sistema de pull, a tarefa é criada e é colocada numa fila de trabalho, onde ficará a aguardar processamento. Sempre que uma pessoa da equipa tem disponibilidade para realizar mais trabalho, desloca-se até à fila de trabalho e retira a tarefa com maior prioridade, para assim a começar a desenvolver. A principal diferença é que reside na pessoa que vai fazer o trabalho o poder de fazer pull às tarefas mais prioritárias.
Os sistemas pull utilizam normalmente quadros kanban que permitem fazer uma gestão mais visual do trabalho por realizar, trabalho em curso por pessoa e trabalho já terminado.
Procurar a perfeição
O último princípio que te vou falar é a procura constante pela perfeição. Isto envolve uma melhoria permanente dos processos, e é um trabalho que nunca tem fim. O valor de cada uma das atividades deve ser sempre posto em causa, evitando cenários de status quo que tanto se vêem nas empresas. Diria que nunca vais conseguir a perfeição, até porque é algo que não existe, mas tenho a certeza que com melhorias constantes vais conseguir chegar bem perto.
E a nível de processo?
Agora que já tens uma ideia mais clara de quais são os princípios do lean, deves estar a perguntar-te como tudo isto se liga com a gestão de projetos. Conforme já tinha mencionado no post anterior, uma metodologia lean faz mais sentido sempre que exista uma grande quantidade de trabalho que chega numa base quase diária, requerendo assim mais agilidade. Desta forma, normalmente a equipa faz uso de um kanban, onde vai colocando em backlog (fila de trabalho por realizar) tudo o que existe para ser executado. De acordo com a prioridade, a equipa vai fazendo pull ao trabalho e executando-o assim que tenha capacidade para o fazer, assegurando assim que o trabalho mais prioritário é terminado primeiro. Claro que de acordo com as boas práticas do agile, deve também existir a disponibilização de demos para que o cliente consiga dar feedback, existindo também um foco constante em melhorar a forma de trabalhar (de forma a procurar a perfeição).
Para teres uma ideia, dá uma vista de olhos na imagem que coloco abaixo (cortesia da Disciplined Agile).
Por hoje é tudo, o post foi um pouco mais longo do que é normal, mas espero que gostes.
Mas afinal qual a melhor metodologia de gestão de projetos?
Nos dias que correm, muito se fala de projetos. E como os projetos são realizados por pessoas, igualmente muito se fala de metodologias para os gerir. Parece que todos andam em busca de uma metodologia milagrosa que vá salvar o seu projeto de um desastre absoluto, e já agora que possa ser utilizada e aplicada em todos os projetos futuros. Quem não ambiciona entregar sucesso atrás de sucesso?
É por isso que enquanto gestores de projeto tendemos a procurar a melhor metodologia. E como em tudo, também aqui existem modas. De há uns tempos para cá só se fala em Agile, parece que é a derradeira arma contra as dores de cabeça com que nos deparamos nos nossos projetos. A realidade é que em algumas situações o Agile pode ser a resposta, mas não podemos cair no erro de pensar que é a solução para tudo. Se me perguntares então qual a melhor metodologia, receio que a minha resposta não te vá agradar, contudo é a única que te posso dar. A resposta para a pergunta "Qual a melhor metodologia de gestão de projetos" é..."Não existe uma metodologia melhor que as outras", tudo depende do contexto em que te encontras!
As empresas devem ser vistas como um organismo vivo e complexo. Na grande maioria das empresas é extremamente difícil estabelecer comportamentos de causa-efeito. Uma ação que originou um resultado numa situação, pode em situações muito similares originar um resultado completamente diferente. Isto acontece porque as empresas têm na sua estrutura pessoas, cada uma delas com os seus objetivos, realizações e frustações. Por exemplo, o comportamento de uma pessoa quando está feliz é radicalmente diferente de quando está triste. Essa mesma pessoa pode hoje realizar uma ação (efeito), mas daqui a 2 semanas realizar outra completamente diferente quando confrontada com a mesma causa (por exemplo porque leu um livro que a ensinou a fazer melhor ou teve formação).
Este tipo de complexidade espelha-se também nos projetos. A menos que o teu projeto tenha 1 pessoa, e que o resultado do projeto seja para essa mesma pessoa utilizar, então terás sempre alguma complexidade. Tudo isto piora se estivermos por exemplo a falar de projetos com 100 pessoas, com impacto em várias áreas da empresa, com novos processos, com novas formas de trabalhar e com nova tecnologia. Tudo depende do contexto do teu projeto, e a realidade é que para determinados contextos existem metodologias com taxas de sucesso mais elevadas. É por isso que uma empresa não pode apenas ambicionar ter uma metodologia única de gestão de projetos que possa ser utilizada em todas as situações. Não existe o canivete suiço das metodologias. O que deve ser feito é uma adaptação da metodologia à realidade e ao contexto do projeto.
Pessoalmente acredito que as empresas deveriam ter 3 metodologias de gestão de projetos, uma mais tradicional (ou waterfall), uma mais agile (por exemplo scrum) e por último uma Lean. A par dessas metodologias, deve existir um mecanismo para entender em qual delas é que cada projeto se insere. Surge então uma questão pertinente. Como escolher a melhor metodologia para os teus projetos?
A escolha pode variar de acordo com vários fatores. Do meu ponto de vista, deves observar quais as características do teu projeto, mas também da tua equipa. Vê a informação abaixo para teres uma ideia mais clara.
Características Metodologia
-Ambiente burocrático elevado
-Pessoas especializadas em apenas uma função
-Poucas entregas
-Ciclo de feedback com cliente longo
-Projetos "conhecidos" e com probabilidade baixa de surpresas
-Trabalho estável (saber o que se vai fazer)
Tradicional, por exemplo waterfall
-Ambiente menos burocrático e mais voltado para a disciplina
-Equipas multidisciplinares
-Entregas frequentes
-Ciclo de feedback com cliente curto
-Projetos com elevada possibilidade de sofrerem alteração ao âmbito
-Trabalho mais ou menos estável (possível de repartir por sprints)
Agile, por exemplo scrum
-Ambiente não burocrático e voltado totalmente para a disciplina
-Pessoas com conhecimentos gerais e com capacidade de fazer de tudo um pouco (por exemplo com capacidade de realizar análise, desenvolvimento, testes e releases)
-Ciclos de feedback com cliente curto
-Projetos com constantes alterações ao âmbito
-Trabalho não estável (novo trabalho chega regularmente, por exemplo diariamente)
Como podes observar, conforme a complexidade do teu projeto vai aumentando, existe uma transição de uma metodologia mais tradicional, onde existe uma elevada previsibilidade do trabalho que se vai realizar, avançando para metodologias mais agile, onde se continua a ter uma ideia em traços gerais do que se pretende construir, mas necessita-se de entregar rápido e de forma iterativa, até ao cenário mais caótico, onde novas tarefas poderão surgir no limite várias vezes ao dia, utilizando-se princípios Lean.
Sei que não tenho falado muito de Lean, mas prometo fazê-lo num post futuro, para que entendas melhor do que te falo. Por agora espero ter conseguido passar a mensagem que não existe uma metodologia universal que possas utilizar em toda e qualquer situação. Tal como uma empresa é um organismo vivo e complexo que se adapta para sobreviver, também as tuas metodologias o devem fazer, sob pena de entrarem em vias de extinção!
Por hoje é tudo, até à próxima
Qual a diferença entre projeto e operação?
Espero que se encontrem bem. Hoje voltamos ao tema gestão de projetos, mais especificamente, o que é um projeto e o que é uma operação. Calculo que à primeira vista tudo isto te pareça trivial, mas não imaginas na quantidade de empresas em que já presenciei um total desconhecimento de quando deve acabar um projeto e começar uma operação. Não te preocupes, estou aqui para te esclarecer .
Bom, indo direto à parte mais teórica, importa reter que um projeto tem o objetivo de construir algo único para a organização que o está a realizar. Para além dos projetos terem esta característica de unicidade, são também temporários, ou seja, têm uma data de início e fim muito bem definidas. Por comparação, uma operação trata-se de um esforço não temporário ou contínuo, assumindo características repetitivas com o objetivo de construir algo que a empresa já sabe fazer. Face a estas características, podemos então afirmar que o objetivo máximo de um projeto é transformar o negócio, e que o objetivo máximo de uma operação é manter o negócio.
Do ponto de vista de importância, ambos são fundamentais para uma empresa, já que projetos sem operação não trazem benefícios, e operação sem projetos acaba por se extinguir por falta de inovação. Como podes então distinguir um projeto de uma operação? Imagina o seguinte exemplo, sempre que uma marca automóvel constrói um novo modelo, necessita de desenhar o chassis, necessita de desenhar um novo modelo de motor e novos interiores. Para além de tudo isso, precisa de perceber como se vai organizar internamente para conseguir produzir o novo modelo em larga escala. Tudo isto que te falei pode ser considerado um projeto. Desde a ideação, ao desenho, até à definição de processos operacionais que permitem transformar tudo em realidade, trata-se de um projeto. Se pensares bem, tem que ter um prazo bem definido e é algo único na empresa, ou seja, apesar da empresa já ter provavelmente produzido dezenas de modelos, nunca construiu aquele em específico. A empresa está a dar continuidade ao seu portfólio ao introduzir continuamente novos produtos, está a transformar o negócio, neste caso através de inovação incremental. A operação vem depois do projeto, já que estará encarregue de utilizar os outputs deste para iniciar a produção em massa do automóvel. Trata-se portanto de um processo repetitivo e contínuo. A empresa irá continuar a produzir aquele modelo automóvel pelo tempo que considerar necessário. Está portanto a manter o negócio.
Pelas diferenças que existem entre projetos e operação, a forma de medir o seu sucesso também é radicavelmente diferente. Um projeto normalmente mede os desvios entre tempo e custo (do planeado para o real). Quanto menor o desvio melhor, ou seja, interessa que seja concluído dentro do budget e dentro do prazo que estava inicialmente definido. Claro que outro excelente indicador é se o projeto entregou a qualidade pretendida, podendo isto ser medido pelo número de defects ou mesmo através de um questionário de satisfação ao cliente.
Já a operação rege-se muito pela produtividade, interessa produzir o máximo de unidades no menor tempo e custo possíveis, otimizando assim o fluxo de todo o processo.
Algo comum nas empresas é um projeto ser entregue ao cliente, mas continuar aberto, mesmo quando a operação já começou a fase de produção. Não digo que isso seja errado, mas o ideal é manter uma fase de acompanhamento por tempo limitado. Imagina a construção de uma moradia (um projeto), quando o construtor a termina e entrega a chave ao seu cliente, o projeto está praticamente concluído. Pode existir uma fase de apoio curta, mas a partir desse momento a equipa muda, deixam de ser as pessoas envolvidas na construção e passam a ser pessoas responsáveis pela manutenção (uma operação). É exatamente isto que deve acontecer nos projetos. Após entrega, a equipa mantêm-se por exemplo durante um mês a prestar apoio, mas de seguida o projeto é considerado entregue e finalizado. A partir desse instante, qualquer alteração ou apoio deve ser tratado com a equipa de operações. É por isso que é importantíssimo existir um momento de partilha de informação entre a equipa de projeto e a equipa de operações. Desta forma evitas que um projeto se prolongue tempos sem fim em fase de "Encerramento", e acredita que já vi projetos nesta fase mais de um ano!
Não deixes que os teus projetos continuem eternamente. Numa fase inicial distingue muito bem quais os critérios de aceitação para que o projeto possa ser considerado aceite. Após conseguires cumprir esses critérios, dá por encerrado o teu projeto.
Por hoje é tudo, espero que te tenha sido útil. Até à próxima
Os 7 hábitos dos gestores de projeto brilhantes
Recentemente li um livro de gestão de projetos dos autores Stephen Barker e Rob Cole, chamado Brilliant Project Management. Para quem tenha curiosidade, pode consultá-lo aqui. Um dos pontos que gostei foi o facto dos autores referirem 7 hábitos dos gestores de projeto brilhantes. Não sei se acontece o mesmo contigo, mas pessoalmente gosto sempre de ler estas listas, porque facilmente consigo aplicar alguns dos hábitos no meu dia a dia, permitindo-me verificar se funcionam na realidade. Caso funcionem tento continuar a utilizar, caso não funcionem, aprendo algo com a experiência e sigo em frente.
Finda esta pequena introdução, escrevo-te abaixo os 7 hábitos do gestor de projeto brilhante:
1.Foco constante na solução
Sempre que um problema ocorre no teu projeto, o teu grande foco deve ser sempre a sua solução. Evita ao máximo entrar em pânico ou tentar perceber quem foi o culpado. Se tens acompanhado o meu blog, sabes que olho para os problemas como oportunidades para aprender e ser melhor. Creio que é a postura certa. Se o problema é muito grave, respira fundo e conta até 10, deves tentar acalmar-te antes de fazer o que quer que seja. Um gestor de projeto deve manter uma postura calma e no controlo da situação. Todos os problemas têm uma solução, portanto utiliza a inteligência de toda a equipa na sua resolução. Caso tenhas múltiplos problemas, prioritiza quais deves resolver em primeiro e trata de um de cada vez.
No filme Perdido em Marte, o personagem interpretado pelo Matt Damon revela a um grupo de estudantes qual foi o seu segredo para sobreviver sozinho em Marte durante tanto tempo. O segredo foi perceber de todos os problemas que lhe foram apresentados, quais os mais prioritários, e ir resolvendo um a um, sempre mantendo a força para continuar, mesmo quando tudo parecia correr mal. Por vezes ficamos afogados em muitos problemas e é fácil irmos abaixo. Tenta tratar de um tema de cada vez, vais acordar um dia e verificar que o trabalho difícil já ficou para trás.
2.Ser consultivo, mas também decisivo
Este ponto é muito importante, já que se por um lado o gestor de projeto deve envolver a sua equipa nas grandes decisões, por outro deve estar preparado para tomar decisões sempre que por exemplo não exista consenso entre todas as partes. Apesar de considerar muito proveitoso envolver a equipa sempre que possível, a realidade é que por vezes este processo pode ser muito demorado, já que pode não existir um resultado que seja apoiado por todos. Por outro lado, um gestor de projeto que não consiga tomar uma decisão vai na grande maioria das vezes afetar negativamente o projeto, já que por vezes é necessário ter um estilo mais diretivo e decisor.
3.Ter um foco constante no cliente
Este ponto não é novidade para ninguém. Se analisarmos as empresas com mais sucesso, todas elas têm um foco permanente nos seus clientes. Deves ao máximo tentar colocar-te nos sapatos do teu cliente e ver as situações através dos seus olhos. Enquanto gestor de projeto é muito fácil ter um foco apenas no custo, prazo e âmbito do projeto, mas os projetos que obtém verdadeiramente sucesso são aqueles onde existe um grande envolvimento do cliente, permitindo então atingir as suas expectativas e objetivos. Se um projeto é entregue dentro do custo, prazo e âmbito, mas não cumpre com aquilo que o cliente necessita, é um fracasso. É por isso que deves manter foco sempre no cliente.
4.Negociar para obter situações win-win
Várias são as situações onde o gestor de projeto vai ter que fazer uso das suas capacidades de negociação. Exemplos disso são, negociar recursos para a realização de tarefas do projeto, negociar pedidos de alteração ao âmbito do projeto, pedidos para encurtar o prazo, entre tantos outros. O segredo é utilizar cada negociação como uma possibilidade de obter situações win-win, ou seja, situações onde ambas as partes ganham. Sempre que o gestor de projeto assume uma postura mais agressiva numa negociação, até pode conseguir aquilo que pretende, mas pode ganhar um inimigo de futuro. Tentar assumir uma atitude de win-loss, vai prejudicar a outra parte, e esse tipo de atitude não passa despercebido. De futuro podes ser tu a necessitar de ajuda dessa mesma pessoa, portanto tenta obter uma situação justa para ambas as partes. Vais ser mais respeitado e também conhecido como uma pessoa que utiliza a criatividade para chegar a soluções benéficas para todos.
5.Obter o melhor de todos
Colocar a pessoa certa na hora certa a executar a tarefa certa é uma característica de um excelente gestor de projeto (e também líder). Uma das tuas tarefas mais importantes enquanto gestor de projeto deve ser identificar quais as motivações e aspirações de todos os membros da tua equipa. Perguntas como o que gostam de fazer ou o que os move devem ser realizadas continuamente. Se conseguires que as pessoas da tua equipa se encontrem a realizar tarefas que gostem, vais obter enormes melhorias de produtividade e redução de erros. A motivação vai também aumentar. Claro que todos sabemos que não podemos estar 100% do nosso tempo a fazer tarefas que gostamos, é normal existir uma percentagem de tarefas das quais não gostamos ou que não nos motivam, mas se conseguires maximizar as tarefas que cada elemento da tua equipa gosta de realizar vais também conseguir construir uma equipa o mais heterogênea possível. A forma como recompensas as tuas pessoas também deve ser diferente, já que por exemplo alguns de nós gostamos de reconhecimento público, enquanto outros preferem não ficar debaixo de holofotes. Ao invés de fazeres ao outros aquilo que gostarias que te fizessem a ti, deves fazer aos outros aquilo que eles gostariam que lhes fizessem a eles.
6.Foco constante em adaptar e evoluir
Quem me conhece sabe que sou fã de adaptar e evoluir. A pior coisa que podes fazes é ficar cristalizado no tempo, e assumir que se fizeste algo no passado deves fazer o mesmo no presente. Recordo-te que um projeto é por norma um sistema complexo, onde o output de uma ação pode variar, ou seja, uma ação que realizaste num projeto passado que deu excelentes resultados pode no presente não funcionar de todo. Deves desenvolver uma atenção constante ao teu meio ambiente e a todas as suas variáveis, podes utilizar estratégias que já funcionaram no passado, mas não assumas que vão funcionar, observa, adapta e evolui. Ainda que o teu projeto esteja a correr bem, procura a melhoria, pensa no que poderias fazer melhor, naquilo que podes efetivamente potenciar e fazer evoluir. Nunca pares de aprender e experimentar.
7.Liderar e gerir pelo exemplo
Pratica aquilo que apregoas. A melhor forma de conseguires que a tua equipa siga os standards que pretendes é fazê-los tu mesmo (de forma exemplar). Neste ponto a tua consistência vai ser crucial! A tua equipa está constantemente a observar-te e a avaliar-te, e se o líder do projeto não segue as regras do jogo, porque haverão eles de seguir? Este ponto é muito importante, mantêm-te fiel aquilo que acreditas e segue-o de forma religiosa até se tornar um hábito. A tua equipa vai-te seguir se observar que o exemplo parte de ti.