现在大家谈论软件项目管理的比较多，但一般都是从项目出发来谈项目管理的方法、规律、经验。在软件项目的管理中，最普遍的形式是项目经理制，本文试图从项目经理出发来谈项目管理的问题。
对于大部分软件项目的项目经理，可以这样来作个定义：项目经理是对项目负责，管理、协调项目全过程，对项目的人员、可用资金、工作内容、进度等各个方面因素进行统筹调度、合理计划，督查项目实施过程，解决项目进行中各类矛盾、确使项目成功的一种角色。
当项目经理接受一个软件项目开发及实施的任务时，一开始往往是千头万绪，例如：
——上级对你说，项目就交给你了，这些人都由你安排/监督，你先制定一个管理制度和开发计划给我；尽量提高效率，客户要求某月某日前先看到一些某某成果，你要在某月某日先让我看到一些某某成果；年底要评先进部门，你们项目组争取给部门争光；公司要求压缩行政开支，各方面你们要注意节约点，加班时注意节约用水用电……
——客户/成果接收方对你说，我看到过某某软件公司的网上升级方式，蛮好，你们把这个功能做上去；我们有些部门网络、电脑都比较烂，你最好想个办法让我们提高速度；我们头说他喜欢蓝色基调，界面上要你们先提供一些样子，他先看看；我们想报今年的市先进成果奖，你们先帮我们准备一些文档吧，要突出某某方面的亮点；某月某日某领导要来视察，你们要把某某功能做得尽可能形象……
——你打开原始需求细看时，发现大量的篇幅只在描述普通的功能需求，而散在各个角落里的轻描淡写的一些语句却隐藏着复杂的技术问题……
——你的上级告诉你，他配给你的团队里有参加过重大项目的“优秀”程序员，有来自名牌大企业的技术“骨干”，有考过各种证书的好手；你把他们叫来时，他们带着“个性”的架子姗姗来迟；你问：XX技术熟悉吗——不熟悉；XX开发工具用过吗——只听说过；XX的GUI开发是你的强项，经理跟我说你曾解决过一些比较难的技术，本项目中有一个XX技术问题，你能解决吗——我要到网上找找看有没有类似例子——网上没有呢——那谁能做啊……
——经理告诉你，公司其他部门会尽力配合项目组的工作，并希望项目尽快启动。你因为项目需要，要申请一笔款子，报告拟好了，财务告诉你要找某某头签字，你发现某某头经常不进公司，要碰上他非常困难；一项目组员鼠标坏了，要更换一个，你打报告上去了，却如石沉大海，一两个星期都落实不下来——这些情况并非国企专利，不少管理不善的私企中同样存在……
作为项目经理，需要面对所有可能出现的情况，并处理好它们。因为项目经理一般不是公司领导成员，应对项目外因素的权力、手段、精力都相当有限。项目经理只能把握一条根本的原则：使项目获得成功！
使项目获得成功，从项目经理来看，要把握住三个支点：上级、人员、技术。这几个支点把握住了，项目成功的主动权就掌握了，项目进行中的工作，如计划、协调、督查等，就可以运用项目管理方法论的知识去灵活施展，灵活应对了。
上级——与上级的沟通
作为项目经理，肩负着项目成败的责任，管理和控制着项目的方方面面。因为责任大，涉及面多，一般公司也会赋予一定的管理权力。因为权力，又最容易招来非议、嫉妒和各种明暗的竞争甚至攻诽，这些对项目的负作用力有时还会来自于你的下属——比如当你的下属具有野心、对你抱有无名反感或你是公司的新员工时。因为很多人都是存在私心的或对自己水平/能力缺乏正确认识的，使他们常常持有一种不健康的心态，这种心态影响着人们在各种情况下的行为，所以无论国企还是私企，无论大企业还是小企业，往往都存在着人为的负作用力。项目经理，他的目标是保证项目的成功，他要排除来自各方面的不利干扰，并且尽可能保证自己绝大部分的精力能投入到项目管理中去。而项目经理的上级，因为各种各样的原因，往往容易轻信各种谣言诽语，对项目经理疑虑重重，严重时会作出一些对项目组工作极为不利的决定甚至更换项目经理。
项目经理必须维护自己在项目组中的权威——只有这样，你的命令才能被顺利执行，你的意志才能得到实效地贯彻，你的知识、经验、能力才能为项目作出充分的贡献。如果你本身是公司的领导层员，可能自然地拥有权威；如果你只是因为业务/技术/能力的因素被置为项目经理，你的权威就需要自己来打造。而获得上级的信任、支持是树立权威的基础。获得上级的信任、支持，还可以带来其他好处：使项目组得到及时可靠的后勤保障，赢得客户的信任，得到其他部门的配合等等。
定期、主动向上级汇报工作，得到上级的理解和支持，是项目经理应付各种项目外因素，维护自己权威的支点。
项目经理通常会要求项目组员定期上交工作报告，如工作月报、周报甚至工作日志，以深入了解项目进展及每个成员的工作状态。而你的上级却可能采取的是“粗放”的管理方式，对项目经理没有严格的汇报制度，甚至对项目定期汇报感到麻烦。无论上级对你的要求怎样，项目经理应当定期向上级汇报项目情况，上级没要求的时候也应该采取主动的方式让上级了解。汇报的形式可以是在面见上级时口头陈述，或写成书面报告递交，或利用各种适当的机会简述项目的进行状态。从经验看来，让上级了解项目状态有时是件很困难的事情——特别是项目进入复杂状态时，你提交的书面项目报告他可能不愿去看，你昨天跟他面见时的陈述他可能“哦、哦…”实际根本没听进去，今天经理碰到你，又会突然问你：“现在项目进行得怎样了？”、“你这样吧，把XX、XX方面的情况写个报告给我。”。要让上级真正了解你的项目情况，你必须具有足够的耐心，要反复的利用各种适当的机会，帮助他来听到你的声音，了解你项目的情况。如果你只是专于业务/技术，只能通过制度式的、正式的途径向上级报告工作，而不善于采用另外的方法与上级交流，偏偏上级又是一个并不英明的人，那么你及你负责的项目就存在较大的风险。
作为项目经理，坦荡、宽阔的心怀是相当重要的。一般，具有一定阅历、经验的项目经理对自己的下属是具有宽阔心怀的，是能够容纳下很多事情的；但他们对上级，却不一定能承受某些冤屈。一种较笼统的概括可以是这样来讲（针对国内公司）：七十八十年代的领导是属于老革命类型的，九十、二十一世纪初的领导是属于少爷派类型的。老革命类型对企业有足够的忠心，主要的缺点是过于保守和缺乏先进知识；少爷派类型有足够的干劲和雄心，但他们却缺乏足够的资历、能力，缺乏作为领导者的足够底气，所以这一类型的领导者大多会带有一些古怪的脾气，并有意无意借助这些古怪脾气彰显自己的领导权威。项目经理，往往是有有着丰富经验和精深专业知识的人才，为了获得项目的成功，他们需要具有比客户、同事、上级更宽广的胸怀，来应对各种复杂的人际交流问题！
项目经理应具有坦荡胸襟。这种胸襟不仅是公平的评价项目组成员的业绩及容忍/消释他们对评价的误解而产生的非健康情绪，还要能坦然面对来自上级的决定。现实中会存在各种现象，如你的上级仅仅是要借用你的头脑，等你把项目基本问题都解决后，可能安排他的亲信来替换你的职务，让他的亲信来接受项目成功的奖誉；当项目进度过慢，你和上级肯定是一致的要提高进度，但如果进度过快，快到远远超过了公司的想象（如果你是个杰出的人才，出现这种情况是平常的），你可能以之为业绩，而你的上级却可能忧心忡忡（原因是非常复杂难以理喻的），除非你有权力或有适当的方法让公司认可你，否则应调整进度到适宜的程度，以适应上级的意图和兄弟部门的感觉，不然的话，上级的一些后台动作会让你窒闷/吐血。遇到这些情况时，项目经理要能以坦荡的胸襟待之，项目经理的一条职业道德是：只要你还是项目经理，就要为项目的成功而努力，用是否利于项目，来衡量各种取舍关系。
人员——认清项目组的能力
项目组成员是执行项目各项任务的人力资源。明确了目标，确定了人员，一般项目经理都知道如何按照项目的特点、规律去制定工作计划。然而，制定一套科学合理的计划是不容易的，原因之一是项目组成员的能力并不能被轻易地看出来。公司交付给你项目时，往往也基本框定了项目组成员，你只有很小的调整余地。组员的简历你一般是看不到的，组员的水平、经验就只能通过你与组员的各种形式的接触、会议、交流来了解。人员配置与项目规模、进度要求的关系中，有时甚至不是按照如图：
所示的推导过程由项目规模、进度要求来确定人员要求，然后再确定组织方式，而是先从项目规模、进度要求、人员配置均基本确定的情况下，你要找出合适的组织方式来执行项目。
认清项目组每个成员的水平、能力，是项目经理在确定组织方式之前要尽量做好的工作。因为现实的原因，采取笔试、口试的方法一般都难被接收。项目经理需要想一些即尊重组员、又能深入揭示组员水平/能力的方法，来认识清楚项目组的水平/能力。正确认识项目组的能力，是项目经理开展具体项目工作的支点。
一种MIS项目的工作程序可能是下图所示的情形：
这个工作程序中，对项目组要求一些基本的能力：设计、编程、界面美化、独立担当功能模块、撰写文档、有测试技能等。假设项目组共有甲乙丙丁戊五个人，你通过了解后，得出的项目组的能力情况为：
能做设计的有：甲、乙
能编程的：甲、乙、丙、丁
能做美化的：戊
能独立担当模块的（不能独立担当模块的意即需要别人给安排具体的工作内容、给以指导、并时时检查他/她的工作）：甲、乙
能撰写文档的：丁、戊
有测试技能的：甲、戊
经验/水平排序：甲、乙、丙
根据项目本身的要求，结合项目组成员的水平/能力，你可以这样来组织项目组：
而如果你通过了解后，得出的项目组的能力情况是另外一种状态：
能做设计的有：甲、乙
能编程的：甲、乙、丙、丁
能做美化的：戊
能独立担当模块的（不能独立担当模块的意即需要别人给安排具体的工作内容、给以指导、并时时检查他/她的工作）：无
能撰写文档的：无
有测试技能的：甲
经验/水平排序：甲、乙、丙
那么你的组织方式就要根据实际情况重新安排，比如下图的形式：
因为你没有可撰写文档的人员，也没有可独立担当功能模块任务的人员，你必须先作一些培训（按模板写文档、测试技能等）、分解/新加一些工作程序（制作文档模板、功能讲解、完善设计、完善开发等）、人员配置也要在项目过程中动态调整。如果这种人员状况下的进度要求不变，你还得安排项目组加班，以挽回培训的时间。
一般项目要求的能力与组员实际能力之间会存在差异，这些差异如果不是很大，可以通过合适的组织方式（特别是项目过程中的动态人员配置）来解决。如果差异超出了组织方式可调整的极限，项目经理就要另想办法了，可能不得不申请延长项目时间、增派人员等。
项目经理应该在项目前期即了解项目组成员的实际水平/能力状况，及它们与项目要求的差异。了解了这些，你才能制定正确的工作计划，并较准确的估计项目组的效率。
从与组员普通、自然的交谈中，去感知他们的水平/能力，是最易实施、最少出现负作用的方式，也是很有效的方式。组员的经验、知识面、考虑问题时能达到的深度、习惯（常常影响一个人思维联想的方向）、精神毅力等等都可以通过这种方式来了解。
要了解组员对某些具体技术掌握的深度、大脑中积累的技巧、判断能力等方面的情况时，需要采取一些测试技术才能获得。因为被明显测试常常为人们所不愿意，也易产生不正确的答卷，所以项目经理要认真设计测试方案。可以给组员布置一些小的带测试目的的任务（告诉他们这是项目工作的一部分），从他们对任务完成的态度、效率、结果来了解他们；可以特意给某些组员安排一些与他们水平/能力相距极大的任务，他们因为光凭自己能力很难完成，一般都会找同事寻求帮助，从他们帮助与被帮助的过程、事件中，能对他们得出很多新的认知。只有比较正确地了解了组员的水平/能力，项目经理的组织方式、工作计划才能制定得合理，才能保证项目实际进展过程符合预期。
对组员的水平/能力有了较准确地认识后，项目进行过程中有可能还会碰到一些难于处理的问题：有些组员保留自己的经验、能力，不肯充分发挥。产生的原因是多方面的，如存在心理不平衡感、持有一种歪曲的竞争意识、个人的情感因素、公司在管理/待遇方面存在明显不公平的地方、项目管理方式上有一些缺陷等。项目经理要发现问题的症结，能通过项目内手段处理好地自然好办，通过项目内手段处理不了的，需要与上级沟通寻求办法，如前述方式均无助，你可能不得不重新考虑项目的组织方式，重新设计计划。这样的情况有时在项目计划前也能发现，如你从组员的态度、工作中的精神表现能发现它们。
项目内手段有很多。与组员进行深入地交流，化解他们思想上的障结/包袱；利用表扬/批评、奖励/惩罚等方式也能起到较好地作用，能给组员带来成就感、荣誉感、耻辱感、失落感等，这些精神感觉/刺激如运用得当，能强化组员的效率、提高创造性、主动性、责任性。如果组员都自觉努力，发挥效率大于90%，采取宽松的任务管理方式能获得最好的效果；如果组员有一些不佳情况（行为上的/精神上的），发挥效率降到了90%以下，可以采取定期写工作总结的方式，如月工作报告，周工作报告，这种定期报告能促使组员不断审视自己的工作效率和工作业绩，从而注意保持或提高工作效率/工作量；如果组员效率降到了70%以下，你可以要求组员写工作日志，促使其注意保持每日的工作量，不同的组员可以作不同的要求，因为对一个非常自励的组员来说，过于频繁/严格的工作要求，会降低他的工作效率、抑制其创造性和主动性。假如组员的发挥效率降到了60%以下，那你就采取直接指定每日具体工作内容的方式进行管理，如制定日工作表格，日工作表格中计划安排了组员当日应完成的具体工作，每日下班前验收其工作成果，这种方式是一种严格的保证工作效率的方式，但它要付出较大地管理成本，如制定具体的日工作内容及检查工作的实施/完成是一个较繁重的工作，日工作计划会被频繁调整，有时还会感到无法拟订具体的工作内容（软件开发中经常如此）。
技术——准确把握项目的风险
对软件项目来说，项目进展过程也就是不断解决技术问题的过程。项目中包含的技术难点可能大部分已被明显地描述出来，对这些技术问题人们都能理解要安排的资源及准备付出的成本；有一些技术难点并非一开始就能描述清楚，它们需要在项目进行到一定地步后，才能看清楚；还有些技术问题普通人不能发现，只有那些经验丰富、水平较高的技术人员才能感觉到。
项目进行过程中遭遇到的直接影响到进度的技术问题不妨称之为技术卡点。如果项目进行前对技术卡点没有全部认识到，或认识有误，带来的后果是严重的。首先是打乱了项目计划（全局的或阶段的），然后是会使公司、上级怀疑你的能力及职业忠诚度问题（他们可能认为你是在故意制造事件、拖延怠工、养患自重…），会使你在各种明暗竞争中处于被动地位，甚至直接危及你管理的项目。当然，如果你确实感到能力不济，也要坦然承认。
在一个自动控制系统中，项目经理采用了一种新型的PLC控制器。他看了控制器的一些技术资料，觉得与他以前用过的控制器基本相近，于是他排好了计划，带领组员做好了设计，开始编程实现。相当部分的程序编好了，但他的组员遇到一个问题：控制器对时钟的处理方式与他们设计时理解的不同。设计时他们认为控制器的时钟是通过中断处理的，是不断运转不受程序影响的。而实际中发现该控制器的时钟是无中断处理的（无中断控制器触发），时钟前进是在每一次程序循环的结尾才由系统扫描处理。如果在同一个程序循环中设置了时钟初值又去判断时间差的话，永远得不到等待的差值，而且要使时钟比较精确，每一循环执行的程序必须尽量简短。而时钟在自动控制系统中极为重要（如延时、定时、关联设备的次序控制等）。这一细节性的技术问题，使项目组不得不重新设计，从头再来。
在一个大型的应用系统中，应用数据的组织非常复杂，大部分用户需求也迟迟不能明确，你为了及早进入开发，并减少以后其他需求明确时带来的影响，于是计划采用将部分对象移到数据库一端的设计方式（一般对象都放在程序一端，数据库主要作数据存储），这种方式可以通过数据库对象的调整来适应需求变化及数据结构的变化，减少已完成程序的修改。在此中，你采用的数据库是否支持会话标识，是否能透明地存储/获取会话数据，对你的设计将有比较大的影响，因为它对今后的优化数据获取方式、转换慢速视图等都是非常重要的。你需要通过实际编写例子去确证。
能否准确地意识到项目中的关键技术细节，与项目经理的知识范围、经验直接相关。项目经理要虚心，多听取各个方面及组员的意见，并要多查阅相关资料。清楚地了解项目中存在的关键技术细节，对项目经理来说是需要的，项目经理才能科学地制定计划、组织人员、把握方向/整体进度、正确评价组员业绩等等。
项目经理要善于从复杂的技术问题中抽象出模型来，这样才能及早发现项目中隐藏的技术卡点。将主要干线流程列出，模拟前进走一遍，将每一步都较详细地写出来，然后召集组员对照模拟步骤思考/讨论，能发现大部分的关键技术细节问题。仅在头脑中思考，人们很容易将多个步骤的条件混淆起来，而不大能感觉到其中的问题；将模拟步骤写出来，每一步的当前环境、条件都比较清楚，人们能更容易地觉察出一个步骤中某些细微条件的不足，而能更好地发现关键技术细节。
结语
对于项目规模，一般是从该项目参与人数、计划时间长短来衡量的。同样的项目，由不同的项目经理来领导、来看待，其规模会有所不同。如开发一个关系型数据库系统，一个公司可能会计划投入一百以上的程序员，花几年的时间。这时，它是一个大规模项目。另一个公司来做同样的项目，因为该公司人才杰出，可能计划投入十以下的人员，两年的时间。这时，它是一个中等规模的项目。两个公司实施项目的结果可能是相同的，比如都取得同等标准的成功。
项目规模越大，所设管理层次可能越多。无论管理层次如何设置，对其中任一层的管理者来说，其工作机制是类似的：接受上层管理者的领导，管理好直属下层人员的工作。管理控制观念强的管理者可能参与管理隶属下面两层或更多层的人员。本文所述项目经理主要针对国内极典型的一种项目管理形式：一个项目经理，配置一个项目团队，由项目经理自行决定项目人员的实际管理层次、组织方式。
有时被指任为项目经理，而实际只履行着参与了解项目进展，进行概念性指导、协调一些多边联系的职能，这只是名义上的项目经理。真正意义上的项目经理是对项目负责，管理、协调项目全过程，对项目的人员、可用资金、工作内容、进度等各个方面因素进行统筹调度、合理计划，督查项目实施过程，解决项目进行中各类矛盾、确使项目成功的一种角色。
一旦被指任项目经理，对项目组来说，你就具有了最高的领导和决策权力。项目执行过程中，如果把握好了上级、人员、技术这三个支点，项目的成功一般是指日可待的。上级这一支点较变化莫测，有时候最难处理，你需要有较好的沟通技巧和深广的胸怀；人员在你的领导之下，是一个能以精神、制度等主客观因素共同作用的支点，你管理的方式/手段都比较多；技术支点是偏重于客观的，对你的知识、经验、智慧、精神有着较高、较全面的要求。之所以将上级、人员、技术作为项目管理的三个支点，是因为：三因素的任一个与项目经理意图/目标完全相悖或完全失控，则项目必败无疑；从三因素入手，是最适于概括项目中各种现象、矛盾的，是项目经理可从之出发拟订方案/措施/计划并最终回归之以判断效果/结果的。
|