❗我究竟在抱怨什么

只有一种人才有资格抱怨：在彻底绝望地告别之前，按一贯的标准，尽最大的努力做好每一件事的人。———— 我·自己·说的

大约一年前我是S项目的主程，同时也是架构设计的主要负责人，由于负责O项目的前期调研工作和后续设计、开发任务，半年前我移交了所有的S项目的工程给一名资深的程序员C（6-7年的编程经验，但没有计算机相关的教育经历），仅作为架构和实现的咨询人员参与S项目。

在我移交项目之时，相关工程的测试覆盖率在80%左右，所有工程都有着相对应的CI设施，能够在每次代码推送后自动构建好可供部署的二方库。在我移交项目之后，我仍会在设计、关键评审、代码review等方面提供帮助，但并不参与各方的联调，也不对后续修改负责。

大概三周前，程序员C离职，其离职原因是组长对他的指责，将相关工作交接给了我的组长，此后S项目由组长负责。

事情发生在组长出差到客户现场支持时，这是本季度最重要的项目，我们所有人不得不放弃其他工作对此项目进行支持，我也从O项目被调到S项目，为客户现场需求提供支持。期间我发现，原有的单元测试已经无法运行，旧的工程CI大部分失效，新的工程既没有单元测试和CI，代码质量也不尽如人意，我不得不在大量的代码片段中找到我需要的配置，我还发现了多个C在离职时声称已经完成、并测试过的功能实际上未经测试、无法运行，甚至有些功能根本没有实现。

于是，在前两天组长对我定位问题的指手画脚中，我爆发了。我不想讨论其中细节，因为这只是一个导火索，而下面我将讨论根本原因。

从个人发展的角度：一致性缺失

组长很忙，我将成为顶缸的老实人。组长不止负责S项目，还有其他A、B、C、D等等等等项目、沟通、汇报等任务，因此从程序员C离职以来，我就知道再也不可能像之前那样从S项目中抽身出来，全身心地投入团队和我的未来——O项目。于是，就像这次一样，在组长出差的时候，我将承受巨大的上下文转换的压力和代价，在非常短的时间内响应项目里的需求、咨询、问题，同时又要保证O项目的进度。这是因为O项目所采取的理念和技术都是很前沿的，有太多需要确认、调研、测试的内容，而我是唯一一个能够做到这些的人。而S项目，留给我的是一个我无法掌控的泥潭，我没有办法在如此有限的时间和精力投入下将S项目带回原来的正轨，同时我认为组长也不能（因为他太忙了），那么我的精力就又会被S项目所分散，越陷越深，直到最后技术债务破产。但在这之前，我感受到的是深深的无力感和失望：我既不能将S项目做好（下面我将解释除了精力以外，还有别的原因），也缺乏在O项目投入的一致性。

从团队的角度：这不是一个具有”工程师文化”的团队

缺乏质量意识：忙是一个客观因素，而“能跑就行”则是最让我感到失望的主观因素。由于S项目的研发经理们和程序员们对于代码的态度都是“能跑就行”，这意味着在我组的工作无论多么优秀，都将受到上下游代码质量和调试时间的影响。这一态度从我入职以来就从未改变，我所能做的只有尽量早地提供我能提供的一切支持，并督促他们尽早尽快地进行联调，这也是我将本组的自动化工作和代码质量作为重要工作内容的原因。但由于目前上下游所在组的资深程序员也有缺口，低级的校招生并不能按时、保质地完成编码任务，常常匆忙中进入联调阶段，由此联调阶段的时间被拉长，bug率显著上升，导致我组负责此项目的人需要投入更多的低价值工作，来完成项目。我个人称之为：被拖累的部分。这一情况的发生，我认为组长们需要负主责，而下面的程序员也难辞其咎。

有一次我在一个月之前就提供了开发并测试完成的服务镜像，但到最后一天才被告知其无法启动容器，我只能紧急加班为其解决。事后证明是其没有阅读相关文档，但此文档我已经在提供容器时交付。

团队成员之间缺乏信任：团队对于程序员（技术人员）也缺乏尊重，自以为是，常常有产品、组长、研发经理等人在不了解技术细节的情况下，对程序员的工作进行指手画脚，甚至是指责。这一情况将严重打击程序员的积极性，加强了“能跑就行”的思想，又因为这种思想导致了质量问题，从而引发信任危机，最终导致了团队的恶性循环。我将此归咎于“工资更高”的人的傲慢、不尊重，以及“工资更低”的人的自卑、不自信。我并不是在说某个或某群人的性格有缺陷，这是一个团队文化/士气问题，一个乐观开朗的人在一群悲伤的人中也会被影响，人群的力量是隐秘但巨大的。

有一次产品负责人Z要求运维保存所有模型服务的日志，并告知“这就是用户的需求”。运维为此任务拟引入Clickhouse以及一整套查询系统，在我的强烈要求下，产品才解释用户的需求是保留模型服务的请求日志，而这一功能是已经通过边车代理实现的。产品负责人Z并不清楚另一个产品经理已经设计了这一功能，并且在下个版本就能上线。

自己为是的领导风格：我对“外行指导内行”、“领导一句话，累死跑腿的”、“将帅无能，累死三军”的现状感到失望、无助和愤怒。似乎领导讲两句，下属照做即可，一切尽在掌握中。但实际上，领导不相信你能做好，于是又把上下文（context）藏着掖着，仿佛告诉了你天就塌了，或者花这些时间在给你解释前因后果纯属浪费，但事实是领导自己也没想好怎么做，也是脚踩西瓜皮滑到哪算哪。于是大家东忙西忙，由于缺少上下文成为无头苍蝇，与之对应的，是对真正高价值目标的持续性的投入的缺失。与其上的一致性缺失所对应。

包括这次爆发也是一次令人愤怒的指手画脚

从集团的角度：缺少数据基因，无法给团队带来成长

集团的传统业务是安全乙方，其思考的是如何在不影响用户业务的情况下，分析用户业务，为用户提供安全加固的服务并收取费用。而我们想做的是接管用户的某个数据使用流程，通过此方式保护用户的数据，使其满足某些合规要求，或在合规要求下开展之前无法开展的业务。二者从销售的角度上讲，最大的不同就在于从以前的卖盒子、卖小软件，变成了卖整个服务集群、卖一整个处理系统，其规模、成本与销售难度的对比就像是蚂蚁与大象。而集团内部的人仍然会使用传统的安全乙方思维来看待我们的项目、产品，等于用篮球运动员的标准评价桌球运动员，那丁俊晖肯定不能在姚明头上暴扣。而其积重难返，我们人微言轻，无法改变这一现状。

而同时，由于集团效益，也没有HC重新招聘人员维护S项目，这将加剧S项目技术债务的积累，与我上文提到的越陷越深、拖垮团队形成有机结合，是典型的项目恶性循环。

由此，我觉得S项目在集团的前途是暗淡的，被S项目拖累的团队的前途亦是暗淡的。

总结

综上，我抱怨的实际上是不负责任、推诿、不作为、得过且过的思想，对工程问题异想天开、自以为是的幼稚病，以及缺少相关基因，无法提供土壤的集团环境。

就我个人而言，为了实现自我价值与身心健康，为了大团队能够进一步往下走，我不愿，不想，不支持再将自己的精力投入在S项目上。

但基于我的职业操守，在我彻底绝望告别之前。我将尽我最大的努力做好我应该做的，按照我一贯要求自己的标准。