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

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

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

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

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

    等等

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

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

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

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

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

3、关于产品重构的思考

4、参考资料

  The Product Re Architecture

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

  软件架构的艺术

© chuanliang for 出家如初，成佛有余, 2010. | Permalink | 9 comments

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under 产品管理, 技术相关.

1、不可能完成项目的典型特征

    对于互联网公司及做传统系统集成的公司的同志们而言，接到这样不可能完成的项目开发任务的情况已经司空见惯了。这些不可能完成项目的典型特征如下：

• 老板说：项目对公司具有战略意义，必须搞定
• 项目突发：销售跑过来告诉你，一个月内必须搞定这个项目
• 需求不明确
• 对现有系统架构有较大冲击，改动风险很大
• 项目给的时间很短且交付时间固定(time boxing) ，只能够倒推
• 销售过度承诺，必须实现狂复杂、狂大的需求
• 资源有限
• 设计诸多部门协调，很难短期搞定

2 、失败项目的典型症状

• 项目组所有成员及利益相关者对项目愿景及目标没有达成一致
• 为了赶进度，压缩需求分析、系统设计时间，需求理解尚未统一就投入开发
• 每个人只关心自己负责的一小块业务，对系统整体需求、架构、设计没有达成一致
• 为了赶进度，只关注功能的完成而忽视了功能实现的质量，导致大规模的返工
• 为了赶进度，不进行统一设计，由各模块负责人自己设计，设计存在较大缺陷
• 公用问题没有专人负责，工作重复
• 项目组成员沟通不畅，出问题后才沟通，导致无谓的时间浪费
• 项目组没有形成团队文化，团队成员只是为了完成项目目标而加班赶工，没有归属感

3、不可能完成项目的Scrum实践

    对于这样的不可能完成项目的管理使用Scrum这样的Time Boxing迭代开发过程很恰当，关于实践方法有兴趣的可以参考脑图。

原图点击下载

4、参考资料：

Quick-Kill Project Management

Quick-Kill 项目管理（完成“不可能的”任务）

用“看板图”实现敏捷项目的可视化

硝烟中的Scrum和XP

EssUP迭代核心——时间盒 Time boxing

© chuanliang for 出家如初，成佛有余, 2010. | Permalink | 14 comments

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under 产品管理, 技术相关.

    相对于传统瀑布式开发过程及RUP这样的重量级开发过程而言，敏捷软件“重视与客户的沟通；小步快跑，尽早交付；迭代式开发，拥抱变化”等实践正好符合互联网要求快速迭代、坚持以用户为中心的设计（UCD）等特征相吻合，因此敏捷软甲开发过程成为了互联网软件开发的标准模式。

    一直以来都觉得敏捷软件是“轻架构设计”的，不管是XP、Scrum、FDD、Getting Real等敏捷软件开发过程对待设计（Design）的理念都遵循了演进式设计 (evolutionary design) 而非计划性的设计(Planned Design)。

    而且由于类似于Ruby on Rails、SSH（Struts+Spring+Hibernate）、Django、CakePHP这样快速开发架构的出现，技术架构已经成为流行的术语，一个刚毕业的小孩也能够大谈架构设计、设计模式、架构模式，传统的架构设计似乎已经没有太多的必要。

    但在实践过程中，会发现轻架构设计的一堆严重后果，诸如：陷入了"code and fix" 的恶梦；系统越来越复杂和混乱，架构完全失控；

    再读Martin Fowler的《Is Design Dead?》，才发现自己对于敏捷软件的理解是如此的教条：

  Continuous integration、testing 和 refactoring 这些有效的实作方法让 evolutionary design 看似很有道理。但是我们尚未找出其间的平衡点。我相信，不论外界对 XP 存有什么印象，XP 不仅仅是 testing、coding 和 refactoring。在 coding 之前还有 design 的必要。部份的 design 在 coding 之前准备，大部份的 design 则发生在实作每一项详列的功能之前。总之，在 up-front design 和 refactoring 之间可以找到新的平衡。

   大师不愧为大师，能够准确把握住事物的本质，能够把握住过犹不及的度。其实任何方法论都有其应用的边界，方法论没有问题，错误的根源在于使用方法论的人的教条主义。

2、形形色色的架构

    “架构”这词成为了一个技术领域时尚的话题，每一个人都在谈论架构，似乎不谈架构就没有技术品位，于是乎出现了一堆与架构有关的术语，包括：软件架构（Software Architecture）、系统架构（System Architecture）、企业架构（Enterprise Architecture ）、信息架构（Information Architecture ）、应用架构（Application Architecture ）、IT架构（IT Architecture）、产品架构（Product Architecture）、业务架构（Business Architecture）、技术架构（Technology Architecture）、解决方案架构（Solution Architecture）、基础架构（Infrastructure Architecture）、领域架构（Domain Architecture）

