管理 on 冯威的博客

再读《人件》

Tue, 21 Oct 2025 18:08:48 +0800

最近有点忙，更新得不太规律。其实也是这个号的初衷，写我自己想写的，没有想写的，就继续沉淀沉淀。

《人件》这本书是汤姆·德马尔科（Tom DeMarco）和蒂莫西·利斯特（Timothy Lister）于 1987 年共同创作的，主要探讨了软件开发领域中的人际关系和组织文化问题。这本书凭借其深入浅出的观点和独特的见解，已经成为软件行业的经典之作。

最近重读了这本书，下面是一些记录。

项目失败不只是技术问题

我们很容易犯一个错误，就像书里提到的一个故事：

一个人在黑漆漆的街道上丢了钥匙，却跑到灯光明亮的地方去寻找，因为那里“更容易看清”。

在软件项目开发中，技术问题就是那片“灯光明亮”的地方。它们是具象的、有逻辑的，容易被发现的，也可以通过调试、重构来解决。

而人的问题，比如：沟通不畅、团队内耗、士气低落等却是模糊的，不太容易发现。所以，我们会下意识回避它们，而把重心转移到更容易看到的技术问题当中。

这种例子非常多：

需求分析和客户之间沟通不畅，导致最终交付的功能并非客户所需。
团队成员之间因为信息不对称，对同一个需求的理解天差地别，导致开发和测试之间天天扯皮。
上下级之间缺乏信任，很简单的任务分配，可能会牵扯到多部门、多层级的资源协调。

这些问题，都是隐性的成本，最终会让项目延期、甚至失败。我们必须将注意力从技术领域转向团队的成员状态、沟通质量上。

做什么样的管理者？

在传统的管理思维中，管理者是“踢屁股”的人，负责分派任务、监督进度。这种模式下，管理者负责思考和决策，员工负责执行。

然而，对于脑力劳动者而言，这种模式早已失灵。创造力、解决复杂问题的能力，无法通过“踢屁股”来激发。如果你把自己归为码农（每天重复做增删改查），那么不在此列。

《人件》提供了一个新的视角：管理的本质不是督促大家去工作，而是为他们创造一个可以顺利工作的环境。

管理者应该像一个“园丁”，他的职责是创造一片肥沃的土壤，提供充足的阳光和水分，然后让植物（团队成员）自然茁壮地成长。

管理者的核心工作应该是：

移除障碍：无论是流程上，还是环境中的干扰，只要是阻碍团队高效工作的，都应该是管理者优先解决的问题。
保护团队：保护团队免受不必要的会议、随意的需求变更和来自组织内部的部门墙的干扰。
提供支持：提供必要的资源、信息和培训，让团队成员能够不断成长。

书中提到了两种截然不同的管理哲学：“西班牙理论”和“英国理论”。

西班牙理论：将员工的工作时间视为可压榨的资源，通过不断施压、鼓励无偿加班来换取产出。这种理论的信奉者，痴迷于“忙碌”的表象，认为“996”是福报。
英国理论：强调“聪明地工作”而非“辛苦地工作”，鼓励员工创新方法、提高效率，将焦点放在成果而非工作时长上。

作为管理者，我们需要时常反思，自己更倾向于哪一种？如果我们只是在不断地施加压力，那么结果往往是“工作得更快，而不是更好”，还有可能让不好的事情慢慢发生。

环境不可忽视

我们应该都听过心流状态。这是一种完全沉浸、物我两忘的状态，在这种状态下，工作会比较高效。

《强风吹拂》里的阿走就多次在跑步时出现心流状态。

他的专注力，有如一根紧绷的丝线，来到濒临断裂前的张力极限；他紧张又高昂的情绪，就像水盛满土钵，再多加一滴就会溢出钵缘。阿走就是保持着这样的精神状态，心无旁骛地向前跑。

但进入心流状态不容易，至少 15 分钟不被打扰才有可能，任何小的打扰，比如：一个电话、一个微信消息、一封邮件、同事的一个问题等，都会让我们从这种状态中跳出来，再想要进入就变得非常困难。

之前看过很多帖子抱怨白天各种会议，到了晚上，才能真正专注写代码，于是不得不加班。这种表面上的忙碌，实际上是效率低下的表现。

作为管理者，应该给团队成员创造一个好的工作环境：

