在网上看到一位在微软做PM(程序管理)漂亮女人写的一篇文章,写得很精彩,这也是自己曾经在工作中的体会,把内容贴在下面:
曾经听过一个比喻, 如果把一个项目比作一个大蛋糕, 开发人员会切走一大块, 测试人员会切走一大块, 用户体验专家会切走一大块, 用户教育人员也会切走一大块, 而剩下的所有东西 – 无论是剩下的大块蛋糕, 还是落下的小块奶油、半个草莓、开发人员和测试人员拿走的蛋糕之间所留下的那一小条蛋糕等等,统统都归PM。这个比喻不完全准确,但至少说明了为什么我说三言两语说不清这件事情。
好了,言归正传。就我的理解,总结起来PM的职责包括但不局限于以下事务:
a) 了解并理解客户需求
b) 设计产品功能
c) 与项目组中其他人员沟通,使他们理解并认同你的设计
d) 为项目制定进度表,管理项目进度
e) 扫清一切影响进度的障碍,使产品按时按质交付
f) 向项目组以外的人介绍和演示产品(老板、其他组、合作伙伴、客户…)
我承认,这些描述也许仍然无济于事。那么让我们来看看具体的例子吧…软件开发是一项合理的人类社会活动(当然!),因此环顾四周便很容易找到可与软件开发类比的其他社会活动。如果您是个DIY爱好者,那么您一定有过许多类似这样的经历:自己筹办婚礼,自己设计装修房子,自己制定旅行计划…这些事情都可以看作是项目,而您也许多次扮演了项目中PM的角色。
假设,您正打算帮您的父母好好重整一下他们现在的住所,因为那间房子是十年前装修的,已经不够舒适了。现在您是PM,您的父母是用户,您还分别找到了一个很有经验的装修团队和一个很专业的监理团队。
** 您早已注意到这个老房子的书房里一盏灯的线路有问题,这必须在装修时弄好。
—— 这叫PM在现有版本中发现需要修复的问题。
** 与老妈聊天时,她提到最近每天晚上10点开始播的韩剧很好看,就是晚上在客厅里看电视觉得挺冷的。您说,那我给您在客厅按个空调吧。
—— 这叫了解客户的需求。
** 老妈说,哟,这得多费电哪。于是您说,那就在卧室里给您再按个电视吧。我给您卧室里设计个电视柜。
—— 这叫理解用户真正需要,并设计产品功能来满足需求。
** 于是您开始设计电视柜了。您先考虑了一下该买个多大的电视,然后又考虑电视柜得打在什么位置,长宽高是多少,在什么位置有几个抽屉,抽屉把手用什么样的,需要承重多少等等等等。等一切都想清楚了,您把所有这些都写进了装修合同里。
—— 这叫设计产品功能,并编写功能说明 (Functional Specification)。
** 带着合同,您就与装修团队和监理团队见面了。您先向他们阐述了您的想法,并请他们仔细阅读合同,看看是否合理。他们对此设计没有提出异议,因此彼此立刻签署了合同。
—— 这叫使项目其他成员理解并认同您的设计。
** 于是您请他们分别估计工作量,装修团队说需要2个月,监理团队估计在那之后他们还需要1个月。因此您将进度表(Schedule)定为3个月长,并在其中设置了多个里程碑(Milestone)。
—— 这叫为项目制定进度表。
** 第二天,装修团队打来电话说您想要的那种墙面漆涂料最近缺货,没有涂料便没法刷墙,也将影响其它任务的工期。迫在眉睫,您忽然想起了有位朋友刚买了这种涂料,便询问他是在哪里买的。得知某郊区卖场还有剩余,将此信息告诉装修团队,于是刷墙得以如期进行。
—— 这叫扫清项目障碍。
** 两周后是第一个里程碑,您来到房子一看,墙面已粉刷一新。但被告知最近天气多雨,墙面漆要多花几天才能干透。于是您及时调整进度安排,将修理电线线路等任务提前。
—— 这叫管理项目进度。
** 两个月后,监理团队告诉您,他们看了做好的电视柜,发现长度略长于合同规定尺寸,其中两只抽屉无法打开。您找到装修团队,与监理团队一起商量。鉴于修复长度问题成本较高,而且对用户使用影响不大,决定不修复。但抽屉的使用为基本功能,需修复。
—— 这叫鉴别bug。
** 三个月后,项目顺利完工。您带着父母一一参观房子装修后的每个角落,向他们介绍如何使用等。
—— 这叫向用户演示产品。
当您看到用户 - 老妈舒舒服服地躺在被窝里看着韩剧时,看到老爸的书房里灯再次明亮如初,您的心里是不是感到满足呢?