出家如初,成佛有余

Scrum 入门基础

Posted in Uncategorized by chuanliang on 2010/08/28
Advertisements

互联网产品线管理模式思考1:产品线管理策略

Posted in Uncategorized by chuanliang on 2010/08/22

    现代制造业为了应对大规模定制(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、产品线基础知识

Product line,Product platform,产品线,产品平台                     

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

Product line,Product platform,产品线,产品平台

                               产品线核心活动                           

Product line,Product platform,产品线,产品平台

                  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,产品线,产品平台

网络营销客户端思考

Posted in Uncategorized by chuanliang on 2010/08/14

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

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

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

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

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

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

网络营销,SEO,竞争情报,市场营销,危机公关

互联网产品的灰度发布

Posted in Uncategorized by chuanliang on 2010/08/08

    在传统软件产品发布过程中(例如微软的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 。

 

灰度发布,灰度放量,A/B Testing,A/B 测试,分流发布

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或服务器端实现分流的规则即可。但对于大型的互联网应用而言,单独的用于管理用户分流的发布引擎就很有必要了。“钱掌柜”分流发布模式 提到了原来阿里软件所使用的灰度发布引擎,设计思路具有普遍性,可以供参考

灰度发布,灰度放量,A/B Testing,A/B 测试,分流发布

6、参考文档

  “钱掌柜”分流发布模式

   百度百科:灰度发布

   A/B testing

   A/B测试终极指南