3、敏捷架构

    敏捷模型驱动开发(Agile Model Driven Development)中对于Agile Architecture Modeling有比较清晰的描述，也回答了为何在敏捷软件开发过程中需要进行架构设计的原因：

    1）、Improved productivity. You can think through some of the critical technical issues facing your project and potentially avoid going down fruitless technical paths.

    2）、Reduced technical risk. Your team gains the advantage of having a guiding vision without the disadvantage of having to overbuild your system – just because you’ve modeled it doesn’t mean you have to build it.   

    3）、Reduced development time.  Initial agile architecture modeling enables you to make better cost and time estimates for your project, two pieces of information which management will want.  

    4）、Improved communication.  Having a high-level architecture model helps you to communicate what you think you’re going to build and how you think that you’ll build it, two more critical pieces of information desired by management.

    5）、Scaling agile software development.  Your initial architecture model will be a key work product in any "agile at scale" efforts because it provides the technical direction required by sub-teams to define and guide their efforts within the overall project.

    6）、Improved team organization. Effective teams are organized around the architecture or line of business, not around job function.  As you scale to larger and/or distributed teams the sub-teams should each be responsible for one or more sub-systems — you don’t want to organize your sub-teams around job function (e.g. an architecture team, a development team, a testing team, …) because that requires you to increase the documentation and bureaucracy overhead which in turn increases risk, cost, and time to value.

   相对于其他的敏捷软件开发过程，在Agile Model Driven Development（AMDD）中明确包括了初始需求分析与架构建模，这个过程发生在敏捷项目开发的第0次迭代中。所谓第0次迭代，就相当于项目的热身活动，是项目得以启动的基础。

    Agile Enterprise Architecture 中谈到了敏捷软件架构的一些指导思想：

    1）、Focus on people, not technology or techniques

    2）、Keep it simple

    3）、Work iteratively and incrementally

    4）、Roll up your sleeves

    5）、Look at the whole picture

    6）、Make enterprise architecture attractive to your customers

4、关于架构的一些思考

4.1、架构！=技术架构

    敏捷架构并不只是指技术架构本身，正如前面提到的，还包括产品架构、业务架构、信息架构、应用架构等等。

    技术架构不单纯只是技术实现本身，还承载了业务架构、产品架构、信息架构、应用架构的具体实现，纯粹的技术框架本身没有太多的价值。纯粹的技术框架的架构可以一次性完成，但对于业务架构、产品架构的架构必须随着公司对于行业深入的了解才能逐步完善，对于业务需求的管理能力成为一个公司发展的决定性因素。

    对于一个运营型的互联网公司，核心的竞争力之一在于对所服务的行业业务及客户深刻的理解并具备将这种行业经验转化为产品及服务的能力。互联网在服务过程中积累的不单纯只是技术架构的积累，更为重要的是行业需求的积累，而这需要对应的业务架构和产品架构来作为持续积累的框架。技术架构可以较为容易获取和变迁，但行业经验却难以短期突破。

    对于中国这些互联网公司而言，基本上没有太多原创的产品，尚没有能力做到技术驱动、创新驱动的层次，大家还停留在做简单的行业应用上，公司间的竞争基本上也停留在应用开发能力及运营能力的竞争。因此对于中国互联网公司而言，合理的业务架构及产品架构比技术架构本身意义更为重要。

4.2、架构是管理出来的，而不是架构出来的

    在中国公司比较典型的情景：

    1）、公司原有架构师及开发人员因为某种原因离职，公司招聘一个新的架构师

    2）、新的架构师被公司寄予较大期望，由于维护老的架构吃力不讨好，而架构师要急于证明自己的能力，最为简单有效的办法就是重做一套系统。

    3）、新的架构师将原有的架构推倒再重新做一遍，并承诺了完美的架构：能够解决目前产品、运营、财务人员们面临的所有问题

    4）、新的架构上线后架构师及技术人员不断应付开发新的需求和迁移老的需求，疲于奔命，没有精力去整体把控架构，于是将架构的维护权限移交给每一个开发人员

    5）、销售、运营、财务发现与当初承诺的需求不符合，投诉不断；架构师认为已经完成系统架构，剩下的都是开发的问题、产品的问题

    6）、新的架构被否定掉，开发人员们或是离职或是沉沦

    7）、同样的悲剧不断上演

    一个好的架构不是一蹴而就的，没有一个架构是一次性完美地架构出来的，完美架构的诀窍就在于持续维护、持续完善。任何架构都有一个从孕育->诞生->成长->成熟->衰退的演进过程，没有经历风雨的完美架构只能是温室中的鲜花。

    对于架构的持续完善不单纯只是一个技术问题，而是一个研发管理的核心问题，架构的完善应当贯穿于市场管理流程、需求管理流程、产品研发流程各大流程中。对于架构的管理必须有专门的组织机构、流程制度来保障。

    可以说一个好的架构不是架构出来的，而是管理出来的，对于架构的管理体现了一个公司的研发管理能力。

5、参考文档

    Is Design Dead?

    Agile Architecture: Strategies for Scaling Agile Development

    Agile Enterprise Architecture

    The Agile Unified Process (AUP)

© chuanliang for 出家如初，成佛有余, 2010. | Permalink | 4 comments

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under 产品管理, 技术相关.

    一般来说，我对图书的选购都是通过如下一些方法：

    1）、标签/关键词搜索法：如果知道内容的标签/关键词，则在当当、亚马逊、豆瓣上以关键词进行搜索，然后在搜索结果中一条一条遍历，根据评分、评价内容等来判定是否值得购买。

    2）、关联推荐法：通过豆瓣/当当、亚马逊上图书的相关推荐来查找

    3）、分类遍历浏览法：如果不知道明确的标签或关键词，则通过当当、亚马逊分类浏览方式进行遍历查看，然后结合评分、点评内容来决定是否值得购买。

    4）、Web2.0 新媒体法：通过搜索引擎、Twitter、专业论坛、SNS社区以及业务专业人士的Blog等方式，看那些图书被极力推荐。  

    5）、销售榜单法：查看各大网站的销售排行榜单，看那些图书是热销的、评分高的等

    当然这些方法并非完全独立的，各种方法之间很多时候是结合使用的。

    相对于其他方法的优缺点有众多人专业人士在长篇累牍地讨论，销售排行榜的设计问题很少有人谈及，很值得深入思考和讨论，因此记录一下不成体系的思考。

