项目经理与敏捷开发

项目第一阶段结束，各个组员也在本身学习相应的知识，没有人催促他们去学习，也没有人上网聊天看电影之类的，这样一个氛围的造成，和项目组中项目经理有很大的关系。我本人也是敏捷的拥护者，刚好今早看博客园时看到两篇文章：有些感慨很想写下来与各位分享一下。

第一篇：敏捷中的沟通与故事点

第二篇：亲爱的项目经理，我恨你

第二篇是今天的推荐新闻，笑点不少也很让人沉思

1、项目经理在项目中到底是什么角色

      国内的氛围是“学而优则仕”，放到软件开发领域也是同样，很多开发人员向往管理岗位，一是以为技术领域突飞猛进，学习上感受吃力；二是长江后浪推前浪，前浪死在沙滩上，技术上新人更有一股狠劲，而年纪大了的开发人员面临婚姻、子女、父母的诸多问题难以拼命了，身体也大不如前；三是几千年的文化造成要作人上人，必须管理人的观念。

     上述三个方面没有对错，我只想说若是你对技术没有持续的热忱，你想向项目经理或管理领域发展时，就要明白项目经理这四个字背后的含义。

一、  项目经理的心态

      永远不要将本身作为一个传统意义上的管理者（决断、控制、平衡），传统领导力在IT企业里是玩不转的，一群高智商的员工广泛有着本身的骄傲和尊严，你的能力再突出，能比得上全部你的小组成员的累加值吗？

      项目经理永远在内心要告诉本身“我是一个服务者”，认识到在IT企业里，员工须要的是新的领导力（决策、协商、服务）。

      讲个小故事，有点偏颇不常见，但也许能让你们有一些共鸣：

     之前有个加、美、印和离岸外包地（中国）的合做项目，加国派来一个需求分析师，米国派来的是个协调人员（你们能够当作项目助理吧），阿三国派来的是个架构师。帝国本部选一个“技而仕”的项目经理来主持这个项目。加国是个大汉，语速快手势多，米国是个大叔，精干语少但经常关键时候发炮攻击，阿三比较随和但经常有些莫名其妙的优越感，对反对意见彻底听不进去。四方开会的时候，让我想起了我如今团队里一个兄弟爱玩的四国军棋，充满了地雷和诡计，经常一个会几个小时下来，各方都没有达成一致。加国大汉愤怒地写了好几封公开邮件指责团队效率低下影射攻击项目经理，米国人看不起阿三，在技术上攻击不了阿三只好说这个团队彻底不知道业务，阿三指责团队合做力不足。总之是一团乱帐，可怜的项目经理彻底没见过这阵势，本身团队精心提出的架构，阿三老是挑鼻子瞪眼，需求更是彻底没有边界，不知道加国大汉是想要什么，米国人到是清闲反正他是表明甲方的，一副看好戏的样子。公司没办法，项目经理搞得想辞职，团队成员更是被激起了愤青的情绪。最后迫于无奈，公司把一个副总委派下来直接担任项目经理，原项目经理做为该项目的技术经理。

       这个副总一下来，在团队会议上没有指责任何人，只是笑眯眯地说“兄弟我是门外汉，对技术一窃不通，各位都是专家，个人主要职责就是服务好你们”。会后，这个副总搞了几回联谊会，带着你们搞野餐、郊游、亲子聚会，工做时竭尽全力的安排你们的后勤，天天下班前都会问你们次日的茶点和水果安排。私下里呢，和米国人的上司沟通了几回，对项目中的风险进行了分析，要求米方更多地对需求进行干涉和确认。没过一周，团队的氛围正常了，加国大汉发现本身的奇思妙想的需求被米国人拦了几回后也放弃那些不着边的想象力了，米国人也收到了上司的邮件要求他确实的担负起需求确认的责任，阿三在副总的几回游山玩水和推心置腹后，也老实了，对于架构的事也没那么吹毛求疵了，项目组间的沟通基本上正常了，项目总算正常推进了。最后项目结束的时候，这三个老外怀着感激之心离开，连连说还要再来伟大美丽的中国。

         这个项目里，项目经理彻底不懂技术，他的理念里只有“服务”这一个词，项目的进度固然是他关心的，但项目的质量和成本他彻底放手给项目组成员去作。

         关于项目经理需不须要懂技术，见仁见智，但我以为项目经理懂技术不是坏事，特别是国内目前中小型项目居多的状况下，项目经理彻底不懂技术很危险。

         新的领导力，核心就是一句话“我能为您们作什么？我还能为您们作什么？我有什么能够帮助您们的吗”，在中国，领导天然而然地就会有一些威严，你只要时不时的严肃一下，你们会知道你的威严，但这个“信”字就不是这么容易创建了。若是你不把本身当一个服务者，而是一个控制者，试问谁喜欢在这样的领导手下作事，IT本就是一个讲究创造力的行业，守着一个只想流水线生产代码的领导，工做有乐趣么，我的有成就感么。很差听地说，这叫死气沉沉。

