高级项目管理小论文，纯属胡TM扯淡，但好歹是原创故放在此供接口水
----
不管你主要使用的开发工具是J2EE还是.NET，职位是测试员、程序员，或者是项目经理，在最终的工作中只要你属于一个工作团队，进行某种旨在完成一个特定项目的工作，对项目管理这门学问的了解程度都会在很大意义上成为你最终成功的重要指标。普通项目成员需要项目管理的知识来更好理解自己所需要完成的任务，而项目经理则更需要用最高效的方法来对整个团队进行管理，完成上级的目标的同时，也带领整个项目团队赢得团队胜利。
而在整个完成项目的过程中，团队成员之间的沟通究竟有多么大的意义，只有在亲身进行过项目工作后才能深切体会。尤其是在软件项目中，那种“每个人做完自己的工作，整个项目就可以顺利完成”的想法早就被证明是绝对不可取。将团队沟通这项更多与个人自身性格密切相关的工作彻底系统化是一个不可能完成的任务，但我最近亲身经历的一些事例，以及阅读了相关书籍后的感想可以简单阐述团队沟通的重要性。
在最近的某门课程中，根据教授要求，全班被分成了三个小组分别完成教授安排的项目。我所效力的小组中的5名成员没有一个对教授所要求掌握的visual studio.net拥有足够的经验，是所有小组中平均水平最低的，也是最终完成项目困难最大的。而在开发过程中，作为类似项目经理角色的组长之一的我（5名组员中4名中国人，1名美国人，我和美国人出任双组长），在不知不觉中完成了许多从项目管理中学习到的知识。
比如在第一次会议中，我们基本明确了每个项目成员的技能，在了解了我们由于对.NET的不熟悉而即将面临的巨大困难后，我们并没有简单地“你去学这个，你去学那个，一周之内必须熟悉”进行学习任务的分配，而是先冷静下来，表述了项目的重要性，希望大家在力所能及的范围内尽量迅速地开始工作。我们很快就归纳出了我们目前拥有的技术能力：我有过3个月的C#开发经验，尽管非常有限，但对代码的适应性要强一些，也可以帮助其他成员进行.NET平台学习最基本的操作，节省了初学者一开始浪费在学习如何建立项目，建立HELLOWORLD的大量时间。而其他人中，一名组员对数据库内部管理有着熟练的掌握，两人在与C#非常类似的JAVA开发中拥有不错的经验，理论知识也比较扎实。
我们同时明确在整个开发过程中，必须随时保持联系，以便在每个人得到最新情报和开发中问题解决方案时能够第一时间在所有组员中传达开来。此外由于以前的长期相处，我们的组员之间关系已经十分融洽，这对我们之后的团队沟通有着不可或缺的作用。因为在其他某小组中，四名成员住在四个地方，性格差异较大，最终导致他们的沟通不够流畅，甚至还曾经发生过误会，最终尽管同样及时完成项目，但在某些方面还是没有达到教授的要求，一些性能也逊于我小组的项目。
尽管最终成功完成了项目，但在回头总结整个项目的进行过程中，我意识到这次小型的项目开发模拟中依然无法掩盖我在项目管理上很多不成熟的地方。一些只有在实际工作后才能够体验到的团队工作依然没有体验的机会。比如在对团队成员的鼓励方式上，在学生时代我们只能通过精神上和极少数的物质上的奖励来鼓励组员及时乃至提前完成任务，而且即使没有任何奖励，很多学生项目组同样可以顺利完成教授的要求。而到了工作中一切就都不一样了。按照米歇尔-勒波夫在《世界上最伟大的管理原则》中的说法就是，“当今许多企业、组织之所以无效率、无生气，归根到底是由于它们的员工考核体系、奖罚制度出了毛病。而对今天的组织体而言，其成功的最大障碍，就是我们所要的行为和我们所奖励的行为之间有一大段
距离。”，“我最终发现的这条世界上最伟大的管理原则就是：“人们会去做受到奖励的事情。”
同时，在这本书中，勒波夫还描述了在项目中对普通组员进行奖励时所常犯的错误，按照他的说法，每个项目经理都有必要在考虑用一些手段给组员提升士气前，好好考虑一下“我们是不是口头上宣布讲究实绩、注重实效，却往往奖励了那些专会做表面文章、投机取巧之人?”，“我们是不是口头上宣布员工考核以业绩为主，却往往凭主观印象评价和奖励员工?”..这样非常简单却也非常实际的问题。
当然，与团队之间的沟通不只是平日工作的沟通，上下之间的奖罚措施，团队胜利目标之下，如果每个人能够明确自己的目标，那样不仅在团队沟通中有着足够的底气和信心，也会提高团队管理的效率。首先，项目经理需要明确，绝对不能将自己摆在一个命令者的位置上。“你做这个，你做那个，必须两周之内完成！我度假回来之后验收，不得有误”，这种话放在一些没什么前景的基层小公司里可能还吃得开，但在当今竞争如此激烈的软件市场，如果作为项目经理的你跟手下的高水平人才们说这种话的话，那你的项目组就会有麻烦了。如巴斯-德巴尔在《Surprise! Now you’re a software project manager》所讲的一样：“首先，你需要问自己，你需要什么，你能够为这个项目做些什么。你是否了解客户的需求？你是否认为自己能够完成很好的管理？你是否真心相信自己负责的项目能够顺利完成？”在对项目组员进行各种要求前，一个没有考虑这些问题的项目经理是完全不够格的。我始终认为，一个理想的项目经理应该同时出任该项目的高级程序员，负责工作也许未必是工作量最大的部分，但至少要负责一些与大多数成员都有密切关系的核心工作，从而在主持会议的同时有足够的“资本”与组员进行沟通。在一个喋喋不休的命令者和一个高水平的项目队友之间，正常心态的组员会偏向与哪种人合作呢？
而过于与组员打成一片，与每个人都称兄道弟的项目经理是否会肯定取得成功呢？这个问题没有准确的答案，江湖气比较重的公司照样有机会取得成功，但如果一个项目经理真的这样做的话，将整个项目组变成天天一起喝酒打游戏的“大学生集团”的可能性要比变成成功项目组大了不少。“没有一个项目经理能够让所有组员100%满意，也没有一个项目组能够实现真正的100%成员成为胜利者。”一些在成本花费或者工作效率中表现不让人满意的组员理应在项目顺利结束后得到相应的处罚，即使项目经理不执行，上级也会执行。因此建立更加妥善的赏罚机制，保持与组员良好工作关系的同时注意避免结成一个个小圈子，或者跟组员变成了天天喝酒无话不谈的损友，都是项目经理应该注意的部分。他应该在力所能及地范围内，让所有的组员最终都能够有一个可以接受甚至满意的结果。
最后，作为从前从事过其他行业而目前从事软件行业的人员，其他项目管理和软件项目管理有着多少共同之处，是我一直很关注的话题。团队沟通这一内容在任何由多人组成的项目组中都会是项目经理所处理的要务，具体到软件项目中的比喻就是“将材料放进锅里、炒菜、将材料放进锅里、炒菜，反反复复的项目工作中，如何保证饭菜原料中的各种美味能够将自己的味道综合起来而不是相互抵消，甚至是做出一些更加糟糕的东西。”而且鉴于目前残酷的形势，如果你对上级说出了“我这盘菜炒糟糕了，再给我一些原料让我重新做一次吧”这种话，相比那些依然可以在其他小组中重新发挥能力的组员，身为项目经理的你就会有大麻烦了。至今，看似简单却永远没有最完美的公用解决方案的团队沟通工作，已经让很多人丢掉了饭碗，但如果你掌握了这门艺术，最终它会帮助你将成功之路拓宽很多倍。
参考：
米歇尔-勒波夫 《世界上最伟大的管理原则》
Bas de Baar 《Surprise! Now you’re a software project manager》
RVL
没有评论:
发表评论