看完《人件》这本书，发现全书中基本没有涉及到任何软件技术，但作者精辟的探讨了专业软件团队管理这一非常专业的话题。怎么把团队做好，这是一个大问题。只有做好团队，才能做好软件。这本书同时也推荐了许多已在使用中的标准，如关闭公共寻呼系统，怎么面试软件开发人员等。由于《人件》这本书涉及的内容非常广泛，而且有许多后面的部分前面已经提到过，只是换了一种讲法而已，所以经过思考后，我决定分为四个方面去阐述《人件》这本书给我带来的新观点，它们分别从面试开发人员，管理开发人员，凝聚开发人员和办公环境四个方面来描述软工中需要注意的问题。
人力资源的管理
《人件》提到：软工本质上其工作的主要问题，与其说是技术问题，不如说是社会学问题。记得这学期软件设计课上老师也提过三分技术，七分管理，我想道理应该是一样的。但是下面又提到很少有经理人用这样的思想指导管理工作，在我做创新项目的时候我也是这种情况。我和我同组的同学更倾向于集中精力做技术方面，而几乎不怎么开会，一般是你做你的模块，我做我的模块，这种结果是到最后磨合的很差，记得我们中期开了一次会，发现我和另一个同学原来做的是一样的，缺少沟通让我们做了许多重复工作。而我们为什么会不集中精神解决人际关系方面的工作呢，《人件》告诉我不是因为技术更重要，而是因为它更容易做。的确如此，人际关系是很复杂的，大家都希望尽快做完项目，一味的去追求代码的速度，而没有人愿意去管岌岌可危的人际关系，因为人们的天性就是用对自己有利的方式去解决问题，与人沟通这种能力恰恰是整日埋头编码的程序员所缺乏的。
而对于编程这件事，从大一到大三，也编过不少程序了，但在考试的压力下我总认为一个程序越少出错越好。而《人件》告诉我对大多数脑力劳动者来说，偶尔犯一个错误是自然的，也是工作的一个健康组成部分。因为不太了解实际工作时项目经理的操作情况，但是我想如果他试图培养一种不允许出错的气氛只会让他的手下产生防备心理，如果我是那个项目组的一员，我会因为这种氛围而不去尝试我认为结果会很糟糕的事，比如尝试一种新的算法，尝试一种新的技术。尽管整个团队的技术平均水平也许会因为采取的任何限制错误的措施而得到适度改善，但是团队社会学却会受到严重损害。所以当人们犯错时，作为项目经理应该鼓励他们。说到错误，不得不想到老师曾提过软工中软件测试占着很大的一部分，而我在做创新项目时总是默认我写的程序没有错，或者说我潜意识里期待这样，这让我对检查出错这一结果十分厌恶，读了《人件》后我知道这是人之常情，并且我必须花更多精力在测试这方面。
《人件》内提到大多数程序员都是热爱自己的工作的，这一点我不太清楚，因为不太了解计算机从业人员是否都热爱编码这一过程。假设这条是正确的，那么“管理就是赶驴“这句话就有待商榷了，开发与生产不同，一个进行脑力劳动的人要进行思考，他有自己主动的
决定，纯粹的“赶”人能迫使他们动起来，却对于整个项目的进展是没有任何实质性的效果的。所以给我们的启示就是也许减少一点严厉的措施能让经理和成员都好过一些。提到成员就不得不说每个员工的独特性，独特性是一种很神奇的东西，每个员工或多或少都有自己的特质，也许某种人他技术不行，但是他可以协调好人际关系，有很强的亲和力，总是能准确理解客户的需求，并能帮公司维持稳定的客户源，若是这样项目经理就必须重视这种员工特质，因为亲和力是很强的催化剂。《人件》中有句很幽默的话：项目的全部目标就是让自己死亡，项目中唯一稳定的状态就是死后僵硬。项目评价关键在于动力学，所以催化剂的适时出现对于一个项目的完成还是有很大意义的。
以前经常听人们说软件从业人员是悲哀的，因为整天泡在公司加班加点，于是生活已离他远去，严重的可能还有“妻离子散”。这不得不显示软件业的管理就是在更大程度上以员工的生活为代价，让他们更努力、更长时间的工作。没有人能真正工作超过40个小时的，在我们这种学生阶段，对于自己喜欢听的课、对自己感兴趣的程序也顶多只能集中一个上午的注意力，而要以连续的和以创造性工作所需要的强度水平进行工作是没可能的，这提示我们若以后真正作为项目经理人时，要尽可能在不影响质量的情况下减少加班的时间，因为世故的程序员都知道保持沉默并抓紧一切时间补休，而菜鸟则是一味工作最后导致崩溃。若一味加班加点，可能的结果是失去一名优秀的员工，从而带来更大的成本—如培训一名新员工等，所以职业经理人需要考虑的一个方面就是员工的个人生活代价问题。前面提到一个人不可高强度的工作那么长时间，所以在高强度时间压力下就不会保证质量了，同时也牺牲了员工对于工作的满意度。