我也非常赞同甲方不要指手画脚的指挥，这种强势性领导的结果就会是强势方的实力决定了，不是团队的效果，乙方唯唯诺诺的，成了干活的杂役了。效果的确不好。

沟通、管理的目的都是要激发团队成员（包括乙方之类的人）的“自我管理”，就是他们积极主动的完成自己的事情，还会帮PM想哪些地方会有漏洞。所以一个团结、合作愉快的团队效率会非常高。

2、甲方不信任乙方的后果

这个我也是深刻体会，因为我们的项目就是甲方不信任乙方，然后因为我们的业务部门老大又选了他，我们（IT和业务部门的几个底层人员与乙方）在前期又谈崩过，所以就是甲方的人拼命的考虑合同，怕有东西写漏了，乙方的也拼命的改合同，那段时间，我们甲方改合同的这几个和乙方改合同的这几个差点改崩溃。即便是这样，我们也很清楚，有很多事情是合同之外的，很多事情都是可以协商的，但要看双方态度怎么样。

之后，大家的阴影都很重，有一点事情就会想，当初怎么样怎么样。大家其实是处于一种脆弱的信任关系，非常容易破裂的。

3、倒霉的甲方
只是我们非常郁闷，因为乙方的有点为所欲为了。这个词还真不是瞎说的，我们简直倒霉至极，这个乙方的PM简直可以用见鬼的形容。比如，叫他需求调研完了写报告，人家说不用，说了3遍就是不写，因为选供应商这件事上我们和业务部门也闹翻了，他们的中高层选择的这个供应商，所以这些事情都是业务部门协调，IT 把问题、原因都告诉业务部门了，业务部门的人不太理会（他们因为没有项目经验，所以不太重视）。乙方的PM一看，太爽了，甲方是业务部门协调，业务部门的人不太懂又太好说话，就开始无法无天了。

牛到什么程度吧？培训，给全集团十几家厂培训，他说的流程是错误的，后来我们的测试人员发现了，乙方的PM说“我也不知道啊，没人给我培训啊”！还有一个功能，昨天还好好的，今天就不能用了，乙方的PM说“本来就没这个功能”！这些都冰山一角，凡是出一点问题，乙方的PM就是“我也不知道啊，没人告诉我啊”！简直牛到了姥姥家。他们后来来一个高层和我们交流，我们告诉他们高层乙方的PM这样了，人家也不管。我们简直可以吐血了。

关键还是业务部门因为选了这个供应商吧，就心虚，就拼命掩着盖着，替乙方说话。出那种问题，还说“你们沟通不清楚”。乙方的又太不知道收敛，最后才导致连业务部门的这个人都倒戈了。

其实我很奇怪的，一般的乙方都很好的，甚至被甲方打压着喘不过气，这个项目正好相反，我们倒霉得没脾气得不成话。

最后我们对他们不信任到什么程度吧，我们全部自己使用功能，除非bug，否则绝对不问他们，问了乙方一个功能有没有，行不行，他也胡说八道。最搞笑有一次，下面企业的问一个功能行不行，乙方的说可以，我说不可以。开会揪出这个事情了，乙方的理直气壮的说我测试过，我冷笑，现场当着所有人的面测试，果然不行，如我所说。人家就因为“下一步”按钮没点，点了就会弹出错误的提示框了，人家测了前面就不点“下一步”，这个责任心……真是让我无语呀。

他们给个补丁，我们要狂测试好久才敢用。因为以前几次，给一个补丁，得，打上之后其他程序用不了了，因为前面几次我们也大意了，没完全测试就上了，就看补丁的功能可以了，没看其他功能是不是不能用了。和乙方理论，要求他们加强测试，乙方的理直气壮的说“因为你们测试系统最近出问题，你们没测试导致的”！ 5555555，谁见过我们这么倒霉的甲方？

tony_sy ，不是和你对着干啊，我只是回忆起心酸的过去，忍不住发发牢骚。我必须承认，这种情况简直万里挑一，可是我们跟中彩票似的居然中了。以前别的项目，乙方真的很好，甲方的有些人就太不厚道了，该自己做的都推给乙方，乙方的都默默接收了。这种甲方的不厚道的人我也很不赞成。

一直在做乙方，开始的时候认为对甲、乙方的关系是针对的。后来慢慢的感觉其实大家应该是真心合作的，当然，除了谈价格外；）。

此外，对于这个项目额情况个人感觉这有点涉及到公司内部的问题了，比较政治化的问题。记得几年前看过一篇文档，是讲的在信息化过程中存在的公司政治，其时很有感触，当时还特地买了类似的书来看。

信息化项目总是涉及到相关人员的利益，有时很明显：某些人是收益者、某些人的利益被限制。这实际上就是项目管理中的干系人管理。根据定义：项目干系人是所有与项目相关的人。所以在一个项目中干系人的数量就会很多。

处于不同位置的干系人在项目中的目标其实并不一致，所以在项目中有一个目标妥协的过程。尤其在大项目中更是如此。个人认为只有在这种项目中沟通技巧起到的作用尤其之大。

