1 真实案例
这里用一个真实案例来作为引言，用真实来说话，以下引自某著名高校计算机研究生：
“导师让我们干活，开始大家积极性非常高，每天聚在一起讨论，可是导师有一个天大的错误，他总寄希望于施加给我们最大的压力，试图通过这样来提高我们的工作效率，从而提前进度，事实上领导也没有催什么进度，每次他都催我们在某某日之前把目前的一个版本做完，于是，我们被迫连续工作很多天，根本没有时间休息，甚至他会每天打电话给我们每个人，试图了解其他人有没有在干活，如果发现有人休息的话，就会得到他的批评，说我们又放松了，到目前为止，似乎我们根本不应该有休息的时间，大家对他都非常反感，觉得他很没有人性，根本不懂项目管理，却还在和我们开会的时候谈项目管理，说我们的进度控制不到位，说今后走向工作岗位就怎样怎样，我曾经把我的《最后期限》（一本关于软件项目管理的著作）给他看，结果他说没有时间。
现在大家都想躲他，以前对他的那种敬仰的感觉也完全没有了，其实很多项目经理对于人的理解是很不到位的，所以随着时间的流逝和接触的增加使得项目组的成员都很反感。
他甚至在我们面前说：其实有时候我知道你们做不完，但是为了让你们更有效率就故意把进度提前，让你们有点压力，项目管理的时间控制是最终要的。我听了之后就想给他一拳，拿大家不当人。竟然还好意思大谈项目管理........”
这尽管是发生在老师和学生之间的“故事”，但在实际工作中却常有发生，笔者自身就经历过这种项目，这种问题不仅仅是一个项目中的问题，更多的是反映到一个企业经营管理的能力，而中国的企业管理能力很薄弱，不要说百年老店、基业长青，就连２０年以上的企业都少之又少，IT行业尤甚，一方面是企业管理人员的自身素质有关，中国的老总们绝大多数未接受正规的管理教育，多半靠几十年的商海经验摸爬滚打而来；另一方面国内软件行业不景气再加上恶性竞争，大部分软件企业还处在资本的原始积累阶段，温饱尚成问题，要想让老总们多多人性关怀，无异于与虎谋皮。
2 分析问题
曾有一个程序员提出他心目中理想公司的标准：
第一，是否配置液晶显示器。
第二，是否不合理限制上网。
第三，员工是否有提出建议的渠道。
第四，对于员工提出的建议是否重视和及时的答复和解释。
很简单的几点要求，但我敢肯定能做到的国内企业在两手之内，尤其后两点，很多公司都设立了总经理意见箱（有人向里面投过建议吗？至少我没有J），多半也就是个自我安慰的装饰品。对于第一点，这个程序员说了这样一段让人心酸的话：“当我看到我的同事用电脑吃力地看电子书的时候，我只好摇摇头。很多收费的人员都在使用液晶显示器的时候，而程序员却没有这个福气,可悲啊。我想要求单独的办公室也许还不合国情，要求一个液晶显示器应该不过分吧。”
一个简单的液晶竟会带来这么大的问题，当然每个公司的环境都不一样，不能苛求一致，本文不是谈企业环境和企业文化，自从项目角度本身来分析人的问题。
DeMacro和Lister（《人件》作者）指出了软件业的根本问题，那就是人的问题。
在项目完成之前，软件公司的心目中一个软件，用户心目中有一个软件，而这两个软件可能根本就不是一个东西！只有随着沟通的深入和进度的推进，这两个软件才会逐渐靠近，当二者相同时，这个项目就完成了。所以说，实际上软件项目的完成很大程度上并不是由开发工作量决定，这就是几乎所有的软件都不能按进度完成的一个非常主要的原因。
以做饭上，将它细分为每个人和每道菜，每个人都有自己喜欢吃又会做的菜，自己喜欢吃但不会做的菜和自己不喜欢吃的菜（注意：这里不存在自己不喜欢吃但会做的菜，没人会去学做自己不喜欢吃的菜--别跟我说你老婆喜欢吃^_^，这是抬杠嘛）。饭做完后，每个人只要吃自己喜欢吃的菜（包括自己做的和别人做的）就够了，并不是要把所有菜都吃过才行，而且最关键的一点是，即使是自己喜欢吃的菜，如果别人做得不好，你也可以选择不吃，只吃自己做的部分也不会饿死。
软件也可以这样分，用户可以分成一个个具体的用户，软件公司可以分成一个个具体的开发人员，软件可以分成一个个具体的功能。在这里，每个用户要用到的功能都不是自己开发的，而每个开发人员开发的功能又不是自己用的，这样，在开发人员心目中和用户心目的功能可能是完全不同的两个功能。这里的问题就在于：用户要用的功能（喜欢的菜）是别人做的，而且还不合用（不好吃），但用户又不能不用（不能不吃）。而从开发人员的角度上来说，就是在开发一个自己不用的功能（做一道自己不喜欢吃的菜）。
正因为有这样的根本矛盾，Alexander 的“自治”理想在软件开发中并不能很好地实现。
但即便如此，采用管理建筑工地的管理方法同样是不可行的，虽然这种方法在一定程度上是有效的。但不管是在软件业还是建筑业，它都仅限于在“一定程度”上。
当年有一个时髦词语--“深圳速度”，后来却不再提了，因为它跟更早以前的“亩产万斤”有异曲同工之妙。当年人们幻想通过无限制地减小庄稼的株距和增加施肥量来增加单产，结果却是千里饿殍。后来的人们幻想通过没日没夜地加班加点，无限制地缩短工程各阶段的时间来加快进度，然而结果却留下质量隐患。
软件业也一样，偶尔对开发人员加压可以达到在一定程度上加快进度的目的，然而它会有很多问题：
首先，这种方法很快会失效，员工的工作时间越来越长，效率却直线下降，因为体力劳动与脑力劳动有本质的区别，大脑远比身体要容易疲劳；
其次，与建筑业一样，这同样会带来很多质量隐患，大脑在疲劳时犯的错误要远远高于平时，不论是对于开发还是测试；
最后，这种方法是严重的副作用，就是人员流动，最坏的情况是整个TEAM的人都受不了，全跳槽了。在建筑业这不是大问题，建筑工人多的是，换一拨就是了。当然，现在程序员也多的是，但问题在于换一拨是绝对行不通的。
所以说，“人”出了问题，既有企业管理，企业文化方面的问题，又有项目管理的问题，如何在项目进行中始终让团队成员保持高昂的士气和战斗力这就是考验一个ＰＭ的时候了。
3 解决问题
笔者非管理学大师，难已开出什么“灵丹妙药”，只谈谈自己的一些认识和做法。
公司的大环境，企业文化都是长久积淀的结果，不是短时间能够改变的，也不是一两个PM或者程序员能够改变的，所以作为ＰＭ，在无法改变整个公司的大环境的前提，就只能尽可能从小处入手，在你的项目组内营造一个“世外桃源”。
Ø PM必须对你的项目有充分的了解和掌控
作为项目经理，对整个项目的目标、范围、时间和资源都要有非常清晰的了解，整个项目的WBS分解图要了然于胸，只有明确了目标和现状，才能清楚关键何在，风险何在，根据管理学上的“二八”原则，你必须在每一个ＫＰＡ，每一个Milestone上投入最大限度的资源，这样也才能驾驭好这个项目，不然若你的“船员”问起我们的方向何在，你却无法作答，可想而知对整个团队的士气打击有多大。
Ø 在允许的条件下实行弹性工作制
中国人历来强调纪律，强调集体，所以中国的企业都有很严格的作息制度，倒不是说这种制度不好，而是要看面对的人群、工作的性质再作取舍，很多大型ＩＴ企业，典型的如微软，一直实行弹性工作制、强调每个员工的个性，每人一个房间，尽管我们国情还不允许但我们可以在允许的条件下“随意”一点，每个项目都有忙时闲时，忙的时候紧张一点，现的时候做以下培训或者大家出去放松放松。而且大多数ＰＭ都是由考侵权的，所以时间上也没必要死板的“朝九晚五”，如果一个同事昨天加班到深夜，今天你还要求他９点准时上班就未免太不“人道”了。
Ø 不建议无原则的加班
对于一个软件企业，不加班那简直就是天方夜谈，但人的精力是有限的，一个人的加班时间是有限的，这好比打仗时的预备队，任何一个成功的将领决不会在战役之处就出尽手中所有的牌，将自己的精锐部队和预备队一股脑的统统派上战场，战事瞬息万变，一开始就暴露全部兵力必然陷己于被动。
团队成员的加班时间就是你的预备队，不要一开始就要求他们天天加班，项目的初期常有一个混沌期，一开始就加班（就如前面的那位导师所为），以为催的紧项目就能顺利完成，其结果恰恰事与愿违，所以合理的分配你的加班时间，将好钢用在刀刃上，最大限度的利用“加班”。所以我不建议无原则的加班，加班一定要有加班的理由。
Ø 了解和关心每一个项目组成员
这种关心不是表面工作，不是说两句冠冕堂皇的官话，而是将关心落实到实处，了解每个成员的长处和不足，安排工作时尽量发挥他的长处，多交流，一旦有人攻克了一个技术难题，取得了大的进展一定要当众给予表扬，中国人常不懂得夸奖别人，以为虚伪，这一点很不可取。另外若有成员在工作以外的方面遇到问题，也应该力所能及的给与帮助。总之，只有你设身处地为下属着想，你的下属才会“卖力”的为你干活。
Ø 以身作则
这一条说着容易但大部分ＰＭ都难以做到，中国人的“官味”很浓，很多人以为作了经理，当了领导就可以不干具体的工作了，只要发号施令就可以了，这么做必然脱离群众，让下属不服。
Ø 勇于承担责任
项目中总会遇到这样那样的问题，甚至最终项目会失败，失败不可怕，就怕不敢正视失败，面对问题，遇到问题要敢于一肩挑，推卸责任就等于把自己推到了项目组的对立面。
Ø 敢于承担压力
这里的压力主要是指来自上级和客户的压力，高层领导总是希望能够用最少的资源、最短的时间和最好的质量来完成项目，所以会不断的施加压力，客户也是希望能用最少的钱来实现更多的功能。作为ＰＭ必须要顶得住这种压力，不能加这种压力转移给团队成员，永远要记住：你的项目组成员是你最坚实的后盾！
Ø 恩威并重
管理要讲艺术性，中国官场也常讲权谋二字，每个人都是不一样的，根据马斯洛的需求理论，每个人的需求都不一样，而且同一个人在不同的时期也会有不同的需求，在一个项目组内有的人工作积极，而有些可能很懒散，得过且过，对于工作态度不积极的成员要分析原因采取相应措施，进行监督和控制，必要时候可以采取一定的惩罚手段。