BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Planejamento de iniciativas ágeis com roadmaps

Planejamento de iniciativas ágeis com roadmaps

Pontos Principais

  • O Agile foi criado por profissionais de software para discutir as melhores maneiras de desenvolvimento, porém, fornece pouca orientação para os gerentes sobre o que ou como devem fazer o serviço;

  • Estruturas ágeis comuns não explicam como o gerente de produto obtém orçamento ou uma equipe de desenvolvimento, como projetam o produto e a solução ou como integram a iniciativa com o resto da empresa e como gerenciam as expectativas;

  • A maioria das empresas reage a esse distanciamento entre o gerenciamento e o Agile mantendo com abordagens híbridas e, em cascata, orientadas a planos que tenham histórico de ultrapassar o orçamento e entregar muito menos valor do que o previsto;

  • Os roadmaps ágeis constroem uma ponte entre as equipes técnicas e de gerenciamento, adicionando produto, projeto, arquitetura e planejamento de UX a iniciativas ágeis para que possamos obter o financiamento e o suporte necessários para entregar uma iniciativa ágil;

  • Os roadmaps permitem o planejamento de iniciativas em uma fração do tempo e do custo dos métodos preditivos, o que significa que podemos entregar benefícios antecipadamente e a um custo menor.

A situação

A maioria das empresas utiliza projetos para entregar as iniciativas.

O Project Management Institute estima que haja pelo menos 66 milhões de gerentes de projeto no mundo, com pelo menos 25% deles alocados na área de TI. Isso significa que provavelmente existam pelo menos 17 milhões de projetos de TI em andamento ao mesmo tempo.

Embora haja muita conversa na comunidade Agile sobre a mudança de projetos para equipes de entrega com financiamento contínuo, a pesquisa mostra que a grande maioria das empresas ainda financia iniciativas por meio de projetos. A pesquisa do Gartner de 2019 mostra que 89% das empresas estão usando um processo de orçamento anual tradicional para novas iniciativas. Uma pesquisa feita pela mesma instituição, , mostra que, embora muitas empresas queiram mudar para um modelo centrado no produto, 85% ainda estão usando um modelo centrado no projeto.

O problema

Poucos projetos atendem às expectativas de negócio

Qualquer pessoa que já trabalhou na indústria digital por um tempo sabe que a maioria das iniciativas de software, especialmente as de grande escala, são seriamente problemáticas. Uma pesquisa do Project Management Institute mostra que apenas 20% dos projetos cumpriram sua meta, dentro do prazo e do orçamento, 65% foram ou não cumpriram as metas de negócio, prazo ou custo e 15% falharam completamente. A pesquisa do Standish Group mostra resultados semelhantes.

 

Uma pesquisa da McKinsey e da Universidade de Oxford mostra que, em média, 45% dos grandes projetos de TI ultrapassam o orçamento e 7% ultrapassam o tempo, enquanto 56% deles entregam menos valor do que o previsto.

A maioria dos recursos não são usados

Ao mesmo tempo, a pesquisa do Standish Group sobre produtos internos mostra que as pessoas usam apenas um terço dos recursos que foram desenvolvidos. A pesquisa é apoiada por uma recente pesquisa da Pendo, que mostra que os clientes não usam 80% dos recursos de um típico produto de software na nuvem. Esta pesquisa mostra que estamos desperdiçando de 50 a 80% do esforço na maioria das iniciativas digitais.

A maioria dos projetos é baseada em uma grande fase de planejamento inicial

De acordo com a pesquisa do PMI, setenta por cento das empresas estão entregando projetos usando uma abordagem preditiva (em cascata) ou uma abordagem híbrida (water-scrum-fall). Uma pesquisa da University of Southern Denmark aborda a mesma questão em "O Water-Scrum-Fall é uma realidade? Um estudo sobre o uso de práticas de desenvolvimento ágeis e tradicionais" (artigo em inglês).

Water-Scrum-fall (Agile híbrido) é o gerenciamento preditivo de projetos tradicional com a construção e algumas outras etapas feitas em sprints.

