项目管理实际中的应用（转载整理）

各位都有心得,我扔两句:
1.没错,PM的活比较零碎,主要作为项目组和领导以及客户的信息中转站,因此,项目分配任务的时候考虑尽量少安排一些工作,因为总会有意想不到的工作干扰你.
2.权利下放,考虑TSP(我们实行过,效果不错),将组员分成角色,例如每天的备份,由专人负责,你只管检查备份是否完成,这样同样能调动组员积极性,让他自己对项目有责任感,自己也省心.
3.放下追求技术的心态,看问题的眼光放在项目上.
4.多看看管理的书,尤其是激励的方法.

 

 

个人觉得项目经理比较重要的是
1、“随时可中断”。必须随时做好准备去应付一些突发的事情。
   因此项目经理不应该给自己分配需要集中精力和较长时间才能完成的事情。
   一旦必须要这么做的时候，尽快安排人接替。
   明确哪些事情自己该做，哪些事情不该做，不该做的事情要坚决扔出去。

   换句话说，项目经理的第一任务是“让自己空下来”。

   PM的活比较零碎,主要作为项目组和领导以及客户的信息中转站,因此,项目分配任务的时候考虑尽量少安排一些工作,因为总会有意想不到的工作干扰你.

  项目计划要多富裕些时间：
  以应对不可预测的情况发生。
  整体计划与各阶段计划相结合，控制时间和进度。
  对用户的需求要画定好范围和界限，不能一味的迁就客户影响工程进度。

2、“团队优先”。
   我一般给团队中人分配两件任务，一件是主要的、固定的，有时间限制的，
   一般是需要八到九成时间。
   一件是次要的、灵活的，无时间限制的，但是有目标要求。
   通常后一件会带有一些技术探索意味，属于该成员个人比较感兴趣的部分。

   换句话说，项目经理的第二任务是“让团队中的所有人都有事情做”

3、“控制客户”
   控制客户包括多方面的意思，搞好关系是一层，但如果软件做的实在太差，
   没法用，关系再好都没有用。
   而且关系好是双面的，客户同样可能以关系好为由来要求你这里改改那里
   改改，结果造成项目无限期拖延。尤其是市场/销售人员经常去开空头支票。
   我觉得，应该是对客户领导要搞好关系，告诉他一切没问题，一般这是
   市场/销售人员搞定的
   但是对软件的实际使用者也就是客户的底层人员诉苦。这个就要项目小组
   自行解决了。

   如果是小项目，往往是开发人员直接见用户。前者由项目经理来自行，后
   者直接由软件开发人员进行，挑一个比较会说话的，多往用户那边跑跑，
   聊聊天。当软件投入运行时，这是很有用的。再好的软件也架不住用户
   不断地需求变更，因此最好的办法是“把需求变更扼杀在襁褓之中”。
   如果是大项目，用户方应该会有专门的项目负责人（用户代表），和用户
   代表绑定在一起是非常必要的。但是底层的人员一样要搞定，那就可以有
   专门的支持人员，更需要和用户多接触了。
   
   操作的时候注意多留文档，哪怕是再小的问题也要留档，过一个月整理一
   下，往客户领导（或者用户代表）那边一放。统计一下本月共发现多少问
   题，哪些是新需求，哪些是软件BUG，哪些是用户使用问题，解决了多少，
   有哪些遗留，我方技术人员现场支持多少小时，诸如此类。总之让对方感觉
   我们劳苦功高，服务周到，响应及时。
   来上几次就可以由销售出面谈维护或者二期之类的事了。这样就赚到了。
   即使软件还有很多问题一样可以继续操作。

4、对付领导/老板
   
    要对付领导，首先要学会站在领导角度看问题。
    其实做领导也挺不容易的，听话的手下往往能力不够，能力强的
手下往往不太听话。
    因此做领导的最希望手下能力又强又听话，什么事情交下去就完
全搞定，而且效果很好。
    当然领导也不是笨蛋，也知道需要提供必要的支持，他也不会逼
死你。但是他会认为在他合适的时候来逼你。
    什么都不懂，只会压榨下属的领导往往也没什么前途，当然如果
他是老板的亲戚就例外，如果跟了这种领导就只好认倒霉了。

    在国内，绝大部分是树型管理架构，因此这里主要针对树型管理
架构，矩阵式的可以自行类推。
    作为项目经理，一般接触的主要领导就是部门经理了。如果公司
比较小，也可能接触总监/副总甚至总经理。
    对于项目经理来说，部门经理有两个身份。
    一方面，在整个公司里，部门经理是项目经理的上级，直接掌握
项目经理的奖惩，尤其是奖金和升职（我想绝大多数人都希望钱多职
高吧）。
    另一方面，对于单个项目来说，部门经理又是项目经理的后盾，
提供项目所需要的人力、物力甚至财力，以确保项目的完成。必要的
时候需要请部门经理出面进行较高层次的协调。
    对于软件开发来说，最关键的就是人。尤其是在一个部门中有多
个项目在进行的时候，这个时候一些能力比较强的人肯定是稀缺资源。
大家都要抢的。
    我想做项目经理最痛苦的莫过于自己团队中的主力支援其他小组
