不涉足RDMS太多，不代表不需要关注RDMS---浅谈各种开发流程模式对产品经理的影响（中）

常见的RDMS流程—Align开发框架对产品经理的影响

2001年2月，在Jeff Sutherland, Ken Schwaber和Alistair Cockburn的牵头下，美国十七个开发人员在犹他州的Snowbird酒店联合发布敏捷宣言的那一刻起，就已经决定了Align是一种典型的以开发人员为中心的开发框架。

因为在Align开发框架中，除了程序员和客户之外，并没有其他更为重要的角色，包括产品经理。

需要注意一点的是，之所以本篇的标题把Align称之为开发框架，而不是一种统一化的开发流程，是因为Align更强调基于企业的实践，而非简单的规格化，这也就是为什么Align的实践更强调“导师”的作用的原因。

在国内，针对Align，我个人感觉谈的更多是的Scrum，其实在Align框架下，还有其它的实践，比方说XP（Extreme Programming，极限编程），Crystal，Adaptive和Pragmatic Programming。

但无论是哪种实践，产品经理都有一个困惑，在Align中，我们的位置在哪里，我们会受到何种影响，以及我们该如何面对这种影响。

尽管Align框架中，也有客户的角色，Scrum中称之为PO，XP中称之为客户代表，但是这毕竟不是产品经理的真正含义，因为这些角色根本还是隶属于开发团队，而非产品管理体系。

关于PM和PO的区别，大家可以参看这两篇文章：

《六张图搞清楚PM和PO的前世今生！》

《实话实说，你只是个PO，而不是PM》

在本篇中呢，我就以XP为例，简单介绍一下以它为代表的Align给产品经理都带来哪些影响。

简单了解XP的开发原则

XP的开发原则不用讲太多，网上都能查到。

结对编程——软件是由成对的程序员围绕一台计算机一起工作而编写的。

简单设计——只设计和构建现在需要的东西，而不是一些潜在的未来需要。

现场客户——开发人员有一个代表产品需要做什么的客户，与团队坐在一起，随时可以澄清和决定。

增量开发——从小处着手，做许多“小版本”来快速地将产品发展到它需要的位置。

排程和计划-评估由工程师提供，客户决定每个版本的范围和时间。

持续的代码审查——基于结对编程模型，开发人员不断地审查彼此的工作。

持续测试——让开发人员在编写代码时编写单元测试，客户在定义用例时编写功能测试，这些测试都是在自动化的、持续的基础上运行的。

持续构建——软件不断构建、集成和测试，以便及早发现问题，系统始终保持可构建状态。

持续重构——软件开发人员不断地通过重构代码来简化和改进实现，同时保持所有测试的运行。

集体代码所有权——每个开发人员都可以在任何时候看到机会和需要时改进系统中的任何代码。

开放式工作区——这个想法是团队在一个大房间里与中心的开发人员一起工作。

每周工作40小时——人们认为加班时间应该受到限制，这样才能保证高质量。

通过代码编写文档——相信最有用的文档是软件本身，团队需要遵循编码标准。

以XP为代表的Align给产品经理带来的影响

影响1：产品经理的位置

了解XP历史的朋友应该知道，XP最初是为满足单个客户的特定需求，而非面向有一系列需求的众多客户设计的。

这也佐证了为什么在XP中没有产品经理，而有客户代表这个角色。

也就是说，XP更关注的是有客户在场的现场开发，但是，拥有这样产品的企业毕竟是少数，大部分的企业关注的还是为满足大多数客户需求的通用产品。

这只是需求层面给产品经理带来的影响，如果我们视角再放大，就会发现，需求之外的工作依然很多，对目标客户的充分和足够了解，他们的普遍性问题，需要，竞争等等，这都是XP中的客户代表无非承担的，而这又恰恰是产品经理传统和典型的工作。

因此，我们就会发现，在采用了Align开发的企业中，产品经理事实上要么扮演两个角色，一个是PM，一个是PO或客户代表，要么就是被阉割成了PO或客户代表。

这还不是产品经理最郁闷的，最郁闷的是，如果是前者，那么无疑让产品经理在企业内的位置出现了混乱，并且也会增加产品经理的工作量，压力陡增，如果是后者就更有意思了，产品经理就成了典型的“挂羊头卖狗肉”了。

更通俗的说，如果企业严格执行Align的话，那么事实上并不需要产品经理，有个PO或者客户代表就可以了。

影响2：用户故事取代了产品规格

在XP中，事实上并没有传统产品规格的概念，而是用用户故事进行了取代。对于定制化的产品是可以的，但是对于通用的，必须依赖一定商业模式的产品，仅仅依靠用户故事是不够的，产品经理必须做大量的和产品有关的，方方面面的研究和分析才能定义出一个成功的产品是什么样的。