Empiricamente falando, essa abordagem "Agile Híbrida" ou Iterativa, cria muitos conflitos, confusões e solicitações de mudança que geram resultados tão ruins, senão piores, do que um processo de desenvolvimento tradicional feito em fases. Uma pesquisa do consórcio Disciplined Agile mostra que as equipes Iterativas (Híbridas) têm muito mais probabilidade de falhar do que as equipes tradicionais além de ter menos sucesso do que as equipes Agile ou de Entrega Contínua.

A abordagem em cascata de desenvolvimento teve origem nas indústrias de construção, onde as mudanças no projeto se tornaram proibitivamente caras no início do processo de desenvolvimento. Os gerentes de projeto na indústria de desenvolvimento de software aplicaram essa abordagem desde o início porque não reconheceram que havia ou precisaria haver uma abordagem diferente para o trabalho criativo baseado no conhecimento.

As empresas que usam a abordagem em cascata ou water-scrum-fall gastam metade do tempo e um terço do esforço (portanto, do orçamento) desenvolvendo planos detalhados, requisitos e projetos antecipados. Referência: "Distribuição de Fases do Esforço de Desenvolvimento de Software" de 2008 (texto em inglês).

As empresas usam a abordagem em cascata ou water-scrum-fall porque querem saber quanto custará uma iniciativa antes de iniciá-la. As pessoas que desenvolveram a proposta argumentam que vale a pena gastar tempo e dinheiro na fase inicial porque é de cinquenta a duzentas vezes mais barato corrigir um problema na fase de requisitos ou na fase de design do que no desenvolvimento ou quando o mesmo se encontra em operação.

As empresas também precisam desenvolver planos financeiros, produtos, projetos, aquisições e gerenciamento de recursos para integrar e controlar as atividades em toda a empresa. Os métodos ágeis oferecem pouca orientação nestes quesitos.

Um projeto inicial grande causa muitos problemas

Projetos que tem uma grande fase inicial planejam antecipadamente, bloqueiam muitas suposições, sem ao menos testá-las. Esses projetos não sabem se a arquitetura da solução funciona até testá-la e não sabem se os requisitos estão corretos até a implantação do produto. Durante a fase de teste, as equipes de projeto sempre descobrem que muitas das suposições feitas previamente estavam erradas ou foram alteradas, o que os leva a muitas alterações dispendiosas nas fases finais.

A verdade é que os projetos e planos se deterioram à medida que o ambiente, o escopo e as prioridades mudam e, à medida que aprendemos quais devem ser os requisitos e a solução. Planos detalhados decaem rapidamente enquanto arquiteturas e estratégias decaem lentamente.

O custo da mudança é muito menor em projetos ágeis

Frameworks Ágeis foram idealizados para diminuir o custo de mudança, reduzindo a duração do ciclo de feedback de anos para dias e minutos.

O baixo custo de mudança que o Agile proporciona aos stakeholders dá muito mais controle sobre o custo de um projeto ao longo de sua vida. Com ele, as empresas podem reduzir as fases de projeto e planejamento iniciais a uma fração dos projetos idealizados com a abordagem em cascata. Isso se dá porque, com a abordagem Ágil, é sabido que o escopo e a arquitetura podem ser alterados durante o desenvolvimento do projeto, com o intuito de entregar o maior valor possível dentro do tempo e orçamento disponíveis.

Roadmap de iniciativas

Planos não valem nada, mas planejar é tudo.

- Presidente Dwight D. Eisenhower.

Os planos são essenciais pois definem expectativas sobre as metas, a estratégia, os recursos necessários e justificam os gastos da empresa com a iniciativa, além de permitem que consideremos os problemas e riscos envolvidos ao longo do caminho de forma que possamos desenvolver maneiras de contorná-los. Os planos constroem uma ponte entre a administração e a equipe de desenvolvimento, sendo possível se preparar para diferentes eventualidades para aumentar a chance de sucesso. Com um plano, é possível obter o comprometimento e os recursos necessários para atingir o objetivo, porém, em sua ausência, é improvável que consigamos os fundos ou recursos necessários para ter sucesso.

Roadmap de iniciativa

