1.跟对应开发确认
需求理解确认：确认是否是你对功能的表达有误或者开发自身理解有误，导致信息偏差，从而认为技术难以实现。此时应再次梳理需求，并由开发讲解需求期望的功能是什么样，以此达到理解一致。或者找个市面上有类似功能的产品，当面演示相关功能，让开发自己研究下看是否能依葫芦画瓢；
功能实现难度确认：确认是否是因为功能本身实现不了：1、原系统的底层架构受限：需在需求设计上避开对原系统的干扰或者进行需求重构；2、开发人员自身技术能力有限：可考虑换个简化实现方式或者寻找其他开发外援协助；
主观影响确认：确认是否是因为与功能本身无关的其他原因实现不了：比如因时间来不及、开发自己不想做这个功能等等。项目自己能协调解决的尽快解决，不能解决的可适当求助外援。
2.找开发负责人确认
若跟对应开发确认的几种方式都尝试过且失败了，则选择以下方法：
确认对应开发所说功能本身无法实现是否属实：若属实需追问有没有其他的替代解决办法？本次功能若暂缓开发但在将来实现的可能性有多大？对应的研发成本、资源支持和时间点又是怎样？若不属实则让该负责人与员工沟通具体实现方案。
注意：
切记不要上来就直接找开发负责人确认，一是开发负责人都很忙，你这边的情况他不一定特别清楚，直接找他可能他也会让你直接找下面的员工去对接，关系特别好的可能一次两次人家都会直接帮你解决，但不建议经常这样；二是你越过对接的开发，直接找人家上级，有种不尊重他的意思，更有点像利用他的上级权利强压他一头，这样其实不利于后期和平相处的关系维护，尊重是互相的。
3.权衡做与不做
根据得到的答复结果来做决定：评估实现后的效果与研发成本的ROI，若收益失衡则可考虑放弃此功能并需总结经验让下次需求设计考虑更为周全。且若需求不做的影响有哪些？针对有影响的地方再考虑其他弥补措施。
4.最后
不论这个需求最终做还是不做，都是一次经验的复盘。不仅对于你自身的产品能力，又或者是技术能力，再或者是与人沟通的能力，都是一次很好的磨炼。只有在一次次这样的经验中，你才能逐渐让自己对负责的产品、当前所属团队的实力、团队间的合作习惯更加地熟悉。
标签：需求,功能,或者,实现,确认,拒做,开发 来源： https://blog.51cto.com/u_14540820/2798149
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。