Certificação PMI-ACP: riscos, aquisições e integração no Ágil

Projetos Ágeis - Apresentação

Olá, sou Roberto Pina. Boas-vindas a mais esse curso da série de preparação para Certificação PMI-ACP: riscos, aquisições e integração no Ágil.

O público-alvo para esse curso são analistas de sistemas e de negócios, gerências e coordenações de projetos, integrantes de áreas de governança, como PMOs (Project Management Office) e escritórios de projetos, pessoas que desejam atuar como Scrum Master ou Product Owner futuramente, pessoas desenvolvedoras com interesse em migrar para funções mais ligadas à gestão, pessoas que já praticam o Ágil e desejam se certificar para reforçar as suas credenciais e pessoas consultoras em metodologias, gestão e transformação organizacional.

Esse curso é o sexto da série que se destina à preparação para certificação PMI-ACP, que é a grande certificação Ágil provida pelo PMI (Project Management Institute).

Mas a nossa jornada vai além. Além de preparar você para o exame, para essa certificação, temos também como objetivo aprofundar o seu conhecimento a respeito do Ágil nos aspectos teóricos e práticos.

Nesse curso nós trataremos de conceitos básicos a respeito de riscos, aquisições e integração. Depois veremos como o Ágil endereça a questão dos riscos, como endereça a questão das aquisições e como trata a questão da integração; como esses três grandes assuntos de gerenciamento de projetos são tratados no contexto do Ágil. E ao final faremos algumas discussões práticas e conclusões para ilustrar o conteúdo.

Os benefícios para os participantes envolvem um grande apoio à preparação para certificação PMI-ACP e uma extensão e um aprofundamento a respeito da cultura e dos métodos Ágeis.

Venha comigo então nesta jornada de preparação. Vamos em frente, começando na sequência a trazer os conceitos fundamentais a respeito de riscos.

Projetos Ágeis - Riscos

Falarei sobre conceitos básicos a respeito de riscos. O risco por definição é um evento incerto, ou seja, que pode acontecer ou não, e que se vier a acontecer pode trazer impactos positivos ou negativos no projeto. Então risco é algo arriscado, que pode trazer um impacto.

Quando o risco traz um impacto que pode ser positivo, costumamos chamar de oportunidade. São os riscos bons. Mas o maior foco, tradicionalmente falando, são em cima dos riscos que trazem impactos negativos, os riscos ruins, ou simplesmente riscos.

Os principais fatores de um risco são a sua probabilidade e o seu impacto. Probabilidade é a chance de aquele evento acontecer, que varia de 0 a 100%, excluindo os extremos. E o impacto é quanto vai arder, quanto vai ser doloroso, qual vai ser o prejuízo caso aquele risco se concretize.

E a combinação de probabilidade e impacto dá o chamado nível ou grau do risco. Se eu conseguir quantificar a probabilidade em termos percentuais e o impacto em termos financeiros, por exemplo, esse valor de probabilidade vezes o impacto dá o nível ou o grau do risco.

Como eu faço para descobrir os riscos do meu projeto, da minha empreitada, do meu contexto? Simples, eu pergunto à equipe. Todos da equipe devem ser estimulados a sinalizar candidatos a risco.

E a pergunta que eu devo fazer à equipe é: “vocês estão enxergando alguma armadilha, alguma ameaça no nosso caminho, alguma cabeçada que podemos dar? Vocês estão farejando alguma coisa que pode dar errado?”.

Se sim, traga para colocarmos como candidato a risco e vermos se devemos realmente tratar aquilo como risco de fato e fazer a devida tratativa do mesmo. Dessa forma eu vou recolhendo os meus riscos.

E o que eu faço com esses riscos descobertos? Eu devo fazer 3 coisas: registrar, priorizar e tratar. Para registrar, registramos os riscos no chamado registro de riscos, que é um artefato que veremos em detalhe mais à frente.

