出家如初，成佛有余

 

 

站内标签:Scrum，agile，敏捷编程，敏捷项目管理

    现代制造业为了应对大规模定制（Mass Customization）的需求，大部分公司都采用了“产品线”管理模式。所谓“产品线”是指一群相关的产品，这类产品可能功能相似，销售给同一顾客群，经过相同的销售途径，或者在同一价格范围内等，采用产品线的典型案例有丰田、福特这样的汽车制造商，华为、思科这样的电信设备制造商，Nokia、Moto这样的手机制造商等等。B·约瑟夫·派恩(B·Joseph Pine II)在《大规模定制：企业竞争的新前沿》一书中写到：“大规模定制的核心是产品品种的多样化和定制化急剧增加，而不相应增加成本；范畴足个性化定制产品的大规模生产：其最大优点是提供战略优势和经济价值。”

    借鉴制造业大规模定制（Mass Customization）的生产方式，在软件架构实现上，卡耐基梅隆大学软件工程研究所（CMU/SEI）推出了软件产品线（Software Product Lines）模型。SEI对软件产品线定义为：A software product line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way。

   软件产品线具有如下如下一些重要的特征：

• 一个软件产品线应该由一系列产品成员组成，即产品家族；产品家族中的所有产品都是服务于一些特定相似的领域，例如电信、教育、航空、数字娱乐等
• 一个产品线的定义是基于市场策略的，而不是基于它的成员产品之间的技术相似性。
• 产品家族成员在构建时候都利用了相同或相似的功能，这些功能来自一些公共的、固化的、并且是受严格管理的核心软件资产
• 软件产品线每个产品都是由来自公共资产库中的组件（Component）组成，然后按预定义的变化机制，如参数化或继承，对这些组件进行必要的剪裁，添加必须的新组件，根据一个产品线范围内的公共架构来组装这些组件。因此，构建一个具体软件产品（应用系统）的主要工作是组装或繁衍而不是创造；主要的活动是集成而不是编程。

1、产品线基础知识

                     

             产品线中产品、组件、架构、商业目标关系

                               产品线核心活动                           

                  Software Product Line Practice AREAS

  软件产品线的基础知识可以参考A Framework for Software Product Line Practice, Version 5.0

 

2、互联网产品线管理策略

    对于互联网平台化产品而言，最佳的实践模式也是软件产品线的模式。平台上的各个产品一般由同一公司不同部门或不同合作伙伴来运营、维护，具体可以体现为栏目、频道、产品、地区版块等。平台化产品中各个产品运营维护团队的不同，实际上是各个公司组织机构的映射，例如按客户群划分、按产品划分、按职能划分、按地域划分等等。为区分组织架构层面的产品线管理架构和软件产品线架构，后续将软件产品线都统一成为产品平台、平台。

    这些产品依托于统一的产品平台（产品线），平台提供了各产品间能够复用的业务组件、技术架构、信息架构、运营支撑体系等。通过这些公用架构、元素的复用，可以相对快速地满足各产品公用需求，在竞争上获得较大的优势，包括：

