Por Peter Mello

Em 2003 eu já trabalhava com RUP, um framework de trabalho iterativo e com objetivos claros de entregas por etapas, mas com um grande nível de documentação e controle atrelados.  O XP surgiu como uma iniciativa de uma pequena equipe em um grande projeto e começamos a discutir métodos ágeis e sua aplicação. Por esta época começamos a falar também de SCRUM, mas o contexto era todo alinhado a um ambiente de Tecnologia da Informação.

Dez anos depois, estou envolvido com projetos de Engenharia sob encomenda e Manufatura de equipamentos pesados (tão pesados que a venda não é feita por “casos de uso” ou “sprints” ou “lista de equipamentos”, mas por toneladas mesmo!). Em um primeiro momento parece que não há espaço para uma “metodologia ágil” e estamos envolvidos em projetos com cronogramas gigantescos e informações ainda mais complexas quando tratamos das Ordens de Produção na fábrica.

Mas na indústria há muito se fala do Kanban, desenvolvido na década de 40 e implementado na Toyota em 1953. Hoje Kanban é classificado por muitos como um método ágil e como uma demonstração de que os diversos métodos ágeis – entre eles o Scrum – podem ser aplicados fora do contexto da Tecnologia da Informação.

Versões eletrônicas para o Scrum normalmente permitem ser configurados para uma aplicação do Kanban e vice-versa, como é o caso do Kanbanize.Com, que pode ser utilizado como uma versão on-line para os post-its.

(fig.1 – uma interface eletrônica com aplicação no Planejamento Estratégico – Kanbanize)

 

No final das contas, não importa qual “Sabor” do método ágil escolhido, mas existe aqui uma oportunidade para a sua aplicação no desenvolvimento de ações para um Planejamento Estratégico.

(fig.2 – Consulta no Google demonstra uma gama enorme de informações sobre métodos ágeis)

Desafio na execução de Ações de um Planejamento Estratégico

 

Em diversas organizações onde já estive envolvido com consultorias ou projetos, o Planejamento Estratégico é elaborado com uma massa enorme de horas “nobres”, com o envolvimento de Diretores e Alta Gerência, até que uma lista de subprojetos e ações estratégicas são publicados tendo como essência a “transformação da empresa para seus novos objetivos estratégicos” ou “recuperação do foco para realizar os seus objetivos históricos”.

Encontramos aí a aplicação das duas ferramentas mais populares para a gestão de projetos: O Excel e o correio-eletrônico.

Após a reunião do planejamento, o Excel vira anexo obrigatório e membros da alta, média e baixa gerência são convidados a tomar parte das ações necessárias à realização do Planejamento Estratégico.  Em muitos casos, certos profissionais recebem apenas um substrato das ações e não têm a noção clara do vínculo de suas atividades com outras que irão ser necessárias para o atingimento das metas, que serão revisitadas pela Diretoria e Alta Gerência meses depois.

Organizando tarefas em um Planejamento Estratégico

 

Seguramente há boas opções no mercado de softwares que podem contribuir para o detalhamento e acompanhamento de um Planejamento Estratégico.  Um portal que naveguei recentemente e que oferece uma interface específica para o Planejamento Estratégico é o Project Builder (fig.3).

(fig.3 – área do Project Builder específica para a criação de Planejamento Estratégico,  Metas e Tarefas)

 

Para o acompanhamento de múltiplos indicadores, com uma metodologia para o acompanhamento de painéis detalhados e “faróis”, outra ferramenta que utilizei é o Stratws (fig.4), embora este segundo eu tenha me encontrado com algumas dificuldades operacionais que não sei ainda como atribuir a falhas em usabilidade, no meu desconhecimento de macetes para sua operação ou alguma questão de sua implementação (que me parece não ser a última versão).

(fig.4 –visão parcial de painel de acompanhamento de indicadores de Planejamento Estratégico – Stratws)

 

No entanto –  e aqui começamos a tratar o tema desta postagem – o que precisamos entender é que independente da ferramenta (Excel, E-mail, Project Builder, Stratws, etc), poderemos nos encontrar em uma próxima reunião com a Alta Diretoria para descobrir que a grande parte das Ações Estratégicas não aconteceram em função de urgências, rotinas de trabalho, reuniões, compromissos com clientes, entre outros.

Em uma abordagem tradicional para o Planejamento Estratégico, os envolvidos irão realizar um detalhamento das atividades através de um formulário 5W2H, onde descrevem o que será feito (What), quando será feito (When), como será feito (How), por quanto será feito (How Much), porque será feito (Why), onde será feito (Where) e por quem será feito (Who).

A listagem dos WHAT/WHEN/WHO poderá dar origem a um cronograma onde cada item tem uma data final, não necessariamente coordenada em entregas específicas para a empresa.  Ou seja: Um conjunto de “trabalho” irá definir o “prazo” final.

Em uma abordagem com princípios ágeis e que no SCRUM vamos chamar de SPRINTs , nós temos a criação de “time-boxes” ou períodos pré-definidos de tempo onde os participantes terão objetivos claros para um conjunto de entregas.