去了，结果最后领导还怪你项目没做好。

    那么如何争夺人才呢？有以下要点
    1）自我定位。
       我在部门中，在领导眼里是什么地位？
       我手头目前负责的项目在领导心中是否重要？
       这个项目做好了对部门，对领导有什么好处？
       这个项目做坏了对部门，对领导有什么坏处？
       如果这个项目不是关键性的项目，那么就要有使用较差人员的
   准备，硬要去和关键项目抢资源是绝对没有好处的。
       如果这个项目是关键性的项目，那么就要充分估计风险，狮子
   大开口一些，点名要人。
       一般是否关键性的项目只要看看客户是不是大客户，合同金额
   多不多就行了。

    2）了解他人
       至少要知道公司里面哪些人擅长什么，哪些人什么时候有空，
    这样可以有的放矢。
       这个需要日常和别人搞好关系，而且要了解其他项目的进展情
    况，包括即将启动的项目。

    3）掌握时机
       向领导要人是要看时机的。
       要的太晚不行，一旦给别的小组捷足先登，则除非你的项目特
   别关键，否则就只好拣剩下的了。
       要的太早也不行，因为如果要来了人没事干，那么就会给领导
   造成不好的印象，下次要人就困难了。而且会让领导质疑你的管理
   才能。
       个人建议是项目初期启动的时候大概的估算一下，然后调研一
   段时间以后再稍细的估算一下，到需求比较明确的时候就要出很详
   细的计划，把要多少人都列清楚。
       要有个一两周的提前量，一般情况下都会有一些拖延的。
       然后就催着领导落实这个计划，只要计划没落实，就要一直催
    ，当然催得时候要注意方式方法。
       另外，到了项目后期，也要注意及时的释放人力，不要占着人
   一直用。这样领导就会对你留下个好印象。
       如果有别的项目差不多时间启动的话，一定要比对方快那么一
   点点，即使只是一天。


    4）方式方法
       前面三点都是战略性的，这一点就是战术性的。大多数情况下
   项目经理去要人，都很难得到完全满意的结果。
       个人认为有以下几点需要注意：
       a、准备充分。至少要有一份比较详细的文档，对现阶段进行
          总结，并给出大致的计划，然后提出人员要求。
       b、人员质量要求。对人员的质量应该有所要求，一个高手和
          一个新手差别极大。如果已经看中部门中某个人了，则可
          以按照那个人的水准来套，引诱领导往那个人的方向去考
          虑。只要领导说一声，“那xxx你觉得怎么样？”立刻就
          说“好啊好啊”，领导再想反口也来不及了。
       c、讨价还价。其实向领导要资源也就是和领导谈判的过程，
          本质上和小菜场讨价还价差不多。项目经理是卖方，领导
          是买方。你要让领导相信提供资源可以买到项目的成功。
          但是领导会在多个方面上进行挑剔，甚至可能召集其他人
          来一起评审你的计划。一般情况下项目经理的要求总是
          会被砍掉一些的。
          因此有时要稍稍高开一些（但也不能太过分了，很容易就
          会被别人拆穿的），以给领导砍价的余地。
       d、软硬兼施。此招慎用
          如果领导比较开明，你在公司的地位比较高，有的时候也
          可以撂狠话，不满足我的要求我就没办法作这个项目经理
          了！
          说这种话的时候要注意给自己留好台阶，避免留下不良后果
      以上种种只是一些辅助性的措施，最关键最首要的前提还是本人
      水平够高。如果本人水平不够，再好的人才到手里也只是浪费，
      那还不如给别人用呢。

 

5. 任务分配
    进行任务分配时应当注意任务之间的耦合程度以及任务的内聚程度，以减少项目内耗。尽量做到低耦合，以降低对成员之间交流的依赖程度，让大多数成员（需要把握全局的骨干成员除外）无需考虑太多繁杂的、不相干的东西；尽量做到高内聚，让成员可以尽量发挥他的能力以及已经获得的项目相关信息。
    如果工作量实在太大，或是工期要求太紧，不得不把高耦合工作分给多个成员负责，这时候就要特别注意成员间工作相关知识的同步的问题。
    要给所有成员一份详细的工作内容说明，并要注意所有成员得到的相关资料的一致性。在所有成员都做好自己工作的有代表性的一部分的时候，要把这些成员集中起来进行一次review，以消除成员之间知识／理解上的差异。如果在开发过程中出现了需求变更，则要及时通知与这部分需求相关任务的负责成员。做一个简明的变更索引，按索引定期review，以检查变更的落实情况。
    如果由于成员调度、个人进度、需求变更、以前遗漏的任务或者某种不可抗力等原因，而不得不更改任务分配，这时候一定要考虑如何最大化地利用项目人员已经做过的工作、已经获得的项目相关信息，尽量减少任务更改而引起的交流、培训和再教育花费。

6. 成员教育
    在成员的教育上要注意知识层次上的连续性，切不可出现断层。每个层次都应当有足够的候补要员，以便在非常情况下在层次间流动。
    在项目的早期，要全力打造几个能深刻理解全局的骨干成员，以在关键时刻减轻leader的工作压力。如果项目时间允许，早期加入到项目的人员可以适度拔高，让他们参与一些稍高于他们现有能力的工作。可以与他们一起理解需求，让他们参与分析模型的评估。由于有较长的时间来验证他们对知识的理解，相对来说可以比较放心。但是也要尽早检验，以减小修改错误的代价。
    而对于项目中后期加入的成员，不必让其了解太多的全局知识，尽量让其负责单一的工作。此时需要注意把对知识剪裁的尺度。什么样的知识是必需的，什么样的知识是需要大概了解一下的，什么样的知识是完全没有必要的。这些都需要leader仔细地斟酌。由于是中后期加入，应该在第一时间验证他们的任务相关知识的正确性和准确性，以保证最终产品的质量。