• 降低产品维护成本
• 加快产品上市速度
• 提高产品质量
• 降低新产品开发风险
• 有利于产品需求持续积累，为产品创新提供素材

   另外一方面，产品平台上的不同产品对公用组件的个性化需求、产品上线频率、产品维护能力、需求优先级、用户体验等要求都不尽相同，无法采用统一的、相对固化的策略来满足所有需求。尤其是各产品线对平台提供的公用元素也存在定制化需求，这些需求对平台的统一性、稳定性也存在较大挑战。如何在保证统一平台的前提下，能够敏捷响应各产品线的共性需求、个性化需求，充分复用已有业务沉淀的资产（产品资产、业务资产、技术资产），保证产品能够低成本、高质量、快速上市成为互联网企业的核心竞争力之一。

   在产品平台的管理上一般可以采用如下几种模式：

  1、产品平台由专职的平台管理维护团队来维护

     有专门的产品产品平台管理团队（产品、技术、UED等）来统一对平台进行管理维护，各产品线的共性需求、个性化需求都由这个平台维护团队来完成。

      优点：平台的策略相对延续，能够保证平台相对稳定性。

      缺点：由于互联网产品需求变化快、迭代周期较短，但按照平台管理流程，需要经过繁琐的审核流程，很难满足各产品线的敏捷响应的要求；各产品线间需求（个性化、共性）优先级的排序很难满足各产品线需求，对某个产品线至关重要的需求可能在整个排序中优先级很低

  2、各产品线有自己独立的产品团队、技术支撑团队

     各产品线的需求由自己的支撑团队来开发维护，基础公用平台及共性需求由单独团队来维护

       优点：能够快速响应各产品线的个性化需求

       缺点：各产品线支撑团队只关注自身短期需求的满足，不会从全局上考虑平台的整体性，而对于架构一点一滴无关紧要的修改最终会导致整个平台的变形和混乱；对公用需求的判定放到每一个产品线团队，大家倾向于快速满足自身的需求，平台的共性需求很难持续积累下来。

3、采用软件产品线的管理模式

      采用软件产品线的管理模式并不是对上述两种管理模式的完全否定，只是希望采用业界已有的最佳实践和框架作为指导原则，从而得出适合于互联网产品线管理的最佳实践。

      关于在互联网平台化产品中怎样使用SEI的软件产品线的具体策略后续具体思考和探讨。

站内标签:Product line,Product platform,产品线,产品平台

    对于大部分的中国互联网企业而言，对成功商业模式克隆比“自主创新”更有吸引力、成本更低。在业务模式趋同，竞争日益白热化的情况下，网络营销能力也是一种核心竞争力。

    传统的市场营销方式相对容易，市场部只需要定期出几篇软文发给平面媒体、新闻门户等合作伙伴发布即可。但面对博客、微博、SNS等新媒体的普及导致的媒体去中心化，以及用户习惯从所谓的AIDMA营销法则（Attention关注 -> Interest兴趣 –> Desire渴望 -> Memory记忆 -> Action购买）到AISAS营销法则（Attention注意 –> Interest兴趣 –> Search搜索 –> Action行动 –> Share分享)转变，要让市场部那仅有的几个人在新形势下完美搞定网络营销挑战较大。因此好的营销工具成为市场部人员的有力战斗武器。

    很奇怪，除了一些诸如“自动发帖机”这样的客户端外，市面上似乎没有一个客户端来针对网络营销来提供一揽子的解决方案。或许有开发能力的公司内部都有一套这样的工具，只不过大家都不愿意把自己的杀手锏公开化。其实像“菊子曰”这样的客户端干这事情挺有优势的，至少比针对普通大众做博客发布工具更容易找到盈利模式。

1、网络营销客户端的需求

    危机公关： 最大限度降低公司负面新闻的影响
    舆论监控： 实时监控各种媒体有关公司的正面、负面新闻
    竞争情报分析：实时监控、收集各大竞争对手的竞争情报
    整合营销：在各大新闻门户、社区、论坛、微博等新媒体一键式发布正面新闻，EDM、SDM等 

2、网络营销客户端技术方案

