Metodologias ágeis no setor público
O conceito de ágil surgiu na indústria de tecnologia como resposta às frustrações sofridas no desenvolvimento de softwares. Longos e detalhados planos de trabalhos de projetos com alto nível de incerteza levavam muito tempo para terem suas entregas concluídas e, muitas vezes, o resultado final era diferente do esperado; ou já não atendia mais às necessidades do negócio e dos usuários.
No início dos anos 2000, alguns líderes da indústria de softwares assinaram o Manifesto Ágil, onde escreveram as diretrizes do que seria uma maneira de fazer projetos de tecnologia de forma mais rápida e dinâmica. Desse manifesto derivam diversos métodos diferentes de se trabalhar o desenvolvimento de softwares, sendo o Scrum, Kanban e XP os mais conhecidos.
O ágil é mais do que aplicações de metodologias: é um mindset para entregas de valor pequenas, rápidas e contínuas ao longo do projeto.
12 princípios do manifesto ágil:
- Garantir a satisfação do cliente, entregando rápida e continuamente um software funcional;
- Adaptabilidade: Mudanças tardias de escopo no projeto são bem-vindas;
- Software funcional é entregue frequentemente (semanal ou mensalmente – o menor intervalo possível);
- Cooperação constante entre as pessoas que entendem do ‘negócio’ e os desenvolvedores;
- Projetos surgem por meio de indivíduos motivados, devendo existir uma relação de confiança;
- A melhor forma de transmissão de informação entre desenvolvedores é através da conversa ‘cara a cara’;
- Software funcional é a principal medida de progresso do projeto;
- Novos recursos de software devem ser entregues constantemente. Clientes e desenvolvedores devem manter um ritmo até a conclusão do projeto;
- Design do software deve prezar pela excelência técnica;
- Simplicidade;
- As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis;
- Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento.
Metodologia Scrum
Umas das metodologias ágeis mais conhecidas e utilizadas é o Scrum. No Scrum, o projeto é dividido em pequenos ciclos de planejamento, execução e entrega, os chamados sprints. Em geral, um sprint dura cerca de 15 a 30 dias.
Ao longo do projeto, as necessidades (chamadas também de história) dos clientes / usuários surgem, sendo preciso incluir atividades que antes não eram previstas. No caso do desenvolvimento de um software, por exemplo, pode ser essencial uma nova funcionalidade, ou mudar a interface, para melhorar a usabilidade. Essas demandas são acumuladas num backlog, que é uma pequena lista de necessidades que precisam ser resolvidas.
O sprint é tipicamente dividido em 3 etapas: o sprint planning (planejamento), o sprint development (desenvolvimento) e o sprint retrospective (retrospectiva).
No sprint planning são discutidas as histórias do backlog (as necessidades dos clientes) e verificadas qual é a prioridade de cada uma e qual é o esforço necessário para resolvê-las. Então, são definidas quais histórias serão trabalhadas naquele ciclo e quem irá trabalhar nelas.
Uma vez definidas, essas histórias serão executadas na etapa de desenvolvimento, o chamado sprint development. Durante o desenvolvimento, a equipe faz reuniões diárias curtas para conversarem sobre o que foi produzido no dia anterior, o que será produzido no dia seguinte e tomar pequenas decisões para direcionar o time, as chamadas daily standup meetings.
Ao fim do sprint, as tarefas são finalizadas e entregues aos clientes. Independentemente de todas as demandas serem concluídas ou não, o sprint irá terminar na data prevista e as demandas não concluídas ficam para outros sprints.
Em seguida, o time se reúne para analisar o sprint passado e discutir o que foi bom e os pontos de melhoria, o chamado sprint retrospective. Em alguns casos, é feita uma apresentação das entregas realizadas para os clientes internos da empresa. O time aproveita essa etapa para colher primeiros feedbacks.
Em geral, os times (também chamados de squads) são pequenos com uma média de 5 a 15 participantes, cada um com um papel definido.
O product owner (ou simplesmente p.o.) avalia as necessidades dos clientes e stakeholders* (envolvidos no projeto) e ajuda a definir uma ordem de prioridade, ou seja, ele gerencia o backlog do produto. O próprio p.o., juntamente com um UX designer, utiliza métodos de design thinking para entender as necessidades dos clientes e stakeholders em detalhe e desenhar uma solução para elas. O p.o. e o time de desenvolvedores (ou simplesmente devs) definem o grau de dificuldade das necessidades e quais serão trabalhadas em cada sprint. Os desenvolvedores são responsáveis por executar as melhorias no produto, conforme definido com o p.o. O scrum master garante que todas as etapas do ciclo estão sendo realizadas, e garante os recursos que o time precisa para executar suas tarefas.
Metodologias ágeis que podem ser aplicadas em projetos para além do desenvolvimento de softwares
Mais do que as práticas, o ágil é um mindset que requer transformações profundas de cultura do ambiente de trabalho. No entanto, devido à grande dificuldade de implementar uma transformação dessas no setor público pelo alto nível de complexidade da organização, a proposta deste texto é trazer ideias de como aplicar algumas práticas da metodologia scrum no dia-a-dia de qualquer projeto. Trazendo primeiro mudanças de metodologia, incitando o mindset ágil de maneira bottom-up (de baixo para cima).
Planos de trabalhos longos X pequenos sprints
Uma prática comum em gerenciamento de projetos é construir planos de trabalhos longos e detalhados que abarcam todas as fases de execução daqueles projetos na etapa de planejamento. Muitas vezes o direcionamento muda e o plano não é mais coerente com o esperado. Neste caso, praticar os sprints pode ser um método mais eficiente para projetos em desenvolvimento. Por exemplo, a cada início de mês, o gerente de projeto pode revisar com a liderança se os principais objetivos daquele projeto ainda se mantém e, a partir disso, ele monta uma proposta de atividades detalhadas. Ele, então, pode trazer para o time de projetos essa proposta e discutir o tempo de execução e prioridades de cada atividade, fechando com esse time um plano de atividades para o mês em questão (sprint planning).
Gerenciamento de atividades e visibilidade para todo o time
A prática do daily standup meeting pode ser bastante saudável para dar visibilidade sobre o que está sendo realizado a todos os membros do time de projetos; identificar falhas de antemão e ajudar ao membro da equipe a tomar pequenas decisões do dia-a-dia. Se o time não tiver disponibilidade de se reunir, uma ótima prática também é cada membro enviar um e-mail diário com a lista do que foi feito no dia e próximos passos para o dia seguinte.
O uso do quadro Kanban também ajuda os envolvidos a ter visibilidade do avanço das tarefas, além de poder ser usado também para medir a eficiência do time. Assim, toda vez que alguém tiver dúvidas sobre o andamento de determinada atividade, pode checar no quadro ao invés de ter que fazer reuniões de check-in. Existem várias ferramentas gratuitas disponíveis para gerenciamento de tarefas e quadros de Kanban, como Trello e Asana.
Entregas menores e com visibilidade para a alta liderança e áreas envolvidas
Mensalmente, ao final do sprint, o time pode juntar tudo o que foi realizado e apresentar para a liderança ou áreas cliente o que foi desenvolvido ao longo daquele mês, demonstrando como aquela etapa contribuiu para atingir o objetivo final do projeto. Isso ajuda a dar visibilidade para os stakeholders sobre o que o time está desenvolvendo, bem como colher feedbacks para adaptar o plano de trabalho futuro.
Feedbacks contínuos
Além da prática do feedback 1:1 ao final de cada mês, o time de projetos pode se reunir para discutir sobre o que deu certo, o que falhou e o que pode ser feito para melhorar. É importante também aproveitar estes momentos para medir a moral e o engajamento do time, identificando pontos a serem trabalhados com antecedência. O ideal é começar fazendo uma pesquisa anônima entre os membros e depois uma reunião para discussão em grupo e elaboração do plano de melhoria.
Autonomia
É importante trazer o time para participar das etapas de planejamento, replanejamento e apresentação das entregas, bem como deixar com que, mesmo os membros mais juniores, participem das tomadas de decisão do projeto ou permitir que eles tomem decisões sozinhos no meio do caminho. Isso permite que os membros se vejam como parte daquele projeto, faz com que fiquem mais felizes e mais eficientes.
Interação entre membros de equipes diferentes
Criar espaços para que membros que exercem mesma função possam interagir e trocar experiências pode ser bastante valioso para o desenvolvimento deles. Por exemplo, os gerentes podem se reunir e trocar experiências; ou os analistas para participarem de treinamentos, discussões em grupo, encontros de happy hours.
Mínimo Produto Viável e testes AB
Suponhamos que o seu projeto seja realizar uma série de melhorias num determinado serviço (por exemplos em hospitais públicos), mas você não tem certeza do valor/impacto que cada iniciativa trará ao usuário. Um grupo de teste pode ser montado (por exemplo, uma ala do hospital) e as iniciativas podem ser aplicadas naquele grupo. Comece com iniciativas simples (um Mínimo Produto Viável, chamado MVP), avalie se as iniciativas estão surtindo o efeito esperado neste grupo pequeno e faça contínuas melhorias nos serviços. Uma vez que as iniciativas provarem seu valor no grupo pequeno, expanda as iniciativas para grupos maiores, por exemplo, para o hospital todo.
Espero que essas dicas possam ajudar ao serviço público a criar projetos de forma mais dinâmica e integrada, adaptando as propostas iniciais às demandas que podem vir a surgir no meio do processo.
*Nota da WeGov: Segundo Edward R. Freeman (1984), Stakeholders pode ser definido como o conjunto de grupos que podem afetar uma organização ao mesmo tempo que também podem ser afetados por ela.
Foto de Dylan Gillis no Unsplash
