函数式编程、软件体与产品经理
在软件体产品设计时，一种很常见的做法是枚举功能点：
看似调理清晰，实质上里面隐藏了致命问题：
无法直观地判断这个功能点是否有必要。
有可能这个功能点是个完全没必要的功能点，但是你是无法通过这个表格判断出来的。
所以更合理的做法，实际上是通过工作流来进行软件体产品设计：
功能点，附着在STEP上，为STEP服务，而非像第一张表一样附着在功能模块上。
看似是同一件事情的两种不同表达，实质上存在本质上的区别——
「软件体设计中，究竟什么最重要」？
第一张的表结构中，给出的答案是子系统、功能模块等实体最重要；
第二张图结构中，给出的答案是流（Flow）最重要。
我认为，第二个答案才是 「最佳实践」。
一个有意思的事情是，这里说的虽然是软件体的设计，但是和编程思想也能产生映射关系——
面向对象编程认为什么最重要？
实体对象最重要，所有函数都是依附于实体。
函数式编程认为什么最重要？
函数最重要，所有变量、结构体都是依附于函数。
然后，我们将这个话题转化到商业的角度，同样也会有有意思的发现——
功能点=>更强的功能点是否能创造具有商业价值的产品？
答案是不一定，但是这个思想通常具有迷惑性，很多产品都会有这样迷思，我具备了某个更强的功能点，我便具备了商业竞争力，例如——从「普通聊天」变成「加密聊天」。
实质上，单个功能点的强化（创新）没有意义，只有落实到「流」的强化（创新）上才有意义。
例如，原本的「看电视流」变成「打开抖音看短视频流」，这个是具备商业逻辑的，站得住脚的。
输入「 比特币 」，推送比特币技术入门教程；
输入「 联盟链 」，推送联盟链开发系列教程； 输入「 项目 」，看看大狗最近在玩什么。