站内标签:竞争情报,网络营销,seo,危机公关,市场营销

    在传统软件产品发布过程中（例如微软的Windows 7的发布过程中），一般都会经历Pre-Alpha、Alpha、Beta、Release candidate(RC)、RTM、General availability or General Acceptance (GA)等几个阶段（参考Software release life cycle）。可以看出传统软件的发布阶段是从公司内部->外部小范围测试>外部大范围测试->正式发布，涉及的用户数也是逐步放量的过程。

    在互联网产品的发布过程中也较多采用此种发布方式：产品的发布过程不是一蹴而就，而是逐步扩大使用用户的范围，从公司内部用户->忠诚度较高的种子用户->更大范围的活跃用户->所有用户。在此过程中，产品团队根据用户的反馈及时完善产品相关功能。此种发布方式，按照中国特色的叫法被冠以”灰度发布“、”灰度放量“、”分流发布“。

    关于“灰度发布”叫法的来源无从考察。只不过按照中国传统哲学的说法来看，很符合中国人中庸的思维模式：自然界所有的事物总是以对称、互补、和谐的形式存在，例如黑与白、阴与阳、正与负、福与祸。在二元对立的元素间存在相互过渡的阶段，所谓”祸兮福所倚，福兮祸所伏“。具体到黑与白，在非黑即白中间还有中间色——灰色。于是出现了很多关于灰色的说法：灰盒测试，灰色管理（极力推荐 任正非：管理的灰度），灰色收入，灰色地带等等。因此对于灰度发布实际上就是从不发布，然后逐渐过渡到正式发布的一个过程。

1、灰度发布的作用

• 及早获得用户的意见反馈，完善产品功能，提升产品质量
• 让用户参与产品测试，加强与用户互动
• 降低产品升级所影响的用户范围
• 。。。

2、灰度发布的步骤

  1）、定义目标

  2）、选定策略：包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等

  3）、筛选用户：包括用户特征、用户数量、用户常用功能、用户范围等

  4）、部署系统：部署新系统、部署用户行为分析系统（web analytics）、设定分流规则、运营数据分析、分流规则微调

  5）、发布总结：用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表

  6）、产品完善

  7）、新一轮灰度发布或完整发布

3、常见问题

  3.1）、以偏概全

         1)、问题特征：

              a、选择的样本不具有代表性；

              b、样本具有代表性，但选择样本用户使用习惯并没有涵盖所有核心功能
         2）、解决方案：

              样本选择要多样化，样本的组合涵盖大部分核心功能

  3.2）、知识的诅咒

        ”知识的诅咒“的说法来自《粘住》中实验，具体可以自己搜索一下。我们自己对于自己开发的产品极为熟悉，于是乎想当然认为用户也应当能够理解产品的设计思路、产品的功能使用。

         1）、问题特征：

               a、结果没有量化手段；

               b、只依赖于用户问卷调查；

               c、没有web analytics系统；

               d、运营数据不全面，只有核心业务指标（例如交易量），没有用户体验指标

               e、对结果分析，只选择对发布有利的信息，对其他视而不见
          2）、解决方案：
               a、产品设计考虑产品量化指标
               b、结果分析依据量化指标而不是感觉

  3.3）、发布没有回头路可走

        1）、问题特征：

              a、新旧系统用户使用习惯差异太大，没有兼容原有功能

              b、新旧系统由于功能差异太大，无法并行运行，只能强制升级

              c、新系统只是实现了旧系统部分功能，用户要完整使用所有功能，要在 在新旧系统切换

              d、新旧系统数据库数据结构差异太大，无法并行运行

         2）、解决方案：

              前期产品策划重点考虑这些问题，包括：

                  回滚方案、 新旧系统兼容方案、用户体验的一致性、用户使用习惯的延续性、新旧系统数据模型兼容性

  3.4）、用户参与度不够

         1）、问题特征：

                 a、指望用户自己去挖掘所有功能。对于一个产品，大部分用户经常只使用部分功能，用户大部分也很懒惰，不会主动去挖掘产品功能
                 b、互动渠道单一
                 c、陷入“知识的诅咒”，不尊重参与用户意见
        2）、解决方案：
                a、善待吃螃蟹的样本用户，包括给予参与测试的用户小奖励（例如MS给参与Win7测试用户正版License）、给用户冠以title
                b、通过邮件、论坛、社区、Blog、Twitter等新媒体与用户形成互动
                c、提供产品功能向导。在hotmail最近的升级后的功能tip，gmail的tip都有类似的产品功能导向。在产品中会提示类似于：你知道吗，xx还提供xx功能，通过它你可以xx 。

 

