产品与建模（洞察人性的工程之旅）-《软件方法》阅读笔记

1.引子

洞察人性

黄金圈法则、三现两原、计划与反馈、PDCA、发现问题背后的问题…… 通过管理更好的做事；

建模，通过工程更好的做物（产品）

价值与ROI：

两种不同的攻坚方向，同样困难

管理的作用，达成最后一公里；从 1 到100， 从99%到100%

工程的作用，走好999公里；从0到1，从近乎0% 到 99%

产品等式：

利润 = 需求 - 设计

需求为了提升销售，建模定位最重要的需求

设计为了降低成本，分析确定不变的设计，最大化复用、最少的返工

如何做到：

组织建模：了解组织内部如何协作，为其他组织创造了什么价值；业务流程存在什么可改进的地方；

需求：思考引入什么的产品解决组织的问题，应该具有的功能和性能；

思考产品核心域机制，找到变与不变；

在特定的约束下实现；

各种概念：

功能模块、业务架构、需求分析、用户需求、系统分析、功能设计、详细设计、文档、业务、技术……

目标组织、组织愿景、业务流程、涉众利益、系统需求（功能需求、质量约束、设计约束）、状态分析

2.1.洞察人性之一：看客户的客户要什么

如何找到你的客户，对客户进行分类，不断比较谁比谁更像你的客户；这一部分很多时候是老板在做，但我们仍然要找到那个最重要的“客户”；

一切站在客户的客户的角度，他们对客户的要求是什么，我们是否能够满足？

2.2.洞察人性之二：看客户的老大是谁？他的kpi是什么？

引入产品后改善了组织什么指标，通过鱼骨图帮助（从显而易见的大问题）定位真正的问题，这就是痛点；

——前面的是和高层打交道，找到组织愿景；后面的是苦活，和一线打交道，找到客户怎么给他的客户提供服务，有哪些痛点

2.3.洞察人性之三：看客户的业务流程是什么？我们的产品是否有立足之地？

阿布思考法：假设资源充足，得到一个完美方案；用现有资源去山寨这个方案；

物流变成信息流；

改善信息流转；让越来越多分散的产品自行沟通；

封装领域逻辑；把知识从人脑搬到电脑中；

我们的产品是否可以提供以上三类改进？那就是本质需求！！

3.1.洞察人性之四：哪些需求更重要？

与客户的老大最关心的指标（愿景）更相关的需求最重要；偏离了愿景，很多产品就没有必要做下去了；

3.2.洞察人性之五：客户没有责任和资格提供需求！

产品人员需要与各类客户进行交流，应聚焦于他们的切身利益，然后综合各类人员的利益决定需求；

客户老大的利益以及他最关心的指标是应该首先满足的；

一线员工的利益（在看业务流程时）大概率是处在较低位置的，引入新产品或新系统会导致一线岗位变少、职责缩减或节奏加快；

3.3.洞察人性之六：时刻关注产品的整体表现，需求即价值，满足的越好、价值越高

产品必须提供可接受的价值，不是从研发人员的视角去看，是从各类客户的角度；

关注与产品发生功能交互的人和外部产品，所有的交互过程就是产品满足需求的路径；

3.4.洞察人性之七：把产品看作黑盒子，需求过程是博弈过程

需求是由各类客户的利益冲突和平衡决定的，在需求过程中时刻用“不这样不行”，而不是“这样也行”来检验；

都来舞台上扮演：为各类客户选定一个利益代表，明示他们的担忧，让他们从这些担忧角度去审视每一步交互——尽可能少的侵犯他们的利益；从人性角度更进一步考虑，如果他们的意见偏离了应有的担忧（可能违背了应扮演的角色，可能对人性更深层的利益没有关注到），那就给他们加上新的担忧；

每一步的功能交互关注：产品接受什么样的输入、做什么样的处理和产生什么样的输出；与界面无关、与交互细节无关、与研发人员无关、与实现平台无关；

在进行验证交互的时候，考虑业务异常处理（非技术类的异常）；

在与人或外部产品通讯的时候，考虑他们的反馈是否会符合预期；

设计约束应当来自客户要求，而不是研发人员；

4.1.洞察人性之八：先做业务，再做技术；从需求开始考虑产品内部如何更低成本满足

只有理解业务的研发才能做好产品，精研底层技术的研发是“像蝙蝠一样在鸟中充作兽”；

深入挖掘产品内部静态关系，明示出来、达成一致，“需求变更”会非常少；

4.2.洞察人性之九：Talk is cheap, show me the code ??

产品核心逻辑的变化远小于平台、技术的发展速度，分析上花更多的时间、采用统一的模型，就会发现文档不是代码的另一种形式，文档（泛指代码以外的工件）可以成为代码的基础、可以是真正的设计，而不是只有最后的图纸、电路板和代码！