比较阴暗的讲：项目干系人的管理实际上是对干系人在项目中的利益进行管理，沟通的目的也在于此：陈述厉害，让各方面在某一点上达成妥协。至于沟通的效果，其实在于你手工有多少张牌可以打，如果没有话语权，就只有厥嘴干活了，这种情况下责任可以不负，这是要跟各方讲清楚的；有话语权，就要利用好这种权利，为自己的目标服务。

其实项目管理是与日常的管理方式在很多方面相关的，所以个人在关注项目管理方式的同时，也涉及了些管理方面的内容，感觉还是不错的。

共同讨论，共同进步啊：）

比如在这个项目中，可以将项目干系人分为以下几类：

业务部门：项目使用者、需求提供者、还有部分决策职权
IT部门：项目监控者
本公司老总：项目决策者
乙方：项目执行者

其实分析下来，IT 部门在这个项目中的话语权并不是很大，有点被排挤的感觉。如果这样，还不如跟老总讲，让业务部门直接复制项目的进度，而把自己定位为一个为业务部门服务的角色，游离这个项目中，可能楼主就不会有现在的那种感觉了。

不是很了解项目情况，瞎猜的，分析也不会很透，供参考。

这一点在项目中是非常关键的，就像PMBOK里面讲的influencer，这些人也要搞清楚。

其实这个项目中郁闷的是我，明明看着是悬崖，业务要跳，我只能傻看着。但是高兴的是我的老板W。这是个很阴暗的心理，也是我暗自揣测的，说了大家不要鄙视我的人品啊。我的老板因为在选供应商这件事上没有得到业务部门老大的同意，所以其实就是要搞他们一下。我就是觉得告诉我老大项目出问题了他好像很高兴。

但是不能告诉更大的老总BOSS，我们和业务部门是这样的情况。
1、BOSS其实太聪明了，说穿了就知道问题根结，而且马上就知道是供应商选型的事情出了问题。那么一来把业务部门的老大给卖了，得罪了人就傻了；二来，BOSS对我们部门印象也不好，因为觉得我们推责任。

2、我的老大W推责任其实也有道理，供应商我都没法选，我否定的你非要选，那么承担你选供应商的后果，我不是傻瓜？

3、我的老大W其实留了一手，虽然供应商和他闹翻了，但是万一项目做得也不错，我们不是又傻了。所以他命令我项目还是好好做，有问题一定要暴露，只一点不同，凡是要协调和决策的，一定要业务部门来协调来决策，而且事先话一定要说清楚，可能有什么问题，风险是什么等等。这样做好了，我们肯定也要分一羹，可是做砸了，供应商你们选的，决策你们做的，我们该做的都做了。也让BOSS抓不着把柄。如果话说白了，呵呵，我们人得罪了，做什么也分不了一羹了。

办公室当然是有政治的，PM们要分清楚政治风向标呀。前面说的如果遇到老大们打架，就老老实实传话，千万不要参杂个人意见。不要歪曲任何意思。如果有老大问，那个老大什么意思，就乖点说，不知道喔，装傻呀，千万别多嘴……

虽然我认为很少有PM会犯这个错误，但是今天突然想起来了，觉得还是说一说比较好。周报是干嘛的？其实很多时候虽然是一个formal written的DD，但是最大的作用我认为是保持所有人对项目的关注度。让一些更大的BOSS、边缘的team member、边缘的stakeholders保持对项目的关注度；让 core team有成就感：我们做了那么多，还报告领导了。我认为，周报或者叫周期性报告不是解决问题的，只是陈述性、总结性的。

一旦有了问题要马上汇报！当然还要考虑上级领导的风格（他是事无巨细都关注型还是抓大放小型）和PM的权利（什么样的问题有决策权）。但是一旦有了 PM搞不定的问题是要马上汇报。你想周期性报告一周一次？一月一次？那时候黄花菜都凉了。所以马上汇报！不要怕你的领导。耽误了时间更可怕。

总结一下，有了PM搞不定的问题要马上汇报！周报、周会做什么用的？保持所有人（包括非core team）的关注度，这个会不是解决问题的，是讲讲总结（上一个周期干什么了）讲讲计划（下一个周期每个人要做什么）讲讲问题（上个周期出什么问题了，我们怎么解决的）和讲讲风险（下一个周期可能出什么问题，要注意什么）的，总之不是解决问题的。出了问题要随时解决、即时解决。

说真的，这个也没什么好办法，基本原因还是因为大家太不诚信了。

而且工作量的估计也是个问题，比如，甲方算工作日最爱算开发需要的工作日，乙方肯定把测试的时间也加进去，虽然标准的比例大概是4：2：4，构架时间4成，开发时间2成，测试时间4成，但是乙方多半在测试上大砍时间，构架时间也缩小很多，大家拉拉扯扯的很难说清楚。

同情乙方啊……很多时候一个聪明的乙方老大能作用很大，遇到这种情况一般来说PM处理不了，还是要聪明的乙方老大和甲方老大解释会好很多。