模板|遇到要做但是有“隐患”的需求怎么办？( 二 ) Y700|y700|vc|ota|手机|平板|配置

如果顺利一般操作两次，如果不顺利不好说。现实情况往往就在这个不好说里面。
我过去用过类似的功能，有些城市反复上传都无法成功，问技术也不知道问题在哪里。然后就没有然后了。
一旦反复遇到这种匹配失败的情况，使用的同事的体验就不会很好，然后会继续提要优化的问题。
问题就在这里了，没法优化。产品经理需要解释为什么无法优化了，很可能是解释不好的，最后的结果是虽然使用的同事接受了解释，但仅仅是接受了解释。
要是领导问起来，使用的同事对这个功能的评价就是不高的，那么对于做这个功能的产品来说就是做了一件不讨好的事情，技术觉得不合适、同事用着不好用。
所以我遇到这种需求真是不想做，后续的处理和解释比较麻烦。
遇到这种情况，有一点是可以明确的，那就是做是必须做的，毕竟需求的合理性是存在的。
但是你也必须做一些前期工作，避免后续的麻烦：
首先是必须合理管理使用人员的预期。一定要在前期的时候把可能会遇到的情况和使用的同事讲清楚，管理好预期。
提需求的同事肯定是不知道这里面还有这么多名堂的，这就要靠你科普了。
你需要把这个问题用最简单的语言讲清楚，使用的同事如果比较容易沟通的话就还好，不容易沟通的通常不会在意你说的这些，他们会觉得自己肯定不会犯这些问题。
不管是哪一种你都需要在前期多做一些沟通，这样至少在后面的沟通里面占据主动。
其次，你需要和主管领导也沟通一下这个问题，让他心里有数。
把具体的需求和沟通的情况都说一下，如果后续遇到被其他部门质疑的时候，你的主管领导能在第一时间做出合理的处理，不至于一脸懵。
不要给领导添麻烦，尤其是可以避免的麻烦，领导也是人，不会喜欢麻烦的。
最后你还需要和技术的同事做沟通，讲清楚这个需求的使用场景。
像这个批量上传城市的需求，对于技术的同事来说，如果你不说场景，只说需求，他们肯定会提出来异议，说要按照预设的模板上传，按照code进行匹配，这就和需求不匹配了。
你需要说清楚场景，解释清楚为什么不是按照更精确的思路实现，而是采用这种方式。
讲清楚关键的地方，技术自然也能理解，也就知道不是你这个产品经理坑，而是确实需要这么做。
这三步下去就能把后续的影响降到最低。
产品经理在这里面做的工作并不仅仅是整理需求，还有大量的沟通工作，实际上沟通本身就是产品设计解决方案的一部分。你需要让大家知道你设计方案的思路，确保符合需求同时也保障落地实现。
产品经理还是需要懂得保护自己的合理利益。
因为正好遇到这么个需求，所以分享一下，希望对大家有个启发。
我说的不包含全部，仅仅是一种思考的分享。
本文由 @产品人玄青原创发布于人人都是产品经理。未经许可，禁止转载
【 模板|遇到要做但是有“隐患”的需求怎么办？】题图来自 Unsplash，基于 CC0 协议