当前位置: 首页 > news >正文

《人件》阅读笔记

在2024年的冬天,我读完了《人月神话》这一软工领域的巨著,但是《人月神话》更偏向于软件过程,以布鲁克斯在IBM 360项目中的经历为主,从人月、队伍组成、管理模式、交流、实践、做减法、文档、工具、测试等各个方面阐述作者对整个过程中每个部分是否能提高开发效率,软件开发成功率进行论述,最后得出“没有银弹”能解决软件本身的根本性困难

但是《人员神话》中对人本身的论述是较为缺乏的,因此笔者看向了这本大名鼎鼎的《人件》

一、管理人力资源

我们一起来探索一种迥然不同的思考人及管理人的办法。这种办法考虑的是怎样去适应人的“非模块化”特征。

技术决定成败?以笔者的经历,在我见过的一部分项目中,决定这个项目是否成功的关键因素往往不是技术本身,因为技术大多就是一个“重复发明轮子”的过程,我们称自己的工作是赛博搬砖,从官方文档或者别人的经验贴亦或是开源项目中将别人的代码抄过来从而满足自己的业务需要,一个没有技术创新的项目正在滑向失败的深渊,那么使项目遭遇灭顶之灾一定是技术之外因素造成的

人件中作者经过十年的调研统计了500多个项目得出项目出现的问题:项目取消、终止、延迟或者交付产品从未被使用

导致这些的问题原因无非是产品交付的慢了、交付错了(需求问题)

随着项目越大,项目中部门越多,人员也就越多,部门与部门之间,人与人之间的沟通之间存在问题。

我们以谈恋爱举例,谈恋爱失败的原因会是仅仅因为没有钱导致的吗,我认为也不是,爱情的根源是人,人之外的因素会对爱情造成一部分响应,但是其根本原因还是人与人之间的问题

1.1 “政治”游戏

我经常喜欢说我很喜欢两个群体,一个是残疾人群体,一个是程序员群体(笔者没有对其他任何群体带有歧视)。因为这两个群体十分的纯粹,程序员对于技术之间的讨论是十分热爱的,创造性工作带来的满足感和成就感是其他活动或者娱乐所不能比拟的,但是与客户,与公司其他部门人员、与上级之间的交互不是技术难题,而是社会学问题

对于管理者来说,如果总是将对技术的担心看的更重,甚至越俎代庖将时间花在亲自解决技术难题时,这个管理者一定不是合格的管理者,我很喜欢我的第一个项目的项目经理,也是我的老师–胡老师。我的老师给我们整个团队充足的信任(即使当时我们还是刚从知识课程走出的小白),即使遇到技术上的困难,胡老师也是通过引导的方式来对进行帮助。

在《人月神话》焦油坑一章中指出,软件开发的乐趣之一就是亲自解决遇到的困难的成就感,如果管理者剥夺开发者的乐趣,寻找并不存在的“技术银弹”,将最重要的与人相关的要素放在最低优先级,那么在这场“政治”游戏中就很难成功

1.2 高科技的幻觉

在这里我想提出一个问题,我们开发者是高科技人才吗?

我的回答是我们不属于高科技人才,我们做的仅仅是高科技的应用,就像是几十年前智能手机刚刚出的时候,第一批会使用智能手机的人或许很厉害,但是会使用不代表会研发,而随着时代的发展,智能手机已经普及到几乎人手一台。

而现在AI大模型的发展也是如此,我们使用大模型写文章,写代码,看似是与高科技靠近,但实际上也只是调接口,应用AI罢了。有人会说,在AI的冲击下,软件行业会最先死去。但这种说法我并不完全认可,十年间互联网风口期软件行业高薪的辉煌并不代表这就是互联网行业的常态,现在行业平均薪资的下降也是一种恢复常态的标志。

一个培训班半年毕业的java程序员就可以入职互联网行业从而实现“月入过万”的辉煌时代已经过去了,现在AI时代要做的就是学习AI,使用AI。

刚刚跑题了,话说话来,在软件项目开发中,大多数人从事的是要与人交流的职业,我们的失败往往是与人的互动性的缺失。我们习惯专注于工作中的技术问题,是因为它足够简单,比如安装一块硬盘,安装一款软件,比寻思小张为什么整天忧郁更加简单。

1.3 标准化管理

在快餐行业标准化流程,把工人看做机器上可随意替换的零件,让整个流程趋向稳定是很常见的,但是在智力型的软件领域,这种风格与开发工作水火不容

对于脑力劳动者来说,工作偶尔出错再自然不过,对于脑力劳动者,往往把自己对问题的思考是否正确,是否被别人认可看的比一些物质满足更重要,我们都听说过Linus 和 Tanenbaum 对操作系统微内核和宏内核之间的讨论,二人都认为自己的观点更适用于当前的操作系统,但在讨论以外Linus 和 Tanenbaum仍保持着良好的关系。

笔者想通过这个例子表达,对于脑力工作者,标准化的管理会限制思维限制创造性,对于错误本身也不应过于指责以至于整个团队对出现失误持有戒心,针对天生容易出现错误的设计,可以考虑彻底抛弃而不是去修复,或者对于不能抛弃的设计,也应该通过MVP原则去迭代而非一次性实现一种完美的设计

1.4 傻瓜式管理

管理者负责全盘思考,他的手下照章办事,即使向人们施压可以增加短期产出,长远来看还是无效的。把人当做机器上的零件,一批坏了换另一批,这种傻瓜式的管理模式在脑力工作中是必然走向失败的,软件行业中大部分人都是热爱他们的工作的,没必要用这种傻瓜式“踢屁股”的方式促使大家工作,大家真正需要的是提供更多的动力,而非强制性管理。

1.5 人力商店

太多的管理者认为工作人员展现其个性是一种威胁,但公司是讲文化的,个人也是要讲文化的,个人文化和公司文化不相融一定会出现矛盾,表现出个人的个性化。

书中有这么一个案例,某位老板有一个富有才华的员工常年在外地到访客户现场,花销自然不少,但是对他的报销的分析显示他在食物上的花销远远超过了其他出差人员,于是这位老板给这位员工打上“食物犯罪”的标签,但这位员工实际上花费并没有超过预算,他在其他方面节省了。

对于崇拜生产世界管理风格的管理员来说,员工的个性是一种持续的困扰,但是前文也提到了,不应该把人看作是模块化特征,不能以黑盒的角度看待人本身,人性化的管理应该是使人的这种独特性和项目团队产生化学反应,是团队充满活力和高效的源泉。

1.6 稳定的项目濒临死亡

项目的生命周期的最终目标就是结束自己,项目唯一的稳定期就是将死之时。一个在开发期间和维护期间的项目是不可能做到稳定的,这是由软件的根本性困难所决定的(《人月神话》中没有银弹一章的观点),那么既然项目只有在死亡的时候才是稳定的,我们在开发和维护过程中对于工作人员使用的却是稳定化的评估方法,比如这个员工写了多少代码,写了多少文档等等,而非是对该员工对项目带来的价值

举个不恰当的例子,如果团队中招募了一个十分漂亮,性格温柔的女同事,即使开发能力还不够成熟,但是和我进行双人编程的过程中能给我带来更多创作的动力,从而提高生产效率,那么这位同事带来的价值是否能按照她写了多少代码完成了多少功能来评估呢?

1.7 磨刀不误砍柴工

如果分配给你一个任务,你会花多少时间来真正实施这项任务,不可能百分之百,实施之前肯定需要一些头脑风暴、调研新方法、规避一些子任务的方法或者进行培训

我们花了太长时间去做事,却没有花足够的时间去考虑“这件事到底该不该做”,对于管理者来说,如果用稳定的管理模式驱动员工,让员工把大多时间都投入到做事情上,没有人去考虑这件事本事是否值得去做,团队会变得越来越不稳定。

比如将太多不值得做的任务分给你的员工,你的员工生产力不足,那么最先想到的解决办法是什么,招募新员工吗,但是我们读过《人月神话》,都知道在一个已经进度落后的项目中添加新的人员,项目依然会落后,对新员工的培训依然需要花费时间,花费成本。

思考方法,学习如何多花时间在思考上才是更重要的,项目的投入越夸张,成员越应该学习如何更好地协作,而非一味的苦干实施。

我最喜欢的书中一句话是:项目越是需要在一个无法完成的固定时间交付,项目团队越不能缺乏频繁的头脑风暴,或者项目组聚餐之类的活动来帮助团队形成一个统一的整体

最后还是一句话,磨刀不误砍柴工,以笔者自身经历举例,我会把一部分花费在买工作的设备上,买显示屏,好一些的键盘和鼠标。这些花费对我来说是非常值得的,因为他带来的反馈感会提高我的生产效率

1.8 西班牙理论和英国理论

西班牙理论认为世界上的价值总量是定额的,因为财富积累的道路就是学会从大地或者别人的背上去攫取。

英国理论认为价值通过智慧和科技创造出来的

西班牙的价值理论在很多管理者身上都有看到,无论你的员工工作多久,他们都按照每周5*8小时分配,而不是员工现实工作的80乃至90小时,虽然我们知道这更像是一种欺诈,通过各种方式连哄带骗地延长员工的工作时间,告诉员工DDL的重要性,但不可否认的是大部分管理者甚至个人都是西班牙理论的实践者,通过花费员工更多的时间降低产品价格而非通过创新提高生产效率

有一个很有意思的现象是如果一个问题本身并不复杂和困难,比如对某个系统进行改错和调优,可能对于一个有经验的人员来说花半小时就能搞定,但是甲方可能会认为,我花了这么多钱这么快就容易地解决了,是不是太吃亏了;相反,如果你拖了一两天再告诉甲方,这个东西如何如何的复杂,排查多少问题后才定位到是哪里的错误,甲方可能就会认为得到小便宜了,这钱花的真值啊

管理者使用各种手段让员工接收那些根本没有希望达到的进度安排,让他们因为内疚而不得不牺牲自己的其他时间来工作,对于这个问题的讨论笔者认为应该将生活和工作学习时间的投入能够恰当,即不至于牺牲所有时间在学习和工作上依然愧疚,也不至于完全躺平去追求自己喜欢的生活

1.9 平衡工作与家庭

书中对这一段的论述对我十分有感触

虽然你的员工在办公室里得到的信息是“工作时间长点、强度大点”,但他们在家里得到的信息却迥然不同。家里传递着信息:“生命正在流逝。衣柜里面堆着你的脏衣服,你的孩子们得不到拥抱,你的配偶正在寻找别的地方。那种被称为生命的旋转木马只有一圈,中奖的机会只有一次。如果你把你的生活都消耗在C++上…"

我有一个好朋友的父母因为事业长期在外地工作,从而导致和父母关系的疏远,和父母产生遥远的距离,这份与亲人渐行渐远的工作是值得的吗,或者换个角度,当你在公司疯狂加班,甚至晚上都不得不回家的时候,你的亲人对你的担心会让你考虑,你的这份努力或者是被管理者“欺诈”是值得的吗

1.10 不存在加班的谎言

加班所花费的时间却需要花费“地下时间”来弥补自己的生活,计算投入与产出,每加班一个小时,就需要一个或更多小时的“地下时间”来弥补。

