原文链接：Managing Product Development by Integrating Around Concerns
by Ryan Singer (@rjs)
产品设计时怎样为需求划分优先级？开发过程中如何监控所有功能点的进度？产品的整体规划是怎么完成的？如何有效避免开发过程中由于规划问题导致的需求变更？
很多人好奇我是如何做产品开发规划的？这通常是产品经理需要考虑的问题而非仅限于开发者或者程序员。完善的产品开发计划不仅是高效完成当期工作的保证，同时还能在未来的迭代过程中为我们指明里程碑路径，帮助产品经理更有弹性的分配研发资源，最终完成与MRD相一致或者更为完善的产品。
作为产品经理，如果你一直在重复设计着同样的产品，这篇文章对你不会有太大的帮助。我喜欢创新性的工作，这就导致我很难准确的估算开发工作量或者某一个功能是否真的可以满足用户的需求。在这个情况下，我尝试用我自己的方法来应对未知的工作。
每当我开始一个新项目的时候，并没有现实的产品存在。在一件产品变成现实之前，我们会脑暴或者调研出无数的用户需求、功能规划、产品目标等信息。我可以轻易列举出上百个务必完成的功能模块。举例来说：仅仅一个会议日程管理的应用，就必须包含活动日程表、来宾签到表、签到流程、支付流程、信用额度及折扣管理等。所有的这些功能都等着你一步步地实现。
另外，每一个功能模块都包括了更多需要在PRD中体现的细化功能点。仅来宾签到表就包含区域管理、校验规则、错误状态反馈、浏览器适配、UI设计等更多方面。在需求提交开发之后，所有的这些需求必须被正确的划分成功能点，还得确保被正确的执行以保证高可靠性与可维护性。
我们上面提到的这些功能模块还没有包括各个组织模块之间的交互以及依存性关系等。所以，如果你企图在需求调研阶段搞定所有的功能点规划，那会是很恐怖的工作量。
怎样才能更好地规划产品的需求优先级呢？我通常把这些大块的功能点想象成一个未经探索的地图。这张地图包含了所有针对用户痛点的需求，而我的任务就是把不同的功能模块串联起来，并探开整片地图。为了更有效的确定哪些区域是已经探索过的，哪些仍然被战争迷雾笼罩，我们首先应该把整片地图划分为不同的区域。
这幅图片仅仅展示我脑中的开发计划。在实际工作中，我使用清单来管理他们。（译者更多的使用思维脑图，工具不同、各有千秋）
在我们完成区域标定之后，下一步的工作就是权衡需求的优先级。会为你的目标用户提供同样的价值的两个需求是不存在的。有些解决用户核心问题的功能必须要首先开发，因为离开他们整个应用都是毫无价值的。另外一些锦上添花的功能虽然同样必不可少，但优先级不必太高。当我看着这幅被战争迷雾笼罩的地图，我会问自己三个非常重要的问题
- 从用户的角度看，这个功能有价值么？
- 这个功能属于“缺一不可”还是“锦上添花”？
- 这个功能点的最终表现形式是什么？什么情况下才算是开发完毕、测试合格？
你必须明白这条法则：产品中没有两个功能的价值是一模一样的！UI与RD会尝试把他们自己负责的所有工作做到尽可能的完美。作为产品经理，如果你提升了交付标准，开发团队的这种“务求最好”的工作态度很有可能会导致开发进度延期以及成本的增加。你需要自己衡量这些投入的价值，把更多的资源向关键功能倾斜。
在项目开始初期，我根据上面三个问题的答案粗略地给主要功能点划分优先级，来找到最重要的那些需求。就好像《Getting Real》所说：“找到震中！”
或者我们换一个思路来衡量功能点的优先级：哪些功能才是促使用户打开应用的关键！你会用微信看新闻么？你会用微博跟闺蜜聊天么？面向对象的设计方式比传统的面向过程的设计流程更加有效。举例来说，我们到底是先开发“看似需要”的用户授权系统还是先投入资源完成“缺一不可”的重要模块开发？
当我们完成需求的优先级分类工作之后，就可以把上面的地图变成热点图，并从中发现产品中的哪些功能才是更有价值的。
不要纠结一次就给每个区域都准确地标明优先级。重要的是明确找出那些事情是我一定要在第一步完成的。等这些事情搞定之后，就把优先级标定的流程再做一遍然后找出下一批最重要的事情。往复循环，直到整个产品全部完成。
还是上面这个关于会议管理应用的例子，“在线注册与支付系统”给用户带来了最大的价值。用户首先会因为这两个方便的功能而使用我们的产品，与这两个功能近乎同样重要是“注册数据的快速统计”。用户可以通过这些数据知道所需的场地规模与工作餐数量。其次，用户授权与账号管理功能也需要尽快上线，但他们在优先级中排名第二。最后，我们还能上线一些优化类的功能来帮助用户更好的使用，例如数据导出等。
好了，现在我们可以开始做些实际工作了。我们先从最重要的会议登记表开始。注册表的界面设计将会首先进行，因为我希望用设计来驱动整个项目，而不是开发的难易程度。当我真正开始UI设计时，我发现仍然有好多关于产品的设想。
整个会议登记模块其实是一系列小功能点的集合。我们需要考虑很多应用场景而不单单是设计一张表格。什么样的情况是注册成功？什么情况是注册失败？需要设计邮件模板么？如果我们不能列出所有的小需求点，我们就很难顺利的完成开发工作（说白了就是提前想清楚、别乱改需求）。为了更有效率的完成这些功能点，我们需要把刚才的区域标定工作在“会议注册”这块区域里再做一次，把整个区域进一步细化。这是一个层层递进的过程。
现在产品需求已经细化到足够的颗粒度，我开始进行界面设计，首先规划出不同的状态，接着加入细节与原型模板。这个时候，开发人员将在这个时间段进入项目。这时其实才是整个产品开发工作的开始。
这时，大多数产品经理会将整个团队划分为不同的角色，例如“设计团队”、“开发团队”，并分配给他们不同的“任务列表”。
这个管理方式的缺陷在于：两个不同角色的工作实际是割裂的，没有人能同时了解对方团队的开发进度，因为这样的团队划分不能与我们之前的地图相交互。
为了解决这个缺陷，我通常使用面向对象的方法来划分任务列表。如下图：
我可以非常清晰明了的从新版的任务列表中知道整个会议注册模块每一个细分功能点的情况。每当一个子列表的所有确认项被完成，都意味着这个产品已经有一部分已经开发结束、可以进入测试环节了。我喜欢这样的任务列表，因为我可以清楚地知道每一个细微部分的具体情况。
在产品地图上给一个区域标明“完成”是非常激动人心的！因为这需要设计团队、开发团队、支持团队与测试团队的通力合作。面向整个功能模块的任务列表可以把所有的成员都放在一个平面内进行讨论，最大化沟通效率，因为团队的每个成员都随时准备跟其他人配合解决问题。举个例子来说：当开发对界面设计有疑问时，马上就可以找到相关的设计人员；而测试人员在发现问题后可以直接推送回开发去修改。
我的这种方法适应性很强，不管你是自己工作、在小组工作、或者是与大型团队公事，都可以非常好的掌控整个产品开发进度、了解每一个功能点的具体情况，帮助你快速准确的从一个模块开发转入下一个模块开发。
不论何时何地，只要看到这份开发地图，我就会问自己：“我们在哪里？”并确认项目的任务列表。我希望知道哪些需求已经被完成了，而哪些仍在进行；哪些问题已经得到了解决，而哪些仍在排期？在过去的数年中，通过把数百个细化功能点用十几个功能模块概括出来的产品开发管理方法，帮助我对每个项目都保持清晰地视角。
这篇文章包含了下列重要的观点：
- 不要觉得产品的未开发部分所包含的需求优先级是永远不变的。
- 你需要在心中对整个产品关键功能模块有整体性的规划。
- 要细心的衡量每个产品功能模块的价值，明确他们存在的必要性以及各自的特色。不要像傻瓜一样只聚焦在那些“需要，但是却毫无差异化竞争力的功能”上面，例如：用户授权功能。
- 每一个功能模块都是由更多的次级功能点构成，你同样可以衡量他们的价值并确定开发顺序。
- 不要使用”角色“型的任务列表来追踪开发进度。你需要明确整个团队任务每一个组成部分的完成情况，确认后才可以开始进行下一项工作。
- 将整个团队的工作综合管理，并允许每一个成员提出疑义。同时，每个成员都要做好帮助他人的准备。
- 一个健康的产品开发过程是稳定的，所有的需求是逐步实现的，不要奢望一步登天。
- 我们的最终目标是在开发过程中清楚地朝着未知区域前进。产品经理应该经常提问：“我们在哪里？”并知晓哪些需求是已经完成的，哪些是还未完成的，哪些是正在开发的，哪些是正在排期的，哪些是令人满意的而哪些需要优化等。
本译文微信首发“三节课”公众号
