敏捷软件开发，一次开发人员对PM的起义

为什么要有敏捷开发呢？

如果从敏捷的历史看，其实敏捷并不是来源于软件行业，而是来源于传统的制造业。

简单说一下它产生的历史原因。

在上世纪80年代的时候，美国的制造业受到了日本、德国（当时是联邦德国）产品的冲击，日本货便宜，德国货质量好，而美国货两头都不占，因此，美国的制造企业就着急了，心想这可怎么办啊，于是就由美国政府要求国防部牵头，GM（通用汽车）和里海（Leigh）大学的雅柯卡（Iacocca）研究所组织了百余家公司，耗资50 万美元，花费1000 人/日，分析研究400 多篇优秀报告后，提出《21 世纪制造企业战略》的报告。

在这份报告里，他们提出了两个最主要的观点：

● 影响企业生存、发展的共性问题是：目前竞争环境的变化太快而我们企业自我调整、适应的速度跟不上；

● 依靠对现有大规模生产模式和系统的逐步改进和完善是不能实现重振美国制造业雄风的目标的。

基于这两个观点，他们提出了一个崭新的工业生产模式——以动态联盟为基础的敏捷竞争模式。敏捷制造的概念首次出现。1990 年向社会半公开以后，立即受到世界各国的重视。1992 年美国政府将敏捷制造这种全新的制造模式作为21 世纪制造企业的战略。

关于敏捷诞生的历史就讲这么多，以后有时间再细讲。

没过几年，软件行业看到这概念不错，正好软件行业也出现了轻量化开发的趋势：

1991年的快速应用开发；

1994年的统一流程和动态系统开发方法（DSDM）；

1995年的Scrum；

1996年的透明和极限编程（XP）；

1997年的功能驱动的开发。

但是这些都没有统一到一个旗帜下，于是在2001年2月，美国的十七个开发人员相聚在犹他州的Snowbird酒店，在Jeff Sutherland, Ken Schwaber和Alistair Cockburn的牵头下联合发布了敏捷宣言。

这个时候，软件行业的敏捷开发才小溪汇聚为江河，成为软件行业一种流行的开发路径。

再回到本文的主题，为什么说软件行业的敏捷是开发人员对产品经理的一次起义呢？

要说明这点，我们先来看看开发人员是怎么认识敏捷的：

The Agile movement is not anti-methodology, in fact many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.

敏捷活动并不是反对方法论，事实上，我们中的许多人想恢复方法论这个词的可信度。我们想恢复一种平衡。我们拥抱建模，不只是为了在落满灰尘的储藏室里归档一些图表。我们信奉文档，而不是上百页的从来不会被维护和几乎不使用的书。我们规划，但是认识到在混乱的环境中规划的局限性。

不知各位产品经理看到开发人员的这些想法后，有啥感觉呢？

我个人有三点感触：

1、产品经理给研发的文档太多太长；

2、产品经理从来不知道文档的重要性，根本不去维护；

3、产品经理不知道如何做好产品的规划。

这三点或许是在敏捷诞生之前，开发人员对产品经理工作最“痛”的领悟。

先来看第一点，我们都知道，产品经理和研发接口最关键的文档就是PRD，但是大家PRD的质量如何呢？

各位产品经理想一想，你的PRD有几次不会被研发打回来，然后告诉你，你这PRD根本没法指导我们的开发工作，于是就反反复复的修改，结果PRD越来越大，开发人员越来越没耐心看，于是最终的结果就是出现了两个PRD，一个是你写的PRD，一个是研发人员理解的PRD。

大家就这么对付着来吧。

这还仅仅是一个PRD，而产品经理要做的文档有多少，不同的文档面对不同的团队成员，如果都是这种质量，这工作能干好吗？

大家还记得尼尔.麦克埃洛写的品牌管理思想的备忘录吧，800个字，三页，不多吧，三页就把一个管理思想说清楚了，其实在当时的宝洁，杜普利的要求是不能超过一页，老麦属于是严重超标的，还好，杜普利慧眼识才，没有把他怼回去。

再来看第二点，文档完成以后，很多产品经理就不去管了，认为可以存档了，这又是我们这些产品经理容易犯的一个问题，我曾经说过，文档可不仅仅是记录我们想法的载体，从产品的角度看，其实一套文档就是一个产品的抽象的文字化的呈现，直白点说，产品文档也只一种产品的形态，很多产品经理就是意识不到这点，我们可以想一下，我们都知道产品在发布后，是需要去维护的，那文档作为产品的一种形态，怎么就不去维护了呢？

如果你能意识到这一点，那么，你在写每个字的时候，一定会慎之又慎，并且知道什么是惜墨如金了。

更重要的是，一定要学会维护自己的文档，这种维护有两个好处：第一，能够让文档的信息随时跟随市场的变化；第二，能够让后继者通过你的文档知道你所有关于产品的想法，往大了说，这叫知识管理。

最后看第三点，产品经理的规划工作，规划对于产品经理来说，甚至对于整个公司来说，重要不重要呢？

相当重要，因为规划是为了让公司和团队成员知道你的产品长远要走向哪里，如果没有方向，那大家就都是一群无头苍蝇在乱撞了。

那为什么开发人员会有这样的想法呢？

很简单，因为很多产品经理根本就没有规划，或者说，很多所谓的规划并不是真正开发人员想看到的，或者是打动不了他们的。

我们就结合敏捷来说，敏捷的产品规划要分三个级别：长期规划；中期规划；近期规划。

长期规划一般是指产品路线图（12个月），中期规划一般是指版本计划（3-6个月），近期规划一般是指具体的开发计划（4个星期），产品路线图是战略层面的，版本计划是战术层面的，开发计划是执行层面的。

而产品路线图肯定是由产品经理来完成的，版本计划一般由PO来完成（不过，大部分情况下，PO往往也是PM扮演），版本计划则是由开发团队来定。

因此说，如果你的路线图定不好，后续的计划根本不可能做出来。

说到现在，各位产品经理应该知道了吧，为什么开发人员对我们的很多工作有意见，有情绪，有矛盾了吧，别只从开发的伙计们身上找问题，很多问题其实都在自己身上。

最终当这种矛盾不可调和的时候，开发人员就会自己琢磨如何来改变他们的工作质量，这对于产品经理来说，难道不是一个惨痛的教训吗！

看看吧，很多产品经理很多不到位的工作把研发的伙计们都逼成什么样了！

忘了说了，牵头发布敏捷宣言的人中，有一个叫Ken Schwaber的，他做过开发，也做过产品经理，或许他是真正感受到了开发和产品经理在工作协作上的问题，才做出了这个让每个产品经理可能都要反思的决定。

如果我们不去自己改变，那么，总会有人去改变我们。