软件开发项目经理的起源

在一个软件团队里, 不同的人有不同的投入, 我们在 猪,鸡和鹦鹉的故事里已经说明了. 不同的人还要在团队中担负不同的任务, 我们也要讲一下.

开发人员 （大部分内容在: 现代软件工程讲义 2 工程师的能力评估和发展）

项目经理 ( 这篇博客 )

测试人员 ( link)

1. 微软PM 的来历

大部分公司的项目经理叫 Project Manager， 微软的经理叫 Program Manager, 这有什么本质的区别么?

微软曾经也是一个创业公司, 两个创始人都是 dev, 招聘的新成员也大多是像他们一样的开发人员, 这其中就有一个叫 Charles Simonyi的超级程序员 (当然还有像 Steve Ballmer 那样的超级销售人员, 这里按下不表)。

1974 年, Charles Simonyi 在Xerox PARC 开发了 WYSIWYG (所见即所得) 的字处理软件 Bravo, 成为 PARC 的 Alto 个人电脑的重要应用软件。

(作为时间的参照:

同一年, Steve Jobs 从印度回来, 加入Atari 公司打工, 因为其他员工不能忍受他的傲慢态度和卫生习惯, 他只好上夜班。

同一年, Bill Gate 在哈佛大学读 2 年级, 他第二年看到了个人电脑的曙光 – MITS Altair 8800， 于是退学创立了 Microsoft.

)

1981 年, Charles 加入了微软公司, 领导 Word 和其他办公软件的开发。 很多开发人员聚集在一起, 怎么工作呢? 如果大伙做的是搬砖的体力劳动 (我很喜欢用搬砖的例子), 那么在一定限度内, 人员的增长和项目复杂度的增长是线性的关系; 程序开发就有些不同, Charles 发现项目管理的复杂度似乎是和人员数量的平方成正比。 一个团队里有 4 个成员, 就有 6 种双向依赖和交流的途径, 然后增加一位新成员, 就要增加 4条新的双向依赖交流的途径。 对于 N 个成员的团队来说交流的途径总数是 n * (n-1) /2, 这种 N 平方的增长是不可持续的。

怎么办? Charles 想到了一个办法 - 他提议把程序员分成 Master Programmer 和 Slave Programmer, MP 和其他成员交流, 了解需求, MP 只写抽象的伪代码, 或者对功能的描述; SP 根据MP 的文档, 实现具体的功能。 SP 只用和 MP 交流。 这样不就大大减少了交流的成本么?

这个想法在理论上是好的, 但是在实际上, 没有人想做 Slave Programmer, 刚加入团队的成员问 - 为什么我们不能当 Master Programmer? 这次改革最后不了了之。

但是, 随着软件复杂度的提高, 用户需求的多样化, 市场竞争的日益激烈, 光有程序员和销售人员是不够的。 我们需要专门人才来做下面的事:

怎么让软件变得可用 (usable), 有用 (useful)

销售人员把顾客的需求直接告诉开发人员, 但是开发人员往往听不懂。 我们需要专人来把市场/销售人员那一套 MBA 的套路翻译成程序员能懂的功能说明 (spec)

一个产品团队要做很多事, 这些事往往是程序员不愿意花时间的:

和客户交谈, 组织用户调查, 发现用户需求

了解和比较竞争对手的产品

怎么改进团队的流程

谁都不愿意做, 谁都没有能力做好, 大家宁愿盯着屏幕写代码。 怎么办呢? 这时候有另一个聪明人出现了, 一个叫 Jabe Blumenthal 的程序员提出了 Program Manager (PM) 的头衔, 并成为了微软第一个 PM (1984年). PM 做什么呢?

2. PM做开发和测试之外的所有事情

Program Manager 和一些公司的 Project Manager 的区别:

在别的团队中, 也有产品经理的职位, 例如这个博客 (和书) http://iamsujie.com.

问: 目前微软公司有哪几类的PM?

