Neste artigo compartilharei minha experiência na seleção de ideias para o desenvolvimento da funcionalidade de nossos produtos e contarei como manter os principais vetores de desenvolvimento.
Estamos desenvolvendo um sistema de liquidação automatizado (ACP) - faturamento. Prazo
A vida útil do nosso produto é de 14 anos. Durante este período, o sistema evoluiu das primeiras versões de um sistema tarifário industrial para um complexo modular composto por 18 produtos que se complementam. Um dos aspectos mais importantes da longevidade dos programas é o desenvolvimento constante. E o desenvolvimento requer ideias.
Idéias
fontes
Existem 5 fontes:
- O principal amigo de um desenvolvedor de sistemas de informação corporativos é cliente. E o cliente é uma imagem coletiva de tomadores de decisão, patrocinadores de projetos, proprietários e executores de processos, especialistas internos de TI, usuários comuns e um grande número de indivíduos interessados em diversos graus. É importante para nós que cada um dos representantes do cliente seja potencialmente um fornecedor de ideias. Na pior das hipóteses, só recebemos feedback negativo sobre problemas no sistema. Na melhor das hipóteses, existe uma pessoa do lado do cliente que é uma fonte constante de ideias de melhoria, fornecendo informações estruturadas sobre as necessidades do cliente.
- Наши vendedores e gerentes de contas são a segunda fonte mais importante de ideias para melhoria. Eles se comunicam ativa e extensivamente com representantes do setor e recebem perguntas em primeira mão sobre a funcionalidade de faturamento de clientes em potencial. Os vendedores e as contas devem estar cientes de todas as mudanças significativas em suas funcionalidades e das atualizações mais recentes do software dos concorrentes, e ser capazes de justificar os prós e os contras de diferentes soluções. Estes são os nossos funcionários os primeiros a perceber se algumas capacidades de facturação se tornam um padrão de facto, sem as quais o software não pode ser considerado completo.
- Proprietário do produto — um de nossos principais gerentes ou um gerente de projeto muito experiente. Tem em mente os objetivos estratégicos da empresa e ajusta os planos de desenvolvimento de produtos de acordo com eles.
- Arquiteto, uma pessoa que entende as capacidades e limitações das soluções tecnológicas escolhidas/utilizadas e seu impacto no desenvolvimento do produto.
Equipes de desenvolvimento e testes. Pessoas que estão diretamente envolvidas no desenvolvimento de produtos.
Classificação de solicitações
Recebemos dados brutos de fontes – cartas, ingressos, solicitações verbais. Todos
os recursos são classificados:
- Consultando com o significado “Como fazer?”, “Como funciona?”, “Por que não funciona?”, “Não entendo...”. Solicitações deste tipo vão para a Linha de Apoio Nível 1. É possível retreinar a consulta para outros tipos de solicitações.
- Incidentes com o significado “Não funciona” e “Erro”. Processado por 2 e 3 Linhas de Apoio. Se forem necessárias correções imediatas e lançamento de um patch, eles poderão ser transferidos do suporte diretamente para o desenvolvimento. É possível reclassificá-lo como uma solicitação de mudança e enviá-lo para o backlog.
- Solicitações de mudanças e desenvolvimento. Eles entram no backlog do produto, contornando as linhas de suporte. Mas existe um procedimento de processamento separado para eles.
Existem estatísticas sobre solicitações: imediatamente após o lançamento, o número de solicitações aumenta de 10 a 15% por um curto período. Também há aumentos nas solicitações quando um novo cliente com um grande número de usuários chega aos nossos serviços em nuvem. As pessoas estão aprendendo a usar novos recursos de software e precisam de conselhos. Mesmo um cliente pequeno, ao começar a trabalhar no sistema, queima facilmente mais de 100 horas de consultas por mês. Por isso, ao conectar um novo cliente, sempre reservamos tempo para consultas iniciais. Muitas vezes até selecionamos um especialista específico. O preço do aluguel, é claro, não cobre esses custos trabalhistas, mas com o tempo a situação se estabiliza. O período de adaptação geralmente dura de 1 a 3 meses, após o qual a necessidade de aconselhamento é significativamente reduzida.
Anteriormente, usávamos soluções escritas por nós mesmos para armazenar solicitações. Mas gradualmente mudamos para produtos Atlassian. Primeiro, transferimos o desenvolvimento para facilitar o trabalho de acordo com o Agile, depois o suporte. Agora todos os processos críticos residem no Jira SD, além de serem suportados por vários plug-ins do Jira e do Confluence. As soluções autoescritas permaneceram apenas para processos que não eram críticos para as atividades da empresa. Acontece que as nossas tarefas são agora transversais e podem ser transferidas entre suporte e desenvolvimento sem saltar de um sistema para outro.
A partir deste link podemos obter dados sobre todas as tarefas, custos de mão de obra planejados e reais, utilizar diversas opções de preços para clientes e gerar documentação para necessidades internas e relatórios para clientes.
Processando solicitações de mudança
Normalmente, essas solicitações vêm na forma de requisitos de funcionalidade. Nosso analista estuda a solicitação, cria uma especificação e especificações técnicas de alto nível. Transfere as especificações e especificações técnicas para a pessoa que enviou esta solicitação para aprovação - devemos ter certeza de que falamos a mesma língua com o cliente.
Tendo recebido a confirmação do cliente de que nos entendemos corretamente, o analista insere a solicitação no backlog do produto.
Gerenciamento de funcionalidade do produto
O backlog acumula solicitações recebidas de mudança e desenvolvimento. O conselho técnico, composto pelo diretor, chefes de suporte, desenvolvimento, vendas e arquiteto de sistemas, reúne-se semestralmente. Em formato de discussão, o conselho analisa e prioriza as aplicações do backlog e concorda com 5 tarefas de desenvolvimento para implementação na próxima versão.
Com efeito, o conselho técnico responde às exigências da indústria e do mercado, analisando as necessidades expressas nas aplicações. Tudo o que tem pouca relevância fica no backlog e não chega ao desenvolvimento.
Classificação de Solicitações de Mudança e Finanças
O desenvolvimento é caro. Portanto, informaremos imediatamente quais opções podemos ter caso a solicitação de alteração venha de um cliente e não de um funcionário.
Classificamos as solicitações de mudança da seguinte forma: necessidade do setor ou característica individual do empreendimento; uma quantidade significativa de novas funcionalidades ou uma pequena correção. Pequenas correções e solicitações individuais são processadas sem frescuras. Solicitações individuais são calculadas e implementadas para um cliente específico como parte do trabalho de projeto com ele.
Se esta não for uma grande necessidade da indústria e o volume de funcionalidades for grande, então poderá ser tomada a decisão de desenvolver um novo módulo separado que será vendido além da funcionalidade principal. Se tal solicitação for recebida de um cliente, podemos cobrir os custos de desenvolvimento do módulo, fornecer o módulo ao cliente gratuitamente ou com pagamento parcial e colocar o próprio módulo à venda. Nessa situação, o cliente assume parte da carga metodológica e realiza essencialmente ele mesmo uma implementação piloto do módulo.
Se esta for uma grande necessidade da indústria, então poderá ser tomada a decisão de incluir novas funcionalidades no produto base. Os custos, neste caso, recaem inteiramente sobre nós, e a nova funcionalidade aparece na versão atual dos programas.
Clientes antigos recebem uma atualização.
Também pode acontecer que vários clientes tenham uma necessidade semelhante, mas isso não se qualifica para um produto de massa. Nesse caso, podemos enviar a especificação a esses clientes e oferecer a divisão dos custos de desenvolvimento entre eles. No final, todos ganham: os clientes recebem funcionalidade a baixo custo, enriquecemos o produto e, depois de algum tempo, outros participantes do mercado também podem obter a funcionalidade para seu uso.
DevOps
O empreendimento prepara dois grandes lançamentos por ano. Em cada versão é reservado tempo para a execução de 5 tarefas recebidas do conselho técnico. Assim, em meio à rotina, nunca esquecemos do desenvolvimento de produtos.
Cada versão passa por um conjunto apropriado de testes e documentação. Em seguida, esta versão é instalada no ambiente de teste do cliente correspondente, que, por sua vez, verifica tudo meticulosamente e só depois a versão é transferida para produção.
Além do sistema de liberação, existe um formato para correção rápida de bugs para que os clientes não convivam com erros por seis meses. Este formato intermediário permitirá responder rapidamente a incidentes de primeira prioridade e cumprir os SLAs declarados.
Tudo o que foi dito acima é verdadeiro principalmente para o setor corporativo e soluções locais. Para serviços em nuvem voltados para o segmento de pequenas e médias empresas, não existem oportunidades tão amplas para os clientes participarem do desenvolvimento de produtos. O formato de aluguel SMB nem mesmo pressupõe isso. Em vez de uma solicitação de mudança na forma de requisitos claros da parte corporativa, aqui há apenas comentários e desejos comuns para o serviço. Tentamos ouvir, mas o produto é enorme e o desejo de um cliente de trazer algo familiar do seu antigo sistema histórico pode contradizer a estratégia de desenvolvimento do sistema como um todo.
Fonte: habr.com