1、销售排放榜作用

    1）、展现网站精品，帮助用户决策

    2）、体现流行趋势，引导用户消费

    3）、作为运营指标，优化运营效率

2、榜单设计

    在几大电子商务网站中，只有当当把排行榜单独出来放在一级导航菜单，并且在排行榜分类上也更多层次、多维度，而其他的网站的排行榜基本上只是简单的分类销售排行榜或是根本没有排行榜概念。或许这些网站觉得销售排行榜毫无价值，没必要像当当那样投入大量精力去优化这一部分的用户体验。

    对我而言，“当当榜”还是挺有用的，通过“当当榜”我发掘了几本不错的图书。相对于以前原封不动抄袭亚马逊而言，当当的这一“原创”做法还是值得称赞的。

    下图是粗略的“当当榜”的结构。

2.1、榜单设计标准

   怎样设计一个好的榜单不是我关心的内容，我比较感兴趣的是：一个好的榜单设计的标准应该是怎样的呢？

   个人觉得，一个好的榜单的标准应该是：多维度、多层次展现网站产品的精品内容，帮助用户快速挖掘出有价值的产品

• 多维度

         所谓多维度是指榜单应当从多个维度来描述榜单产品的内容，满足用户多视角对比需求，包括：   

        1）、时间序列：以不同时间段形式来展现榜单内容，或是不分时间段（累计榜）形式来展现

        2）、Web2.0元素：包括用户评分、收藏数、搜索数、点击数、标签（tag）、用户群、分享数、评论数等

        3）、销售量

        4）、产品类别

        5）、趋势

        6）、产品组合

        7）、专题

        8）、地域

        等等

• 多层次

        所谓多层次是指榜单的展现应该以层次化的形式逐级细化，符合用户由粗到细、由总到分的浏览习惯。

        例如“当当榜”的五星图书榜->历史类->累计榜->TOP50

    整体说来，按照我这标准当当榜做得还是不错的。

2.2、用户体验及产品设计

    只不过在产品设计及用户体验上，“当当榜”尚有许多值得改进的地方，例如：

    1）、各榜单内容只是在“当当榜”才有入口，其实如果各产品详情页面左侧的推荐栏中能够放入当当榜的内容，对于促成用户决策还是很有帮助的。 

    2）、“当当榜”如果能够与诸如各大出版社联合发布图书排行榜，进而成为业内权威的排行榜，对于当当而言也是一种宝贵的品牌资源。

    3）、在目前的EDM中有“当当榜”的链接，但对于大部分人并没有太大感觉，可以在EDM中根据用户兴趣突出“当当榜”对应推荐内容

    4）、“当当榜”可以适当采用一些图形化的形式来展现相关的趋势，这比数字更加直观明了。

2.3、系统榜单 VS.  用户榜单

    目前“当当榜”的榜单内容应该是通过OLAP方式由系统根据模型汇总统计出来的，这种方式姑且叫“系统榜单”。系统榜单更擅长反应系统以往及当下销售的热点产品，在用户互动上并不是很强。

    由于电子商务与社区结合是一种趋势，因此如果能够结合社区活动，以专题、投票、小组等形式推出用户自定义榜单，例如“产品经理必读的十大图书”、“架构师必读的十大图书”等，对于活跃社区气氛、加强与用户互动、促进用户购买还是很有意义的。这一点可以学习Twitter lists的设计理念。

2.4、榜单与推荐系统

    榜单与推荐系统本身并不矛盾，两者的目标都是帮助用户发掘有价值的资源。原来在研究推荐引擎时候一直关注推荐引擎的关联算法、协同过滤算法等机器算法，其实榜单内容既可以作为推荐数据源之一，也可以一定程度上缓解推荐算法的“冷启动”等问题。

© chuanliang for 出家如初，成佛有余, 2010. | Permalink | 8 comments

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under 产品管理, 电子商务.

    由于产品需求管理的需求来源于目标用户所处的市场及行业，因此要从根本上解决需求管理及需求创新的问题，必须回归到市场这个源头寻求答案。

    对于中国的互联网企业而言，在这个山寨化蔚然成风的时代，似乎不用费劲研究怎样洞察市场，反正也没多少原创性的产品，即使有大家也能够快速山寨化，因此大家都在“用户体验层面”寻求核心竞争力。 真的是这样吗？

1、洞察市场与需求管理的关系

    1）、只有能够洞悉和准确把握市场走向，进而把握行业未来的发展趋势，才能够提出具有前瞻性的思想及产品

    2）、只有深刻理解所在行业市场现状，才能够挖掘出深层的用户需求，否则始终只能够被动地满足用户需求

    3）、只有洞悉所在行业的消费者语言及消费者心理，才能够准确把控细节的用户体验

    4）、产品创新必须基于对行业弊端深刻的理解，山寨式的产品研发模式只能够尾随竞争对手而难以超越竞争对手

2、怎样洞察市场

    洞察市场实际上是一个很大的话题，涉及战略层面及战术层面各方面的问题。

    在战术层面前面在统一需求管理及需求收集中提到的各种方法一样可以适用。

    在战略层面而言，战略分析的各种方法的核心目标之一其实就是“洞察市场”，整理一下自认为有效的方法。

