Você deve incluir um recurso muito solicitado que esteja fundamentalmente errado? [fechado

Question

Em nosso produto principal, temos uma solicitação de recurso que já existe há alguns anos que foi solicitada algumas vezes. É tecnicamente fácil de implementar, o problema é que ele mudará fundamentalmente o conceito do que a ferramenta faz e provavelmente causará mais relatórios de bugs, à medida que as pessoas usam mal o novo recurso para corresponder ao novo conceito (que não poderemos capaz para contornar). Temos um recurso separado que funciona muito bem no problema, mas ainda temos solicitações para implementar o novo.

Nós deveríamos

• Ouça nossos usuários e implemente o novo recurso, mesmo que mude o conceito do que o produto faz e o que queremos fazer, e aumentará os custos de suporte
• Adicione mais alguns artigos de suporte explicando como usar a solução alternativa
• Torne a solução alternativa mais óbvia na interface do usuário para que os usuários o encontrem com mais frequência
• algo mais

Answer 1

Implemente-o como um plug-in.

• Ele estará disponível para usuários que realmente o desejam, mas não alterarão fundamentalmente seu produto.
• A maioria dos usuários não vai instalá -lo, portanto, sua base de suporte será menor.
• Não atrapalhará os usuários que não o usam.

Answer 2

Se esse recurso for contratado para a filosofia do seu produto, indica que o produto não está em conformidade com o modelo mental de seus usuários. As consequências disso são muito maiores do que apenas um único recurso ausente. Você precisa entrar na cabeça dos seus usuários e descobrir como ajustar seu modelo às expectativas deles ou orientar suas expectativas em relação ao seu modelo.

Pense o suficiente nisso e pode se tornar uma grande oportunidade para você.

Answer 3

Em 'O Mês Mítico do Homem' (que você leu, não é?), Brooks diz palavras no sentido de que "a integridade conceitual da arquitetura é a coisa mais importante". Isso significa que, se o recurso solicitado quebrar a integridade conceitual do design geral do seu produto, você provavelmente deve continuar a evitar implementá -lo, independentemente de quanto ele é solicitado. Ou você precisa remodelar a arquitetura para que o recurso solicitado se encaixe na arquitetura revisada.

Um dos produtos em que trabalho possui um 'recurso muito solicitado' que foi adicionado. Ele se comporta diferente de qualquer outro recurso do produto. É uma verruga horrível. Mas como a competição faz isso, tivemos que fazê -lo. Mas, em vez de permanecer verdadeiro nossa arquitetura (que passa a diferir fundamentalmente da concorrência nessa área), impotemos o recurso da competição, até detalhes tolos.

Eu ainda me ressenti amargamente o fato de que o recurso foi estragado no sistema com semântica quebrada e o restante do produto. Para esfregar sal na ferida, tive que apresentar o novo recurso como a 'melhor coisa desde o pão fatiado' para a nossa base de clientes - isso realmente doeu.

Dito isto, ninguém se queixou (como eu acho que deveria) sobre o recurso. Provavelmente é usado às vezes. É uma diferença a menos que a competição possa usar contra nós.

(E Nota: eu não era contra o recurso implementado em um estilo consistente com a maneira normal de trabalhar do nosso produto; eu só era contra ele sendo implementado no estilo que nossa competição usa - porque os outros recursos relacionados funcionam análoga à implementação quebrada Em seu sistema, enquanto o nosso sistema é mais sã e amigável.)

É duro. Às vezes, o mercado vence.

Answer 4

É quase impossível responder a isso, pois não sabemos exatamente do que você está falando.

Dito isso, alguns pontos:

• O número de usuários que realmente desejam o recurso, provavelmente é muito maior do que você pensa, pois a maioria dos usuários nunca registrará feedback.
• Você descreve uma 'solução alternativa', isso implica que seu produto tem um problema ou a interface do usuário precisa mudar.

Eu estaria inclinado a implementá -lo, pois isso deixará seus clientes felizes.

Uma opção seria dar a eles uma opção de menu, que os direciona para os dois métodos.
Possivelmente um mago de algum tipo, o que os ajuda a decidir qual solução alternativa usar.

Answer 5

Eu tentaria redesenhar a interface do usuário para o seu trabalho para torná-lo mais fácil e óbvio para seus usuários. No final do dia, o cliente paga as contas, por isso temos e obrigação de atender às suas necessidades. Quando o que eles pedem causará mais problemas, ele volta para oferecer uma solução diferente, de modo que não criemos mais bugs futuros e ainda mantemos os clientes felizes.

Answer 6

Embora não seja uma pergunta de programação, vi muitas pessoas ao longo dos anos lutando com esse tipo de problema.

Você precisa se fazer algumas perguntas

1) Você, ou gerenciamento, fez uma análise de custo-benefício? Pergunte a si mesmo "Como vai o recurso .."

• aumentar as vendas? ou seja, mais pessoas comprarão
• diminuir as vendas? ou seja, perdendo clientes que são adiados
• impacto no atendimento ao cliente?

2) Se o produto mudar radicalmente - faria sentido girá -lo para um novo sku inteiro?

3) A gerência conseguirá o que deseja no final. Deseja trabalhar com eles para fornecer aos seus clientes a melhor experiência possível e ser o herói, ou contra eles e procurar outras oportunidades.

Answer 7

Defina "nossos usuários". É 5%da sua base de usuários, 80%, 95%? Você pesquisou o suficiente deles para descobrir se isso é algo que a grande maioria dos usuários deseja ou é apenas um grupo desonesto de usuários (eles podem ser os mais difíceis e difíceis de agradar).

Eu acho que isso precisa ser estabelecido primeiro. Se é a maioria da sua base de usuários e agrega valor aos olhos deles, tentaria alcançar um compromisso onde você se encontra no meio, sem comprometer a integridade do seu produto, mas ainda oferecendo ao cliente uma solução alternativa que ainda atender às suas necessidades.

Answer 8

Anuncie a solução alternativa como a solução para a solicitação para aqueles que a solicitaram. Torne a solução alternativa mais proeminente na interface do usuário / mais fácil de usar.

Answer 9

Eu iria com o que tiver mais ROI em potencial. Você aumentará os lucros implementando esse recurso? Em caso afirmativo, isso excede o custo de apoiar o novo recurso? Se os lucros em potencial forem maiores que o seu custo de suporte, sugiro ir com o recurso.

Se não houver ganho a ser feito finacialmente ou reduzindo os custos de suporte, não faz sentido fazê -lo.

Answer 10

Eu iria com um palpite simples ao custo (em termos de usabilidade) versus o benefício, pelo menos como um fator importante a pesar. Por exemplo, se o recurso provavelmente ajudará 45% dos usuários, mas dificultam o uso do programa para os outros 55%, não o faça.