¶ Estratégia de Entrega MVP do Portal do Governo de Rondônia
| Data de elaboração | 15/12/2025 |
| Responsável pelo estudo | João Marcos Sales Oliveira (UX) |
| Equipe do estudo | João Marcos Sales Oliveira (UX) Escarlet Imopoco Lima (PO) |
| Alvo | Portal do Governo de Rondônia |
| Origem | Objetivo Estratégico: Antecipar a entrega de valor público e mitigar riscos de atraso no desenvolvimento. - Contexto: Necessidade de validar a viabilidade técnica de entrega considerando a alocação de recursos humanos limitados (1 Desenvolvedor) versus o cenário ideal (2 Desenvolvedores). - Desafio: Equilibrar a complexidade da configuração dos plugins (Elementor, PublishPress, Wordfence) com o prazo de execução estimado em 100 dias úteis. - Solução: Adoção do conceito de Mínimo Produto Viável (MVP) para entregas incrementais. |
| Objetivo | Definir o escopo do MVP para o Portal do Governo, estabelecendo o cronograma de Sprints prioritárias |
| Documentação correlata | Estudo de Planejamento para as Ações de Desenvolvimento do Portal do Governo de Rondônia |
| Observações | Este estudo assume a metodologia ágil onde 1 Sprint equivale a 10 dias úteis. As estimativas de tempo consideram dias de trabalho focado e podem sofrer alterações mediante dependências externas, aprovações de layout, atravessamentos e impedimentos. |
¶ Contextualização
No contexto de desenvolvimento de software moderno, especialmente sob restrições de recursos técnicos (poucos desenvolvedores alocados), a adoção do conceito de Mínimo Produto Viável (MVP) torna-se não apenas uma estratégia de agilidade, mas uma medida de segurança para o sucesso do projeto.
¶ O que é o MVP?
O MVP não deve ser confundido com um produto «incompleto» ou de «baixa qualidade». Trata-se da versão mais enxuta de um produto que ainda assim resolve o problema central do usuário (neste caso, o cidadão e os servidores da SECOM). O objetivo é entregar as funcionalidades vitais primeiro, permitindo que o portal entre no ar e comece a gerar valor público, enquanto funcionalidades secundárias são desenvolvidas em paralelo.
¶ Por que adotar o MVP neste Projeto?
Considerando a estimativa técnica de 15 meses para o desenvolvimento completo com um único profissional, confome Estudo de Planejamento para as Ações de Desenvolvimento do Portal do Governo de Rondônia, a abordagem MVP oferece três vantagens críticas para a administração pública:
-
Antecipação de Valor Público: Em vez de esperar 100 dias para ter o portal no ar, o governo pode lançar o núcleo do portal (Home, Notícias e Transparência) em um prazo menor, atendendo à demanda da sociedade mais rapidamente.
-
Redução de Riscos: Projetos longos tendem a sofrer com mudanças de escopo ou obsolescência tecnológica antes mesmo do lançamento. O MVP permite testar a infraestrutura e a usabilidade em ambiente real, corrigindo rotas sem grandes prejuízos.
-
Eficiência de Recursos: Focar no essencial garante que o tempo do desenvolvedor seja gasto no que realmente importa para o cidadão, evitando o desperdício de horas em funcionalidades que podem ser pouco utilizadas.
¶ Cronograma Resumido de Desenvolvimento (Cenário Base)
Considerando o cenário atual de alocação de 01 (um) Desenvolvedor, o esforço técnico total foi estimado em 100 dias úteis. Adotando a metodologia ágil onde 1 Sprint = 10 dias úteis, o projeto se desenrola ao longo de 10 Sprints sequenciais.
Abaixo, a distribuição das atividades críticas ao longo deste período:
| Sprints | Foco da Entrega | Atividades Principais | Duração Estimada |
|---|---|---|---|
| Sprint 01 | Fundação e Segurança | • Instalação e configuração do plugin Wordfence Premium. • Configuração inicial do Elementor Pro. |
10 dias |
| Sprints 02 e 03 | Governança Editorial | • Configuração do PublishPress Revisions Pro (Fluxos de aprovação e revisão da SECOM). | 20 dias |
| Sprints 04 e 05 | Identidade Visual | • Desenvolvimento da Home do Portal (Layout, menus, responsividade e estrutura visual). | 20 dias |
| Sprints 06 e 07 | Estrutura Institucional | • Desenvolvimento da Página das 57 Entidades (Secretarias e Órgãos vinculados). | 20 dias |
| Sprint 08 | Dados e Permissões | • Gestão de usuários e funções hierárquicas. • Configuração e indexação dos posts nas entidades específicas. |
10 dias* |
| Sprints 09 e 10 | Experiência do Usuário | • Finalização da indexação. • Desenvolvimento dos Templates de Posts (Visualização final da notícia para o visitante). |
20 dias* |
| TOTAL | MVP FUNCIONAL | Ciclo completo de desenvolvimento com 1 profissional. | 100 Dias Úteis |
*Nota: Algumas atividades menores foram agrupadas para compor o tempo da Sprint.
¶ Metodologia de Estimativa: Decomposição por Componentes
Para assegurar a precisão do cronograma de 100 dias apresentado acima, foi realizada uma decomposição granular dos esforços de desenvolvimento baseada no protótipo de alta fidelidade. A estimativa não considera apenas a «página» como um todo, mas o custo técnico de cada bloco visual (seção), considerando a ferramenta necessária (ex.: Elementor Gratuito ou Pago) e a complexidade de Backend/Frontend.
A imagem abaixo exemplifica essa metodologia aplicada aos principais componentes visuais da Interface Principal (Home e Estrutura Global), que compõem as Sprints 04, 05:
Imagem 01: Decomposição dos elementos da página Home do protótipo do Portal
Imagem 02: Decomposição da implementação da Gestão de usuários
Imagem 03: Decomposição de implementação de código legado do projeto do Portal em produção
¶ Dimensionamento de Equipe e Análise de Esforço
A análise técnica demonstra que o prazo de entrega é altamente sensível à quantidade de desenvolvedores alocados. Devido à natureza modular do WordPress, muitas tarefas podem ser executadas em paralelo (ex: um desenvolvedor foca no Backend/Fluxos enquanto outro foca no Frontend/Visual).
A tabela abaixo compara o esforço necessário entre manter a equipe atual ou duplicar a capacidade técnica:
| Atividade Técnica | 👤 Cenário Atual (1 Desenvolvedor) |
👥 Cenário Otimizado (2 Desenvolvedores) |
📉 Redução de Prazo |
|---|---|---|---|
| Instalação/Configuração Wordfence Premium | 5 dias | 3 dias | -2 dias |
| Instalação/Configuração Elementor Pro | 5 dias | 3 dias | -2 dias |
| Instalação/Configuração PublishPress (Fluxos) | 20 dias | 10 dias | -10 dias |
| Desenvolvimento da Home | 20 dias | 15 dias | -5 dias |
| Página das 57 Entidades | 20 dias | 10 dias | -10 dias |
| Gestão de Usuários (Funções) | 5 dias | 3 dias | -2 dias |
| Configuração e Indexação de Posts | 10 dias | 5 dias | -5 dias |
| Template dos Posts (Frontend) | 15 dias | 10 dias | -5 dias |
| TOTAL GERAL (DIAS ÚTEIS) | 100 dias | 59 dias | ⬇️ 41 dias |
¶ Justificativa de Ganho de Eficiência
A redução de 41 dias úteis (aprox. 2 meses de calendário) no Cenário Otimizado ocorre devido a dois fatores:
- Paralelismo: Enquanto o Desenvolvedor A trabalha na complexa configuração lógica das 57 entidades (Backend), o Desenvolvedor B pode construir simultaneamente a interface visual da Home e os Templates de Posts (Frontend). No cenário atual, o único desenvolvedor precisa terminar uma tarefa para iniciar a outra.
- Especialização Temporária: Em duplas, problemas complexos são resolvidos mais rápido (Pair Programming), reduzindo o tempo de bloqueio em configurações difíceis, como as permissões do PublishPress.
Conclusão do Dimensionamento:
Embora o projeto seja viável com 1 desenvolvedor (100 dias), a alocação de um segundo profissional reduz o tempo de entrega em 41%, permitindo que o MVP seja entregue à sociedade em pouco menos de 3 meses (6 Sprints), contra os 5 meses (10 Sprints) do cenário atual.
¶ Riscos e Limitações do Escopo
É fundamental ressaltar que as estimativas de esforço apresentadas neste estudo baseiam-se na análise do protótipo atual e da estrutura visível do portal em produção. Contudo, a fase de ideação aprofundada para o novo projeto ainda será realizada.
Existe uma dependência crítica identificada relacionada a entidades que possuem alto nível de customização via código (hard code) no ambiente atual, tendo a SUPEL como principal exemplo.
Considerando que a premissa estratégica do novo portal é a utilização majoritária de plugins padrão (abordagem Low-Code) para garantir a independência das secretarias e minimizar a manutenção técnica, destaca-se que:
- Limitação do MVP: O escopo deste MVP concentra-se na entrega da estrutura padrão que atende à maioria das secretarias. Ele não contempla, nesta fase inicial, a refatoração de regras de negócio complexas ou customizações profundas de código existentes no sistema legado.
- Necessidade de Ideação Específica: Durante a fase de ideação, será mandatório discutir caso a caso a situação dessas entidades (como a SUPEL). O objetivo será encontrar alternativas viáveis dentro do ecossistema de plugins ou definir se haverá necessidade de um «projeto paralelo» ou Sprints adicionais exclusivas para tratar essas exceções, sem comprometer a entrega do MVP para o restante do governo.
¶ Resumo da Evolução e Versões do Estudo
A tabela a seguir apresenta as versões do estudo, com datas de criação e atualização, destacando as principais alterações realizadas ao longo do tempo:
| Versão | Data da Criação | Data da Atualização | Notas da Versão |
|---|---|---|---|
| 1 | 15/12/2025 | 16/12/2025 | Elaboração inicial do estudo técnico focado na Estratégia de Entrega via MVP (Mínimo Produto Viável). Principais Inclusões: • Definição de Estratégia MVP para antecipação de valor e redução de riscos; • Cronograma físico detalhado em Sprints (Fases de Infraestrutura, Interface, Segurança e Expansão); • Comparativo de esforço técnico: 1 vs 2 Desenvolvedores (Redução de prazo de 100 para 59 dias); • Justificativa técnica e funcional da stack de plugins; • Inclusão de ponto de atenção crítico sobre customizações legadas (SUPEL) e fase de ideação. |