## 思考与感悟 我是在看完 [[Spencer Johnson|斯宾塞·约翰逊]] 的另一本书，[[谁动了我的奶酪]] 之后，在微信读书中顺手刷到的这本书。当时正好觉得时间比较碎片，感觉这本书的书名 “一分钟管理” 看起来很简短，于是就去读了。读完之后我觉得：哇塞。 ### 最大的感悟：一分钟称赞 其实，如果没有我的几段实习以及领导团队的经历，我其实并不会对这样一本书有很大的体悟。我在上一家公司工作的时候，遇见过一个瑞典人，感觉他的能力并不太行。怎么不太行呢？他写代码就是整天坐在 GPT 面前，把 GPT 给的东西原封不动地 copy paste 到代码库里。而这样的代码，根本并不遵循代码库的 linter rules，同时也有很多很奇怪的错误。但是他似乎并不在意，觉得能写出来就好了。我看到最离谱的案例大概有比如把一个 Enum 转换成字符串再和字符串进行比较（如果是这样，你要 Enum 干什么呢？），以及比如 throw 的时候 throw 的不是 Exception，而是一个 String。——说实话，如果不是见到这个老哥这么写，我都不知道这居然是允许的。再加上，这个老哥因为生长环境的原因，在当时的我的眼里看起来，非常地”病娇“，一生病就是好几周不来，还有产假等，一周就上那么一两天班。对于我一个整天来公司写代码的人来说，当时的我觉得和他合作简直是一个噩梦。 于是我是怎么做的呢？我就趁他不在的时候，直接把这些错误的代码修了。我是这么想的：反正他一周只来那么一天，而且可能大部分的时间还在开开会，或者是玩玩他的 Steam Deck、和他女朋友打打电话等，最终能写代码的时间差不多也就是 1 - 2 小时。这 1 - 2 小时，我要再花时间去认真教他，多费事呢？于是我就改了。改完之后，我没有料到的一件事是他意见很大，他认为我 ”改他的代码“。所以，关系有那么一些紧张。 直到我和我父亲交流这件事。他问了我一个问题：”XX，你代码写的不错，这是不错；可是你有没有想过一个问题，你的同事和你在一起写代码，他对他的工作有任何的成就感吗？如果他没有成就感，他每天写的代码被你当作是垃圾，你们怎么能在一起愉快地工作呢？”——这个问题引起了我的深思。我一直以为，代码是一个很理性地东西，对的代码就是对的代码，错的代码就是错的代码；代码也有感性的层面，那是对于不同设计的感受，什么样的 API 设计是好的，什么样的 API 设计是不好的，我们应该运用什么样的设计哲学——但是我的同事显然没有 sophisticated 到能理解这样的不同设计哲学之间的好坏的程度。而我忽略的点在于，虽然代码是理性的，但是和你一起合作的写代码的人未必是——你在很多程度上需要去照顾好他们的情绪，努力给他们构建一个友好的工作环境。唯有这样，你才能构建一个好的组织去做这样的事情。 加深这件事对我影响的是另外一件事。因为和同事合作的不愉快，我和老板聊了一次。老板说：“你要理解他的难处。”我初听到这句话有些不乐意，他如此病娇，能有什么难处呢？老板进一步说：“我作为一个老板，我的职责是照顾好我的每一个员工，让他们尽可能在他们的职位上发挥到最大的价值。”我想了想，逐渐有了更多的一份感激。如果不是因为老板对我的信任，我作为一个实习生，不可能有机会去主导他们 App 的完整重写——而这样一种信任，其实不是针对我一个人的，而是对于每一个人的。 当然，如果我们理性地去看待这样一个问题，其实存在另外一种解读的空间。因为瑞典的劳动法严重偏向被雇佣者（这在很多人眼里是好的），所以裁员的成本很高。一个人一旦被雇佣，老板所面临的问题就不再是我是否应该把不合格地人裁撤、去换上更合格的人；相反，而是去思考：我怎么提升他的工作效率，怎么让他在我们的公司中发挥最大的价值。——这也成了为什么欧盟被创投圈诟病的一大原因，因为在创业的叙事中，另外一个模式更为显著：“一个 B Player 对整个团队所带来的伤害远不是一个 A Player 所能弥补的。”——就连我自己带团队的时候，我也在强调 [[0002 平庸的滑坡谬误|平庸的滑坡谬误]]，即宁缺毋滥，一定要最精英的人。 不过，抛开这件事的对错不谈，抛开这件事的不同角度不谈——我父亲、我老板，以及这本书所给我的启示无论在任何情况下都是受用的。在和别人一通共事的时候，事情做好是一方面，但是同样重要的另外一方面是让和你一起合作的人舒服，让他们在工作中找到成就感、有获得感。我觉得这是这本书对我最大的启发之一。 ### 一分钟更正：与传统智慧不一样 看这部分的时候，我想到了 [[Influence - The Psychology of Persuasion]]，因为那本书里提到了很多 “Trick” 别人的心理学小技巧。而先抑后扬，如这本书所强调的一样，似乎比先扬后抑，有更好的效果。然而这个与我们的传统智慧（Conventional Wisdom）其实是不一样的。仔细想想，这样似乎更有道理。如果不是因为看到了这本书里这么说，我可能在要和一个人说他做事情做的不对的时候，会先努力想一个点夸赞对方一下，然后再批评。 ### 一分钟目标：沟通的障碍 我在最开始带团队做项目，以及后来做 Startup 的时候，我意识到了一个很大的问题。这个问题就是：我说 A，团队成员也听到了 A，但是成员最终给我的并不是 A——我意识到了存在这样的一个沟通的障碍与鸿沟。我觉得这样提出的 “简单、清晰的一分钟能看明白的任务” 其实是一个不错的思路，可以考虑等后面有机会（无论是我自己接受任务，还是分配出去任务）的时候尝试实践、落实一下。当然，我觉得大概率可能会需要更多的沟通。 我觉得这里其实强调的观点与 [[Measure What Matters|OKR]] 很像。OKR 的书我还没来得及读，等读完之后回来看看能不能回来 Update 一下这个点。如果相似的话，这大概可以算得上是 OKR 的鼻祖了？ #todo ## 摘录与笔记 # 寻觅 > 似乎世界上的绝大多数经理人都坚持自己那一套，而他们最感兴趣的不是结果就是人。只看重结果的经理人总被认为是“专制的”，而只重视人的常常被誉为“民主的”。 # 新一分钟经理人 > “来看看这个，”经理人指着电脑说，“我把这条实用的真理设成屏保程序，时时提醒自己。” > “所以，”年轻人说，“帮助别人获得良好的自我感觉就是提高效率的关键。” # 第一个诀窍：一分钟目标 > “是的，”泰莉莎说，“设定一分钟目标是第一个诀窍，也是一分钟管理的基础。你瞧，在大多数公司中，如果你问老板某个员工在做什么，再去询问员工本人，往往会得到两种截然不同的回答。实际上，在我以前工作过的一些公司里，我自己和我的上司对工作任务的理解只是偶尔一致，那仅仅是巧合而已。这样一来，我就会因为没有做某些事陷入麻烦，而事实上，我从没想到这些事是我该做的。” # 第二个诀窍：一分钟称赞 > “实际上并不会，”保罗回答道，“记住，并不是非得对某个人称赞很长时间他才知道你关心、关注他。其实，有效的称赞常常连一分钟都用不了。” “这就是叫它‘一分钟称赞’的原因。”年轻人说。 > “也不是，”保罗回答道，“只有你刚到这里工作，或是刚刚接手了一个新项目或新职位的时候，他才会这样做。等一切轻车熟路后你就知道他对你有信心，因为你不会经常看见他了。” “真的？在受到关注后这样不会让人很失落吗？” # 第三个诀窍：一分钟更正 > “然后，他分两步来进行一分钟更正。前半分钟他把视点集中在所犯的错误上，后半分钟则在我本人身上。” > 乔恩继续说：“更正的后半分钟，他明确地告诉我，我的实际能力其实比这强得多，他对我有信心也很信任我。他说特别期待再跟我碰面——只要不是因为犯了同样的错误。” # 一分钟目标为什么有效 > “对，”一分钟经理人说，“我相信大部分经理人都下意识假设下属们知道应该完成什么工作。但我在设定目标的时候，从不做任何假设。 > “道理很简单，人们行动的最大动力来自结果的反馈，大家都想知道自己干得怎么样。实际上，套用一句老话：‘反馈是成功的前奏。’反馈让我们不断地前进。但可惜的是，虽然大多数经理人已经意识到这一点，但他们通常却制订另一套保龄球规则。 > 看到监督者举起两根手指，示意撞倒了两个木瓶。但大多数经理人是不是会说你撞倒了两个木瓶呢？ > “如果你在工作表现评估表上给每个下属都打了高分，你想你的上司会怎么看你？” “他们会认为我是个好糊弄的人，根本分不清工作表现的优劣。” # 一分钟称赞为什么有效 > 年轻人说：“那么，一开始最关键的是，发现他们基本上算是做对的事情，直到他们真正做对了。” # 一分钟更正为什么有效 > “谁在乎真的假的。”经理人笑了起来。“话说回来，”他补充道，“我知道结局会是这样。但反过来，先严厉指出客观上的错误行为，再肯定并鼓励他们，就能收到很好的效果。”