2.1、市场管理流程

    在战略层面，要洞察市场，首先要选定自己的目标市场及目标用户，按照IPD的方法论，通过市场管理流程来完成。

    摘自：华为IPD流程管理

2.2、产业链分析（Industry Chain）

    关于产业链分析，可以参考产业链（Industry Chain）。

    对于产品需求管理而言，产业链分析具有如下价值：

    1）、产业链的整体发展趋势是产品战略的重点考虑内容

    2）、产业链各利益相关体的需求是产品需求的重要来源

    3）、产业链解决方案是产品解决方案的重要组成部分

2.3、标杆分析法(Benchmarking,BMK)

    关于标杆分析法可以参考标杆分析法 ，正如文章总结得，标杆分析法的作用如下：

    1）、做竞争对手的标杆分析，有助于确定和比较竞争对手经营战略的组成要素。

    2）、通过对行业内外一流企业的标杆分析，可以从任何行业中最佳的企业、公司那里得到有价值的情报，用于改进本企业的内部经营，建立起相应的赶超目标。

    3）、作跨行业的技术性的标杆分析，有助于技术和工艺方面的跨行业渗透。

    4）、通过对竞争对手的标杆分析，与对客户的需求作对比分析，可发现本公司的不足，从而将市场、竞争力和目标的设定结合在一起。

    5）、通过对竞争对手的标杆分析，可进一步确定企业的竞争力、竞争情报、竞争决策及其相互关系，作为进行研究对比的三大基点。

    实际上国内互联网产业的山寨化现象基本上都有意无意沿用了标杆分析法的核心理念，由于缺乏产品原创的能力，于是乎抄袭国外所在领域标杆企业的成功案例成为最为简单的办法。

3、一些杂思

    1）、洞察市场的先决条件是专注。只有专注于细分市场，持续学习、持续积累，这样才能够成为所在行业专家。但专注绝不是两耳不闻窗外事，一心只关心所在行业的事情，跨界学习其他行业标杆企业也是洞察所在市场的有效手段。

    2）、洞察市场不单纯只是市场、行业BD、销售或产品、技术的事情，“洞察市场，预见未来”是所有公司产品管理的梦想，要达到这一点市场管理流程能否顺利执行就变得至关重要，这是一个公司战略层面必须重点解决的问题

    3）、“同理心”是洞察市场的有效手段，设身处地以一个普通用户的视角近距离观察市场、感受市场

    4）、所谓“当局者迷”，适当跳出所处的市场，与市场保持一定的距离，以旁观者视角从远处观察市场也有助于洞察市场需求。

    5）、Apple、Google式的创新并不是在实验室创新出来的，“Think Different ”必须根植于：对所在市场深邃的洞察力+与市场适当的距离，这也是那些“破坏性创新”者能够创新的根源所在

    6）、“标杆分析法”不是“山寨化”，“标杆分析法”的核心是全方位分析别人成功的根本原因。标杆的成功有其特定的文化、市场、机遇等因素，单纯的山寨并不能复制成功，所谓“学我者生，似我者死”

© chuanliang for 出家如初，成佛有余, 2010. | Permalink | 3 comments

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under 产品管理.

1、需求收集目的

    需求收集的目的在于：通过以市场为导向的客户需求收集，保持公司产品的核心竞争力，最终实现产品创新。具体说来：

    1）、深刻理解市场需求、用户需求，准确把控行业发展趋势，保持高度的市场敏感度。

    2）、保证产品研发是围绕客户需求来展开，真正实现产品研发“以市场为导向、以客户为中心”，而不是闭门造车。

    3）、实现产品创新。通过有创新性的新卖点、新产品的持续不断推出，保证公司产品核心的竞争优势

    4）、及时获得竞争对手相关产品及市场策略，做到“知己知彼”

    5）、通过需求收集等相关活动，有机串接市场营销部门与产品研发部门，建立跨职能部门、端到端的流程进行需求开发

    6）、加强与用户互动，提升用户忠诚度及粘性

2、需求收集指导原则

    互联网并不缺少用户需求，恰恰相反，用户需求泛滥。面对市场上众多的“需求”，那些才是真正的用户需求呢，那些需求符合公司的产品战略要求呢？

    需求采集的指导原则：

• 以公司的产品愿景、产品战略为指导

       产品愿景及战略决定了：需求采集应该面向那些细分的目标用户群，而非普遍撒网；对不同的用户需求进行优先级排序出现需求冲突时候取舍的标准；确定能实现或者不能实现的需求；

• 以用户欲望为准绳，给用户带来“价值”而非“功能”

3、需求收集方法

1）、建立需求收集机制：明确每个需求收集活动参与者的岗位职责、建立需求预处理流程、周期性的重复需求收集活动

2）、使用统一的需求收集系统

3）、采取一定的需求收集技术和方法

  关于需求收集的方法，如何做好需求收集 这篇文章讲解得比较详细，可以参考其内容。

  用于需求收集的常见手段包括：

• 原型法
• 头脑风暴
• 用户访谈法
• 问卷调查法
• 标杆分析法
• 观察不期而遇的用户
• 各种会议（如用户大会、展览会、学术研讨会等）
• 现场支持
• 和支持团队（运营团队、技术支持团队）谈话
• 客户热线
• 客户满意度调查
• 用户行为分析
• 合作开发

