Em artigo anterior procurei discutir como, a partir da análise competitiva do ambiente, chegamos à definição de Diretrizes Estratégicas da organização, elementos chave no Planejamento Estratégico.
Agora, seguiremos este roadmap a fim de definirmos quais as práticas de gestão, e as tecnologias que as sustentam, devem ser selecionadas, compondo o portifólio de projetos estratégicos.
Inicialmente, se faz necessário entendermos de forma clara os conceitos de Metodologias e Tecnologias, aplicadas ao contexto da gestão das organizações.
Novamente recorro aos valiosos conhecimentos adquiridos em minhas aulas com o Prof. Oswaldo L. Agostinho, durante meu doutoramento na FEM/UNICAMP.
Metodologias são o conjunto de regras, meios e conhecimentos, dispostos em ordem lógica e aplicado às atividades dos processos de negócio gerenciais ou tecnológicos, destinado a atender e prover os atributos de competitividade interna da organização ou sistema de negócio
Oswaldo L. Agostinho
Ou seja, metodologias são práticas de gestão, logica e harmonicamente empregadas nos processos da organização, visam conferir atributos competitivos, capacitando o enfrentamento dos estímulos do meio exterior.
Agora vamos entender o que são Tecnologias…
Tecnologia pode ser entendida como todo conhecimento, produto. processo, ferramenta, método ou sistema empregado na criação de bens ou provimento de serviços.
Oswaldo L. Agostinho
Assim as Tecnologias sustentam as Metodologias, priorizadas mediante as Diretrizes Estratégicas.
Pensar de forma estratégica vai muito além de uma análise de ambiente e representação em uma matriz SWOT, implica em priorizar os agentes estressores externos (estímulos) e definir, à luz da Missão, Visão e Competências Centrais, quais atributos precisam ser desenvolvidos.
Estes gaps, ou oportunidades de desenvolvimento de atributos, definem Diretrizes Estratégicas, as quais, como já mencionado, se desdobram em Metodologias e Tecnologias.
A definição das Tecnologias a serem implementadas compõe o Portifólio Estratégico da Organização.
Isso sim é pensar Estratégia em alto nível, e não copiar o que os concorrentes estão fazendo, por puro modismo.
Pense nisso…seguem sugestões de materiais para aprofundamento no tema.
Agostinho, O. L. (1995). Integração Estrutural dos Sistemas de Manufatura como Pré Requisito de Competitividade. Tese de Livre Docência, Universidade Estadual de Campinas, Campinas, SP, Brasil.
Agostinho, O. L. (2014). Methodology to prioritize business and technology strategies to provide enterprise competitiveness. Proceedings of 2014 International Conference on Engineering, Technology, and Innovation – ICE 2014, Bergamo, Italy. DOI: 10.1109/ICE.2014.6871536.
Agostinho, O. L. (2015). Proposal of organization framework model, using business processes and hierarchical patterns to provide agility and flexibility in competitiveness environments. Procedia Engineering. 131, 401-409. DOI: 10.1016/j.proeng.2015.12.433.
Como já mencionado nos artigos anteriores, tais boas práticas foram reunidas ao longo de 20 anos de atividade profissional minha (e de colegas) com projetos, em diferentes organizações.
Vamos então às últimas 5 boas práticas:
BP#11: A partir das entregas do projeto, crie uma WBS para obter uma visão comum do escopo do projeto.
Certamente aqui os defensores do ágil vão “torcer o nariz” pelo fato desta ferramenta ser mais ortodoxa mas, por favor, me deem tempo para explicar.
Como já explorado na BP#10, entregas são um importante instrumento para materializar os resultados do projeto, inclusive auxiliando na árdua tarefa de “alimentar os tigres” corporativos (alta gestão).
Assim, uma interessante alternativa para melhorar a comunicação com estes e demais stakeholders chave, inclusive seu time, é criar um mapa gráfico do escopo do projeto, mesmo que ele venha a mudar, fruto da evolução na jornada de descoberta e entrega de valor.
Exemplo de WBS. Fonte: O Autor.
Este mapa do escopo, já entendido como evolutivo por natureza, pode ser representado em uma WBS – Work Breakdown Strucutre ou Estrutura Analítica de Projeto (EAP).
Uma WBS ajuda muito em mostrar os elementos do seu desafio, da entrega de valor do projeto, além de ser uma forma evidente (gestão a vista) de mostrar o que já foi feito e o que há por fazer.
Assim, entendo como importante recorrer a este instrumento para “colocar todos na mesma página”, como um GPS do caminhar da execução, pense nisso.
BP#12: Crie um cronograma enxuto do projeto.
Novamente corro o risco de ser mal interpretado aqui, não me refiro nesta boa prática aos cronogramas tradicionais, com muitas tarefas e relações lógicas.
Na minha visão tais cronogramas mais funcionam como uma “camisa de força” para o projeto, prejudicando a adaptabilidade frente aos desafios externos, ao invés de direcionar caminhos…
Um cronograma enxuto, com apenas as macro etapas e deadlines (datas limite) serve para, assim como a WBS, mostrar o caminho que o time seguirá na sua jornada de entrega de valor.
Este caminho, demonstrado desta forma, ajuda inclusive a trazer uma certa segurança ao time, evitando que se sinta perdido, risco observável em cenários de equipes praticando o ágil.
Neste cronograma as entregas podem e devem ser identificadas, associadas aos marcos do projeto (milestones), sem detalhamento de tarefas, visto que tais pormenores serão definidos à medida que o projeto avança e por decisão da equipe.
Um cronograma assim é um belo instrumento para apaziguar os ânimos dos “tigres” corporativos, visto que demonstra o projeto em um racional de entrega, servindo assim como uma ferramenta de stakeholder management.
BP#13: Cuidado ao determinar a relação custo-benefício do projeto.
Este é um tema sério que aflora ao ver apresentações (pitchs) de projetos mal preparadas, orçamentos mal feitos e projeções de retornos ou mal calculadas, ou com otimismo demasiado.
Um pitch é um momento vital para o projeto (e para quem o apresenta), nele a alta gestão fará sua apreciação e teremos o go/no go.
Assim minha recomendação é que qualquer orçamento de projeto seja feito com o apoio de um especialista, que pode ser da área financeira ou do próprio PMO (Project Management Office) da organização.
O mesmo vale para o cálculo dos benefícios…
Uma certeza podemos ter, na hora de apresentar os números (Orçamento e ROI do Projeto) alguém vai perguntar sobre como foram determinados e é necessário ter segurança neste momento, é um teste importante.
Esteja preparado para este momento, busque conhecimento, não ache que sabe o suficiente para fazer estas demonstrações, alinhe antes todos os racionais de cálculo também com o patrocinador (sponsor) do projeto…
Segurança em um pitch é vital, números são a linguagem dos gestores, tenha fluência neste idioma.
BP#14: Seja ágil! Acompanhe a execução do projeto através de um quadro de SCRUM.
Um quadro de SCRUM do projeto, o qual apresenta o conjunto de atividades, nos seus respectivos status (A FAZER/FAZENDO/FEITO) tem uma simplicidade e poder sobre a execução do projeto que não consigo encontrar em outro instrumento, quando o assunto é manter o time focado nas atividades que agregam valor.
Mas é preciso ter um cuidado, é importante que este quadro seja atualizado de forma contínua, assim alguém do time precisa assumir esta responsabilidade, em alguns cenários este indivíduo é o chamado scrum master.
Esta ferramenta é muito eficaz para fazer o acompanhamento da execução, e inclusive não precisa de nenhuma tecnologia rebuscada, basta um simples quadro branco.
“Simplicidade é o mais alto grau da sofisticação”, já dizia Leonardo da Vinci.
Mantenha este quadro em um local visível para todos do time, esta ferramenta inclusive o ajudará a manter o senso de urgência no grupo, condição tão importante, já comentada em nosso artigo anterior, como instrumento de engajamento da equipe.
E agora a última (e não menos importante) boa prática…
BP#15: Arquive toda documentação de forma organizada ao longo do projeto, ao final conduza uma reunião de post mortem.
Em 20 anos de consultoria sou capaz de contar nos dedos de uma das mãos situações em que me deparei com departamentos que faziam uma gestão minimamente adequada da documentação de seus projetos, para fins de arquivamento.
E para isso não estou falando necessariamente de gestão do conhecimento em último grau ou softwares específicos, apenas de uma simples boa vontade em organizar as informações, imaginando que um dia, no futuro, elas podem ser consultadas para algum novo projeto (servindo de lições aprendidas ou lessons learned).
Pois é, frustrante é começar um projeto e saber logo depois que algo muito semelhante foi conduzido anos atrás, e a informação se perdeu, particularmente nos notebooks de seus idealizadores, que agora estão em outras organizações…
Daí a constatação de “reinventar a roda” tem seu espaço, desperdiçando energia com indivíduos comentendo os mesmos erros, mesmo por ignorância…
Melhor do que aprender com os próprios erros, é aprender com os dos outros.
Minha dica aqui é, se não há uma boa gestão de documentos dos projetos na sua área ou organização, comece a fazer esta gestão a partir do seu projeto, reúna as principais reflexões, entregas, resultados de testes, documentações de provas de conceito, além dos documentos mais tradicionais, como cronogramas e especificações de produto.
Organize em pastas, quer físicas ou na rede, digo na rede pois quantas não foram as vezes que tais documentos estavam em um computador em particular e, como a sorte nem sempre sorri para nós, uma falha na máquina fez todo o conteúdo do seu HD ser perdido, e aí se foram as informações.
Outra alternativa é o uso de pastas na nuvem, a qual eu indico e tenho feito intenso uso.
Uma dica final é conduzir uma reunião de post mortem com os principais stakeholders e o time ao final do projeto, a fim de coletar como foi a experiência do projeto para eles, quais os momentos mais difíceis, quais os mais fáceis, que comportamentos precisamos mudar e que lições tiramos para futuros projetos.
Como sei que é difícil reunir todos, o uso de teleconferência é uma alternativa, você pode organizar um webinar para fazer isso, é até um meio elegante de “fechar” o projeto.
Muito bem, aqui concluímos nossa jornada pelas 15 boas práticas, espero que você tenha gostado, procurei organizá-las e detalhar cada uma delas de forma que você possa aplicá-las nos seus projetos.
Se você gostou destes artigos, compartilhe-os na sua organização! A intenção é esta, trazer conteúdo de qualidade aos amigos que vivem a dura (e emocionante) rotina de gestão de projetos.
Olá! Vamos continuar neste artigo a apresentação da sequencia de boas práticas para uma boa condução de projetos…
Aqui vamos tratar de mais 5 boas práticas (6 a 10), se você não leu as 5 primeiras, segue o link do primeiro artigo.
Como comentei no artigo anterior, todas estas boas práticas são fruto da minha experiência (e de meus colegas) nestes últimos 20 anos como consultor na área, envolvido em projetos de diferentes naturezas e em diferentes ramos de negócio.
Vamos então às boas práticas…
BP#6: Crie uma lista de características da sua solução (ou requisitos), tenha conciência que ela evoluirá à medida que as hipóteses da solução forem comprovadas (ou não).
Como citamos na BP#5, projetos envolvem o estabelecimento de hipóteses para a solução de um problema (ou explorar uma demanda), tais hipóteses estão atreladas às características daquilo que vai ser construído (um produto e/ou serviço).
Os mais conservadores em gestão de projetos chamarão tais características de requisitos, os agilistas chamarão de user stories, não importa a denominação, tais atributos da solução são uma ótima forma de descrever o que vai ser criado, clarificando os horizontes para os que vão usufruir dela, assim como para o time que vai construí-la, servindo de direcionador (uma bússola) para os trabalhos.
Muitos até relacionam tais características a serem criadas com o chamado Sprint Backlog, que nada mais é que uma lista de coisas que precisam ser feitas, na forma de funcionalidades (features) da solução.
Deixo claro aqui que isto vale para a grande maioria dos projetos, e não somente para os de software…
BP#7: Identifique os stakeholders (partes afetadas), entenda como influenciá-los em favor da condução do projeto.
Um projeto é um evento político, explico, a equipe de projeto e a comunidade de stakeholders (partes afetadas) que assiste os trabalhos tem demandas e percepções diferentes. Fazer com que todos caminhem para um objetivo comum consiste na da arte da política de condução de um projeto.
Assim, para conseguir esta coesão, inicialmente faz-se necessário entender como cada indivíduo enxerga o projeto, fazendo uso da empatia.
Compreendendo como cada stakeholder é afetado parte-se para a segunda e terceira etapas do gerenciamento político de um projeto, priorização e resposta.
Como priorização entendo em identificar quais são os stakeholders que podem impactar de forma significativa a entrega de valor do projeto (o seu legado), o que não necessariamente quer dizer que estamos tratando de um gerente ou executivo, pois um usuário de uma solução mal envolvido no projeto pode por muita coisa a perder…
Cabe ressaltar que um dos princípios da geração de hipóteses em projetos é testá-las, e quem vai fazer isto e nos dar feedbacks é peça-chave na nossa jornada de entrega de valor e descoberta.
Identificados os stakeholders mais importantes, inicia-se uma reflexão sobre como se pode obter o apoio de cada um deles (etapa de resposta), Alan Cohen, autor do Livro “Influência sem autoridade” costuma dizer que todos, de alguma forma, esperam algum tipo de recompensa. Exemplos de recompensas podem ser oferecer um desafio ao indivíduo, dar um significado ao seu trabalho, dar-lhe visibilidade, etc, ou seja, entender como se pode estabelecer uma zona de sombreamento entre os interesses e objetivos do projeto e os interesses e objetivos do indivíduo.
Em alguns cenários stakeholders relevantes podem nos trazer novas demandas, a fim de criarmos esta zona de sombreamento, o que pode, em última instância, a reconfigurações no projeto. Destaco que isto está longe de ser um descontrole no projeto, mas precisamos sempre ter em mente o velho ditado que “o melhor é inimigo do bom” e política (no bom sentido) faz parte do contexto.
BP#8: Cuide do engajamento do time.
Certamente você já deve ter ouvido uma dica desta natureza em outros posts, mas aqui queria deixar algumas questões um pouco mais práticas.
Além de identificar o que motiva cada indivíduo na equipe, é pertinente estabelecer um senso de urgência, a fim de “elevar a temperatura” do time.
John Kotter, autor do livro “Liderando mudanças” explica que o senso de urgência é o combustível da equipe, assim estabelecer metas ou entregas muito distantes não funciona, pois o indivíduo em última instância se questiona…”Em que isto vai mudar minha vida agora?”
Logo a procrastinação, este fantasma corporativo, precisa ser exorcizado, metas próximas são uma alternativa, muitos denominam tais metas como quick wins, ou seja, vitórias de curto prazo.
Cumpridas estas vitórias, nada mais justo que pequenas comemorações, a fim de estabelecer uma retribuição ao time, um reconhecimento pelo trabalho feito.
Só tome um cuidado, não comemore em demasia, se não o jogo vira e a equipe acha que “já ganhou”, ok?
Um outro ponto a se comentar que ajuda muito no engajamento do time é a presença do líder, assim nada de ficar no seu computador disparando emails somente fazendo cobranças (já vi muito disso…), é preciso ter skin on the game, ou seja, estar junto do time.
Vamos esclarecer melhor este ponto, visite a equipe com maior frequencia, tenha conversas com cada um deles (não necessariamente sobre o projeto), procure identificar reais ou potenciais bloqueios para a realização dos seus trabalhos e atue como um jardineiro.
Um jardineiro!?! Isso mesmo, o novo paradigma de liderança não é mais o de um comandante, mas de um jardineiro que identifica impedimentos e procura retirá-los, permitindo que cada indivíduo (ou planta do jardim), floresça e se desenvolva melhor.
BP#9: Identifique quais são as premissas e restrições do projeto, entenda suas relações com os riscos.
Acho que aqui é importante trazer as definições de premissa, restrição e risco, visto que em workshops e consultorias rotineiramente me deparo com situações as quais revelam a confusão dos termos.
Como restrição podemos entender todos os fatores que limitam as opções do projeto, quer em termos de tecnologia, pessoas, recursos financeiros e tempo. Também é muito comum verificar questões de compliance como restrições, visto que a adequação às boas condutas da organização, e em última instância às leis, servem de condições de contorno na definição de hipóteses e realização de testes.
As premissas podem ser entendidas como fatores que assumimos como verdadeiros no contexto do projeto, ou seja, são pontos de partida nos quais o projeto é construído.
Costumo usar a seguinte metáfora para explicar este conceito, imagine que seu projeto é uma grande torre, na sua base temos os alicerces de concreto, entenda cada alicerce como uma premissa, note que ele não faz parte da torre (o seu projeto), mas depende totalmente dele para não cair.
Um exemplo que acabo me deparando com frequencia é o caso de projetos na área de business intelligence, os quais buscam gerar dashboards para análise de dados, gerando informação para a tomada de decisão da alta gestão, seja na área financeira ou operacional.
Nestes projetos uma premissa certamente está na fidedignidade dos dados que serão utilizados na criação do dashboard, pela minha experiência esta premissa costuma falhar em muitos casos e o projeto acaba atrasando porque foi necessário enxertar uma etapa de tratamento de dados (remoção de redundâncias, verificação de valores, adequação de formato do banco de dados, etc).
Daí que se conclui que é importante estudar o contexto do projeto para mapear as premissas, visto que elas são fontes de riscos para o projeto.
Deixo aqui o link de um outro artigo interessante que escrevi sobre competências necessárias para a boa condução de um projeto, nele detalho mais quais as questões do contexto que precisam ser levadas em conta.
Há quase um axioma nesta questão….“toda premissa tem ao menos um risco associado”.
Bom, agora que mencionamos a relação entre premissas e riscos, precisamos definir o que é um risco.
Risco é um evento que pode ou não acontecer e, em acontecendo, trará um impacto positivo (isso é bem raro) ou negativo ao projeto, este impacto normalmente se materializa em atrasos nas entregas por conta de retrabalho.
Assim é importante mapear os riscos do projeto, pode-se começar analisando cada uma das premissas e refletindo….“e se esta premissa se mostrar falsa, qual ou quais serão os desdobramentos sobre o projeto?”
Uma simples pergunta como esta levada ao time pode levantar várias respostas ou, como gosto de dizer, contramedidas para reduzir a chance do risco acontecer ou minimizar os impactos.
Tais reflexões do time pela minha experiência acabam em contramedidas que trazem em um ligeiro aumento no prazo, por conta da criação de contingências, mas é importante dizer que isto faz parte do contexto, pois o que se quer é aumentar a chance de sucesso (entrega de valor) do projeto.
Riscos devem ser mapeados continuamente ao longo dos sprints, incite este tipo de pensamento no time, o maior inimigo neste momento é o excesso de confiança…
BP#10: Defina entregas bem claras para demonstrar a geração de valor contínua do projeto.
Alguns chamam as entregas pelo seu termo em inglês: deliverables. Entende-se entrega como qualquer artefato gerado ao longo do projeto, pode ser o resultado de um teste, a criação de um protótipo, a validação de uma hipótese, todos estes e mais outros momentos importantes do projeto, os quais relacionam a materialização de uma descoberta à linha do tempo.
Este tipo de artifício é ótimo para acalmar os ânimos dos executivos, os quais normalmente estão ansiosos por resultados…Assim não demore muito para gerar entregas, crie uma linha do tempo macro do projeto com, pela minha experiência, ao menos uma entrega importante por mês.
Aliás este conceito vai de encontro com as quick wins que mencionamos na prática #8.
Uma expressão que se costuma ouvir neste caso é “temos que alimentar os tigres…”, entendendo o tigre como um animal corporativo (executivo) ansioso por resultados. Assim, gere entregas continuamente, mesmo dentro do contexto dos sprints (geração de hipóteses, condução de testes e tratamento dos feedbacks).
Esta estratégia te dá um pouco mais de calma para trabalhar com a equipe, reduzindo a pressão externa.
Muito bem, concluímos aqui o segundo artigo, falamos de mais 5 boas práticas de gestão de projetos, perfeitamente aplicáveis quer em um contexto ágil ou mais ortodoxo.
Aguarde o próximo artigo com mais 5 boas práticas… Espero que este material o ajude a ter melhores resultados em seus projetos, quer pessoais ou profissionais…
Após 20 anos envolvido com projetos em diferentes organizções e de diferentes naturezas, consegui reunir um conjunto de 15 boas práticas, fruto da reflexão quer minha, quer de experiências de colegas…
Encontrei que o conjunto de boas práticas, em um total de 15, se mostraram muito bem alinhadas com uma ferramenta conhecida por alguns, criada pelo colega José Finocchio Jr., o Project Model Canvas.
Assim quero compartilhar estas boas práticas com você, a fim de que, através desta troca de experiências, consigamos melhorar a assertividade com a qual projetos são idealizados, planejados e executados, tendo o objetivo final um legado de valor para as organizações e sociedade.
Então vamos às boas práticas… Neste artigo vou citar as 5 primeiras, depois publicaremos mais dois artigos neste blog a fim de trazer as demais práticas, agrupadas de 5 em 5…
BP#1: Tenha uma ferramenta que, em um único local e em uma única visão, traga de forma organizada as informações essenciais do projeto, o Project Model Canvas é uma excelente alternativa.
Um dos maiores problemas que vivencio em projetos é a falta de integração entre os elementos, a começar pelo escopo, tempo e custos, mas é comum observar projetos com uma carência de clareza nos objetivos, benefícios mal descritos, os quais levam a requisitos definidos sem levar em consideração o legado para a organização, a resposta a uma dor, quer de um indivíduo, quer materializada na deficiência de um processo.
O Project Model Canvas é uma ferramenta bem interessante, costumo dizer em meus workshops que nele podemos ter uma verdadeira noção das ligações invisíveis, mas essenciais, dos elementos do projeto, como se fosse uma estrutura de uma grande construção.
Esta visão sistêmica apurada responde à muitos problemas que vejo durante a fase de execução.
BP#2: Defina um objetivo SMART para o projeto, alinhe-o com seu gestor ou patrocinador, este objetivo o ajudará a manter o foco.
Falta de foco é um problema sério em projetos, muitas são as demandas e é fácil perder o controle.
Às vezes é preciso dizer não para os anseios dos stakeholders (ou partes influenciadas), o que nem sempre é fácil, pois alguns tem grande poder na organização.
Por isso o estabelecimento de um objetivo SMART (Específico/Mensurável/Atingível/Relevante/Atrelado ao Tempo) pode ajudar a definir uma bússola para o projeto, pois é preciso dizer que um plano é passível de mudança, mas mudar o legado ou, em outras palavras, o valor a ser entregue, não.
O objetivo SMART materializa muito bem este legado.
Uma forma alternativa que também observo ser empregada hoje é o uso de OKR´s (Objectives & Key Results), o qual tenho encontrado como uma forma bem elegante de estabelecer a régua de sucesso do projeto.
BP#3: Faça um bom benchmarking! (ou “não reinvente a roda”)
Bom, quando o assunto é benchmarking, ou seja, pesquisar lições aprendidas de projetos semelhantes, usualmente vejo dois cenários: ou não temos estas lições registradas, ou nós que estamos conduzindo o projeto achamos que não precisamos delas.
Suspeito que nos dois casos estamos enganados, primeiro porque há uma boa chance de encontrarmos alguém dentro da organização que já trabalhou com um projeto semelhante…
Costumo dizer que pouco conhecemos das organizações que trabalhamos, ou que prestamos serviços…
No segundo caso, é comum sermos acometidos pela soberba e acreditarmos que não precisamos de ninguém , até por crermos que assim faremos um planejamento mais rápido, ledo engano…
Melhor que aprender com seus próprios erros, é aprender com os dos outros…Um pouco de humildade faz bem nesta hora…
BP#4: Crie um cenário “As is” e “To be” do projeto, faça uma boa avaliação do seu custo-benefício.
Nenhum projeto é aprovado sem uma boa argumentação, na forma de uma apresentação ou pitch, assim um possível patrocinador, para entender o projeto e seu legado, precisa entender o contexto atual (“As is”) e como será o novo contexto (“To be”), ou seja, como será o novo cenário com o produto do projeto “rodando”, quer seja uma melhoria de processo, um novo produto ou ainda um serviço para um cliente interno ou externo.
A definição destes cenários é muito útil também para manter o foco da equipe, é normal durante a execução o time identificar oportunidades de implantação de novas funcionalidades ou melhorias mas, em muitos casos, pela minha experiência, são mais fruto de um desejo da equipe que de uma real necessidade, logo precisamos estar atentos para não perder o rumo.
Aqui vale um ditado…”Quem muito abraça pouco aperta”…Pense nisso.
BP#5: Procure criar um protótipo ou faça um piloto da solução, não demore muito para testá-la.
Aqui cabe dizer que um projeto tem dois momentos bem distintos, o primeiro no qual faz-se uma imersão no problema, a fim de entender sua estrutura e implicações no modelo de negócio (pessoas, processos e infraestrutura). E um segundo no qual hipóteses são geradas…
Hipótese nada mais é que um bom “palpite” para resolver o problema, fruto do conhecimento da equipe.
Mas hipóteses precisam ser testadas e o quanto antes isto ocorrer, melhor, assim a criação de testes piloto, uso de protótipos (MVP´s: Produto Mínimo Viável) e demais artifícios para comprovar se as hipóteses estão corretas precisa ocorrer, na minha opinião, ao menos logo no final do primeiro terço do projeto (ex: em um projeto de 6 meses, lá pelo final do segundo mês seria importante ter um teste em curso…).
Esta estratégia é interessante, inclusive bebe das fontes do agilismo, visto que, se a hipótese se mostrar falsa (e isto pode ocorrer, apesar de todo conhecimento e experiência do time), o erro pode levar a novas hipóteses, em uma rota evolutiva, com mais chances de sucesso.
Por ora seguimos até aqui, no próximo artigo vamos discutir mais 5 boas práticas.
Espero que tenha gostado, desejo que estas boas práticas lhe façam refletir melhor sobre como gerir projetos, com mais chances de um final feliz…
Em minhas atividades como consultor em projetos sempre me deparo com uma questão que aflige as equipes…Como definir o objetivo do projeto?
Uma questão simples mas, dadas as implicações, de difícil resposta.
Explico, um objetivo bem escrito deve servir de referência em todas as decisões futuras da equipe quanto ao planejamento e execução, assim como na verificação de, em que grau, o projeto ao seu final foi bem sucedido.
Usualmente, ao pensarmos em como escrever objetivos de forma inteligente, pensamos no conceito SMART, ou seja, um objetivo bem escrito precisa ser Específico (Specific), Mensurável (Measurable), Attainable (Atingível), Relevante (Rellevant) e atrelado ao Tempo (Time Bound).
Mas ainda sinto que falta algo neste conceito…Projetos por natureza respondem às dores da organização, que no final das contas são oriundas de pressões competitivas.
À parte se a organização está agindo de forma reativa ou proativa, projetos são respostas que, através das soluções que almejam implementar, procuram trazer consequências positivas aos sistemas de negócio que se propõem a contribuir.
Aqui está o ponto, o conceito SMART, no contexto do estabelecimento de objetivos para projetos, em minha opinião, não atende completamente à esta necessidade.
O SMART tenta fazer uma ponte entre as demandas estratégicas da organização e a implantação de respostas táticas (projetos) procurando ser um “meio termo”, ou seja, não é totalmente ligado na estratégia e tão pouco traz de forma clara quais os indicadores que deve-se perseguir a fim de comprovar o valor entregue ao negócio.
Um outro ponto a considerar é que, por praxe, recomenda-se que o objetivo SMART tenha, em sua declaração, uma descrição preliminar da abordagem a ser adotada a fim de cumprir o objetivo.
Mas, será esta abordagem está correta? Será que existe uma abordagem correta? (Mito do plano perfeito)
Não seria melhor pensar que o que existe de fato é uma disposição a entregar valor ao negócio, mediante indicadores de sucesso mais claros?
É aí que o conceito de OKR (Objectives and Key Results) entra, uma prática que nasceu na Intel e nos últimos anos adotada em empresas de vanguarda (Google por exemplo), com o OKR se procura explicitar um Objetivo (Objective) inspirador, desafiador em certa medida, fortemente ligado às dores da organização, que por sua vez são derivadas das pressões competitivas.
Os KR´s (Key Results/Resultados-Chave) são métricas (indicadores) que mostrarão qual o grau em que o objetivo está sendo atingido (fullfillment), Objetivos e Resultados-Chave estão arranjados hierarquicamente e ligam-se aos projetos/iniciativas da organização, conforme esquema a seguir.
OKR Framework
Assim, em minha opinião os OKR´s, por terem elementos exclusivos às questões estratégicas e táticas, servem como melhor régua para definir a trilha de entrega de valor dos projetos/iniciativas conduzidas em uma organização.
Em um contexto de Agilismo isto fica ainda mais evidente, visto que não temos um escopo definido (o plano perfeito), mas sim hipóteses que são testadas de forma rápída (sprints) e sua eficácia atestada mediante os desdobramentos sobre os KR´s.
Não posso deixar de pensar que isto muito me parece com um um PDCA (Plan/Do/Check/Act) melhorado, com ciclos rápidos (1 a 2 semanas) e feedbacks, os quais correspondem ao passo A (Act) do ciclo de Deming, permitindo que um novo ciclo se inicie, ou um novo sprint.
Se você se interessou pelo tema, visite o link abaixo do site da Endeavour sobre OKR´s:
During the past month, on my readings about philosophy, I came to Nietzsche´s book “Thus spoke Zarathustra”. A reading that has brought me important reflections about life, in the spheres of knowing, doing and particularly acting, as taught by the great philosopher Aristotle.
In one of the excerpts of the book, I came across a one-page text that seems to me have come from a blog by an agile management expert.
Let´s go to the excerpt then…
“The higher its type, always the seldomer doth a thing succeed. Ye higher men here, have you ye not all been failures?”
And follow…
“What wonder even that ye have failed and only half-succeded, ye half-shattered ones! Doth not man´s future strive and struggle in you?”
See that here he seeks to motivate those who chase superior results, already saying that the error is a natural result of the process…
…Or be my friend, no mistake, no growth, so never believe in fairy tales, what is there is work, many mistakes, few hits, you know?
This is the essence of the agile, David Kelley already said (did he read Nietzsche?) “Failure sucks, but instructs.”
And there is more…
“What wonder that many a vessel shattereth! Learn to laugh at yourselves, as ye ought to laugh! Ye higher men. Oh, how much is still possible!”
That is, here he gives us a hint to view error as something positive, I remember he wrote this in 1885! Brilliant isn’t it!
Ah, he follows and gives another important tip…
“Set around you small, good, perfect things, ye higher men. Their golden maturity healeth the heart. The perfect teacheth one to hope.”
When I read this I thought…look at the guidance for creating small wins, the so-called quick wins, which help us solidifying results, cheer up team morale and demonstrate to those around us that “We are on the right way.”
Friends, I am increasingly convinced that we have a lot to learn from the great masters, there is a lot of concepts today with the label NEW that, in fact, has already been thought out and properly debugged in the classics.
I recommend this reading “Thus spoke Zarathustra” by Nietzsche, strong at times, revealing at others, in the end (I´m coming to the end), I feel closer to my truth.