二、  项目经理的意识中要有决策而不是决断

      项目经理永远是一个指导者而不是皇帝。

      今早园子里的敏捷中的沟通点与故事点中有这么一段话

　　首先，任务分配这件事情是我一手包办了，我和团队成员之间仍然是分配与被分配的关系，这和敏捷的自组织相抵触。其次，我分配出来的任务迫于时间的压力，欠描述，和敏捷提倡的故事点有距离，一般就一句话或一张图片。团队成员要处理这些任务，有时还要和我进行进一步的沟通。固然，这个过程还算有效，毕竟我已经用这种方式成功地完成了数不清，各类规模的项目了。

      说实话，这种方式培养不了优秀的开发人员，只能培养没有主动思考的代码机器。好的方式是，哪怕你和客户谈个普通优先级的需求，你也须要把你的关键组员带着去，一方面可让你们集思广益了解需求，一方面能够锻炼你的组员的沟通，一方面可让客户与小组的关系更融洽。

　　在亲爱的项目经理，我恨你也有这么一段话，我本人很认同：

       你是一个信息黑洞

　　你更善于积极跟你的上级管理者交流沟通，而不是跟你管理的团队。结果，重要的项目信息根本存不到你脑子里，只有在一些特殊时期，一般是上线最后期限的前几天，你才会关注。上级管理者和开发人员之间出现了一堵墙，你就是阻挡信息流通的那堵墙。

      要知道你领导着一群渴望成长、渴望成就的员工，他们是你的支撑是你的财富，金钱都有个杠杆效应更况且活生生的人，你不能发挥他们，这些人早晚会离开你。钱要发挥效应必须会投资，人要发挥能力必需要让他们尝试和主动。而若是你作的事是想像流水线的富士康同样的工人，那你的团队必然是一群呆头鸭。    

     项目经理要作的事是和团队一块儿决策而不是独自判断，你甚至要学会受权在细节上让团队拥有充分选择的权力，在可有可无的技术细节上你考虑的越多，你给他们的限制就越多，你只要对架构、高优先级需求、质量和进度多加关注就好了。准确的说，项目经理是团队的“核心交换机”，你这里的传递的信息量越大，项目和团队的受益才会越大。

2、项目经理与客户的关系

         既然是核心交换机，项目经理与客户那里更多的就象是一个防火墙，防止需求越界，防止客户的攻击传递到团队内部，软件开发团队的士气很容易受打击，开发人员也有生理周期，一个有趣的现象是，呆得越久的团队，其生理低潮也越同步。

         项目经理和客户的负责人，应该是合做的关系，你们利益一致是要项目经理时时保证和提醒对方的，毕竟对方也是人，也想在企业内树立政绩，保不许头脑发热提出一些天马行空的想法，这些想法不要急着去否认，按事实一条条分析，按技术一条条陈述。实在不行，出来吃个饭，洗个脚，坦诚相对一下（先说我很讨厌声色犬马那套，我和客户通常就是吃个饭喝个洒），不少问题在感情因素的影响下会得到一个平衡。

         要明白，你和甲方的负责人永远不是博弈，而是利益的共同体，一荣俱荣，一损俱损。

         而项目组内部，你这个防火墙要传递的是客观的需求和评价甚至批评，甚至你要把你内部那些组员带出来到防火墙外测试一下，经受一下客户的考验，回来后他们会更理解客户（人）而不是软件（代码），软件是给人用的，不是给机器用的。

3、项目经理与公司的关系

         项目经理是公司的为将者，为将者对公司要服从大局，多站在老板的角度考虑，固然为将者，也要有将在外，君令有所不授的觉悟。项目经理不要伦为马屁精，那样与项目没有半点好处。要学会常常汇报，学会争取资源，学会向老板提出问题并根据问题拿出A、B、C几套解决方案供他选择。学会时不时的参政（不要议政）。

        

         好了，大体上个人感慨发完了。

 项目经理不是传统意义上的管理者，他是教练是指导者，他的做用在于发挥成员的能力，与客户作好沟通，把握项目风险及时预警和解决。

 项目经理对进度、成本、质量负首要责任，但你要学会受权。

 项目经理适当地要掌握技术，保持coding everyday的习惯。

 项目经理是团队的灵魂，要学会给团队成员打气和招魂。

 项目经理是孤独的，团队成员不可能成为你真正的朋友，公司高层也不能。

 项目经理这条路不是终点，前方的路还很长。