上篇敏捷产品管理的开篇我跟大家讲了瀑布式开发和敏捷的区别，以及在敏捷的环境下 PO 这个角色如何快速转型，这要求PO不仅作为产品创新的守护者，还要保证让团队成员提供更多的想法，参与到整个决策的过程中。那么，怎么让团队成员在保持目标高度一致性，快速响应变化的同时不脱离产品线路，充分激发大家的创造性呢 ？作为 PO 怎么在敏捷的实践中带领团队成员共同将愿景执行到底？那从今天跟大家讲如何描绘产品愿景开始，之后的几篇我将全线路的带大家一步步深入实践。
Scrum 方法整体路线图
愿景
愿景是描述了项目的发起原因以及预期的最终状态。
—施瓦伯《scrum敏捷项目管理》
我眼中的愿景，其实就是能够见到未见事物的艺术。未见事物决定了我们脚下的方向。而产品的精髓就是通过进行粗粒度级别的选择性描述这一简约方式激发大家的创造力和执行力。
看到此刻，有的同学会说，我一直有在项目开始的阶段，描述产品愿景。那我请你此刻试着回忆下你现在或以往的产品愿景，它是否能很好的回答以下几个问题：你的产品是什么？是否有共享目标？产品将来应该是什么样？用户是谁？竞争对手是谁？如何满足用户需求并超越竞争对手？这样的愿景如何提升创新进程？
我常见看见刚接触描绘产品愿景的 PO，一上来熟练的套用着以下公式来”一键生成”产品愿景：
今天，当【用户群】 想要【期望的活动/结果】时，
他们必须【当前的解决方案】 。
这是不可接受的，因为【当前解决方案的缺点】。
我们相信有【一种体验/一个场景/一项服务/…，是令人向往的】，
我们通过【技术/方法】达成它。
这种”一键生成”的产品愿景看下来是没什么问题，能帮助我们思考产品是什么，是否解决了核心问题。但是我想说的是在描绘产品的初期，我们还是需要深入了解一个好的愿景要具备的素质、客户属性和产品属性分别代表什么，然后通过创立愿景的技巧最终描绘出产品愿景。只有当你充分了解了这些，你才能描绘出从战略出发，颗粒度适中，既能统一目标，又能发挥大家创意的愿景。接下来我就跟大家从这几个方面一一展开。
好的愿景具备的质量
1. 共享和统一
参与开发工作的每一个团队成员都应该拥有一个共同的愿景，它可以提高团队的工作效率并促进团队成员学习，只有当产品负责人和团队成员拥有一个共同的构想并且能够承诺他人也能共享的时候，我们就拥有了一个共享的愿景，而拥有一个统一的愿景需要团队所有人员的参与和展望。
2. 广而专
这个愿景粒度标准既要刚刚好能够指导开发工作，又能为创造性工作流出足够的空间，还要鼓舞人心。这要求产品负责人的“克制”，抵制诱惑，不要在愿景里添加太多的描述和细节，可以在产品 Backlog 中发现并捕捉到更多的功能。
3. 简短而清新
对于产品愿景来说，少即是多，它应该只包含对产品成功至关重要的信息。永远记住，一鸣惊人的产品一般不会有超过6个以上的产品属性。它不是特性清单，也不应该出现无意义的细节。想出很多的功能不难，难在从中只能选出3-4个。多数成功的产品只有一个明晰而简单的价值主张，消费者会再比较产品的3-4个关键因素，然后在此基础上作出选择。
4. 最基本、可上市的产品
借助精益创业的基本假设：用户痛点与看到的中间变量是不确定的，解决方案是不确定的，需要通过不断迭代、不断积累认知，从而逼近真实的用户痛点和有效的解决方案。
一个产品，推向市场的时间越短，功能的发布的越及时，产品的开发成本就会越低，投资回报率就越高，现金流的提升可以让我们更频繁的听取市场反馈；反之，如果验证市场失败，及时撤退，这样能避免更大的损失。失败越快，才能迅速改进，这是一种风险驱动的方法。
5. 简洁
产品愿景要求产品负责人只关注产品的本质，只开发真正必要的东西，我知道这很难，但是产品负责人要有“反逼”自己的过程，是深思熟虑之后的缩减。创新本身就不是要肯定一切，而是要否定除最关键特性之外的一切。
注意
在描绘产品愿景声明时，要避免笼统的描述和详述技术实现细节，笼统描述无法明确产品未来的目标，详述技术实现细节会限制团队今后的工作。反例如下：
让**产品在今年占领中国市场；
让**产品t获得更高的用户满意度；
让**产品的质量更上一层楼；
使用JS重构**产品的软件；
使**产品更加容易使用。
客户属性和产品属性
产品愿景的重点包括客户需求和产品需求。
客户需求可以让我们关注市场或者市场细分。而通过关注客户需求，我们视产品为服务客户或者用户的一种终极手段；产品属性是产品为了满足某些需求而必须拥有的关键特性。一旦识别出产品属性，就可以对其进行优先级排序，可非为功能性或者非功能性两类。
这里要说平衡两个属性：互操作性和可服务性。互操作性要求有一定的架构负责性，可服务性有要求架构简单并且可拓展。这一对不可协调的矛盾要求我们必须作出妥协或者选择，有三种方法可供选择：舍孩子套狼、尽量保留、抱孩子舍狼。不管哪种选择，都需要团队共同参与，权衡利弊，产品负责人作出最终的选择。
创立愿景的技巧
不管你用pet 项目方法（谷歌的20%时间研究新思想转换为产品原型）还是scrum项目方法诞生的愿景，你都需要不同的技巧来判断这些愿景是否合适自己的项目，其中包括原型与实物模型；人物角色和场景；用户案例和用户故事；排序和故事板；愿景盒；展望产品路线图；卡诺模型等。下面对其中的几种进行简单的介绍。
1.人物角色和场景
角色可以帮助我们选择目标客户，场景可以是我们理解产品如何改变客户的生活，具体步骤是选定一个具体的角色，为角色创建一个具体的场景，此时主要创建两个消耗图来建立产品价值定位：一种是在没有产品的情况下实现特定目标所必须的活动；二是在产品可用的情况下，未来所需要的活动（具体用户故事的实践会在后续的文章进行详细介绍）
2.愿景盒
产品愿景盒其实就是可以交付的产品包装模型，可以有效的判断产品的增值和卖点。首先团队要选出一个产品名称、一个产品图形示意图以及三个产品卖点；然后讲这些信息放在盒子正面，详细信息可以添加到盒子背面，同时愿景盒可以有效检验大家是否对愿景的理解达成一致。
3.卡诺模型
卡诺模型区分了三种功能类型：基本型、理想型、奇迹型。
基本型是必不可少的功能，但是并不能提高客户的满意度；理想型功能可以使满意度得到线性增长，原则是“多多益善”；奇迹型可以取悦并刺激客户的需求，涉及的是潜在客户需求，只有能够提供竞争性优势和独特销售主张的产品功能才可以归为此类。
我们通常关注的是理想型和奇迹型属性，而不太会强调基础型需求。并且随着时间的推演，奇迹型最终会变成理想型，而理想型会变成基础型。我们要做的就是不断保持领先优势们顶起升级并交付新的奇迹型需求。
4.展望产品路线图
产品路线图是一种计划工件，显示了产品在不同版本的产品愿景中是如何演化的。每个版本的预计发布时间、目标客户及需求以及三五个主要特征都会在路线图上表述清楚。我们要关注的是对市场反馈的仔细己检查并相应调整产品所起的作用。
线路图要建立在市场和产品周期之上，关注眼下的6-12个月，而不是未来两三年。
小结
每个团队都需要产品愿景来指引方向，有时产品愿景甚至可以作为判断一个需求要不要做的有力依据。要确保团队对未来的产品有一个共享的愿景。从全局考虑，但是从小做起。邀请客户和用户参加评审会议，迅速发布产品增量来对愿景加以验证。然后在这些反馈的基础上对产品加以验证。
所以，要重视产品愿景，每隔一段时间根据业务需要和市场变化对愿景声明进行审核与修改。
下篇文章我会从如何有效梳理 Backlog ，如何处理非功能性需求排优先级来带大家全线路落地。
网友评论