Colocamos nossos clientes para trabalhar no Comitê Diretivo Internacional FreeBalance 2018 em Miami, no mês passado. O oficinas de governança alavancaram técnicas ágeis de desenvolvimento adaptado ao contexto do governo. A FreeBalance utiliza uma abordagem única centrada no cliente para 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 gerentes de produto desenvolvem roteiros 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 é através de parceiros de integração de sistemas. Estas empresas de integração de sistemas geram receita através da personalização do código. Os incentivos não são necessariamente alinhados aos clientes. Os fabricantes raramente estão envolvidos diretamente com implementações.
Os pedidos de aprimoramento de produtos chegam aos fabricantes de software através do canal de suporte ao cliente. Os fabricantes são freqüentemente desconectados dos clientes. Espera-se que os gerentes de produto compensem esta 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 muitas vezes desapontam igualmente todos os mercados verticais.
![Gerenciamento do roteiro do projeto: Abordagem de planejamento de recursos empresariais]()
Contexto e roteiros de produtos
A compreensão do contexto é o desafio mais difícil para os Gerentes de Produto. Os Gerentes de Produto freqüentemente têm que adivinhar por que os clientes estão pedindo por características específicas. Que problema este recurso vai resolver? É um problema compartilhado e deve ser parte do produto? O gerenciamento do roteiro muitas vezes depende da experiência e da opinião do Gerente de Produto. Os Gerentes de Produto muitas vezes têm que abstrair várias solicitações para identificar padrões.
Isto vem na esteira de idéias 'brilhantes' de executivos, ou de um impulso de 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 despedir").
Os gerentes de produto freqüentemente têm que equilibrar as necessidades com as idéias de tecnologia. A tecnologia emergente é mais interessante, mas os Gerentes de Produto são freqüentemente confrontados com a criação de soluções de vanguarda em busca de problemas.
Um grande esforço é feito para mapear os futuros produtos. Os diagramas Visio, as apresentações em PowerPoint proliferam. Os fabricantes de software constroem complexos roteiros ao longo de muitos anos. Isto parece estranho dado o ritmo das mudanças tecnológicas. Temos visto inúmeros casos em que os fabricantes não foram capazes de prever as necessidades futuras. Muitos produtos novos, e novas versões de produtos de software empresarial já existentes, têm recebido uma resposta negativa por parte dos clientes.
O que acontece depois que grandes empresas de Software Empresarial entram em novos mercados com roteiros otimistas? Mais freqüentemente isso não acontece, essas empresas têm que adquirir empresas ágeis.
A abordagem tradicional do roteiro do Enterprise Software está quebrada.
Abordagem do roteiro centrada no cliente sem interrupções
A FreeBalance tem usado uma abordagem de votação de roteiro nas conferências da FISC desde 2007. Esta abordagem é facilitada por nosso foco exclusivo do governo. Nós não vendemos para nenhum outro "mercado vertical". Ela também é facilitada por nosso envolvimento em todas as implementações. Recebemos contribuições diretas de nossa equipe de serviços de implementação. E recebemos informações indiretas de parceiros de integração de sistemas, e através de solicitações diretas de recursos.
O FISC fornece o contexto por trás dos itens do roteiro. Nosso roteiro é ajustado a cada ano no FISC através de um processo de votação. Como eu escrevi em 2014:
Procuramos 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 fornecedores teve que 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.
- Vendendo para a Engagement: mudar a ênfase comercial da venda por meio de pessoal da conferência com executivos e gerentes 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 quando aos clientes mudando as prioridades do produto, adaptando o roteiro e trabalhando em conjunto para objetivos comuns.
- Controle para o fórum: mudar o paradigma de comunicação de apresentações manhosas e controladas para um fórum onde os clientes envolvem outros clientes, palestrantes externos e funcionários do FreeBalance para aprender o que funciona na reforma da Gestão Financeira Pública (GFP).
Isto nos deixa em uma situação interessante porque os fornecedores de Enterprise Software condicionaram os compradores a esperar roteiros focados no fornecedor, em vez de focados no cliente.
loops de feedback. Os clientes potenciais querem ver nosso roteiro de 5 anos ou 10 anos. Poderíamos produzir um documento que atenda a este objetivo, mas é um exercício de futilidade. Nosso roteiro de produtos e serviços muda anualmente. Os ciclos tecnológicos se comprimiram. Como mostrado acima, nós nos concentramos no governo e no Mapa dos Componentes de Gestão Financeira Pública. Esta é a visão central por trás do FreeBalance Accountability Suite. Nosso roteiro é delimitado por este mapa de componentes. Efetivamente, nosso roteiro inclui qualquer coisa no mapa de componentes da PFM.
Nosso roteiro consiste em itens previstos para 1 ano, 2 anos e 2+anos. Estes mudam a cada ano. É por isso que alavancamos 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 FreeBalance
Este foi meu 12º ano coletando o feedback de nosso roteiro de produtos. Tem sido uma jornada fascinante, descobrindo aspirações de ganho e pontos de dor na governança. Algumas das tendências que testemunhei incluem:
- Adição de um roteiro de serviços devido a lacunas de prestadores de serviços tradicionais e parceiros doadores
- Maior foco nos requisitos não-funcionais, especialmente para uma melhor manutenção, menores custos operacionais 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 treinamento
O roteiro de 2018 tinha produtos e serviços com tecnologias emergentes como "cadeia de bloqueio", aprendizagem de máquinas, desenvolvimento de código baixo e governo inteligente.
Passamos mais tempo este ano articulando porque os itens de produtos ou serviços foram benéficos do que nos anos anteriores. Estas declarações de benefícios foram alinhadas com as exigências de finanças públicas, serviço público e transparência que muitos governos compartilham. Tenho o prazer de dizer que o principal item do roteiro veio do brainstorming de clientes da FISC. (Uma de minhas idéias veio em segundo lugar com 98% de votos do item superior).
Agile amplia organicamente os roteiros de produtos
Reescrevemos nosso software com uma arquitetura orientada a serviços (SOA) de nível componente. Isto nos permitiu compor novas aplicações baseadas em componentes de negócios reutilizáveis, que chamamos de "entidades governamentais" em um projeto unificado. Esta reutilização facilita nosso roteiro de produtos.
Esta abordagem também permite o desenvolvimento personalizado, incluindo o desenvolvimento de aplicações governamentais exclusivas. Estes provêm de leis de reforma únicas. Mas, quase todas as implementações do FreeBalance estão sujeitas a alguma legislação única. Nossa abordagem a esta situação difere das normas de mercado.
As empresas de integração de sistemas personalizam o código para necessidades específicas. Essa é a prática aceita. Como descrito em um posto na semana passadaIsto deixa os clientes "altos e secos" 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 ú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 treinados. Poucos clientes o fizeram por causa da elegância do A-i3+qM TM metodologia para o 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 da UAT do Cliente. Isso é um pouco enganoso porque só termina o processo de colocar o software em produção....