比如我在田界智航项目组中,前期疯狂加班花费自己娱乐和休息时间完成工作,但是后面在工作中尽可能多的摸鱼来弥补曾经的损失,对于脑力工作者来说,没有人能真正工作超过40小时,至少不可能持续,加班就像冲刺,若一开始就冲刺,那就是纯粹的浪费时间。

在敏捷开发中,可以将工作让燃尽图一样进行下去,应该以一个稳定的状态去交付,过快以及过慢都应该进行调整。

1.11 工作狂

工作狂是一种病,但不像酗酒那样只影响不幸的少数人,工作狂就像常患的感冒,每个人都可能染上,而一旦工作狂认识到自己为了一些不那么重要的工作而牺牲了生命中更重要的价值,如家庭,爱情,青春等,这种打击会促使他们一旦这个项目结束后会永远离开这个团队。

所以无论如何加班,都不能让大家以牺牲个人生活为代价,失去好的员工绝对不划算。

1.12 赢得战斗,输掉战争

在《人月神话》中我们讨论过,招募新员工对于员工培训所花费的时间和经济成本是很大的,如果因为采用加压、流程机械化、牺牲质量或者标准化这些方式来提高开发效率从而导致“员工流失”是很不值得的。

这里还有一个有趣的故事,是通过降低别人的预期来保证别人的满意程度(不过是个反例)

在我早期的一个咨询项目中,项目运行平稳,项目经理知道她能够按时交付产品。她被叫到管理委员会(management committee)做进度报告。她说她可以保证产品在 3 月 1 日的最后期限完成,完全准时地遵循最初的估算。上层管理者仔细地讨论了这意料之外的好消息,第二天又把她叫来。他们解释道:因为她能够在 3 月 1 日准时交付,所以最终期限被提前到 1 月 15 日。

压力不会让工作做的更好,只会让工作做的更快

这句话我是认可的,但是对于不同时期的人来说压力不一定是一种坏事,对于精神麻木,没有自控力的人,施加一定的压力会促进他们的工作,因为并不是所有人都能够很好地控制自己,对工作一直保持热爱。

1.13 质量–如果时间允许

人们通常倾向于将我们的自信与生产出的产品质量紧紧关联,如果因为某些原因,从而不得不牺牲产品质量,生产出大量质量马虎的产品,从而使得带来的满足感很小,你的员工可能会挑起反对你的情绪。

管理者设定的不可达到的期限威胁着产品的质量,当员工处于极度的压力之下时,质量就开始被牺牲了。

也许管理者会说:“我们一些同志会为了质量在一个任务上无休无止,但市场才不管你什么质量–昨天就赶着要这个产品了,即使质量粗糙也行”,这句话对市场的判断是没错的,但是如果不能在上市之后将缺失的质量弥补回来,最后一定还是错误的。

客户想象的产品质量往往比制造者认为的要低,这是一个天然的冲突,降低质量可能会让一些人不再购买,即使通过降低成本提高单个产品的利润也无法弥补损失的市场占有率。

1.14 质量免费

质量免费是Philip Crosby在《质量免费》一文中提出的,但是宣扬的并不是质量免费,因为质量是无价的,其核心观点是只有愿为质量倾其所有的人,质量才是免费的。

一个组织如果为了质量一毛不拔,那么收获的质量也是一文不值的,提升质量是需要花费成本的,提高质量不代表牺牲生产效率,提高效率也不一定意味着生产效率的下降。

举个例子,假如客户要修改一个业务逻辑,在实现上可能就是修改一个SQL语句,但是依然要经过评审测试才能完成修改,如果为了追求效率绕过这些环节导致最终数据库挂了,最终的效率不见得是提高了

1.15 帕金森定律

帕金森定律是一位喜剧作家提出的,但并没有收集数据没有提供统计推论规则,这个定律被大家接受仅仅是因为十分有趣

帕金森定律认为工作会自动膨胀,占满一个人的所有时间

看到这里大家可能会想到,在敏捷开发中一次次冲刺最后都变成了加班,是不是正好论证了帕金森还是有一些道理的,一个平庸的管理者会招募很多比自己强的员工吗,我想是不会的,因为他们害怕员工会取代自己,那么平庸的管理者招募的会是更多的平庸的员工,恶性循环往复,最终整个团队都会平庸下去

帕金森定律所说的是官僚主义中存在的一些问题,在软件行业中,给一个能力欠佳(如快速培训出来)的人施加压力,他依然无法完成自己的工作。更合适的应该是调换工作或者跳槽到其他的公司

在这一小节中,我们讨论的是团体整体的问题,讨论了一种帕金森团队的组成,那么有什么办法能够促进团队的协调。

书中通过比较各种估算方法给产能带来的影响,得出的结论是能力越强的系统分析师给出的估算更为合理,因为他们既了解具体的细节,又不会陷入自然的乐观估计中。

不准确的估算,会消磨构建者的精力,通过加班来完成只会让项目团队变得更为烦躁和暴躁。

如果惩罚比较少见,而时间点也能够掌握得恰到好处,惩罚就可能起作用。若经常需要施以惩罚,就说明你自身是有问题的

1.16 软件行业的七宗罪

有不少对提高产能的说法,但是实际上就是虚假宣传,因为所有的简单手段在之前就已经被尝试和实施过,根本没有这种灵丹妙药

  • 有一个你不知道的新窍门可以让产能飙升

    错误的,这只是一种纯粹的心理上的恐吓战术,让你觉得这一神奇的创新不容错过

  • 其他管理者正在收获 100%、200%乃至更多的增长

    错误的,软件生命周期不仅仅有编码和测试,即使去掉某些环节也不能做到100%的增长

  • 技术日新月异,你已经过时了

    错误的,软件开发本身就不是高科技行业,技术的提升不会带来生死的决定,还要考虑项目成员对技术的偏好和学习成本

  • 改变程序语言能带来巨大提升

    错误的,编码本身在整个生命周期中占比并非最重的,而且编程语言也可能只是在编码阶段中能带来一点提升

  • 因为backlog需要让产能翻倍

    错误的,一个经济上的失败之作,项目根本不应该存在库存里

  • 你自动化了所有其他东西就不能自动化掉你的你的软件开发人员吗

    错误的,软件开发人员面对的最主要的问题是与人沟通,把用户的需求改变为正式的程序,这一步是无法自动化的

  • 你的员工在巨大的压力下会工作的更好

    错误的,员工更喜欢减少压力

管理者的作用不是让大家去工作,而是创造环境,让大家可以顺利开展工作

二、办公环境

电话铃不停的响,打印机维修人员顺道过来聊聊天,复印机不工作了,人事部不停催促更新的能力调查表,下午3点之前就要提交时间表…然后一天就这样过去了。

2.1 家具警察

人们怎么使用空间、需要的桌子空间多大、花多少小时独立工作、又花多少时间跟别人一起工作。是否调查封闭空间(一人、两人、三人办公室)和开放空间的优势,在成本开销和保护隐私,营造安静环境之间做平衡。

但是大多数管理公司的人不会花太多时间来考虑上述问题,因为他们不会置身于这样糟糕的环境去开展工作,不仅如此,管理者甚至会组建家具警察–采取的方案与你做的几乎背道而驰。

家具警察喜欢的是整齐划一的环境,但是我们脑力工作者都喜欢在自己办公桌上放一些个性化的东西,比如一些手办,不同的键盘,照片等等。

2.2 统一的塑料地下室

想象一下,大家做高铁都喜欢靠过道的位置,但是无法做到让所有人都能够选择靠过道的位置,如果一个公司的办公环境有靠窗的,有四面通透的,有一面靠墙的,那么公司为了不因为无法顾此失彼而让部门人员不满意,那么公司可以选择统一所有位置,让所有人都不满意,如下图

在这里插入图片描述

从家具警察的角度看,这种地下室环境是他们的最爱,因为这样更容易产生统一的规划,但是人们都不希望在一个完全整齐划一的环境中工作,都希望把自己的地方打造得带有自己的风格以方便自己的工作。

大部门脑力工作者的环境总是嘈杂没有隐私的,交谈声、键盘声、电脑风扇声。

但在国内,对工作环境的要求并不高,一部分原因我觉得可能是在家的环境还比不上公司的环境,也就是在家没有一个够大的桌子,安静的屋子,面对家人的打扰可能会躲去卫生间开会办公等等,因此没有吃过细糠就不会提出更好的要求。

家具警察的思维是用最小的成本达成最好的封闭性,但对于大多数处于生存中的公司改善工作环境不在他们的考虑范围内。

2.3 朝九晚五在这里啥也完成不了

加班在软件行业里面司空见惯,就如同所有人员都形成了一种共识“加班就是命中注定”,思想密集型岗位为什么需要投入如此多的额外时间呢,明明业内都知道对于思想密集型岗位来说,加班增加不了工作产出,他只不过提升了平均质量而已。

你常常听到这样的话

“在清晨大家到达之前,我做事的效率最高”

“只要一个晚上,我就能做两三个大白天的事情”

“办公室一天到晚像个动物园,下午六点,慢慢安静下来了,这时你才可以真正开始完成点事情呢”

2.4 编码战争

书中通过一项编码游戏,在编码竞赛开始之前先收集了来自不同公司2位参赛人员的调查问卷,然后让同一公司参赛人员都做同样的工作,设计、编码和测试一个满足固定需求的中等规模的程序。

这场编码战争的第一个结果证明了参赛者个体的差异

在这里插入图片描述

  • 能力最强的人较之最差的产出比大概是 10 : 1。
  • 能力最强的人比居间的产出高 2.5 倍左右。
  • 能力靠前一半的人较之后一半的产出比大于 2 : 1。

从这场竞赛结果分析中得出生产效率与以下因素基本没有关系。

  • 语言

  • 经验年限

  • 缺陷个数

  • 薪酬

    前一半的薪资比后一半的薪资高出不到百分之十,但他们产出效率却高出一倍。

那么与生产效率有正向关联的是,你和谁搭档关系很大,平均一对竞赛搭档在表现上相差21%。

因为他们在同样的公司环境以及公司文化下工作,两个来自同一组织的人表现会趋向一致,这说明效率最高的人聚集在一些组织中,效率低的人会聚集在另一些组织中。

一些公司比另外一些还要糟糕,他们的公司环境及文化不但不能吸引或留住好的人才,更是让真正的人才无法在这种环境下有效工作。

2.5 工作环境的影响

工作环境的质量直接关系着开发者的效率,在上一节的编码战争开始之前先收集了调查问卷,调查他们要完成任务的工作地的物理环境,其中包含客观数据(如空间的大小和层高等等)以及主观数据(比如“你觉得你的工作环境让你感觉很舒适吗”),然后将他们的答案和练习中的表现相关联起来。

结果显示练习最快和最有效率的前四分之一的工作环境更加安静,更具有私密性,更不受打扰。

我们就拿高中教室举例,上过高中的都见过这样一种现象,每一层与每一层的气氛截然不同,清北班所在的楼层比普通班所在的楼层更加安静,甚至有些压抑。好的环境对效率的影响很大,长远来看,生活在更加安静、宽敞和注重隐私的环境无论对提升效率还是留住和吸引人才都是有很大帮助的。

