即刻App年轻人的同好社区
下载
【基本无害的产品小札 004】
《不解决问题也是一种解决方案》
————
在 37signals 主页（37signals.com）有这么一句话：“No” is no to one thing. “Yes” is no to a lot of things.
这句话简洁但是十分有力量的打动了我，并且我认为不能简单地用机会成本来理解这句话，下面我从需求、软件工程和产品设计三个角度来试图解答一下这句话。
首先，做需求的本质是投资，如果一个需求既不符合产品原则，也不符合年度规划，在单项目 ROI 上面也没有明显的收益，那么为什么要做这个需求呢？或者说的更直白一点，就算 ROI 再高，如果和自己的 KPI 没有任何关系，那为什么要接呢？当然这里面会涉及到康威定律的问题，以后有机会再探讨吧。
其次每做一个需求，都意味着一次给软件增加债务的风险，软件复杂度的增加是不以人的意志为转移的，无论产品经理多么小心翼翼，工程师多么谨小慎微，这都无法避免，更何况实践的时候大部分人就是糙猛快干就完事了。但是软件产品就是一个互联网公司最重要的资产，如果一个功能会给系统带来复杂度的急剧上升，那么这件事情本身和「破坏固定资产」没有区别。
最后，不是所有问题都是可以被解决的，或者说解决一个问题很有可能引发新的问题。举例说明，很多人总是吐槽微信，想要教张小龙做产品，给一些小天才 idea。比如 PC 端不支持密码登录，真的改了也会有人反对，反过来问 PC 端支持密码登录了安全措施怎么办，微信里面可是有钱包的！又比如喷微信的文件传输大小限制，这条如果真的改进了的话大家又该喷微信占存储了。
况且这个世界上并不是每一个问题都需要解决的。
有一类问题随着时间的推移会收敛，比如一些运算性能的问题，如果问题复杂度不会随着业务规模扩展而上升，那么就可以考虑不解决。因为再过 18 个月，计算机的性能就会翻一倍，只要程序能吃满这些机器的性能那就可以考虑先不优化。
还有一类问题常常发生在运营和产品之间，简单地说就是运营想要一个功能来提效，产品经理不干，最后运营自己用土办法吭哧吭哧解决了，一边解决一边骂产品傻逼，我不知道大家遇到过多少次这种情况，我认为这种情况下产品经理不解决问题就是对的。
虽然我们总说用机器替代人力，但是大部分情况下机器替代不了人力，机器能约束人类的规范质量并且稍微提升一下效率就不错了，如果能够通过系统传递一些最佳实践，那已经是非常了不起了。
除非运营耗费的人力是长期且繁多的，并且能够证明这个业务随着时间的推移规模只会越来越大而不是越来越小，那么机器替代人力这个说法才是成立的，毕竟大部分 C 端产品生命周期是非常短的，效能工具上线的那一天说不定业务都死了。
最后还有一类问题，可能就是不一定只有我才能解决的问题，这种情况下我也不太会倾向于去解决。一个系头系统可能有十几个模块组成一个完整地链路，到底在哪个模块解决才是最优解其实提需的人是不关心的，他们只是找到自己认识的人提需求而已，这种时候拒绝是对全局的负责。
由此可见，大部分需求拿到手之后，其实根本不需要解决，随着时间的推移，问题就会得到解决，或者承载问题的业务本身会得到解决，用《侏罗纪世界》的一句话说：「Life always find way.」
不要觉得这是在摸鱼，拒绝解决一个不值得解决的问题的本质是在维护公司资产。一个问题如果一定需要系统来解决，要么就是量大到人力所不能及，要么就是解决了之后时间复利比较明显的问题，不然用系统来解决，都是性价比很低的。
把系统当成一种固定资产，而不是工作成果，才能真正理解 37signals 的这句话，要知道固定资产是会折旧的。
【基本无害的产品小札】往期历史链接
————
【003】 《什么是产品原则》：
m.okjike.com
【002】《太讲究 ROI 的产品，一定比较难用》：
m.okjike.com
【001】《要爱上这个草台班子支撑的世界》：
m.okjike.com
《不解决问题也是一种解决方案》
————
在 37signals 主页（37signals.com）有这么一句话：“No” is no to one thing. “Yes” is no to a lot of things.
这句话简洁但是十分有力量的打动了我，并且我认为不能简单地用机会成本来理解这句话，下面我从需求、软件工程和产品设计三个角度来试图解答一下这句话。
首先，做需求的本质是投资，如果一个需求既不符合产品原则，也不符合年度规划，在单项目 ROI 上面也没有明显的收益，那么为什么要做这个需求呢？或者说的更直白一点，就算 ROI 再高，如果和自己的 KPI 没有任何关系，那为什么要接呢？当然这里面会涉及到康威定律的问题，以后有机会再探讨吧。
其次每做一个需求，都意味着一次给软件增加债务的风险，软件复杂度的增加是不以人的意志为转移的，无论产品经理多么小心翼翼，工程师多么谨小慎微，这都无法避免，更何况实践的时候大部分人就是糙猛快干就完事了。但是软件产品就是一个互联网公司最重要的资产，如果一个功能会给系统带来复杂度的急剧上升，那么这件事情本身和「破坏固定资产」没有区别。
最后，不是所有问题都是可以被解决的，或者说解决一个问题很有可能引发新的问题。举例说明，很多人总是吐槽微信，想要教张小龙做产品，给一些小天才 idea。比如 PC 端不支持密码登录，真的改了也会有人反对，反过来问 PC 端支持密码登录了安全措施怎么办，微信里面可是有钱包的！又比如喷微信的文件传输大小限制，这条如果真的改进了的话大家又该喷微信占存储了。
况且这个世界上并不是每一个问题都需要解决的。
有一类问题随着时间的推移会收敛，比如一些运算性能的问题，如果问题复杂度不会随着业务规模扩展而上升，那么就可以考虑不解决。因为再过 18 个月，计算机的性能就会翻一倍，只要程序能吃满这些机器的性能那就可以考虑先不优化。
还有一类问题常常发生在运营和产品之间，简单地说就是运营想要一个功能来提效，产品经理不干，最后运营自己用土办法吭哧吭哧解决了，一边解决一边骂产品傻逼，我不知道大家遇到过多少次这种情况，我认为这种情况下产品经理不解决问题就是对的。
虽然我们总说用机器替代人力，但是大部分情况下机器替代不了人力，机器能约束人类的规范质量并且稍微提升一下效率就不错了，如果能够通过系统传递一些最佳实践，那已经是非常了不起了。
除非运营耗费的人力是长期且繁多的，并且能够证明这个业务随着时间的推移规模只会越来越大而不是越来越小，那么机器替代人力这个说法才是成立的，毕竟大部分 C 端产品生命周期是非常短的，效能工具上线的那一天说不定业务都死了。
最后还有一类问题，可能就是不一定只有我才能解决的问题，这种情况下我也不太会倾向于去解决。一个系头系统可能有十几个模块组成一个完整地链路，到底在哪个模块解决才是最优解其实提需的人是不关心的，他们只是找到自己认识的人提需求而已，这种时候拒绝是对全局的负责。
由此可见，大部分需求拿到手之后，其实根本不需要解决，随着时间的推移，问题就会得到解决，或者承载问题的业务本身会得到解决，用《侏罗纪世界》的一句话说：「Life always find way.」
不要觉得这是在摸鱼，拒绝解决一个不值得解决的问题的本质是在维护公司资产。一个问题如果一定需要系统来解决，要么就是量大到人力所不能及，要么就是解决了之后时间复利比较明显的问题，不然用系统来解决，都是性价比很低的。
把系统当成一种固定资产，而不是工作成果，才能真正理解 37signals 的这句话，要知道固定资产是会折旧的。
【基本无害的产品小札】往期历史链接
————
【003】 《什么是产品原则》：
m.okjike.com
【002】《太讲究 ROI 的产品，一定比较难用》：
m.okjike.com
【001】《要爱上这个草台班子支撑的世界》：
m.okjike.com
16 32
来自圈子
产品经理的日常
192792人已经加入