一些思考：

1）、需求收集应该收集用户真正面临的问题和业务场景，这样才能够捕获用户真正的需求，而不是只盯住用户提出系统需要实现什么样的功能，“需求收集”不是“需求汇总”。

2）、用户要的是产品的“价值”，而非产品的“功能”。只有当一个产品功能真正帮客户解决问题，这个功能才具有价值，也才真正有“功能”。

3）、需求收集流程要真正发挥作用，必须在组织层面通过组织管理制度及绩效考核制度来保证，将需求收集纳入到各相关部门的绩效考核中。不能指望大家三分钟的热情。

4）、需求收集流程的执行情况是一个公司管理是否规范的试金石，也可以衡量一个公司是否真正“以市场为导向、以客户为中心”。

5）、需求收集既要避免“什么都要做”的冲动，又要避免“只关注当下需求”，核心根源还是在于产品战略是否清晰。

6）、常规的需求收集手段并不能够解决产品创新问题，但如果没有持续的需求积累，创新就无从谈起，创意的灵光源于专业。

7）、尊重竞争对手和用户。竞争对手和用户并不像我们想象的那么愚蠢，以自己的标准来度量别人的产品才是真正的愚蠢。很多时候我们从自己的预设立场出发，否定掉了众多创新机会。对竞争对手，我们应当首先成为其产品忠实用户；对用户，我们应当通过用户社区等互动手段来“倾听用户的心声”。

4、需求收集理论模型

4.1、$APPEALS：收集市场需求的工具

    $APPEALS方法是IBM在IPD总结和分析出来的客户需求分析的一种方法。它从8个方面对产品进行客户需求定义和产品定位。

• $-产品价格（Price）
• A-可获得性（Availability）
• P-包装（Packaging）
• P-性能（Performance）
• E-易用性（Easy to use）
• A-保证程度（Assurances）
• L-生命周期成本（Life cycle of cost）
• S-社会接受程度（Social acceptance）

  关于$APPEALS可以参考 $APPEALS市场需求和产品定位工具 

4.2、客户满意度模型（Kano模型）

    KANO模型定义了三个层次的顾客需求：基本型需求、期望型需求和兴奋型需求。这三种需求根据绩效指标分类就是基本因素、绩效因素和激励因素。

    基本型需求：顾客认为产品“必须有”的属性或功能。当其特性不充足（不满足顾客需求）时，顾客很不满意；当其特性充足（满足顾客需求）时，无所谓满意不满意，顾客充其量是满意。

    期望型需求：耍求提供的产品或服务比较优秀，但并不是“必须”的产品属性或服务行为有些期望型需求连顾客都不太清楚，但是是他们希望得到的。在市场调查中，顾客谈论的通常是期望型需求，期望型需求在产品中实现的越多，顾客就越满意;当没有满意这些需求时，顾客就不满意。

    兴奋型需求：要求提供给顾客一些完全出乎意料的产品属性或服务行为，使顾客产生惊喜。当其特性不充足时，并且是无关紧要的特性，则顾客无所谓，当产品提供了这类需求中的服务时，顾客就会对产品非常满意，从而提高顾客的忠诚度。

    一旦每个需求都得到了明确的分类，就能够在需求收集过程对需求进行优先次序排序。

    关于Kano模型的详情，可以参考kano模型  及 需求入门 － 用Kano模型来确定需求优先级

4.3、层次分析法（AHP, Analytic Hierarchy Process)

    在做需求收集时候，最为麻烦是确定用户需求的优先级，利用层次分析法（AHP, Analytic Hierarchy Process）可以从不同的方面（如重要性、风险、成本）等角度去比较每两个用户需求之间的优先顺序。

    层次分析法将决策总是有关的元素分解成目标、准则、方案等层次，在此基础之上进行定性和定量分析的决策方法。这种方法的特点是在对复杂的决策问题的本质、影响因素及其内在关系等进行深入分析的基础上，利用较少的定量信息使决策的思维过程数学化，从而为多目标、多准则或无结构特性的复杂决策问题提供简便的决策方法。尤其适合于对决策结果难于直接准确计量的场合

    在IBM Rational Focal point中提供了层次分析法对需求进行排序。

4.4、四象限定位法

四象限定位法以需求的急需性作为横轴，需求的重要性作为纵轴，可以建立如下的消费者需求四象限图：

具体内容可以参考 四象限定位法

当然还是其他的一些方法，例如：Delphi方法、亲和图法（Affinity Diagram）等

5、创新产品的需求收集：你是否有自己的idea bucket？

    对于众多颠覆性创新的产品，其核心的创意很多时候与现有产品的需求及要求是相互矛盾的，因此这些创意是不可能完全依赖现有产品的需求收集过程得出来。

    当然任何创意也不可能从空而降，这些创新性产品之所以能够脱颖而出，根本原因还是在于这些产品经理们对于所在行业的用户真实需求及痛苦之处有深刻的了解，然后“Think Different”。别的产品经理们在审视收集的各种需求时候把这些创意作为“不靠谱”的需求而过滤掉了，而这些创新产品的产品经理去把这些需求作为一个创新的机会来把握住了。

    因此创新产品的需求仍然可以收集，只不过相对于普通产品的需求收集过程，我们在标准上应当更加开放。在需求收集平台中，我们应当单独留出一个创意桶（idea bucket），专门用于收集、汇总各种产品需求、创意、设想等，并定期在公司层面回顾这些创意，以发掘产品创新的机会。

    前面的Kano模型也经常用于产品创新领域。

