Pusemos os nossos clientes a trabalhar no Comité Director Internacional FreeBalance de 2018 em Miami no mês passado. O oficinas de governação alavancaram técnicas de desenvolvimento ágeis adaptado 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 consultoria, implementaçãoe sustentabilidade serviços).
As práticas do roteiro do fornecedor de software empresarial são semelhantes entre os fornecedores. Os gestores de produtos desenvolvem roteiros com base no feedback dos parceiros de integração de sistemas e nos pedidos de características dos clientes. A principal ligação do cliente aos fabricantes de software é 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ódigos. Os incentivos não são necessariamente alinhados com os clientes. Os fabricantes raramente estão directamente envolvidos nas implementações.
Os pedidos de melhoramento de produtos chegam aos fabricantes de software através do canal de apoio ao cliente. Os fabricantes sã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 triangulação de pedidos de funcionalidades. Os roteiros de produtos tornam-se "lotarias de características". Os resultados decepcionam frequentemente todos os mercados verticais por igual.
![Gestão do roteiro do projecto: Abordagem de Planeamento de Recursos Empresariais]()
Contexto e roteiros de produtos
A compreensão do contexto é o desafio mais difícil para os Gestores de Produto. Os Gestores de Produto têm muitas vezes de adivinhar porque é que os clientes estão a pedir características específicas. Que problema irá esta funcionalidade resolver? É um problema partilhado e deve fazer parte do produto? A gestão do roteiro depende frequentemente da experiência e da opinião do Gestor de Produto. Os Gestores de Produto têm muitas vezes de abstrair múltiplos pedidos para identificar padrões.
Isto vem na sequência de ideias 'brilhantes' de executivos, ou de um recuo 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 muitas vezes de equilibrar as necessidades com as 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 vanguarda na procura de problemas.
É feito um grande esforço para mapear os futuros produtos. Os diagramas Visio, as apresentações em PowerPoint proliferam. Os fabricantes de software constroem roteiros complexos ao longo de muitos anos. Isto parece estranho dado o ritmo da mudança tecnológica. Temos visto numerosos casos em que os fabricantes foram incapazes de prever as necessidades futuras. Muitos produtos novos, e novas versões de produtos de software empresarial existentes, têm recebido uma resposta negativa por parte dos clientes.
O que acontece depois das grandes empresas de Software Empresarial entrarem em novos mercados com roteiros optimistas? Mais frequentemente que não, estas empresas têm de adquirir empresas ágeis.
A abordagem tradicional do roteiro do Enterprise Software está quebrada.
Abordagem do Roteiro Inquebrável Centrada no Cliente
A FreeBalance tem vindo a utilizar uma abordagem de votação do roteiro nas conferências da FISC desde 2007. Esta abordagem é facilitada pelo nosso enfoque exclusivo do governo. Não vendemos para nenhum outro "mercado vertical". É também facilitada pelo nosso envolvimento em todas as implementações. Recebemos contributos directos do nosso pessoal de serviços de implementação. E, recebemos contributos indirectos de parceiros de integração de sistemas, e através de pedidos directos de funcionalidades.
O FISC fornece o contexto por detrás dos itens do roteiro. O nosso roteiro é ajustado todos os anos no FISC através de um processo de votação. Como escrevi em 2014:
Procurámos mudar a dinâmica de eventos centrados no produto para eventos centrados no cliente em 2007. Isto significou que grande parte da cerimónia associada às conferências de vendedores teve 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 de qual possa ser a contribuição da FreeBalance para as soluções.
- Venda à Engagement: mudar a ênfase comercial da venda através da contratação de pessoal para a conferência com executivos e gestores em vez de vendedores. Envolver os clientes para que possamos melhorar os produtos e serviços.
- Ditar para Colaborar: mudar a dinâmica de ditar que produtos serão fornecidos quando aos clientes mudar as prioridades dos produtos, adaptar o roteiro e trabalhar em conjunto para objectivos comuns.
- Controlo para o fórum: mudar o paradigma das comunicações de apresentações manhosas e controladas para um fórum onde os clientes envolvem outros clientes, oradores externos e pessoal da FreeBalance para aprender o que funciona na reforma da Gestão Financeira Pública (GFP).
Estes deixam-nos numa situação interessante porque os vendedores de Enterprise Software condicionaram os compradores à expectativa de roteiros centrados no vendedor, em vez de centrados no cliente.
loops de feedback. Os potenciais clientes querem ver o nosso roteiro de 5 ou 10 anos. Poderíamos produzir um documento que cumpra este objectivo, mas é um exercício de futilidade. O nosso roteiro de produtos e serviços muda anualmente. Os ciclos tecnológicos foram comprimidos. Como demonstrado acima, concentramo-nos no governo e no Mapa da Componente de Gestão das Finanças Públicas. Esta é a visão central por detrás da FreeBalance Accountability Suite. O nosso roteiro é delimitado por este mapa de componentes. Efectivamente, o nosso roteiro inclui qualquer coisa no mapa de componentes da PFM.
O nosso roteiro consiste em itens previstos para 1 ano, 2 anos e 2+anos. Estes mudam todos os anos. É por isso que aproveitamos processos ágeis e integramos o desenvolvimento de produtos com serviços de implementações no nosso A-i3+qM TM metodologia.
Tendências do Roteiro FreeBalance
Este foi o meu 12º ano a recolher o feedback do nosso roteiro de produtos. Tem sido uma viagem fascinante, revelando aspirações de ganho e pontos de dor na governação. Algumas das tendências que testemunhei incluem:
- Adição de um roteiro de serviços devido a lacunas dos prestadores de serviços tradicionais e dos parceiros doadores
- Maior enfoque nos requisitos não funcionais, particularmente para uma melhor manutenção, custos operacionais mais baixos e melhor integração com subsistemas não-FreeBalance
- Aumento da alfabetização tecnológica e da capacidade
- Descobrindo soluções de usabilidade que reduzem as pegadas de treino
O roteiro de 2018 tinha produtos e serviços com tecnologias emergentes como a "cadeia de bloqueio", aprendizagem de máquinas, desenvolvimento de código baixo, e governo inteligente.
Passámos mais tempo este ano a articular a razão pela qual os produtos ou serviços foram benéficos do que nos anos anteriores. Estas declarações de benefícios foram alinhadas com os requisitos de finanças públicas, função pública e transparência que muitos governos partilham. Tenho o prazer de dizer que o principal item do roteiro veio de um brainstorming de clientes do FISC. (Uma das minhas ideias veio em segundo lugar com 98% de votos do item superior).
Agile estende organicamente os roteiros de produtos
Reescrevemos o nosso software com um componente de Arquitectura Orientada para Serviços (SOA). Isto permitiu-nos compor novas aplicações baseadas em componentes empresariais reutilizáveis, a que chamamos "entidades governamentais" num desenho unificado. Esta reutilização facilita o nosso roteiro de produtos.
Esta abordagem também permite o desenvolvimento personalizado, incluindo o desenvolvimento de aplicações governamentais únicas. Estas provêm de leis de reforma únicas. Mas, quase todas as implementações FreeBalance estão sujeitas a alguma legislação única. 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. Esta é a prática aceite. Como descrito num post na semana passadaIsto deixa os clientes "altos e secos" com código órfão e dívida técnica.
O FreeBalance faz sempre parte dos contratos de implementação governamentais. A personalização para necessidades únicas são requisitos contratuais.
O FreeBalance personaliza o código para clientes na maioria das situações. O FreeBalance tem um Ambiente de Desenvolvimento Integrado (IDE) construído sobre Eclipse. Parceiros e clientes podem ser formados. Poucos clientes o fizeram por causa da elegância do A-i3+qM TM metodologia para o desenvolvimento personalizado.
- O pessoal dos serviços no local FreeBalance constrói storyboards e utiliza os casos interactivamente com os clientes
- O pessoal de gestão de produtos FreeBalance valida este input utilizando conhecimentos tecnológicos, e identifica mais como as entidades governamentais podem ser alargadas para outros requisitos do Mapa de Componentes PFM
- Os storyboards validados e os casos de utilização são aprovados pelos clientes
- O pessoal de gestão de produtos FreeBalance desenvolve especificações
- O desenvolvimento do produto FreeBalance valida as especificações antes de desenvolver o código
- O pessoal dos serviços no local da FreeBalance acrescenta à garantia de qualidade para assegurar que o resultado satisfaz as necessidades do país
- O teste de aceitação do utilizador cliente valida a utilização do código na produção (ou demonstra a necessidade de adaptar as especificações)
O diagrama acima sugere que o processo chega ao fim com a aprovação da UAT do Cliente. Isso é um pouco enganador porque apenas termina o processo de entrada do software em produção....