减少不必要的会议：如果有每日站会，控制在 15 分钟内，切记不要发散了。其他会议尽量集中安排。
设立专注时间：每天有固定的专注时间可以集中精力工作，这个时间段内，尽量不被打扰，有问题可以先收集记录，在非专注时间进行沟通。
优化办公环境：为团队提供安静的工作区域，减少噪音干扰。

构建高效团队

一个优秀的开发者固然重要，但一个具有凝聚力的高效团队是可以做到 1+1＞2 的。如何构建一个高效的团队，这是管理者应该关注和思考的。

书中给出的答案是：找到正确的人，并给予他们成长的土壤。

这里正确的人，不仅仅指技术能力强的人，技术能力强是硬技能，是能做好本职工作的必要条件。除了硬技能，软技能也同样重要。

一个沟通能力强、乐于分享、能将团队氛围变得融洽的成员，其价值可能远超一个技术大牛。他们是团队的“催化剂”，正是这种催化剂才能让 1+1＞2 。

下面是一些建议：

1、在面试过程中，考察候选人的沟通、协作和问题解决能力。多问一些“你如何处理冲突”之类的问题。

2、将培训、学习、技术分享视为投资，而不是成本。鼓励员工成长，为他们提供挑战性的工作。

3、确保团队有一个清晰、共同的目标（OKR），而不是一堆零散的任务列表（KPI）。当个人目标和团队目标一致时，每个人就会有自驱力，而不被动接收任务。

4、每个团队中都可能存在一些“超级催化剂”。他们或许不是代码写得最好的、最快的，但他们能让整个团队的沟通更顺畅，氛围更融洽，帮助新人快速融入。这些人的贡献是隐性的，但对团队的健康至关重要，管理者需要能够慧眼识珠。

5、好的工作体验总是伴随着一定的挑战性，没人愿意每天做重复的事情。一味地做没有难度的工作会让人懈怠，而持续的挑战和成功后的成就感，是团队保持活力的关键。

总结

忙碌不等于有有效的产出，代码写的多也不意味着贡献就大。

管理者不能只是埋头赶路，就像越野跑，当你发现前后都没有人时，不一定是跑得最快或最慢，也可能是跑错了方向。

作为管理者，我们需要时常抬头看路，审视我们的管理行为是否真的在为团队创造价值，还是仅仅在制造“无效的忙碌”。

忙碌的陷阱

Mon, 23 Sep 2024 08:35:29 +0800

在一个公司中，当所有人都很「忙碌」时，常常被视为高效和生产力的象征，但如果项目还是不能按时上线、客户投诉比较多，满意度差，就需要思考：这种忙碌是真的高效吗？我们是不是陷入了忙碌的陷阱了呢？

2023 年总结（工作）

Thu, 19 Jan 2023 15:47:06 +0800

涂总，您好！提前祝您春节快乐。

组织架构的调整，使得我对产品的定位以及产品部门的职责变得非常清晰，前所未有的清晰。

最近一直在思考现有的问题和来年的规划，以邮件的形式跟涂总您分享下。

现状

1、目标一致性问题

目标如果不一致，所有的方向都很使劲，但会停留在原地。

2022 年上半年，项目的需求到不了我这里，而我们做的事情对项目的落地和增效又没有任何帮助。

项目组的需求得不到响应会有两个后果：

项目要想各种变通的方式来实现功能，花更长的时间；
变通的方式可能不是客户想要的方式，客户的体验差，这些日积月累的不好的体验可能就是日后投诉的根源。

甚至一些个别项目禁止使用二开，采用完全搭建的方式来实现，满足不了的地方需要借助一些第三方工具，这些工具都有学习成本，最终结果就是实施周期变长。

2、搭配问题

人无完人，我们需要充分利用每个人的长处，这样就可以拼成任正非所说的「高桶」。

元旦后，我被琪雅拉进了葛洲坝路桥的项目群，目的是要做技术支撑，经过几天的紧急问题处理和事后的分析复盘，发现了一些问题：

项目的顶层设计出现问题，交付给客户的是一个考评系统，互相交叉评价会产生大量的数据，没有提前预判；
技术上错误地使用数据库触发器，导致大量的表死锁，导致考评数据的生成不及时、客户使用过程中频繁出错；
不得不中途修改方案，这是项目实施大忌；
项目组成员非常幸苦，元旦假期加班、周末加班、工作日也每天晚上很晚还要响应客户的问题。

让本来不到一周就能顺利完成的事情，最终花了两周多的时间。

