敏捷开发产品管理系列之1-14

敏捷开发产品管理系列之一：序言及设立迭代目标敏捷开发产品互联网活动工作目录(?)[+]本文是敏捷开发产品管理系列的第一篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，ProductServant，ProductOwner团队，产品线管理）序言之前的“敏捷开发用户故事系列”已经提到了微观层面的需求管理问题。由于敏捷开发的提出者和实践者主要是开发团队及其领导，因此一般较少提及产品的整体规划、商业目标这些内容。本系列汇集了本人在做产品管理的时候的一些心得，以及在与不同企业交流、做互联网软件分析的时候的一些所得，与大家分享。本系列的顺序整体由微观到宏观排序，拟包括设立迭代目标，产品版本规划，新产品研发，ProductOwner团队，产品线管理等话题。为何设立迭代目标之前笔者的博客中曾经两次提到关于迭代目标设立的话题。基于版本规划的迭代目标一次是关于“迭代期内无变更”，即由于产品应该预先设定商业目标和客户群，因此整体版本规划也应预先设定，进而可以分解出相对稳定的迭代目标。若能完成上述工作，则迭代期内尽管有微弱的变更，但迭代的总目标不会发生大的变化，从而保证迭代期内整体开发内容的稳定。基于故事群的迭代目标第二次则是提到用户故事的组织时，引入了“故事群”的概念，即某个迭代不应该简单地开发“当前最重要的功能”，因为万一这些最重要的功能零散地分布在不同的业务模块中，开发者就要同时面临同步了解多个业务模块的困境，前来评审的客户也会有如瞎子摸象一般只能看到多个局部的一角。相对容易开发的方式，是在一个迭代中，应该安排相关的一组故事，从而将开发和评审的焦点都集中在一起。这样开发出来的产品也不完整，但却相对完整地交付了一部分功能，比之零散功能还是更有价值。上述两种方法，一种基于外部的商业目标，一种基于内部的开发方便性，但都指向相同的结果。怎样设立迭代目标会前准备迭代目标是提前设立的，早于计划会，甚至早于ProductOwner将有开发意向的Backlog条目计划到迭代中。它实际上在做产品版本规划的时候，就应该捎带着被完成了。它常常是一句简单的描述，如“一个能登陆和显示故事列表的版本”。在迭代计划会之前，ProductOwner会审视这个迭代的目标，从而决定将哪些故事置于本迭代中开发。事实上，若已经设定了多个迭代的目标，ProductOwner应该会同开发团队骨干，为未来2～3个迭代大致分配所需的用户故事，而不是赶在当前迭代前才匆匆分配。这个活动有利于开发团队骨干提前了解未来，从而在架构上做一些准备。长期存在的一个难以平衡的问题是：若在架构上做了过多的准备，若中间发生变更乃至放弃某些功能，这些准备会浪费；若架构上准备不足，不断迎来新功能又会导致过多的“重构”发生，也会造成浪费。为多个迭代设立目标可以有效地帮助开发团队做出切合实际的架构准备，将浪费降低到最低点。会后核对在计划会上讲解故事、估算故事后，事情常常有所变动。这时候要从已经计划要开发的故事总结一下看看，是否与原来设定的目标相符。开发中跟踪在日常开发中ProductOwner常常提出变更，若变更符合目标甚至能更好地达成目标，则应该被积极地接纳；若背离了目标，则应该缓做或重新考虑。若“被激励”的程序员有了奇思妙想的时候，团队同样应该冷静地思考，做出判断。“拥抱变化”与“迭代期内无变更”的矛盾其实向我们揭示了敏捷开发中的一个重要原则：变化的是路径，不变的是目标。为每个迭代设立目标，非常好地让我们能够遵循这一点。敏捷开发产品管理系列之二：产品版本规划本文是一篇旧文，原名为《“迭代期内无变更”与敏捷开发产品版本规划》，因符合本系列内容，做相应修改后重新编排发出。迭代期间无变更？支持派说：对，如果经常变，我们怎么开发啊。反对派说：不对，敏捷开发不能上来就确认了需求，要的就是在开发中逐步了解需求，怎么可能不变呢。只在开发层面，这个问题无解。让我们站在产品版本规划的高度来看这个问题。基于商业目标的产品版本规划下个产品版本（或下个迭代）中到底应该有什么功能？最重要的功能？最基础的功能？当前可能实现的功能？已经弄清楚的功能？这些角度都是基于技术活动而非市场目标来制定的，都有其局限性。其实，每个产品的版本都是企业的一步棋：在某个时间，推出某些功能，满足某些需求，获取某些客户，打败某些对手，取代某些产品。若认同了这一点，则早在产品版本规划的时候，就应该确认此版本中应该大致包含哪些功能，而非到迭代计划会议或迭代中才会确认，更不会在迭代中间发生变化。这样看来，“迭代期间无变更”指的是：“不应该到迭代开发已经开始了还没明确要开发什么功能”（What问题）；而不是：“应该在迭代前把需求弄明确，一旦开发了就别改动了”（How问题）。产品版本规划步骤图产品立项-------------------------------------------在这个时候大致规划出路线图，走多远，多久，走到哪里V1.0---------------------------------------在这个时候明确规划处这个版本要做哪些功能（未必到达故事点的粒度）Sprint1计划会---------------------------------在这个时候达到故事点的粒度，且从技术角度思考可以先做什么后做什么日常工作-----------------------------细化做成什么样子，随时可以变，但基本不会大量扔掉或换掉什么功能了Sprint2计划会……SprintRelease-----------------------在这个时候，无论技术顺序的先后，所有V1.0的功能都做完了V2.0---------------------------------------根据市场反馈，调整产品路线图V3.0---------------------------------------继续从这一点上，敏捷产品版本规划的目标与设定迭代目标的初衷相同：在“事先计划防止返工”与“随机应变防止想太多没用上”之间找到平衡，降低浪费。敏捷开发产品管理系列之三：产品用户群规划产品敏捷开发工作互联网windows游戏目录(?)[+]上周在培训做“用户故事的用户建模”练习的时候，就有人提出一个疑问：这么短的时间里边，能定义好用户群和用户群分类吗？答案是：不能。用户群的规划是产品概念期就应该完成的工作，它是一个产品管理工作，而非需求管理工作。用户群定位这里仅就自己所从事的互联网行业提出一些简单看法。这些看法与本人在做的产品密切相关，因此在别处可能会不适用，仅作参考。我们整体把用户分为人气用户和付费用户两种。这个与互联网通行的分类方法很接近，相信很多企业给产品用户的分类也是如此。那有什么可谈的呢？因为若不把用户群定位的想法仔细写出来，产品做起来容易走样。在传统行业乃至传统软件行业里边，用户基本上就一种：付费用户。你不买我的产品，就不会用上我的产品，我们基本上没有任何关系。这个分类的弊端在于：所有风险都压在用户身上，付费后一旦证明选择是错误的，后果自付。这件事情造成几个问题：1.用户付费前犹豫不决，售前和销售成本很高，造成销售和售前人员甚至多于开发人员2.用户如果不满意，因其损失很大，会产生很大的负面作用所以（限于商业秘密写得很模糊）：1.人气用户负责做免费的市场工作，消除售前和销售成本。这要求在给人气用户准备的免费版本里边做好一些工作：免费，简单，上手快，能互动点评，能传播，能试探性使用付费产品……2.人气用户中的一部分将成长为付费用户，用于提供销售额。这要求给付费用户的的版本里边做好另外一些工作：从免费版直接升级，包含具有财务决策权者所用的功能（升级购买动机），快速的合同和付费渠道……太细节的内容不方便说，这里点评一下“快速的合同和付费渠道”，其目的是有效降低售前成本。“快速”有多快？点一个按钮，网上付账，电子格式化合同，自动发送许可，结束。“客户连人都没见到，肯付费吗？”如果不肯，就说明我们的免费版本做得不够好，或他作为人气客户期间还没有获得足够的信心。我们会在免费版本中做得更好，消除其疑虑，而不是动用销售人员。这一点同时也就是规划好了“免费版本”到底要做成什么样子，它不再只是一个“功能相对简单，许可受限”的产品，而是赋予其“完成售前信心建立”的使命；这两个目标下产品的定位截然不同。再说就到核心商业机密了，大家自悟吧，呵呵。不同阶段用户群的变化产品在长达10年的生命周期中，不同阶段会接触到不同的用户，会产生另外一个维度的划分。大致如此：1.粉丝用户无限认同产品理念乃至认识产品开发者的用户。介意产品风格与内涵，不介意易用性。会提出大量意见甚至多数意见都是他们提出的，但是其追求的并非大众化的功能，而是具有很强的价值观取向的功能。对待这些用户在早期应积极响应，形成影响力；中期应审慎对待其需求，防止产品走向极端。2.试探性用户有新东西就会尝试，但是本着实用主义精神，因而缺少耐心的用户。因此中期产品的易用性和易上手性非常重要，否则过不了试用关。3.大众用户不爱尝试，受到以往用户的影响多于自身的体验感受，纯实用主义者。易用性和标准性非常重要。所谓标准性，就是产品具有相对一致的用法，因此很容易搜索到，很容易培训大量用户。大众用户的数量庞大，必须利用粉丝、试探性用户形成的知识对其进行市场、销售、支持活动。这句话什么意思呢？去游戏网站转转就知道了，各大游戏网站的BBS区都不是由游戏公司的人负责回答问题的，而是广泛发动粉丝、试探性用户对大众用户提供支持。因此末期产品的产品本身与其外围支撑系统浑然一体，比如QQ，比如360，点着点着，你已经分不清楚到底自己在产品里边，还是产品的支撑系统（就是老观念中的“帮助文档”）中了。非互联网行业也大致存在类似的过程，如微软为粉丝用户做了DOS（相当难以普及，因为操作复杂，但绝对有人用），为试探性用户做了Windows3.1/3.2（非常容易上手），为大众用户做了Windows95（从此之后的界面就没怎么大的改动过），完成了其“每个人电脑中安装着MS操作系统”的商业计划；但随着Win95/98装机量上升后，后面的产品就越来越不知所云了。因为“每个人……”的用户群计划已经完成，而新的用户群计划是什么呢？没有，所以才有Win7大战XP这样的内战出现。配套商业模式为配合这样一个产品的规划，很多配套的商业模式也要随之产生。这里不方便说太多，但无外乎：免费，长尾，集合器，生产者与消费者合二为一，半成品思维，无重经济……这些常见的互联网策略。当然要把这些内容落实到实际工作，每个企业都要付出很大的努力。抛开用户群谈产品规划是空谈，用户群规划是敏捷产品管理的起点。用户群定位的方法很多，有空间方面的，也有时间方面的。但其目的只有一个：理解应该做出怎样的产品及版本，才能赢得这些用户，达到商业目的。敏捷开发产品管理系列之四：新产品研发目录(?)[+]这里所指的新产品研发，不是指自己企业的新产品，而是特指那种在行业中初创，前途不明，尚需市场检验的新产品。敏捷开发可以在很大程度上帮助这种产品的开发过程。新产品的第一要务策划新产品的第一要务是：谁会买这种产品？为什么？开发新产品的第一要务则是：它与以往产品的核心差异是什么？这个听起来不难理解，但是做起来有困难。因为一般产品开发往往是先做“最重要的功能，最基础的功能，最影响架构的功能”，这很容易在很久以后，才能看到产品的核心差异。因此，虽然不可能完全脱离重要性、基础性、架构性的制约，但仍然应该常记：验证与市场上以往产品的核心差异是第一要务。新产品研发如何快速体现核心差异（一般是创新性的价值观），是新产品研发的中心。具体做法很多，下面举一个例子。曾经有一家游戏企业，希望能用“广种薄收”的方法来做新游戏。但是发现每个游戏上来都要做可视化、用户登录、商店、NPC、场景、帮派……这些基本功能，所以经常游戏开发开始很久了，还看不出游戏“好不好玩”这个最重要的核心。这就极大地制约了人才、资金的流动性。后来他们决定：开发一个基本平台完成上述基本功能，任何团队拿到这个平台，直接在其上开发“核心玩法”，在规定时间