Depois eu devo priorizar os riscos, eu devo atacar os riscos mais importantes. E para priorizar os riscos eu faço de acordo com o nível ou grau, não simplesmente com a probabilidade ou com o impacto, porque um risco de pode ter uma probabilidade muito alta de acontecer, mas o impacto ser pequeno. Ou o contrário, ele tem um impacto gigantesco, mas a probabilidade é remotíssima.

Então olhar só a probabilidade ou só o impacto não me dá elementos suficientes para dizer se aquele risco é importante. Agora, a combinação dos dois, que é o nível ou grau me dá elementos para dar um peso para aquele risco, e eu devo então priorizar os riscos do meu registro de riscos a partir do nível ou do grau dos mesmos.

E uma vez priorizado eu devo tratar. E para tratar eu crio o chamado plano de resposta aos riscos, que diz o que eu vou fazer com aquele risco, como eu vou lidar com ele, quais são as ações que eu devo ter em cima daquele risco que está priorizado.

Então isso é risco e a maneira como ele deve ser classificado e tratado. Na sequência falaremos a respeito de conceitos básicos acerca de aquisições.

Projetos Ágeis - Aquisições

Agora trarei para você conceitos fundamentais a respeito das chamadas aquisições em projetos, ou, em inglês, procurements.

Muitas vezes adquirimos projetos, produtos e serviços de terceiros, porque vale mais a pena fazer isso. E no nosso contexto falaremos bastante, principalmente na parte mais prática, sobre aquisições de projetos de software, aquisição de desenvolvimento de sistemas por terceiros.

E os projetos de software adquiridos por escopo, preço e prazo fixo, baseado na abordagem Waterfall, que era como se faziam muitos projetos algum tempo atrás, Waterfall tem uma sistemática contrária ao Ágil.

Nós vimos que o Ágil se contrapõe ao ciclo de vida Waterfall para o desenvolvimento de produtos complexos, porque um produto complexo não tem o seu escopo detalhado a priori.

Assim sendo, eu criar um compromisso de escopo e, portanto, preço e prazo fixos de algo que ainda será descoberto, ainda será detalhado e depende de feedback é extremamente complicado. E para produtos como software essa abordagem não cabe e tem um histórico de empreitadas desastrosas.

Então, a primeira observação importante a fazer é que a contratação de desenvolvimento do software Waterfall deve ser evitada, porque o software é um produto complexo, onde o ciclo Waterfall não cabe.

Diferentemente de outro tipo de produto, como uma ponte, um galpão, algum produto físico, que é mais repetível e previsível, cuja construção pode seguir uma receita. Por mais complicado que o produto seja, ele pode e deve ser totalmente desenhado a priori, e aí sim o ciclo Waterfall é adequado. Mas para produtos como software não.

Por outro lado, apesar de nós termos descoberto que a abordagem Waterfall não é boa para software, existiu durante muito tempo na indústria uma cultura de “quero saber quanto vai custar e o que eu vou receber” de antemão.

Eu vou comprar um software, ou alguém vai desenvolver um software para mim, e eu quero saber a lista completa do que eu vou receber a priori e quanto vai custar.

Isso era algo natural, eu comprar software como se estivesse comprando qualquer outro produto, qualquer outro artefato de engenharia. E essa forma tradicional é muito baseada na orçamentação.

Eu tenho o meu orçamento, ou preciso fazer o meu orçamento, portanto preciso saber quanto esse produto de software vai custar. A equipe tem que me dizer, porque eu tenho meu orçamento. E na orçamentação tradicional, focada em projetos, era demandado ter esse valor, o que acabava acontecendo eram chutes, ou então estimativas deliberadamente erradas.

Isso causava uma série de problemas, tais como estouros de orçamento, ou então sacrifícios na qualidade do produto em função das pressões que acabam caindo em cima do projeto devido a essa restrição e o prazo e orçamento acabando, e o escopo sendo descoberto e alterado e tudo mais. É aquela problemática que quem já tocou projetos Waterfall conhece muito bem.

