A fase de Inception surgiu no RUP (Rational Unified Process), uma metodologia de engenharia de software desenvolvida pela Rational Software Corporation. O RUP surgiu na década de 1990 como um método ou estrutura de processo gerenciável para a construção iterativa de software. As fases do RUP são: Iniciação (Inception), Elaboração, Construção e Transição. A Inception marcava o início de um projeto de software, onde o objetivo é estabelecer a visão do projeto, alinhar as necessidades do negócio com as capacidades técnicas e validar a viabilidade das ideias.
Inspirado na fase de Inception, nos primeiros anos das metodologias ágeis os planejamentos de software usavam um roteiro onde discutíamos uma visão de negócio, seus objetivos, personas, jornadas, funcionalidades e plano de sprints. Paulo Caroli, autor do livro “Lean Inception: Como alinhar pessoas e construir o produto certo“, inspirou-se nestes conceitos de Inception e sua longa experiência na Thoughtworks para criar a Lean Inception, uma técnica ágil e eficiente para planejar projetos de software.
Como facilitador vivencio uma grande variedade de condições em projetos de software, em sistemas de inovação, de diferenciação ou de registro, cada qual em diferentes momentos, que exigem ajustes no formato, agenda e tempo de Inception.
Conforme o produto, projeto e momento, estruturamos uma Inception para planejamento de software em um tempo que varia de um (1) a cinco (5) dias. Tudo depende do que temos como entrada e requisitos, e daquilo que queremos como saída.
Alguns passos que acontecem antes de uma inception, o que chamamos de prévias:
Reunião(ões) Prévias – Realizamos uma ou mais reuniões, é preciso conhecer o contexto, levantar as informações, nominata e artefatos disponíveis. Muitas vezes temos a disposição documentos de visão, BPMN dos processos, jornadas de usuários, mapas de funcionalidades ou WBS já existentes ou desenvolvidas, mapa de tecnologia, composição de times e profissionais envolvidos, … Nada se perde, estas informações podem e devem acelerar ou permitir maior entendimento e assertividade desde o início de nosso planejamento.
Contextualização – É importante definirmos qual o dimensionamento do time, com seus papéis, como desenvolvedores, testadores, UX, analista, líder técnico, arquiteto, … Quais as tecnologias envolvidas e quais as boas práticas exigidas ou recomendadas pela empresa, PMO ou arquiteto de soluções. Aqui prevemos a metodologia a ser seguida, o tamanho das iterações, o percentual de cobertura de testes, documentação, etc. Raramente estas informações são fruto de tomada de decisão durante a Inception, mas já aconteceu de fazermos dois ou três planejamentos de entregas comparativos, com um ou mais times, com uma ou outra tecnologia.
Agenda – A partir das prévias é possível propôr uma agenda e abordagem, com previsão de tempo, participantes e passo-a-passo para nossa Inception alinhado as expectativas e recursos. Quantos dias, o que acreditamos que vai rolar a cada turno, nominata de participantes integrais e eventualmente convidados pontuais. É importante que o cliente esteja a par deste planejamento e de acordo com o mesmo.
Preparação – Alinhado às prévias e planejamento é preciso preparar o material necessário, quer seja presencial (quadros e murais, postits, canvas, canetões, fita crepe e tudo o mais, sendo que as vezes é possível preparar in loco ou em folhas de flipchart para fixação chegando meia hora antes) ou virtual (usualmente um board Miro recebe os frames e quadros para cada dia e cada técnica ou dinâmica, incluindo orientações e modelos).
Chegou o(s) dia(s) da nossa Inception, temos uma agenda entorno de algumas técnicas:
Check In – É importante reservar algum tempo no início do primeiro dia para o check-in, apresentar a agenda da inception, fazer alguns alinhamentos, combinações e comportamento, horários dia-a-dia, apresentação dos papéis e pessoas presentes e um quebra-gelo inicial. Quando a sessão for virtual, normalmente o quebra-gelo é uma dinâmica exercitando os recursos do Miro, para que todos saibam como navegar no board, criar um postit e interagir formalmente.
Briefing – Na prévia é importante estabelecer quem irá fazer o briefing e apresentar as informações disponíveis, muitas vezes exigindo a preparação de uma apresentação estruturada que demanda tempo e recursos. Há casos em que temos variados documentos e informações, algum canvas de negócio como o Business Model Canvas ou Lean Canvas, desenhos da situação atual, planejamento estratégico, não é incomum termos diferentes papéis, como um presidente, diretor ou gerente de negócio. Mas também pode ser um projeto técnico em que teremos a contribuição de um arquiteto de soluções ou mesmo um gerente de projetos.
Objetivos do projeto – A partir do briefing é necessário registrar claramente quais são os objetivos de negócio, muitas vezes mapeados através de números e cenários. Frequentemente estes objetivos nos ajudarão no mapeamento mais efetivos de funcionalidades, nos destaques de agregação de valor e na priorização pra planejamento de entregáveis através de MVP, MMP, Releases ou Incrementos.
Entendimento – Para muitas soluções dedicamos um tempo para a construção de um Elevator Statement, um É-NÃO É/FAZ-NÃO FAZ ou mesmo uma Matriz CSD (certezas, suposições e dúvidas). Estas técnicas são bem-vindas sempre que o Briefing apresenta uma solução inovadora ou que exija discutir o entendimento inicial por parte dos participantes. Neste caso, podemos dividir em grupos e desafiá-los a apresentarem seu entendimento sobre aquilo que foi brifado.
Personas – Em muitos projetos eu já recebo as personas modeladas e elas são apresentadas logo após o briefing, frequentemente decorrente de um trabalho prévio de Design Thinking, que procedeu no mapeamento de personas para a realização de entrevistas e Focus Groups. Em outros casos nós apenas relacionamos as personas e suas características pertinentes a sua atuação em relação ao produto em discussão, o suficiente para nos levar à discussão das jornadas mais adiante. Eventualmente uso um canvas de personas e raramente um Empathy Canvas.
Jornadas – Em alguns projetos eu já recebo as jornadas modeladas e elas são apresentadas logo após as personas, frequentemente decorrente de um trabalho prévio de Design Thinking, que procedeu no desenho das jornadas. Em outros projetos recebemos um BPMN, fruto de um trabalho de desenho de processos que precedeu a decisão do produto/projeto que é nosso foco. Mas, frequentemente realizamos o desenho, inicialmente em épicos e depois detalhado em seus passos e ações. Este trabalho pode ser através de uma única jornada destacando diferentes personas no seu curso ou no desenho de várias jornadas, uma para cada persona ou objetivo.
Funcionalidades – O brainstorming de funcionalidades é a peça central de nosso planejamento, elas materializam as necessidades do usuários, levando em consideração o briefing, objetivos, personas e jornadas. Cada postit representa uma funcionalidade necessária, externada apenas cm título e uma discussão mínima para entendimento, devidamente registradas se necessário.
Balanceamento – A Lean Inception propôs balanceamento entre tamanho do valor para o negócio, a estimativa de desenvolvimento e o domínio que temos para sua construção. O valor para o negócio indica o quanto aquela funcionalidade é importante para o negócio ($-$$-$$$). A estimativa de desenvolvimento exige uma percepção de complexidade para dimensionamento (P-M-G ou E-EE-EEE). Finalmente, o domínio nos ajuda a entender o tamanho do esforço adicional para especificar o que precisa e como precisa ser feito (etiqueta verde, amarela ou vermelha).
Contraponto ao balanceamento – Antes da Lean Inception ser proposta, era comum focarmos na estimativa técnica com TShirt Size (P-M-G), discutindo valor quando da priorização no plano de entregáveis, enquanto domínio se materializava em tickets adicionais se necessários, funcionais ou técnicos, a qualquer momento. O modelo proposto pelo Caroli organizou estas informações.
Planejamento – É o planejamento de entregáveis, em iterações, o Caroli chamou de Sequenciador de Ondas. Todos os passos anteriores nos traz até aqui, momento em que colaborativamente estabelece-se a ordem de desenvolvimento e o que cabe em cada Onda ou Iteração. Ao final, teremos uma perspectiva de tempo (número de ondas ou iterações), escopo (o que será entregue e fechamento de um MVP ou versão) e custo (a partir do tempo e dimensionamento de equipe é possível posteriormente calcular os custos básicos e agregados).
MVP Canvas – O MVP Canvas proposto pelo Caroli é uma forma de resumir todas as decisões tomadas durante uma Inception, especialmente quando se trata do planejamento de um MVP e eventuais incrementos rumo a uma versão comercial. Eu somente o utilizo quando realmente um MVP está sendo discutido e planejado.
Check Out – Sempre que possível feche com um checkout, importante fazer um alinhamento final dos resultados da Inception, pedir um feedback quanto a participação e contribuição de todos. Alinhar a percepção de valor construído frente a expectativa antes do início da Inception, o que nos proporciona a identificação de oportunidades de melhoria pra futuros planejamentos.
Showcase – Pode ser que os principais stakeholders e sponsor do projeto participem do início, no briefing, e do fim, de forma que recebam uma apresentação dos principais pontos e do planejamento final de entregáveis. Não é incomum que stakeholders não possam participar de vários dias de planejamento, por isso dedica-se a eles um tempo no briefing para compartilharem suas expectativas e objetivos, recebendo no final uma apresentação geral via showcase.
Alguns exemplos no Miro, mostrando variações de acordo com técnicas e agenda:
Jorge Horácio "Kotick" Audy 
1 comentário