也就是说，仅仅依靠用户故事只能解释产品介质功能性的要素，而要对产品进行商业和业务层面的解释，就必须依赖更为完整和体系的产品管理文档的支持。

即使是产品介质的规格，我个人也建议同步使用PRD和用户故事，PRD用来记录你的分析过程，用户故事用来向RDMS的成员传递分析结果和进行交流。

关于用户故事，大家可以参考以下几篇文章：

《产品经理们，今天我们讲“故事”》

《除了“用户故事”和“工作故事”，产品经理还要讲好一个故事》

影响3：单一客户还是大众客户

前面提到了，XP面对的是单一客户的需求而非大众客户的需求，同时，我们又知道我们的产品，往往是希望尽量满足更多的目标客户的需求的，而这些我们细分出来的不同的目标客户又一定在一些具体的产品需求上有差异，那么，这就给产品经理带来了又一个困惑，为了验证产品在开发之前就是正确的，那么，如果按照XP的开发原则，似乎就需要多个客户代表才可以，而这就意味着技术解决方案很有可能不得不面临不断的修正去应对这些客户代表的现场意见。

这是企业的成本和进度无法承受的。

影响4：不可或缺的设计师团队

我个人认为这是Align给产品经理带来的最大和最直接影响。

在现实中，很多产品经理其实连PO或客户代表都算不上，只是一个原型设计师，这在很多企业的RDMS伙计们的观念中也确实是这样。

产品原型的目的是什么？

用它来更直观的呈现产品规格其实并不是最终目的，它的最终目的是为了验证产品的可用性，也就是我一直提到的在开发之前去验证这个产品是正确的，是能够解决客户问题的。

产品经理对于产品的关注，无非就是三点：产品的可用性（能解决问题）；产品的可实现性（能做出来）；产品的商业价值（有市场交换的价值），前两个是前提，后一个是目的。

但是，要能做出一个具有验证可用性级别的产品，说实话，单靠现在产品经理用的这些工具和能力，不太容易。

因此，拥有一个完整的设计师团队就成为了解决这个问题的关键所在，而一旦有了这个团队，产品经理就会有更多的精力和时间去关注产品的目的，也就是商业价值的实现。

影响5：产品进度的不确定性

Align的典型原则之一就包括增量开发和持续构建，虽然这样在预测给定迭代的时间框架上要容易的多，但是预测达到可发布产品所需的迭代次数却非常困难。

但是对于产品经理来说，我们要考虑的不仅仅是开发的因素，还要考虑市场，也就是MMS这个体系中的因素，比方说你所计划的产品上市发布计划肯定是要交给MMS去操作的，而可发布产品的迭代次数则会出现一定程度的不确定性，这种RDMS中的不确定性就必然会影响到MMS的计划，产品经理必须面对这种情况。

当然，总的来说，相对于瀑布而言，Align的总时间还是要少的多，但是企业将不得不面对总体时间上的不确定性。

个人感想

作为一种来源于开发人员，以他们为中心的开发框架，Align确实在减少开发时间，增强开发和功能性需求的沟通，降低开发风险上比瀑布流程有了很大的进步，在Align框架下，有一些非常有价值的具体技术，比方说结对编程、增量开发和持续的自动化测试和构建等。

但是，成也如此，误也如此，正是因为过于站在RDMS的角度，太关注产品在开发流程中的产出，而弱化，甚至是忽视了产品固有的商业属性在企业整个业务体系中的传递。

站在RDMS的角度，这没有任何问题，因为Align确实解决了开发人员很多头疼的问题，但是站在PMS的角度，则恰恰给PMS带来了困惑和影响，就我了解，很多实践Align的企业中的产品经理，认为Align对产品的成功（产品如约合规的开发完成，只是RDMS的成功，而非PMS的成功）的作用是有限的。

当然，正如我在《敏捷软件开发，一次开发人员对PM的起义》这篇文章中提到的，在一个健康的企业业务体系结构中，体系之间并不是谁领导谁，谁主导谁的关系，一定是相互配合，相互促进的关系，尽管Align表面看，带来的只是开发流程的变化，但是放到整个体系中，它对PMS，甚至MMS的影响也是显而易见的。

有眼光的产品经理绝不会无视这种影响，而一定会用卓越的眼光去思考，如何让PMS基于RDMS的变化带来的影响和挑战成长的更加健壮，也会用百倍的勇气去实践，让PMS的生命之树更加茂盛。

既然瀑布太死板，太重量化，太强调阶段控制，Align太灵活，太轻量化，太强调个人能力，那么，是否有第三条路可以走呢，在下一篇中，我就来聊聊基于RUP的开发流程对产品经理带来的影响。