我在想，项目是不是应该分下类型，适合一线人员做项目经理的，就由一线人员担任；适合二线人员做项目经理的，那就应该让二线人员来担任？

每个人还是要在适合的位置，才能发光发热。

3、加减法问题

做加法的效果容易感知，比如多读了一本书，多记了一条笔记，那么很容易感觉到「积累」。

正是因为这种思想，产品上会不停地加功能，说好听点，产品功能非常丰富，说不好听的，臃肿，易用性差。

那产品应不应该加功能呢？答案是肯定的。产品团队肯定要按照节奏去迭代产品，但出发点是以项目落地增效为导向、以一线实施人员的使用痛点为导向、以最终用户的用户体验为导向。

以这些为导向，那产品的迭代就不完全是功能的叠加，而是：

解决用户实际问题的功能的增加；
某些功能使用体验的优化；
某些淘汰功能的弱化甚至删减。

4、复用问题

在代码架构中经常说要提升代码的复用性，目的就是为了提升效率。

在 2022 年了解到存在升级难、迁移难的问题。

葛洲坝事务系统花了很大精力做完，需要迁移到其他项目，有大量的改造工作，接近重做；
省厅的项目想要迁移到其他地方，也几乎不可能，或者说需要花费大量的精力；
江铃从版本 6 是升级到 7，前前后后花了好几个月。

很多项目应该是能盈利的，但因为升级和迁移的不顺畅，最终可能导致赚不了钱，甚至亏损。

我认为这一部分也应该作为产品团队 2023 年工作的重点。

2023 规划

目标清晰了，事情就好办了，剩下的就交给时间，静待花开。

根据涂总的的指示，我理解的产品部职责如下：

作为项目落地的强有力支撑；
项目资源不足，产品优先支持响应；
产品功能的迭代必须是能提升项目落地效率、提升用户体验。

目标明确，所以，2023 ，我非常有信心。

年前跟团队的每个人面谈时，我说我们应该往一个终极目标去努力，就是将 S2 交付给一线或二线之后，他们不会来找我们了，这样，我们可以做更重要的事情。

这个不找不是说部门之间有墙的屏蔽，而且他们自己在实施和运维的过程中碰到问题，可以自己找到答案。

当然，达到这个目标很难，可以先从下面的一些方面先入手：

收集一线人员的想法，他们跟客户直接接触，能更清楚客户的问题和习惯，以此来反推需求（已经跟一二线人员做了座谈）；
构建内部文档库，使用引导的方式进行让实施人员能自己找到各种问题的答案；
平台代码层优化，让每一个异常情况都是明确的，有路可寻的，运维阶段的问题排查可以大大提升效率；
项目代码的提交记录要和任务进行强绑定，为迁移和升级做好保障；
将项目运维过程中的很多重复性工作，工具化。

一定要打破「又不是不能用」这种错误的思想。

2022 年初，我在团队实行敏捷模式，大家觉得效果不错，沟通变多了，问题变少了。后来由于一些阻力没有继续。2023 年我将恢复敏捷模式，三周一个迭代，有序地进行平台功能的升级。

每个迭代的内容会和项目团队进行沟通确认，然后跟涂总您进行汇报，确保所做的事情都是有用的，有效的。

最后，我想说，不管经济形势怎么样，疫情是否反复，只要大家心是齐的，就不惧怕任何困难。

技术 Leader 怎样带跨一个团队？

Mon, 19 Jul 2021 08:05:00 +0800

网上很多分析大公司，小公司的文章，都会提到在大公司工作就是螺丝钉，岗位分的非常细，每个人把自己的专职工作做好就行；而在小公司需要每个人都是多面手，一岗多职。

这种观点我同意一半，在小公司中，某些阶段人手不足，确实需要每个人都做很多职责之外的事情，比如开发人员除了写代码，还需要测试、写需求文档、用户手册、运维等。但大公司再大，最终也会分解为很多小的团队，从团队最小的颗粒度来说，差别就没那么大了。小公司的团队想要走的更好，也需要能发挥每个人特长，职责清晰。

怎样带领一个技术团队

Mon, 03 Sep 2018 06:25:36 +0800

从2012年的Team Leader到现在负责公司的产品团队，在技术管理的道路上也走了6年的时间，看过不少管理的书，也经历过从零开始组建一个团队，和团队成员的更替。下面谈谈我自己的一些感受和理解。