Neste artigo, compartilharei minha experiência na seleção de idéias para o desenvolvimento da funcionalidade de nossos produtos e mostrarei como manter os principais vetores de desenvolvimento.
Estamos desenvolvendo um sistema automatizado de cobrança (ASR) - billing. Prazo
A vida do nosso produto é de 14 anos. Durante esse período, o sistema passou das primeiras versões da tarifa industrial para um complexo modular composto por 18 produtos que se complementam. Um dos aspectos mais importantes da vida longa dos programas é o desenvolvimento contínuo. E para o desenvolvimento, são necessárias idéias.
Idéias
Fontes
Existem 5 fontes:
- O principal amigo do desenvolvedor de sistemas de informações corporativas é o cliente . E o cliente é uma imagem coletiva de tomadores de decisão, patrocinadores de projetos, proprietários e executivos de processos, especialistas em TI, usuários comuns e um grande número de pessoas de interesses diferentes. É importante para nós que cada um dos representantes do cliente seja potencialmente um fornecedor de idéias. Na pior das hipóteses, obtemos apenas feedback negativo sobre problemas no sistema. Na melhor das hipóteses, do lado do cliente, há uma pessoa que é uma fonte constante de idéias para melhoria, fornecendo informações estruturadas sobre as necessidades do cliente.
- Nossos vendedores e gerentes de conta são a segunda fonte de idéias mais importante para aprimoramento. Eles se comunicam muito com os representantes do setor e recebem ativamente solicitações em primeira mão da funcionalidade de cobrança de clientes em potencial. Os vendedores e as contas precisam estar cientes de todas as alterações significativas em sua funcionalidade e das atualizações de software mais recentes dos concorrentes, para justificar os prós e contras de diferentes soluções. São esses funcionários que são os primeiros a sentir se algumas opções de cobrança se tornam um padrão de fato, sem o qual o software não pode ser considerado completo.
- O proprietário do produto é um dos nossos principais gerentes ou um gerente de projetos muito experiente. Ele mantém em mente os objetivos estratégicos da empresa e ajusta os planos de desenvolvimento de produtos de acordo com eles.
- Um arquiteto , uma pessoa que entende as possibilidades e limitações das soluções tecnológicas selecionadas / usadas e seu impacto no desenvolvimento de produtos.
Desenvolvimento, equipes de teste. Pessoas diretamente envolvidas no desenvolvimento de produtos.
Classificação dos recursos
De fontes, recebemos dados brutos - cartas, ingressos, solicitações verbais. Todos
os recursos são classificados:
- Consultas com o significado de "Como fazer isso?", "Como funciona?", "Por que não funciona?", "Eu não entendo ...". Esse tipo de chamada vai para a linha de suporte nível 1. Possível requalificação da consulta em outros tipos de aplicações.
- Incidentes com o significado de "Não funciona" e "Erro". Manipulado por 2 e 3 linhas de suporte. Se necessário, uma rápida correção e liberação do patch podem ser transferidas do suporte imediatamente para o desenvolvimento. É possível treinar novamente em uma solicitação de alteração e enviá-la para o backlog.
- Pedidos de mudança e desenvolvimento . Entre no backlog do produto ignorando as linhas de suporte. Mas para eles existe um procedimento de processamento separado.
Existem tais estatísticas sobre recursos - imediatamente após o lançamento, o número de recursos aumenta de 10 a 15% por um curto período de tempo. Além disso, surtos de chamadas acontecem quando um novo cliente com um grande número de usuários chega aos nossos serviços em nuvem. As pessoas aprendem a usar os novos recursos do software, precisam de conselhos. Mesmo um pequeno cliente no início do trabalho no sistema queima facilmente mais de 100 horas de consultas por mês. Portanto, ao conectar um novo cliente, sempre reservamos tempo para as consultas iniciais. Muitas vezes, até destacamos um especialista específico. O custo do aluguel, é claro, não paga esses custos trabalhistas, mas com o tempo a situação é nivelada. O período de adaptação leva, em regra, de 1 a 3 meses, então a necessidade de aconselhamento é significativamente reduzida.
Anteriormente, usamos soluções auto-escritas para armazenar chamadas. Mas gradualmente mudou para os produtos Atlassian. Primeiro, desenvolvemos o desenvolvimento para facilitar o trabalho no Agile, depois o suporte. Agora, todos os processos críticos vivem no Jira SD, além de serem fornecidos por vários plugins para o Jira, além do Confluence. As soluções auto-escritas permaneceram apenas em processos que não eram críticos para as atividades da empresa. Verificou-se que nossas tarefas agora são transversais, podem ser transferidas entre suporte e desenvolvimento sem passar de um sistema para outro.
Deste pacote, podemos obter dados sobre todas as tarefas, custos de mão de obra planejados e reais, usar várias opções de tarifas para os clientes e gerar documentação para necessidades internas e reportar aos clientes.
Processamento de Solicitações de Mudança
Normalmente, esses pedidos vêm na forma de requisitos funcionais. Nosso analista estuda a solicitação, gera uma especificação e um ToR de nível superior. Ele passa a especificação e a declaração de trabalho para a pessoa que enviou essa solicitação de aprovação - precisamos ter certeza de que falamos o mesmo idioma com o cliente.
Depois de receber a confirmação do cliente de que nos entendemos corretamente, o analista grava a solicitação no backlog do produto.
Gerenciamento de produtos
A lista de pendências acumula solicitações de entrada para mudança e desenvolvimento. A cada seis meses, é convocado um conselho técnico, composto por um diretor, gerente de manutenção, desenvolvimento, vendas e arquiteto de sistemas. No formato de discussão, o quadro analisa e prioriza aplicativos da lista de pendências e coordena 5 tarefas de desenvolvimento para implementação no próximo release.
De fato, o conselho técnico responde aos requisitos da indústria e do mercado, considerando as necessidades registradas nas aplicações. Tudo o que tem pouca relevância permanece na lista de pendências e não atinge o desenvolvimento.
Classificação de Solicitações e Finanças de Mudanças
O desenvolvimento é caro. Portanto, informaremos imediatamente quais opções podemos ter se a solicitação de alteração vier de um cliente, não de um funcionário.
Os pedidos de mudança são classificados da seguinte forma: necessidades do setor ou características individuais da empresa; quantidade significativa de novas funcionalidades ou pequenas correções. Pequenas correções e solicitações individuais são processadas sem frescuras. Solicitações individuais são calculadas e implementadas para um cliente em particular como parte do trabalho do projeto com ele.
Se essa não é uma necessidade maciça da indústria e o escopo da funcionalidade é grande, pode ser tomada uma decisão para desenvolver um novo módulo separado, que será vendido além da funcionalidade principal. Se tal solicitação for recebida do cliente, podemos assumir os custos de desenvolvimento do módulo, fornecer ao cliente o módulo gratuitamente ou com pagamento parcial e colocá-lo à venda ao público. O cliente assume parte do ônus metodológico em tal situação e realiza essencialmente a implementação piloto do módulo.
Se essa for uma necessidade maciça da indústria, poderá ser tomada uma decisão para incluir novas funcionalidades no produto base. Os custos, neste caso, recaem sobre nós e a nova funcionalidade aparece na versão atual dos programas.
Os clientes antigos recebem uma atualização.
Também pode ser que vários clientes tenham uma necessidade semelhante, mas isso não atrai um produto em massa. Nesse caso, podemos enviar a especificação para esses clientes e oferecer o compartilhamento dos custos de desenvolvimento entre eles. Como resultado, todos ganham: os clientes recebem a implementação da funcionalidade a um baixo custo, enriquecemos o produto. Depois de um tempo, os demais participantes do mercado também podem receber a funcionalidade para uso.
Devops
O desenvolvimento prepara dois principais lançamentos por ano. Em cada release, o tempo é reservado para a implementação de 5 tarefas recebidas do conselho técnico. Assim, para o fluido, nunca esquecemos o desenvolvimento do produto.
Cada versão passa por um conjunto apropriado de testes e documentação. Além disso, esta versão é instalada no ambiente de teste do cliente relevante, que, por sua vez, verifica meticulosamente tudo e somente depois que a versão é convertida em produção.
Além do sistema de lançamento, existe um formato para correções rápidas de erros, para que os clientes não vivam com erros por seis meses. Esse formato provisório permitirá que você responda rapidamente a incidentes de primeira prioridade e cumpra o SLA declarado.
Tudo acima é verdadeiro principalmente para o setor corporativo e as soluções locais. Para serviços em nuvem focados no segmento SMB, não existem oportunidades tão amplas para os clientes participarem do desenvolvimento do produto. O formato de concessão para SMB nem sugere isso. Em vez de uma solicitação de mudança na forma de requisitos claros da parte corporativa, aqui estão apenas os comentários e desejos usuais para o serviço. Tentamos ouvir, mas o produto é enorme e o desejo de um cliente de trazer algo familiar a seu antigo sistema histórico pode contradizer a estratégia de desenvolvimento do sistema como um todo.