4、灰度发布  VS.  A/B测试

    灰度发布于互联网公司常用A/B测试似乎比较类似，老外似乎并没有所谓的灰度发布的概念。按照wikipedia中对A/B测试的定义，A/B测试又叫：A/B/N Testing、Multivariate Testing，因此本质上灰度测试可以算作A/B测试的一种特例。只不过为了术语上不至于等同搞混淆，谈谈自己理解的两者的差异。

    灰度发布是对某一产品的发布逐步扩大使用群体范围，也叫灰度放量

    A/B测试重点是在几种方案中选择最优方案

   关于A/B测试可以参考这篇文章：A/B测试终极指南

5、灰度发布引擎

   对于一般的小系统并不需要单独的灰度发布引擎，可以参考A/B测试中做法，在页面javascript或服务器端实现分流的规则即可。但对于大型的互联网应用而言，单独的用于管理用户分流的发布引擎就很有必要了。“钱掌柜”分流发布模式 提到了原来阿里软件所使用的灰度发布引擎，设计思路具有普遍性，可以供参考

6、参考文档

  “钱掌柜”分流发布模式

   百度百科：灰度发布

   A/B testing

   A/B测试终极指南

站内标签:灰度发布，灰度放量，A/B Testing，A/B 测试，分流发布

   前两天接到了蜘蛛网客服的电话，说我年初通过他们网站订阅中国经营报时候，中国经营报赠送了几本书。这段时间中国经营报那边盘点时候发现给我的赠书一直没有送出，中国经营报那边向蜘蛛网询问情况。客服说蜘蛛网这边一直也没有收到我的投诉，因此直到中国经营报问起他们最近才发现此事。

    年初订阅杂志时候，平常也没时间去邮局，因此就直接在蜘蛛网上订了常看的几本杂志和报纸，其中就包括中国经营报。中国经营报赠送了洗衣液和几本图书。洗衣液几周以后很快就送到了，而图书过了1个月还没到，给蜘蛛网发过3次邮件投诉。第1次的回复说是已经反映到相关部门了。过了一个多月赠书还是没有送到，再发了两次邮件投诉后都没人搭理了，打了几次电话都没打通。由于对赠送的几本图书并不是很感兴趣，因此也懒得再催了。通过此事体验了一下蜘蛛网极差的服务，打算以后不再使用蜘蛛网。

    其实细想一下，也不能完全说是蜘蛛网的问题，大致的原因应该如下：

   根据中国经营报在其网站及报纸上的广告，订报送洗衣液和赠书的活动应该是中国经营报自己举办的。蜘蛛网只是类似于邮局的一个订阅渠道而已。蜘蛛网应该把我的订单传送给中国经营报了，不然中国经营报就不会每周送报，也不会安排人赠送洗衣液。预计中国经营报订报送赠品活动也是找不同的合作伙伴来弄的。例如洗衣液是开米出的，而图书又是其他合作商来弄的。因此中国经营报收到订单后，也把订单同步给了提供洗衣液的合作伙伴，但在处理过程中，把赠书的事情拉下了。

    当然并不是说蜘蛛网没有责任，其实在这过程中，蜘蛛网有很多可以改进的。而蜘蛛网与线下合作伙伴合作过程中所面临的服务品质问题也是众多电子商务提供商所面临，关于服务品质一些体会：

  1、多种客服渠道的服务体系一致性的问题：蜘蛛网的服务渠道应该主要是电话，像我通过邮件的投诉应该并没有整合到其整个呼叫中心体系中去，因此出现了我没投诉过的事情。这与电子商务企业的客户服务系统建设-再谈京东商城购物所感 中提到的类似。呼叫中心！=电话服务中心。如果不能够将同一客户通过传真、Email、IVR、电话、短信、电话、IM、社区、论坛等各种渠道的投诉申告等整合到一起，各种服务渠道的服务品质不能够保证一致性，则所谓的“以客户为中心”只能是空谈。其实并不需要呼叫中心建设时候在技术上必须支持所谓的多媒体呼叫中心、第三代、第四代呼叫中心等等。问题的关键还是在意识和管理体系上。

  2、服务边界问题：对蜘蛛网而言，其只要引导客户生成订阅订单并成功支付后，蜘蛛网将订阅订单成功发送给合伙伙伴，则在其平台的服务就结束了，后续的服务品质的保证蜘蛛网就无能为力了。这也是目前大部分电子商务网站的模式。但对于客户而言，并不关心后续服务是谁提供的，他只关心在单一的接触点，服务都能够得到保障。对于蜘蛛网这些前端提供服务的电子商务提供商而言，其服务的边界不单纯只是自己，还包括相关的合作伙伴。这正如电子商务平台之平台服务杂思 中谈到的：“在面临日益剧烈的竞争下，平台服务对于合作商户的核心价值在于：通过平台来帮助其提高竞争力。这种竞争力包括服务能力、盈利能力、营销能力、服务的持久性等。”

    这也是为何沃尔玛、麦当劳、Dell这些跨国公司其实将采购价格压得很低，但一堆合作厂商还是愿意挤破头去竞争合作伙伴的名额，除了品牌、销量因素外，还有重要的一点是：沃尔玛这些厂商会帮助合作伙伴提高标准化管理能力、服务的品质和能力。

   3、服务无小事：自己作为服务提供商服务时候，总觉得大部分客户的投诉都是鸡毛蒜皮的问题，并不影响产品使用，觉得主要是客户素质太差。当自己作为客户使用蜘蛛网这样的服务时候，才发现：我们作为客户在使用别的服务提供商的产品时候总是比我们自己作为服务提供商时候的标准更高、更没有耐心。可能只是一件鸡毛蒜皮的事情就会导致我们很不爽，从此不再使用此服务。在做产品时候，“同理心”是一种很好的手段，但“同理心”并不等于实际用户的心理，只是我们的揣测。作为客户和作为提供商时候，我们的标准体系并不一样。

    因此应当善待每一次的客户投诉及不爽，每一次的投诉都是我们改进产品最好的机会。对于客户投诉不妨想得更加严重一些。

  4、服务品质也是一种品牌：最为典型的例子要数海尔。海尔的产品可以概括为：一流的服务、二流的产品（耗电、价格高、质量一般），但并不妨碍海尔产品的口碑。个人认为海尔的品牌就是其服务品质所造就的。对于互联网服务提供商同样如此，服务也是一种核心竞争力，尤其是对于那些竞争激烈的产品。在选择产品以及合作伙伴时候，如果所提供的产品的服务品质不能保证，再赚钱的产品也会成为品牌的杀手，这时候要勇敢学会放弃。在做市场营销、网络营销时候也是如此。

 

