遇到要做但是有“隐患”的需求怎么办？
我是一个产品经理，做需求是我的本职，但有一类功能我真的是不想做但又不能不做——技术实现不复杂，用起来容易有很多小问题，存在“隐患”。这种功能做了就很麻烦，弄不好就未必能够有正面评价。
今天之所以谈这个，自然是因为最近又遇到了这类功能。
最近，我收到一个需求：后台的某个城市选择功能，除了单独勾选外，需要新增批量上传的功能，允许直接导入excel表格，批量勾选城市。
经过进一步了解后这个需求可以翻译为：新增批量上传的功能，操作的时候使用的同事直接上传excel表格，上传后通过技术手段从表格中读取出城市，将这些城市和数据库中的城市自动匹配，然后自动勾选匹配上的城市，由于上传的时候表格里面的城市是中文名称，所以需要使用中文进行匹配，不预设上传模板。
如果是技术的同事看到应该就知道这个功能其实不好处理，不是指技术不好实现，而是说实际用起来会有很多问题。
我们展开聊一下这个功能。
需求的起源是什么呢？是因为在实际操作的过程中，一个个勾选城市很麻烦。
大家可以想象一下，类似在app上的城市选择组件，如果要多选，就需要先选择省份再选择市一级单位。如果是整个省都选就还行，如果是这个省里面只有部分城市，那就必须先进入这个省，然后再选择对应的城市，确实麻烦。
尤其是如果参照的城市列表城市不是按照省份来列的，那就更麻烦，每次都得看这个城市是哪个省份的，然后进去勾选，然后到下一个省份勾选，如果这个省份有十个城市，搞不好就得进十次，非常麻烦。
这还是你知道所有的城市归属到哪个省份，如果不知道你还需要百度，然后再勾选。
活虽然不复杂，但是操作起来是很麻烦的，如果还需要多次重复操作的话简直可以说是噩梦般的体验，分分钟眼睛就花了。
所以才有了批量上传匹配这种需求，需求是十分合理的。
虽然合理但是不意味着这个需求不麻烦，问题就出在这个【按照中文名匹配，不预设模板】上面。
我们先说说如果是技术来处理一般是怎么处理的：
在技术实现层面，一般来说数据库里面预存的城市是同时包含了城市名和code的，code可以理解为城市的唯一编码，是一串数字，技术部门在内部使用这些城市数据的时候实际上是以code为准的，因为精准不会出错。
所以如果是技术做处理的话一般是让使用的同事导入城市名+code两列，技术根据code进行匹配，城市名是给使用的同事识别用的。
而且这些城市名和code是技术会预先给模板数据的，需要在模板数据里面选取对应的城市然后导入。
操作上就是使用的同事拿着要勾选的城市名单，然后从模板数据里面选出这些城市，最后导入数据库。
操作起来的确是不那么方便的，如果说多次重复操作的话也能节省时间。
但是在使用的同事的层面来说，使用code显然是不合适的，最便捷肯定是有名单就可以直接导入。
使用的同事的城市名单来源可能是多样的，可能是第三方给的，或者自己从某个地方导出的，或者从页面上复制的，无法预判，换句话说很可能是不符合规范的。
注意我说的这句话——很可能是不符合规范的，虽然使用的同事使用的表格在人工使用上没有问题，但是技术层面要识别的话必须符合特定的技术规范，而使用中文名进行匹配就很容易识别失败。
譬如表格里面的内容有空格/符号，内容里面还有隐藏字符，数据库预存的城市带有市/州但是上传的时候没有，上传的表格有其他格式设置等等，虽然人工使用没有问题，但是技术层面就会匹配失败。
所以这个功能技术实现不复杂，读取表格的城市名匹配一遍，匹配成功的勾选，匹配失败的不勾选。
对于匹配失败的提示，最基本的就是提示一下上传了多少条，成功了多少条，如果两个不相等就肯定有失败的，进阶一点的就追加一个需求点，把匹配失败的展示在弹窗上，这样就能更直观的知道有哪些城市需要再次处理。
使用的同事在看到提示以后去修改相关的城市数据，然后再次上传。
如果顺利一般操作两次，如果不顺利不好说。现实情况往往就在这个不好说里面。
我过去用过类似的功能，有些城市反复上传都无法成功，问技术也不知道问题在哪里。然后就没有然后了。
一旦反复遇到这种匹配失败的情况，使用的同事的体验就不会很好，然后会继续提要优化的问题。
问题就在这里了，没法优化。产品经理需要解释为什么无法优化了，很可能是解释不好的，最后的结果是虽然使用的同事接受了解释，但仅仅是接受了解释。
要是领导问起来，使用的同事对这个功能的评价就是不高的，那么对于做这个功能的产品来说就是做了一件不讨好的事情，技术觉得不合适、同事用着不好用。
所以我遇到这种需求真是不想做，后续的处理和解释比较麻烦。
遇到这种情况，有一点是可以明确的，那就是做是必须做的，毕竟需求的合理性是存在的。
但是你也必须做一些前期工作，避免后续的麻烦：
首先是必须合理管理使用人员的预期。一定要在前期的时候把可能会遇到的情况和使用的同事讲清楚，管理好预期。
提需求的同事肯定是不知道这里面还有这么多名堂的，这就要靠你科普了。
你需要把这个问题用最简单的语言讲清楚，使用的同事如果比较容易沟通的话就还好，不容易沟通的通常不会在意你说的这些，他们会觉得自己肯定不会犯这些问题。
不管是哪一种你都需要在前期多做一些沟通，这样至少在后面的沟通里面占据主动。
其次，你需要和主管领导也沟通一下这个问题，让他心里有数。
把具体的需求和沟通的情况都说一下，如果后续遇到被其他部门质疑的时候，你的主管领导能在第一时间做出合理的处理，不至于一脸懵。
不要给领导添麻烦，尤其是可以避免的麻烦，领导也是人，不会喜欢麻烦的。
最后你还需要和技术的同事做沟通，讲清楚这个需求的使用场景。
像这个批量上传城市的需求，对于技术的同事来说，如果你不说场景，只说需求，他们肯定会提出来异议，说要按照预设的模板上传，按照code进行匹配，这就和需求不匹配了。
你需要说清楚场景，解释清楚为什么不是按照更精确的思路实现，而是采用这种方式。
讲清楚关键的地方，技术自然也能理解，也就知道不是你这个产品经理坑，而是确实需要这么做。
这三步下去就能把后续的影响降到最低。
产品经理在这里面做的工作并不仅仅是整理需求，还有大量的沟通工作，实际上沟通本身就是产品设计解决方案的一部分。你需要让大家知道你设计方案的思路，确保符合需求同时也保障落地实现。
产品经理还是需要懂得保护自己的合理利益。
因为正好遇到这么个需求，所以分享一下，希望对大家有个启发。
我说的不包含全部，仅仅是一种思考的分享。
本文作者 @产品人玄青
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
