我欺骗了CTO，但拯救了公司（附HN热评）

原文 The One Where I Lie To The CTO https://grumpyolddev.com/post/the-one-where-i-lie-to-the-cto/

这是几年前的事了。我刚开始我的职业生涯，我爸跟我说，要想做好工作，有时候需要不顾老板的意见去做事。他表达的其实是，可以让你的老板因为你而成功和满意，也可以选择把每一个决策都交给老板决定，但结果往往是大家都不开心也不成功。

当时我在一家财富 500 强公司工作，我们的 CTO 接了个他有私交的重要客户的一重大项目。他还决定把项目中的一个关键部分外包给一家大型技术服务公司，这家公司声称他们的一款产品可以帮我们完成大部分繁重工作。

在我职业生涯中常见的一幕再次上演：供应商所说的「产品」，实际上只是勉强能称之为产品的东西，勉强能满足我们的需要，需要大量定制后才勉强能用。显然，通过对他们的「产品」进行定制，我们巧妙地集供应商软件的缺点与定制软件的所有缺点于一身。我们还无意中创造了最糟糕的主意：一个僵硬的供应商软件，被迫做它本不应做的事，同时还从他们的主产品代码库中分叉出来 - 一旦供应商认识到维护成本过高，这个产品迟早会被淘汰。我们为此互相埋怨，认为这是一个极其糟糕的想法，尤其是考虑到供应商一贯不按时交付的记录。

由于 CTO 的直接下属每年都在变动，每次关于这个项目的会议上，即便没人真的认为是个好主意，大家还是会说「好主意，老板」。

或者说，这根本不是个好主意，而是一个糟糕的主意。

除此之外，我们还得在内部为项目的其他部分进行大量开发，已经够多挑战了。项目在夏天的截止日期再三被推迟，供应商却一再保证他们的交付物马上就好，可以集成进产品里，赶上十月的发布。然而，对于除 CTO 外的所有人来说，项目正愈发明显陷入困境中。到了八月，供应商交付了他们的「产品」，我们开始了艰难的整合进程。

九月，我们遇到了一个关键性错误。供应商的产品将每一笔客户交易都存储为一个 json 记录，并归档于一个庞大的 json 文件中。随着测试数据的不断积累，产品的性能逐渐下降。每多一笔交易，都需要读取整个 json 文档并在其末尾增加一条新的记录。供应商声称他们可以通过给交易字段建立索引来解决这个问题，这个办法起初似乎有用，直到我们遇到了第二个问题。

他们选用的数据库是 MongoDB，当时 MongoDB 对每个文档的大小限制是 16MB。因此，到了十月份，当转换团队开始导入真实客户数据时，我们开始触碰到这个 16MB 的上限，问题变得严重起来。有人做了个决定，对客户隐藏这一限制，并推迟一个月上线，同时秘密启动一个项目来替换供应商的集成，于是他们也被蒙在鼓里。这样，我们同时对客户和我们重视的技术合作伙伴不实。

当时的暴躁老研发（小编注：此暴躁老研发即作者本人）其实还是个充满热情的年轻研发，他迅速组建了团队来开发替代方案。供应商的项目团队有 70 人，而暴躁年轻研发只安排了 3 人进行替代开发：一人负责数据库设计，一人负责开发数据库后端接口，还有一人负责开发业务逻辑和网络服务。

客户被告知在一月份会一个新版本可以进行测试，这个版本将解决他们在最初上线时遇到的一些重大问题。但是，我们没有告诉他们，实际上我们正在彻底重写整个核心系统，而且只用了不到两个月完成。考虑到原项目花了一年多的时间才上线，这次只用三个人，在假日期间完成（可以脑补一下接下来的剧情）。

到了十二月中旬，参与项目的每个人都被强制要求（不是请求）在假日期间加班。

需要指出的是，我们大多数人在过去六个月中已经持续工作了 60-80 小时/周，仅仅是为了赶上原定的上线日期。

每个人都已经精疲力尽了。

如果你正在读这段话，而且你不是一个专注于保证工作交付的人的技术人员，你可能会觉得这太可怕了，是时候考虑辞职了。你是对的。但是，我们这些真正热爱软件开发的人，有时会有种摇滚明星的感觉。可能花了几个月甚至几年时间来准备这个项目，而上线的那一天，就像是最后的汇报演出。你想要按时完成上线。这有点像剧院里的演员：演出必须进行！但同时，当你的辛劳成果首次面对真实用户，感受到那种「这是我做的！」的激动时刻，你也想体验一下摇滚明星的感觉。大家喜欢我的作品，我完成了不可能完成的任务。软件的发布，对于内向者来说，就像是一场现场演出。

