人在软件工程中的定位
——读人件有感
刘胜男11计科一班 110507140120
初学软件工程导论这门学科，听老师说过《人月神话》和《人件》这两本书，它们被誉为软件图书中“两朵最鲜艳的奇葩”。于是我迫不及待的借了《人件》一睹它的风采。这两本书关注了软件开发过程中两个不同的方面，《人月神话》注重于“软件开发”本身，而《人件》则是强调了软件开发中的“人”。我选择了《人件》这本书来写读后感。
看完《人件》这本书，发现全书中基本没有涉及到任何软件技术，但作者精辟的探讨了专业软件团队管理这一非常专业的话题。怎么把团队做好，这是一个大问题。只有做好团队，才能做好软件。《人件》提到，软件工程本质上其工作的主要问题，与其说是技术问题，不如说是社会学问题。记得有位老师也曾提过三分技术，七分管理，我想道理应该是一样的。《人件》告诉我不是因为技术更重要，而是因为它更容易做。的确如此，人际关系是很复杂的，大家都希望尽快做完项目，一味的去追求代码的速度，而没有人愿意去管岌岌可危的人际关系，因为人们的天性就是用对自己有利的方式去解决问题，与人沟通这种能力恰恰是整日埋头编码的程序员所缺乏的。
而对于编程这件事，从大一到大三，也编过不少程序了，但在考试的压力下我总认为一个程序越少出错越好。而《人件》告诉我对大多数脑力劳动者来说，偶尔犯一个错误是自然的，也是工作的一个健康组成部分。尽管整个团队的技术平均水平也许会因为采取的任何
限制错误的措施而得到适度改善，但是团队社会学却会受到严重损害。所以当人们犯错时，作为项目经理应该鼓励他们。
《人件》内提到大多数程序员都是热爱自己的工作的，这一点我不太清楚，因为不太了解计算机从业人员是否都热爱编码这一过程。假设这条是正确的，那么“管理就是赶驴”这句话就有待商榷了，开发与生产不同，一个进行脑力劳动的人要进行思考，他有自己主动的因素抽象化并忽略掉。
提到关于人选的问题，不得不提的就是面试的问题。面试是选拔人才的方式，但是面试时似乎有条不成文的规定：可以问候选人以前干过的工作，但是不能要求看看其工作产品。但是检查其工作产品往往是非常有好处的，可以更直观的了解候选人。而新录取的员工往往被要求做能力倾向测试，这种测试大部分是关于左脑的，即不进行创造性活动。《人件》提供给我一个数据：一个有40年工龄的人，只有5年的工作时间，却有35年的管理时间。这就说明能力倾向测试只能为我们提供短期工作得很好的人，所以不应该只通过该测试来决定是否雇佣这个人来作为团队的成员。
大概从马列主义传进中国开始，理论指导实践的思想在人们脑海里已根深蒂固。伴随理论的指导实践是一套方法论，大方法论是关于所有种类的需要集中思考的工作应该如何进行的总系统理论。而这种大方法论并不适合在软工中使用。这让我想到了老师上课强调的文档的建立，而我们在强调文档的重要性的同时也要清楚的认识到建立文档不等于解决问题，有时候动手解决比建立长篇累牍的文档更为重
要。综上所述，方法论并不适合于软工，如果一定要规定一个标准，那么可以制定一个非标准的标准（即规定员工不能做什么）。
《人件》中提到了“黑衣团队”的一个案例。作为一个胶冻团队的特例，黑衣团队有种接近疯狂的行为，他们培养一种毁坏者的形象，在程序上制造各种失败，作为团队他们成功了，并且他们快乐的工作着，他们有着共同的目标促使他们成为一个成功的团队。
我觉得，建立一个有健康氛围的团队我们可以从以下几个方面着手：
1、质量崇拜；
2、提供许多令人满意的完形；
3、建立精英意识；
4、保持和保护成功的团队；
5、提供战略但不是战术指导。
以上就是我读《人件》的初步感想，我相信以后花时间再精读一遍会有更深的领悟。《人件》让我懂得“伟大的经理懂得人本质上是不可管理的，软件成功的本质是使每个人朝着同一个方向努力，然后使他们热情高涨，并且任何事物都不能阻止他们前进。”同时也让我重新对软工有了更深一层的见解，让我认识到了自己思维的误区。我认为《人件》带给我的是建立成功团队的非常重要的思想，对我以后的工作颇具指导意义。