6、常用需求管理软件

  除了使用自行开发的软件来实现统一需求收集外，一些常用的需求管理软件也可以用于类似场合：

    IBM Rational Focal Point

    IBM Rational Requisite Pro

    IBM Rational DOORS

    Jira

    Borland Caliber RM

    其中Focal Point用于需求收集是最为合适的工具。

© chuanliang for 出家如初，成佛有余, 2010. | Permalink | 4 comments

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under 产品管理.

     关于需求管理的故事很多,列举一些常见问题：

• 某天老板问起：我很久以前提过一个需求，提过以后就没下文了。产品经理无辜地说：有提过吗，是给我提的吗？
• 某个销售谈起：我很久以前提过一个需求，当时被产品否掉了，觉得不重要，现在竞争对手就靠此功能赢得了众多客户。产品经理无辜地说：当时是被否掉了，但你后面再没有提过，因此在后续产品开发中当然没考虑此需求
• 某天老板提起：某个产品的某个功能很不错，于是乎大家加班加点地开发实现了类似功能。等到产品开发出来后才开始找客户、找卖点。
• 销售们抱怨：产品人员、开发人员闭门造车，只关注技术，不关注客户需求。产品及技术无辜地说：销售人员根本描述不清楚需求，我们已经按照他们需求开发出来了，他们还是不满意。
• 销售人员只管销售目标的完成，客户反映的信息不能传递到产品及技术部门。研发部门主动到销售人员那里了解市场信息时，他们往往说：“我只管销售，你先把产品拿出来再说”
• 某个客户在社区里投诉：xx产品的xx功能做得太差了，已经投诉过几次都还没有改善；但产品及技术无辜地说：他这功能相对于其他产品功能优先级很低，因此暂时不考虑
• 竞争对手某个杀手级产品的功能其实以前公司很久以前就做了，但后来没有持续完善，导致“起了个大早，赶了个晚集”
• 某个产品越做越大、越做越乱，直到有一天无法维护时候整理产品功能才发现，里面有一堆乱七八糟的需求，这些需求怎么来的、现在哪一个客户在使用此功能，谁都不知道
• 公司层面产品相关利益者都参加的需求收集会议也开了很多次，但大家对于产品需求的理解还是没有统一
• 与竞争对手的产品比较，产品功能比竞争对手全面多了，但还是竞争不过竞争对手的产品
• 某个产品离职了，大家才发现，对产品最熟悉的人只有这个产品经理，没有任何文档及功能说明，有的只是网站页面和代码

   对于大部分互联网公司而言，都意识到了产品管理的重要性，因此都有相应的产品管理流程，但为何以上问题仍然屡见不鲜呢？

   以上问题的根源在于：

    1）、没有对各种需求有效地分层分级，对不同阶段需求的目标没有明确的定义

    2）、没有建立一个横跨市场和产品研发部门的组织机构来统一负责收集市场需求，并将其传递给产品研发团队

    3）、缺少完备的需求收集、汇总、分析机制，“公司神经末梢与大脑失去联系”；

    4）、没有建立一套跨部门的端到端的业务流程来指导市场需求收集与传递工作

    5）、没有一个客户需求分析工具来指导系统性地收集客户需求

1、互联网产品需求来源

    一提到需求管理，产品人员及技术人员都会异口同声地说：软件需求管理，我们有啊。我们的软件开发过程遵循CMMI3、RUP、XP、SCRUM等开发过程，需求管理是我们进行开发的最重要阶段。

   我们这里所指的“需求”不单纯只是技术术语的产品需求、软件需求，还包括：

• 客户所想所需：Needs、Wants
• 市场需求
• 产品包需求：Offering Requirement 
• 产品需求
• 开发需求

   相对于传统软件开发过程，互联网企业的需求管理来源更加多样化，包括：

  1）、外部来源

• 客户需求：客户在使用产品过程中所提的建议和意见；以及通过客户访谈等手段得到的需求
• 竞争对手产品分析：直接作为竞争对手产品的客户试用，获得竞争对手产品相关信息
• 社会化媒体：搜索引擎、IM、BBS、Blog、SNS社区、Blog、Twitter、百度知道等社会化新媒体
• 传统媒体/竞争对手软文等
• 合作伙伴
• 行业分析    

    一些竞争对手分析的手段可以参考 电子商务企业竞争情报分析工具

   2）、内部来源

• 公司产品战略
• 客服人员：包括呼叫中心（电话、短信、传真、邮件等）、在线客户（IM、BBS、留言板、WebCall等）
• 运营人员：所谓互联网产品是运营出来的，任何成功产品不可能一蹴而就。公司内部运营人员在运营中产生的需求是重要的需求来源渠道。
• 市场营销人员
• 销售人员
• 财务人员
• 技术支持
• 网站用户行为分析：包括网站用户购买行为、点击流等

2、统一需求管理的意义

  由于需求来源的多样化，就要求在公司层面对需求进行统一的管理，以保证能够：

  1）、建立端对端的需求管理流程，实现技术与市场的无缝结合。

  2）、深入理解行业，成为行业专家：对于互联网企业而言，必须深刻理解所在行业的特征及行业用户的痛点才能够推出有竞争的产品，因此必须首先成为所在行业专家。产品需求本质代表了行业用户的需求，通过产品需求的持续积累，可以加深对于行业理解，从而成为行业专家，能够推出更符合行业需求的产品

  3）、知识的传承：通过对需求持续统一的管理可以保证知识的传承，避免产品需求知识积累在几个人脑袋里。

  4）、主动收集需求，准确把握市场机会点

  5）、产品创新：通过产品及产品间原有需求的优化、借鉴、组合等手段来达到产品创新的目的。

