1. Platform
Platform相对于产品而言，它是横向的。Platform是服务与汇总多方角色的一个完整产品线，它横跨多个纵向产品并为这些产品提供‘公共的’服务，Platform服务并支持点融的多个产品或点融所有的产品。比如，用户运营中心是一个Platform，它既可以给投资端产品提供服务，又可以给借款端产品提供服务；安全反欺诈平台是一个Platform，它为点融所有产品提供公共接口，产品可以通过调用这些公共服务来解决人机识别，黑客恶意注册，登陆等安全问题。
Platform关注‘转化’及‘复用’的能力，它希望越来越多的第三方采用它所提供的服务，从而最大化使用平台的产品数量和不同的业务类型。可以将Platform理解为一系列的基础构造，而这些基础构造的目标是使多个产品能够在同一种技术框架下进行搭建。Platform将功能标准化，抽象化，依靠提供标准化的服务，从而提升Product产品化及开发的效率，同时，它也是MVP产品可以快速上线的强大后盾。
Platform的功能一般比较通用，不和任何产品线紧耦合。它所服务的对象是众多不同的产品或内部团队，通常不会直接面对C端用户。这些使用Platform所提供服务的用户和产品对于Platform本身而言，是没有优先级和重要等级之分的，同时，Platform的设计也没有业务偏向性。
Platform和Product均可Saas化，并有可能卖给第三方。在点融，我们一般会优先考虑Saas化纵向的产品，可以选择性的整合部分平台化的模块作为VAS，从而增加纵向产品的竞争力。
Platform和Product的关系图如下：
A．如何判断
如果对以下大部分问题的回答是肯定的，那么您所致力开发的项目就是一个Platform：
i. 您的项目当前是不是服务于多个点融产品或者未来6个月内会服务于多个（≥2个）点融产品？
比如：这个平台是服务于投资端和借款端多个不同产品的吗？
ii. 如果有一个点融自我组建或者收购的新团队/部门，您所提供的服务是否能够让他们使用？
iii. 您的框架是否支持不同的多种应用和产品在上面进行搭建和提供支持？
iv. 这个项目的目标是不是为了提升Product产品化的效率？
B． 需要遵循的规则
i. MRD Review: 必须进行，且为Blocking Review；
参考流程：MRD Review Process
ii. Architecture Review: 必须进行，且为Blocking Review；
参考流程：Arch Review Process
iii. 职责分配：必须有较高职级（如Director）的人作为owner，必须要有不同的角色分别承担：Approver, Block reviewer和Non-Block reviewer的角色；
iv. 每三个月Product Committee 与 Arch Committee对所有的Platforms进行一次评审来确认该Platform是否值得进行继续开发投资；
C．不建议做的事
i.Platform上不建议做Hack的解决方案，在设计之初就要考虑到与其他产品/用户的整合和对接，项目产出常为模块化的接口及标准；
ii. 不建议做与某个业务强耦合的功能；
D． Platform举例
i. 市值最高的10家公司中有5家就是或有平台业务，比如：Apple, Microsoft, Google, Amazon, Facebook。Amazon是一个线上零售的平台，一开始Amazon只卖书，随着时间的推移，Amazon扩展并销售了各种各样的产品和服务，成为一个Platform；
ii. 对外平台举例：
点融网dianrong.com本身就是一个服务于借与贷的平台；
Chained Finance是为供应链上下游的供应商和经销商提供金融服务的平台；
iii. 对内平台举例：
用户运营，数据仓库，会员体系这些都属于对内的Platform；
除此之外，Design Bible 也是一个Platform。
2. Product
Product相对于平台而言，它是纵向的。Product通过满足特定用户的需求来创造价值，其用户对象十分清晰。比如一个客户关系管理产品的用户就是客户服务部门，点融理财APP的用户就是C端的投资用户，魔借APP的用户就是线上小额借款用户。Product只服务于某一类核心客户，可能会有外部其他的潜在用户，当PM看到有这群用户的机会时，可以考虑做产品Saas化来满足潜在用户的需求。
从业务的角度去看，Product是一个独立运行的业务（Standalone Business），而且Product是有能力成为一个单独的BU或者是分公司的。
Product从一开始设计的时候就伴随着预先定义好的业务逻辑，而这些预定义的业务逻辑将Product的范围限制在一定的界限之内。在做产品设计的时候，PM首先应该去调查公司已有哪些平台可以帮助产品进行快速搭建（通俗的说，就是先要寻找已经可用的轮子），为了推动业务快速向前发展，可以允许Product使用Hack的方式快速实现目前没有的功能，因为其与业务的强相关性，它所关注的是业务走向而不是谁会来调用我的产品。比如，当某个产品需要使用标签的时候，可以将功能做在自己的产品里满足需求即可，但是产品里要做一个公司级别的标签系统，并不是一件靠谱的事。
A．如何判断
如果对以下大部分问题的回答是肯定的，那么您所致力开发的项目就是一个Product：
i. 这个产品如果单独在市场上卖的话，有没有机会？
ii. 这个产品是不是服务于一类特定用户的？
iii. 产品本身有没有可行的商业模式？
iv. 产品中实现的功能是不是强依赖于业务，若非常依赖于业务，则是Product，比如：产品如果脱离了某项业务就无法生存；
B． 需要遵循的规则
i.MRD Review: 必须进行，且为Blocking Review；
参考流程：MRD Review Process
ii.Architecture Review: 当产品处于POC/MVP阶段时，建议进行架构评审，为Non-blocking review；当产品进入成长阶段之后，必须进行架构评审，为blocking review；
参考流程：Arch Review Process
iii.Investment Thesis: 应当包含；
参考流程：Investment Thesis
iv.职责分配: owner为产品经理；
v.每三个月Product Committee对所有的Products进行一次review看是否值得对某个产品进行继续开发投资；
C．不建议做的事
i.不推荐在产品中做平台化的东西，例如借款产品中不应该去开发与“用户生命周期”相关的功能，这些功能应当在Platform中的用户运营里进行开发；
ii.产品加入的功能越来越多的时候Product可以向Platform发展，但是产品不应该是平台化的发起者，需要做平台化的项目就要遵循平台的立项流程并指派合适的Owner；
iii.杜绝产品经理不调研公司已有的技术平台和模块，按个人喜好和想象搭建产品；
D． Product举例
i.每个汽车公司都拥有多个设计制造的平台，比如：底盘设计，轴传动，转向操舵等，而不同型号的汽车就是基于这些平台所搭建出来的产品；
ii.点融借贷，MCA等，这些都属于Product；
iii. 聚合支付服务也是一个Product，服务于点融的核心业务；
iv.CRM也属于Product，为用户运营的一部分，其对内服务于销售和客服，如果Saas化，将能服务于金融企业，银行等外部客户。
3. Feature
Feature是令Product有别于其他产品和竞争对手的重要特征之一，它是Product的重要组成部分，也就是说，一个产品由多个Features组成。Feature主要是指功能性的单元或组件，客户/用户和开发者可以通过Feature来进行沟通，我们也可以利用Feature来审视和提高产品被重复消费的意识。比如TTZ 1.0是一个Feature，它拆散所有的资产包并分配到不同的团中，构成了产品有别于其他产品的特性；现金贷中实时全自动线上审批，极速（仅需3分钟）借款申请体验等属于Feature，它们构成了产品的卖点。
Feature一般包括产品的功能性与非功能性特征（functional/non-functional Features），非主体特征（outlier Features），交叉性特征（cross-cutting Features）及由于时间压力带来的不成熟的特征（immature Features）等。
A．如何判断
有时候我们很清晰的知道“这是一个产品的Feature”，但更多情况下，尤其是当我们在做产品的MVP的时候，往往只是做了一个解决简单问题的Feature。Feature更多的是具体的动作/功能，而包含众多Features的产品，解决的则是特定用户的场景化问题。
如果对以下问题的回答是肯定的，那么您所致力开发的项目就是一个Feature：
i. 这个Feature是不是产品所具备的众多特征（nice-to-have, must-to-have）之一？
ii. 这个Feature是不是高度聚焦的？它是不是与产品现有的其他功能完全不同，但是它又是和其他的Feature一起组成了这个产品？
B． 需要遵循的规则
i.MRD Review: 推荐进行，为Non-blocking Review；
参考：MRD Review Process
ii.1 Pager立项流程：需要进行，且为Blocking Review;
参考流程：1 Pager Review Process
iii.Architecture Review: 推荐进行，为Non-blocking Review；
参考流程：Arch Review Process
C．不建议做的事
i. 防止功能蔓延（Feature Creep）；
D． Feature举例
i.TTZ 2.0对于TTZ 1.5来说，它是一个Feature而不是Improvement, 依赖于RiverRun这个平台, 服务于点融的核心业务；
ii. 小融包，节节发，企业团，社区，商城，点融币都属于Feature；
iii.好的Feature与不好的Feature:
Good Feature
Bad Feature
受用户欢迎
用户抱怨
受开发者欢迎
重复的特性
充分实施的，思虑周全的
变通方案，Hack
准确无误的
缺陷特性
测试充分的
无法测试或者很难进行测试的
满足架构设计要求的
选择性Feature
独特的功能性
极易变动的，不稳定的
4. Improvement
Improvement是指对产品的改善，产品是否实施了这一项Improvement，不会影响产品功能的主要业务目的，但是Improvement在用户体验，使用方便，稳定性，性能等方面的提升，可以更好的实现产品的目标。Improvement的引入不会带来新的business goal，但是Feature会。
比如点融理财界面改版是是一项Improvement，而TTZ 2.0对于TTZ 1.5来说，是一个Feature而不是一项Improvement，因为两者要实现的业务目标不一样，设计和实现也不相同，并且TTZ 2.0为整个产品创造了新的卖点，而TTZ 1.5的目的是为了团产品的合规化，所以TTZ1.5是Improvement，TTZ 2.0是Feature；总而言之，Improvement不会增加产品本身的卖点，但是它可以增强用户体验，提高转化率。
A．如何判断
Improvement针对的是已有的功能，是在已有功能的基础上所做的优化，包括：用户体验，性能等，这是一个持续的过程。
如果对以下问题的回答是肯定的，那么您所致力开发的项目就是一个Improvement：
i.这项改进是不是在现有的产品功能上所做的优化？
ii.您的目标是不是为了提升用户体验？或者是为了提升产品性能/产品质量？
B． 需要遵循的规则
i.MRD Review: 推荐进行，为Non-blocking Review；
参考：MRD Review Process
ii.1 Pager立项流程：推荐进行，为Non-blocking Review；
参考流程：1 Pager Review Process
iii.Architecture Review: 推荐进行，为Non-blocking Review；
参考流程：Arch Review Process
C.不建议做的事
i.防止范围蔓延，杜绝开发者凭经验喜好将Improvement扩大为对一个Feature的重构；
D.Improvement举例
i.点融理财界面改版Lender 4.0是一个Improvement；
ii.注册时由数字验证码改为极验。
5. Bug/Defect
Bug/Defect是指软件产品中存在的缺陷。当软件的功能实现没有满足产品的需求，或者没有满足用户的期望时，这时产生的问题就是缺陷；换言之，缺陷是指代码或数据库层，或代码逻辑实现所引发的功能故障，或者是不符合用户预期的结果。
软件的缺陷可以从以下几个角度进行分类：
优先级 Priority
严重等级 Severity
用户发现缺陷的机率 Probability
质量维度，包括Accessibility，Compatibility，Concurrency，Efficiency，Functionality，Install-ability，Localizability，Maintainability，Performance，Portability，Reliability，Scalability，Security，Testability，Usability
相关的模块/组件
缺陷发现的阶段
缺陷引入的阶段
A.如何判断
i.缺陷可以发生在软件开发生命周期的任何一个阶段，缺陷的识别可以由参与项目的任何人员完成，例如：产品经理，系统维护人员、开发人员、测试人员、界面设计师、用户等；
ii.对于缺陷的修复是指修正不符合设计规格的结果，而Feature request则是给产品添加新的功能；
iii.缺陷是引起客户对产品‘不满’的主要起因，而Feature request则是提升产品吸引力的方法及手段；
B.需要遵循的规则
i.Defect/Bug在创建时应遵循Priority & Security的定义；
参考流程：优先级Priority和严重等级Severity的定义
ii.所有Bugfix，代码一定要进行review；
参考流程：Code Review Guidelines
C.不建议做的事
i.防止为了修复缺陷而引起的范围蔓延，杜绝开发人员凭经验喜好将一个Bug fix扩大为做代码优化甚至扩大为做一个Improvement；
D. Defect举例
i.团投资记录无法显示给投资用户；
ii.散标无法进行投资；
iii.为账户充值点击确认支付后手机应用退出；
iv.新贵贷提交审核后，在审核系统中无相关贷款信息；
v.用户输入的还款金额等于应还款金额时，无法进行还款操作，并且APP报错“不可超过当前结清应还金额，请重新操作”；
vi.社区模块由于新版本的上线加载速度由300ms 延长至 3s。
本文作者：安娜（点融黑帮），资深项目经理。