2.6 在空间上省钱

对于公司而言,在空间上省钱是一个普遍的现象,先不聊公司,我们把视角转向IT工作者个人上,在电脑等工作设备上省钱也是一种很普遍的现象,一台笔记本和自带的键盘触摸板,其开发效率是远远低于多个屏幕、有前进后退键的鼠标的工作者的效率的。有人可能会说,笔记本电脑自带的键盘不也一样能用吗,为什么还有再买一个键盘,笔者的回答是,一款适合自己的键盘带来的反馈更加令人预约,可以减轻长时间工作导致的热情流失。

我们把视角再拉回公司,现在很多公司面临的问题是专用空间较少,会议室很少,纠其原因,其一是房价确实很贵,其二是每个人都希望在一个能集中精力,不会被打扰的环境中完成脑力型工作。

“工作环境中节省一分钱就是在运营中挣得一分钱”,得出如此结论的人,没有从收益分析中理解收益,他们只知道节流,却不知道该怎么开源。但是对于公司来说,节流比开源要容易,通过缩减工作环境的成本降低开支,这很有吸引力,但是缩减的开支与失去效率的风险放到一起比较。

为一位开发人员在环境上的整个投入只是他薪酬的很少一部分,大致是在6%~16%之间,也就是说在工作环境及附属设施上花费一元钱,对应于直接支付给工作者的十五元钱,就像在节假日公司给员工发小礼品,可能其成本比直接发奖金要低很多,但是其附带人文关怀的价值。

富有远见的管理者是不会罔顾员工工作效率是否受到影响,就将大家搬到更便宜,更吵闹或者更拥挤的隔间里。

2.7 席卷大地的瘟疫

对环境不负责任、漠不关心的态度在我们这个时代随处可见,开放式设计的工位就像一场瘟疫席卷大地一般扩散,我们不妨思考,我们做敏捷,就一定要把环境敞开吗,我认为真正的敏捷不是严格仿照敏捷所推荐的模式,而是根据不同的团队不同的阶段灵活运用。

开放式环境有助于沟通是毋庸置疑的,但是沟通效率不代表综合效率的提高,环境的设计应该考虑的是一个个活生生的人在这种环境中工作的因素。

2.8 让我们暂停抨击,来谈几点事实

IBM 抛开了所有现行的行业标准,仔细调研了未来将在那里工作的人们的工作习惯,得出了最小标准的安置计划。但是笔者认为这个仅仅看一看就行,可以以这个为目标,但是对于不同情况的公司还是要考虑实际的经济因素

IBM得出了最小标准的安置计划是

  • 每人100平方英尺的独立空间
  • 每人30平方英尺的工作平面
  • 封闭的办公室或者 6 尺高的隔断来隔离噪声(他们的设计结果是,一半的专业人士工作在 1 或 2 人的办公室里)

节省成本而造成办公环境达不到最低标准将会导致工作效率降低,从而抵消掉节省的那点成本。IBM 最后遵循了研究的建议,为员工建造了这样的工作环境

2.9 工作环境质量和产品质量

提供狭小和嘈杂工作环境的公司相信这些都不是问题。当员工们诉求更大更私密的空间时,他们会对这些针对噪声的抱怨充耳不闻。算了吧,一点点噪声能带来什么大不同吗?说不定,这还可以帮助大家清醒清醒呢。

在2.4章节的编码战争中,赛前的报告提及自己工作环境较为安静的人,要比另一类人多1/3的机会完成交付,并且没有缺陷。

就像降噪耳机的流行也是因为在嘈杂的环境中是难以专注完成创造型工作的,但是不同的人对噪声的容忍度是不同的,在编码战争中没有做任何关于噪声层级的客观度量,只是问他们是否觉得噪声层级可接受。所以,并不能区分哪些人是真正在一个安静环境里工作,哪些人是习惯了嘈杂环境(不被影响)。但当一名员工抱怨噪声太大时,他就是在告诉你他不属于上述任何一种情况。他同时在告诉你,他可能更容易犯错。当然,你可以不顾危险地忽略这样的信息。

2.10 诺贝尔奖级别的发现

我们开始注意人员密度和人均独立空间这两者之间不同寻常的关系。当一边升高时,另一边似乎会下降!也就是说随着公司人员的增多,人均空间是成反比地降低的,这并不难以理解。

究其原因,一个公司在环境的配置上是很难进行预料的,人员的招募并不是一个连续的过程,在不同的阶段所需要的人力资源是不同的,人员的入职和离职也是难以估计的

在这里插入图片描述

而随着人均空间的减少,噪声所带来的影响只会增大

为了解决这个问题,大家往往都会找地方躲起来,躲在会议室,躲在图书馆或者咖啡厅。甚至往往喜欢把工作留到晚上去做。

我在布朗大学学习的几年,要应对论文截稿期集体到期的疯狂时间,一个有效办法就是找一块安静的地方工作。在布朗大学,图书馆形成了一条不成文的阅览室条例:唯一可接受的干扰是火警,而且必须是真正的火警。我们慢慢成了善于寻觅那些不为人知的小阅览室的专家。生物图书馆五楼的阅览室是我的最爱,我的一位朋友甚至找到了拉丁图书馆下面的地窖 —— 真的是地窖,还伴随着资助这一建筑的那位女士的遗骸。那里非常冷清,全是冷冰冰的大理石。我朋友说那里真的很安静,非常安静。 --TRL

2.11 生产效率度量和不明飞行物

我们为什么不能直接度量在好与坏的工作环境下的生产效率,从而找到环境和工作效率之间的关系呢?这种方法对流水线可能适用,但如果我们要度量的工作更加偏重于脑力劳动,就不那么明显了。对脑力劳动者生产效率进行的度量已经背上了软科学的名声。在一些人的脑子里,这仅仅比研究不明飞行物好一点儿。

软件开发工作的是由一个一个人的脑力工作所完成的,但是人的好坏是不能简单的进行度量的

设计一项实验来测试工作环境对生产效率的影响足够简单:
● 度量在新工作环境中完成的工作总量。
● 度量工作带来的花销。
● 比较在新旧环境中完成工作的总量和工作花销。

设计很简单,但是实施起来却很困难,比如怎么计算一个市场调查、一个新电路设计或者贷款新政策设计的工作总量?

换个例子,比如度量一个人的代码指标用的是他所写代码的行数,那么我把一个简单的代码写的冗余一点,多写一些注释,不用那些封装好的方法自己手动实现初始化等等。

在一个组织中,可能提供了花费在一个问题上的总小时数统计,却没有包含对其中有效小时数的统计,所以笔者认为在敏捷开发对用户故事的估算时间按照工作点更加合理而非工作时间,工作点是对问题规模的估计而非所有人都是需要这些时间完成工作点的任务。

2.12 吉尔布定律

有一年,我在伦敦软件工程国际会议上和汤姆・吉尔布聊了一下午,他是《软件度量》和其他十几篇关于开发流程度量论文的作者。我发现只要说有些事情 “不可度量”,就很容易让他激动起来。这种想法对他就是一种冒犯。让我印象深刻的是他关于度量基础真理的描述。在那时看来,这一想法如此明智而令人鼓舞。我甚至逐字逐句地将它们抄到我的日记中,并命名为吉尔布定律。

你想要量化的任何东西都能够以某种程度度量,至少聊胜于无。

吉尔布定律并没有保证度量免费或便宜,而且可能度量也不是完全准确 —— 但总比没有度量好。 --TDM

在我们最了解的软件制造业,有很多有效的生产效率度量体系。甚至还有很多服务能够到现场评估你的生产效率,并告诉你在同行业里处于什么位置。如果一个组织不能评估自己的生产效率,只能说还没有努力尝试。

2.13 但是,不知你是否接受

假设现在就有一个简单且验证充分的生产效率度量工具,而且已被大家用到日常工作中。如果度量者进来告诉你,你的团队的生产效率在同行业中名列前 5%,你一定非常开心。你的脸上堆满了神秘的笑容,来回在走廊上徘徊,心里温柔地想着你的员工:“我原来就觉得大家很不错,这条消息实在太棒了。”

哇,糟糕。度量者一会儿又跑了回来,告诉你他们把图拿反了,那是一个错误的结果,其实你的团队是行业的最后 5%。现在,你这一整天都给毁了。

度量指标最看重的是你在同行中的排名,就像是我们去看奥运会,你可能并不在乎运动员跑了多少秒,而只是在乎ta是否拿到了冠军,在软件行业也是如此,你不可能忽略你当前所处的位置。

如果你不知道,你就不可能做出任何改变,若是只有市场了解,自然会有一些让你不舒服的外力来纠正存在的问题。

2.14 闭上眼睛去度量

为了能够让度量这个理念发挥应有的潜力,管理者必须足够主动和安全地把自己从这个圈子里摘出去。换句话说,就是度量的结果不影响KPI考核,个人的数据不会传递到管理层书里,而且组织中每个人都心知肚明,收集的个人数据只用于个人提升。度量体系就是自我评估的一个练习,只有处理过的平均值才会交给老板看。

度量一定是在无感知的情况下完成的,如果你知道度量的方式就会无意的去迎合这种度量,要做到精准度量需要个人的积极配合并且有意愿的合作,如果数据的保密性被破坏,如果数据被用来针对哪怕一个个体,整个数据收集系统就会即刻停滞。

2.15 大脑时间和身体时间

以下表格是《人件》作者收集到的开发人员典型的一天中是如何分配时间的

工作状态时间分配比例(%)
独自工作30
和别人一起合作50
和两个或更多的人合作20

从噪声的角度来看,该表的特征显而易见:在 30% 的时间,人们对噪声敏感,而在其余时间,他们又是噪声的制作者。

在同一时间内,有些人可能处在和别人交流的过程中,但有些人可能处在独自工作的过程中,从而带来了模式上的冲突。

在单一思考的工作时间里,理想情况下人们处于心理学家称为“流”的状态中,流是一种深度的近乎于冥想的融入情况。在此状态下,人们几乎意识不到时间的流逝。

并非所有工作都需要进入流的状态才能变得高产,但对于从事工程、设计、开发、写作或类似的工作,流是必需的。这些任务都需要精神高度集中,只有处在流的状态下,你才能够很好地工作。

不幸的是,你无法像开关那样随时启动流。你需要一个缓慢的过程来进入状态,15 分钟或更长时间的集中才能把自己锁定在流里面。在这个引入过程中,你对噪声和干扰是非常敏感的。在一个毁灭性的环境,可能让你很难甚至不可能进入流的状态。

一旦锁定在流里,状态可能被一个针对你的干扰(比如电话)或持续的噪声破坏,每次被破坏后,就需要再一个过程使你回到流的状态。

假设打来的电话平均时间为 5 分钟,你重新引入的时间为 15 分钟,那么一个电话在流时间(工作时间)上的损失就是 20 分钟。一打电话就会浪费掉半天时间,再加上其他的干扰,剩下的半天时间也泡汤了。这就是为什么 “朝九晚五在这里什么也做不了”

