Instituto de Educação Tecnológica Pós-graduação Especialização em Gestão de Projetos Turma 142 25 de setembro de 2014 Planejar projetos com o uso da metodologia PMC Ana Paula Assis da Costa RESUMO Atualmente há um número crescente de empresas nascentes de tecnologia da informação que tem como principais características lidar com negócios de extrema incerteza e altamente mutáveis. Nesse contexto, essas empresas não dedicam muitas horas do seu tempo disponível planejando projetos. Tempo é dinheiro e dinheiro é um recurso escasso no universo das Startups de TI que quase sempre precisam de investidores para patrocinar os seus projetos. O presente artigo tem como objetivo apresentar os principais conceitos da metodologia Project Model Canvas (PMC) assim como os benefícios da adoção dessa metodologia em Startups brasileiras. Palavras-chave: Startup. Planejamento de projetos. Project Model Canvas. 1 INTRODUÇÃO Há uma quantidade enorme de definições do termo startup. O que os investidores chamam de startup? Muitas pessoas dizem que qualquer pequena empresa em seu período inicial pode ser considerada uma startup. Outros defendem que uma startup é uma empresa com custos de manutenção muito baixos, mas que consegue crescer rapidamente e gerar lucros cada vez maiores. Mas há uma definição mais atual, que parece satisfazer a diversos especialistas e investidores: uma startup é um grupo de pessoas à procura de um modelo de negócios repetível e escalável, trabalhando em condições de extrema incerteza (GITAHY, 2010). Ries (2012) discorre sobre como criar novos negócios de forma ágil, com baixos custos e orientado às necessidades dos seus clientes. Ao utilizar a metodologia presente nesse livro, o empreendedor terá noções de como desenvolver um produto que realmente atenda às necessidades do seu cliente.
Pesce (2012) escreve sobre o livro A startup enxuta e apresenta alguns dos conceitos presentes em Ries (2012) como: a) Aprendizados validados: as startups vivem em circunstâncias de incerteza extrema. A quantidade de suposições ao redor do que funcionará é absurda. Então, esteja pronto para cometer muitos erros. Errar não tem problema, desde que gere um conhecimento que pode ser aplicado para melhorar a sua empresa e acelerá-la na direção positiva. Esses são chamados de aprendizados validados. b) O ciclo do Construa Meça- Aprenda : determine uma hipótese sobre seu produto; decida quais informações são necessárias para validar essa hipótese; construa o mínimo possível para agregar essas informações; tire conclusões baseadas nos dados reunidos. c) Mínimo produto viável: é a versão de um produto que permite agregar o máximo de aprendizado validado com o menor esforço, de acordo com Ries. Por exemplo, o site de compra coletiva Groupon começou como um blog. Cada post era uma oferta, os cupons eram feitos com um gerador de PDF e enviados para lotes de e-mails no fim do dia. Dessa forma, os fundadores puderam validar que os clientes estavam interessados nas ofertas e decidiram continuar a criar o produto de uma maneira escalável. d) Pivô: na caminhada para validar as hipóteses, é muito provável que você perceba que o rumo da sua empresa precisará de algumas correções. Essas correções chamam-se pivôs. Talvez seja preciso mudar o segmento de clientes, o modelo de negócio, a plataforma ou até mesmo a combinação desses e de outros aspectos. Em geral, quanto mais cedo você perceber que um pivô é necessário, maiores as chances de você gerar uma mudança bem-sucedida. Pesce (2012) escreve sobre o livro The Four Steps to the Epiphany e apresenta os 4 momentos ou passos definidos por Steven Blank: a) Descoberta de clientes: descubra se há pessoas que querem o seu produto e que valor dão a ele; b) Validação de clientes: prove que é possível ter um ciclo de vendas sustentável. Isso acontece quando cada vez mais pessoas que experimentam o produto se tornam usuários ou compradores e você os monetiza de alguma maneira. O primeiro e o segundo passos juntos servem para validar a existência de um mercado para o seu produto; c) Criação de clientes: decida a estratégia para crescer a sua base de clientes; d) Construção da empresa: monte a estrutura da sua companhia, incluindo contratação de uma equipe capaz de escalar o negócio. Cukier (2013) informa que empresas nascentes de TI tem adotado mais intensamente metodologias ágeis tais como Scrum, XP e Lean.
Mas independentemente do momento em que as startups estejam é necessário que elas utilizem metodologias que possam trazer mais benefícios e agregar mais valores ao seu negócio e aos negócios de seus clientes. Cukier (2013) diz que agilidade não significa inexistência de técnicas de engenharia de software e de planejamento de projetos. 2 PRINCIPAIS CONCEITOS DA METODOLOGIA PMC O Project Model Canvas é uma metodologia para planejar projetos de forma visual e colaborativa. O projeto é planejado em uma folha A1 dividida em 13 blocos ou componentes (FINOCCHIO JUNIOR, 2013). FIGURA 1 Canvas com divisão dos blocos Fonte: FINOCCHIO JUNIOR, slide 04. Para preencher essa tela de fundo canvas em inglês são utilizados apenas post-its ou papéis adesivos. Esses post-its podem ser de tamanhos e de cores diferentes. É usual utilizar tamanhos maiores para definir blocos que requerem mais detalhes como o bloco de objetivo, enquanto é comum usar tamanhos menores para definir os requisitos do projeto. Um processo com quatro etapas e com ordem predeterminada deve ser seguido para a sua construção.
As quatro etapas da metodologia são as seguintes: a) Conceber: nessa etapa são respondidas as 6 perguntas fundamentais em sequencia determinada da esquerda para a direita. Os blocos na cor laranja receberão as respostas para a pergunta Por que?. Os blocos na cor roxa receberão as respostas para a pergunta O que?. Os blocos na cor branca receberão as respostas para a pergunta Quem?. Os blocos na cor azul receberão as respostas para a pergunta Como?. E os blocos na cor verde receberão as respostas para as perguntas Quando? e Quanto?. As respostas às perguntas feitas são escritas em post-its que são colados nos blocos correspondentes. FIGURA 2 Canvas com perguntas Fonte: FINOCCHIO JUNIOR, slide 05. Os componentes na cor laranja são definidos da seguinte forma: Justificativa: são os problemas e necessidades não atendidas atualmente ou oportunidades ainda não exploradas. Objetivo do Projeto: é aquilo que o projeto permitirá que seja alcançado ao utilizar todos os esforços e recursos disponíveis. Deve ser escrito no formato SMART (sigla que deriva das iniciais de cinco palavras em inglês que
significam Específico, Mensurável, Alcançável, Realista e Delimitado no Tempo). Benefícios: são as melhorias e o valor agregado que o projeto produzirá. Devem ser quantificáveis e poderão ser mensurados após finalização do projeto com o intuito de verificar se o projeto teve êxito. Os componentes na cor roxa são definidos da seguinte forma: Produto: é o que será entregue ao Cliente no final do projeto. Pode ser um produto, um serviço ou um resultado. Requisitos: são as informações de alto nível que o Cliente passa para a Equipe do Projeto sobre o comportamento, funções, qualidade, desempenho e confiabilidade que o produto deverá possuir. É comum colocar os post-its de requisitos mais prioritários no topo do bloco. Os componentes na cor branca são definidos da seguinte forma: Stakeholders externos: são todas as pessoas ou organizações envolvidas ou afetadas pelo projeto e que não trabalham nele; ou Fatores externos: são os fatores que de alguma maneira poderão afetar o planejamento do projeto de maneira significativa. Os stakeholders ou fatores externos devem ser monitorados pelo Gerente do Projeto. Equipe: são todas as pessoas que trabalham no projeto ou fazem entrega para ele. A equipe deve ser controlada pelo Gerente do Projeto ou receber influência do Gerente do Projeto. Os componentes na cor azul são definidos da seguinte forma: Premissas: são suposições dadas como certas no plano do projeto sobre componentes que não estão sob o controle e a influência do Gerente do Projeto. As premissas quando aprovadas pelos Stakeholders, protegem o Gerente do Projeto e garantem que as promessas de tempo e de custo só serão consideradas se as premissas valerem e forem verdadeiras. Grupo de Entregas: são as partes menores que, uma vez integradas, garantirão que o projeto seja concluído. Elas são palpáveis, mensuráveis e verificáveis. Especialistas podem participar da Equipe do Projeto e contribuir sobremaneira para a identificação dessas entregas. Não devem ser identificadas muitas entregas e sim as mais relevantes para que os Stakeholders tenham uma noção lógica do projeto. Na hora de identificar essas entregas deve-se simplificar, agrupar entregas pequenas em entregas maiores e organizar grupos de entregas.
Restrições: são limitações impostas, originadas tanto dos Stakeholders quanto da Equipe do Projeto, que diminuem a liberdade dos membros da equipe para realizar o seu trabalho. Elas devem ser analisadas e respondidas à tempo com soluções viáveis que contribuam para a continuidade do projeto. Para identifica-las no projeto basta que se faça a pergunta: por que não se pode entregar o trabalho antes? Ao responder a essa pergunta tem-se uma ou mais restrições identificadas. Uma restrição bem formulada deve: ser específica, quantificável (quando possível), indicar quem por ela é limitado e indicar quem impõem a restrição. Os componentes na cor verde são definidos da seguinte forma: Riscos: são as incertezas que efetivamente podem afetar os objetivos do projeto. Uma vez identificados, eles deverão ser gerenciados para proteger os objetivos do projeto. Eles podem ser positivos e assim serem chamados de oportunidades; ou negativos e assim receberem a denominação de ameaças. Devem ser identificados tanto os riscos globais do projeto quanto os riscos específicos do projeto. O processo de gerenciamento de riscos prevê as seguintes etapas: identificação, avaliação e destaque para os mais relevantes, desenvolvimento de respostas para os riscos mais relevantes e implantação dessas respostas. Para o risco global do projeto deve-se utilizar uma tabela para categorizar e avaliar os riscos do projeto. Em um post-it grande coloca-se apenas as categorias de riscos do projeto que são mais relevantes. O post-it receberá esses riscos e a classificação do nível de risco global será igual ao resultado da classificação da categoria de maior relevância. Os riscos específicos do projeto devem ser descritos segundo o formato Causa Risco Efeito. Eles devem ser identificados ao examinar ou analisar os componentes do Canvas até então definidos. Apenas os riscos específicos mais relevantes deverão ser colocados em post-its. Na base desses post-its devem ser informados a probabilidade de ocorrência e o grau de impacto do risco identificado. Linha do Tempo: não representa uma precisão absoluta de quando as entregas serão feitas para o Cliente. É definida através do julgamento das pessoas que estão elaborando o canvas. São assumidas datas de compromisso das entregas. Uma boa estratégia a ser seguida é dividir a linha do tempo do projeto em 4 partes iguais (entre a data de início do projeto e de término do projeto), reordenar os grupos de entrega numa sequencia de liberação e colar post-its pequenos em cada uma das partes da linha do tempo para indicar quando cada entrega será disponibilizada.
Custos: são estimados por grupos de entrega em ordens de grandeza. É adicionada ao custo total do projeto uma reserva proporcional ao risco do projeto. Quanto maior o risco maior essa reserva de contingência. Para simplificar pode decompor os custos em outros elementos menores como trabalho, material e contratação. Isso não é mandatório, podem ser definidos outros elementos que não esses, segundo as especificidades do projeto ou mesmo da cultura organizacional. b) Integrar: nessa etapa é checado se há consistência entre os blocos do canvas. A metodologia PMC fornece um Protocolo de Integração que é um conjunto de verificações predeterminadas e que são feitas numa sequencia coesiva. São 8 os passos desse protocolo: Passo 1: os pontos mencionados nas justificativas são sanados? Passo 2: o objetivo se revela suficiente e necessário? Passo 3: todos os requisitos têm dono e definem o produto? Passo 4: estão subordinados ao projeto aqueles que precisam estar? Passo 5: objetivemos convergência formulando premissas válidas? Passo 6: as limitações aplicáveis ao trabalho estão identificadas na forma de restrições? Passo 7: os riscos cobrem o que já sabemos do projeto e vislumbram, ao mesmo tempo, o que ainda não sabemos? Passo 8: o cronograma e o orçamento estão orientados por entregas? c) Resolver: nessa etapa é identificado se há indefinições, falta de informação ou contradições no projeto. A qualquer tipo de problema como esses apresentados, dáse o nome de nó. O nó nada mais é que um ponto que estrangula o planejamento dali para adiante e que, portanto, precisa ser desatado para restaurar o fluxo de informações do projeto. A etapa de resolução do projeto é realizada seguindo o mesmo fluxo do trabalho da etapa de concepção, respeitando a ordem das questões fundamentais. Ao ler e analisar o projeto nessa sequencia as pessoas envolvidas na construção do canvas perceberão os problemas e para isso terão que seguir passos fundamentais para resolver o projeto. São 3 os passos de resolução de projetos: Identificar o nó: caracterizar bem qual é o problema que impede a concepção do projeto; Lição de casa: levar o problema para a organização e dar espaço para propostas; Alterar canvas: com a solução em mãos, avançar na concepção do plano.
d) Comunicar / Compartilhar: nessa etapa o plano do projeto visual estará disponível para as Partes Interessadas e poderá ser utilizado como entrada para a elaboração de outros documentos tais como cronogramas e apresentações do projeto. A equipe necessária para planejar o projeto através dessa metodologia deve ser formada por pelo menos um profissional que domine os conceitos básicos de gerenciamento de projetos, por outra pessoa que conheça bastante do negócio a ser discutido e por outro integrante que contribua com críticas ao desenho de plano de projeto proposto. Vale à pena mesclar nessa equipe pessoas com mais experiência e pessoas com pouca experiência nos assuntos abordados de tal forma que o conhecimento seja compartilhado e que novas ideias possam surgir e ser aproveitadas no projeto. 3 BENEFÍCIOS DO USO DA METODOLOGIA EM STARTUPS BRASILEIRAS A empresa mineira Siteware possui em torno de 30 profissionais, 40 clientes e desenvolve projetos de gestão para os segmentos de saúde, mineração e varejo. Segundo Ladeira, para novos projetos eles utilizam o PMC. Já construíram um produto interno chamado MEETINGs que reuniu em torno de 20 profissionais da empresa. Os principais benefícios oferecidos pelo PMC apontados por ele foram: a) Melhoria da comunicação e do alinhamento de todos os envolvidos direta ou indiretamente com o projeto; b) Melhoria da qualidade do projeto e do produto após maiores contribuições das pessoas envolvidas; c) Plano em uma única folha de papel A1 facilitando a identificação de inconsistências e riscos do projeto que só poderiam ser visualizado tardiamente; d) Aderência ao PMBOK. Porém, salienta que o PMC não é uma ferramenta para a gestão de projetos e que, portanto, não pode ser utilizado para esse fim. Ele é a vitrine do projeto, mas o dia-a-dia, o que precisa ser feito, os reports do andamento do projeto, eventuais riscos e ações mitigadoras, o cronograma detalhado, etc. exigem o uso de outras ferramentas. (LADEIRA). Na entrevista do professor Finocchio, idealizador do Project Model Canvas, ele diz que É mais fácil pensar e planejar visualmente. E acrescenta que seu objetivo foi fornecer uma ferramenta prática para organizar as ideias, deixar claro os objetivos e fases e tornar todo o
processo compreensível rapidamente mesmo para quem não tem familiaridade com os conceitos de gerenciamento de projetos. 4 CONSIDERAÇÕES FINAIS A utilização da metodologia PMC é indicada mesmo para aquelas pessoas que não possuem fluência em gestão de projetos, pois os conceitos básicos, necessários para o preenchimento do canvas, são muito bem explicados. Finocchio (2014) apresenta vários exemplos que facilitam a assimilação desses conceitos. Além da etapa de concepção, as fases de integração, resolução e comunicação são; da mesma forma; bem explicadas e exemplificadas. O objetivo principal da metodologia que é, de forma colaborativa, ter o modelo mental do projeto em uma única folha pode ser conseguido com bastante rapidez. Isso não seria possível ao se elaborar um plano de projeto da forma clássica prevista no Guia PMBOK. Apesar disso, os adeptos ao seguimento das práticas previstas no Guia PMBOK podem ficar tranquilos pois o PMC é aderente a elas. Para ter um nível adequado de planejamento do projeto é necessário começar com o preenchimento da tela do PMC, mas isso não é o fim de tudo. O canvas passa a ser um documento de entrada para os processos presentes no PMBOK. As Startups brasileiras em busca por metodologias ágeis e de fácil uso podem encontrar na metodologia Project Model Canvas um ponto inicial para a descoberta das reais necessidades dos seus clientes, necessidades essas que poderão ser traduzidas em um projeto numa folha de papel A1. REFERÊNCIAS FINOCCHIO JÚNIOR, José. Project model Canvas: como conceber projetos em uma única página e transformá-los em agentes de inovação e convergência na organização. Slide 04-05. Disponível em: <http://www.pmcanvas.com.br/wp-content/uploads/2013/02/project- MODEL-CANVAS-APRESENTACAO.ppsx>. Acesso em: 17 set. 2014. FINOCCHIO JÚNIOR, José. Project model Canvas: gerenciamento de projetos sem burocracia. 1. ed. Rio de Janeiro: Elsevier, 2013. 229 p. FINOCCHIO JÚNIOR, José. Project Model Canvas: planejamento em uma folha!: compreendendo ambiente e necessidades para uma melhor estruturação do projeto. Revista Mundo PM, Curitiba, ano 9, n. 49, p. 70-79, 2013. Entrevista concedida à Revista Mundo PM, a Iago Malachias. Disponível em: <http://www.pmcanvas.com.br/wpcontent/uploads/2013/05/artigo-pmcanvas.pdf>. Acesso em: 17 set. 2014. GITAHY, Yuri. Afinal, o que é uma startup?. Exame.com, São Paulo. Entrevista concedida à Revista Exame, a Daniela Moreira. Disponível em: <http://exame.abril.com.br/pme/noticias/o-que-e-uma-startup/>. Acesso em: 19 set. 2014.
LADEIRA, Marcello. Re: Startup - Pesquisa de Metodologias de Gestão de Projetos [mensagem pessoal]. Mensagem recebida por <anapaula@gqsinformatica.com.br> em 18 set. 2014. PESCE, Bel. A menina do vale: como o empreendedorismo pode mudar sua vida. Rio de Janeiro: Casa da Palavra, 2012. 158 p. RIES, Eric. A startup enxuta: como os empreendedores atuais utilizam a inovação contínua para criar empresas extremamente bem-sucedidas. São Paulo: Lua de Papel, 2012. 274 p. CUKIER, Daniel. Agile em Startups. InfoQ Brasil. Entrevista concedida à InfoQ Brasil, a Marcelo Cenerino. Disponível em: <http://www.infoq.com/br/interviews/agile-startups>. Acesso em: 17 set. 2014.