《人件》书评

翻译的让人上火

书不错，但是翻译烂到非飞天，几乎很难看懂要表达的东西。难道拿在线翻译翻译的管理开发团体很难，看懂这本书更难

从IT书籍看东西方差异

东方的书籍注重应用性，理论性不强！西方的书籍更着重于原理的介绍，深入浅出！科技的差距，让中国人更浮躁更看重于眼前的利益，学一门技术更看中于它能带来的眼前利益，所以中国的IT只能跟着西方的技术亦步亦趋的小跑，而不能独立去创造！从VB，VC到JAVA，无不体现出西方创造的精妙，而东方只能在“大漠孤烟直”中去意想。都说西方擅长严密的逻辑推理，东方习惯于抽象意境，但我看来东方的抽象似一个病态的小妇人在那里无病呻吟。无聊之中，更感无趣！希望搞技术的人都看看这本书！

无题

“隔街找钥匙，只因街更亮” ---- 我们关注技术方面的东西而故意忽视人际关系的问题，不是因为它重要，而是因为他更容易。允许犯错 ---- 团队技术平均水平或许会因采取的任何限制错误的措施而得到改善，但团队社会学却受到了破坏。团队催化剂 ---- 一些成员的重要性就在于他让整个团队凝聚。加班 ---- 从长远来看，这些好处都会被抵消。世上没有加班这件事，在时间的压力下，人们只是工作得更快，而不是更好质量 ---- 如果时间允许，我们可以考虑质量？在日本，高质量导致成本降低普遍被人们所接受。给一个项目多少时间，它都能耗完 ---- 这个理论之所以流行，只是因为它的有趣。当一个项目完全不合理和不现实的时候，不应该再加班加点。成员的情绪会跌落至低估。什么是管理 ---- 经理的职能不是强迫人们工作，而是让人们有可能工作。清静的环境？ ---- 在一个开放“噪杂”的环境下，人照样可以集中精神。这只是一个适应过程。突然看到封面上说：这是一本为开发者争取权利的书。自由的工作时间 ---- 公司用一种简单的“自由假象”，让你在加班时更加心甘情愿。而且，重要的不是你出勤的数量，而是发挥潜力的时间。人才是最重要的 ---- 谁做这件事情往往比如何做这件事情更加重要。不够专业 ---- 这个术语经常用来描绘令人惊讶和制造威胁的行为，专业往往用来描述那些“完美的样板”，但事实上有知识和能力的人才是专业的人。公司的熵总是在增加的 ---- 熵就是平庸和相同。人员流动的成本 ---- 更换一个人的成本相当于一个雇员5个月的成本。有最低人员流动率公司的特点是广泛的再培训。长篇累牍的文档 ---- 是问题的一部分，而不是解决问题的一部分。团队的作用 ---- 是每个人都朝着共同的方向前进。你的“团队”真的是团队么？管理？ ---- 最好的成功是没有明显管理的成功，最好的老板是一遍遍地管理着这个集体，而不让成员感觉到“被管理着”。你感觉到自己在团队中有一种不可或缺的能力么？你感觉到自己的独特性了么？ ---- 你的项目经理的管理已经成功了。人是不可管理的 ---- 他们只需要有一个目标，然后调动他们的积极性即可。经理 ---- 你不是团队中的一员。眉头紧锁 ---- 这不代表专业，工作应该充满乐趣！无序 ---- 在团队内允许一些无序的存在。这些无序反而是亲和力建立的基础。竞争 ---- 在一个有适当竞争的团队中，我们愿意让别人看到我们正在接受训练和成长；也乐于帮助别人成长。CMM ---- 公司的能力通过一个模型来衡量，越符合这个模型，分数越高。这就是理论!CMM ---- 一个紧箍咒罩着你，安全第一。你要承担一些更有风险，更有价值的东西，就得放弃它。实践 ---- 我们应该识别一些有用的实践，而强制执行一些实践却是另外一回事儿。裁员 ---- 把曾经的投资扔出窗外？好吧，这仍是为我们争取权益而已。学习 --- 公司的学习应该来自于中层。中层是高层和低层的纽带。浪费 ---- 人的时间浪费是最大的浪费。很多会议并不是会议，而只是仪式。社区 ---- 如果社区意识足够强，则没有人想离开。

强力推荐参考

通俗易懂，案例鲜活。能够将一个个问题分析得很到位，令人感同身受，很不容易。例如书中谈到环境对效率的影响，反映的正是当下普遍存在的现状；又如论及对项目现状无法客观评价，暴露出很多人的逃避心理，导致最终的失败...虽然看似是一本指导管理的书，却也揭示了不少与人性相关的东西。作者用心分享，确实值得一读。推荐〜

伸张正义

温习旧书还是有好处的。这本书的内容如果有一句话来概括，应了封皮上的小字：为软件工程师伸张正义。我想我已经过了读这种书的程度了，我欣喜于看到了自己的成长。

翻译太差了