通常,现在公司的时间计算系统是传统模式。在这种模式下,完成的工作与花费了多少带薪工作时间成比例。当员工根据这样的体系填写时间表时,他们并不会区分花费在工作上的有效时间和焦躁时间。他们汇报的是身体时间而不是大脑时间。

关于流和引入时间的现象给了我们一个更加真实的方法来分析一项开发工作的时间花销。要计算的不是在岗时间,而是你真正全力发挥开展工作的时间。一个小时的流时间真正有产出,但夹杂在 11 个打断之间的 10 个 6 分钟的工作时段等于什么都完不成。

但是这种度量方式是十分困难的,几乎无法完成。即使可以做到,也不能提交给薪资部门,可能还是需要将出勤时间用于薪资结算。

那么如果想要统计流时间作为度量参数,那么可以用以下公式作为参考
E参数=不被打断的小时数出勤时间的小时数 E参数 = \frac{不被打断的小时数}{出勤时间的小时数} E参数=出勤时间的小时数不被打断的小时数
在 0.10 环境中工作的员工,比起 0.38 环境中的员工需要花 3.8 倍的出勤时间来完成同样的工作。这就是说,在成本削减的环境中,对工作表现的惩罚比节省的环境成本要多得多。

一开始度量 E 参数时,倘若数值在零附近徘徊,我们也不必感到惊讶。人们可能会觉得记录不被打断的工作小时数多么可笑:“在这样疯狂的环境里,还有不被打断的时间吗?” 不要绝望,要记住你不仅仅是在收集数据,你还在帮助改变大家的态度。

当年贝尔实验室的环境和当下流行的办公室规划的区别在于,在那些安静的办公室里,我们还能做些与工作相关的思考。

2.16 电话

想象一下这样一个场景,你正在为了优化某个业务编写相应的算法,这时一个诈骗电话打过来:“喂,哥,我们是游戏公会的,你最近在玩什么游戏吗?”,这通电话不仅打断了你的思路,而且其毫无营养价值的内容更让你愤怒。

电话是一种强打断的方式, 一天接15个电话算不了什么,但如果考虑它带来的重新引入的时间,可能耗费的就是一整天了。当一天就这样结束了,你还在迷惑时间到底花在哪了。

现在放松,想象我们进入了另一个简单点的世界,这个世界电话还没有被发明出来,在那个世界,你写张便签来邀约午餐和会议,从另一个便签得到回复,每个人都需要提前一点进行计划。

当然我们不可能扭转历史,电话已经存在在我们生活中,不可能丢弃。

你经常会因为接电话而打断跟同事和朋友的讨论吗?你当然会。你甚至没有考虑过不去接那个电话。而这样做就违反了公平原则,只是因为持续不断的 BBRRRRIINNNGGGG 声,你就破坏了先来后到的顺序。你对别人这样做,同时别人也这样对待你。对这样的恶习你已经习以为常,毫不在意。

对于非紧急事件的打断,使用电子邮件这种非强制打断的方式会更好,电话与电子邮件之间的主要差别在于电话是打断性质的,而电子邮件不会;邮件的接收者可以在他方便的时候来处理。对于大多数业务交流来说,系统流量的总和可以证明 “在接收者方便时处理” 的优先级排定是可行的。

2.17 不兼容的多任务处理

如果你在做诸如设计这样的思维密集型工作,打断就是生产效率的杀手。你和你的同事一块设计产品,若你同时还要负责该产品的销售与市场支持,你就不得不回应每一通电话。对其他产品的用户支持同样如此。

推而广之,若是要求脑力劳动者进行多任务处理,管理者就需要分析不同任务对流状态的要求。将一个需要流状态的任务和一些经常打断性的工作放在一起只能滋生焦躁。这种做法不可能形成合理的电话道德(“请勿打扰,我正在工作。”)。

任何精密装置都比不上改变观念来得重要。人们必须理解在某些时候不接电话合情合理,管理者也应对此表示理解。这就是脑力劳动者的工作特点:对于花费的时间,质量胜于数量

2.18 门的回归

创造一个合理的工作环境,成败与否可以由一些公认的标志来决定。一个显而易见的成功标志就是门。如果环境有足够多的门,员工就可以有选择地控制噪声和干扰来满足工作的变化。最显而易见的失败标志就是传呼系统。那些习惯通过找人而打断所有人工作的组织,完全展现了对建设有利于开展工作的环境的无知。

但是当员工对环境开始抱怨的时候,下面三条反面论调就会立刻浮出水面

  • 大家都是聪明人,谁会关心办公环境是否够闪亮。那些真在意的不过是在玩推脱的把戏
  • 噪声可能是个问题,但比起清理物理环境,咱们有更便宜的方法来处理。我们搞些轻松的背景音乐来抵消噪声不就得了。
  • 封闭的办公室环境没有活力嘛。我们要让大家有效地互动,这正是大家喜闻乐见的。所以,墙和门的改进方向根本就走错了。

下面对上面三条反面论调进行反驳

闪亮空间

人们对环境的闪亮程度确实并不在意。在一个个调查中,员工都不能有效地选出哪种装饰更合适,比如各种颜色的面板与设备。感觉上,那种让人压抑的四周似乎会影响生产效率,但只要办公室不让人压抑,你就能忽略它们继续完成工作。如果我们追求的工作环境是可以让我们忘我工作,而不在乎周遭的环境,那么任何高端装饰都是浪费。

但是这种想法总是被误解为员工不关心工作环境的任何属性,没人可以在一个充满打断,呼叫,总之就是不断骚扰员工的环境下,还能够听之任之,视而不见。

创意空间

对待员工对噪声的抱怨,你可以治标抑或治本。治本就意味着隔离噪声 —— 用墙和门 —— 这些都要花钱。治标就便宜多了。
播放一些轻音乐或者其他形式的柔和声音,就可以抵消恼人的噪声,而且花销极小。要省钱,还可以通过让人忽略这个问题,例如让大家使用自己的 iPod,戴上耳机来避免噪声。倘若采用了上述任何一种治标手法,可能会带来一种无形的惩罚,从而影响员工表现,他们会失去创造力。

书中做了这样一个实验,将一批人分成两组去两种环境中完成任务,一组是没有音乐的安静环境,一组是有音乐的环境(适应音乐的人进入) ,最终的结果是两个屋子里面完成速度和质量基本上相同,但是待在安静房间中的人更多发现了输入输出的规律。

很多专业工作者的日常任务都是在左脑的处理中心完成的,音乐并不会对这些工作造成影响,因为右脑在倾听音乐,但并非所有工作都在左脑,有时,偶然会有让你突然“啊”的突破,这种突破甚至能让你少做几年的工作。

活力空间

反对封闭办公室,迟早会让人将它看做独立工作的 “无菌空间”。但是,封闭办公室并非就是一个人的办公室,两人、三人或者四人的办公室反而更加合理,最好是按照工作组来划分办公室。两名员工在一起工作的时间如果达到了 50%,那么他们俩就是同一间办公室的自然候选人。

即便是在开放式的办公环境,一起工作的员工也应该将格子间修改为一个共同的小套间。若这种改变可行,大家就会很巧妙地根据工作需要去设计自己的区域:工作区、讨论区和社交区。因为他们工作步调很一致,他们制造噪声影响别人工作的几率,就会比随机选择的邻居少了许多。这种空间具有活力,因为容易互动,也很自然。适当控制这样的空间会获得额外的收益。

只有大家把空间按照适合自己的工作组织好后,他们才能够抛开空间的影响, 完全投入到工作中。

2.19 采取保护措施
  • 什么样的空间最适合你的员工,让他们感觉舒适、高兴同时高效?
  • 什么形式的工作空间能够让员工自身以及对工作感觉良好?

若要弄明白自己需要什么样的环境,就需要找到工作环境的不变特性

有一种建筑的永恒之道

建筑学的理念带来的影响远远不只包括建筑业

想象一下,你的组织要筹建一个新的复杂空间,那么哪里才是你开始的起点?几乎确定无疑,就是制定一个总体计划。

根据《建筑的永恒之道》所言,多数情况下,开始迈出的第一步常常会带来最致命的偏差。按照这种方式,永远不可能创造出活力四射、激情澎湃、和谐蕴藉的环境。总体计划总是梦想着宏伟的工程,钢筋水泥的延伸,通过模块方式不断重复地建造出整齐划一的建筑。于是乎,一个枯燥乏味风格雷同的空间诞生了,它除了能满足某些人的自我野心外,根本不适合人们工作。

对于这样的总计划,亚历山大提出了演进计划(meta - plan)的概念,其哲学是设施能够根据使用者按需演进。

  • 逐渐发展的哲学
  • 一组支配发展的模式或达成共识的设计原则
  • 使用空间者对设计的局部控制

在演进计划下,设施一小步一小步地进化出建筑群园区与社区。遵循共识的原则,它们守护着和谐的愿景,但并不千篇一律,就像成熟的村落一般展现出不断进化的魅力一样。

2.20 模式

《建筑的永恒之道》中的每一个模式都是对成功的空间和内部构造的抽象。书中的核心卷《模式语言》讲到了 253 种模式,并把它们交织为建筑学上的连贯视图。

这其实就和面向对象的23中设计模式是类似的,设计模式是一套被反复使用、多数人知晓、经过分类编目的代码设计经验总结 ,是解决特定问题的通用套路。重点在问题解决方案的一般性、通用性、可复用性,以及如何遵循设计原则优化软件结构、提升可维护性和扩展性。

而具体实现更关注功能实现细节,如变量定义、语句执行顺序、函数调用、异常处理等。

这里推荐另外一本书《图解设计模式》,以后有机会的话笔者也会总结这本书的读书笔记。

下面四个模式直接针对当下机构最糟糕的四种空间设计。

第一个模式:从工具箱里定制工作空间

今天常见的模块化小隔间是各方妥协的经典之作:在没给你任何有意义的隐私的前提下,还让你感觉被隔离开了。对噪声和打扰基本不提供任何保护;事实上,噪声和打扰源源不断地被输送到你的隔间里。你被隔离的原因是在这个独立的空间里只有你一个人(这有点像一个没有马桶的洗手间)。这样的空间让人很难独自工作,并且基本不可能参与那些可能与工作相关的社会活动。

这样的设计模式既没有给个人提供良好的工作空间,也没有给团队提供任何场地。另外一种方式是围绕工作小组来组织空间,每个团队需要公共的和半私人的空间,每个人需要受保护的私人空间。

我们来看一下几种比较合适的设计方案(让员工参与进来一起设计)

在这里插入图片描述

在这里插入图片描述

这种与简单的小隔间不同,这些设施必须能够适应于多种不同的配置。

但是实际上也十分困难,因为并不会有这么大的环境能够拿来做出设计。

第二个模式:窗户

现代办公室政治使得窗户的分配成了地位的差别。参与窗户彩票摇奖的人大多成了失败者。习惯家中窗明几亮的人,无法容忍将自己白天的大部分时间耗费在没有窗户的工作空间中。亚历山大对没有窗户的空间容忍度极低:“没有窗外风景的房子,对于居住在里边的人而言,就像是牢笼。”

