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

Profissional Moderno

Profissional Moderno

21
Jun20

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

Luís Rito

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

 

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

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

 

workflow

 

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

 

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

 

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

 

 

 

14
Jun20

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

Luís Rito

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

 

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

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

 

Kanban Board

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

 

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

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

 

Wait Time = % Busy / % Idle

 

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

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

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

 

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

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

 

Qual a tua opinião?

 

 

31
Mai20

Agile Mindset

Luís Rito

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

 

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

 

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

 

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

 

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

 

Individuals and iteractions over processes and tools

 

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

 

Consumable solutions over comprehensive documentation

 

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

 

Alta performance

 

Stakeholder collaboration over contract negociation

 

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

 

Responding to feedback over following a plan

 

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

 

Transparency over false predictability

 

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

 

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

 

 

01
Mai20

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

Luís Rito

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

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

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

 

Definition of Done

 

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

 

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

 

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

 

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

 

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

 

Até à próxima!

 

22
Abr20

Scrum em projetos de grande dimensão

Luís Rito

Olá!

 

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

 

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

 

 

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

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

 

Scrum of Scrums

 

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

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

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

 

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

 

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

 

Até à próxima :)

 

 

 

 

 

 

 

 

 

05
Fev20

Gestão de portfólios de projetos

Luís Rito

Olá :)!

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Obrigado por leres e até à próxima!

 

 

 

 

29
Dez19

O PMP ainda vale a pena?

Luís Rito

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

 

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

 

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

 

PMI

 

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

 

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

 

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

 

22
Dez19

Áreas estratégicas das empresas do século XXI

Luís Rito

Olá a todos :)

 

Hoje vamos abordar o que considero serem duas das áreas mais importantes de uma empresa do século XXI. Decerto já não é novidade para ninguém que o ritmo de mudança nos últimos anos tem sido infernal. Muitas empresas que falharam em incorporar essa mudança na sua estrutura estão a ter dificuldades no seu dia a dia. É uma realidade que em algumas indústrias a mudança tem chegado mais devagar do que noutras, por exemplo, uma empresa cuja base é vender energia (petrolíferas e afins) não necessita de um ritmo de mudança tão elevado como por exemplo o setor das viagens ou da banca. Grandes empresas com vários anos de existência estão a ser desafiadas por pequenas startups, que devido à sua grande agilidade conseguem implementar soluções com uma rapidez muito superior às empresas já estabelecidas com estruturas pesadas. Ora, se analisarmos bem, uma das grandes vantagens de uma startup é o seu elevado foco no cliente, a par com a disponibilização de processos e de soluções informáticas de alta qualidade. É por isso que considero que a grande maioria das empresas, apesar do seu core não ser IT, tem forçosamente que ser muito boa em IT.

 

É vital para a sobrevivência de qualquer empresa ter competências muito elevadas em IT. Diariamente todas as empresas acumulam gigabytes de dados, que quando devidamente trabalhados e interpretados dão origem a informação, que posteriormente se transforma em conhecimento. As maiores empresas do mundo apostam exatamente nisso, existem muitos casos em que na sua estrutura o diretor de IT já reporta diretamente ao CEO. É esta a importância que as empresas têm que dar ao seu IT, já que quando funciona bem permite alavancar em muito os lucros da empresa. Dou um exemplo muito simples, sou cliente da Amazon à vários anos. Por vezes recebo um email onde me é dito que livros me poderão interessar, ou de acordo com o que comprei, o que outras pessoas compraram, e acreditem que muitas vezes acabo a comprar essas sugestões. Multipliquem isto por milhares de clientes e podem imaginar os milhões que a Amazon encaixa graças a um tratamento inteligente dos dados que já dispõe.

 