翻译太差了，有时候看了一段琢磨不出到底想说啥意思。作了一些笔记：软件工作团队管理问题学习第一部分 人力资源管理管理问题的实质本质上，技术管理者工作中的主要问题，与其说是技术问题，不如说是社会学问题管理问题的实质成功源自于良好的、与所有的工作参者的人际交流关注技术而不是社会学方面的问题，就如在一条黑暗的街道上丢失了钥匙，却在另一条街上去寻找，因为“这条街道灯更亮” 团队不是机械偶尔一个错误是自然的，这是工作中的健康的组成部分，是他们得到报偿的一部分我们必须建立这种对错误的态度使开发工程系统化、把生硬的方法论强加给员工、替代员工做所有关键性的决策，技术水平也许获得适度的提高，但团队社会学会严重损害团队不是机械大多数人都热爱自己的工作，但必须作更有意义的工作只有时间做,没有时间考虑我们必须学会花更多时间思考工作本身，花更少时间工作http://computer.mblogger.cn/lugis/archive/09162006.aspx

个人与团队

一个团队的成功取决于五大要素：人力资源的管理；办公环境的协调；筛选适当的人才；高生产力的培育；工作心态的调整。这五大要素缺一不可，个人利益总是与团队利益有着千丝万缕的联系，只有团员积极向上才能让团队徐徐生辉，而要想让对团员积极工作，强制是愚昧的，咱们不能改变他人思想，但可以在工作上做到统一行动。

在软件开发中人的重要性

看完《人件》，我读懂作为管理者，有那么多可怕的短期行为所造成的重大损失。看完《人件》，作为一名普通员工，我是那么期望到胶冻团队中去工作。看完《人件》，我有如下思考：作为社会个体的人，当我们临终前一刻，目前的工作状态、工作结果是我们想要的吗？有千万中理由浪费一天，但没有任何办法找回了。这里的浪费有不同的意义扩展，对于修行人来说，一天心中无佛那就白修行，浪费了。对于管理者来说，没有意义的管理工作，不但浪费自己的也浪费了下属的一天。从另一方面说，忙，并不代表你就是过了有意义的一天，所以说愚痴是那么的可怕，一天天过去，甚至于浪费一生，到头了空悲切啊！《人件》对于我自己来说，结合我自己，很有同感的有：1、时间片，各种繁杂事务不时袭击你，电话、qq、email、临时紧急安排等等，将一天的工作分隔成各种独立的小单元，难有深刻的思考，包括管理、技术。2、开放的工作环境，也是造成时间片的一个非常重要原因。3、对于程序员和普通机械化生产的工人，我们能用统一的方式方法进行管理吗？什么绩效考核，按件计价，标准化流程管理，质量标准管理，这些或许会培养出一批蓝领计算机开发工人，从事低层次的代码工作，谈不上创新，谈不上质量，谈不上团队管理，更谈不上复杂的工程实现。4、要求加班，严格纪律管理，项目时间的紧箍咒等等，只会是短视行为。5、员工的流动性所带来的恶果，远远超出我们的预期，一方面证明了我们所提供的工作机会、环境没有竞争力，也可以说我们没有形成胶冻团队。另一方面，替补该员工所花费的成本，或许远远不止6个月的人工成本。6、人力资源：人的可以培养的是知识、技能，很多先天的东西并不是一个公司所能改变的，一个人的品质决定了一个人的能力范围，所以说招聘对于一个企业是多么的重要。一个员工对于企业文化的认同是企业的一笔财富，员工缺乏某种技能导致跟不上公司的发展，宁愿花大力气去培养他，也比从外面聘请一位有经验的新人更有价值。很多时候，我们的企业文化都从较高的角度去阐述，或者从客户的角度进行关注，缺少一些从员工从团队出发的实实在在的可行阐述，例如激情团队，如何做到？1、2、3......快乐工作，如何做的？1、2、3......7、避免团队的7条自杀行为，要相信人是自我要求成长的，团队是可以自学习的。8、工作也是生活，团队成员也是好朋友，一起工作是我们的缘分，融洽快乐是我们不断创造更多的源泉。

你不会一辈子都是程序员

我们能为我们的社会贡献些什么?我们能为我们的工作环境贡献些什么?我们能为我们自己的发展做些什么?如果有一天我们成为管理者,我们可以或应该做些什么?这是一本关于团队建设的书(在我看来),你总是有机会了解作者想告诉你什么.

中国有这样的软件公司吗?

正在Reviewing人件,"策划人语"里面说"20多年转瞬即逝,我们听说过很多软件英雄和编程奇才的故事,却没有产生一个有国际影响力的软件品牌或有国际竞争力的民族软件企业".我比较孤陋寡闻,想问一下大家:1.这样的软件公司中国有吗?2.中国是不是一定要有这样的软件公司?3.这本书出版是03年,现在是09年,6年过去了,中国的软件有什么变化吗?重点是第一,第二个问题,欢迎大家讨论!谢谢!

软件管理的人文精神

《人件》和《人月神话》完全是两个风格。管理，不仅仅是技术，更是充满人文精神的艺术。而且《人件》中的一些很精辟的箴言远远超过了软件管理的范畴。没有大量的数字、精密的论证，也不需要这些。这正是《人件》深入浅出的长处。“容易的不解决问题的方法比艰苦的解决问题的方法更加吸引人”、“我们倾向于集中精力做技术方面，而不是人际关系方面的工作，不是因为它更重要，而是因为它更容易做”、“人际交往是很复杂的，并且就效果而言从来都不会是很明晰和清楚的，但是它们比工作的其他任何方面更重要”……管理，就应该是这样。作为一个管理者，首先应该管理好自己，包括行为、习惯、道德、人格等。所有的技巧技术可以学习到，它们有效但是也有限。从根本上说，一个天生的管理者，他凭借的不是技术而是道德的力量、人格的魅力，这些是不能被任何东西取代的。