答: 有做功能设计的PM; 有些需要很深的 Computer Science 的专业知识 (如 Visual Studio, SQL server, Windows Server, Bing Search 等团队的PM ), 有些需要对商业和客户很强的了解能力 (如 Office 应用软件的PM ), 有些需要广泛的经验和知识面, 商业拓展能力 (如 MSN 部门的 PM); 有些是驱动流程的PM, 例如推动几百人的团队完成一个版本的开发, 又如保证 WP7 在几十个不同硬件上能发布; 也有专门深入某一领域的 PM (如 localization/globalization); 还有和研究人员合作, 做技术转化的 PM。

问: 既然PM 这么厉害, 为什么不让他们领导开发人员和测试人员, 这样 PM 工作起来不就是更有利了么?

答: 首先, 我们认为好的产品设计是在平等讨论 (甚至争论) 的基础上产生和完善的, 如果讨论的一方同时又是另一方的老板, 则无法进行平等和无拘束的讨论。

其次, PM 的产品是 spec (规格说明书), PM 要凭自己的能力, 把用户的需求展现成 dev/test 能够了解, 能够执行的语言, 从而赢得同伴的信任和尊敬。 如果PM 同时又是其他人的老板, 则不必写太好的 spec, 用命令即可说服别人。 再次, PM 不一定是很好的行政经理, 硬把管理不同专业的 dev/test 的任务加到PM 头上, 反而会坏事。 关于这个问题, 这里也有一篇讨论.

问: PM 最大的, 最独特的贡献是什么?

答: 保持团队的平衡。

一个软件产品几乎做不到同时又多又快又省。 在别的领域也类似, 中国在大跃进期间提出了 多快好省的要求。 最后只得到一个 “多” - 人多。 （参见 软件工程的估计）

大部分优秀的团队可以做到两个:

多, 快, 但是不省

多, 省, 但是不快

快, 省, 但是不多

PM 要带领团队选择哪两个是最重要的, 哪一个是可以牺牲的。

还有许多不那么优秀的团队也许勉强可以做到一个:

多, 但是不快, 不省

省, 但是不多, 不快

快, 但是不省, 不多

当然还有一些团队一个目标也达不到, 中途作鸟兽散了。

问: 我们团队有几个程序牛人, 参加过 ACM 比赛什么的, 他们写的程序都不用测试, 为什么还要 PM？ 如果PM 也来开发, 是不是项目进展更快?

答: 程序 和 软件有区别, 请看: http://www.cnblogs.com/xinz/archive/2011/05/22/2053838.html

其次，在下面的图中, 团队有很多划船的牛人, 也有一个拿着话筒的舵手. 如果这个舵手也开始划船, 后果会怎么样?

可能小船的速率会快一些, 但是小船的方向, 稳定性会出问题。 你愿意船很快, 但不稳, 而且最后到了一个以前没计划的地方?

问: PM 文化的盛行有副作用么?

答: 任何方法或文化都有优点和缺点, 由于大部分决定都是经过平等的讨论协商折中的到的, 一个后果是 “design by committee”, 一些产品不能很快跟上市场变化, 在需要个人特色的方面, 如设计/UI, “committee”设计出来的东西大多中规中矩, 但是很多方面了无新意。

3. PM 的能力要求和任务

成为一个团队的PM, 需要哪些能力呢?

学习能力:在一个新领域中能很快上手

观察理解能力:能理解用户, 站在用户的角度上考虑问题, 观察发现用户不善于表达的需求, 观察团队成员的言外之意, 老板/客户/利益相关人的弦外之音.

分析管理能力:每天项目中发生的事情千头万绪, 能够分析出重点, 找到优先级, 做决定…

一个项目和个人一样, 每天都会碰到各种问题:

重要而紧急的 //网站崩了!

//程序员二柱突然说他要离职!

重要而不紧急的 //按照流量和内容的发展趋势, 三个月后, 目前的架构似乎撑不住, 但是现在还凑合…

//程序员们都不写文档, 他们三个月前说等忙过之后会写的, 但是…

不重要而紧急的 //老板的老板问到了项目的进度! 要写一个PPT，请若干人征求意见

不重要且不紧急的 //…

PM 如何处理这些事情呢?