我们这里的所说的“统一需求管理”比RUP中的更为宽泛，包括：

• 公司层面统一的需求管理组织支撑体系
• 公司层面统一的需求管理流程制度
• 公司层面统一的需求管理工具

4、怎样实现统一需求管理

  在实现公司层面需求统一管理，华为及IBM所采用的IPD过程很有借鉴意义，核心思想在于：

  1）、组织支撑

    通过建立一个横跨市场和产品研发部门的组织机构来统一负责收集市场需求，并将其传递给产品研发团队

  2）、端对端的流程

   所谓“端到端流程”是区别于职能式的产品开发模式，建立的产品开发流程是跨部门的、关注业务实现的、客户到客户的业务流程。企业中与产品需求相关的主要有三大流程体系：市场管理流程、产品开发流程、需求开发流程。在市场管理流程的第一阶段（了解市场阶段）、在产品开发流程的第一阶段（概念阶段）都会定义客户需求的收集活动，用需求开发流程来支撑需求收集活动。

可以参考：华为IPD流程管理 

5、统一需求管理一些思考

   1）、所谓“工欲善其事，必先利其器”，一个好的需求管理工具对于需求管理有很大帮助。但工具不是万能的，关键还是使用工具的人，因此不用整天寻找完美的工具，而是要问一下自己：对于工具的使用热情我们能够坚持多久？

   2）、工具本身并不能解决需求管理混乱的困局。核心问题还是需求管理的方法论、流程制度是否能够持续完善。成功需求管理的秘诀之一就是：持续积累、持续完善。

   3）、我们很多时候忙于开拓新的市场需求而忘记了总结的价值。与客户、市场、销售、产品、技术、运营等相关人员定期对积累的各种需求（不单纯只是产品需求）进行“requirement review ”（类似于“cod review”），可以碰撞并挖掘出许多有价值的产品需求及卖点。

   4）、对于运营型企业而言，各种行业需求的持续积累是企业最为宝贵的财富之一，也是产品创新之源。因此应当把持续的需求积累提升到公司战略层面。

© chuanliang for 出家如初，成佛有余, 2010. | Permalink | One comment

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under 产品管理.

1、为什么需要“产品平台”？

总结一下常见的产品研发常见问题，由此可以看出平台化的重要性。

1.1 产品问题

• 产品规划不具有前瞻性、整体性，不断推倒再来
• 缺乏有效的需求积累机制
• 不断变化的需求，产品生命周期相对短暂，很难产品化
• 产品线产品间没有复用，同样的功能重复开发

1.2 研发问题

• 系统属于不同研发团队开发维护，系统异常庞大、复杂，没有人能够完全明白
• 用户界面异常复杂、凌乱，易用性很差
• 开发周期很短，短迭代、快速上线，文档很少、质量没有保证
• 缺乏公用组件，缺乏知识积累和共享机制
• 技术研发与产品研发没有分离，缺乏技术研发体系

1.3 运营问题

• 没有统一运营平台，每个系统都有自己一套运营系统
• 有统一的运营管理系统，但缺少统一规划，运营系统异常复杂，开通一个用户需要经过10多步
• 运营以处理客户投诉为主，没有做到客户运营

1.4 管理问题

• 缺乏有效的考核和激励机制
• 缺乏有效的培养机制，研发人员职业素质不足
• 不同产品线及职能部门间跨部门协作很难

2、产品平台

  “产品平台”不单纯只是产品术语或是技术术语，要达成“产品平台”目标，必须在运营型互联网企业的市场、营销、产品、技术研发、运营、管理等多个环节以平台化思路来建设，包括：

• 市场营销平台化
• 产品平台化
• 技术平台化
• 运营平台化
• 管理体系化

© chuanliang for 出家如初，成佛有余, 2010. | Permalink | No comment

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under 产品管理.

    再打电话投诉，仍然一直是忙音。打了2个多小时，打了30多个电话后，终于打通了。把情况一说，客服人员很流利地说明了原因：他们自己系统是有问题，与去哪儿合作的合作页不是实时刷新的，因此在下单时候成人票的价格在他们平台上是1080，而不是860元，要避免此种情况，最好在下单前在他们平台再查询一下实时价格。从客服的解释来看，以前应该也遇见很多这样的问题，很奇怪明知有问题，为何一直不修改，只好退票。退票时候，客服人员问银行账号，而且建议最好是工行的账号。很奇怪，问她：不是通过快钱支付的吗，你直接给我退回我的支付行就行了。客服说不行，如果不用工行而用其他银行账号，退款退回时间不确定。

    懒得再一家一家地比较，担心再出问题，于是直接在去哪儿上比较了一下进行直销的航空公司的价格，找了相对便宜的南方航空下了单。在这过程中，暴露了很多问题，包括：

    1、合作商户系统与平台对接时候信息同步、实时性问题

    2、合作商户系统本身存在很多问题

    3、合作商户本身服务的能力、服务规范性及服务质量

    4、平台服务体验的一致性问题

    5、平台对合作商户资质的选择

    这些问题归根结底可以概括为电子商务平台服务问题，以上问题能否有效解决影响着一个电子商务平台的成败，总结一下零碎思考的一些内容：

