Os governos alteram anualmente o roteiro do produto FreeBalance class=

Os governos alteram anualmente o roteiro do produto FreeBalance

FreeBalance International Steering CommitteePusemos os nossos clientes a trabalhar no FreeBalance International Steering Committee de 2018, em Miami, no mês passado. O as oficinas de governação utilizaram técnicas de desenvolvimento ágil adaptados ao contexto governamental. A FreeBalance utiliza uma abordagem única centrada no cliente para o nosso roteiro de produtos e serviços. (Sim, nós fornecemos consultoriaimplementaçãosustentabilidade serviços).
As práticas de roteiro dos fornecedores de software empresarial são semelhantes entre os fornecedores. Os gestores de produto desenvolvem roteiros com base no feedback dos parceiros de integração de sistemas e nos pedidos de funcionalidades dos clientes. A principal ligação dos clientes aos fabricantes de software é feita através de parceiros de integração de sistemas. Estas empresas de integração de sistemas geram receitas através da personalização de código. Os incentivos não estão necessariamente alinhados com os clientes. Os fabricantes raramente estão envolvidos diretamente nas implementações.
Os pedidos de melhoria dos produtos chegam aos fabricantes de software através do canal de apoio ao cliente. Os fabricantes estão frequentemente desligados dos clientes. Espera-se que os gestores de produto compensem esta falta de feedback. As práticas aceites de gestão de produtos incluem a gestão e a triangulação de pedidos de funcionalidades. Os roteiros dos produtos tornam-se "lotarias de funcionalidades". Os resultados desiludem frequentemente todos os mercados verticais de igual modo.

Gestão do roteiro do projeto: Abordagem de planeamento de recursos empresariais
Contexto e roteiros de produtos

Compreender o contexto é o desafio mais difícil para os gestores de produto. Muitas vezes, os gestores de produto têm de adivinhar porque é que os clientes estão a pedir funcionalidades específicas. Que problema é que esta funcionalidade vai resolver? É um problema partilhado e deve fazer parte do produto? A gestão do roteiro depende muitas vezes da experiência e da opinião do gestor de produto. Os gestores de produto têm muitas vezes de abstrair vários pedidos para identificar padrões.
Isto acontece na sequência de ideias "brilhantes" dos executivos ou de reacções das equipas de desenvolvimento que têm preferências de engenharia. (Há um ditado que diz que os Gestores de Produto são como mini-CEOs - isso é altamente enganador porque os Gestores de Produto não têm privilégios de "contratar e despedir").
Os gestores de produtos têm frequentemente de equilibrar as necessidades de funcionalidades com ideias tecnológicas. A tecnologia emergente é mais interessante, mas os Gestores de Produto são frequentemente confrontados com a criação de soluções de ponta em busca de problemas.
É feito um grande esforço para traçar o futuro dos produtos. Os diagramas Visio e as apresentações em PowerPoint proliferam. Os fabricantes de software elaboram roteiros complexos ao longo de muitos anos. Isto parece estranho, dado o ritmo da mudança tecnológica. Vimos inúmeros casos em que os fabricantes não conseguiram prever as necessidades futuras. Muitos produtos novos, e novas versões de produtos de software empresarial existentes, receberam uma reação pouco positiva por parte dos clientes.
O que acontece quando as grandes empresas de software empresarial entram em novos mercados com roadmaps optimistas? Na maioria das vezes, estas empresas têm de adquirir empresas ágeis.
A abordagem tradicional do roteiro do software empresarial está quebrada.

Abordagem de roteiro ininterrupto centrado no cliente

A FreeBalance tem usado uma abordagem de votação de roteiro nas conferências FISC desde 2007. Esta abordagem é facilitada pelo nosso foco exclusivo no governo. Não vendemos para nenhum outro "mercado vertical". Também é facilitada pelo nosso envolvimento em todas as implementações. Recebemos informações directas da nossa equipa de serviços de implementação. Além disso, recebemos informações indirectas dos parceiros de integração de sistemas e através de pedidos directos de funcionalidades.
Gestão do roteiro de produtos: Abordagem centrada no cliente
A FISC fornece o contexto subjacente aos pontos do roteiro. O nosso roteiro é ajustado todos os anos na FISC através de um processo de votação. Como escrevi em 2014:
Em 2007, procurámos alterar a dinâmica dos eventos centrados no produto para eventos centrados no cliente. Isto significava que grande parte da cerimónia associada às conferências de fornecedores tinha de mudar:

  • Empresa para as necessidades do cliente: mudar o foco do que a empresa precisa para o que os clientes estão preocupados, independentemente da contribuição da FreeBalance para as soluções.
  • Vender para o envolvimento: mudar a tónica da empresa em relação às vendas, integrando na conferência executivos e gestores em vez de vendedores. Envolver os clientes para podermos melhorar os produtos e serviços.
  • Ditar para colaborar: mudar a dinâmica de ditar quais os produtos que serão fornecidos e quando, para clientes que alteram as prioridades dos produtos, adaptando o roteiro e trabalhando em conjunto para objectivos comuns.
  • Controlo do fórum: mudar o paradigma das comunicações, passando de apresentações controladas para um fórum em que os clientes se envolvem com outros clientes, oradores externos e funcionários da FreeBalance para aprender o que funciona na reforma da Gestão das Finanças Públicas (GFP).

