软件是有生命的，最终走向EOL。

那如何定义软件的“衰老”呢？

是功能不够用，满足不了需求？还是功能太多，架构太复杂，无法维护呢？

显然是“后者”，如果一个软件因为功能不够用，满足不了需求，那么它连“成长”的机会都没有。

所以我这里指的软件都是在市场成功后，快速下滑的。

这种经过“年富力强”，最后走向“衰老”，而且几乎是必然的。

软件产品经理的诞生是业界挽救“衰老”的已经验证的成功经验。

并不是产品经理有能耐，不然也不会说“人人都是产品经理”。

产品经理的角色设定，真正改变了软件需求的供需关系。

产品经理折射的玄学

没有产品经理的时候，程序员会根据自己的喜好开发软件系统，产生了大量“假设需求”，“万一需求”和“将来需求“，这些会使软件系统“衰老”加速。

为什么有独立产品经理时不同呢，因为产品经理要间接麻烦程序员开发需求，所以产品经理的大量“假设需求”，“万一需求”，“将来需求“没法都给到软件开发人员，只能低三下四次给几个，就在筛选这几个需求的过程中，“需求控制”的意义达到了。

没有哪个程序员愿意在高强度工作下，还能把产品经理的“假设需求”照单全收，都是推三阻四，提三个留一个，并不会都收下还连夜加班多送两个。

当然要达到这种控制的平衡，产品经理和程序员地位一定是一致的，虽然有“经理”二字，但一定是平级，否则悲剧还是会重演。

如果没有产品就没办法了么，有！

那就是程序员的“克制”，自己克制对技术完美，架构完美的追求，克制对假设需求，万一需求，将来需求的恐惧。敏捷理论的“拥抱变化“并不是鼓励“需求变更”，而是说“将来”真的到来时再考虑这个需求。

程序员的克制

除了产品经理，玄学，还有几个方法：

• 让程序员自己实现自己提出的需求
• 让程序员自己测试自己开发的系统
• 让程序员自己维护自己开发的系统

DevPM，DevOps，DevTest 这不容易实现，其实就是独立开发者。

所以也不难理解独立开发者的软件水平要高与团队系统一个等级，独立开发者的时间开销和收入也必然要求他做最有价值的需求。

比如张小龙当年的Foxmail，最后变成了PM头子还能把微信需求把持得这么好。

现实情况下一个大系统一般不可能一个人开发，除非克服人性，极度“克制”。

当然一个没有产品经理的团队也要学会“克制”，“克制”软件系统在当下的需求。

预言

最后预言一下Hadoop全家桶快走向“死亡”了。

不是因为它不支持什么功能，而是支持的功能太多，引入组件太多，架构复杂，依赖复杂，维护困难，性价比低。

一个刚过“年富力强”的软件系统，过于贪婪，膨胀太快，“死亡”只会来得更快，拭目以待。