画外音：
一直都在收拾了别人的烂摊子，总结一下怎么做一个"人见人夸"的功能设计。
这个系列主要写给产品看，最佳实践不敢说，失败案例我有大把可以分享和吐槽的。
研发请随意，有不妥的地方欢迎指正。
前情提要：
当你不得不造一个轮子的时候，你需要先储备一些基础常识。内容很多，我们分期讲：
一、组件设计的需要工程
先回忆一下我们整体的设计流程。
（一）梳理业务需要和现有数据结构
这里讲的是 需要，不是需求。
需要和需求是不一样的。
比如 经济学开篇第一句：给钱的才叫需求，不给钱的都叫需要。
所以 先搞清楚 需要，再转化成 需求。
这里安利一本书，有兴趣可以买来看看。
1.需要是什么？
1）业务方描述的需要，是 愿景 / 目标 / 问题 / 方案 哪个级别？
-
愿景：我们希望 减少 运营的工作量，这堆后台要合并和打通
-
目标：A后台与B后台能打通，减少运营每日工作耗时1小时
-
问题：B后台不能拿到A后台的XX数据做筛选和清洗，要线下excel搞vlookup
-
方案：在B后台增加筛选指标，指标==A后台的XXX
————
2）警惕方案型的需要，要刨根问底 到 目标和问题
我经常跟刚入行的小朋友讲，人家怎么提不等于我就要这么做。
提归提，做归做。最少 需要 先找准 问题和目标。
同上面的案例，如果提了一个 方案过来，似乎很成熟，是不是就要开始做呢？
如果仔细问问，可能情况就大不相同。
这里一般来讲要问 5次 why。
why 1 -> 为什么要这里加筛选指标？-> 我需要从 A和B两边拿数据，筛选出一批白名单。
why 2 -> 为什么要拿这两个数据筛选? -> 我需要拿到交集的白名单，然后导入到C后台，配置推荐位。
why 3 -> 交集规则固定吗？-> 固定，但是筛选参数看运营策略，每周调一遍。
why 4 -> 调参的目的是什么？-> 看线上数据调整一下权重，活动需求也需要插入排序，把CTR拉高。
why 5 -> 调权有成熟方法吗？-> 有根据这批id的dau和pv调，然后把这周的活动强插进去。
why 6-> 活动数据有现成数据吗？-> D后台有现成配置好的数据。
...
这个时候，你大概已经可以重新定义他的问题和目标：
目标：提高X页面的CTR？
问题：每周在A/B/D 三个后台获取数据，按参数调整排序然后导入到C后台。操作成本太高？
再好好对比一下，跟之前提的方案和问题，是同一个吗？
解决操作成本就能提高CTR吗？
是不是应该换种方法提高CTR呢？
这里有一个衡量你是否挖掘要真实需要的标准：
目标或者真实需要，是与功能无关的。
就像 更快到达目的地 和 让马车跑得更快。前者才是需求，后者不是。
2. 整理业务场景用例和现有数据结构
第一件事：能不能不做？
业务部门总有一大堆 为了证明自己很重要而编出来的流程和工作，不然就被裁光HC了。
所以 先问他：能不能不做。不做你的业务会死吗？
很多时候 答案是：少这个流程也不会怎样。
甚至于 人家会吐槽，其实原本就有兜底机制了，根本不用这么卷。
第二件事：这个需要 涉及什么用例？
如果要做，按部门，按职能，先梳理一遍相关方。
比如说 美术，运营，A/B/C/D的应用的研发 等等等。
按照 POP 面向过程 或者 OOP 面向对象，梳理他们在流程中的初步用例。
一般，我建议按 oop 大概列2张表：
表1：干系人关注点：
| 人 | 系统 | 初步用例 | 涉及数据 |
|---|---|---|---|
| 美术 | --- | 根据运营的诉求，产生活动切图 | |
| 运营 | A系统 | 筛选满足X+Y的ID | 筛选数据X&Y;ID |
| B系统 | 筛选M+N的ID | 筛选数据X&Y;ID | |
| D系统 | 上传创建活动 | 活动id，图片地址，活动名称 | |
| 研发 | A系统 | 控制id上下架 | id状态 |
| .... |
表2：干系人阻力点：
| 人 | 系统 | 阻力点 |
|---|---|---|
| 美术 | --- | 太忙了，会不会没空出图，不想出图？ |
| 内审 | --- | 会不会有私下收钱上推荐？ |
| 风控 | --- | 会不会有不符合社会主义价值观的内容上去了？ |
| 运营 | --- | 多个系统的使用，操作会不会太复杂？ |
| .... |
备注：C端产品和交互设计，喜欢讲体验地图，本质上是一个东西，换个排版而已。
你看梳理一下，就看出来问题了，
上下架状态要同步过去吗？活动开始和结束日期呢？
在其他系统做变更怎么联动C呢？活动和id的数据是怎么合并排序的？
第三个件事：思考新的方案，最好给出3个以上
有一位CFO说过，像财务这种职能部门或者中台部门为什么总是招人恨？
往往就是只SAY NO，不说解决方法，让业务自己头痛去。
所以 定了一条铁律：每次say no, 都要给出3个替代的解决方案。
而在大多数情况下，是不可能走AB实验和数据驱动的。
所以，我们要训练一个能力：暴力枚举+人脑选型。
暴力枚举idea，花不了多少时间的，之后，就要搞一个简化版的swot。
| 方案 | 优点 | 缺点 | 风险 | 上线工期 | 使用者成本 |
|---|---|---|---|---|---|
| 在B系统做一个筛选导出 | -- | -- | --- | --- | --- |
| 写一个接口直接插入C后台 | -- | -- | --- | --- | --- |
| 新增一个后台负责所有筛选和导出 | -- | -- | --- | --- | --- |
| 在C后台获取其他后台数据进行添加 | -- | -- | --- | --- | --- |
| 直接让算法部门改推荐机制 | -- | -- | --- | --- | --- |
为什么这里列出来一个 上线工期和使用者辅助配合的两列呢？
这就涉及到选型的衡量标准:是 技术和业务的最佳平衡点。
优点，缺点，风险，更多是从技术和业务视角，讨论 实现方案本身的合理性。
上线工期和使用者成本，才是真正的硬约束，也就是甲方觉得什么叫最合理。
某种程度上，算是软件工程欠缺的用户视角或者产品思维。
（二）构思方案和选型方案
1.合理的方案是由质量属性和业务约束双重决定的
1）质量属性：
一般从来讲，技术角度的选型合理需要满足以下14个特性：
| 设计属性 | 运行属性 | 感知属性 |
|---|---|---|
| 可修改性 | 可用性 | 可管理性 |
| 可维护性 | 可靠性 | 可支持性 |
| 可复用性 | 性能 | 简单性 |
| 可测试性 | 可伸缩性 | 指导性 |
| 可构建性 | 安全性 | -- |
用大白话来讲：
- 开发起来简单吗，测起来好测吗？
- 以后好不好改，好不好维护，能不能拓展出别的？
- 是不是有什么同类功能是重复的，能不能合并？还是要隔离？
- 在线上运行可靠吗？什么情况下会出问题？
- 有日志可以打点吗？监控排查故障简单不？
- 运行起来成本高吗，快不快？方便回滚不？
当然再往下探索，就涉及到 开闭原则，依赖倒置，里氏替换等等架构原则。 这些后续再讲...
2）业务约束：
一般来讲，包含 认知成本+使用成本+上线工期：
通常来说，
A 涉及的系统/页面/模块 越少，认知成本就越低，对于 后续的交接/培训 都有正向价值。
==> 没有人想动脑子。但这不代表 技术上简单，往往需要花大力气进行 重构整合。
B 使用者操作成本，枚举一遍操作步骤和每个步骤的耗时，这对长期来看，有人持续使用有帮助。
==> 没有人想干活。尤其对运营来讲，不干活就能涨kpi的系统最好，操作超过3分钟肯定有人骂你。
C 上线工期时间。越快能上，及早给业务交付使用，才是开发系统的目的。
==> 没有人想等。尤其对大部分管理者来说，他们眼里只有完成kpi的短期收益。
D 其他约束：
这个比较复杂，比如 组织约束 / 政策约束 / 风控约束 / 财务约束 / 管理约束 / 技术栈约束 等等
某种程度上，这些决定了你的方案选型范围。
2.选型的方法和评估标准
1）如何取舍：
虽然说：约束条件是没有谈判余地的，而质量属性可以取舍。
一般来说，决策顺序应该按照以下优先级：
- 必须满足其他约束：组织/政策/风控/财务/管理/技术栈
- 选择认知成本低+使用成本低的方案，先不要在乎实现成本
- 与业务方商讨上线工期，了解后续拓展场景，试图获取全局最优解
- 根据上线工期倒推，优先考虑 性能/测试/修改/维护/拓展，适当放弃其他质量属性
只有这样，才不会出现一些看似合理，实则不合理的设计：
比如我前文举的例子： 一个九宫格抽奖，高亮和默认配18张切图。
这种选型，就是典型的 使用成本高，前端性能差。
2) 如何量化：
现代软件开发，是围绕着接口和对象（系统/应用/页面/模块/组件/函数）展开的。
有3组核心指标，是需要注意的：
- 接口个数
- 字段个数
- 对象个数（系统/应用/页面/模块/组件/函数）
这三个决定了复杂度，影响着 实现成本，认知成本，操作成本。
- 接口改动数
- 实现改动数
- 接口改动/实现改动的比值
这三个代表着 抽象的合理性。优雅的抽象，起码要做到接口不动，改实现。
- 上游依赖数
- 下游影响数
- 关联干系人
这三个代表着 功能的重要性。越是重要的功能，越容易出现中心依赖。需要尽量选择有长期价值的方案。
通过这9个指标，定义方案的 重要性，复杂性，合理性。 在满足业务约束的情况下，基本上应该选择什么方案就呼之欲出了。
