在实际软件开发过程中，在中国，可能很多项目管理人员第一头痛的事就是，团队成员工作热情不高，投入程度不够。
这个问题成因可能有很多，比如：
可能原因之一，在于人。
假设每个人都自觉遵守职场里的规则，那管理难度要相对较低。但很多时候团队成员有可能缺乏一些基本的共识。对于很多人来讲，可能基本思路是：
打工不过是谋生的一种手段，明天我还不知道在那里？这也就导致了，团队成员对公司没有归属感，进而责任感及主动性这类东西相对欠缺。
可能原因之二，在于环境。
中国的软件产业处于整个产业链的下游。外包和系统集成是软件产业的主题。这个大背景就决定了很多工作确实无聊。就好比微软不可能把内核外包出来一样，很多时候外包出来的东西，往往重复性较强，趣味性较差。
可能原因之三，在于企业。
有的企业把员工等同与工具，本就没什么长远规划。
对于原因一，二事情尚有可为之处，如果真实原因是原因三，那就非项目级别可以解决的事情了，也许更好的办法是换个公司。
在特定的时间点，特定社会环境下，有些现实只能接受，而很难以个人的力量使之改变，比如产业环境。这个时候，对于个人，最为关键的是自身的选择。
任何一个人，都有选择一个公司，选择自己工作的权利，发现自己的选择不当也可以放弃，这都无可厚非。
但选择之后，却只是浑浑噩噩或者怨天尤人，那就一定是错的，其结果只能是白白的浪费青春。
所以如果问题的原因是一或者二，那么管理者的第一个责任是让大家认清自己的选择。接下来则可以参照韩非子讲的法术势来开展自己的工作。
法即大家约定遵守的规则。这里的关键点是一定要大家都确实同意。确实同意后，这份规则事实上相当于团队成员间的一份承诺。
术即临时的应对措施。比如批评，惩罚或鼓励。批评，惩罚这类事情要以法为根本，无疑地违反自己承诺的人是应该受到批评的。
势么比较微妙，这里就不说了。
在做上面这些事情的同时，不要忘记了管理的基本原则：真诚的坚守双赢哲学。
要努力规划个人发展远景，帮助个人切实成长。
与此同时有两件事情一定不能做：
第一是单纯的使用大棒政策或放任自流。
大棒政策的简单描述是，我让你干什么你就干什么，不干的话或干不好的话，立刻就罚。罚的方式自然可能有很多，降低评价等级，批评等等。
从短期来看，这几乎是唯一能迅速见效的方式，但实际上这是在牺牲长期的利益。这种方法下效率降低，优汰劣胜（与优胜劣汰相反）几乎是一种必然结果。
与此相反，另一种极端是放任自流，试图维持一团和气。这样一来，团队的氛围尚可，但却没有战斗力，平时的时候趋于散漫，不从细处着手，日积月累，最终就会成为大问题。与此同时人员没有成长。长线来看，最终同时损害个人和公司的双重利益。
第二，试图用数字来度量个人。这么做的成本和效果完全不成比例。
在传统行业中似乎有计件工资这样的说法，而十分偏爱量化管理的人往往试图用某些数字直接对团队成员进行度量。这么做并非完全不可行，但对于软件开发而言，这么做是危险的。在前文曾经提到过，作为概念和逻辑集合的软件，其度量本身存在着非常大的模糊性。
比如说，如果以生产率 = 规模/工作时间来度量个人，并且使用代码行作为度量单位的话，有可能会出现反常的情形。比如完成同样的功能，优秀代码的行数可能比质量稍差的代码的行数要少，这个时候如果耗费时间相同，那么表面上看来，反倒是优秀代码这一方的生产率较低。
但以生产率，Bug率这样的指标对人进行度量，其危险性还不止在于数字自身的不精确。而在于一旦把这些数字通考评等牵涉个人切身利害的东西关联在一起，那么这些数字自身的不精确性很可能会被放大，进而导致更大的不公平性。代码行，工作时间，甚至Bug数这些关键性的度量指标，个人其实可以对其实施非常大的影响，而这种影响通常很难作为一种干扰数据的因素被排除出去。
