前言
最近工作中接触到新的业务领域，且该领域存在产品化的潜质。
在原来面向项目交付场景下，以快速迭代交付业务为主，随着业务的发展和规划的演进，技术的迭代升级等历史原因，可能存在很多个性化且复杂的交互及实现，或者为了快速交付业务而依托个体存在的功能。
许多传统企业依然是以项目为核心组织价值交付，在此过程中暴露了很多问题，如持续产生的技术债、无法有效执行优先级、质量意识日益淡薄、用户的真正诉求无法确保实现、项目成员工作缺乏主动性、无法有效保证持续性的技术预研、流程及工程实践无法持续改进等。
基于以上问题，一些企业开始从项目化管理向产品化管理的转型，以价值链的形式组织团队，让团队形成对产品的主人翁意识，拆分项目需求为更小的可交付单元，组织敏捷团队相对独立的进行交付，持续投入资源以改进流程和工程实践，以稳定的开发团队来带动对团队成员技术能力的长期投资和培养。
所以最近一边熟悉新的业务，一边在思考到底什么是产品化？如何在原来复杂的系统中抽丝剥茧，进行产品化建设？
一、项目与产品有什么差别？
简单来说，项目是一对一，在一个特定场景给一个特定客户使用， 如企业内部自己开发的办公系统。 而产品是一对多；能快速复制给多个客户使用，如钉钉就是一个产品。 项目与产品还有很多差异，具体差异参考如下表格：
添加图片注释，不超过 140 字（可选）
二、什么是产品化
之前阿里高级技术专家嘉措有提出为了更好地理解产品化这个问题，首先要解释“系统、产品、商品”的定义。
-
系统：各种离散功能组成的功能集合体。
-
产品：有使用价值且封装良好的可复用功能集合体
-
商品：以交易为目的，有使用价值且封装良好的可复用功能集合体。
系统转化为产品的过程就是产品化。产品转化为商品的过程就是商业化。从系统到产品再到商品，是复杂性逐渐降低，体验逐渐提升的过程。
所以产品化就是把离散功能的集合体通过标准化、规范化的流程形成有价值的、封装良好的、可大规模复制生产和发布的能力，它体现的是一种有价值的能力的可复用性和可移植性。一种技术或者一种成果一但形成产品化，就可以真正转化为生产力，并实现规模效益，通过效率最大化实现利润和回报的最大化。如果一个产品的服务能力依托于个体存在，不能体现可复用性和可移植性，也不能称之为产品化。二、为什么要把项目产品化？
对于乙方公司来说（如上面那家为各个微商定制电商系统的IT公司），把项目产品化，可以提升效率、降低成本，从而提高企业收益。 对于内部乙方来说（企业内部的IT团队，或集团下属IT子公司，如平安科技、润联科技），原来作为企业内部的IT团队，属于花钱的成本中心，如果能够把研发的IT系统对外销售，自己可以为公司挣钱，成为利润中心，在公司的地位与话语权都会得到提高。 调查表明，很多内部乙方都有把内部项目产品化、商业化的冲动，一旦认为条件具备了（现有的项目有价值、具备服务更多客户的能力），就想把自己研发的内部系统（项目）做成产品对外销售，希望自己能独立挣钱。
三、如何把项目产品化？
接下来从下面几个方面来介绍如何把项目产品化：
-
产品化的条件；
-
B端产品的演化路径；
-
产品架构设计；
-
商业化准备工作。
1. 产品化的条件
做产品化之前，得先评估一下是否具备产品化的条件。 要考虑如下几个方面： 1）产品
-
项目在内部应用取得良好的成效，有较高的成熟度（功能、性能、体验）；
-
做竞品分析，与市场上的竞品相比，有差异化优势。
2）团队
-
需要组建商业化团队，包括：运营、市场、销售、客户成功部门……
-
做好技术储备：技术架构设计、难题攻关、应急救火。
-
构建双团队：产品团队负责研发产品，项目团队负责交付、运维、技术支持。
-
建立保障机制：问题响应机制、客服与培训。
3）商业可行性
-
要做商业模式分析，设计盈利模式、成本预算、收入预估。
-
做市场分析，确保有足够多的付费客户，有商业前景。
近几年我到各大企业内部做培训与咨询项目时，我发现很多内部乙方（做系统给企业内部使用）的产品经理普遍存在技能短板，如果要产品化，就要针对性地提升这些技能短板：
① 产品化能力不足
-
以前经常被动接受需求，缺乏规划意识与前瞻性；
-
缺乏产品架构设计经验。
② 商业化能力不足
以前做内部系统不需要考虑竞争、定价策略、销售推广、成本、盈利模式，缺乏商业化方面的技能与经验。 通过对内外部的条件进行收集整理，然后可以用SWOT模型来进一步分析是否适合产品化。
添加图片注释，不超过 140 字（可选）
2. B端产品的演化路径
B端产品的发展会经过几个关键的阶段：
-
定制化项目：内部自用系统或为甲方订制交付的项目，通过做项目积累业务经验，了解行业的共性需求、个性化需求。
-
产品化：把共性需求进行抽象，通过产品的形式满足这个共性需求。通过复用共通模块来提高效率、降低成本。另一方面也要考虑个性化需求的满足，因为不同甲方的需求都有差异。
-
商业化：把产品卖出去、交付并挣钱。
-
多元化：产品发展壮大，进入不同的行业、覆盖更多的业务、支持更多类型的终端、更多的部署方式。
-
平台化：这是B端产品发展的终极目标，通过建立生态体系，联合众多合作伙伴共同满足不同客户的需求。很多脏活累活交给第三方的系统集成公司来完成（包括前期调研、方案设计、二次开发、运维等）。
添加图片注释，不超过 140 字（可选）
注意，这几个阶段不要跨越式发展！
每个发展阶段都有每个阶段的任务。
-
项目：积累行业经验，了解共性与个性。
-
产品：设计产品架构，通过抽象复用来满足共性需求，通过配置、插件化、自定义、二次开发等手段来满足个性化需求。
-
平台：打造开放平台、与系统集成商合作、制定行业标准。
哪怕在内部应用得很成功的系统，也不要马上去把这个项目产品化。应该要再做几个项目积累业务经验，才能知道哪些是共性需求，哪些是个性化需求，这样做出来的产品才能复用与扩展。 更不要一开始就立项去做一个平台。 要等到产品要达到很高的成熟度、具有很大行业影响力之后再考虑平台化。
3. 产品架构设计
B端产品架构设计的重点是共性的抽象、个性的扩展，还要考虑依赖解耦、通用化设计。 接下来展开介绍一下。
1）共性的抽象，个性的扩展
做过几个项目之后，有了足够的业务经验，知道哪些是共性需求、哪些是个性化需求，然后就可以做产品化，对共性需求进行抽象复用，同时考虑个性化需求的扩展。 产品化的重点是共性的抽象，个性的扩展。
方便面是经久不衰的好产品。即满足了共性需求，又考虑了个性化需求的满足。
-
方便面的共性需求：方便快速地吃饱肚子。
-
方便面的个性需求：多种口味可选；可泡、可煮、可炒；调味包可根据口味自行调节。
① 共性的抽象
把每个项目共通、可复用的部分，抽象提炼出来进行复用。如下图所示：
添加图片注释，不超过 140 字（可选）
通过复用，可以减少重复工作，提升效率、降低成本。 比如，你开了一家特色餐厅，请了10来个厨师，每人负责做几道菜。如果每个厨师做自己负责的那几道菜都要自己买菜、洗菜、切菜、配菜、做菜、上菜，显然是很不合理的安排。
添加图片注释，不超过 140 字（可选）
做每道菜都有一些重复性的工作可以抽象提炼出来，比如买菜、洗菜、切菜、配菜，交给专人负责，一方面可以提高效率，另一方面可以降低成本。 把这些基础性、重复性工作提炼出来，交给专人负责，为所有厨师服务，就达到了复用的目的，这样厨师可以专注于炒菜，满足不同客户的不同需求。
添加图片注释，不超过 140 字（可选）
四、系统产品化之抽象思维
《史记》有云：“大乐必易，大礼必简。”意思是说．“大”的音乐一定是平易近人的；“大”的礼仪则一定是简朴的。世界的表现虽然复杂，但方法的本质却是简单。在复杂的系统中抽丝剥茧，看到其本质，就需要有抽象思维。抽象思维的核心是通过大量的现象来提炼出本质的东西，即从特殊到一般的过程，提炼出的本质不再是实际的事物，而是一些概念类的东西。
比如草地上有两只羊，在艺术家、生物学家、物理学家、数学家看来却有不同的感受与理解，下面是他们的的描述。艺术家：“蓝天、碧水、绿草、白羊，美哉自然。”生物学家：“雄雌一对，生生不息。”物理学家：“大羊静卧，小羊漫步。”数学家：“1+1=2。”
不同的人或者不同的场景，感受与理解不同，而抽象思维就是在看似不相关的东西中抽象出有相同的共性。
举实际工作中的一个例子。我们在不同的业务场景下，经常会遇到各种各样的策略配置，从策略生产线角度，使用抽象思维抽象策略生产线的流程如下：
策略生产线
-
策略变量准备：策略运营人员在配置策略前，需要确认策略中使用的特征变量有没有准备好，可能不同的策略使用的变量不同，来源也不同，基于共性的角度看，应该有一个产品功能是变量管理，用来管理变量的各种信息，以便提供给策略选择使用。
-
策略配置：变量准备好以后，策略运营人员配置策略，可以看到策略列表，新增策略，编辑策略，查看策略的详情。修改策略，策略版本会发生变化，便于对新版本的策略进行空跑、灰度、正式运行的切换或者策略版本回退。对于不再使用的历史策略，可以删除，便于清理和维护。为了方便快速配置策略，可以复制一个已有的策略，进行适当修改，提高配置效率。
-
策略验证：新增策略或修改后的新版本策略，能快速验证配置的策略逻辑是否正确，策略执行不会出现异常。
-
策略空跑：策略配置验证通过后，可以复制流量进行空跑验证，只执行策略，输出执行结果，但不对后续的流程或动作起作用，不影响线上真实的业务。方便收集策略输出结果，评估策略输出是否符合预期。
-
策略灰度：策略空跑验证通过后，可以切一部分正式的流量，进行策略灰度执行，执行的策略结果对后续流程是生效的。方便回收策略的效果数据，评估策略的效果是否符合预期。
-
策略发布：如果策略效果是正向的，符合预期，可以正式启用新的策略，如果不符合预期，可以停用该策略，或者回退到某个历史版本。
-
策略分析：通过指标监控和策略的效果分析报表，了解每个策略的执行情况和效果分析，不断优化策略。
五、系统产品化之分层思维
分层思维是用层次化思考方式对目标对象逐层分解进行分析和设计的思维过程。生活中比如我们常去的商场，店铺的分布也是有分层的思维，比如一层一般是化妆品/黄金首饰店铺，二楼是女装、母婴用品等，三楼是男装，四楼就是餐厅和电影院等。
商场
在系统产品化建设中，通过抽象思维抽象出来的共性的流程和产品功能，在不同场景下或不同租户下可能存在差异，面对这些差异性和复杂性，同样需要使用分层思维来拆解问题。比如面向业务和系统的复杂性，我们可划分成三层，分别是基础设施层、业务能力层、租户层，每一层有不同的定位和职责。
添加图片注释，不超过 140 字（可选）
-
基础设施层：主要沉淀一些基础的能力组件和业务组件。基于标准和规范定义，提供一些默认实现，并预留好扩展点。基于扩展点，形成差异化的基础组件和业务组件。比如数据持久化机制。
-
业务能力层：基于基础设施层的能力，和差异化的基础组件和业务组件，结合业务领域内的一些特性，组装成领域内的业务组件。比如策略执行当作一个业务组件，在业务领域A场景下策略变量的值是通过API获取，在业务领域B场景下由于时效性要求，策略变量需要从缓存中获取，这样策略执行的业务组件和变量获取的基础组件在不同的业务领域场景下，组合成不同的业务组件或业务能力。领域业务组件或业务能力在差异化的地方提供默认实现，然后预留扩展点，就可以达到快速移植和复用的目的。如果将预留了扩展点、封装好、可复用、可移植的业务能力按照抽象出的产品的共性能力和功能特性进行组合，就可以得到不同的产品。
-
租户层：主要沉淀租户业务的特性内容，在业务能力层的基础上，叠加一些租户所不同的特性内容和差异化的业务配置形成具体的租户解决方案。不同租户之间也是一个分层思维，分层管理租户间的差异。比如A租户基础能力层包含哪些组件，业务能力层包含哪些业务能力，租户层差异化的配置有哪些等。
基于上述分层思维的设想，结合DDD的架构，在系统拆解落地实施方面，用户接口层负责向用户显示信息和解释用户指令，这里的用户可以是使用系统的人，也可以是另外一个系统，其依赖应用层。应用层定义软件要完成的任务，指挥领域层来解决问题。其依赖领域层，可以通过直接访问聚合根（某个实体类），并进行方法的执行和操作，也可以直接访问基础设施层。领域层负责表达业务概念，业务状态信息以及业务规则，通过依赖倒置和基础设施层产生关联。基础设置层提供通用的技术能力和持久化机制。其各层关系如下：
DDD分层架构
具体可以参考我的文章：
总结
系统产品化主要是增强产品的架构设计，提升产品模块的复用性和扩展性。要做好产品化建设，首先要解决的是产品长远规划路线的问题，走一步看三步，避免没有合适的产品架构设计之前就匆忙落地，二是产品设计时要考虑模块组件的抽象和复用。在产品化建设过程中，可以通过抽象思维和归纳思维快速抽取问题的本质，归纳出一般规律和共性结论，在通过分层思维拆解问题，分而治之。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