造成没有足够窗户问题的直接原因就是长宽比例。假如建筑物设计为狭长的形状,那么不应该有缺少窗户的情况。一个合理的建筑物宽度应该是 30 英尺

在这里插入图片描述

这种设计能保证每个房间都能有窗,但是占地空间成本会大很多,就算为了每位员工能够在更合理的空间工作而花销高点,也是物超所值的,因为总能在其他地方做到节余。

第三个模式:室内和室外空间

狭长的布局同时也能够让我们更容易融合室内和室外空间。如果你在一个拥有室外建筑的地方工作过,就很难想象将你自己限制在室内环境工作。

就比如有室内室外两种环境的咖啡厅,或者有室外平台的公寓酒店。

这里会面临两个选择,一个是环境优美的室外环境但是要以延迟交通时间为代价,另一种是交通时间短但是室外环境一般的公司。

我想大部分还是会选择后者,在阳光明媚的一天里,一些人会在露台上工作,而另外一些会选择花园、树荫或者庭院,这是一种错落美。这种工作环境在互联网行业还是很难实施的,除非以减少工作时长为代价。

第四个模式:工作空间

工作场所的入口应该是属于所有小组的,就像大家可以围坐在壁炉周围一样。沿着亲密梯度往前应该是为小组成员互动和社交而设计的紧密空间。最后应该是为个人工作设计的受保护的安静思考空间。

小组互动的空间需要提供能够容纳所有人员的桌椅,可供书写的表面,以及允许随意张贴的区域。最理想的是能够有空间让小组成员一起准备餐食,并一起进餐。

没有一起聚餐的人类不可能形成群体,给每个小组一个可以共同进餐的地方,并让其成为日常活动。在每个工作场所开展集体午餐变得格外重要。

2.21 模式之模式

在成功的空间设计中,一次次观察到这些模式的原因在于它们跟人类的特性息息相关。这样的空间考虑了人性化的功用,抓住了问题的关键——人既是个体的人,又是群体的人。人的个体属性和集体倾斜性都得到了认可,从而让人能够自由发挥。

三、正确的人

然而,现代管理学仍然没有足够重视雇用和留用正确的人。在这点上,你参加的任何管理课程基本都是浅尝辄止。对大多数尝试来说,成功还是失败在组建团队并形成最初方向时就已经设定了。一旦拥有一群才能超卓的成员,管理者就可以在开动后退居二线了。

3.1 霍恩布洛尔因素

霍恩布洛尔是一个冒险船船长、他的一生通过运用智慧、勇气、政治手段和好运,从一名海军军官学校学生成长为一名海军上将,就像《商业周刊》介绍的某公司管理者如坐直升梯般得到晋升一样。从他的故事中,我们能够学到现实生活中真正的管理课。

在霍恩布洛尔船长的故事中,不断重复的主题是他内心预感到进取者都是天生的,而不是后天练就的。但是笔者并不认可霍恩布洛尔船长的观点,种观点有其局限性,现实中大量案例表明后天的培养、环境塑造和个人努力等对成为进取者起着关键作用 。

但是如果换个角度理解这个观点,我觉得就很有意思,我们常说的就是我们只能接受一个人,而无法改变一个人,人们通常在短时间内很难做出改变,管理者也很难找到杠杆的支点来撬动他们发生本质的改变。

而对于互联网行业来说,真正热爱互联网行业的人及时技术不够,但是可以随着时间和经验弥补,但是如果从一开始这人就不适合做互联网,不喜欢软件行业,即使现在有些技术,也不适合长期的发展。

这意味着从一开始就找到正确的人至关重要。幸运的是你不需要完全靠撞大运,在雇用新人或者从公司内部选取人员成立团队的过程中,管理者可以起到关键作用。

3.2 整齐的塑料人

即使是新晋的管理者,在初次面试人的时候也知道一些招聘原则。譬如,他们知道不能以貌取人。产品质量与外貌无关,外表出色未必能交付优秀的产品。

尽管这一道理人人皆知,但让人奇怪的是,许多招聘上的失误又都是由于过度重视外表而忽略了真正能力造成的。这并非招聘者的疏忽或肤浅,而是物种的进化让我们更关注那些非凡的人。这种趋势直接服务于物种的进化,从对诸如恐怖电影的反应中,你可以观察到这种在你身上的进化防御。某种类人的 “生物” 总是会比慢慢吞噬着底特律的一团无眼怪物更让人害怕。

就像是《人月神话》中描述的人狼,平时是以人类进行出现,但是能够在某个晚上,变成一个狼一般的怪物。

究其原因,影响招聘的并不仅仅是你个人存在这种倾向,你所在的组织下意识也在制造自己的标准。雇来的每位员工都是你这小帝国的一员,你老板帝国的一员,溯流而上,是你老板的老板的下属。你采纳的标准并不属于你自己,你是在为你的各级上层招聘。当你每次在决定雇用一个人时,高层管理的喜好都在左右着你。这种几乎无形的压力推动着公司趋于平均化,促使你去招聘长相相似、说法相似、思想相似的人。在一个健康的公司文化下,这种影响微乎其微,以至于可以忽略;若公司的文化不够健康,想要招到一个与其他人比较显得特立独行的关键人物,就变得异常困难,甚至根本不可能。

这种整齐划一的要求是部分管理者缺乏安全感的表现。好多公司甚至都会要求员工的服装,但是在IT行业里面,对服装的要求还是比较低的,有着一定的自由度,但是笔者认为这种服装自由还是要有一定的度,如果穿拖鞋背心来上班,对于笔者来说就感觉很是不够尊重他人。

3.3 专业

在书中,作者举了这样一个例子:一个员工在公司微波炉中加热爆米花,然后管理层的一位正好闻到了这个气味,于是发了一个公告“爆米花是不专业的”。作者认为技术部门是一个对内的部分,而不像销售部这些和客户打交道的外部部门,这些“专业化”的标准仅仅是内部人员的认知罢了。

虽然作者想表达的意识是,公司太多的“专业”对开发人员的限制太多,会使员工逐渐丧失活力。

但在笔者看来,对于脑力工作者来说,过多的标准化会限制员工的思维和活力,这些在第一章和第二章中有论述,每个员工都是有个性的,而彰显个性并非是一种威胁,如果什么都用“专业”来衡量,比如男生留长发是不专业的,在墙上贴海报是不专业的,即使是非上班时间在公司打游戏是不专业的等等。

这些“专业”化的衡量无疑是病态的,衡量一个人是否专业,更应该看的是他的学识和能力,但是有些限制我认为是必要的,比如在微波炉加热榴莲,穿着不得体这种会影响他人的无理行为应该是所有员工(不管是对内还是对外的部门)都应该达成的共识。

3.4 领导力

领导力是命令吗?显然不是,自上而下的领导并非真正的领导。真正的领导一定是了解自己的团队的,了解团队每一个成员的能力和性格,从而做到服务式的领导。

想象一下,一个高高在上的领导,发布命令,但是因为并不了解自己的员工,即使员工费劲力气也无法完成设定的目标,这种领导力就是工作榨取的机制,他追求数量而非质量。管理者领导你,就是想办法让你工作更卖命、时间更长,没法休息。

在前面2.3节的时候我们聊过,朝九晚五在这里啥也完不成,脑力型劳动不同于面包店这种体力型劳动,可以靠让员工工作更多的时间榨取更多的价值,软件开发团队一味的砸时间,陷入100%满负荷,毫无创新力可言。

在这里插入图片描述

真正的领导力:作为服务的领导力

领导力并不是从我们身上压榨出什么东西,而是一种服务,这样的领导力保证了能够不停地推动大家前进。虽然这种领导者不会制定明确的方向,但是起到的大多是催化剂的作用,逐步向着可实现的目标前进。

书中总结了服务型领导力需要做到的几点

  • 主动承担责任
  • 明显地胜任工作
  • 为任务准备提前做足必要的功课
  • 让每个人创造最大的价值
  • 实施过程中保持幽默和明显的善意

领导力和创新

在本小节第三段中,我们谈了自上而下的压榨性领导力对创新的不良影响,创新和领导力的关系是互为依存,创新依靠领导力,而领导力又需要创新,创新依靠领导力,这一点很好理解。如果你的老板压迫你在公司的一切时间,让你时刻处于满负荷状态,那么即使你再有创新力,再有想法,你的创新也无从实战。

那么领导力需要创新要如何理解?

明明创新会打破现有格局,对创新者以外的人或多或少都有正面或者负面的影响,但真正的领导力是作为服务的领导,这种领导是推动成员发挥自己的价值,逐步向着目标靠近的。

就像敏捷中的敏捷教练,敏捷教练充当的角色是敏捷团队的领导者,但不是发号施令者,敏捷教练是为整个团队服务的。

因此,真正的领导力是需要创新的,一个企业不能没有创新,创新是第一动力,而且领导力需要贯彻执行,而非口头承诺实际却不作为。

3.5 招聘与被招聘

在人才招聘领域,面试环节的核心不应局限于技术考察,而应着重评估候选人的综合能力。相较于单纯依赖口头表述,通过多维渠道评估候选人的真实能力更为可靠,具体可从以下两方面着手:

一方面,了解候选人过往作品,包括个人博客、代码仓库、出版书籍等。这种评估方式能有效规避 “面试包装” 带来的认知偏差,从实际成果中洞察候选人的技术实力与思维深度。

另一方面,优化面试提问策略,避免采用 “HTTP 与 HTTPS 协议区别” 这类简单知识问答,转而设计开放性问题,如 “若将 Java 项目迁移至 Go 语言,你将如何规划实施?” 此类问题聚焦候选人的技术视野、问题解决能力与逻辑思维过程,能更全面展现其综合素质。

当前,多数企业在招聘时过度关注候选人当下是否适配特定项目需求,却忽视了人才发展的长远性。事实上,具备较强综合能力的开发者,尽管现阶段掌握的技术可能有限(如仅熟悉 BCD 技术),但其学习能力与知识迁移能力更强,未来学习新技术(如 A 技术)的效率与成本,远低于仅掌握单一技术且缺乏成长性的候选人。这种短视的招聘策略,可能导致企业错失潜力人才,影响团队的长期发展与创新能力。

3.6 与他们良好合作

在我的首篇帖子《项目管理总结》中曾明确提出,团队的发展需经历形成期、震荡期、规范期与成熟期四个关键阶段。由于团队成员在性别、认知水平及文化背景上存在显著差异,要塑造一支成熟高效的团队,必然需要漫长的时间磨合。在磨合期间,团队的组成不能轻易改变,正如《人月神话》所揭示的,在项目延期的情况下引入新成员不仅难以推动项目进展,反而会增加成本投入,其核心原因在于新成员与原有团队尚未建立起高效的协作机制与默契。

一流企业与外包公司在企业文化建设与人才管理方面存在显著差距。一流企业会运用多元化策略,如职业发展规划、企业文化熏陶、激励机制设计等,全力营造良好的工作环境与企业生态,以增强员工归属感,吸引和留住人才。而外包公司由于业务模式与行业特性,往往被员工视为职业发展的跳板,员工普遍缺乏长期扎根的意愿,存在 “留一手” 的心态,这种人才流动特性导致外包公司在企业文化建设与团队稳定性上难以与一流企业相提并论。

