O que você faz quando um usuário solicita um recurso que você não implementará?

O que você faz quando um usuário solicita um recurso complexo que você pode implementar, mas não o faz porque 1) adiciona complexidade desnecessária a outros usuários 2) você também não o faz como opção porque você não quer que seu painel de configurações seja complicado.

Eu escrevi um aplicativo para iOS e alguns usuários me pediram alguns recursos complexos que não posso fazer por causa dos motivos acima. Na maioria das vezes, eu apenas respondia que "Nós levaremos isso em consideração". Explicar que eles são a minoria que deseja esse recurso também não ajudará. Então, o que você faz nesse caso?

Eu acho que você está fazendo a coisa certa. Você não pode agradar a todos e não deveria! Seja educado e profissional, mas você não precisa fazer tudo o que for solicitado.

Você precisa chegar a um compromisso. Seu usuário (o motivo pelo qual o aplicativo existe) está dizendo que não atende a uma de suas necessidades.

Há uma diferença entre atender às necessidades do usuário e permitir que o usuário final projete seu aplicativo. Faça uma reunião com o usuário e pergunte "Por quê?" perguntas até chegar ao cerne da tarefa que a pessoa está tentando executar e não pode, ou isso é muito complicado de executar na interface do usuário atual. Faça essas anotações e crie algumas abordagens alternativas com as quais você PODE viver e apresentá-las de volta ao usuário.

Acima de tudo: lembre-se de que o aplicativo não existe para facilitar sua vida como programador. O aplicativo está lá para servir o usuário.

Se você ler o blog de Seth Godins ( http://sethgodin.typepad.com/ ), verá a mesma mensagem passando repetidamente:

1. Envie algo (e ouça o feedback)
2. Não tente agradar a todas as pessoas o tempo todo.

Eu tive um problema semelhante a você com um produto que eu vendo. Eu tive todos os tipos de solicitações para todos os tipos de recursos. O aplicativo tornou-se mais complexo do que eu realmente queria. Cada opção adiciona complexidade, algo que eu queria evitar. E agora tenho mais complexidade do que gostaria.

Fazer isso agrada mais usuários. E afasta os usuários que acham muito difícil de configurar.

Ter uma configuração simples / avançada é uma saída. Até certo ponto. No entanto, torna seu desenvolvimento mais complexo.

Em todos os casos em que recebo uma solicitação, sempre respondo educadamente. Às vezes vou recusar completamente, embora isso seja raro. E onde faço isso, explico por que, geralmente, seria em resposta a uma solicitação que exigiria que toda a interface do usuário fosse renovada, uma tarefa tão maciça que simplesmente não irei lá. Nesse caso, explico minhas razões, mas agradeço ao usuário pela solicitação.

Em TODOS os casos, incluindo aqueles que rejeito imediatamente, eu os registro no banco de dados de recursos e defeitos para consideração na próxima versão. Isso permite um pouco mais de tempo para pensar em tudo, e talvez venha mais tarde com uma alternativa que não é exatamente o que foi solicitado, mas pode agregar algum valor.

Se uma solicitação de recurso tiver sido considerada, anotada e uma decisão finalmente (no momento do desenvolvimento) for tomada para matá-la, eu a encerro. Caso contrário, eles ficam abertos para reconsideração mais tarde.

Essa não é uma abordagem perfeita, mas no final, como autor do software, você tem certos princípios de design que você precisa seguir ou abandonar. A escolha de cada abordagem deve ser cuidadosamente considerada.

Eu acho que você deve ser honesto com seus usuários. Não diga a eles: "Nós levaremos isso em consideração", se você já decidiu que não o fará. Isso levará os usuários a acreditar que o recurso chegará algum dia e ficará desapontado porque nunca vem.

A longo prazo, isso irá beneficiar você mais, acredito.

Gostaria apenas de agradecer a sugestão, mas dizer que não está no seu roteiro agora. As pessoas entenderão principalmente que você tem recursos limitados.

Eu costumo fazer três coisas quando estou nessa situação:

1. Penso duas vezes se a ideia do usuário pode ser uma boa ideia, afinal. Eu aprendi a não confiar no meu primeiro instinto. Às vezes, o usuário está certo e eu estou errado.
2. Explique ao usuário por que você não pode incluir esse recurso.
3. Explique ao usuário como ele pode obter o que precisa com o software que possui

Eu acho que o último ponto é mais importante. A maioria dos usuários não quer exatamente sua sugestão implementada. Eles só precisam de uma solução para um problema e sugerem a solução mais simples possível. Talvez você possa encontrar uma solução melhor que possa implementar.

Para cada um de nossos produtos, temos uma "lista de idéias para versões futuras". Então, o que dizemos a nossos usuários é "colocaremos sua sugestão nessa lista" - e isso é honesto, na verdade, fazemos isso.

A lista não tem prioridades, mas escolhemos regularmente as coisas e as usamos para alimentar nosso backlog. Nós não os tomamos "em ordem", em vez disso, tentamos identificar quais idéias dão o melhor retorno possível - o maior benefício para o maior número possível de usuários, por um esforço de desenvolvimento razoável.

As solicitações de recursos em relação à integridade conceitual do produto provavelmente permanecerão lá para sempre. Ocasionalmente, porém, acontece que pelo menos algumas das idéias ocultas nessas solicitações de recursos podem ser realizadas, talvez não exatamente da maneira como a pessoa que sugeriu isso estava pensando, mas de uma maneira que se encaixa melhor na arquitetura do produto.

Portanto, minha sugestão aqui é: não diga apenas "Vamos levar isso em consideração". e esqueça a ideia assim que terminar a ligação. Em vez disso, tenha uma ferramenta onde você armazena idéias e solicitações de recursos, talvez em um rastreador de problemas, talvez em um Wiki, talvez em uma planilha, o que melhor se adapte às suas necessidades.