主题：东扯西拉：也谈Project Manager -- 南寒
看了月光下的尘的PM的职业定性，也胡说两句。一己浅见，大家批判。
PM是好还是坏，全看你怎么用、用在哪儿，这听起来是废话，但经常被忘了。
我这些年熬免煮柿油的地方，不是IT的地界，但远远看去，窝棚里各家的烟囱和IT的地界差不多，所以不少对黔无驴感到遗憾的大爷大娘们总想着弄个PM进来。我只要能劝得住的都尽量劝：您还不如直接给我们送点切好的肉来。
我们这匡家窝棚有两个毛病，PM来了多少有点水土不服。
第一，我们这里的活到底该怎么做不确定性比较大；你大年初一立下雄心壮志，说我们二月二把秧子种下去、三月初五上粪、清明捉虫、夏至轰鸟、秋天了就一定能把土豆收上来、入冬的时候盆景就能上市了；但真做起来，从秧子到粪、虫、鸟都不一定跟你配合，所以这Project Plan两天就得重写一回；PM无所谓，正好创造就业，但我这儿的兄弟们还得对付粪、虫、鸟，就一个个都要Victor Chen、Broad Wu了。
第二呢，我们这儿不象NASA那种伟大的地方，成百成千的科学家们，隔壁办公室里坐着，但谁都不认识谁。我们这一个窝棚里，大家一不小心就撞到一起去了，把每一句话都写到纸上、发个Memo，实在是一件事倍功半的事情。说得文诌一点就是，标准PM的交流、沟通方法如果不变通，根本就不是那么回事。
这里的一个根本矛盾就是：PM所能有的用处，与把PM往我们这儿发的大爷大娘们的想象力之间，往往有很大的差距。详细的下一段再写。
本帖一共被 1 帖 引用 (帖内工具实现)
依我个人的看法，PM最理想的环境是一个繁琐而不复杂、不确定性比较小的地界。我可以想象这么一个环境，最终产品有多种形态，但所有这些最终产品都是由一系列模块化的中间产品组合而成。
生产这些模块化的中间产品的技术和过程都已经非常成熟，而且在每个计划期内，对每个模块的总需求是相对稳定的。组合这些模块、形成最终产品的过程虽然各不相同、但都定型化了，最终产品的具体种类选定以后，生产时间大部分情况下可以较准确地预见。
这种情况下，PM的任务是收集各方面的信息，然后把它们＂摆＂在一起，再把＂摆＂在一起的信息送回给原来的单个信息输出者。这里要强调这个＂摆＂字，因为PM只是把信息放在一个有固定格式的载体里面，并不需要做权宜性的处理。同时，
（１）PM不需要也没有对资源（人、物、时间）的分配权，
（２）PM不需要也没有提出、实施技术革新的能力和权利。
我这儿上纲上线一下。对于某些高层管理者来说，这基本上就是白日美梦成真、写写Project Plan日本鬼子就灰吹了烟灭。公司的运营完全按照自己的设想进行，自己还啥劲也不费，同时权利也不会落到中层的管理者和操作者手中。从整个经济变迁的角度来看，就是要实现知识产业民工化，土豆种植及盆景制作机械化。从社会结构变迁的角度来看，就能长期维持0.5%的老板和99.5%的各类民工的比例。
当然，这种理想化的情况很难成为现实，现实中PM有用的时候，是在和这种理想状态偏差不大的若干种修正状态下。下一段试着说说这些修正状态--如果还有下一段的话。
本帖一共被 1 帖 引用 (帖内工具实现)
第一种修正状态下，虽然没有一个组装最终产品的大全手册，但是有一个总设计师这样的人物，能对出现的各种问题给出一个简明并容易执行的解答， 然后由PM传达下去。
好比五个小分队过河，下水半个小时以后，第一小分队说：我们今天手气好，连着摸着了五块石头，眼看着要挂了单了，PM你看我们怎么办？PM找老大，老大略一思索、然后告诉PM：大家别再往前摸了，停在最后一块石头上打个盹儿。
第四小分队，摸着了第一块石头以后，再也摸不着第二块，赶紧告诉PM，PM找老大，老大问了问大概的方位、然后告诉PM：左前方、与河岸成28度角、五米开外、反手摸。PM又赶紧告诉分队长，大伙一摸：别说，还真有块石头。
实际当中的问题是，这样的总设计师往往不存在。有时候，即使有那么一位在，或者能力不够、或者出现的问题太复杂。话说这第三小分队自打下了河以后，左摸、右摸、前摸、后摸，连土疙瘩也没赶上一块。PM一查进度，老大一皱眉、有了注意：大家往有蛤蟆出没的附近多摸摸。大家瞪大眼睛，瞅了好几袋烟的功夫，未果。PM告诉老大、老大告诉PM、PM告诉大伙儿：赶紧恶补两栖动物学，掌握蛤蟆居家旅行各种习惯。大伙用塑料袋包着书看完了导论，一位忽然想起来了：老大啊，现在可是在腊月里啊！
在河里泡着的那几位，一边要摸石头、一边还要跟PM对付，现在又得琢磨蛤蟆。大家一般不敢冲着老大干点啥，这PM就得受夹板气了。
第一种修正状态可以说是PM不在查一个印刷的、或者存在计算机里的一个手册，而是在查一个活手册。但PM还是决策管理的一个环节。
我能想到的第二种修正状态中，PM已经基本不在决策管理中起作用了。比如说在一个很大的复杂系统中，PM被用来在各个层次间传递信息，通报进展；而作出的决策需要由能够处理专业知识的渠道来向下传达和向上反馈。
但是，如果被交流的大伙儿都是低头不见抬头见，而且被传递的信息需要多次反馈才能达成最后的形式，这种交流方式从成本上和功效上都往往不是最优。
在第三种修正状态中，PM也是基本不在决策管理中起作用，但PM被赋予了一个新的功能，就是处理一些跨部门的杂务，原因是PM本来就和多个部门打交道。但是当杂务越来越多的时候，就需要一个统一的后勤管理了。
我们以上一直在说多个部门执行多项任务，一个有相似性的情况就是一个人执行多项简单而有序、但不完全相同的任务。显然，给每个人配一个PM是不可能的；如果给一群人配一个PM，似乎还不如传统意义上的管理人员。
等到最后一段，再说说大爷大娘们往我这儿发PM，在我的想象中到底是要干什么？
问一下，项目管理中的工作说明书sow咋写呀？
你这儿是否涉及到两个公司？如果是的话，你是卖W那边的，还是买W那边的？
如果是在一个公司内部，写的和做的是一拨人吗？如果不是，你是写的那拨的、还是做的那拨的？这个问题对于卖W那边也适用。
是一个机电安装工程项目，我方为施工方，业主要求我方写一个SOW作为投标文件一部分，至于具体施工照不照做不好说。现在是让我来编这玩意，但这是第一次遇到这种情况，不知如何下手，网上搜索了下，只找到个比较接近项目的模板
工作说明书主要包括以下内容
前言、服务范围、方法、假定、服务期限和工作量估计、双方角色和责任、交付资料、完成标准、顾问组人员、收费和付款方式、变更管理等。
前言
对项目背景等信息作简单描述。
项目工作范围
详细描述项目的服务范围，包括业务领域、流程覆盖、系统范围及其他等。
项目工作方法
项目拟使用的主要方法。
假定
项目进行的假定条件，具体内容需双方达成。
工作期限和工作量估计
项目的时间跨度和服务期限，对于按人天计算费用的项目，需评估服务工作人天，并估算项目预算。
双方角色和责任
分为供应商的职责和公司的职责，并对关键角色的工作职责进行描述“如：项目经理”。
交付件
列出项目的主要交付资料，并对交付件的内容与质量要求进行描述。
完成以及验收标准
列出项目的完成标准和阶段完成标准，完成标准作为项目验收的依据内容。
服务人员
请列出供应商的人员名单，及顾问资格信息。供应商人员的变更：描述在什么情况下可进行供应商人员的变更。
聘用条款
对聘用供应商人员的级别要求、经验要求及其他相关条款。
收费和付款方式
项目的付款方式、费用范围、涉税条款等。
变更管理
项目变更的管理过程、相关规定与约束条件等。
承诺
双方承诺均已阅读，理解并同意遵行上述协议书及其条款的约束。而且双方同意，所提到的服务条款及其附件(包括工作说明书和变更授权以及任何为双方协议中独立完整的陈述)，取代所有的建议书或其它在此之前的书面或口头协议以及有关的其他交流。
保密
遵守保密协议（保密条款另行签署）
签署接受
XXXXXXXXXX公司（供应商） xxxxxxxxxxx公司（发包商）
授权签名：_______________ 授权签名：_________________
姓名：_________ 日期：______ 姓名：_________ 日期：______
职位：___________ 职位：___________
我干的这行和机电工程差得实在太多了，只能说点虚的。
比较我对付过的SOW，我觉得你找的那个模版SOW里基本内容都有了：
（１）我开始干之前得有什么条件－假定
（２）我到底要干啥 － 范围、方法、人员和资源配置
（３）我干的时候你都需要干啥 － 对方责任
（４）我干出来的东西都是啥样 － 完成标准
（５）我啥时能干出来
（６）账怎么算 － 记时、记件，还是两种都有
（７）出了没有预见的问题怎么办。
但是，这上面的各项在机电工程中到底都是啥，我可是想破了脑袋也想不出来。不知道河里有没有对于这方面有经验的河友能不能给大家说说？
你所写的是国内PM的现状
实际上PM的活不应该是这样的，一个好的PM应该知道在什么地点、什么时候能摸到石头，如果眼瞅着到那个点了摸不到石头，PM应该知会到所有人，推动者大家去研究怎么想办法摸到这个石头。
我的屁股经常不是和PM被摁在一条凳子上，有偏颇不当之处，还请多指教。
写到这里，觉得还是要把我这儿说的PM给界定得更清楚一点。我这儿说的PM要起到的作用不同于传统意义上的管理者。PM是要在不增加人力和物力资源、不提高团队技术禀赋的前提下，只是通过对过程和流程的协调、调整，来提高团队的效率。我有关PM的经历只限于美国这个免煮柿油的地界，对中国国内的情况就不熟悉了。
回到上一段，我们说到这PM不是哪儿都管用，那为什么大爷、大娘们总是满腔热情地把PM满世界地发呢？
一种情况是公司正赚着钱，但看不到什么上升空间、也想不出什么太好的办法，就被擅长捣浆糊的管理咨询公司抓了个冤大头，捣出来的浆糊中十有八九有一瓶就是发PM。
第二种情况是大爷、大娘们自己制定的战略方向有问题，但总觉着是下面这帮人不得力，以为发了PM这帮人就能个个飞檐走壁了。
第三种情况是大爷、大娘们自己专业知识有限，但好奇心特别强，总是想知道下面这帮人到底都是在干啥，然后好加以指点。他们认为，如果PM能把下面这帮人干的事放到一个框架里，自个儿就能明白了。
第四种情况是出于一个有意无意间对成本的考虑。比如我们这儿，要是开发新盆景、同时又没赶上盆景卖得特别好的时候，招人的成本就是个问题。我们这儿招人，光土豆种得好的能找得到、光盆景栽得好的更是有的是，但是要找一个能照种土豆的成本种出来、还能按盆景的价钱卖出去、就不多了；而且呢，土豆种得好的一般都是单干出身，找一个没啥倔脾气、能跟窝棚里的大家伙们打成一片的、就更不容易啦。你再看PM，传说中的作用巨大，现实中的成本又低得多，于是大爷、大娘们又一次美梦成真，哈喇子一枕头。
再有一种情况，基本上就是掺沙子。在免煮柿油这种个人利益最大化是唯一最终目标的各类群体里，如果你是领导者，首位的问题就是不能失去对被领导部门的控制。一旦失去了控制，不管事情做得多好，都跟你没关系啦。所以，如果其它的手段（专业技能、明星魅力、忠实跟班等等）不能有效到令人满意的程度，PM及其所用的手段就不失为一种可选择的方法。
拉拉杂杂就写到这儿，我的看法是呢，在你没混到可以给别人发PM之前，不管你自己是被发的PM、还是你是有幸被发了PM，尽可能地知己知彼吧。
事实上PM的出现还有一种状况：比如某公司为了进入某市场而要达到某指标（比如CMMI....），于是强制所有部门都加了PM的位子....
PM和大牛设计师合二为一了：这样一般来说Project Plan的预算和预估工期会比较准确，同时也简化了大家交流的步骤，PM自己在跟老板要人要钱要资源的时候也会硬气不少
最好的PM还是由工程师转, 这样就做到了PM和设计合二为一.
但是PM在老板眼里就是有了你PM了, 我不管, 反正就这么点时间, 这么几杆枪, 搞不定就是PM的错.
然后老板就度假逍遥去了.有点像甩手掌柜.
有时候这样也就算了, 可惜有些老板还有时候要出面展示一下肌肉, PM你这样不对那样不对, 然后把Plan搞的乌烟瘴气之后他走了.
最近我就在受这个气.