以烹饪领域的发展为例,在过去,饮食文化具有强烈的地域局限性,人们往往只能品尝到本地特色美食。但随着全球化与市场化进程的加速,不同地域、不同文化背景的人群频繁交汇融合。这种融合为团队发展带来双重影响:一方面,多元文化的碰撞为创新提供了肥沃土壤,不同文化背景的成员在交流与思维碰撞中,可能会激发出全新的创意与解决方案;另一方面,也给团队管理与协作带来巨大挑战,管理者需要花费更多精力协调成员间的文化差异,建立有效的沟通机制与团队规范,以确保团队高效运转。

3.7童年的终结

随着科技的深度渗透与迭代,电脑、智能手机、互联网、编程技术及网络社交平台早已超越单纯的技术范畴,演变为塑造当代社会生活的新型环境。在这种环境中,技术使用近乎成为本能,无需系统性教学,而与之相关的道德规范却在便捷性的冲击下逐渐被边缘化。

以 B 站为例,早期严格的入站考试设置了文化与规则认知的准入门槛,筛选出的用户群体普遍具备一定文化素养,且自愿遵守社区道德规范,使得当时的弹幕和评论区充满友善交流氛围。然而,随着互联网普及程度提升,用户准入门槛降低,不同年龄、认知水平的人群涌入,社区原有的道德秩序被打破。如今,引战言论、节奏风波频繁出现,曾经的和谐交流场景逐渐被碎片化、情绪化的互动取代。

在代际沟通方式的差异上,通讯工具的演变体现得尤为明显。在互联网发展初期,即时通讯尚未成熟,老一辈职场人习惯通过电子邮件和电话进行工作沟通。电子邮件以其正式性和高信息密度,成为商务沟通的重要载体。但对于成长于即时通讯时代的年轻人而言,电子邮件的使用频率大幅下降,甚至部分年轻人从未撰写过邮件,也没有专属电子邮箱。尽管即时通讯的便捷性契合了快餐化时代的节奏,但电子邮件在正式商务沟通、文件存档等场景下的不可替代性,仍凸显出代际间沟通习惯与价值认知的差异。

在注意力模式与工作习惯方面,年轻一代展现出独特的行为特征。他们更适应 “持续不断的局部注意力” 工作模式,常同时开启数十个软件,将学习、工作、娱乐工具交织使用,并认为这种多线程操作能实现效率最大化。这一现象的形成,既与年轻人成长于信息爆炸环境有关,也深受当下工作模式的影响。如今,工作内容愈发零散化,突发的紧急会议、例行站会等频繁打断工作节奏,使得人们难以长时间维持深度专注状态。当工作者刚刚进入 “流状态”,就可能因外界干扰而被迫中断,久而久之,便催生了适应碎片化工作场景的注意力分配模式。

3.8 在这很开心

新员工入职初期普遍存在 “负收益” 现象,需经历业务熟悉、技能培训等适应期才能实现价值转化。高离职率企业的长期损失远超人员替换带来的短期收益,这一现象背后隐藏着深刻的管理逻辑。

高离职率的公司一般都会有着这样的相同点

  • 过客心态:同事造成不希望长期投入工作的感觉
  • 可被替代感:管理层认为员工只是可被替代的部件

在这种公司中,员工的忠诚是可笑的,没有人会对一个视自己的员工为部件的公司效忠。

与之形成鲜明对比的是,优秀企业将员工视为核心资产,通过系统化培训体系、个性化职业发展规划彰显对人才的重视。这些企业致力于构建和谐的组织生态,塑造共同追求卓越的价值导向,显著提升员工凝聚力与创造力。虽然从短期财务视角看,保留并培养潜力员工的成本高于直接雇佣成熟人才,但由此形成的高归属感、低离职率,能够为企业带来长期稳定的创新能力与竞争优势。

企业战略决策中的 “病态行为”—— 盲目搬迁,常成为破坏员工归属感的隐形杀手。无论是基于成本控制、政策导向,还是管理者的个人意志,企业迁移往往伴随员工家庭分隔、通勤成本激增、环境适应困难等连锁反应。以 ESS 项目为例,负责人肯特勒奇・雷在搬迁后坦言,因员工流失造成的损失远超预期,搬迁前的离职潮对项目推进产生了毁灭性打击。这一案例深刻揭示:忽视员工情感需求与生活质量的决策,终将反噬企业自身的持续发展能力。

3.9 人力资本

公司花在人身上的钱算作花销还是投资,对于大部分会计来说,可能会算作花销吧。但是如果你的员工参加了一场培训,培训后的知识没有消失,而是作为一种在员工的脑子里的资产,管理者一定要看清楚这一点,如果仅仅因为短期利益而放弃对员工的长期投资,或是是裁掉已经投资过的员工,都会在长期利益上受损。

下面我们看一个案例:

假设贵公司的数据库专家路易丝决定月底要离开公司。在这之前,你对自己的 5 人团队在明年夏天交付公司新一代的订单管理系统感到乐观。工作推进得很平稳,团队能力很强并且效率很高。至少这是在路易丝扔出这个重磅炸弹之前的情况。现在看来就难说了,这简直是一场灾难。你打给人事部一个电话,告诉他们这个坏消息。“路易丝决定 31 号离开,” 你报告说,然后充满希望地要求,“能给我们找到另外一个路易丝吗?”

不幸的是,人事部没有像路易丝那样有技术、懂业务、经验丰富的专家。“拉尔夫怎么样?” 有人向你建议。你从未听说过拉尔夫,但现在看来也没什么其他选择了,你只有接受。事情搞定,路易丝 31 号离开,拉尔夫在次日加入。

表面看来项目没受任何影响,31 号你有 5 个人,下个月 1 号还是 5 个人。如果拉尔夫和路易丝工资一样,那么公司就尽职地用同样的价格购买了工时,团队也得到了完整的 5 个人月的安排,就好像路易丝留下来了一样。如果项目上个月是按计划进行的,那么现在也应该按计划进行。那你还有什么感到闹心的呢?

让我们先来看看拉尔夫在公司的第一天是怎样度过的吧。路易丝走后,仍然留下不少数据库相关的工作;拉尔夫第一天能够干掉多少呢?答案当然是什么都做不了。拉尔夫当然不会只坐在那里。他花了一天处理他的健康保险、学会怎么订午餐、领取他的办公用品、配置好他的电脑及网络。他的原始产出是零。呀,可能还是负数!如果他占用了别人的工作时间 —— 这个当然你也知道,他总是需要问一些基本问题的 —— 这个时候他对团队的贡献就是负数了。

第一天就这样了;第二天呢?第二天可能稍微好点。拉尔夫现在全身心投入了,学习路易丝留给他的资料。当然,如果路易丝留下来,这些工作是不必要的,她早知道这些知识了。(如果不是因为要离开,她也不需要写这些资料。)拉尔夫的产出效率仍然远低于路易丝。他可能还是负贡献,因为他很可能还是需要其他团队人员的帮助。对于团队来说如果拉尔夫不来他们是不需要花这些时间去支持的。

渐渐地,你的团队新成员拉尔夫完全跟上了节奏,达到跟路易丝差不多的产出效率。

在这里插入图片描述

生产效率在路易丝离开后受到很大打击,甚至于有段时间到了零以下,因为团队其他人慌忙去填补一个完全融入团队的成员离开带来的工作缺口。然后,经过一段时间,团队最后又回到了原来所在的生产效率水平。

四、高效团队养成

当团队成为一个整体时,大家工作会变得更好,更富有乐趣。

4.1 整体大于部分之和

在群体协作中,凝聚力是区分团队与普通小组的核心要素。具备凝聚力的群体能产生协同效应,其整体产出远超松散协作的小组。这种强大的内在驱动力不仅提升工作效率,更为团队的成功奠定坚实基础。

当团队形成凝聚力后,管理模式也需随之转变。此时管理者无需采用传统的管控方式,而是将重心放在清除阻碍、优化流程、隔绝外部干扰上。成员自发的高昂斗志与协作精神,使得团队能够自主高效运转,管理者只需做好后勤保障与资源协调工作。

敏捷教练在高凝聚力团队中同样扮演着特殊角色。其成功的标志在于,能够逐步从台前退居幕后,让团队在脱离外部指导的情况下仍能保持敏捷运作。教练的主要职责变为守护团队的协作生态,防止外部因素破坏团队的凝聚力与工作节奏。

团队的组建离不开目标的统一。虽然部分管理者认为员工接受企业目标是职业素养的基本要求,但实际上,这并非天然形成。正如企业通过机制设计让管理者的个人目标与企业目标趋同,团队也需要通过内部社交单元,构建共同愿景,引导成员将个人目标与团队目标深度绑定。只有当全体成员对目标达成高度共识,团队才能真正组建并持续发展。

离职率是衡量团队凝聚力的重要指标。具有凝聚力的团队成员对所产出的成果抱有强烈归属感,他们渴望在作品中留下自己的印记,在工作中获得成就感与价值感。这种积极的工作体验使团队成员更愿意长期投入,自然降低了离职意愿。因此,通过观察离职率的变化,能够直观地评估团队凝聚力的强弱。

4.2 黑衣团队

如果你还没有见过一个有凝聚力的团队,那么这个黑衣团队就是一个很好的例子。

在很久之前纽约州北部的一家生产大型蓝色电脑的小公司,交付的软件总是缺陷不断,在一段时间里,公司花了不少精力去培训他们的客户,期望他们能够容忍软件的缺陷,但这个方法没有奏效,因此他们不得不下定决心消除这些缺陷。

但是开发者都信心满满地认为自己写的程序是最好的,他们尝试去寻找缺陷却找不到。

于是,具有传奇色彩的黑衣团队诞生了

一开始,黑衣团队仅仅是一群证明自己测试能力更优秀的人。他们的动力更强一点儿。他们也会测试别人写的代码,因而可以避免开发人员测试自己程序时先入为主的偏见。归根到底,对于组建这样一支团队的人来说,他们期望至少能适当地提高产品质量。然而,他们的收获比预期更多。

黑衣团队最让人吃惊的不是他们在一开始有多好,而是在接下来的一年时间里他们改进了多少。一些神奇的事情发生了:团队形成了自己的个性。在测试的对抗哲学影响下,这一个性在团队成员中形成,它让大家积极主动地去发现缺陷。他们并不完全是为开发人员提供支持,恰恰相反,他们乐于提交一个程序(包括程序员)去接受一系列测试,更像是一种考验。提交你的程序去接受黑衣团队测试,就像去经受冷血魔王的考验一样。

他们毁灭的不仅仅是你的代码,而是你的一整天。他们使用各种惨无人道的手段来造成程序失败,比如缓冲区过载、空文件比较或者输入无理的长字符串。看着自己的程序被如此邪恶的方式给践踏,无论男女,都要忍不住落泪了。可你越感到难过,他们就越开心。

