《人件》读后感

人在软工中的定位

-读peopleware有感

史婕茹5080369079F0803604

一、引言

未上大三前，就曾经听学长学姐说过《人月神话》和《人件》这两本书，它们被誉为软件图书中“两朵最鲜艳的奇葩”。于是我迫不及待的借了《人件》一睹它的风采。这两本书关注了软件开发过程中两个不同的方面，《人月神话》注重于“软件开发”本身，而《人件》则是强调了软件开发中的“人“。我选择了《人件》这本书来写读后感。因为我才大三，对于软件开发还接触不深，但看了《人件》这本书后再对照自己在国家创新项目中遇到的问题还是感触良多。

二、《人件》读后感

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

人力资源的管理

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

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

《人件》内提到大多数程序员都是热爱自己的工作的，这一点我不太清楚，因为不太了解计算机从业人员是否都热爱编码这一过程。假设这条是正确的，那么“管理就是赶驴“这句话就有待商榷了，开发与生产不同，一个进行脑力劳动的人要进行思考，他有自己主动的

决定，纯粹的“赶”人能迫使他们动起来，却对于整个项目的进展是没有任何实质性的效果的。所以给我们的启示就是也许减少一点严厉的措施能让经理和成员都好过一些。提到成员就不得不说每个员工的独特性，独特性是一种很神奇的东西，每个员工或多或少都有自己的特质，也许某种人他技术不行，但是他可以协调好人际关系，有很强的亲和力，总是能准确理解客户的需求，并能帮公司维持稳定的客户源，若是这样项目经理就必须重视这种员工特质，因为亲和力是很强的催化剂。《人件》中有句很幽默的话：项目的全部目标就是让自己死亡，项目中唯一稳定的状态就是死后僵硬。项目评价关键在于动力学，所以催化剂的适时出现对于一个项目的完成还是有很大意义的。

以前经常听人们说软件从业人员是悲哀的，因为整天泡在公司加班加点，于是生活已离他远去，严重的可能还有“妻离子散”。这不得不显示软件业的管理就是在更大程度上以员工的生活为代价，让他们更努力、更长时间的工作。没有人能真正工作超过40个小时的，在我们这种学生阶段，对于自己喜欢听的课、对自己感兴趣的程序也顶多只能集中一个上午的注意力，而要以连续的和以创造性工作所需要的强度水平进行工作是没可能的，这提示我们若以后真正作为项目经理人时，要尽可能在不影响质量的情况下减少加班的时间，因为世故的程序员都知道保持沉默并抓紧一切时间补休，而菜鸟则是一味工作最后导致崩溃。若一味加班加点，可能的结果是失去一名优秀的员工，从而带来更大的成本—如培训一名新员工等，所以职业经理人需要考虑的一个方面就是员工的个人生活代价问题。前面提到一个人不可高强度的工作那么长时间，所以在高强度时间压力下就不会保证质量了，同时也牺牲了员工对于工作的满意度。

在未看《人件》前，我曾经幻想过如果我是一名项目经理的景象。当时我觉得我会给我的员工们设置一个不可能实现的最后期限，因为我的感觉就是给予这个期限可以帮助他们为优秀而奋斗，让他们更有紧迫感，我的潜意识里认为我的这些员工都是有惰性的，必须在后面加以鞭策。但是《人件》让我从人的方面去思考，如果我是一名在高强度下的员工我会怎么做。诚然，就如书中残酷的现实一样，我会掩盖问题，等待以后处理或者把问题硬塞给产品的最终用户，这就牵涉到开发人员也不把软件用户当人看，也许应该有一本“人件”的姊妹篇来阐述这一点。会有人说提早发售的利润远远高于产品质量降低带来的市场损失，但这只是假象。长远来说远远超过最终用户需求的质量是一种取得更高生产力的手段。购买产品的用户在购买多次劣质产品后会最终放弃这家公司的品牌，并向周围用户群体传达该品牌质量差，不要买它的信息，相反，有口皆碑的公司则更容易赢得客户的青睐。所以经理们在各种时间压力下要进行质量和时间的权衡。

同样是时间问题，帕金森定律成了职业经理人的口头禅。正是这项定律让他们制定一个不可能的、乐观的交付日期。帕金森定律是这么定义的：给一个项目多少时间，它都能将之耗完。我觉得这个倒是挺适合我的创新计划项目的，但是我的项目跟一般意义上的项目并不一样，毕竟我的专职工作不是这个。《人件》提到除非是官僚机构，帕金森定律肯定不适用于你的员工，同样《人件》基于的也是编程人员会从工作中得到许多快乐的条件下。这时我想到了我第一次做PRP，那时我才大二上学期，跟着一位同学一起报的想尝试一下，结果老师属于不闻不问型的，我想我当时的行为在老师眼里也是不能履行工作并且对我的工作质量漠不关心。因为我当时实在不知道从什么地方入手，编程的能力太欠缺。其实这也就说明一个问题，这种工作对于我现有的知识水平来说太难了。《人件》告诉我们，当一个项目完全不合理或不现实的时候，不能再加班加点。项目组的成员会产生愤怒的情绪并在内心滋生一种挫折感——并且士气也会降到低谷。我想这句话是有一定道理的，如果有人限制我在一天内做完不可能做完的事，我内心里认定这是不可能的事，就不会努力去完成好它，说不定效率会极其低下。所以对于经理人来说不得意的情况下降日程排的很紧可以理解，但是总是这么做，就要考虑员工对你已经产生了极差的印象了。