Como lidar com o tipo de solicitações dos clientes "você pode adicionar apenas mais alguns campos"?

Muito comum, temos solicitações de recursos para campos que apenas um cliente deseja. Na melhor das hipóteses, isso desorganiza o código do aplicativo. Frequentemente, quando olhamos no banco de dados alguns meses após adicionar os campos, podemos ver que eles nem sequer estão usando os campos extras. Além disso, é um aplicativo bastante antigo; portanto, a adição de um único campo requer várias alterações de código, alteração de relatórios e verificação de que isso não afeta outros clientes que não precisam ver o campo.

• Como podemos garantir que um cliente realmente precise dessas solicitações de recursos?

• Como dizemos educadamente "você realmente não precisa disso"?

Atualmente, estamos começando a cobrar por determinadas solicitações de recursos. (Anteriormente, as solicitações de recursos eram gratuitas normalmente) Existe mais alguma coisa que podemos fazer?

Eles estão pagando pelos recursos adicionais? Nesse caso, não é da sua conta se eles os estão usando ou não. Dê a eles o que pagam. Se, no entanto, não for esse o caso, cabe a sua liderança decidir se eles desejam continuar adicionando recursos sem receita adicional.

Temos uma situação semelhante. A maneira como lidamos com isso é a construção de um relacionamento baseado em confiança, que nos dá a liberdade de dizer "você não precisa disso". Leva tempo, paciência e você precisa estar preparado para conversar bastante e ter almoços e outras tarefas chatas. Essas reuniões chatas se pagarão a longo prazo, onde você poderá se concentrar na criação de recursos realmente importantes.

Conversar também fará você ver se o que eles estão pedindo é realmente tão importante.

Eu não acho que você pode entrar no "você realmente precisa disso?" discussão com os clientes. Pessoalmente, gostaria de perguntar: "Como isso tornará sua empresa mais dinheiro?" mas o fato é que, algum gerente, por algum motivo, quer acompanhá-lo e está acostumado a conseguir o que quer. Se você não quiser fazer isso, diga não ou cobrar uma quantia tão grande para desencorajar a solicitação.

Comece a considerar maneiras de tornar mais fácil para seu aplicativo lidar com um número maior de campos de clientes.

1. Permita que os rótulos nos relatórios e formulários sejam definidos pelo cliente para utilizar os campos existentes.
2. Adicione campos genéricos (String12) a tabelas de campos personalizados existentes ou adicionais.
3. Tenha um sistema de campo definido pelo usuário em que tudo isso seja tratado pela entrada de dados e sem a necessidade de criar novas colunas nas tabelas (não me lembro como isso é chamado de ajuda).

Você pode achar que os clientes existentes estão superando seu sistema. O setor pode estar mudando para que novos requisitos estejam surgindo.

Desculpe, mas se você não pode oferecer a seus clientes o que eles desejam apenas por razões técnicas e sem lucro, é necessário acelerar o ritmo. Não seria difícil para um novato entrar no seu mercado com mais campos, por isso não deixe que isso aconteça.

Olhando do outro lado da janela por um momento, no meu último trabalho, fui exposto a um sistema ERP que permitia que colunas "personalizadas" fossem adicionadas pelo usuário final a qualquer entidade / tabela. De minhas breves interações com ele, parecia que eles estavam adicionando dinamicamente as colunas a uma segunda tabela com um mapeamento individual. Por exemplo:

Tabela WIDGET com colunas estáticas:

• WIDGET_ID
• NOME DO WIDGET
• WIDGET_COST
• etc.

Tabela WIDGETCUSTOM com colunas definidas pelo usuário:

• WIDGET_ID
• WIDGET_WEIGHT
• DID_BOB_WORK_ON_WIDGET
• etc.

A coluna WIDGET_ID pode uni-los. Ele mostrava automaticamente seus campos extras quando você estava editando um widget e podia incluí-los em relatórios dinâmicos ou até pesquisar por eles. Foi bastante eficiente, porque o banco de dados ainda pode acompanhá-los e indexar essas colunas, se necessário, etc.

Do ponto de vista da programação, vejo como isso o manteria saudável. Cada cliente pode ter suas próprias colunas personalizadas, mas essas colunas personalizadas não interferem com sua lógica principal.

Recurso "pedidos" são apenas isso, pedidos. Se eles estão exigindo, você precisa decidir quanto vale a empresa "bagunçar" a base de código com isso. Se isso se tornar um problema endêmico, você poderá reprimi-lo, mas se eles estiverem dispostos a pagar o que você está pedindo ou algo parecido, e são apenas alguns recursos aqui e ali, eu digo: vá com o dinheiro.