站内标签:电子商务,客户服务,服务品质,产品管理

    一个新产品需要重点考虑业务风险控制。关于风险控制系统整体的技术方案可以参考 支付系统风控系统建设思考 。此方案尽管能够满足业务需求，但对于海量交易数据分析、风险事件的实时处理、大量的风险规则处理上，在实时性、性能、架构的可扩展性上都不是很理想，有必要重新从架构上考虑一下实现方案。

   一般而言，风险控制系统标准的软件架构如下：

   

1、风控系统实现的几种方案

   1)、数据库方案：将风险规则、交易数据等都采用关系数据库存放。正如 支付系统风控系统建设思考 所提到的方案，交易库和风险库一般分别部署在不同的服务器上，在事件触发上可以采用数据库触发器、消息队列事件等方案。此种方案技术实现相对简单，但在进行海量交易数据查询以及大量风险规则处理时候，数据库系统查询性能及扩展性成为一个较大的瓶颈。很难满足风险事件实时分析的要求。

   2)、内存数据库方案：由于对海量交易数据的查询、分析极其消耗数据库资源，可以采用内存数据库方案来替代关系数据库，保证风险事件实时处理的性能。 但目前开源的内存数据中VoltDB、H2、MonetDB、FastDB、Berkeley DB、SQLite等在大规模的业务场合应用的成熟度尚待考察，而Oracle TimesTen、MCObject eXtremeDB、Altibase价格太高。

   3)、分布式缓存方案：采用Memcached等NOSQL的分布式缓存来缓存交易数据、风险规则等，但由于NOSQL解决方案并不擅长数据间的关系逻辑处理，需要在程序中大量维护业务处理逻辑，远不如关系数据库或内存数据库方案方便。

  以上方案，都可以通过规则引擎（例如drools）来完成风险规则的管理和维护，避免了风险规则维护的繁琐及规则间复杂关系处理。

 