这时候，圣诞节就要到了。团队在一个月的工作中构建出了替代软件。虽然还有一些功能需要完善，但这些开发者都很聪明，他们一直在完成他们的任务，我相信只要他们不过劳，我们能按时完成测试。

因此，当 CTO 告诉我假期被取消时，我只好答应了。

接下来是我一生中最自豪的时刻之一，我想到了父亲的话 - 关于无视老板。我对我的三名员工说「你们休息一周，这里的事情交给我」。每天早上我都会参加与 CTO 的强制项目进度会议，并对他撒谎。

• 「团队正在努力工作。今天我们完成了第 73 个 milestone」
• 「团队昨天取得了不错的进展，我们又完成了一个网络服务」

每一天我都会报告我们正在忙碌，而这些其实都是我们一个月前就已经完成的任务。

一周后，我的团队成员精神饱满地返工了。

一月，我们按期完成了所有任务，顺利上线，短暂地成为了摇滚明星。或许我们更像是 Herman's Hermits （小编注：赫尔曼的隐士们，英国摇滚乐队） 而不是 The Beatles （小编注：披头士，英国摇滚乐队），仍旧，让人感觉很棒。

这就是我欺骗了 CTO，但拯救了公司的故事。

---

Hacker News 评论精选

翻译本文不是希望推崇公司强制员工加班，剥夺宝贵假期，特意摘录了几条 Hacker News 上此文的评论：https://news.ycombinator.com/item?id=40304453

motbus3

如果你是那种取消假期以保证工作交付的人，我想根据自己的经验劝你一句：不要这么做。

我懂，尤其是当你因为辛勤工作获得表扬时，停下来似乎很难，但你最终会为此感到后悔。

如果你的工作是在一个依靠你牺牲假期和休假来推销产品的公司，你实际上是在助长我们今天所面对的问题世界。如果很多人都这么做，那么将有更多人需要这么做。如果没有人这样做，并认为这种要求是荒谬的（确实是这样），那么就没有人会被迫这样做，公司就不得不进行真正的成本估算，即使这可能会损害你最喜欢的 CEO 的利益。

roenxi

这个故事中的每个部分都显得混乱不堪，包括主人公的行为方式。一个团队领导给员工随意放假并对此撒谎是绝对不允许的，这种行为已经触及了公司可能将其解雇的边缘。事实上，如果这种行为导致他被解雇，我也不会感到意外。虽然上层管理显得非常混乱，他可能侥幸免于被解雇并意外获得表彰；这似乎正是他所处环境的一种体现。

给新任团队领导的一个忠告：这里没有任何值得自豪的地方，更明智的做法是强烈反对团队加班，并坚持要求供应商符合合理的标准，或者重新考虑项目范围，以适应正常的工作周时间表。试图应对这种状况只会无谓地耗尽团队的精力，甚至可能导致团队成员在没有任何好处的情况下失去工作。

除非我真的迫于生计不得不工作，否则作为一个团队领导，有责任保护团队成员的合理工作时间，抵御那些不合理的要求。这是一个值得你坚持到底，即使可能因此被解雇，也绝不撒谎的原则。

joshstrange

拯救了谁？

那个交付低劣产品的不良供应商？

那个被一群唯唯诺诺的人围绕、对公司内发生的事毫无所知的 CTO？

那些被压榨到极限的开发者们，虽然给了他们一周假期，又如何呢？

还是那个为了满足一个毫不在乎他们的公司设定的任意截止日期而对所有人撒谎的主角？

这个故事的每一个情节都让我感到不爽。我工作勤奋，偶尔也会为了确保客户发布顺利而加班，但这个故事完全是疯狂的体现。我之所以愿意偶尔加班，是因为我与老板的关系以及我知道我可以随时向他们坦诚。事实上，这是建立无责备文化的核心：只有当每个人都坦诚相对时，我们才能拥有这样的文化。

为了达到一个无知的 CTO 设的截止日期而疯狂撒谎，这简直不可理喻。如果你发现自己处于这样的境地，那么最好赶紧离开，找一个更好的工作环境。