关于后台产品设计(1)

一直从事后台产品设计，在收集需求，书写设计书和评审设计书的工程中，遇到了一些问题和困难，
解决问题的过程很艰难，结果让人欣慰。自己随手记录下了一些心得，希望慢慢的把心得整理成方法论。
一方面能强化自己的产品思维，另一方面可以作为公司内部产品经理(BA)教育的资料使用。
思前想后，决定以博客的形式记录心得，虽然比较片段，但是可以随笔记下，慢慢积累吧。

关于产品方向，
1.世界上没有完美，产品经理要找到最大平衡点。
从用户的角度出发，功能越全面，越易懂，使用越方便，越好。
但是有些功能被使用的概率很低，有些功能只方便了那么一点点，但是对系统的影响却很大，增加了系统的复杂度，增加了bug发生的概率。
最重要的是，没有实质上给用户带来便利，或只带来了很小的便利。
这时候建议产品经理能够结合系统实现考虑是否能在功能上做一些小的妥协，或迂回的实现想要的功能，而不是粗暴的修改代码。

2.大系统是一点点迭代/改善出来的，不是一开始就设计出来的，不要过度开发。
在设计阶段以团队的能力和掌握的信息为基础，考虑系统的扩展性，不要过度开发，不要为几年后有可能发生的需求做很多准备。
复杂系统是在使用⇒改善⇒使用⇒改善中迭代出来的，一开始就设计的很复杂，大概率会导致系统冗余。

3.不要过度设计。
在做产品设计的时候，做决定前考虑一下如果这样做，用户会如何？开发者会如何？产品上线的时候会怎么样？产品使用一年后会怎么样？
不要考虑产品3年后会怎么样。3年离我们很远，科技在发展，用户的需求在改变。基于眼前的需求，把产品做好才是我们的任务。

4.不要过度设计。
审查每一个需求，切割掉产品经理猜测出来的，自我满足的需求。
需求分两类，用户的提出的明确需求，产品经理引导出来的用户需求，为了增强用户体验的技术类需求。第2和第3种需求很容易被无限放大。
时常问问自己这个需求用户真的使用吗，会给用户带来什么样的价值(便利)，没有这个功能会有什么样的不方便。实装了这个功能我们将会付出什么样的代价。
例如：银行购买基金功能，产品经理设计了一个修改功能，在交割日前可以修改购买基金的数量，甚至可以修改购买对象。
这个修改功能就是过度设计，产品经理为了用户使用方便而设计了这个功能，但是用户应该极少使用这个功能吧。绝大数用户会很谨慎的点击购买按钮，
即便是产生了错误，用户也会选择撤销这条购买。而不会直接修改这条购买。
另外，在购买逻辑中一旦加入了修改功能，会导致购买模块的内部逻辑的复杂度增加，难于维护。

5.产品经理要在大脑里有系统的image，需要时刻考虑自己设计是否能够被实现，会被如何实现。
自己都没有image，全部交给开发者的话，大概率会无法得到想要的效果。
这就要求产品经理要有系统开发经验或系统设计经验。还要求产品经理跟上技术发展的步伐，了解新技术，否者“贫穷会限制我们的想象力”。

6.没有完美的方案，把认为可行的方案都罗列出来，分析优缺点，在分析的过程中我们会发现很多新的思考点，分析的过程能直接引导出最佳方案。
由于受到成本，时间，团队综合能力等等的限制，绝大多数情况下，我们都没法执行最完美的方案，还是那句话，适合才是最好。
产品经理的工作是找平衡点。
日本的职人精神很可贵，追求工业产品的极致和完美。这种精神让日本生产出最优秀的照相机和engine。
但是日本人没能创造出Facebook，Apple，阿里，华为，日本甚至没有自己的检索引擎。在他们在追求完美的时候，科技世界已经迭代好几代了。