Nos últimos anos, desenvolvi e refinei um processo de roadmap de iniciativa que permite definir, projetar e planejar uma iniciativa em semanas, ao invés de meses ou anos. Nele é possível definir a meta, estratégia e direção em um plano de alto nível para que possa obter o financiamento e o suporte necessários para formar uma equipe de desenvolvimento para entregar essa iniciativa. Quando a equipe de desenvolvimento é formada, desenvolvem o plano com os stakeholders de negócio para entregar o máximo valor comercial possível dentro do tempo e orçamento disponíveis.

Os roadmaps de iniciativas são importantes para quem precisa obter recursos para o desenvolvimento de um produto ou serviço digital. São úteis para pessoas em gerenciamento geral, de produto, de contas, de projetos, vendas, marketing, , análise, arquitetura e desenvolvimento de software em uma empresa, consultoria, agência digital ou provedor de serviços.

Utilizei esse roadmap para as seguintes iniciativas:

  • Planejar um novo e-commerce para um fabricante de automóveis que permitisse aos usuários personalizar e precificar os carros antes de ir fisicamente a uma concessionária;
  • Melhorar o desempenho do portal de autoatendimento mobile para gestão e compras da Telco para seus clientes empresariais;
  • Aprimorar um portal de gerenciamento de rede de autoatendimento que uma empresa de telecomunicações fornece a bancos e outros clientes corporativos;
  • Projetar e planejar um site de gestão de conhecimento para a equipe de call center de uma empresa de seguro de saúde;
  • Projetar e planejar um novo site de viagens para uma agência de viagens.

Antes de começarmos

Entendendo o problema

Os roadmaps de iniciativas nos ajudam a desenvolver um plano para resolver um problema já conhecido. Se não entendemos exatamente qual é o problema ou quais perguntas fazer, precisamos descobrir isso antes. Para tal, pegamos o resumo ou a causa do problema, fazemos alguns questionamentos, desenvolvemos hipóteses, planejamos e conduzimos as pesquisas.

A pesquisa pode ser qualitativa ou quantitativa, comportamentais ou atitudinais. A pesquisa qualitativa pode envolver entrevistas, estudos de usabilidade e mapas de processos de negócios. A pesquisa quantitativa inclui a análise dos processos de negócios, clientes e dados de produtos. A maioria das iniciativas se beneficia da combinação de percepções de vários métodos de pesquisa.

O objetivo desse processo de descoberta é obter o desafio de negócios claro resumido em um "Como podemos fazer?". Essa declaração deve ser simples, curta, objetiva e com a direção à ser tomada. Deve ser específica o suficiente para permitir que conheça o contexto e, ampla o suficiente para dar espaço para explorar diferentes abordagens.

Por exemplo, se estivéssemos falando sobre a construção de um novo subúrbio de uma cidade, o desafio poderia ser:

"Como podemos fornecer aos primeiros proprietários, famílias jovens e aposentados casas de qualidade a preços acessíveis no novo subúrbio o mais rápido possível?"

Obtendo financiamento e compromisso para desenvolver um plano

Antes de começar a desenvolver um roadmap, é necessário obter financiamento e os recursos para fazer o planejamento. Na maioria dos casos, o patrocinador preparará uma apresentação para os executivos onde explicará qual é o problema de negócio e porque a empresa deve alocar os recursos por algumas semanas para desenvolver um plano para resolvê-lo. Algumas empresas podem exigir que o patrocinador passe por um processo formal de concepção do projeto. Não é necessário fazer um business case antes de iniciar um roadmap porque o mesmo já criará, por padrão, esse business case de forma mais detalhada para a iniciativa.

Os roadmaps de iniciativas são um processo intenso que requerem um compromisso significativo e uma tomada de decisão rápida. Antes de iniciarmos um roadmap, precisamos contratar as pessoas e garantir que estejam comprometidas com o processo.

O que é um roadmap de iniciativa?

Um roadmap de Iniciativa define onde está tentando chegar e como planeja atingir esse objetivo. Descreve a equipe, o orçamento, o tempo e os recursos necessários. Esse roteiros integram o planejamento de produtos, design UX, arquitetura técnica e planejamento de iniciativas em uma estratégia viável para atender às expectativas dos stakeholders. Os roadmaps reúnem os principais stakeholders com especialistas relevantes para projetar e planejar rapidamente um novo produto, de modo que possamos obter financiamento e recursos para desenvolvê-lo.