1、平台服务的边界

   对用户而言，在购买机票过程中涉及两个比较大的电子商务平台：去哪儿的机票比价平台、快钱的支付平台。在两个平台作为这些商户的平台服务提供商，理论上只需要能够为这些商户提供好所需要的各种服务就行，合作商户以上的各种问题让合作商户自己搞定就行，不能归结为平台的问题。

   但对于最终用户而言，在使用服务过程中出现的各种问题都是平台的问题，他并很不清楚这些系统的边界，他只关心能够通过平台低成本、便捷、安全享受各种服务。如果合作商户不能为客户提供优质的服务，那平台本身的价值也打了很大的折扣。平台要保证服务的一致性，要维护平台核心的价值，就应该树立平台的服务标准，用这些标准来要求商户并帮助合作商户从各个层面上进步。合作商户的高度决定了平台的高度。

    因此作为一个平台本身，在考虑平台建设时候，我们不应当只是盯住平台本身的边界，平台的边界的划分应该以用户视角来看，以保证用户以一致性的体验完成整个购物过程。这就要求平台的合作商户的选择、合作商户服务能力、合作商户系统等问题上必须以平台化的要求来执行，对达不到平台化要求的，或者帮助其进步、或者淘汰。   

2、平台服务的核心价值

    对于合作商户而言，如果平台只是单纯作为一个销售通路或营销通路，那平台给合作商户带来的价值并不是持久性的，可替代性很高。尤其航空公司们的直销业务在整个机票分销业务中比重愈来愈大的情况下，这些合作商户凭什么生存呢？

    这些平台服务提供商肯定不希望合作商户在航空公司们的电子商务直销浪潮下消亡掉，在平台上面只剩下几个有限的几个航空公司。平台合作商户的多样化、差异化才能够保证平台对于最终用户的吸引力，也才能够保证平台持久存在的价值。

    在面临日益剧烈的竞争下，平台服务对于合作商户的核心价值在于：通过平台来帮助其提高竞争力。这种竞争力包括服务能力、盈利能力、营销能力、服务的持久性等。

© chuanliang for 出家如初，成佛有余, 2010. | Permalink | No comment

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under 产品管理, 电子商务.

    如果我是Evernote的产品经理，我会怎么做呢？总结一下文章的思路：

1、聚焦核心定位：

    相对于Onenote，Evernote作为一个尾随者，在市场影响力及可以利用的资源上都无法与Onenote相匹敌。因此首先最重要的是要时刻遵循自己区隔于Onenote的核心定位："Notes rethought in Web 2.0"。要找到自己区隔于竞争对手的产品定位很容易（什么定位理论、竞争分析、蓝海理论等满大街烂遍的理论都能够完成），最难的莫过于对产品定位信仰般的坚持，莫过于在定位下对产品功能取舍的平衡及度的把握，莫过于在小有成就后能够压抑住自己进行产品延伸的冲动。

2、改变游戏规则：

    要在与Onenote的竞争中占领上风，依靠比拼功能及用户体验的方式并不能颠覆竞争的格局。一个有效的策略就是所谓的“颠覆性创新”，既然Onenote是收费的、闭源、封闭的，那Evernote可以通过开放平台、Open Source、免费方式来改变游戏规则，让对手不得不放弃其业务核心来遵循你的游戏规则及节奏。Google的「比免费更便宜」的商业模式 可以说是当下最为经典的案例。

3、“抄越”竞争对手：

    有一个强大的竞争对手有时候其实也是一种福气，至少说明市场的价值、机会以及事业的意义。强大的竞争对手是最好的老师，在聚焦核心定位、改变游戏规则的前提下，认真研究学习、抄袭竞争对手优秀的产品功能、用户体验、设计思想，山寨化之并超越之（谓之“抄越”）。虽然我们都在研究竞争对手的产品，但我们缺少对于强大竞争对手的“战略上的藐视，战术上的重视”，更多时候只是处于藐视或自卑的状态，因此基本上只是停留在功能copy层面，并没有用心去领会竞争对手产品的核心设计思想，因此所谓的“抄越”也就无从谈起。

    正如文章所说：I’m hoping Evernote wakes up, assigns at least one developer full-time to analyze what OneNote did right in usability, run their own usability tests with students, and get Evernote to be the best client-side note-taking experience in the world.

4、集中优势资源打歼灭战：

   要集中优势资源对核心产品功能（包括用户体验）进行研发并做到极致，不要将宝贵的资源投到非核心的功能完善上去。产品有了自己的核心优势后才可能有机会将游戏继续下去，“少即是多”。  

5、更加注重与用户的互动，倾听用户的声音

   对Evernote而言，拥有这样忠实且专业的用户是最为宝贵的资源，希望Evernote真的能够醒醒倾听用户的心声。

   通过与用户的互动及对用户的运营，可以获得第一手的用户需求，保证产品竞争策略的有效性。其实任何产品都有这样用户，只不过很多时候我们太过于自负或是过于忙碌，而最终忘记了产品最终的用户是谁。

   写到一半才发现这些道理大家都知道的，懒得写下去了。可为何一家又一家的公司都在犯着同样的错误呢？“纸上得来终觉浅 绝知此事要躬行”。

© chuanliang for 出家如初，成佛有余, 2010. | Permalink | 11 comments

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under 产品管理.