Colocamos nossos clientes para trabalhar no Comitê Diretor Internacional da FreeBalance de 2018, em Miami, no mês passado. Os os workshops de governança aproveitaram as técnicas de desenvolvimento ágil adaptados ao contexto governamental. A FreeBalance utiliza uma abordagem exclusiva centrada no cliente em nosso roteiro de produtos e serviços. (Sim, nós fornecemos consultoria, implementaçãoe sustentabilidade serviços).
As práticas de roadmap dos fornecedores de software corporativo são semelhantes entre os fornecedores. Os gerentes de produto desenvolvem roadmaps com base no feedback dos parceiros de integração de sistemas e nas solicitações de recursos dos clientes. A principal conexão do cliente com os fabricantes de software é por meio de parceiros de integração de sistemas. Essas empresas de integração de sistemas geram receita por meio da personalização de códigos. Os incentivos não estão necessariamente alinhados aos clientes. Os fabricantes raramente estão envolvidos diretamente com as implementações.
As solicitações de aprimoramento de produtos chegam aos fabricantes de software por meio do canal de suporte ao cliente. Os fabricantes geralmente estão desconectados dos clientes. Espera-se que os gerentes de produto compensem essa falta de feedback. As práticas aceitas de gerenciamento de produtos incluem o gerenciamento e a triangulação de solicitações de recursos. Os roteiros de produtos tornam-se "loterias de recursos". Os resultados geralmente decepcionam igualmente todos os mercados verticais.
![Gerenciamento do roteiro do projeto: Abordagem de planejamento de recursos empresariais]()
Contexto e roteiros de produtos
Entender o contexto é o desafio mais difícil para os gerentes de produto. Os gerentes de produto geralmente precisam adivinhar por que os clientes estão solicitando recursos específicos. Que problema esse recurso resolverá? É um problema compartilhado e deve fazer parte do produto? O gerenciamento do roadmap geralmente depende da experiência e da opinião do gerente de produto. Os gerentes de produto geralmente precisam abstrair várias solicitações para identificar padrões.
Isso ocorre depois de ideias "brilhantes" dos executivos ou de reações contrárias das equipes de desenvolvimento que têm preferências de engenharia. (Há um ditado que diz que os gerentes de produto são como mini-CEOs - isso é altamente enganoso porque os gerentes de produto não têm privilégios de "contratar e demitir").
Os gerentes de produtos geralmente precisam equilibrar as necessidades de recursos com as ideias de tecnologia. A tecnologia emergente é mais interessante, mas os gerentes de produtos muitas vezes se deparam com a criação de soluções de ponta em busca de problemas.
É feito um grande esforço para mapear o futuro dos produtos. Diagramas Visio e apresentações em PowerPoint proliferam. Os fabricantes de software elaboram roadmaps complexos ao longo de muitos anos. Isso parece estranho, dado o ritmo das mudanças tecnológicas. Já vimos vários casos em que os fabricantes não conseguiram prever as necessidades futuras. Muitos produtos novos e novas versões de produtos de software corporativo existentes receberam uma resposta insatisfatória dos clientes.
O que acontece depois que grandes empresas de software corporativo entram em novos mercados com roadmaps otimistas? Na maioria das vezes, essas empresas precisam adquirir empresas ágeis.
A abordagem tradicional de roadmap de 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 da FISC desde 2007. Essa abordagem é facilitada por nosso foco exclusivo no governo. Não vendemos para nenhum outro "mercado vertical". Ela também é facilitada por nosso envolvimento em todas as implementações. Recebemos informações diretas da nossa equipe de serviços de implementação. Além disso, recebemos informações indiretas de parceiros de integração de sistemas e por meio de solicitações diretas de recursos.
A FISC fornece o contexto por trás dos itens do roteiro. Nosso roteiro é ajustado todos os anos no FISC por meio de um processo de votação. Como escrevi em 2014:
Em 2007, procuramos mudar a dinâmica de eventos centrados no produto para eventos centrados no cliente. Isso significou que grande parte da cerimônia associada às conferências de fornecedores teve que mudar:
- Necessidades da empresa para o 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.
- Vendendo para o engajamento: mudar a ênfase dos negócios em relação às vendas, colocando executivos e gerentes na conferência 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 quais produtos serão fornecidos e quando, para clientes que mudam as prioridades dos produtos, adaptando o roteiro e trabalhando juntos para objetivos comuns.
- Controle para o fórum: Mudar o paradigma das comunicações, passando de apresentações controladas e elegantes para um fórum em que os clientes se envolvem com outros clientes, palestrantes externos e a equipe da FreeBalance para aprender o que funciona na reforma da Gestão Financeira Pública (GFP).
Isso nos deixa em uma situação interessante, pois os fornecedores de software corporativo condicionaram os compradores a esperar roadmaps focados no fornecedor, em vez de focados no cliente
ciclos de feedback. Os clientes em potencial querem ver nosso roadmap de 5 ou 10 anos. Poderíamos produzir um documento que atendesse a esse objetivo, mas isso seria um exercício de futilidade. Nosso roteiro de produtos e serviços muda a cada ano. Os ciclos tecnológicos foram reduzidos. Conforme mostrado acima, nosso foco é o governo e a Mapa dos Componentes de Gestão Financeira Pública. Essa é a visão central por trás do FreeBalance Accountability Suite. Nosso roteiro é delimitado por esse mapa de componentes. Efetivamente, nosso roteiro inclui qualquer coisa no Mapa de Componentes de PFM.
Nosso roteiro consiste em itens esperados para 1 ano, 2 anos e mais de 2 anos. Esses itens mudam a cada ano. É por isso que utilizamos processos ágeis e integramos o desenvolvimento de produtos com serviços de implementação em nosso A-i3+qM TM metodologia.
Tendências do roteiro do FreeBalance
Este foi o meu 12º ano coletando feedback do nosso roteiro de produtos. Tem sido uma jornada fascinante descobrir aspirações de ganho e pontos problemáticos de governança. Algumas das tendências que testemunhei incluem:
- Adição de um roteiro de serviços devido a lacunas dos provedores de serviços tradicionais e dos parceiros doadores
- Maior foco nos requisitos não funcionais, especialmente para melhorar a capacidade de manutenção, reduzir os custos operacionais e melhorar a integração com subsistemas não-FreeBalance
- Aumento da alfabetização e da capacidade tecnológica
- Descobrir soluções de usabilidade que reduzam as pegadas de treinamento
O roteiro de 2018 tinha produtos e serviços com tecnologias emergentes como "blockchain", aprendizado de máquina, desenvolvimento com pouco código e governo inteligente.
Este ano, passamos mais tempo articulando por que os itens de produtos ou serviços eram benéficos do que nos anos anteriores. Essas declarações de benefícios estavam alinhadas com os requisitos de finanças públicas, serviço civil e transparência que muitos governos compartilham. Tenho o prazer de dizer que o principal item do roteiro veio do brainstorming de clientes do FISC. (Uma de minhas ideias ficou em segundo lugar com 98% de votos do item principal).
O Agile amplia organicamente os roteiros de produtos
Reescrevemos nosso software com uma arquitetura orientada a serviços (SOA) em nível de componente. Isso nos permitiu compor novos aplicativos com base em componentes comerciais reutilizáveis, que chamamos de "entidades governamentais" em um design unificado. Essa reutilização facilita o nosso roteiro de produtos.
Essa abordagem também permite o desenvolvimento personalizado, incluindo o desenvolvimento de aplicativos governamentais exclusivos. Eles vêm de leis de reforma exclusivas. Porém, quase todas as implementações do FreeBalance estão sujeitas a alguma legislação exclusiva. Nossa abordagem a essa 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 aceita. Como descrito em uma postagem na semana passadaIsso deixa os clientes "sem saída", com código órfão e dívida técnica.
O FreeBalance sempre faz parte dos contratos de implementação do governo. A personalização para necessidades exclusivas é um requisito contratual.
A FreeBalance personaliza o código para os clientes na maioria das situações. O FreeBalance tem um ambiente de desenvolvimento integrado (IDE) baseado em Eclipse. Parceiros e clientes podem ser treinados. Poucos clientes o fizeram devido à elegância do A-i3+qM TM metodologia para desenvolvimento personalizado.
- A equipe de serviços no local da FreeBalance constrói storyboards e utiliza os casos de forma interativa com os clientes
- A equipe de gerenciamento de produtos FreeBalance valida essa entrada usando conhecimento tecnológico e identifica como as entidades governamentais podem ser ampliadas para outros requisitos do Mapa de Componentes PFM
- Os storyboards validados e os casos de uso são aprovados pelos clientes
- O pessoal de gerenciamento de produtos FreeBalance desenvolve especificações
- O desenvolvimento de produtos FreeBalance valida as especificações antes de desenvolver o código
- O pessoal de serviços no local da FreeBalance acrescenta à garantia de qualidade para garantir que o resultado atenda às necessidades do país
- O teste de aceitação do usuário cliente valida o uso 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 do UAT do cliente. Isso é um pouco enganoso, pois só termina o processo de colocar o software em produção....