为了加强邪恶形象的效果,团队开始身着黑衣(此乃黑衣团队得名的由来)。一个程序失败,他们会高声发出可怕的怪笑。一些团队成员蓄起了长胡子,卷曲着像凶残的工头。他们聚在一起搞出诸多狠毒的测试方法。程序员们开始抱怨黑衣团队这种病态的折磨。

随着时间推移,团队成员逐渐转移到其他事情上。由于团队担负了如此重要的任务,每离开一位就会有新人加入,这样一直到全部原班人马都离开了团队。但黑衣团队仍然存在,团队失去了原来的所有人,但团队的动力和个性依然存在。

4.3 团队自毁

如果说有什么能够让团队凝聚起来,这可能并没有标准答案,不同的团队凝聚的方式各不相同,但是如果说有什么能够摧毁一个团队,这能够总结出来的共性特点就很多了。

4.3.1 防御式管理

作为管理者,面对风险时采取防御措施本无可厚非。然而,将个人想法强行灌输给团队,或是无端进行技术干涉,这些行为实则是对团队缺乏信任的体现。而这种不信任,恰恰是团队凝聚力的 “毒药”。在不被信任的环境下,成员难以产生动力,更无法形成高效协作的团队。

明智的管理者应充分信任团队,给予成员试错空间。当错误出现时,积极引导团队分析问题、解决问题,而非一味强行干预,更不能营造出 “犯错即犯天条” 的压抑氛围。如此,团队才能在信任的土壤中茁壮成长,释放出最大的效能。

4.3.2 官僚主义

在系统开发领域,那些无需深入思考、机械性的文案工作,本质上是官僚主义的体现。据统计,此类工作耗费的成本,在系统开发花销中占比超 30%,无疑是一种资源浪费。

敏捷开发秉持 “可工作的软件胜过详尽的文档” 原则,坚决反对过度依赖文档的做法,摒弃大量无实质价值的文档。不过,这并不代表敏捷开发将文档完全摒弃。敏捷开发只是在强调,应合理权衡文档的价值,将重点放在打造可实际运行、满足需求的软件上,让文档作为辅助工具,在真正必要时发挥作用,助力团队沟通与知识传承。

4.3.3 物理分隔

将一个团队成员分隔在不同的区域、楼层,对于团队的工作交互可能没有什么大的影响,但团队的日常交流就没有了,团队里的人可能跟不是一个团队的邻居更亲密。邻桌的员工也会是噪声和打扰的来源,但如果他们都在一个团队中,因为工作的一致性,会减少相互之间的打扰。

4.3.4 时间碎片

当一个员工同时在4个项目里时,他就需要4倍的人际互动,几乎把所有时间都花在角色切换上了,没有人可以是多个有凝聚力团队的一员,紧密协作的有凝聚力的团队是排他的,碎片化的团队不可能形成凝聚力。

4.3.5 牺牲产品质量

以牺牲产品质量换取的尽早的交付,对开发人员来说,自我价值及实现倍破坏了,现实要求他们只能生产出质量低于他们力所能及的产品。这时团队建立起来的自我认知就荡然无存了。开发这样的一个产品没有任何协作的成就感,大家都知道,只有停止做这样的事情才能得到解脱,因此项目结束后大家都想尽量彼此分开,然后去做其他有意义的事情。

4.3.6 伪造截止日期

在之前笔记中,我们论述过过紧的截止日期会成功团队的阻力。如果管理者一再拿出不可能交付的日期作为截止日期,大家可能连眼皮都不会抬一下,他们经历过太多次了,知道这是什么样的游戏。

4.3.7 团伙控制

一些公司会要求项目匀速减员,从而使公司能够有效分配资源给新项目,或是避免一个团队对某些资源的持续占有。但这些都会导致团队最终解散。

4.3.8 可恶的标语和纪念碑

在求学或者工作中,是否经常见到这样一个图片

在这里插入图片描述

管理者相信这种所谓的励志标语能够激发人的动力,在公司中,好像无处不在宣扬质量、领导力、创造力、团队协作、忠诚守信等美德,但是这些招贴只会让事情变得更糟,真正的改变不是一张简单的标语就能实现的,而是需要人为的实践探索。标语只会让人变得麻木,给健康的组织带来危害。

4.3.9 加班

加班在短时间内确实可以提高效率,但是加班不是一个良好的企业文化。首先是加班所带来的副作用:犯错、累倒、离职率上升和付薪的无用时间等等。加班意味着这些工作原本就不能按正常情况下交付,而这不应该是招聘更多的人或者延长交付时间吗?

加班所带来的不公平也会加剧团队内部的矛盾,比如小红因为身体原因无法加班,而你却被迫在公司加班苦干。一段时间后,你的家人开始不满,你的老婆孩子开始抱怨,你自己身体也逐渐累垮,也在抱怨凭什么小红不用加班等等。

一个高效运行的有凝聚力的团队就这样被不统一的加班政策瓦解了。

况且,延长加班时间对于脑力工作来说是一项减产的实践,额外几个小时的产出总会被之后的副作用低效,即使不考虑对团队的破坏也是一样。

同时,现在的加班者也并非是要通过加班来完成工作,而是希望能够在工作根本无法按时完成时通过加班来避免指责。

4.4 竞争

在探讨公司内部竞争之前,先来看一个家庭中的现象。家长往往会留意到,孩子们之间常存在竞争行为。部分家长或许会认为,这种竞争有助于孩子日后应对生活的艰难。然而,兄弟姐妹间过度竞争并非良策。经验表明,在激烈竞争环境中成长的兄弟姐妹,成年后关系易趋于疏远;而竞争较少的孩子,长大后更易维系温馨的亲情。

团队内部竞争与家庭内部竞争存在相似性。理想的团队竞争,应是基于发现差距,进而帮助落后成员提升。以知识型团队为例,其成员具备多样技能,管理者难以掌握全部,也就无法为所有员工提供辅导。此时,优秀的管理者会引导团队自主解决问题。比如,成员 A 向 B 分享 TCP/IP 知识,B 则为 A 讲解队列实现知识,同时将这些知识沉淀于知识库。这一过程自然流畅,参与者甚至不觉得是在进行辅导,而将其视为工作的一部分。

曾经受他人辅导,我们会心怀感恩与亏欠。当自己去辅导他人时,能从中获得成就感,仿佛偿还了这份 “人情债”。

竞争催生的团队成员年度量化评级,实则是团队自我损耗的因素之一。年度量化评级使成员为完成 KPI 而奔波,无暇顾及创新与精益求精。因为追求极致品质,可能导致无法完成全部 KPI。而且,在竞争白热化的团队里,成员担心因辅导他人而使自己处于不利境地,相互辅导难以实现,最终团队易陷入类似帕金森定律描述的低效状态。

若用其他行业团队作类比,音乐合唱团颇为契合。在合唱团中,个体与团队的成败紧密相连。没人会因个人演唱出色,却不顾合唱团整体跑调而受到祝贺。

4.5 一顿意面晚餐

设想你身处一个新组建的团队。今晚,老板邀你参加聚会,大家一同前往超市采购食材,每个人负责采购不同的东西。回到住处后,又齐心协力完成意面的制作。在这期间,老板与大家聊天的话题并非食材,而是各类软件工具。

整个过程配合默契、自然流畅。这是一场全员参与的破冰活动,让团队成员感受到,团队是由平等且友好的个体汇聚而成,大家为了共同目标一起努力。最出色的老板,便是能在持续管理团队的同时,让成员毫无 “被管理” 的压迫感,在轻松氛围中实现团队协作与成长。

4.6 敞开和服

“敞开和服” 代表着一种与防御式管理截然不同的态度。秉持用人不疑的原则,当你把员工置于特定岗位,就应给予充分信任,摒弃任何无端的防御举措。要坚信,在你领导下的每一个人都值得信赖。毕竟,一个不被信任、缺乏工作自主权的人,很难在岗位上发挥出真正的价值。

书中有这样一个案例:一位律师将合同呈递给老板,请求老板过目后签字。然而,老板对律师极为信任,直言 “我不读合同” 便欲签字。律师见状,顿时紧张起来,急忙表示:“天哪,让我再检查一遍” 。

这个故事揭示了一个道理:当老板将自身声誉托付给下属时,会在团队中激起一股小小的兴奋与干劲。这种信任能促使每个人全力以赴,让团队的凝聚更具价值。此时,成员们不再单纯为完成工作而工作,更是为了证明这份信任实至名归。

老板不应依赖摄像头监控或现场巡逻等物理手段来监督团队。真正的信任,应贯穿工作全程。即便员工在某些时段看似未在工作,但只要最终交付的产品质量合格,便已足够。要相信,员工或许因身体或精神状态不佳,在工作时间有所懈怠,但他们往往会在其他时间弥补,保证工作的完成。

4.7 团队形成的化学反应
4.7.1 建立对质量的执着追求

对质量的不懈追求,堪称催生团队形成的最强有力的催化剂。从内在激励角度看,当团队成员致力于打造高质量的产品或提供高质量的服务时,每一次接近或达成高质量标准,都如同在他们的职业成就清单上增添了光辉的一笔。这种成就感与满足感,不仅是对个人能力的肯定,更是一种强大的精神激励,促使成员更积极主动地投入工作,在团队中找到强烈的归属感和价值感,进而紧密地凝聚在一起。

从外部差异化角度而言,对质量的执着追求,使团队在众多群体中脱颖而出。在竞争激烈的环境里,或许其他团队并未将质量作为首要追求,满足于一般水准的产出。然而,秉持质量至上理念的团队,凭借高质量的成果,与外界拉开了明显的差距。这种差距不仅体现在产品或服务的实际表现上,更体现在团队的声誉和形象塑造中。高质量的产出成为团队的鲜明标签,让团队在市场或行业中拥有独特的辨识度,吸引更多优质资源,也让团队成员因身处这样卓越的团队而倍感自豪,进一步增强了团队的向心力和稳定性。如此,对质量的追求从内到外,全方位地促进了团队的形成与发展,使其成为一个紧密协作、目标明确且极具竞争力的整体。

4.7.2 提供诸多满意的闭环

所谓 “满意的闭环”,是指持续确认自身是否行进在正确方向上,这是组织发展的必要路径。管理者应设置合理的里程碑,若缺乏阶段性成果的反馈闭环,员工容易士气渐衰,甚至产生难以坚持到项目完结的消极念头。

管理者可将工作细分为若干小块,确保每部分工作完成后都有清晰可辨的成果呈现。即便从客户与高层视角看,无需众多版本更迭,但对团队内部而言,这些版本至关重要。它们是提升团队士气的有效机制,每一次小阶段的成功,都如同给团队注入新的能量,激励成员以更饱满的热情和信心迈向下一步。

4.7.3 建立精英意识

20 世纪 70 年代初期,我们一个客户的副总给他部门的员工群发了一封关于出差费用的通告。你可能收到过类似的通告,但这封信却与众不同。通告的大意是:“最近,我注意到你们一些人在出差时乘坐的是经济舱。我们不是一个经济舱级别的公司。我们是头等舱级别的公司。现在开始,如果你为公出差,请坐头等舱!” 当然,这封通告意味着得花不少钱。花费是实打实的,得到的却是精英意识的提升,这足以平衡这些额外的花销了。

