사용자가 구현하지 않을 기능을 요청하면 어떻게합니까?

사용자가 구현할 수있는 복잡한 기능을 요구할 때 무엇을합니까? 그러나 1) 다른 사용자에게 불필요한 복잡성을 가중시키기 때문에 수행하지 않을 것입니다. 2) 옵션으로하지 않을 것입니다. 설정 패널이 복잡 해지는 것을 원하지 않습니다.

iOS 앱을 작성했으며 위의 이유로 인해 할 수없는 몇 가지 복잡한 기능을 요구 한 몇 명의 사용자가 있습니다. 대부분의 경우, 나는 그들에게 "우리는 그것을 고려할 것"이라고 대답했습니다. 그들이이 기능을 원하는 소수에 있다고 설명하는 것도 도움이되지 않습니다. 이런 경우에 당신은 무엇을합니까?

당신이 옳은 일을하고 있다고 생각합니다. 당신은 모든 사람을 기쁘게 할 수 없으며 그렇게해서는 안됩니다! 정중하고 전문적인 태도를 취해야하지만 요청한 모든 것을 다 할 필요는 없습니다.

타협해야합니다. 사용자 (앱이 존재하는 이유)가 자신의 요구 중 하나를 충족하지 못한다고 말합니다.

사용자의 요구를 해결하는 것과 최종 사용자가 응용 프로그램을 설계 할 수있게하는 것에는 차이가 있습니다. 사용자와 회의를 갖고 많은 이유를 물어보십시오. 사용자가 수행하려고하고 수행 할 수없는 작업의 핵심에 도달 할 때까지 또는 현재 UI에서 수행하기에는 너무 번거 롭습니다. 이 메모를 작성하고 함께 사용할 수있는 대체 방법을 모아서 사용자에게 다시 제시하십시오.

무엇보다도 : 프로그래머로서의 삶을 더 쉽게하기 위해 앱이 존재하지 않는다는 것을 기억하십시오. 응용 프로그램은 사용자를 제공하기 위해 있습니다.

Seth Godins 블로그 ( http://sethgodin.typepad.com/ )를 읽으면 동일한 메시지가 계속해서 나타납니다.

1. 무언가를 배송하고 피드백을 들으십시오.
2. 모든 사람들을 항상 시도하고 기쁘게하지 마십시오.

내가 판매하는 제품과 비슷한 문제가 있습니다. 모든 종류의 기능에 대한 모든 종류의 요청이있었습니다. 응용 프로그램이 내가 원했던 것보다 더 복잡해졌습니다. 모든 옵션은 내가 피하고 싶었던 복잡성을 추가합니다. 이제는 원하는 것보다 더 복잡합니다.

이렇게하면 더 많은 사용자를 만족시킬 수 있습니다. 그리고 설정하기가 너무 어려운 사용자를 몰아냅니다.

단순 / 고급 설정은 바인드에서 벗어날 수있는 방법입니다. 포인트까지. 그래도 개발이 더 복잡해집니다.

요청을받는 모든 경우에 나는 항상 정중하게 답변합니다. 가끔 드물지만 거부합니다. 그리고 내가 이것을하는 곳에서 나는 왜 전체 UI를 개정 해야하는 요청에 대한 응답인지, 왜 그렇게 큰 사업은 거기에 가지 않을지를 설명합니다. 이 경우 이유를 설명하지만 요청 해 주셔서 감사합니다.

즉시 거부하는 것을 포함하여 모든 경우에, 나는 다음 릴리스를 고려하기 위해 기능 및 결함 데이터베이스에 기록합니다. 이를 통해 조금 더 많은 시간을 생각할 수 있으며 나중에 요청한 내용이 아니라 가치를 더할 수있는 대안을 제시 할 수 있습니다.

기능 요청이 고려되고 주석이 달린 후 최종적으로 (개발시) 종료 결정이 내려지면 종료합니다. 그렇지 않으면 나중에 재검토를 위해 열려 있습니다.

이것은 완벽한 접근 방법은 아니지만 결국 소프트웨어 작성자로서 특정 설계 원칙을 고수하거나 버려야합니다. 각 접근법의 선택은 신중하게 고려해야합니다.

사용자에게 정직해야한다고 생각합니다. 당신이하지 않기로 이미 결정했다면 "우리는 그것을 고려할 것"이라고 말하지 마십시오. 이를 통해 사용자는이 기능이 언젠가 올 것이라고 믿게되며 결코 오지 않아 실망하게됩니다.

장기적으로는 그것이 가장 큰 도움이 될 것입니다.

제안에 대해 감사의 말을하지만 지금은 로드맵에 표시되지 않습니다. 사람들은 대부분 당신이 제한된 자원을 가지고 있다는 것을 이해합니다.

나는 그런 상황에 처할 때 보통 세 가지 일을합니다.

1. 결국 사용자의 아이디어가 좋은 아이디어라면 두 번 생각합니다. 나는 나의 본능을 믿지 않는 법을 배웠다. 때로는 사용자가 옳고 틀 렸습니다.
2. 해당 기능을 포함 할 수없는 이유를 사용자에게 설명하십시오.
3. 보유하고있는 소프트웨어로 필요한 것을 달성 할 수있는 방법을 사용자에게 설명

마지막 요점이 가장 중요하다고 생각합니다. 대부분의 사용자는 자신의 제안 이 정확하게 구현 되기를 원하지 않습니다 . 문제에 대한 해결책이 필요하고 생각할 수있는 가장 간단한 해결책을 제안합니다. 구현할 수있는 더 나은 솔루션을 찾을 수 있습니다.

각 제품마다 "향후 버전에 대한 아이디어 목록"이 있습니다. 우리가 사용자에게 말하는 것은 "우리는 당신의 제안을 그 목록에 넣을 것"입니다.

이 목록에는 우선 순위가 없지만 정기적으로 목록에서 물건을 골라 백 로그에 공급합니다. 우리는 그것들을 "순서대로"취하지 않고, 대신 어떤 아이디어가 "가장 많은 돈을 벌 수 있는가"-합리적인 개발 노력을 위해 가능한 한 많은 사용자에게 가장 큰 이익을 주는지를 식별하려고 노력합니다.

제품의 개념적 무결성에 대한 기능 요청은 계속 유지 될 수 있습니다. 그러나 때로는 이러한 기능 요청에 묻힌 아이디어 중 일부가 실현 될 수 있습니다. 어쩌면 제안한 사람이 생각한 방식이 아니라 제품 아키텍처에 더 잘 맞는 방식 일 수도 있습니다.

여기에 제 제안은 "우리는 그 점을 고려할 것"이라고 말하지 않는 것입니다. 전화를 끊 자마자 아이디어를 잊어 버리십시오. 대신 아이디어와 기능 요청을 이슈 트래커, 위키, 스프레드 시트 등 원하는 곳에 가장 적합한 도구로 저장하십시오.