相信大家在做产品需求时，会出现需求和自己预想不一样的情况。为什么会出现这种情况呢？又该如何处理？本篇文章将从前端和后端两个层面，提出对应的解决措施，希望能对你有所帮助。
在工作过程中，我们常常会遇到一种情况：当开发完成开发任务，将功能交付测试时，总会发现有些功能与我们所预想的不一样。
这种主要有两种原因：
一是开发理解的需求与我们所提的需求不一样。
或者说提需求的人描述需求的方式与开发理解需求的方式不一样，导致需求最终出现偏差。这种情况主要还是由于缺少沟通，对需求评审也不到位。
第二个原因则是需求存在隐藏需求。需求设计者默认很多功能就应该存在，所以就没有在需求文档上进行说明。
如果是有经验的开发者或者是合作很长时间有默契的开发者会将你以为的、该有的功能主动加上或者开发到相关功能会与产品进行确认，但是很多开发者是完全按照需求文档进行开发。
默认是不额外开发其他功能，到了交付测试的时候才发现很多你以为该有的功能都没有。这个责任肯定在于产品经理，但是最大的损失还是在于会打破原有的项目计划，严重者导致项目交付延期。
本文针对上述第二种，结合实际工作将常见遗漏的功能点进行列举说明，整篇文章主要从两个方面进行说明，前端、后端。
1）界面风格统一
当项目达到一定的范围时，产品人员与开发人员相应就会配备很多，人多时很容易造成风格不统一的情况。
产品画原型时在没有约定的情况下就会完全自己的想法和习惯进行绘制，需求评审时大家又主要关心功能逻辑，而没有太在意界面呈现形式。
结果交付测试时，发现很多界面风格不统一，按钮放置位置不统一，界面字体与每行字段数量不一样等，单个界面看没有什么问题，但是当全局使用整个产品时，会因为这些细节导致用户体验感非常不好。
所以在我们做产品设计时：
2）查询
① 界面的默认查询
当界面为非看板界面，或者是数据量很大需要分页的界面，又或者是需要要做各种处理事项的界面。进入界面时默认不执行查询，而且由用户设置查询条件进行查询。
针对存在大批量数据且需要用户做各种处理事项的界面，如果打开界面就执行查询，就会让用户被迫等待几秒钟，而这个时间完全是没有必要的。
所以针对有多个功能的处理界面，在不明确用户需要做什么操作时，一定不要做默认查询，而是由用户设置条件查询，减少用户的等待时间，从而提高用户的办公效率。
② 查询条件的说明
关于查询条件一定要说清楚是不是需要模糊查询和批量查询，这个看似一个不起眼的功能，其实很多产品和开发者都会忽略，大多数时间画原型写需求不写清楚的情况下，都是在测试的界面提出来进行优化。
所以最好是在绘制原型时就标注清楚哪些条件需要模糊，哪些条件需要批量。减少后期的修改成本。
③ 优化需求时增加字段
界面增加显示字段，看似一个简单的需求，其实也包含了其他隐藏需求，很多时候增加显示字段是和增加查询条件、导出字段是绑定到一起的。
业务提出的增加显示字段，你在接收这个需求时，就需要确认清楚是否需要增加对应字段的查询条件，以及导出时是否需要增加该字段，大多数时候增加显示字段与查询、导出是一起的，接收需求时就需要确认清楚，避免后期多次进行修改与系统更新。
1）业务场景是否涉及到一定量级的数据操作
设计某个功能点的时候，一定要综合考虑业务场景，评估对应的业务量是否到达一定的量级，是否存在需要系统处理大批量数据的情况，如果有则需要考虑系统的处理效率，就需要给开发提相关的需求，是否需要使用多线程的方式进行处理从而达到业务要求。
千万不要等到开发完成后再提此类需求，这种多线程的处理方式不同的开发模式后续改造的代价各不相同，在开始开发时提出，开发在做整个结构设计时就会考虑。这样从头开始就考虑此种业务场景一是比后期在原来的基础上进行修改要更可靠一些，评估开发时间时也会更准确。
导入/导出同样也需要考虑一定量级的操作，如果有，则需要考虑用异步的方式进行处理，实时导入/导出会存在前端超时用户侧无法知晓导入导出的执行情况，采用异步的方式进行处理；然后提供相应的界面进行结果的查询，异步导入需要查看导入数据的校验结果，同时也能对数据进行修改进行重新校验导入；异步导出需要提供一个界面对导出的结果进行下载。
2）核心功能的日志记录
全局考虑哪些功能是核实功能或者说哪些功能后续可能会引起争议，梳理出来。然后在开发时，同步开发相关的操作日志，且日志一定要详细。
避免后续功能投入使用后，产生一些非必要的争议。特别是涉及到金额方面的尤其重要，切记切记。
3）不同功能对相同同一单据进行更新
当存在不同的业务场景需要对同一单据进行更新时，产品设计时一定要提出来。
特别是大的项目，不同的模块由不同的开发负责，对单据进行更新时由于对全局业务不了解，就不会对订单进行加锁。当各模块业务同时发生时，都对其修改，最后修改提交有先后，就会导致数据被覆盖的问题。
例如线程1、2、3同时修改单据A，同时修改，修改提交有差异，但修改获取时间为同一时间，就可能会存在线程2的最后提交，将线程1修改的数据进行还原。
所以当业务存在同一单据会存在不同业务同时修改时，需要向开发提出，然后开发在开发时无论是加锁还是将各自的业务分开处理，不管哪个方式都需要避免数据被修改后覆盖的情况。以免后续生产环境出现问题。
1）发现问题，认为问题出现概率较小，后续处理
发现问题就一定要及时处理，开发的【后续处理】一般就是后续遇到了之后再处理，但是后续遇到了的情况，就是生产上已经有了脏数据。
极端情况下，会产生一大批的脏数据且如果有后续流程时，会严重影响后续流程。
所以发现问题就一定要及时处理，千万不能随便忽略，否则就像一颗定时炸弹一下，不知道哪天会爆炸，得不偿失。
2）因为工期原因，某些功能就不写前端界面，只做后台功能，数据由数据库直接导入
这种情况除非工期非常紧张，否则一般情况千万不能答应，本身开发前端界面，然后前后端联调如果不是太复杂的界面是不会花费太多时间的。如果答应了，则很大程度上，后续上线后很长一段时间该功能都排不上队。
因为上线后会优先处理线上已产生的的问题，以及用户提出的重要需求，这种有后端功能无前端的小需求就会无限期的往后延，需要使用时每次都需要找开发人员后台导入数据，非常麻烦。
所以非紧急压缩项目时间，此种情况不能同意。
3）某些功能因为实现层面的复杂性，或者和开发沟通上比较费劲就选择妥协
原则性的功能千万不能因为开发层面说实现复杂，或者说和开发沟通比较困难而妥协，如果妥协，你就只是解放一时，反而给自己后面留了一个隐患。
除非找到可替代的方案，否则必须要坚持自己的原则，该要的需求一个都不能落。如果相关的开发沟通执意不做，沟通层面太难交流，那就找相关的领导协调沟通，切勿妥协。
以上就是工作中的一些小总结，希望对大家有帮助。
本文由 @默忧 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。