可以一读再读的好书

在你从事软件开发这个行当的任何一个阶段和任何一个位置你都应该阅读的好书。在这个行业呆得越久，你越会发现这本书讲的这些绝对是真理。唯一一本我任何时候更换办公位置都随身携带的书

所有做计算机的朋友都应该看一看

说了很多软件工程的真谛软件工程师制作的软件产品和他的尊严密切相关，不是软件的数量，而是软件的质量。如果更多的人懂这个道理，我们国家的软件工程就不会这么差，就不会总是做不出品质优良的产品了。

高科技的幻象

在这本书的扉页上，写着这样的一句话：在成千上万的书架上，《人件》永远和《人月神话》并列在一起。作为一本主要讨论软件组织中人文环境因素的著作来说，这本书面向的主要对象应该是软件组织的管理者。但这真是一本令人震惊的书，看来无论国内国外，软件业的真实现状，都不容乐观。软件行业是很奇怪的行业：程序员向往高科技，却被高科技的幻觉所害，在满腔热血，奋不顾身投入到这个行业后，失去了财富、健康和信心。有成就感的人，要么在外企，要么自己当老板或转行。更多的人，在患得患失的困境中，对未来抱有莫衷的期望。不久前，我去参加一个高校的软件学院举办的企业峰会，来了很多国内、国外的知名企业，领导们纷纷发言。我只听懂了所有人都在表达一个意见：人才是可以象加工罐头一样的生产。每个人只是一个零件，每个零件都是可以换的。我感到震惊的是，很多过去从事过技术工作的人，大多也支持这种观点。每当我重读《人件》时，我就觉得不是程序员天生生来命贱，而是环境，软件在这样的生态环境中，只是奢侈品。读《人件》，不是了解一种管理方法，而是学习如何尊重人，发挥人的潜能，通过人来创造高效率的团队。我的博客：http://www.dapenti.com/blog/blog.asp?name=xilei

发挥个人的能力才是最关键的