Claro que para existir um bom IT, é necessário ter pessoas à altura, e é aqui que entra outra área que considero estratégica, os RH. Um bom departamento de RH recebe diretrizes da gestão de topo e contrata pessoas que se encaixem nesse perfil. Se a empresa quer uma empresa ágil, onde se valorize o trabalho em equipa e onde existam poucas hierarquias, não pode recrutar pessoas que não se encaixem nessa visão. Quando um líder idealiza uma estratégia a 3 ou 5 anos, certamente já sabe que tipo de pessoas vai necessitar. É por isso que se deve começar a contratar muito antes do tempo, para que as pessoas possam ir conhecendo o negócio, a organização e para terem tempo para construir. Dou um exemplo, se uma empresa definir que quer implementar uma estratégia de dados em 3 anos, diria que no final do primeiro já deve estar a pensar em contratar pessoas com a capacidade de fazer acontecer essa estratégia. Por vezes cai-se no erro de promover pessoas internas que não têm o perfil indicado, e isso raramente irá resultar em mudança. Não digo que promover internamente é mau, mas deve-se escolher apenas pessoas que façam um bom fit com as funções exigidas.

 

Equipa

 

A verdadeira agilidade que vemos em algumas empresas não advém do software ou dos processos que utilizam. Continuo a achar que o que traz verdadeira agilidade são as pessoas que fazem parte das equipas. Pessoas com um perfil empreendedor, que gostam de deixar a sua marca na empresa e de construir para melhorar são e serão sempre uma mais valia em qualquer empresa. É portanto necessário conseguir recrutá-las, e acima de tudo conseguir mantê-las motivadas no seu trabalho. Um dos fatores que continua a ser de grande importância para qualquer colaborador é a sua chefia, motivo pelo qual a camada de gestão de qualquer empresa deve ser do melhor que existe no mercado. É por isso que se devem continuar a realizar sessões de liderança e gestão, ou promover sessões de coaching entre gestores mais séniores e gestores mais júniores. Se a empresa tem uma excelente camada de gestão, as equipas lideradas por essas pessoas vão andar mais motivadas e mais tranquilas, o que resulta num aumento de produtividade e inovação. Uma boa chefia também tem a capacidade de desafiar as suas equipas de uma forma positiva, o que as vai levar a alcançar novos níveis de performance.

 

Está tudo interligado, se queres que a empresa tenha vantagens competitivas relativamente a outra, é nas pessoas que deves investir. São as pessoas que vão acrescentar o fator diferenciador e que vão catapultar a empresa para outros níveis. Resumindo, investe em processos de recrutamento, investe em liderança, investe em manter as pessoas satisfeitas, dá-lhes autonomia para realizar o seu trabalho e construir ao máximo com o mínimo de burocracia e vais ter colaboradores satisfeitos. Colaboradores satisfeitos vão atrair ainda mais talento para as fileiras da empresa, o que vai resultar em melhores processos e maior agilidade no desenvolvimento de soluções, que consequentemente irá levar a mais valor para os clientes da empresa (e portanto mais lucros). Finalmente, investe muito em IT, o futuro passa por aí, um bom IT vai-te permitir reduzir custos, aumentar o negócio e ter um conjunto de informação que vai suportar grande parte das decisões da empresa. Contra factos não há argumentos, e quando existem dados a tomada de decisão é bem mais fácil.

 

Por hoje é tudo, espero que tenhas gostado. Aproveito para desejar um bom Natal a todos, junto de quem mais gostam 

 

Até à próxima

 

17
Nov19

Extreme Programming - O que é?

Luís Rito

Olá :)

 

Hoje abordamos o tema Extreme Programming, vou dar-vos a conhecer o que é, e quais os seus valores.

 

O que é?

 

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.

 

Valores

 

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:

 

  • Comunicação
  • Coragem
  • Feedback
  • Respeito
  • Simplicidade

 

Comunicação

 

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.

 

Coragem

 

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).

 

extremeProgramming.jpeg

 

Feedback

 

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

 

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.

 

Simplicidade

 

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 :)

 

 

 

02
Nov19

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

Luís Rito

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.

 

Interesse genuíno nos outros

 

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?

 

Até à próxima!

 

Subscrever por e-mail

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

Livro Liberdade Financeira

Livro PMP Questions to Conquer the Exam