2、Complex Event Processing (复杂事件处理)

    Complex Event Processing (复杂事件处理)是一种新兴的基于事件流的技术，它将系统数据看作不同类型的事件，通过分析事件间的关系，建立不同的事件关系序列库，利用过滤、关联、聚合等技术，最终由简单事件产生高级事件或商业流程。CEP适合的场景包括实时风险管理、实时交易分析、网络诈欺、网络攻击、市场趋势分析等等。

    CEP的几大特点：

• 基于数据流
• 时间序列
• 实时
• 复杂

                   数据库方案与CEP方案 对比（摘自Sybase CEP方案）

   

3、开源项目

Esper – Complex Event Processing

    http://esper.codehaus.org/

JBoss – Drools Fusion

    http://www.jboss.org/drools/drools-fusion.html

Open ESB IEP SE

    http://wiki.open-esb.java.net/Wiki.jsp?page=IEPSE

ActiveInsight

    http://www.activeinsight.net/

    其他产品或开源项目，可以参考：Complex Event Processing Vendors

  其中Esper和Drools Fusion很值得考虑，后续作为重点研究对象。

 

4、参考资料

    深入浅出复合事件处理（CEP）

    轻松理解复合事件处理

    Esper：CEP Engine

    Complex Event Processing：An attempt at clarity on an often confusing topic

    Sybase CEP：新颖的数据流分析平台

 

站内标签:CEP，复杂事件处理，Complex Event Processing，Event Stream Processing，ESP,风险控制

1、为什么要进行产品重构

    旧系统人员流失，系统的业务规则、原始需求谁都不清楚，需求文档、使用文档、架构文档极其缺乏，成为一个无底洞，可维护性很差。  

    旧系统越来越复杂，潜规则太多，原本修改一个小需求，一不小心搞得上线后影响一堆用户

    旧系统的业务架构、技术架构无法满足新的业务模式需要

    旧系统性能无法满足公司业务高速发展的需要

    旧系统的产品生命周期已经到头，需要延长期生命周期

    等等

2、产品重构  VS.  重做新产品

    对现有产品进行重构还是重新做一套全新的系统并没有标准答案。技术人员们都倾向于重做新系统，并都倾向于高估自身的管理能力、架构设计能力,大家都会承诺完美的架构、完美的产品规划。但如果没解决根本性的管理问题，重构或是重做宿命都是一样的。这些管理问题包括产品规划能力、业务架构能力、项目管理能力、架构管理能力、架构设计能力等等。   

   在管理能力尚未改善的情况下，怎样保证重做新系统时候不落入旧系统“新做系统，承诺完美架构->管理失衡，系统维护陷入混乱->再重做新系统”同样的命运。好的架构是管理出来的，不是设计出来的。

  产品重构第一困难的是反向工程过程阶段，必须搞清楚现有系统的遗产状况。对于一个在线运营的系统，不管是重构还是重做都必须经历此过程

  产品重构第二困难的是旧系统迁移到重构系统的过程。怎样做到不影响现有客户使用的情况下完成灰度切换，这是最大的挑战。不管是重构或是重做都必须经历此过程

3、关于产品重构的思考

4、参考资料

  The Product Re Architecture

  利用 RUP 对遗留系统进行逆向工程 

  软件架构的艺术

 

站内标签:Architecture Reconstruction，architecture recovery，产品重构，架构重构，反向工程，正向工程