《人件》读后感

看完《人件》这本书，发现全书中基本没有涉及到任何软件技术，但作者精辟的探讨了专业软件团队管理这一非常专业的话题。怎么把团队做好，这是一个大问题。只有做好团队，才能做好软件。这本书同时也推荐了许多已在使用中的标准，如关闭公共寻呼系统，怎么面试软件开发人员等。由于《人件》这本书涉及的内容非常广泛，而且有许多后面的部分前面已经提到过，只是换了一种讲法而已，所以经过思考后，我决定分为四个方面去阐述《人件》这本书给我带来的新观点，它们分别从面试开发人员，管理开发人员，凝聚开发人员和办公环境四个方面来描述软工中需要注意的问题。

人力资源的管理

《人件》提到：软工本质上其工作的主要问题，与其说是技术问题，不如说是社会学问题。记得这学期信安综合实践课上老师也提过三分技术，七分管理，我想道理应该是一样的。但是下面又提到很少有经理人用这样的思想指导管理工作，在我做第三次项目的时候我也是这种情况。我和我同组的同学更倾向于集中精力做技术方面，而几乎不怎么开会，一般是你做你的模块，我做我的模块，这种结果是到最后磨合的很差，记得我们中期在微信群里详细的交流了一次，发现许鉴鉴和段雪源原来做的有一部分是一样的，缺少沟通让我们做了许多重复工作。而我们为什么会不集中精神解决人际关系方面的工作呢，《人件》告诉我不是因为技术更重要，而是因为它更容易做。的确如此，人际关系是很复杂的，大家都希望尽快做完项目，一味的去追求代码的速度，而没有人愿意去管岌岌可危的人际关系，因为人们的天性就是用对自己有利的方式去解决问题，与人沟通这种能力恰恰是整日埋头编码的程序员所缺乏的。

而对于编程这件事，从刚开学接触Python到最后完成大作业，也编过不少程序了，但在作业的压力下我总认为一个程序越少出错越好。而《人件》告诉我对大多数脑力劳动者来说，偶尔犯一个错误是自然的，也是工作的一个健康组成部分。因为不太了解实际工作时项目经理的操作情况，但是我想如果他试图培养一种不允许出错的气氛只会让他的手下产生防备心理，如果我是那个项目组的一员，我会因为这种氛围而不去尝试我认为结果会很糟糕的事，比如尝试一种新的算法，尝试一种新的技术。尽管整个团队的技术平均水平也许会因为采取的任何限制错误的措施而得到适度改善，但是团队社会学却会受到严重损害。所以当人们犯错时，作为项目经理应该鼓励他们。说到错误，不得不想到老师曾提过软工中软件测试占着很大的一部分，而我在做创新项目时总是默认我写的程序没有错，或者说我潜意识里期待这样，这让我对检查出错这一结果十分厌恶，读了《人件》后我知道这是人之常情，并且我必须花更多精力在测试这方面。

《人件》内提到大多数程序员都是热爱自己的工作的，这一点我不太清楚，因为不太了解计算机从业人员是否都热爱编码这一过程。假设这条是正确的，那么“管理就是赶驴“这句话就有待商榷了，开发与生产不同，一个进行脑力劳动的人要进行思考，他有自己主动的决定，纯粹的“赶”人能迫使他们动起来，却对于整个项目的进展是没有任何实质性的效果的。所以给我们的启示就是也许减少一点严厉的措施能让经理和成员都好过一些。提到成员就不得不说每个员工的独特性，独特性是一种很神奇的东西，每个员工或多或少都有自己的特质，也许某种人他技术不行，但是他可以协调好人际关系，有很强的亲和力，总是能准确理解客户的需求，并能帮公司维持稳定的客户源，若是这样项目经理就必须重视这种员工特质，因为亲和力是很强的催化剂。《人件》中有句很幽默的话：项目的全部目标就是让自己死亡，项目中唯一稳定的状态就是死后僵硬。项目评价关键在于动力学，所以催化剂的适时出现对于一个项目的完成还是有很大意义的。