Os roadmaps dizem respeito ao plano do produto final, experiência do usuário, arquitetura do sistema e plano do projeto. Definem processos de várias etapas e fluxos de dados de vários sistemas, fornecendo às equipes um contexto, uma direção e uma estratégia para o projeto detalhado a ser desenvolvido nas sprints.

No Scrum, evitamos planejar com mais de algumas semanas de antecedência, porque assumimos que qualquer trabalho feito para detalhar itens no backlog "se deprecia rapidamente fazendo com que sua estimativa seja refeita". O produto, UX, arquitetura e roadmap de projeto fornecem uma visão geral à serem integradas no backlog do produto Scrum.

Com um roadmap de iniciativa, pretendemos evitar atrasos e desperdícios, fazendo apenas o suficiente da arquitetura técnica, do UX, do projeto e do planejamento na hora certa. Para conseguir isso, criamos um produto de alto nível e um roadmap de iniciativa para os próximos 12 meses, UX e roadmap de arquitetura e modelos para os próximos 3 a 6 meses e projetos detalhados para as próximas 2 a 4 semanas. Nosso objetivo é revisar esses planos todos os dias e em cada Sprint. Nesse cenário, os roteiros e modelos são alterados na medida em que a equipe vai aprendendo sobre o problema.

Um roadmap de iniciativa é uma alternativa ao processo tradicional de análise, projeto e planejamento em estágios, que consome um terço do orçamento e metade do tempo. Os roadmaps substituem design sprint, business case (amplo e detalhado), plano de projeto, fase de requisitos de negócios, de arquitetura de solução, de projeto de UX e a fase de projeto técnico em projetos com abordagens ágeis híbridas e tradicionais.

Por que precisamos planejar com antecedência

Na minha experiência, as equipes que se concentram apenas em planejar histórias para as próximas semanas produzem soluções específicas que funcionam bem para pequenos recursos, mas não funcionam quando aplicadas a outras áreas do produto. Portanto, ao invés de desenvolver estilos de UI consistentes e reutilizáveis para um site, cada desenvolvedor cria uma versão de estilo para o componente no qual está trabalhando, o que leva a uma solução não conectada e fragmentada com muito esforço duplicado.

A otimização local infesta as empresas e é muito comum na pesquisa de IA. Uma equipe que avança em pequenos passos pode ficar facilmente presa em um ótimo local que pode não ser tão ótimo assim em um aspecto geral. Em contraste, um grupo que tem uma visão mais abrangente pode ver mais facilmente os melhores locais.

Os roadmaps de iniciativas nos permitem desenvolver roteiros de nível mais alto que nos permitem olhar mais adiante para obter mais facilmente a solução ideal sem ficar preso em um lugar.

Consulte: "Intro to optimization in deep learning" de Ayoosh Kathuria

Projetando os roadmaps

A experiência mostra que um pequeno número de pessoas inteligentes que se reúnem para esboçar modelos e desenvolver protótipos podem definir um projeto de solução viável em duas semanas, ou seja, de 70% a 80% correto. Este é um exemplo do princípio de Pareto, onde 80% do benefício é obtido com 20% do esforço. A equipe pode então iterar para 95% por meio de tentativa e erro em alguns meses.

Consulte: "Just Barely Good Enough Models and Documents" de Scott Ambler

Consulte: "How Architects Fit in on Agile Teams" de Scott Ambler

 

Entregáveis

O roadmap de iniciativa define:

  • O problema de negócio;
  • Os objetivos e resultados principais;
  • O roadmap da experiência do cliente;
  • O roadmap da arquitetura da solução;
  • O roadmap do produto priorizado por valor, tamanho e dependências;
  • Os riscos e problemas da iniciativa;
  • O orçamento da iniciativa e plano de recursos.

Em um projeto tradicional, cada uma dessas entregas seria um documento de 80 a 100 páginas com modelos detalhados e abrangentes, planilhas e protótipos que levariam seis semanas para serem desenvolvidos e duas semanas para serem revisados. Isso não é necessário neste caso.

