项目第一阶段结束，各个组员也在自己学习相应的知识，没有人催促他们去学习，也没有人上网聊天看电影之类的，这样一个氛围的形成，和项目组中项目经理有很大的关系。我本人也是敏捷的拥护者，恰好今早看博客园时看到两篇文章：有些感慨很想写下来与各位分享一下。
第一篇：敏捷中的沟通与故事点
第二篇：亲爱的项目经理，我恨你
第二篇是今天的推荐新闻，笑点很多也很让人沉思
一、项目经理在项目中究竟是什么角色
国内的氛围是“学而优则仕”，放到软件开发领域也是一样，不少开发人员向往管理岗位，一是觉得技术领域日新月异，学习上感觉吃力；二是长江后浪推前浪，前浪死在沙滩上，技术上新人更有一股狠劲，而年纪大了的开发人员面临婚姻、子女、父母的诸多问题难以拼命了，身体也大不如前；三是几千年的文化形成要做人上人，必须管理人的观念。
上述三个方面没有对错，我只想说如果你对技术没有持续的热忱，你想向项目经理或管理领域发展时，就要明白项目经理这四个字背后的含义。
[h1]1、 项目经理的心态[/h1]
永远不要将自己做为一个传统意义上的管理者（决断、控制、平衡），传统领导力在IT企业里是玩不转的，一群高智商的员工普遍有着自己的骄傲和尊严，你的能力再突出，能比得上所有你的小组成员的累加值吗？
项目经理永远在心里要告诉自己“我是一个服务者”，认识到在IT企业里，员工需要的是新的领导力（决策、协商、服务）。
讲个小故事，有点偏颇不常见，但也许能让大家有一些共鸣：
以前有个加、美、印和离岸外包地（中国）的合作项目，加国派来一个需求分析师，米国派来的是个协调人员（大家可以看成项目助理吧），阿三国派来的是个架构师。帝国本部选一个“技而仕”的项目经理来主持这个项目。加国是个大汉，语速快手势多，米国是个大叔，精干语少但常常关键时候发炮攻击，阿三比较随和但常常有些莫名其妙的优越感，对反对意见完全听不进去。四方开会的时候，让我想起了我现在团队里一个兄弟爱玩的四国军棋，充满了地雷和诡计，常常一个会几个小时下来，各方都没有达成一致。加国大汉愤怒地写了好几封公开邮件指责团队效率低下影射攻击项目经理，米国人看不起阿三，在技术上攻击不了阿三只好说这个团队完全不知道业务，阿三指责团队合作力不足。总之是一团乱账，可怜的项目经理完全没见过这阵势，自己团队精心提出的架构，阿三总是挑鼻子瞪眼，需求更是完全没有边界，不知道加国大汉是想要什么，米国人到是悠闲反正他是代表甲方的，一副看好戏的样子。公司没办法，项目经理搞得想辞职，团队成员更是被激起了愤青的情绪。最后迫于无奈，公司把一个副总委派下来直接担任项目经理，原项目经理作为该项目的技术经理。
这个副总一下来，在团队会议上没有指责任何人，只是笑眯眯地说“兄弟我是门外汉，对技术一窃不通，各位都是专家，我的主要职责就是服务好大家”。会后，这个副总搞了几次联谊会，带着大家搞野餐、郊游、亲子聚会，工作时不遗余力的安排大家的后勤，每天下班前都会问大家第二天的茶点和水果安排。私下里呢，和米国人的上司沟通了几次，对项目中的风险进行了分析，要求米方更多地对需求进行干涉和确认。没过一周，团队的氛围正常了，加国大汉发现自己的奇思妙想的需求被米国人拦了几次后也放弃那些不着边的想象力了，米国人也收到了上司的邮件要求他确实的担负起需求确认的责任，阿三在副总的几次游山玩水和推心置腹后，也老实了，对于架构的事也没那么吹毛求疵了，项目组间的沟通基本上正常了，项目总算正常推动了。最后项目结束的时候，这三个老外怀着感激之心离开，连连说还要再来伟大美丽的中国。
这个项目里，项目经理完全不懂技术，他的理念里只有“服务”这一个词，项目的进度当然是他关心的，但项目的质量和成本他完全放手给项目组成员去做。
关于项目经理需不需要懂技术，见仁见智，但我觉得项目经理懂技术不是坏事，特别是国内目前中小型项目居多的情况下，项目经理完全不懂技术很危险。
新的领导力，核心就是一句话“我能为您们做什么？我还能为您们做什么？我有什么可以帮助您们的吗”，在中国，领导自然而然地就会有一些威严，你只要时不时的严肃一下，大家会知道你的威严，但这个“信”字就不是这么容易建立了。如果你不把自己当一个服务者，而是一个控制者，试问谁喜欢在这样的领导手下做事，IT本就是一个讲究创造力的行业，守着一个只想流水线生产代码的领导，工作有乐趣么，个人有成就感么。不好听地说，这叫死气沉沉。
[h1]2、 项目经理的意识中要有决策而不是决断[/h1]
项目经理永远是一个指导者而不是皇帝。
今早园子里的敏捷中的沟通点与故事点中有这么一段话
首先，任务分配这件事情是我一手包办了，我和团队成员之间仍然是分配与被分配的关系，这和敏捷的自组织相抵触。其次，我分配出来的任务迫于时间的压力，欠描述，和敏捷提倡的故事点有距离，通常就一句话或一张图片。团队成员要处理这些任务，有时还要和我进行进一步的沟通。当然，这个过程还算有效，毕竟我已经用这种方式成功地完成了数不清，各种规模的项目了。
说实话，这种方式培养不了优秀的开发人员，只能培养没有主动思考的代码机器。好的方式是，哪怕你和客户谈个普通优先级的需求，你也需要把你的关键组员带着去，一方面可以让大家集思广益了解需求，一方面可以锻炼你的组员的沟通，一方面可以让客户与小组的关系更融洽。
在亲爱的项目经理，我恨你也有这么一段话，我本人很认同：
你是一个信息黑洞
你更善于积极跟你的上级管理者交流沟通，而不是跟你管理的团队。结果，重要的项目信息根本存不到你脑子里，只有在一些特殊时期，通常是上线最后期限的前几天，你才会关注。上级管理者和开发人员之间出现了一堵墙，你就是阻挡信息流通的那堵墙。
要知道你领导着一群渴望成长、渴望成就的员工，他们是你的支撑是你的财富，金钱都有个杠杆效应更何况活生生的人，你不能发挥他们，这些人迟早会离开你。钱要发挥效应必须会投资，人要发挥能力必须要让他们尝试和主动。而如果你做的事是想像流水线的富士康一样的工人，那你的团队必然是一群呆头鸭。
项目经理要做的事是和团队一起决策而不是独自判断，你甚至要学会授权在细节上让团队拥有充分选择的权力，在无关紧要的技术细节上你考虑的越多，你给他们的限制就越多，你只要对架构、高优先级需求、质量和进度多加关注就行了。准确的说，项目经理是团队的“核心交换机”，你这里的传递的信息量越大，项目和团队的受益才会越大。
二、项目经理与客户的关系
既然是核心交换机，项目经理与客户那里更多的就象是一个防火墙，防止需求越界，防止客户的攻击传递到团队内部，软件开发团队的士气很容易受打击，开发人员也有生理周期，一个有趣的现象是，呆得越久的团队，其生理低潮也越同步。
项目经理和客户的负责人，应该是合作的关系，大家利益一致是要项目经理时时保证和提醒对方的，毕竟对方也是人，也想在企业内树立政绩，保不准头脑发热提出一些天马行空的想法，这些想法不要急着去否定，按事实一条条分析，按技术一条条陈述。实在不行，出来吃个饭，洗个脚，坦诚相对一下（先说我很讨厌声色犬马那套，我和客户一般就是吃个饭喝个洒），很多问题在感情因素的影响下会获得一个平衡。
要明白，你和甲方的负责人永远不是博弈，而是利益的共同体，一荣俱荣，一损俱损。
而项目组内部，你这个防火墙要传递的是客观的需求和评价甚至批评，甚至你要把你内部那些组员带出来到防火墙外测试一下，经受一下客户的考验，回来后他们会更理解客户（人）而不是软件（代码），软件是给人用的，不是给机器用的。
三、项目经理与公司的关系
项目经理是公司的为将者，为将者对公司要服从大局，多站在老板的角度考虑，当然为将者，也要有将在外，君令有所不授的觉悟。项目经理不要伦为马屁精，那样与项目没有半点好处。要学会经常汇报，学会争取资源，学会向老板提出问题并根据问题拿出A、B、C几套解决方案供他选择。学会时不时的参政（不要议政）。
好了，大致上我的感慨发完了。
项目经理不是传统意义上的管理者，他是教练是指导者，他的作用在于发挥成员的能力，与客户做好沟通，把握项目风险及时预警和解决。
项目经理对进度、成本、质量负首要责任，但你要学会授权。
项目经理适当地要掌握技术，保持coding everyday的习惯。
项目经理是团队的灵魂，要学会给团队成员打气和招魂。
项目经理是孤独的，团队成员不可能成为你真正的朋友，公司高层也不能。
项目经理这条路不是终点，前方的路还很长。
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/255750.html