日常的需求评审中，产品经理与开发人员往往会陷入业务逻辑与技术细节的纷争，开发人员觉得这是业务逻辑，要产品定；产品觉得这是技术细节，开发说了算。双发各执一词，吵得不可开交。
尽管需求评审的意义就在于聊清楚细节，但也未必所有细节都要等到会上才能聊清楚，这些争吵总会有些规律可循。
其实业务逻辑与技术细节的边界是非常清晰的，只是有时大家本着多为对方着想的态度，操多心而已。那么这个边界在哪里呢？对了，就是“技术”二字。
产品经理可以了解技术细节，甚至精通某项技术都没关系，但是在产品研发的过程中，是不需要“侵入”技术的。或者说，不需要为技术着想。产品经理需要技术给出的是可行性，即能做还是不能做的问题。而能做要怎么做，就不必关心。如果说不能做，要砍我需求，我倒要问问你是要闹哪样了。
技术研发可以了解业务逻辑，但不能替产品定夺产品形态，更不能在许多产品细节上“先斩后奏”。再敏捷的团队，只要有产品经理存在，就一定是产品来定夺。对于设计师也是一样，既然有设计师存在，就要尊重设计师的工作，在下游实现阶段随意修改设计是不合适的。
举几个常见的例子：
- 某个系统错误 PRD 里没写，开发人员自己加上了文案“啊哦~系统开小差了~”；
- 某个设计师没空，开发人员自己根据色系搭配了个按钮颜色；
- 某个产品觉得这个特性可能系统性能不好，决定不做了；
乍一看这些例子对敏捷开发是有利的，一定程度上可以加快系统上线，不必拘泥细节。但细想起来，就会有问题。
比如，例 1 中的系统假如是个正式严谨的系统，这样的文案就很有问题，而开发人员可能更倾向于使用自己喜欢的语气，未必会考虑真实用户的角色和使用场景，这里就可能给用户造成不适；
例 2 中的例子，我们可能是觉得设计师太忙了，不便打扰。但是系统上线之后，设计师看到的第一反应可能是“什么鬼？这谁设计的...”。设计师可能会感到不受尊重，也可能会因为没有把关好设计而受到批评；
例 3 就更典型了，我们好心的产品经理觉得性能不好，就砍掉了的需求，真的性能不好吗？性能问题无法解决吗？即使真的有无法逾越的障碍，也不应该在产品构想的阶段成为阻碍，没有必要在这个阶段考虑技术细节。
好，你说让我只管可行性，那你说到底能不能做吧？！先等等，能做，但是 ... 你要知道，可行性与实现成本的区别也是常见的陷阱。
什么是可行性？你可以理解为就是能做不能做。但能做是有条件的，不能做也要具体场景具体分析。如果一个特性要求必须 3 天上线，但实现成本要 6 天，能做吗？如果说能，程序员加加班就行了。皆大欢喜；如果说不能，凭什么？6 天怎么来的？不能再快点吗？大不了我陪你一起加班？能。
其实，只要双方心平气和加强沟通，没有做不了的事儿~ 你觉得呢？
作者 | 姬小光 来源 | 姬小光 [ ID: hi-laser ]
识别二维码获取更多干货文章 ↓↓↓