交流能力, 处理冲突的能力:其他角色碰到冲突一般会来找 PM. PM 也要鼓励团队成员保持斗志。

一定的专业能力: 写代码, 玩转Excel, PPT, Visio, 甘特图, 会PS, 有文字功力, 能写有人读的博客, 总得有几招绝活吧!

在一个项目中, PM 的具体任务是什么呢?

带领团队形成团队的目标/远景, 把抽象的目标转化为可执行的, 具体的, 优美的设计。

管理软件的具体功能的生命周期 (需求/设想/设计/实现/测试/修改/发布/升级/迁移/淘汰)。

创建并维护软件的功能说明书 (specification), 让它成为开发/测试的及时准确的指导, 而不是障碍。

代表客户和用户的利益, 主动收集用户反馈, 预期用户新的需求。 协调并决定各种需求的优先级。

分析并带领其他成员形成对缺陷/变更需求的一致意见, 并确保实施。

带领其他成员确保项目保持 功能/时间/资源 的合理平衡, 跟踪项目进展, 确保团队发布让客户满意的软件。

收集团队项目管理和软件工程的各种数据, 客观地分析项目实施过程中的优缺点, 推动项目成员持续改进, 从而提振士气。

成功的PM 如果得到团队成员的支持, 会是什么样?

成为项目流程的主人 - 驱动流程, 会议, scrum, 进度

代表团队, 向上级/伙伴团队/客户/市场报告项目进展

不用自己写一行代码，也同样可以积极地影响项目和产品

PM 如果得不到到团队成员的支持, 会是什么样?

在各种会议或流程中浪费大家的时间, 发一些大家不读的 “Status Mail”.

不能凝聚团队, 形成共识

对团队的状态不了解, 也不能有效和准确地向有关方面报告团队的情况, 获得支持

对项目和产品造成负面的影响。

4. PM 们的故事

讲了这么多条条框框, 我们还是讲几个故事吧:

A) 是不是所有的好功能都是由PM 主导, 一步一步根据用户需求，按照用户场景设计，然后可用性测试等等步骤之后得来的？

功能本天成，妙手偶得之——一个来自微软的故事。[注3]

约摸在1985年，微软的一个叫Steve Hazelrig的工程师正在写Mac Excel 版本的打印功能，那时候激光打印机很贵，而且离办公室也不近。他懒得经常跑到打印机那儿取打印纸，检查打印效果，就写了一个小程序，把要输出到打印机的图像显示在屏幕上，还有一个放大镜功能可以把局部放大以检查每个像素的位置及效果。这时一个PM路过看到了这个小工具，说，这么酷的东西，为啥不做成一个功能呢？

所以后来微软的编辑软件都有“打印预览”这一功能。然而，用户们并没有正式地要求这一功能。

B) PM 怎么说服聪明的同事

这个故事在 [注4, 注5] 中都提到了. 在Macintosh 研发的过程中, 由于计算能力的限制, 计算机的图形显示非常缓慢. 一位聪明的程序员展示了他的新算法, 能很快地画圆形和椭圆. 当他得意地展示给 Steve Jobs 看的时候, （作为一个不懂编程技术的 PM，Steve 应该表示仰慕才对…） Steve 看了之后, 反问 - 你能继续改进, 让圆角的矩形框显示速度加快么? 程序员说: 这个太难了, 也没有必要. 椭圆不是挺好的么? Stevel 为了说服同事, 建议两人到外面散步, 然后指出现实世界中的各种告示牌都是用 圆角的矩形框 来实现，走了一圈, 同事就被说服了。 过了几天, 圆角的矩形框也可以很快速地在屏幕上显示了。

C) PM 的分析能力和韧性

能把市场, 我方的优势和劣势, 创新的机会讲得头头是道, 也是一种能力。 在软件工程课上我们讲过 NABC 方法。 乔布斯在 NeXT 公司时那样也做过很有说服力的分析:

注意, 这么厉害的 PM, 分析的这么透彻, 但是 NeXT 的产品还是失败了.

但是乔布斯没有气馁, 又投入了另一个公司的运作 – Pixar.