在B端产品中，常用到列表展示信息，其中列表内条目的排序规则及实现方法需要产品经理去思考和定义。笔者思考总结了项目中的一些经验，供大家参考。
排序的最终目标：
与所有的产品设计思路一样，我们要“以终为始”去思考问题。不管经由什么方法，排序的最终目的是“以符合业务逻辑的方式呈现信息”，也就是说，排序的结果需要在业务层面具有实际意义。
举个例子，从开发逻辑上来说，任何一个绝对线性的字段，比如条目创建时间，都可以用作排队指标，但是这个指标如果在业务层面毫无意义，就是不可用的。
排序面临的问题主要有两种：
1. 业务逻辑不明确
这种情况下，需要产品经理参考通用的做法，结合自己对业务的理解去制定一个相对合理的排队规则，比如按时间顺序、时间倒序，或者某个关键字段等。
另外一种做法是对列表中多个关键指标提供“排序”按钮，把排序规则交给用户，保持产品的灵活可用性。
2. 实现方式不明确
B端产品设计要受制于业务规则，业务规则具有复杂性。很多时候我们无法用单一或者明确的方式去实现排序结果，而是需要产品经理去设计一个“算法”，来无限接近最终目的。
下面我用一个例子，来具体解释这个问题。
2.1 情境
某资料库类产品，以项目为单位，提供项目信息及文件增删改查的功能。
其中，项目内的各轮投资信息需要在项目首页进行排序显示，且排序结果影响各轮投资之间的参数计算结果。
问题：没有单一可以用来排序的关键指标，产品经理需制定排序规则。
2.2 思路
在这个案例里，最终需要的排序结果是各轮投资实际发生的顺序。
针对结果，首先想到的几个可用指标：投资轮次名称、各轮次结束时间（closing date)、各轮次创建时间
（1）投资轮次名称
“投资轮次名称”是首先会想到的比较明显的排队指标，且具有独一性。但是经过调研之后，发现各轮投资并不是绝对线性发生，所以无法作为排序的指标。
（2）closing date
每轮投资会有closing date，可以标记轮次发生的顺序，且同样具有独一性。
但是，考虑两种情况，closing date 并不是必填项。
资料录入时，本轮投资有可能未结束。
历史资料批量导入，closing date可能缺失。
（3）轮次记录创建时间
创建时间是计算机记录的用户操作时间，具有不可更改性，无法适应历史资料导入的情况，或者用户录入轮次顺序颠倒的情况。
2.3 结论
综合以上分析，最终制定：
短期方案为：优先按closing date排序，此项缺失时，按创建时间排序。
长期方案为：随着产品投入使用和项目资料的规范化，调整closing date为必填项，覆盖closing date缺失的情况。
总结
根据以上分析，B端产品列表排序的设计思路，可以用下图概括：
以上，希望能为B端产品的小伙伴提供一些参考和思路。