Em uma abordagem ágil, cada uma das entregas será um par de páginas de texto, ilustradas com um ou dois slides e mostradas por meio de gravações, modelos, protótipos e planilhas. O objetivo é fornecer detalhes suficientes para permitir que a equipe desenvolva um plano, uma estratégia viável, com estimativas de tempo e custos razoáveis.

O roadmap de experiência do cliente mapeará o fluxo do processo de ponta a ponta, ilustrado com wireframes em preto e branco as interações críticas e com 1 ou 2 modelos de cores para testar o design gráfico. Não fornecerá a arte finalizada, código de trabalho ou um projeto abrangente para cada interface de usuário.

O Roadmap de Arquitetura da Solução será um protótipo simples para representar o fluxo de dados de uma extremidade a outra e mostrar como os principais componentes técnicos funcionam no ambiente. Não será um projeto técnico completo e detalhado e não fornecerá o código pronto para ir para produção.

Alguns exemplos de diferentes iniciativas são mostrados abaixo.

 

 

Como desenvolver um roadmap de iniciativas?

Uma equipe experiente liderada por um facilitador habilidoso pode criar um roadmap de iniciativa em 2 semanas. No primeiro dia de planejamento, explicamos a abordagem, definimos os objetivos, determinamos a jornada do cliente e o roadmap de recursos, além de desenvolvermos o projeto e os resumos técnicos. Em seguida, projetamos simultaneamente o produto, a experiência do usuário e a arquitetura técnica. No final do planejamento do roadmap, reunimos tudo para estimar, priorizar os recursos, desenvolver um orçamento e documentar as descobertas.

 

Atividades

As atividades principais são:

  • Definir o desafio e discutir a abordagem;
  • Definir os objetivos de negócios e os principais resultados esperados;
  • Definir as personas do cliente;
  • Definir a jornada do cliente;
  • Definir o mapa de recursos do produto;
  • Definir o plano de serviço;
  • Definir o ambiente técnico atual;
  • Desenvolver um esboço do UX;
  • Recrutar os clientes para os testes;
  • Desenvolver um modelo de solução de arquitetura;
  • Definir a POC técnica;
  • Definir a POC de guias de desenvolvimento;
  • Definir as características do produto;
  • Desenvolver wireframes UX;
  • Desenvolver a POC técnica;
  • Definir as diretrizes da marca;
  • Definir os riscos e problemas da iniciativa;
  • Desenvolver os mood boards;
  • Revisar e integrar os modelos de UX e da solução com os recursos do produto;
  • Desenvolver os roteiros de entrevista;
  • Realizar testes de UX com os clientes;
  • Revisar a solução técnica com os arquitetos;
  • Revisar as descobertas de UX;
  • Revisar os recursos identificados;
  • Estimar o valor do recurso, o tamanho e a velocidade da equipe;
  • Desenvolver um plano de release priorizado;
  • Desenvolver o orçamento e plano de recursos;
  • Fazer um brainstorming dos riscos e problemas;
  • Definir a abordagem de entrega;
  • Escrever os resultados como um business case detalhado;
  • Revisar a experiência do usuário, a arquitetura e o plano de entrega com os stakeholders.

A Equipe de Planejamento

Na minha experiência, o roadmap de iniciativa funciona melhor com uma equipe de seis a doze pessoas. Três a seis pessoas para conduzir o processo e três a seis pessoas para fornecer orientação, compartilhar conhecimento e tomar decisões. Se já tem uma equipe de entrega deste produto, então essa equipe deve fazer o planejamento com a ajuda dos especialistas. Se não tem uma equipe de entrega de produtos disponível ou se ainda não definiu a iniciativa, convém reunir as pessoas que espera que levem a iniciativa adiante.

Estimo que haja cerca de 70 dias de trabalho em um roadmap espalhado por toda a equipe. A equipe de planejamento deve incluir ao menos um facilitador, designer, arquiteto, líder de negócios, especialista em negócios, especialista técnico e gerente de projeto. Podemos dividir cada uma dessas funções entre duas pessoas, se não estiverem disponíveis em tempo integral. Por exemplo, o sponsor do projeto pode participar por 30 horas com o apoio de um Gerente de Produto/Product Owner na equipe que participa por 50 horas. E a função UX/UI Design pode ser dividida entre um UX Designer e um UI Designer.

 