Para ir ainda mais longe, se esse é um problema constante com seu produto e vários clientes procuram esse tipo de personalização, talvez seja hora de repensar essas partes do aplicativo e flexibilizá-las de uma maneira que os clientes possam fazer isso sejam relatórios ad-hoc, coleta flexível de dados, etc. Tente transformar esses aborrecimentos em um ponto de venda. "Nosso modelo de dados de ações não é bom o suficiente para você? Confira nossas opções de personalização! Você pode fazer isso sozinho!"

Você deve especificar exatamente o que fará no referido recurso e aplicar um tempo estimado para construí-lo. Se o cliente desejar campos adicionais adequados, fature-os por isso. Eu digo aos meus clientes que, se você quiser adicionar recursos depois de criar o recurso, tudo bem, mas, em alguns casos, custará um pouco mais para trabalhar com eles.

Estou tendo dificuldade para entender por que você se importa se eles usam ou não. É simples, você constrói o que eles querem e é pago por isso.

Desordem de base de código? Se você precisar refatorar seu código ao trabalhar no novo recurso, cobrar por ele.

Crie uma lista de vários recursos que você deseja adicionar, incluindo a adição de "apenas alguns campos extras". Mostre a lista aos seus clientes e peça feedback sobre quais eles gostariam primeiro. Explique que seus recursos são limitados e que você não pode fazer tudo de uma vez. Use o feedback para decidir qual direção você deseja seguir com seu aplicativo.

Se um cliente insiste que os poucos campos extras são realmente que importante e você ainda decidir não adicioná-los, espero que o cliente ainda pode ver o benefício dos recursos que você está execução em seu lugar.

Parece que você pode se beneficiar de algum tipo de sistema pull. Deixe o usuário escolher qual recurso será implementado a seguir, mas limite o número que pode estar em desenvolvimento a qualquer momento. Um quadro Kanban é ótimo para isso. Pode dar ao usuário a propriedade do processo de pré -ortização (também conhecido como menos responsabilidade e estresse para você). Confie em mim, se o usuário for forçado a decidir qual recurso será colocado em desenvolvimento a seguir, sabendo que os outros pedidos serão deixados de lado, eles investirão muito mais em decidir realmente o que precisam ter.

Eu acho que você deve pedir ao seu cliente para colocar um ou mais de vocês em um "dia no escritório" para ver como eles realmente usam o software ... Espere ... Contrate-me por US $ 250 / hora e eu irei descobrir. Além disso, por favor, não faça uma placa de ouro. Faça funcionar. A maioria das empresas não se importa que pareça feia quando funciona bem.

Acompanhe os pedidos. Ao planejar / desenvolver os grandes recursos, escolha algumas solicitações priorizadas para incluir nessa versão.

Crie um sistema de negociação padrão para solicitações. Talvez algo baseado em um sistema de relatório de erros ou solicitação de recursos, como fogbugz. Permita que seus clientes façam uma solicitação e priorizem-na com base em:

• a viabilidade / custo técnico do recurso
• o pedido de recurso é "pago"? Se estiver em um contrato e / ou eles pagaram, coloque-o em
• o recurso "faz sentido"? Isso é um pouco de arte, mas, geralmente, se um número suficiente de clientes solicitar um recurso, implemente-o gratuitamente. É uma oportunidade para melhorar seu produto e facilitar a venda para o próximo cliente
• você tem ciclos pagos não utilizados disponíveis? Se você incluir um conjunto de horas mensais para manutenção / suporte como parte de seus contratos (eu recomendo, mesmo que o número seja muito baixo) e eles não estejam se acostumando, comece a usá-los para fazer esses tipos de alterações

Se o cliente possuir a propriedade total do aplicativo, faça o que solicitar. Deixe-os gastar seu dinheiro; é deles.

No entanto, se não o fizer, você deseja ir para uma solução para esses campos auxiliares que envolve armazená-los fora do modelo de dados principal. Você pode usar algo como uma exibição de banco de dados para mesclar os campos extras novamente para esse cliente específico. (Existem algumas maneiras de fazer o armazenamento auxiliar, dependendo da natureza dos dados que estão sendo armazenados; o mais simples é apenas uma tabela que possui a mesma chave primária que um PK na tabela principal, mas isso é ineficiente quando o uso do campo é muito escasso. Somente é realmente um problema quando eles querem recursos do campo que exigem coisas como indexação.)

Você também pode adiar as solicitações dos clientes dizendo que não possui recursos suficientes para implementá-las nesta fase. Realmente ajuda se, nesse ponto, você apontar para o seu roteiro que diz (a sua melhor estimativa em) quando será possível implementar o que eles querem mais barato. E você deve priorizar colocar o aplicativo em um estado em que seja possível oferecer suporte aos recursos de maneira barata, pois esse meta-recurso se torna um recurso de venda principal do seu aplicativo principal.