事情起源于动态语言和静态语言之争，最后争论焦点转移到：「相信人本身的能力重要，还是通过语言/工具来约束人重要」。我认为项目开发中最重要的是个人能力和团队协作能力，工具只是加分项。如果代码质量差、监控难、性能难以优化，解决根本问题的关键还是在人身上。并不是静态编译和工具检查就能搞定了。我愤愤的在 QQ 对话框中写道：> 我工作第一年痛苦于开发流程，阅读了《人月神话》，就开始坚信软件工程的哲学> 后来痛苦与代码质量，阅读了《重构》，开始坚信代码质量决定产品质量> 现在痛苦于人和语言的冲突，动态和静态的冲突，我想读《人件》了人件已经绝版，只能在找线上版，我花了两个星期把它读完。书中给了我一部分答案，另外还有一些意外的收获。<!--more-->《人件》其实讲了一件事情：怎样将脑力劳动者管理好，打造出一个高效的团队。《人件》@豆瓣： [http://book.douban.com/subject/1108725/](http://book.douban.com/subject/1108725/)《人件》在线阅读地址： [http://book.zi5.me/books/read/2206](http://book.zi5.me/books/read/2206)吐槽：翻译太烂太烂太烂了，下次要看直接去看翻译版。## 以人为本 ##> 我们工作的主要挑战，与其说来源于技术，不如说来源于团队成员本身技术人员转成项目经理经理之后，往往继续用工程化思维管理人员，认为人是可以设计成标准化接口，是可以替换的。很可惜，这种想法不是那么 **有效**。因为脑力劳动和体力重复劳动不一样，不是在卖汉堡这种重复工作，而是需要创造、思考和发明的工作。软件经理需要提供有限额的错误机会。错误无法完全避免，并且是工作内容的健康组成部分。一旦硬性阻止犯错，会让团队成员失去创造的勇气。我相信这也是为什么 Facebook 早期会践行「Break it Down」。## 何不双赢 ##> 西班牙人的理论坚持认为地球上只有一个固定数量的价值，> 因此通向积累财富的道路就是学会从土地或者从人身上更有效地榨取财富。> 而英国人的理论认为价值可以通过天才和技术创造出来。因此英国就产生了工业革命，> 而西班牙人就转动起了车轮，开始开拓疆土和剥削在新大陆的印第安人。> 他们从海上运回大量的黄金，> 他们所有努力带来的却是通货膨胀（太多的金钱追逐太少的有用货物）。我坚信公司和员工并不是对立面的，双赢才是正确的路线。大部分情况下，我愿意牺牲个人时间和精力来完成公司的任务。前提就是对产品有认同感，对公司有归属感。## 最好和最坏 ##作者通过一个持续两年，有来自 92 个公司的 600 多名开发程序员参加的比赛，分析出以下数据：* 成绩最好与成绩最差的人之间的绩效比率是10 : 1。* 最好选手成绩大约是中等成绩选手成绩的2.5倍。* 成绩中等以上的一半选手与另外一半选手的绩效比是2 : 1[外刊 IT 评论](http://www.aqee.net/)的[为什么程序员的工作效率跟他们的工资不成比例][] 一文中也提供一些数据支持。我离最好还有很长的距离，但是我相信个人能力是可以提升的，并且在个人能力上面的投资汇报比极高。## 高效工作的秘诀 ##> * 进入顺流：咦？怎么时间过得这么快？！> * 邮件比电话更不容易打乱人的思绪## 团队的力量 ##> * 团结起来，工作的更高效更开心> * 有目标的团队，1 + 1 > 2> * 为一个共同的目标走到一起> * 优秀的团队里的成员，不会因为钱、阶层、晋升的问题离开团队> * 优秀的团队往往是带有个性的《人人都是产品经理》中当时讲了一个愿景（Vison）问题，我相信一个好的愿景可以吸引更多高质量人才，为赚钱而创建的团队是不会长久的。## 烂团队的苗头 ##> * 防范团队成员> * 官僚作风> * 不挨在一起工作（空间上）> * 某个成员的职责被分割多份> * 对产品质量要求降低> * 无意义的截止日期（不可能达到的目标）> * 结党营私> * 加班> * 绩效考核 / 目标奖励 > * 早期时候人员超编这里和上文的愿景问题是对应的，无论是强制加班还是通过考核回报激励，都不是激发人的创造力和战斗力的好方法。老大们应该学会画饼，画大饼。另外，管理团队果然好难：做的事情必须靠谱，才能吸引到人才；需要能管理好有个性的人才（比如伞哥这样的）； 在中国大环境下，还要不错的物质回报。## 经营好团队 ##> * 崇拜高质量：因为市场和用户需要高质量的产品> * 通过里程碑的方式管理任务，提高士气> * 崇拜精英> * 允许和鼓励异端：异端代表创新和进化，没有异端就会种群灭亡> * 给予自由度：对成员信任，而不是纯粹服从权威工作> * 交流，唤醒那些有潜力的巨人（唤醒了才能将脑力劳动能力发挥到极限）> * 内部竞争和培养> * 管理层自身的学习，公司自身定位的不断改变> * 将公司内部建设出社区文化（我觉得就是公司团队文化建设嘛）我有一个观点是工程质量决定产品质量，产品质量决定整个团队。质量的一个标准是：**我以此为荣**## 工作是一种乐趣 ##> * 将混乱重建成秩序是有趣的> * 敢于用小项目来做尝试> * 组织竞赛游戏> * 团队头脑风暴这本这么老的书居然提到团队竞争游戏，和 Facebook 的 Hackday 异曲同工啊。再为这种乐趣补充一点：将公司的成果分享到开源社区。> 团队成员需要做到：> > * 界定自己工作，成为主人翁> * 促使自己成长为多面手，而不是单纯某个职位给了成员足够的自由度，那么就会有相应的风险，需要对他们进行监测，另外招人时候就需要找靠谱的人，这也是为什么 Facebook / Google / 早期百度对招人要求极其严格。## 流程改进 ##> * CMM 是标准，是标准的话就一定不是对于个体的最优情况> * CMM 自身也在改进，说明上一个版本的 CMM 不是最优> * 流程的目标是：提高质量 / 提高生产力 / 减少风险## 读后感 ##发挥个人的能力才是最关键的，要点在于信任、自由、乐趣。原则是 Pull 而不是 Push。我会继续学习和思考这些原则，因为总有一天我也会面临这样的挑战。[为什么程序员的工作效率跟他们的工资不成比例]: http://www.aqee.net/why-programmers-are-not-paid-in-proportion-to-their-productivity/-----via: http://blog.log4d.com/2013/04/peopleware/

翻译太差

看完《人月神话》以后，接着看《人件》。其实书还算不错，我给出三星，总体是因为翻译的问题。相比《人月神话》，此书的翻译就显得差强人意了。书的前半部分还行，到后面有些句子就有些看不明白了，并且有些句子需要回过头看两三遍还不知所云。这种情况只有我在阅读英文原文的情况才会出现。可见《人件》的翻译，实在是太忠于原文了。而往往忠于原文的字面翻译，不但使译文仍然带着大量文化的差异，还往往扭曲了原文的意义。相比之下《人月神话》的翻译，就要好许多了。再简单说说内容，个人感觉《人件》其实主要是给项目管理人员来看的，希望引起管理人员对人的关注。很多篇幅着墨于人员的使用。其实关于人员的个人管理，有许多这方面的著作，用于提高个人管理的效能，如《卓有成效的管理者》、《早点离开办公室》等等，其中的许多原理，《人件》中都有叙述，但是个人认为不如前面两本来的专业。关于团队建设的一些观点，倒是值得学习和引用。说这些，希望有机会看原版。

为开发人员伸张权利?

近日读《人件》这本“旧书”，这书确实不错。不过，这本书主要不是写给开发人员看的，作者是两名consultant，他们的工作是分析研究软件项目的过程，对项目给出指导，很显然，他们的目标是项目的管理者、公司的管理者。而如今，这本书被标榜为“为开发人员伸张权利”的书籍，显然老板并没有兴趣阅读一本为底下的人伸张权利的书，很明显，出版社也知道这本书的读者都是那些受够了的程序员，所以才用这种花招来宣传。只是，这本书如果只给开发人员阅读，它的实际意义就打了很大的折扣了。软件开发领域的悲哀。

人员的管理不是把人当作“件”来管理

本书的翻译可谓极差，非常难读，很多时候参考原文，或者需要重新以英文的方式解构之。本书内容还堪一读，但是对于实作，坦白讲，对于当今中国软件业可谓并无实作之可能。当今的业态，以外包和工程为主，很多时候，不是在写一个“软件”，而是在堆砌一个建筑。研发的比例少之又少！Peopleware这本书对于研发团队，有一定的可以借鉴之处，但是无关people management。Peopleware更关心的是，创造力的保持和激发。如果你确实有研发团队，而且发现很多研发效率问题，而不是管理问题，可以参考本书。但是最好是直接读原版！

联想到国内软件业现状

首先我很同意关于翻译，大家的观点，尤其后半部分。书中的内容对于软件业从业人员来说，是很容易理解的，尤其是对于程序员和项目经理，很容易产生共鸣。但是，往往在现实中，决定从业人员的人文待遇的人一般来说没有这样的觉悟。在一般的公司中，要么是吝啬的老板不愿意接受《人件》中的思想，要么是一些拿着鸡毛当令箭的HR 们，甚至是office assitant 们在人为的制造障碍。所以我觉得，这本书应该给每个老板发一本。

书中提到的很多问题今天还是存在，还是一针见血。

书中提到的很多问题今天还是存在，还是一针见血。很多问题的存在有的是公司没有解决的能力与资源，有的是知道问题但却没有信心或没有兴趣去解决它。问题既然存在，那它的影响就不会消失。管理上不下功夫、投入，那代价自然要在项目、产品、人员等方面来扣除弥补。相信每个公司都希望有和谐的环境，公司的管理者需要首先考虑能够给开发者什么，能够给到什么程度，然后再来设计管理的细则，把人员的能力、效率什么的发挥到最好的水平。

[评价]软件项目工程里面人的管理和思考

很多年前，刚开始踏入IT界，就有人推荐我应该看两本书，一本是<r人月神话>，另外一本就是<人件>。可是10多年过去了，我是这个月才真正的拜读了<人件>，回想起自己多年来接触过的，参与过的大大小小成功、失败的项目，以及参与到公司装修、布局时候遇到的各种问题，不由得发现：原来若29年前(1987年 <人件>第一版)，就有人思考过，总结过，实践过，成功过也失败过了。绝大多数情况下，谈起项目，大家总是在思考：项目流程应该如何规范，软件框架应该如何搭建，产品架构如何设计，项目周期、风险如何控制，但是其实在IT项目中，真正能够发挥作用而却往往被忽视，而是当成工具的，就是“人”。只有当项目中的每个“人”的主观能动性调动起来的时候，项目才能成功。下面的摘抄，体验过的人相信都深有体会：========================1.我们还没有时间来考虑这项工作，只有时间来做这项工作2.人们在受到时间重压的时候不是工作得更好，只是工作的更快3.经理的职能不是强迫人们工作，而是让人们有可能工作4.需要高度集中精力的工作，需要顺流(flow)状态工作才能顺利进行(这需要环境的配合以及项目的合理分配)5.一个团队的目的不是达到目标而是向目标看齐(大多数公司并没有故意开始扼杀团队，他们只是在那样做而已)6.在最好的公司里，自然权威在所有的方向生效：每个人都在做自己最擅长的事情，并且被公认为那个领域的自然权威，只有在这个思想开放式管理的氛围中，团队有形成胶冻(jell)的最佳机会

看了一半, 觉得说的都对

可是国内有几个认真做软件的赚钱的, 只有钻政策空子,脑袋灵光的人才能做老板, 做下面管理层的就更不用说了,都是赶鸭子的. 关于空间的讨论(第9章)是我确确实实感受到的. 公司面积扩大, 人数增加, 做程序员的空间反而变得更小.程序员的价值<销售<管理<人事

做个懂管理的好员工

说实话,这本书写得很好~~虽然我只读了一遍,里边还有东西不是很了解,但是我敢说,对于一个管理者而言,这的确是本好书!我也同意楼上有为XD说的:这是本为程序员声张正义的图书!作为一个好员工,同样也应该了解管理!我是个底层的小管理者,管理着一帮学生,书中或多或少还是给了我很大启发!不过在我上层,有各种大大小小的管理者!汗自己一下

关于《人件》的自身感受

看完人件，翻译确实比较晦涩，每每看完此类的书，总是在反思身边的事情，身边的“环境”怎样，有多少是值得改进的（虽然我们无能为力），用来指导自己如果我是领导，我应该怎样优美的处理类似的事情。很多时候我们就被当作了人件。一些收获如下，部分摘自网络书评：1.脑力密集企业最大的投资和资产，是人力。 　　 　　2.办公室位置布置（根据亲密梯度安排，最里面的区域->个人）&保证研发创意员工的不受干扰（电话）。 　　 　　3.人才流动越大，带给企业的损耗也越大。 　　 　　4.打造共同价值的管理文化：对个人来说，除了事业成就，还包括在这个过程中得到的回应，与同事共患难的心路历程、与感受到人际关系的美好——留住人才的关键。 　　 　　5.几种最不利于团队成立的因素：防御性管理（作业流程标准化+技术控制）、官僚作风（层层的公文递交程序）、实体隔离（在办公室里的位置相聚较远，缺少交流）、时间分割（使团队成员身兼数职）、产品的品质降低（提早交货）、虚假的最后期限（需要脑力的工作并不适合最后期限）、派系的控制（故意打散团队）。 　　 　　6.几种经营团队技巧：营造出追求品质的狂热气氛、让成员感受自我和团队优越感、鼓励个人发展特色、尽可能提供策略性指示。 　　 　　7.团队：员工的互信、互敬与能力的紧密结合。如何让整体工作效率大于部分的总和,这个问题很发人深省。 　　其实，个人单打独斗是很累的，会缺乏韧性，而且由于没有其它人的启发，犯错误的机会也会更多。所以单打独斗并不见得开发效率高。 　　一般来说，3～5人的开发团队，效率是最高的。人多了或少了，都不见得是好事。 　　其中最关键的是沟通因素。如果成员都善于沟通，而且有很好的沟通环境（如BBS，咖啡吧等等），那么是很容易出好成绩来的　 8.黑衣团队，有些类似于architecture board，给特殊的人特殊的荣誉，并组织起来，关键是要形成真正的团队。 　　 这个就是所谓的建立精英团队和精英意识，崇拜质量。 　　9.保护异端。 　　10.平庸的经理担心权力象征，伟大的经历知道，人实际上是不可被管理的。成功管理的本质是每个人向同一个方向努力。 　　尊重员工，让员工过的更舒服一些比较好的书评：http://book.douban.com/review/1604335/

不是书评，是“翻译评”

淡定，“很差”不是给“Peopleware”的，而是给UMLChina翻译团队的，你懂得。我没有比对英文原著，所以只能从文中中英文并存的部分来窥豹一斑。比如Software State-of-art翻译为“软件的艺术状态”，这个实在是copycat的要命。整本书文字不算多，内容的确非常有料，可是拖拖拉拉看了很久才“念”完，再一次让我坚定了技术书绝不看翻译版的决心。做事要认真，没有金刚钻别揽瓷器活，半成不就，害人害己。

给IT管理者的书

是一本给管理人员的书 1.高科技幻觉：所谓的HighTech企业，多数员工都是做应用，因此仅仅关注技术而不关注人是误入歧途。 2.有人把管理开发人员比作“赶驴”，另一本书中比喻为“赶一群高傲的猫”。 3.工作风险越大，越要更好的互动，一个越不可能完成的任务，越要频繁的进行头脑风暴。4.工作场所和环境很重要。正确，高薪和很好的工作环境，我选择后者（前提是薪水差距不是那么大）。5.噪音很重要：记得我在以前的公司，很多大设备旁边工作，差点殉职，想想那个时候太傻了。6.黑衣团队，有些类似于architecture board，给特殊的人特殊的荣誉，并组织起来，关键是要形成真正的团队。这个就是所谓的建立精英团队和精英意识，崇拜质量。7.保护异端。8.平庸的经理担心权力象征，伟大的经历知道，人实际上是不可被管理的。成功管理的本质是每个人向同一个方向努力。一句话，尊重员工，让员工过的更舒服一些。

人件　记

　　每个人都应该有一个自己独立的工作空间，可以提高生产力。就记得这个观点了。。。　　每个人都应该有一个自己独立的工作空间，可以提高生产力。就记得这个观点了。。。　　每个人都应该有一个自己独立的工作空间，可以提高生产力。就记得这个观点了。。。　　

内容很好，翻译的一般

很多关于管理，关于软件行业，关于软件工程的理论，关于人，关于人的习性，程序员的习性，都论述的很精辟。不过翻译的确实有点不怎么样，好多句子读啊读啊，就是不知道什么意思，特别是这本书的最后几章。简直有点受不了了，还是读读原版或者影印版的吧。

比较理想

这本书感觉很罗嗦（也可能是翻译质量的原因），反复说一些差不多的道理。总结就一句话，以人为本。这当然是大家希望的理想状态，但对国内软件开发的实际借鉴意义不大。就看到第三篇，这翻译实在看不下去了

太直接了，人艰不拆好吗

高科技幻觉：事实上，社会学更加复杂（politics）测试一旦程序失败，他们便可怕的笑着如何让团队自杀：防范性管理官僚物理隔离员工的时间分割质量要求降低虚张声势的最后期限私党控制再论团队自杀：年薪和绩效考评目标管理褒奖出色完成任务的某些员工奖励奖金同类与下级挂钩各种可能的形式测量绩效监督直接监督对于开发人员来说是个笑话， 那是为犯人准备的沙特尔的改变模式：旧的现状------->混乱------>综合实践------>新的现状·········↑···········↑·····························外来因素···正在改变的观念··················我们常常把混乱当作新的现状学习不如孩纸快：他们对自己受伤的关心程度还比不上他们对自己出丑的关心程度

关于翻译问题

引一段原文的话"此外,我们对翻译和编辑质量严格把关,虽然两度延期出版,但让我们欣慰的是,如今终于可以向读者和原著者们提交一份负责的答卷".看完中英文版以后,偶再做评论哈

对UMLChina的翻译质量实在不敢恭维

人月神化就翻译的不咋地但是这本书简直是把这不咋地又发扬了光大甚至怀疑翻译书的人有写作功底吗

有点扯了吧

这是一本好书。但恰恰是不那么逻辑，不那么西方，不那么严密的一本书。它有很多好的结论，比如说那个著名的“流”的说法，程序员需要流，那么我们要尽量创造适合产生这种流的环境。我记得在amazon看过一个评论说这本书写的很牵强，主要是指它的论证过程，那个作者更倾向于Scott Adams的辛辣风格，当然Dilbert很难说得上有建设性。我不大喜欢的是国内的这种推销方式，把一本书随便的乱盖上帽子，什么什么必读，什么什么权威，感觉这些出版商的层次比较低。不过这也是国内广告业的现状，不管叫得多恶心，叫得响就好。可怜的是老百姓的耳朵。

翻译 还是翻译

有能力的还是去读 原文把。翻译的实在惨不忍睹，难道这些翻译因为多掌握了几门语言，反而把自己的母语丢掉了？原文如果是浓香味醇的鸡汤的话，翻译之后只剩下满锅油腻的油沫，用勺捞捞，还能捞上几只鸡屁。原本一本有趣的书，被弄成这个样子，实在是罪过罪过。原本作者的风格是简单易懂，通俗有趣的科普类，结果变成了深奥难懂的论文风格。也真难为这些翻译了，太不容易了。

好书|笔记|同时推荐德鲁克

这本书的内容的组织上比较让人抓不住头绪——每一章、每一节都让人觉得鞭辟入里，但整体上很难给人把握住。如果让我概括性总结一下，我觉得是：开发中对人的‘管理’重于对技术的管理，这种‘管理’重在‘理’而不是‘管’，这种管理的核心理念是尊重开发人员、让开发人员‘快乐开发’，这种管理的最高境界是无招胜有招——看似无为，其实处处费尽心机。看看卓有成效的管理者 就会发现 其实很多观点早已阐明且更为深刻。比如说，对不要把自己的员工当做生产劳工；强调知识员工的自我管理；强调给知识员工单独的工作空间和独立的时间段进行创造性思考等。第一篇 管理人力资源 === 管理者的误区脑力劳动者与体力劳动者有太大的区别。因此，我们需要允许他们犯错误和参与关键性决策，甚至鼓励其犯错误；开发者们几乎都是热爱自己工作的；尊重员工的个性和特征；除了评价一些静态指标外，我们需要考虑每个人员是如何适合一个团队的——如同催化剂作用一样；随着风险和压力的增加，应该增加谋而后动的时间，甚至是团体性的大规模头脑风暴。项目经理经常有延长员工劳动时间的倾向；然而加班就像是冲刺，只是在最后的几百米有效。对于工作狂员工，应该尽早提醒他们，死前无法完成一切心愿。工作狂是一种疾病，会传染的疾病。一群工作狂在集体工作的时候，可能暂时性的产出会很高，但最终他们都会离开，而离开带来的代价会更大。因此，要非常关注一个企业的流动率。工作狂的产生与工作压力有直接的关系——而项目经理的一个普遍性倾向是将项目的deadline设置得非常紧张以期增加员工压力、提高效率——但是，要知道的是，压力不能让人干的更好，只能干得更快——更快的代价是低劣的质量和潜在的缺陷、以及员工对工作满意度的丧失。那么对于质量呢——项目经理们习惯于抱怨程序员们的代码质量低下，然而却不知道质量低下的原因正是他们施加了太多压力导致的。是，质量是免费的，但这句话只适合于愿意为质量付出巨大努力的人。在一些软件公司，开发团队甚至可以一票否决对产品的发布。为什么项目经理们会倾向于给团队成员施加巨大的压力？帕金森定律是个玩笑定律——给一个项目多少时间，它都能将之耗尽；这条定律诱惑项目经理们制定出不可完成的计划——他们认为，反正会被耗尽，不如制定出 mission impossible的计划，驱赶开发人员更为疯狂的付出。因此帕金森定律绝对不适用于软件开发从业人员：他们喜欢这份工作，不喜欢拖拖拉拉。倘若他们不必在他们质量标准上进行妥协，他们也和你一样希望把工作做好。倘若你发现了一个员工，他偷懒、懈怠，那么首先要考虑的问题是——他是不是已经被压力压垮了？ 从已有数据来看，那种完全没有开发压力的项目，会导致最高的生产效率。然而，项目经理本身可能就是绝望的，他们期望从技术的角度解决他们的问题——然而，技术基本总是不能解决根本问题的——优秀的项目经理几乎永远只是在人际关系的处理上更为出色。好经理并不是驱使别人去工作，而是使人有可能好好工作。 ============第三篇 如果找到合适的人？如何对待这些合适的人？成功三定律：雇佣合适的人；使他们觉得开心，这样他们就不想离开；宽松对待他们谁是合适的人？因为人们一般来说都不会工作很长时间，因此不太可能从根本上改变一个人——如果一个人开始就不合适，那么可以肯定，他可能从来不会适合于那个职位。这里的合适更可能是个性上的因素，而非知识性的因素。在招人时候一个不好的倾向是，雇佣那些听起来、思考起来跟其公司他人差不多的人——这是一种有风险的倾向，担不是绝对错误的倾向。完全的一竿子打死，不尊重个体的行为，会很大的降低公司员工的活力。此外，在雇人的时候不要仅仅提问一些纸面上的问题，而应该让他实际进行操作，或给你看他以往工作中实际操作的样品。对雇员应该长期的进行评估，不仅是技能上的，也应该是“直觉”上的——他是否适合管理岗位的工作上整体性思考、启发式判断以及建立在经验上的直觉？能力倾向测试可能是个方式，但决不能把这种测试绝对化。如何让员工尽快的融入群体？工作试讲。新雇佣一个人的成本是多高呢？大约是3-5个月工资。如何降低员工流动率？基本原则是让他们高兴。 有种做法是较快的提升他们，然而，这有可能不是一种健康的做法——导致公司管理人员多而实际工作人员少，管理者知识面狭窄，因此，提升这种做法是不可取的。下面从分析人员流动的原因着手分析。三个原因：混日子的思想，被任意支配的感觉，忠诚可笑的意识。根本思想是，若员工感受不到企业对他们的尊重，那么可以肯定的是他们总是想走的。一个极端的例子是不顾员工感受的搬迁。因此要培养员工留在公司的意识——从根本上关心他们——建立社区，培训，再次培训。让员工感受到公司对他们的投入。不要让企业制度墨守成规，让每个人头上都有一堆的规章制度限制其行为——完整的规则似乎就代表着低效。让员工尝试新的东西（霍桑效应），尝试在每个新的项目中都加入新的元素。====第四篇 如何提高团队生产力？几乎所有的软功书都告诉我们，开发团队由于交流的原因，整体的开发效率低于个体——团队越大，效率越低。如何提高团队效率绝对是所有项目经理一直该思考的问题。交流的确会话费很多时间，但是交流却是非常令人印象深刻的经历！我一些同学拒绝了单独开发的工作，因为在一个团队中工作，更有成就感、更让人得到满足。如何让整体工作效率大于部分的总和呢？首先，要让团队成员紧密结合在一起。第一，要有共同的目标理念（参考德鲁克的企业理念章节）；第二，团结的团队的标志就是低流动率——培养团队的个性和精英意识，让团队成员的名字与产品绑定在一起；第三 不要害怕私党，经理们要融入团队。避免黑衣团队——这是一群对测试带有恶意的人群。那么如何提高团队成员的胶东程度呢？一般来说，没有绝对的好办法，但是却有一些办法彻底的毁坏团队胶冻：1 防范性管理 --- 对自己的员工不信任2 官僚 --- 让员工花太多时间在不动脑筋的文档性工作上 3 物理上隔离 --- 导致他们无法自由的交流 4 时间分割 --- 让员工在多个项目间切换4 产品质量要求降低 --- 破环团队的成就感 5 虚张声势的最后期限 ---一个提高团队协作性的诀窍是：让大家自由自在的进行一项协作完成的活动，比如晚餐，聚会等等，提高每个人的参与程度。让团队成员感受不到他们正在被管理======第五章 如何让员工工作得开心？混乱？还是完全的秩序？ --- 事情完全被理清的时候，也就是开发人员丧失乐趣的时候。因此 在一定程度上 要允许甚至是引进一些噪音，以下是几个策略：前导项目 尝试未经证明的新技术 --- 可能会引入一些成本，但同时能激发人的兴趣；但是 同时要注意 不要尝试多于1个的新技术 这里还没研究清楚演习 雇员随时间流逝技能增长的程度；选择1-2人月的工作，4人团队，用周末进行开发头脑风暴 尽可能多的为ideas的数量，而不是质量奋斗；不对idea进行评估；尝试一些诱导策略外出旅游 参加会议等

关于人的软件开发

这本书翻译的不太好，看的也很快，有些不通的就让它过去了。这是本关于软件工程中的人的一本书。人是核心，无论是分析者，开发者，还是使用者。作者大量的从心理学以及社会学的观点来看待软件公司以及软件开发项目组，收获很大。往往我视为亘古不变真理的内容经常是存在大量问题的。比如，我从来没有注意过，总体规划是极权主义的一个表现，读了这么多年的书，才发现读过很多违反人性规律的书。心理学以及哲学，是一个人修养形成的基础。亚里士多德的《政治学》空了读一读。他把五种相互联系的，一起组成哲学的贵族科学归纳为政治学。形而上学（研究存在，宇宙本质及其所有内容），逻辑学（认知事情的方法，认知基础上得到的结论，演绎和推理中一些可感知的规则），伦理学（关于人的事情），政治（如何在逻辑上把伦理学延伸到更大的群体上，创造和管理此类群体的科学），美学（形而上学的现实性的符号和形象的欣赏，有关伦理的相互作用和政治上的和谐）。除此之外，重启思维的几个方式：类推思考，颠倒，沉浸。也是值得注意的。