Cargo/função

Esforço em Horas

Facilitador/agile coach/analista de negócio

80

UX/UI designer

80

Arquiteto de Soluções/líder técnico

80

Sponsor/gerente da unidade de negócio/gerente de produtos /product owner

80

Especialista de negócio

80

Especialista do domínio técnico/arquiteto corporativo/desenvolvedor de integração

80

Gerente de iniciativa/analista de negócios/documentador

80

Armadilhas a serem evitadas

Os gerentes tradicionais podem sabotar inadvertidamente o roadmap Agile, exigindo todos os resultados com os quais estão acostumados em um processo de planejamento com etapas convencionais. Podem insistir, por exemplo, que os artefatos a seguir tenham um alto grau de detalhamento:

  • Documento de requisitos de negócios;
  • Documento de arquitetura da solução;
  • Documento de especificação técnica;
  • Documento de design de IU com wireframes acabados e recursos de arte para cada página;
  • Plano do projeto com gráfico de Gant.

Os gerentes tradicionais também podem tentar transformar o roadmap de iniciativa em um contrato de escopo e preço fixos para a entrega de tudo definido no roadmap sem alterações.

É possível contornar esses problemas trazendo esses gerentes para os processos de planejamento e usando o tempo em workshops para ensinar às pessoas sobre preço e custo fixos, entrega de escopo variável com equipes ágeis, além de explicar quais serão os resultados.

Também podemos ter problemas com pessoas que faltam aos workshops ou passam o tempo nos laptops e telefones. O facilitador deve prestar atenção no comportamento do sponsor e no da equipe de planejamento, explicar o impacto e perguntar ao grupo o que devem fazer a respeito.

O que acontece após o roadmap

Depois que a equipe de planejamento desenvolveu o roadmap de iniciativa, o sponsor pode usá-lo para solicitar financiamento para a entrega do produto ou decidir que o plano é muito caro e precisam encontrar uma maneira mais barata de resolver o problema.

Um roadmap de iniciativa não é um evento único que cria um escopo fixo a ser entregue sem alterações, mas sim um plano vivo que evolui por meio de revisões e replanejamento contínuos em todos os níveis ao longo do ciclo de vida do projeto. No próximo nível, há o planejamento da sprint, depois os testes de aceitação, até o desenvolvimento, integração e implantação contínuos. Se a equipe descobrir que uma das premissas do roadmap está errada, ela mudará o plano para maximizar o valor do negócio dentro do tempo e orçamento disponíveis. O roadmap não é dirigido por planos, mas adaptativo e evolutivo.

Dimensionando o roadmap de iniciativa

Podemos usar os roadmaps de iniciativas para planejar grandes programas, mapeando grandes blocos de trabalho que podem ser feitos em 3 a 6 meses e, em seguida, planejando cada parte como uma iniciativa separada com o próprio roadmap. Uma pesquisa do Standish Group mostra que projetos menores têm muito mais probabilidade de sucesso do que projetos maiores, por isso é sempre uma boa ideia dividir um programa extenso em partes menores.

Dimensionando o programa

Ao invés de iniciar um programa massivo de uma vez, é melhor começar com uma equipe, provar que ela pode entregar o valor esperado e depois dividi-la em dois grupos, que se dividem em quatro e assim por diante por meio de um processo de mitose.

É necessário dividir as equipes de forma que cada uma tenha um cliente externo ou interno. Algumas dessas equipes podem agregar valor aos clientes diretamente, enquanto outras fornecem plataformas e recursos que dão suporte às equipes de produtos voltadas para os negócios. Quanto mais independentes forem os grupos, melhor. Dependências complexas entre equipes tornam o processo mais lento.

Aumentar o programa ao longo do tempo reduz substancialmente o risco e nos permite desenvolver uma cultura e estratégia coerentes entre as equipes.

Equipe de integração

