产品需求的做与不做

聪明的产品设计师往往学会做减法，但很可惜具有抽象和全局观的产品设计师不多。很多时候，他们随口说给某某对象加一个状态，就以为是界面上多一个状态的显示而已，他们不会深究加这个状态是否合理，加这个状态可能会导致所有的流程都要重新判断。结果可能得不偿失，甚至是画蛇添足。

有的人说，开发完不就完事了吗？错也。后面还有测试、维护等各个环节，无疑都增加了工作量。特别是将来某一天要排除问题时，大家各有各的观点，甲说我记得是这样的，乙说应该是这样的。最后还是开发看半天代码说逻辑是这样的，这块可能是忘判断了，导致出问题了。

又有的人说，就添加一个状态而已，我觉得很简单啊，就是1+2的基础上再加个3变成1+2+3而已，一眼就能看出答案。说简单的是以一概全，不理解其中的复杂性可能是几何递增的。人脑对于顺藤摸瓜地推理比较容易，但对于分类分析或者多路径分析就需要有较多的思考时间，甚至会出错。

如普通的推理题：小猫和小兔比赛玩游戏，赢的那个人可以吃一整个西瓜，至少有一个人说的是假话，那到底是谁吃了西瓜？

小猫：我没吃。

小兔：我吃了西瓜

解析（假设法）：

根据题目信息，我们知道只有一个人吃了西瓜，而且必须有人说假话。问题问的谁吃的西瓜？因此，我们可以从问题假设:

①假设是小兔吃的西瓜。那小猫说我没吃就是真话；小兔说我吃了也是真话。不符合“有人说谎”。

②假设是小猫吃了西瓜，那小猫说没吃就是假话；小兔说我吃了也是假话。符合题目，因此是小猫吃的。

这种题目，只有两个角色，一般人都需要考虑一段时间才能得到答案，对于更多角色的题目，可能就需要更多时间来思考了。以此类推到产品需求中的加一个状态，可能就涉及各种正向、反向的判断或过滤，并不是一个一眼就能看出结果的东西。

所以，对于产品设计或者开发，可以扁平的扁平，可以简化的简化，不要过度分支、嵌套、增加影响全局的功能，这样反而把自己都套进去了。

我觉得一个需求做不做可以基于如下的考虑：

1、不是用户强制需要做的，可以不做。

2、做与不做（或者简单做和复杂做），两边都有道理， 哪一边都没有压倒性的优势，那就不要做了，做了往往是画蛇添足。有时认为过多的束缚反而导致开发维护工作量大，耦合性太强容易出问题，用户体验也不好。

产品说：这个已读状态给我加上。

开发说：加这个功能会导致10个模块都要修改，还包括一下统计分析模块和历史数据订正，可能还有遗漏的地方。

产品说：加上后可以很好地了解到对方是否看了消息。

开发说：可我们开发的是微信，不是钉钉啊。