有位同学提到自己在从0到1负责一款内容类产品，需要设计一套信息流排序机制，不知道如何提需求。她给出了第一稿自己做的方案，我一看，立马头就大了，仅几行的规则描述里，存在着很多如“匹配、随机、实时、优先、相似”这样的模糊词汇，尤其对一些关键策略的说明，只是一笔带过，完全没考虑过这背后大量的逻辑细节，我截取了其中两行给大家看下：
这2个需求的背后，基本上就等同于实现一套个性化推荐算法了，作为一个从0到1的产品，真的有必要做成这样么？可以想象如果开发人员看到这样的需求会是这样的表情：
当然，我提出这个，并无冒犯的意思，其实这是很多产品经理的常见问题，包括36氪的产品团队，在我的严防死守下仍旧会出现这样的情况，就是
倾向于用描述性语言说明业务逻辑，这会直接导致开发无法着手进行实现。为什么会这么说？就拿上面的例子，我详细说下。比如这句：“按照用户的搜索关键词和资讯文章标签关键词进行匹配，优先推送搜索关键词和资讯标签相匹配的文章列表，符合关键词匹配的随机推送。”站在开发的角度，就会冒出下面一大堆疑问：
1、搜索词是取用户最近一次的？还是全天所有的？还是过去一段时间的？
2、文章标签从哪儿来？是自动生成还是人工打的？可能有几个标签？取几个？标签有变化是否要重新计算？
3、怎么才算匹配上？如果用户搜索过三个关键词，文章标签也有三个，是只要有一组相等就算匹配上？还是需要全部都相等？还是部分相等？如果有的文章三个都相等，有的文章只有一个相等，那是否要优先推那个三个都相等的？每次匹配的数量是否有上限？匹配不上怎么处理？
4、随机推的范围有多大？100篇随机和10篇随机的计算因子是不一样的。
5、站在用户角度，如果是随机排序，很可能出现某篇文章刷一次出现在3位置，再刷出现在10位置，从体验上很奇怪，所以是否要考虑每次刷新去重？是否要考虑将已读文章去除。
6、如果当天用户无搜索行为怎么办？
……
上面的疑问还只是目前我能想到的，实际开发过程中肯定还要考虑更多细节，比如异常处理，比如缓存机制，比如日志记录等等。看似简单一句话，背后可能就是一起血案。
那么说回来，如何更优雅地描述好这样的“规则性需求”呢？我的建议是：以程序化的语言进行描述，比较好的实施方法是：画流程图！
我之前的日思有聊过怎么画流程图，但那时的思考只是个框架层面的说明，主要教大家从哪几个角度来画。在那篇文章的基础上，最需要注意的一点，也是我今天想强调的，就是：
“对判断语句的说明”，一定要从数学的角度，以“公式”的形式来写。举个例子，所谓“对判断语句的说明”，其实就是流程图里的“菱形分支”，对应到代码层主要是if语句，那“以公式的形式写”的意思，就是要明确写清楚具体的判断时机和触发阈值。比如“二者匹配”就应该写成“关键词A==关键词B”，“实时”应该写成“最新更新时间-上一次更新时间<500ms”，所有的判断都应该有且只有“是”和“否”两个结果。只有明确成计算公式的维度，才不会造成理解偏差，也更接近最终的具体代码实现方案。
当然，也许有同学会说我不懂代码，写不出来怎么办？没办法，学吧，艺多不压身。虽说产品经理不懂开发不代表做不好产品，但懂开发能让你做产品的效率更高，为何不多学学呢。当然有些判断逻辑产品经理确实不如经验丰富的开发同学，那就先描述清楚你的需求和目的，然后请他们来帮你优化这套流程框架，但仍旧要注意其中对判断语句的说明，当你强制要求自己这么思考后，你会有意识地把欠缺的逻辑都补全的。
最后再提一句，并不是所有策略需求都要这么复杂的，做产品是要目标导向。如果你的目的是要完成一个内容分发框架雏形，就不要一上来就搞个性化推荐，而是建议先用最简单的“时间倒序+人工控制权重”方法做MVP实验，再逐渐分析数据，叠加复杂策略。
OK，以上就是今天想聊的，你有做过复杂的策略需求么？你是怎么处理的？期待你的回复与我分享~
閱讀更多 申悅 的文章