Então desenvolver software não é a mesma coisa que construir uma ponte ou um artefato de construção civil. Lembremos sempre, e é isso a tônica do Ágil.

Com a difusão do Ágil então, começou um balanceamento de compromissos e expectativas que ainda está em progressão, que as organizações ainda estão se adaptando, e que foi desfazendo aos poucos o uso do Waterfall no software.

Além disso, o desenvolvimento de software por encomenda se tornou menos comum. Hoje há muitos pacotes prontos, ERP’s e etc., para uma série muito grande de aplicações e finalidades e também soluções de software as a service (SaaS).

Então o desenvolvimento tailor-made a partir do zero não é tão comum. Ele se aplica mais a sistemas muito especializados, que não são commodities, que eu já tenho algum pacote para adquirir.

Esse movimento de expansão do Ágil ainda está em progressão, como eu disse, e ele interfere diretamente na forma de comprar software.

E isso envolve mais foco em valor do que em preço, uma compreensão progressiva, cada vez maior de que é fácil dizer quanto custa, mas é mais difícil dizer quanto vale. Então eu tenho que pensar mais em adição de valor ao negócio ou de estar gastando um determinado valor e esse valor vai me trazer tudo que eu preciso.

Também a expansão do Ágil trouxe para as aquisições horizontes mais curtos de compra e venda. Então eu vou comprando de maneira faseada, e não vou colocar um orçamento num projeto gigante, de 2 anos, e lá na frente ver o que vai acontecer.

Também está em curso uma compreensão de que o escopo do software não é definido, mas sim vai sendo descoberto. Isso não precisa ser um problema. Nós podemos colocar um investimento e ir descobrindo o escopo do software, essa descoberta gerar entregas que vão adicionar valor ao negócio, que vão consumir orçamento e uma hora esse orçamento acaba.

E quando esse orçamento acabar eu tenho uma certa quantidade de valor adicionada ao negócio que compensou esse investimento, mesmo o escopo tendo sido descoberto ao longo da jornada e não totalmente definido a priori.

Também a questão da confiança é muito importante. Começou uma mentalidade diferente, rumo mais à confiança, a confiar que a equipe vai dar o máximo sem ter que ficar amarrada, com restrições de projetos, como cronograma, prazo e outras amarras, para que as pessoas deem o máximo. Progressivamente está se percebendo que não vale a pena essa mentalidade.

E também uma visão mais de fluxo, mais de cadeia de valor, e menos de projetos que representam silos, ou produtos entregues em grandes lotes. Eu tenho uma cadeia de valor, onde uma equipe se dedica a ela, consumindo um orçamento, consumindo investimento que é feito na manutenção da equipe, e vai adicionando valor.

O software é construído, depois ele tem um ciclo de vida onde ele vai recebendo melhorias, novas funcionalidades e adaptações, e isso segue um fluxo.

Não é algo que eu faço um investimento, entrego tudo e está acabado. O software tem uma certa continuidade, e eu posso dosar os meus investimentos, as minhas compras de acordo com o balanço de necessidades e possibilidades, visando a adição de valor a um negócio, como qualquer outra atividade dentro da empresa.

Então as aquisições, em especial no Ágil, começam a ficar cada vez mais revestidas dessa nova mentalidade. Quando falamos de software essa nova mentalidade está ainda em difusão, mas se tornando cada vez mais comum, felizmente.

Na sequência falarei a respeito de conceitos fundamentais do tema integração.

Sobre o curso Certificação PMI-ACP: riscos, aquisições e integração no Ágil

O curso Certificação PMI-ACP: riscos, aquisições e integração no Ágil possui 118 minutos de vídeos, em um total de 45 atividades. Gostou? Conheça nossos outros cursos de Agilidade em Inovação & Gestão, ou leia nossos artigos de Inovação & Gestão.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Projetos Ágeis
• Gerenciamento de Riscos
• Gerenciamento de Aquisições
• Gerenciamento da Integração
• Riscos, Aquisições e Integração