Roteiro do produto FreeBalance
Isto deixa-nos numa situação interessante, porque os fornecedores de software empresarial condicionaram os compradores a esperar roteiros centrados no fornecedor, em vez de centrados no cliente
ciclos de feedback. Os potenciais clientes querem ver o nosso roteiro para 5 ou 10 anos. Poderíamos produzir um documento que cumprisse este objetivo, mas seria um exercício de futilidade. O nosso roteiro de produtos e serviços muda todos os anos. Os ciclos tecnológicos estão mais curtos. Tal como acima referido, concentramo-nos na administração pública e na Mapa da Componente de Gestão das Finanças Públicas. Esta é a visão central por detrás do FreeBalance Accountability Suite. O nosso roteiro é delimitado por este mapa de componentes. Efetivamente, o nosso roteiro inclui tudo o que consta do mapa de componentes da GFP.
Mapa de componentes PFM
O nosso roteiro é composto por itens previstos para 1 ano, 2 anos e 2+anos. Estes mudam todos os anos. É por isso que utilizamos processos ágeis e integramos o desenvolvimento de produtos com serviços de implementação no nosso A-i3+qTM metodologia.

Tendências do roteiro do FreeBalance

Este foi o meu 12º ano a recolher feedback do nosso roteiro de produtos. Tem sido uma viagem fascinante descobrir as aspirações de ganho e os pontos fracos da governação. Algumas das tendências que testemunhei incluem:

  • Aditamento de um roteiro de serviços devido às lacunas dos prestadores de serviços tradicionais e dos parceiros doadores
  • Maior atenção aos requisitos não funcionais, especialmente para melhorar a manutenção, reduzir os custos operacionais e melhorar a integração com subsistemas não-FreeBalance
  • Aumento da literacia e da capacidade tecnológica
  • Descobrir soluções de usabilidade que reduzam as pegadas de formação

O roteiro de 2018 incluía produtos e serviços com tecnologias emergentes como "blockchain", aprendizagem automática, desenvolvimento de baixo código e governo inteligente.
Este ano, passámos mais tempo do que nos anos anteriores a articular os motivos pelos quais os produtos ou serviços eram benéficos. Estas declarações de benefícios estavam alinhadas com as finanças públicas, a função pública e os requisitos de transparência que muitos governos partilham. Tenho o prazer de dizer que o principal item do roteiro veio do brainstorming de clientes da FISC. (Uma das minhas ideias ficou em segundo lugar, com 98% de votos do item principal).

O Agile alarga organicamente os roteiros dos produtos

Reescrevemos o nosso software com uma arquitetura orientada para os serviços (SOA) ao nível dos componentes. Isto permitiu-nos compor novas aplicações baseadas em componentes comerciais reutilizáveis, a que chamamos "entidades governamentais" num design unificado. Esta reutilização facilita o nosso roteiro de produtos.
Roteiro do produto FreeBalance Agile
Esta abordagem também permite o desenvolvimento personalizado, incluindo o desenvolvimento de aplicações governamentais únicas. Estes provêm de leis de reforma únicas. No entanto, quase todas as implementações do FreeBalance estão sujeitas a alguma legislação específica. A nossa abordagem a esta situação difere das normas do mercado.
As empresas de integração de sistemas personalizam o código para necessidades específicas. Essa é a prática aceite. Como descrito num post da semana passadaSe o cliente não tiver acesso ao código órfão e à dívida técnica, isso deixará os clientes "sem saída".
O FreeBalance faz sempre parte dos contratos de implementação do governo. A personalização para necessidades únicas é um requisito contratual.
Processo de desenvolvimento personalizado do FreeBalance
A FreeBalance personaliza o código para os clientes na maioria das situações. O FreeBalance tem um Ambiente de Desenvolvimento Integrado (IDE) construído sobre Eclipse. Os parceiros e os clientes podem ser formados. Poucos clientes o fizeram devido à elegância do A-i3+qTM metodologia para o desenvolvimento personalizado.

  • A equipa de serviços no local da FreeBalance cria storyboards e casos de utilização de forma interactiva com os clientes
  • A equipa de gestão do produto FreeBalance valida estes dados utilizando conhecimentos tecnológicos e identifica outras formas de alargar o âmbito de aplicação das entidades governamentais a outros requisitos do Mapa de Componentes da GFP
  • Os storyboards e casos de utilização validados são aprovados pelos clientes
  • A equipa de gestão de produtos FreeBalance desenvolve especificações
  • O desenvolvimento de produtos FreeBalance valida as especificações antes de desenvolver o código
  • A equipa de serviços no local da FreeBalance contribui para a garantia de qualidade para assegurar que o resultado satisfaz as necessidades do país
  • Os testes de aceitação do utilizador pelo cliente validam a utilização do código na produção (ou demonstram a necessidade de adaptar as especificações)

O diagrama acima sugere que o processo chega ao fim com a aprovação do UAT do cliente. Isso é um pouco enganador porque só termina o processo de colocar o software em produção....

Tópicos

Contacto