Em outras palavras, a partir de prazos pré-estipulados (datas de entregas de pacotes/Sprints) os participantes irão definir o trabalho que será encaixado.

 

 

O que muda com Sprints?

 

A palavra de ordem é: ENTREGAS.

Para cada período pré-definido, o cliente (o representante da empresa responsável pelo Plano Estratégico) receberá um subconjunto claro dos itens que compõem os objetivos/metas/tarefas relacionadas a este planejamento estratégico.

O trabalho a ser realizado deve então ser distribuído entre Sprints, mas – assim como no Kanban – temos três grandes grupos de items:

• O que temos que fazer, ou “backlog”;
• O que estamos fazendo, ou “WIP/SPRINT”;
• O que já está pronto.

Um resumo conceitual das abordagens Scrum e Kanban interessante pode ser encontrada no site da Atlassian (fig.5)

 

(fig.5 –https://www.atlassian.com/agile/scrum)

 

Deixaremos para uma futura postagem uma abordagem mais ampla do Scrum, mas existem dois elementos fundamentais para a boa distribuição de trabalho entre o “backlog” e “cada Sprint” que merecem destaque:

– Cada objetivo/meta/tarefa é calculado com base a uma estimativa de “trabalho”; o trabalho representa a carga de horas que cada recurso deverá investir na atividade e não a duração da tarefa.

– Cada objetivo/meta/tarefa tem um valor de negócio, definido pelo cliente; o “business value” de cada item irá auxiliar na definição de quais itens devem ser priorizados em cada Sprint.

 

Definindo Sprints

 

• Vamos supor 10 objetivos estratégicos (obj1…N);
• Vamos supor que cada objetivo estratégico tem 3 metas (objNa,objNb,objNc)
• Vamos supor que cada meta tem 3 atividades (01,02,03)

O “backlog” antes da criação da primeira Sprint terá então 10 x 3 x 3 = 90 tarefas; podemos imaginar que em certos momentos, não temos ainda as metas claras ou o detalhamento das tarefas. Por isso, vamos imaginar que o “business value” de um objetivo poderá ser distribuído nas tarefas na medida em que vão sendo identificadas.

1º Passo: estabelecer um valor de negócio para cada objetivo estratégico. Podemos usar desde uma classificação simples (baixo, médio, alto) até uma composição de parâmetros diversos.

2º Passo: organizar a lista do maior valor ao menor valor; os objetivos de maior valor terão preferência na composição do primeiro Sprint.

3º Passo: detalhamento dos objetivos em metas;

4º Passo: validação das metas para o Sprint: caso se identifique que a carga de trabalho esperada para uma meta poderá indicar que a mesma levará mais tempo para ser realizada do que o período definido para o Sprint (em geral 30 dias), a meta deverá ser detalhada em tarefas para que estas sejam distribuídas em duas ou mais Sprints.

5º Passo: Decomposição – sempre que possível – das metas nas respectivas tarefas que a compõem.

6º Passo: Estimativas de carga de trabalho: caso a carga de trabalho seja atribuída a uma meta e não em suas tarefas, deve-se buscar em iterações futuras acomodar a carga prevista da meta ao conjunto de tarefas (20 horas de uma meta são distribuídas em 4 tarefas de 5h, por exemplo).

7º Passo: Definição dos recursos prováveis para cada meta e/ou tarefa;

8º Passo: Definição da carga de trabalho em uma SPRINT a ser dedicado por cada recurso (Pode-se definir por exemplo que a Alta Gerência irá dedicar no máximo 2 horas por semana ao Planejamento Estratégico; a Gerência irá dedicar 4 horas e outros participantes até 8 horas por semana)

Em outras palavras: Se uma atividade de 8 horas estiver alocada a um Diretor, a duração prevista será de 4 semanas; se for alocada a um gerente, a duração para a realização da tarefa será de 2 semanas; e outros membros de equipe poderão fazer 1 atividade de 8h em cada semana).

9º Passo: Verifica-se alguma dependência entre tarefas: Embora isso possa ser detalhado posteriormente, 2 tarefas que possuem uma dependência entre uma e outra e que tem uma carga prevista de 8h não “cabem” em uma mesma Sprint se estiverem atribuídas a um Diretor.

10º Passo: Examinando os itens de maior valor de negócio e eventuais dependências, bem como a carga de hora total de “capacidade da equipe”, uma SPRINT é montada com a passagem destas atividades de “backlog” para “A realizar”.

Em outras palavras: Se a equipe tem 2 membros da alta gerência (2 x 8 horas/mês), 4 gerentes (4 x 16 horas/mês) e 5 membros de equipe (5 x 32 horas/mês) então a “capacidade da equipe” é de realizar 800 horas de trabalho.

Continuidade do Fluxo de Trabalho e Entregas

 

Para levantarmos dúvidas dos leitores e criarmos um detalhamento desta postagem que tenha ampla aplicação, iremos retornar a este assunto em uma nova postagem.

Aguardo seus comentários! Traga as suas experiências, suas dúvidas ou correções ao conteúdo aqui elaborado!