精英团队可能会让管理者感到挑战,感觉团队不受到自己的控制,但是一流的管理者知道人们不能被任何合理方法控制。成功管理的核心是让大家齐心协力,然后助推大家到一个连管理者自己都无法让他们停止的点。

4.7.4 允许和鼓励差异性

成员间的差异性是凝聚团队的强大助力。当行动不便却技术精湛的开发人员加入新组建的工作小组,或是朝气蓬勃的实习生融入团队,这些不同背景、特质的新鲜血液,会如石子投入湖面般,激起层层活力涟漪。

这种差异打破了团队可能存在的同质化僵局,让成员们清晰认识到,彼此并非毫无个性、可随意替换的 “机器人”,而是各具特色、独一无二的个体。大家带着不同的经验、视角与思维方式汇聚于此,在相互碰撞、交流与协作中,为团队注入源源不断的创新动力,促使团队成员彼此欣赏、相互学习,进而紧密凝聚,携手迈向共同目标。

4.7.5 维护和保护成功团队

在前面团队自毁那一章节已经论述过逐渐解散团队导致的团队自毁,如果一个团队已经凝聚,就不要拆散团队,至少给大家一个机会尝试其他的项目。即使团队成员可能会自己选择离开,但这也是他们自己应有的选择权,而非强制分配到其他团队中去。

4.7.6 提供战略而不是战术方向

多数情况下,管理者并非团队的一员,团队是由平等的个体组成的。 大多数情况下,管理者都游离在团队之外,不时为团队提供来自上面的方向,同时清除行政和过程中的障碍。根据定义,管理者就跟大伙儿不平等,因而不是团队的组成部分。

在最棒的团队中,不同的个体时不时会展现出领导力,在自己擅长的专业领域带领大家。没有人是永远的领导者,因为这样的领导者不会是团队中平等的一分子,团队里的互动也会由此瓦解。

五、沃土

置身于一个有利于团队开展工作的环境中

5.1 自我修复

在团队的自我修复方面,书中关于规范的论述尤为关键。在软件工程领域,引入大型方法作为规范来约束团队的现象并不少见,看似能增加确定性,实则弊端明显。就像将一个现实的人工业务系统化,系统虽能按设计者预设运行,却缺失了人工时期处理复杂问题的能力。比如一些复杂的金融交易系统,在人工处理时代,交易员能根据市场瞬息万变的复杂情况灵活处理特殊交易,而当系统固化流程后,面对一些罕见的复杂市场波动,往往难以有效应对。

同时,这种大型规范还会束缚开发者的热情和生产力。真正的规范应符合公司实情,从小范围开始逐渐扩大并验证,就像很多成功的软件公司,在制定代码规范时,先在小团队内部试行,根据实际开发情况不断调整,再逐步推广到全公司。而且,应该通过培训、工具、审查逐渐引导性地收敛,而非强制引入 “规范方法”。霍桑效应也表明,人们在尝试新事物时表现会更好,所以在软件开发中,不应过度标准化,给开发者一定的创新空间,能激发他们的创造力。

5.2 风险管理

风险管理方面,书中提到的两种极端行为在软件项目中也常见。没有风险管理意识的冒险,可能导致项目因一个小的技术漏洞而全盘崩溃;而为了避免风险墨守成规,又会让项目难以有突破性进展。

任何有价值的软件项目都要冒风险,比如开发一款全新的人工智能应用,技术上的不确定性就是很大的风险,但一旦成功,其价值不可估量。而管理者往往会忽视自身失败的风险,因为承认失败会让他们颜面尽失,这就需要管理者正视风险,建立完善的风险评估机制。

5.3 会议

会议是软件团队协作中不可或缺的部分,健康的会议对项目推进至关重要。健康的会议是为完成一件事专门组织的,有确定的结束条件。比如在软件开发中,为解决某个技术难题而召开的会议,直到找到可行的解决方案才结束,而非时间一到就散会。而且会议理应是多对多的交流,不能是老板和员工一对一谈话浪费其他人时间。

5.4 让改变成为可能

我们应该认识到,没有什么事情比让一个人成为新秩序的导入者更难驾驭,更难确定成功,更难管理风险的了。因为所有受益于旧秩序的人都将成为他的敌人;而那些也许会收益与新秩序的人只可能成为他缺乏热情的保卫者 --马基雅弗利

马基雅弗利的话深刻揭示了改变的艰难。在软件工程行业,技术和市场变化迅速,改变是常态。软件公司推行新的开发模式,比如从瀑布式开发转向敏捷开发,那些习惯了旧有模式的员工可能会抵触,而受益于新模式的员工初期也可能热情不高。改变的模型 “旧标准 -> 混乱 -> 实践与整合 -> 新标准” 也适用于此,在转型过程中,团队可能会经历一段混乱期,但通过不断实践和整合,最终会形成新的高效开发模式,同时改变需要容忍失败,在软件开发中,新功能的测试失败是常有的事,从失败中总结经验,才能不断完善。

5.5 组织型学习

“业精于勤荒于嬉” 同样适用于软件团队。但学习受限于组织留住员工的能力,如果团队人员离职率过高,之前积累的技术经验和学习成果就会流失,甚至形成恶性循环。

改变活动应从中间管理者开始,高层管理者有战略思维,底层员工受资源和活动范围限制,中间管理层起着承上启下的作用。如果中间管理层之间没有交流、没有共同目标,勾心斗角,整个团队的学习就会停滞,就像一个软件公司的几个部门经理各自为政,不分享技术和管理经验,会严重阻碍公司整体的技术进步和发展。

5.6 构建社区

构建社区对软件公司也意义重大。成功构建社区的组织更能留住人,即使员工离职也会选择合适的时机,减少对项目的影响。构建社区没有固定公式,需要从实际出发探索,比如一些软件公司通过组织技术分享会、团队建设活动等,营造良好的团队氛围,让员工有归属感,形成一个有凝聚力的社区

六、快乐地工作

当你对某事乐在其中,那你一定不是在工作

6.1 混乱与秩序

人类的本性使我们成为混乱的天敌。每当我们遇到混乱时,都希望将其变回秩序井然。但也正因此某些疯狂的乐趣就此丢失了,为了给工作注入更多的能量, 可以引入少量“无序”。

6.1.1 试点项目

在整个公司中,可以引入一些新的未经证明的技术作为试点项目,但在任何一个项目中尽量不要实验超过一种类型的开发技术。

根据霍桑效应,人们在尝试新颖的东西时,所激发的能量和兴趣可以促进人们的生产效率,因此可以抵消过陡的学习曲线带来的负面影响。

6.1.2 战争游戏

正如2.4中提到的编码游戏一样,有时一些具有竞争性但又无所谓输赢的活动可以带来建设意义的无序性。不止软件行业,这种概念是可以应用在任何一个领域,如中学举办的教师说课比赛,老师为学生举办的古诗词大赛等等,这些游戏都可以成为一种令人愉悦的经历,并能比较参赛者之间的能力殊异(安全和信息保障等内容在2.4中有所提及)。

战争游戏可以帮助员工评估自己的相对优势与劣势,进而帮助企业评估自己的整体优势与劣势,但同时为了减少员工之间的落差心理造成的问题,可以在不同侧重点设置奖项,寻找机会让每个人都在某种程度上获胜(最短耗时奖,健壮产品奖,最优方案奖等)。

人们总是喜欢共患难、精疲力竭,让每个人看到其他人头发凌乱,与平时的严谨形成对比的一面,会使整个团队更加紧密联系在一起。

6.1.3 头脑风暴

头脑风暴是一种交互式的会议活动,对于需要创造性思维的工作尤为有用,一群人聚集在一起讨论同一个问题。

头脑风暴没有多少规则,组织者需要保证整个过程是愉快的,并且能产生出实际的效果。有时一个明显看起来很愚蠢而且在常规会议中根本不会被提出来的点子会成为最后的赢家。

作为组织者,当发现大家没有什么点子可提出时,可以采取以下措施:

①类比思考(比如,大自然是如何处理这个问题的)

②反其道而行之

③身临其境(如果是你,你会如何解决这个问题)

6.1.4 培训、旅行、会议、庆祝和撤退

对于在沉闷的办公室待惯了的人来说,到办公室外面走走是一种转换心情的方式。特别是对于正在成长的团队来说,值得花钱让他们走出办公室。比如大家一起参加某次培训,或者组织一次户外活动,你的员工前一天可能为了某个难题而苦思冥想,但第二天却发现在于同时同甘共苦。

或者在某个中午,公司给每位员工提供一次惊喜的午餐作为庆祝,这一成本不过百元,却在之后常被人津津乐道。

毫无疑问,好的秩序是我们日常工作所需,但是我们依然希望能看到一些冒险和一些适应的具有建设意义的无序性。

6.2 自由电子

书中所提 “自由电子”,原指行业大师、咨询者这类有地位的员工,可自主探索新技术、拓展领域,公司也愿为其新想法投入人力尝试。而在我看来,“自由电子” 也可体现为管理者对员工的信任模式:项目经理清晰传递需求后,放手让员工自主定义实现路径,既呵护热情,又能充分激发能动性 。

以上便是笔者读完《人件》后的全部心得。总体而言,这本书尤为强调人在实际工作中的核心作用,始终围绕 “人本身” 及 “影响人工作的各类因素” 展开多维度分析,并结合大量真实案例,针对性地提出了一系列切实可行的解决办法。

http://www.dtcms.com/a/276732.html

相关文章:

  • 【Flask】基础入门
  • 华为业务变革项目IPD基本知识
  • nodejs获取可用cpu数
  • 前端弹性布局全解析
  • 20250712-2-Kubernetes 应用程序生命周期管理-部署应用的流程_笔记
  • PyVision:基于动态工具的具身智能体
  • 剑指offer——队列栈:用两个栈实现队列
  • 模型驱动的架构MDA的案例
  • 如何配置pip使用国内镜像?
  • 2D转换综合写法顺序,以及注意事项
  • 【理念●体系】模板规范篇:打造可标准化复用的 AI 项目骨架
  • 68 指针的减法操作
  • C语言文件读操作详解:使用fgets函数实现安全的按行读取
  • 在YOLO-World中集成DeformConv、CBAM和Cross-Modal Attention模块的技术报告
  • 进制转换算法详解及应用
  • 红旗新能源车:驾驭梦想,驶向未来
  • TDengine 使用最佳实践(1)
  • 系统性能评估方法深度解析:从经典到现代
  • 【C/C++】编译期计算能力概述
  • 《汇编语言:基于X86处理器》第7章 整数运算(3)
  • Noting
  • L1正则化 VS L2正则化
  • 全连接网络 和卷积神经网络
  • 《Java Web程序设计》实验报告一 Java Web环境配置
  • Cypress与多语言后端集成指南
  • C++——类和对象的相关知识点
  • 复习笔记 31
  • RHCSA(2)
  • STM32--USART串口通信的应用(第一节串口通信的概念)
  • docker网络与数据持久化