Gerenciamento de programas: como três equipes distintas podem trabalhar em conjunto para um mesmo objetivo?
Esse é um dos desafios que tenho como gerente de projetos de uma cliente da ThoughtWorks Brasil. Por isso, estive desenvolvendo a capacidade de Gerenciamento de Programas, com a orientação da Madonna Swanson. Nosso objetivo é utilizar projetos já existentes, gerencia-los como programa e ter resultados práticos e reais deste trabalho. Neste texto queremos abordar como três equipes distintos pudessem trabalhar em conjunto, com praticas da gerência de programas.
Mas o que é um programa? Programa é um conjunto de projetos que formam uma força de trabalho coletivo. Os diferentes projetos são complementares entre si e ajudam o programa a atingir seus objetivos. Normalmente existem sobreposições e dependências entre os projetos, então é importante ter alguém com uma visão de alto nível alinhando as expectativas e evoluções entre os projetos. O sucesso do programa é o sucesso de todas as equipes que o constroem.
Com esta visão, focamos em um grupo equipes que estão trabalhando no mesmo escopo do processo de vendas da cliente. As equipes começaram de forma independente, cada uma em um momento e com seus objetivos. Elas se relacionam da seguinte forma:
- A equipe-de-pontos é responsável pelo desenvolvimento da API de vendas para compras com pontos;
- A equipe-de-dinheiro é responsável pelo desenvolvimento da API de vendas para compras com dinheiro;
- A equipe-da-visualização é responsável pelo desenvolvimento do front-end de vendas, para os dois cenários (pontos e dinheiro) e vai ser o primeiro canal a consumir os produtos das APIs.
Dada a complexidade do contexto, algumas datas de entrega justas e a realidade organizacional da cliente, não tínhamos a possibilidade de ter equipes transversais (para mais informações sobre toda a fatia do bolo, veja este artigo). Então o primeiro passo foi buscar uma forma de garantir que as três equipes se vissem como parte de um mesmo contexto e entendessem seu objetivo comum.
Por trabalhar em separado, as equipes olhavam para uma solução comum, mas a construíam de forma distinta e independente. Se o objetivo era atravessar o rio, nós estávamos com a equipe da visualização construindo uma ponte, enquanto as equipes de pontos e de dinheiro estavam construindo um túnel. Todas iam atender o objetivo final, mas não em conjunto.
Porque trabalhar em uma visão conjunta?
Como temos uma cultura baseada no Manifesto Ágil, onde buscamos entregar software funcionando na menor escala de tempo possível, tivemos muito apoio das equipes. Elas não acreditavam em um processo onde cada uma deveria construir toda a sua parte e, apenas no final, fazer a integração e testar como funcionaria. Afinal, se fosse assim, estaríamos produzindo código que não seria utilizado, gerando desperdício.
No nosso desenvolvimento, buscamos feedback rápido da usuária final e trabalhar de forma que seja possível entregar o máximo valor para a cliente, o quanto antes, garantindo que estamos construindo o software mais simples que funcione para cada momento.
Ao invés de passar meses construindo as APIs de pontos e de dinheiro, para depois integrar com front-end e saber se ia funcionar, particionamos em pedaços menores e conseguimos colocar em produção uma parte da API de dinheiro com front-end, coletar dados e feedbacks das usuárias no processo de compra e, a partir disto, evoluir o produto.
Assim nomeamos o conjunto das três equipes como Experiência de Vendas e iniciamos um trabalho de construção de linha do tempo. E foi através da definição de marcos de curto e médio prazo que cada equipe começou a atingir seus objetivos. Com uma linha do tempo única, geramos visibilidade do que estávamos fazendo, qual o próximo passo e assim caminhávamos para um resultado comum a todas.
Como garantir que estejam todas as equipes na mesma página?
Em uma dinâmica com todo a equipe, incluindo as pessoas gerente de produto, as analistas de negócio e as gerentes de projeto, cada uma escreveu em um post-it uma funcionalidade para o produto, que poderia ser transversal (considerando front-end e back-end) ou apenas para uma das frentes. A pessoa que conduzia a sessão colocou os post-it’s em um quadro branco e validou com todas as pessoas presentes a ordem de importância e valor para o negócio de cada uma dessas funcionalidades.
Com base nas funcionalidades levantadas, particionamos em marcos, que são os conjuntos de funcionalidades a serem entregues pelas equipes. Eles podem ou não ser independentes, mas buscamos fazer entregas parciais (um marco por vez) a fim de testar uma hipótese ou conjunto de funcionalidades de cada vez.
Na imagem abaixo você pode ver que temos dois níveis de informações:
- Marcos gerais para Experiência de Vendas (integrados entre as três equipes);
- Marcos pontuais para cada equipe.
Não sendo um equipe transversal esse desenvolvimento exigia muita comunicação, integração e disciplina entre as pessoas das equipes para buscar a otimização do tempo e evitar desperdício. Neste processo é sempre importante revisar as dependências dentro dos marcos, entender como uma equipe afeta a outra, como podem desenvolver em conjunto ou comunicar suas atividades para que não fiquem bloqueadas.
Nas linhas dos equipes são previstas funcionalidades completas que, no kanban, poderiam ser representadas por uma ou mais histórias, dependendo do seu tamanho e complexidade.
A linha do tempo não é escrita em pedra. Aqui entra a questão da disciplina, é preciso sempre voltar para revisar e atualizar esta visão. No nosso caso, a cada duas semanas ou quando sentíamos a necessidade de mudar o planejamento de acordo com retorno das usuárias ou investidoras a respeito do caminho e valor das funcionalidades em desenvolvimento.
PS: Este não é um tutorial do que fazer, mas como podemos adaptar metodologias e conduzir a realidade que vivemos para buscar bons resultados. Há muitas outras práticas e melhorias que você pode utilizar.
PS2: Não utilizamos expressões em inglês na construção deste conteúdo para que entendimento do mesmo seja acessível a todas pessoas.