7.经常有业务设计人员来找我判断设计方针和方向。
普遍认知是因为领导者有权利，所以能够敲定工作方向，其实不是这样，真正决定方向和方针的是事物的趋势和潜在逻辑，不是人。
这里说的趋势包括背景，目标，外部限制条件，内部团队能力等。
如果有人把工作梳理清楚，把话说清楚，很容易能做出正确的判断。这种时候找领导不是判断方向，而是寻求许可和承认。
日本作家大前研一写的《思考的技术》一书中，全面清晰了以上理论，建议每个人都细读一下这本书。我本人读了三遍，每次都能有新的收获。
8.产品需求整理
经验较少的BA设计出来的功能经常漏洞百出，最后导致一部分或大部分推倒重做。

BA喜欢把原因归结到业务知识还不足以及一些其他外界因素，因为业务知识不足是整个金融业的苦恼。
其实根本原因是在没有充分理解全局的前提下进行了细节设计，导致整体结构出现问题。因为细节可以一个一个向用户确认，可以慢慢细致打磨，
但是整体结构的设计用户可帮不了你。初期一旦跑偏或设计狭隘的话，后患无穷。

经验较少的BA人员容易一头扎进详细的功能。应该冷静思考一下产品的定位以及特征。
比如在原有的银行产品平台上新作一个债券交易模块。
在做这类产品时，建议不要一头扎进用户给的需求，因为我们无法保证用户的需求足够系统和全面。
不要让用户给的先入观占领我们的大脑高地。
先考虑债券商品的顾客群体是什么，这里包括现在的目标顾客和今后的发展方向。
这些顾客的Account有哪些种类(如：工资绑定用户，白金用户)，各种类的account在购买债券时候的规则有什么不同。
再考虑债券有哪些种类，国债，社债，转换债，固定利息债，一次性偿还债等等。
之后再考虑哪些account能够购买哪些债券，不能购买哪些债券。购买之后的Position应该如何管理，是否需要合算，以什么单位进行合算。休日是否可以进行交易，交割cycle是什么。
首先要梳理清楚业务场景，就是我们所说的业务Secnario。
Secnario出来之后，顺便就弄清楚了master(account，instruction，Trade calendar)和Transaction(trade,balance)
在此业务框架之上再研究业务细节。例如，哪些金额如何计算等等。

整理业务模块整理清晰之后再和用户的需求做对照，我们会发现很多疑问，接下来我们要做的是把这些疑问一个个击破。

9.用户最少操作，最大化获得信息或实现目的。注意要易懂。
比如，普遍认为一览画面和详细画面是配套出现的，在详细画面可以删改。
如果项目数量过少，就不必要详细画面，在一览画面解决掉。

10.产品线要着眼于世界级的市场，但是要先落脚到细化市场。围绕客户群有一系列产品规划，并牵引技术规划。

11.后台产品绝对不可以被技术牵引。在一些特定领域可以技术牵引产品，实现从零到有的过程，往往这类产品能改变人们的生活，甚至更广泛。

12.先开发产品，在销售或使用的过程中逐渐完善和产品，或是以领导的构想为需求。
这就是技术人员大量加班的根源，需求一定要明确。否则做出来的只能叫demo。
市场需求分析，用户使用习惯分析必须先行，先验证需求之后在开始开发。

13.一个好的产品开发过程是以产品经理以及对产品市场财务的成功负责的核心成员组成。
不是由于各阶段的项目经理主导。项目经理更侧重于执行流程实现产品理念。

14.以平台(基盘)为核心开发产品线，在这个产品线上不断加载新的产品。
有专门的高级成员维护平台，构建长久的以平台为核心的产品线。以此减少开发产品的开发周期，加强产品技术架构的稳定性。

15.质量管理的主体：产品经理，产品owner。品质管理部门是执行者。

16.核心技术以平台为依托支撑产品线，产品支撑商业解决方案，解决方案支撑服务，从而实现企业的商业目的。并且可以走持续健康路线。

17.产品开发定位为三个维度，
    1)平台开发，商业价值在于平台上的技术解决方案销售。比如，分布式并行处理的技术解决方案。
    2)共通级别的产品开发，商业价值在于同一个产品多家公司使用，最低的维护费用，较少的收费标准，创造最高的价值。
    3)产品定制化。不是所有的平台产品都可以可定制化，臃肿的产品在定制化的过程中会消耗极大的成本，甚至高于新开发。
    只有简洁系统才能定制化。简洁系统需要对系统的扩展性有较好的平衡，对技术和业务的相互妥协有较好的判断。