Nos programas, uma equipe de integração gerencia as dependências cruzadas entre os grupos, desenvolvendo os roadmaps de produto, arquitetura, UX, iniciativa e orçamento para os próximos 6 a 12 meses. Esta equipe tem um Product Owner, um Gerente de Iniciativa, um Agile Coach, um Arquiteto de Soluções, um UX Designer e representantes de cada um dos grupos individuais. A equipe de integração é semelhante à definida no Scrum Nexus, mas com um foco mais amplo nos orçamentos, recursos, arquitetura e design UX. A equipe de integração irá liderar o desenvolvimento do roadmap de iniciativa para as novas iniciativas, certificando-se de incluir as pessoas que irão entregar se ele for aprovado.

Benefícios

Planeje rápido, planeje melhor.

Os roadmaps de iniciativa definem uma abordagem que um gerente de produto ou projeto podem usar para determinar de forma rápida e eficaz o plano do produto, a arquitetura da solução e o financiamento para uma nova iniciativa. Com esse plano, podem obter orçamento e recursos para o projeto, começando mais cedo, entregando com mais rapidez, aumentando a satisfação do cliente, reduzindo riscos e obtendo benefícios mais cedo.

Os roadmaps colocam o cliente no centro da iniciativa para que possamos desenvolver uma solução que atenda às suas necessidades. Permitem definir um plano realista para entregar um produto valioso com rapidez e eficiência, dentro do prazo e do orçamento. E nos colocam no controle do processo de desenvolvimento para que obtenhamos o melhor resultado dos fornecedores ou que desenvolvamos nós mesmos a iniciativa.

Os roadmaps de iniciativas reduzem o tempo e custo de planejamento em mais de 50%, permitindo que alcançar benefícios com mais rapidez e retomada rápida quando as coisas não forem bem. O gráfico a seguir mostra o plano de refactoring de um site de médio porte em um comparativo com o que geralmente acontece e o que poderia acontecer com o Agile Planning. É possível ver que a combinação do Agile Planning com o Agile Delivery promove a conclusão da iniciativa em um tempo que normalmente levaríamos para planejá-la.

O Diretor Digital de uma grande empresa automotiva com a qual trabalhamos disse que economizaram 12 meses e centenas de milhares de dólares ao fazer um roadmap de iniciativa. E o sponsor de uma iniciativa de gestão do conhecimento em um fundo de saúde disse que em 2 semanas avançamos mais do que a empresa de TI havia feito nos 12 meses anteriores com uma abordagem Water-Scrum-Fall.

Me envolvi e desenvolvi roadmaps de iniciativas nos últimos sete anos para muitas empresas, grandes e pequenas. Se quiser ajuda para implementar essa abordagem, entre em contato comigo pelo e-mail murray@ev0lve.co, e nós o ajudaremos na implementação.

Referências e agradecimentos

Os roadmaps de iniciativas ágeis baseiam-se em ideias de muitos pensadores diferentes da comunidade Lean, Agile, Scrum, XP, Arquitetura Ágil, Design UX e Gerenciamento de Projetos. Devo muito a Kent Beck e Martin Fowler por "Planning Extreme Programming", Mike Cohn por "Agile Estimating and Planning", Jeff Patton por "Story Mapping", Scott Ambler por "Agile Architecture", Eric Reiss por "Lean-Agile Product Development", Jake Knapp por "Design Sprints", Jeff Gothelf por "Lean UX" e Henrik Kniberg por "Scrum and Kanban in the trenches".

Gostaria de agradecer a Dean Netherton por apresentar ao Agile XP em 2004, a Ben Scown por ajudar a desenvolver uma abordagem de planejamento Agile na Telstra em 2009 e a David Cox por apresentar ao Design Sprints em 2016. Também gostaria de agradecer as muitas pessoas que revisaram e deram feedback sobre este artigo.

Espero que descubra que a abordagem de planejamento que descrevo aqui fornece a melhor maneira de iniciar e planejar a próxima iniciativa digital.

Sobre o Autor

Murray Robinson, MD Ev0lve, trabalha com projetos de iniciativas digitais e empresas capazes de realizá-las. Tem 30 anos de experiência em TI, começando a carreira como desenvolvedor de software, 20 em digital, 20 em gerenciamento de produtos e projetos, 16 com Agile e 3 em UX. Caso queira saber mais sobre como planejar e executar iniciativas digitais entre em contato com Murray pelo endereço de email murray@ev0lve.co.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT