“Se você não pode medir, você não pode gerenciar” (Peter Drucker)

Para que possamos entregar valor para nossos clientes é necessário que as pessoas que trabalham na DETIC tenham um ambiente propício à inovação, as metodologias escolhidas para fazer parte da estrutura de trabalho da GDEV levam em consideração transparência, escalabilidade e qualidade de vida.

Scrum é uma framework criada por Ken Schwaber e Jeff Sutherland no início dos anos 90. É utilizada para gerenciar o trabalho em produtos complexos. Scrum não é um processo, técnica ou método definitivo e, sim, uma estrutura na qual se pode empregar vários processos e técnicas. O Scrum deixa claro a eficácia relativa do gerenciamento de produtos e das técnicas de trabalho para que se possa melhorar continuamente o produto, a equipe e o ambiente de trabalho.

Nosso desafio é ajudar mais de 60 pessoas, divididas em 10 times, a trabalhar de forma auto organizada.

Product Owner (PO): Cada time possui 01 (um) Product Owner que priorizam as demandas que entraram na Sprint, esclarece as dúvidas do time com relação ao projeto, acompanha o processo de implantação e publicidade do software produzido. Scrum Master: Cada time possui 01 (um) Scrum Master, que atua como líder servidor e é responsável por manter o Scrum fluido, compreender e orientar os frameworks e/ou metodologias adotadas pela GDEV, ajudar o PO na construção das user stories e ajudar o time a alcançar os objetivos levantados nas retrospectivas. Time de desenvolvimento: Os times de desenvolvimento tem tamanhos diferentes, habilidades diferentes e formas diferentes de ver o mundo. Cada projeto priorizado leva em consideração qual o time mais alinhado a proposta de solução.

Product Backlog: É uma lista com a priorização das funcionalidade desenvolvidas e validadas no processo de ideação. Sprint Backlog: É uma lista com as funcionalidades que o time se comprometeu a entrega em 10 dias úteis, que é o tempo padrão de duração da sprint de todos os times.

Sprint: É o momento em que um incremento potencialmente utilizável é produzido por um Time de Desenvolvimento. Tem duração fixa de 10 dias úteis para todos os times. Sprint Planning: É o momento em que o time de desenvolvimento, Product Owner e Scrum Master definem qual é o objetivo da Sprint, quais funcionalidades serão desenvolvidas pelo time de desenvolvimento, e a votação de complexidade. Tem duração média de 4 horas. Daily Scrum: Reunião diária que tem como objetivo alinhamento das atividades em execução dos times. Essa reunião não pode passar de 15 minutos e deve começar pontualmente às 8h. Sprint Review: É o momento em que a GDEV apresenta para os clientes o que foi produzido na última Sprint. A cada 10 dias úteis trazemos o cliente para perto, para ele acompanhar o desenvolvimento do projeto. Não abrimos mão do nosso cliente durante o processo de construção do produto. Sprint Retrospective: É o momento em que o Time de Desenvolvimento, Product Owner e Scrum Master dedicam a melhoria contínua. Nesse evento é observado o que foi bom é deve ser mantido, o que foi ruim é deve ser melhorado e o que são propostas de melhoria para a próxima Sprint. É o momento mais importante para GDEV.

O Kanban é um método para gerenciar a criação de produtos com ênfase na entrega contínua sem sobrecarregar o time de desenvolvimento. Assim como o Scrum, o método Kanban é um processo designado para auxiliar os times a trabalharem juntos de forma mais efetiva.

Kanban na GDev

Para que os fluxos sejam claros para todas as pessoas envolvidas em um projeto executado na GDEV, utilizamos o método Kanban. Kanban de Gestão de Demandas apresentam os fluxos que problema passa até se tornar uma solução e de responsabilidade do Gerente da GDEV e o Gerente de Portfólio. As fases são:

1. Caixa de entrada 2. Agendado para apresentação da EPR 3. Aguardar Proposta de Projeto 4. Aguardando entrar em Análise de Negócio 5. Em Análise de Negócio 6. Aguardando apresentação da análise ao Cliente 7. Aguardando Priorização 8. Em atendimento 9. Paralisado 10. Concluído 11. Arquivado

O Kanban de Gestão de Projetos apresenta os fluxos existentes dentro da fase Em atendimento. Nessa fase será elaborado o projeto para solução do problema. As fases desse kanban são:

1. Demandas Priorizadas
2. Elaborando Projeto
3. Aguardando Otimização
4. Otimizando processo
5. Aguardando Ideação
6. Idealizando produto
7. Aguardando Desenvolvimento
8. Em desenvolvimento
9. Aguardando Planejamento de Serviços
10. Planejando Serviços
11. Aguardando Entrega/Lançamento
12. Aguardando registro de propriedade intelectual
13. Registrando propriedade intelectual
14. Paralisado
15. Concluído
16. Arquivado

O kanban de gestão de produtos apresenta os fluxos existentes dentro da fase Em desenvolvimento. Nesta fase o produto começa a ser desenvolvido. As fases deste Kanban são:

1. Backlog
2. Selected backlog
3. Em desenvolvimento
4. Teste e Validação
5. Homologação
6. Paralisado
7. Para Produção
8. Concluído
9. Finalizado
10. Arquivado

Cada time tem seu próprio Kanban e o fluxo é definido por cada um. O time de desenvolvimento é auto-organizado e cada um tem sua particularidade.

Lean Inception em sua tradução significa Criação/Concepção Enxuta. É uma metodologia onde o time de projeto se juntam por alguns dias ou semanas realizando algumas atividades para começar a entrega do trabalho: isso é a inception. Ela foi primeiramente desenvolvida por Luke Barrett por volta de 2004. As inceptions variam de projeto para projeto, porém elas geram o alinhamento entre as pessoas envolvidas e criam uma lista ordenada de user stories (Estórias de Usuário) com estimativas juntamente com um plano de liberação (Release). A estrutura de Lean Inception utilizada na GDEV é baseada no livro “Lean Inception: Como Alinhar Pessoas e Construir o Produto Certo” do autor Paulo Carolli Leia mais. Para se encaixar no cenário do serviço público algumas alterações foram necessárias, tais como:

• Redução da carga horária de 36 horas previstas no livro para 20 horas. Para atingir essa marca, existe um trabalho muito intenso dos facilitadores para conseguir ajudar os participantes a ficarem focados e criativos.
• As etapas “Visão do produto”, “É, N O É, FAZ, NÃO FAZ” e a “jornada dos usuários” são preparadas antes da Lean Inception. No tempo destinado a Lean é feito a validação.
• Substituição de algumas ferramentas por outras para adaptar a diferentes cenários que temos (Saiba mais).

Para o sucesso de workshop é necessário que a equipe seja multidisciplinar e nesta estrutura:

• 01 Membro de nível estratégico (opcional, mas extremamente importante)
• 01 Membro (mínimo) de nível tático
• 01 Membro (mínimo) operacional (usuário que utilizará o sistema)
• 01 Membro do time de gestão (GDEV)
• Time de desenvolvimento do projeto (Desenvolvedores da GDEV)
• 01 Facilitador.

“Por trás de todo problema tem uma pessoa que sofre”

Para GDEV o entendimento do problema vem acima de tudo, e toda solução deve ser pensada em quem vai utilizar. A utilização de user story na construção de demandas permite que qualquer pessoa que realizar a leitura possa identificar para “quem é”, o que precisa ser feito e por que deve ser feito. A linguagem utilizada tem o intuito de simular uma conversa com a própria pessoa que está com problema. Reforçando o propósito de quem vai produzir a solução.

“Métricas moldam comportamentos”

Como acompanhar 10 times auto organizados e identificar seu nível de produtividade e ritmo de produção? Toda GDEV fala a mesma língua, todos analisam as demandas (user story) com base em sua complexidade e para auxiliar nessa análise foi adotada a técnica gamificada Planning Poker. O Planning Poker utiliza cartas com valores da sequência Fibonacci. E cada demanda recebe um valor correspondente a sua complexidade. Esta forma de analisar as demandas tem como premissa a comparação entre demandas, para avaliar qual é a mais complexa e dar um valor base para ela. Com o amadurecimento do time o resultado é o estabelecimento de um valor de complexidade que o time suporta trabalhar. Com a descoberta desse valor é possível acompanhar a evolução do desenvolvimento através da velocidade de produção das demandas pontuadas.

O termo de Abertura, também conhecido como Project Charter, é o processo de desenvolvimento de um documento que formaliza e autoriza a execução do projeto. Ele é definido na fase de iniciação de um projeto. Na GDEV isso é percebido na etapa de Elaboração do Estudo de Impactos do Processo de Desenvolvimento de Software.

Para a GDEV o maior compromisso é com a solução do problema, com base nesse propósito quando um cliente não tem um time de gestão de projeto em sua estrutura e sua demanda exige a estruturação de um projeto, utilizamos o Project Model Canvas para auxiliar e alinhar nosso cliente com relação ao entendimento de sua demanda. O PM Canvas foi criado a partir de uma ideia do suíço Alexander Osterwalder no Brasil em 2013, onde ele aproveitou para uma ferramenta bastante utilizada na arte, o canvas, para o meio corporativo. Uma tela para elaborar um Plano de Negócio, e batizou como Business Model Canvas. Hoje é considerada uma metodologia robusta e simples para planejar projetos utilizando conceitos visuais da neurociência aliados a uma estrutura lógica de componentes que formam um plano de projeto. É versátil, visual e ágil para que as pessoas envolvidas em um projeto tenham a mesma visão a respeito dele. Tais componentes lógicos e visuais estão organizados em blocos de perguntas fundamentais (Por quê, O quê, Quem, Como, Quando e Quanto) integrados em conformidade com a teoria que rege o gerenciamento de projetos. Com isso é composto o modelo mental que permite visualizar todos os componentes e suas dependências em uma única página.

saiba mais

Um processo é uma coleção de atividades de trabalho inter-relacionadas iniciadas em resposta a um evento que atinge um resultado específico. Tal resultado pode ser qualquer coisa, desde enviar um boletim informativo semanalmente até atingir um R$ 1.000.000 em receita. O Gerenciamento de Processos de Negócios (BPM) significa criar e otimizar os planos para atingir os objetivos do negócio. E na GDEV o intuito dessa metodologia é de trazer as informações pertinentes de como os processos são executados dentro do setor para que melhorias possam ser realizadas e para que os processos possam ser gerenciados possibilitando uma melhor tomada de decisões e visão do negócio como um todo.

O Modelo e Notação do Processo de Negócio é um padrão para modelagem de processos de negócios que fornece uma notação gráfica para especificar processos de negócios em um Business Process Diagram (Diagrama de Processos de Negócio), tendo como base uma técnica de fluxograma muito semelhante aos diagramas de atividades da Unified Modeling Language (UML). O BPMN foi projetado para fornecer uma notação padrão prontamente compreensível por todas as partes interessadas, incluindo tipicamente analistas de negócios, desenvolvedores técnicos e gerentes de negócios. Portanto, na GDEV é um modelo utilizado para dar apoio ao objetivo, geralmente desejável das partes interessadas em um projeto, adotando uma linguagem comum para descrever processos para evitar lacunas de comunicação que podem surgir entre o projeto, implementação e/ou seu desenvolvimento.

A Análise de Negócio (BA) é um método de pesquisa que visa identificar necessidades de negócios e determinar soluções para problemas do mesmo. Tais soluções geralmente incluem um componente de desenvolvimento de sistemas de software, porém também podem consistir em melhoria de processos, mudança organizacional ou planejamento estratégico e desenvolvimento de políticas. O responsável que realiza essa tarefa é chamada Analista de Negócios ou BA. Embora existam definições de funções diferentes, dependendo da organização, parece haver uma área comum onde a maioria dos analistas de negócios trabalha. Algumas das responsabilidades que um BA deve ter para a GDEV são: Investigar o sistema de negócio, adotando uma visão holística da situação. Isso pode incluir a análise de elementos das estruturas da organização e questões de desenvolvimento da equipe, bem como os processos e sistemas de TI presentes atualmente. Avaliar ações para melhorar a operação de um sistema de negócios. Novamente, isso pode exigir um exame da estrutura organizacional e das necessidades de desenvolvimento da equipe, para garantir que estejam alinhadas com qualquer redesenho de processo proposto e desenvolvimento de sistema de TI.

A Gestão de Portfólio de Projetos (PPM, do inglês, Project Portfolio Management) trabalha diversos projetos em um único portfólio, com objetivos comuns de resultado. Visando a maximização dos benefícios e a otimização na alocação integrada dos recursos da empresa. Gerenciar um portfólio de projetos não é apenas executar vários projetos simultaneamente. Cada carteira (ou portfólio) de projetos deve ser analisada individualmente, buscando identificar sua capacidade de gerar valor para o negócio e sua aderência aos objetivos definidos no planejamento estratégico. No portfólio, deve constar um ou mais objetivos de negócio bem definidos e benefícios tangibilizados em metas. No que diz respeito ao gerente de projeto, seu trabalho é garantir que os seus projetos sejam desenvolvidos de forma correta e concluídos com sucesso. Enquanto isso, o gestor do portfólio trabalha para que os projetos certos sejam executados de forma a alcançar os objetivos da carteira. Portanto, para GDev, gerir o portfólio é um processo para garantir que ela gaste seus escassos recursos no trabalho de maior valor. Sendo assim, crucial para identificar possíveis contratempos que podem ocorrer em projetos individualmente e determinar um valor comparativo para cada.

O PIPEFY é uma plataforma de gestão de produtividade, que permite o acompanhamento das demandas de forma visual com estruturas de colunas semelhantes a estrutura do Kanban. Essa característica visual torna a ferramenta compatível com a estrutura atual da GDEV. Além de possibilitar a criação de formulários dinâmicos o que permite a escalabilidade e adaptabilidade a novos cenários e atende a busca interna de melhoria contínua. A ferramenta e adaptada para trabalhar com o evento Sprint do Scrum que é utilizado por todos os times da GDEV. Além de permitir a criação dinâmica de relatórios de qualquer dado criado na plataforma, bem como a exportação desses dados em diversos formatos.