大家好，见字如唔，我是小毕。

转眼间，2024年已进入尾声，相对于22年新系统建设中的充实加班生活，23年多项目并行启动及系统初期无尽的优化改造和缺陷修复，24年显得平和了许多，以至于让我觉得今年过的格外的快，能回想到的事情不多。但我仍想好好记录一番，静下心来对这一年工作和生活做下总结。

想一想，好像从高中毕业便没正八经的写一篇文章了，再加上本身文学水平就欠佳，词藻褴褛，敬请见谅。

一、工作篇：

同事：由整个市场和公司现状影响，今年团队里并没有增加新同事，反而有几位同事或是离职，或是去其他项目打工了。唉，这也是市场使然，不已谁的意志为转移。在此，还是希望曾经一起奋斗过的同事，无论现在身在何处，都能扛过这段”寒冬”,以后能过的越来越好。

目前团队里的同事，今年最值得一提的就是我的老舍友现同事胖哥，从毕业到现在马上十年了，历经九九八十一难，终于不再是孤家寡人，在十一完成了一件人生大事。略感遗憾的是，当天中午娃突然发烧了，参加完婚礼便急匆匆带孩子回老家了。让胖哥晚上逃过了一劫。毕竟这可是为数不多可以肆意“践踏”、“蹂躏”他的机会了。

哦对了，不得不提，今年不知不觉间成了苏总监的“狗腿子”，对此我之前深表诧异，为何事情会一步步沦落到如此境地。后来经过一顿分析，也便释然了。毕竟能把《PUA方法论》、《如何欺负老实人》、《一言不合拉黑法》、《降龙十八扇》、《闪现你身后并给你一记八极崩》这种物理斗技加灵魂攻击融为一体的人，实在不是一般人能抵御的了的。

团队：这个话题的篇幅会偏长一点。也算是因为这两年经历感悟比较多吧。如有不对，还请见谅。

之前一段时间一直在思考团队的建设、流程、制度相关资料。因为我发现很多领导者都热衷于建立一套趋于完美流程制度，再通过一定的工具如jira，禅道，teambition运作起来，以达到一种强大的掌控感。并试图以此来减少对某个具体下属的依赖，提高团队稳定性。但往往最终都达不到效果。对此我还是想自己的角度说一下看法。

管理者:流程制度的建设一般都是由管理者主动发起，下属想的肯定是越自由越好，不希望被各种条条框框束缚住。但根据熵增定律：事物总是朝着混乱的的状态不断发展。所以无论任何团队、或系统，流程制度是必不可少的，否则总有一天会崩溃。

就软件交付行业来说，好像已有了标准化的流程指导，如需求、设计、研发、单元测试、系统测试、版本检查、代码检查、验收测试、投产、运维。各流程环节的执行人，任务，交付物。貌似都已经很明了。我们所需要的，只是在流程里面不断的补充细节就可以了。但事实好像并不是如此。

管理者不断追加的流程制度经常会让执行者苦不堪言。这主要是因为：规则的发布者往往不是规则的执行者。发布一项要求很简单，但执行起来可不是那么容易了，若执行者无法认知要求的必要性，那极有可能变成了形式主义，白白浪费时间。

再有，管理者总会带点理想主义，总会朝着“这个要求很简单”，“这个要求不应该出问题”的想法前行，尤其是对于从来没落地执行过的管理者，这种现象尤为严重。但遗憾的是，事情往往事与愿违，事件齐发。于是乎，这个流程最大的价值便成了出问题后的一个借口：我考虑过这些风险，而且指定了流程规范（我是优秀的），只是他们没按标准完成（他们太差了）。

举个例子：

版本管理永远是软件公司关注的头等大事，虽然三令五申，但总会不断出问题，为什么会这样呢，大家可以听一个故事。

从前有一位善良的项目经理，组建了一支20+人的团队，他深知领导对版本问题的零容忍度，于是在团队建设初期，便请来了一名资深架构大佬，花了一个小时，给团队制定了一套无可挑剔的版本管理制度。并进行培训宣讲，经过一周的实践后，架构大佬出了一份版本流程场景模拟题，全体团队成员参与，全体通过，于是他对项目经理说道:"很好，大家都很优秀，按流程执行就好，以后不会出版本问题了"，项目经理听后很开心，一面感叹架构师的强大，一面为自己明智的举措而自得。

于是，项目经理对开发说道，大家都各自拉分支开发吧，一个月以后按流程合版提测。

终于，到了见证奇迹的时刻。项目经理信心满满的找来测试小倩。悄悄对她说：“好好测，争取下周上线哦！”。

测试小倩随意点了一个按钮，咦？阻断了? 再查？版本问题！退回！

项目经理慌了，紧急召开全体会议。在会议上，项目经理怒吼着："你们不都知道流程规范吗，为什么不执行，我辣么相信你们！"

这时，老实的小A说道："领导对不起，我知道流程规范，只是并行工作太多了，我有次本地切到其他分支了，我以为还是这个分支，提错了";项目经理叹了一口气。

活泼的小B说道："领导对不起，我有天请假了，就把工作交给运维的小周来帮忙开发，他没有参加过咱的版本培训，所以弄错了，这可怨不了我哦"，项目经理有点头晕。

帅气的小C又说道："领导对不起，我知道流程规范，也没弄错分支，只是有天我刚开发完代码，到下班点了，那天晚上我要和认识三天的网友见面，她照片长得像林志玲，声音也像。据我的判断，她就是林志玲"。所以忘记提代码就下班了。由于前一天晚上过于美好，结果我第二天也忘记了这茬，代码丢了。"项目经理听完哭了。

卑微的小D这时说道："领导对不起，我之前一直用的svn，不太懂git，代码合错了",项目经理问："可是当时培训时候让大家有疑问就提时候，你并没有发言呀",小D回："当时我看都没人提问题，人家也没好意思问", 项目经理又问：“但后来模拟考试时候你考的也没错啊，那个考试还更复杂，这个怎么就会合错了呢？”小D害羞道："哎呦~，人家当时是偷偷抄的毕老师的作业嘛"; 项目经理听完，两眼一黑，径直倒在了地上。

后来听说，他被救护车抬走的时候，嘴里还在念叨着："为什么这么简单的事情，你们都做不好";

虽然有部分虚构的场景，但这个故事却是在各个团队普遍存在的。由于成员的大意、马虎、沟通不畅、似懂非懂、知行不一，往往会导致实际执行结果与期望大相径庭。因此管理只追求于形式上的制度是不行的。

这时候，有一部分管理者会说：那就在流程环节上加检查，加复核产出物，或提高考核标准。其实我蛮反感这种说法的。若管理者只提要求，而不分析方式方法、不考虑成本、风险、人性、没有一定方法论支撑，那无论加多少流程，都只是为自己失败找的借口，最终的结果，只是无能狂怒罢了。

理解这段话很简单，如果加检查就能解决问题，那如何保证检查人不会应付了事呢，那是否在加一个检查的产出物，以及“检查的检查“环节，这样来想便成了无休止的流程了。说到底，制度能否有效实施，最根本还是要靠参与人本身的品质和认知。流程里要做的，只是在合适的节点，根据风险和成本代价来决定是否追加防御性环节而已。

为什么这么说，其实刚才项目经理的故事还远远没有结束，接下来我会根据自身经历继续讲下去。

当项目经理发现团队成员无法完全按版本管理制度执行时。便有了两种方案：第一种，将代码提交权限回收，只允许特定的人员来进行统一管理。就像现在很多大厂都配备的“配置管理员角色”,统一进行合版、分流、配置等任务。这种模式本身是没问题的，但考虑只有十几二十人的团队，抽出一人专门负责，且为保证原则不被打破，需要天天陪着各个研发加班，必须增加b角。成本代价实在是不小。实施一段时间便不得不终止了。

于是采用了第二种方案：那便是如之前说的，增加版本检查环节。我们要求研发人员在需求切流合版完成后，必须进行各环境代码差异检查，并进行截图确认。确认每行差异代码都是正常的变更，没有多合或漏合代码的问题。

这便是之前说的，在流程里增加检查环节，以及要求检查产出物。

这样问题便可解决吗，其实并没有。

很多高级开发人员对版本使用都很熟悉，并且之前也没出过错误。他们认为这种“傻瓜式的检查”，是对他们高级工程师职位的一种亵渎。因此，虽增加了这个流程，一般也就是简单看一眼，草草截几个图片应付了事。变成了形式主义。

直到有一天，有个高级开发真的犯了一个低级版本失误，给自身和团队带来了不小的损失，处于自责和醒悟，他才真正的理解了这个环节的必要性。

其实管理者和执行者的矛盾在于，执行者认为自己永远不会犯低级错误，或很少会出错，因此增加如此沉重且无技术含量的任务实在没有必要。而管理者考虑的是，若一个人一年出一次错，那对于一个二十个人的团队，那几乎便成了每次变更必会出的问题，量变会引起质变的。那这个检查，便是最高优先级的环节了。

但是话说回来，并不是犯错就一定会成长的，最底层还是要看相关人的品质、价值观。记得有次和同事喝酒时他和我说，有人劝诫他做事不用认真，无论是否是自己的事情，是否自己的错误，能推就推出去，问题总会有人来解决的，并因此变得很闲而洋洋自得。对此我当时并没有发表看法，只是让他遵从内心静观其变，时间会验证一切。

其实那人说的也并不完全不对，问题的确总会有人来解决。但是谁的问题，应该由谁负责解决，这是原则性问题。对那人来说，松散舒适得过且过的生活才是他的价值观，而责任、求知、成长却无关紧要。这种价值观的选手其实很危险，一定会被边缘化直至淘汰。其实无论管理者还是执行者，在职场一定要保证自己有核心“抓手”，耍小聪明，大小事都往外推脱交给其他人做的，最终大多会自我毁灭。

所以，一个团队能否高效稳定发展，还是以每个参与者自身的价值观品质为底座。经验、能力，以及教训为两翼一步步成长起来，最终形成的最佳实践。管理者最重要的，还是根据人的能力、意愿，将人安排在合适的位置。对上要做到谦虚、诚实、展现自我价值。对下要识别、认可，促使成长。自身要能够持续学习、勇于承担，做一个有原则、有边界、有格局的人。

最后再简单分享我个人对人员的识别方法。按照能力意愿矩阵分为四类选手。分别是高能力高意愿型、高能力低意愿型、低能力低意愿型、低能力高意愿型。

第一类高能力高意愿型选手。对这类选手，应该在风险可控范围内，逐步放权，多给予高层次的工作内容，并给与自主和决定权。这样才能最大程度促其成长，这对个人，对团队都是一种互利双赢的事情。

第二类高能力低意愿型选手。这类选手我认为是占比最多的。他们一般都热衷于做低于自己能力边界内的事情。即:只做会做的事，只做自己负责的事。这类人用起来实际很顺手，因为安排的工作都是低于他的能力，只要有责任心，一般不会有大问题。

第三类低能力低意愿型选手。很多公司不想要这类选手，但受成本等因素限制，也不能完全pass掉。如果团队需要有人处理一些边缘的、低风险、低难度工作，这类选手是个不错的选择。

第四类低能力高意愿型选手。这类选手实际才是团队里最让人头疼的。用三个词来形容，就是“眼高手低”、“盲目自信”、“不自知”。这类选手往往会高估自己的能力,拥有低自尊型人格，出问题永远找别人的原因，且过于表现没有边界感。对于这类选手，如果能认清自身的问题还好，否则，还是应尽量的远离。

好了，对团队管理的总结就先到这。最后还是对项目组小伙伴一点建议。虽然对于管理者来说，想的是通过流程建设，通过知识库沉淀，逐步降低对每个成员的依赖，以此防止成员离职带来的风险。但对成员来说，最好还是要有自我学习成长意识，形成自己的职业抓手，既能防止被“优化”掉，也能为以后跳入新职场环境增加选择权。

二、技术篇:

回想起来，这两年工作重心一直在项目团队管理上，再加上前两年的紧促模式，对技术上的探索着实是少了些。因今年自主时间比较多，便抽时间看了几本技术书籍，结合项目组实际遇到过的问题，也是由一些片面的想法。

其实今年看的技术文章大多都是杂七杂八不成篇幅的，唯一一本从头看完的便是Bob大叔的《整洁架构之道》,说是架构，但这本书讲的并不是如何构建现在企业关心的4A架构。更多讲的还是设计原则和依赖原则。如果说企业架构里讲的是顶层架构设计。这本书讲的更像是划分应用边界的原则，以及单应用里的底层设计原则。围绕着抽象、依赖、复用、策略等如何对具体功能进行设计的方法论以及各层级的依赖划分。

其实前几章讲的各种依赖和设计原则和《java编程思想》大同小异，也就随意而过。这里面印象最深的还是那张流传已久的整洁架构图。这也是这本书里作者最核心的一部分。看过六边形架构和洋葱架构的人应该都能理解这个架构图。而且它也为现在DDD架构提供了最核心的概念，在我看来，DDD架构可能也就是在它的基础上，追加了根据业务架构中的业务能力业务对象，映射成应用架构的领域对象的一个说明。而对企业关注的业技融合提供了一个看起来更有信服力的方法论而已。

这里面作者的很多观念都是让我很信服的，比如“架构就是要将易变的部分和不变的部分隔离”，”架构的价值便是以更少的成本维持软件系统整个生命周期”。但是我认为他的理论也不能完全照搬来用。比如Bob大叔花了很大章节讲解了讲基础设施层解耦的必要性，并给出他当年项目建设的案例。

这不由让我想起22年初，新系统建设初期采用了公司新一代开发框架，便是基于DDD的分层架构。当时我和研发框架的架构师们有个分歧，他们认为domain层一定不能依赖infrastructure层，那种架构是“无礼”的“。但我想，既然已经把具体的基础设施(如oceanbase、redis等 )定好了，以后大概也不会有仅仅更换基础设施的需求，它便是最稳定的组件，非要抽出一层接口来解耦实在意义不大，且甲方也不会为这个目前看似无用的扩展额外追加工作量。这可能就是架构思维和交付思维的差异吧。最后，本着谁拍板谁负责，以及项目优先的原则，便默认了这层依赖关系。就算时至今日，我仍不认为这是个错误的决定。

我认为，对于架构之道，还是需要用辩证的眼光来看待，没有最优的架构，只有最合适的。就如同DDD架构与CORS的补充一样，虽然很多帖子都在讲述CORS设计命令和查询的分离的优雅性。不过我看来，之所以有CORS，很大程度上还是因为完全遵循领域建模带来的开发的复杂度，而作出的一种妥协。

同理，若架构师只追求于最前沿，最完美的技术架构，而不考虑项目团队因素进行一定的妥协，如研发团队水平、项目周期、建设成本、交付难度、后期变更维护等方面。即：不考虑架构核心的价值：提高生产力和生产效率。那无论技术多好，都不能算作一位合格的架构师，如果没有这种意识，可能到最后离开时候，还会认为是公司配不上他的技术。

写这个的时候让我想起了以前面试的经历。都说面试造航母,工作拧螺丝。其实面试时通过提问一些实际工作很难接触过的技术，来了解面试者技术的广度和深度，并以此判断面试者的技术自驱性，本身是没有问题的。但这个实在是不应该作为最核心最底层的面试条件。但这种技术标准却在很多面试官身上（尤其在一些技术大佬身上）体现的尤为突出。最终导致的结果便是，要不招不到人，要不花费很高成本招聘的人才，但并没有让团队有很高效的提升。

后来想了想也大概明白了。毕竟每个人都是站在自我角度来面试，既然技术架构师的职责是参与架构设计，他自然看重的是高技术理论的人才。其实在几年前，我还在做开发工程师的时候，面试的时候也偏向于提一些纯技术理论问题，什么cap理论、paxos算法，简直成了分布式面试的标配。并对之前公司高技术架构大佬崇拜不已，视为偶像。但随着这几年职责的改变和工作经历。愈发的发现在实际工作过程中，最有价值最有生产力的选手，并不是那些会很多五花八门技术的员工，而是那些脚踏实地、认真负责、肯深入了解业务知识并勇于解决问题的选手。相反，太过于追求于技术型人才，往往不愿对实际业务逻辑深入了解，他们可能太过于"聪明"，会认为这对技术毫无帮助，浪费时间。当有这种想法认知时，虽有一身本领，但能产生的价值却极其有限了，这也是很无奈的一种现象。

说到这，那便再往外延申一下。《整洁架构之道》有句话说的很对，架构要做的不仅是顶层架构，底层设计也尤为重要。就像建房子一样，设计师若仅仅规划完要建几座大楼，要修几条路进行关联。而对房子内部结构，如哪里当厨房、哪里当卫生间、哪里安插水电不管不顾，那建出来的系统势必徒有其表。但是一旦要做底层设计，又往往涉及到对具体的业务流程业务规则的抽象、拆分。这便和架构师不想参与具体需求设计相矛盾了。而研发的职责还是着重于实现软件的行为价值，也就是实现其功能即可。这可能也就是目前整洁架构领域架构很难落地实施的原因吧。甚至经常发生的事情是，让不了解业务的架构师花两周时间来产出业务架构图。然后架构师找各部门利益相关者调研询问最基本概念，过了两周，出来业务架构图的可能变成了一份企业相关组织机构功能范围清单了。

可是换一种思路，如果按这种看法，那需要的是便是既懂业务又懂技术的业务专家+技术专家一体化选手。可是这种层次的选手，应该大多成为了决策层，最低也是管理层人员，也会有更高的意愿追求，又怎么会长期落地做具体逻辑的设计呢。毕竟，大多数公司并不能想阿里那样，可以给够足够的收入吸引人才，让落地研发的选手也有架构者的思维。所以说，还是价格决定价值，还是要务实一点，既要又要的思想不能有。

哦，今年还简单学了一下k8s相关技术，可能会被技术大佬狂喷，这玩意都多少年了现在才学。哈哈，实在是前几年没有精力。只是前段时间偶然看到一些招聘信息，好家伙，怎么全都些这玩意。于是买了几台腾讯云服务器，跟着网上搭了一套k8s集群，对相关组件，容器组 服务 工作负载 ingress等学习照葫芦画瓢玩了下。简单搞了一套基于jenkins springboot docker harbor k8s的cicd。不得不说，在重拾这些特别纯粹的，一就是一二就是二的技术活的时候，实在是一个让人享受的环节。真的是能专心的做一件事，能只对自己的事情负责，其实是一件很幸福的事情。如果团队小伙伴有兴趣，可以私下找我，趁着还没过期，也可以玩一下。

虽然对k8s目前的学习，还是小白中的小白了。不过我不打算继续深挖下去了。因为这还是偏向于运维测的工作，对于研发来说，达到知道是什么，会用会集成的深度也就差不多了。技术是无穷尽的，大家还是要根据自身的目标追求对知识的广度和深度进行一定的取舍。就像云计算不断衍生的概念IaaS、PaaS、SaaS、BaaS、FaaS、以及ServerLess等，是越看越无奈。真是不得不佩服云厂商的思维，起名都这么高大上。只是可能跟我接触的行业相关，领导明明最关心的是企业业务能力与科技的融合，流程及数据驱动促进来数字化转型。而云计算能做的都是更偏向于技术架构里的运维部分，两者几乎没有关系，也不知为何会有长篇大论云计算在数字化转型的核心地位，难道按量付费、弹性扩展、容器编排、优化迭代布署便能促使技术、业务、决策的深度融合吗哈哈。

相对来说，我反倒觉得公司现在研发的飞猫产品还有点意思。说到这不得不佩服老板的思维，还创造了业务资产等一系列名次。等等，这个好像有点熟悉。如果将产品里的业务资产进行分类，将他们划分到不同的业务对象里作为业务行为。在给他们划分好边界与联系，按需进行流程编排，这不就是之前聊的DDD嘛！

三、思维篇：

其实今年对我来说，最有意义的事便是思维模式的转变。以前无论是学习还是工作，都是无头苍蝇，需要什么学什么，有什么问题解决什么问题。成天忙忙碌碌，问题却源源不断。其实后来想想，不只系统需要框架，人生也是有框架有结构的。

1. 先谈学习篇。

 其实团队里的一些小伙伴们很多还是有技术欲的。如同我刚工作那几年，对技术趋之若鹜,看到一门技术便钻进去研究。其实，现在想想，我们在投入学习前，我建议还是先构建好自己要学习的能力知识地图，当然构建它的底层是你的目标是什么，以后想成为什么样的职业。这是最重要的，先跳出具体的技术组件，想清楚自己要学习的知识谱图，然后将正在学习的具体技术对应的图谱坐标里。明确好要学习的知识广度。这样自身便会有概念了，对于职业规划所需技能，哪些是重要的，哪些是边缘的，哪些技能已经具备，哪些需要重点提升。当把这些都理清后，便会明白要学什么、要学到什么程度了。

然后就是学习方法。我个人还是比较建议参考下费曼学习法。千万不要限制于一直泛读的误区。软件行业相对于其他行业的一个优势，便是一门技术很容易进行实践。

它不像管理学一样，学习了一堆方法论，没有人让你管理，终究是纸上谈兵。软件技术是很容易进行实施检验的。学习一面技术一定要进行运用，总结，最后自我理解，当能给别人讲明白你学到的知识时候，这才是真正的学习。如果恰好你学的技术能够在真正项目里实施，并经过实践的检查，通过复盘总结而形成自己的经验模式库，那便离成为专家不远了。

2.讲完学习，再讲一下我理解的跨行业的底层能力底座。

其实无论是什么职业，要学什么知识，最核心的，还是每个人底层能力品质和价值观的培养。这里面我觉得最重要的几点便是正确的价值观、尊重与自我尊重、高自尊人格、以及边界感。一个人一旦能做到以上几点，我相信任何行业都可以脱颖而出的。

价值观： 我认为还是跟每个人的经历、家庭、学识都有关，别人是很难改变的。毕竟人总是相信自己胜过相信别人。可能多看一些历史人物传记书籍会有一定影响吧。

高自尊人格： 是一个很珍贵的品质。大家在工作过程中是否见过一些人，出问题便开始指责埋怨别人，好像自己永远是对的。这种人，就算明面不说，内心也是这样想的。归根结底便是低自尊人格在作祟。自己的自尊不容挑衅，为了维护所谓的自尊心，潜意识就会把问题都往外甩。有这种思想的人，可进步空间及其有限。给大家两个建议，1.永远不要说“这个事情我之前就说过”。 2.出问题时第一句永远不要问：”你为什么会犯这种错误“，要先解决问题。

一定要培养高自尊人格，时刻自省，我们不需要揽不属于自己的责任，但一定要勇于承认问题，并总结提升，让自身逐步优秀。

边界感： 嗯，到如今为止，我认为这是人生至关重要的一个能力，它比我们学到的任何知识都重要。它就如同系统边界一样，一旦越界，会把整个生活工作搞得乱七八糟。它的范围很大，父母与孩子之间、夫妻之间、同事之间、上下级之间、各部门之间无处不在。保持好边界感才能和谐的进行生活工作。相反，和没有边界感的人接触，往往是灾难型的。

边界感到底是什么我也没法描述。只是，生活中实在太多这样的示例，如工作越级汇报，导致两人相互反感影响后续工作；本职事情越界甩锅，产生不断的扯皮；非本职范围内强行表现引人反感；父母过多干预，遭子女嫌弃。有时候，我们本意是好的，或者都是为了统一目标，但边界感不足，往往适得其反。其实每个人都会或多或少越界，有时候回想之前，我也做了很多没有边界的事情。不过，我们心中一定要有这根弦，慢慢养成边界感强的人。

没有边界感的人，通常都是不自知且低情商。可以想象到，这种人，除非有中大奖的运气，否则以后又会有多高的成就呢。所以从现在开始，培养自己的边界感吧。

好了，本年度汇报就到这了，本来还想写一篇家庭篇，但想了想，还是没必要公开了。总结一下，工作生活中，我们还是要培养正确的价值观、高自尊人格、边界感为底座。确立人生目标，保持长期主义，构建自己的人生框架，通过不断学习实践总结。完善自己的能力地图，形成自我独有的方法论。并采用合适的学习方法来提速。为自己、家庭带来更好的生活。愿大家新的一年都有所收获。

嗯，本来打算定几个25年具体计划的，一时也不知定啥，那就等春节前出计划吧。按苏总监的说法，既然出不了计划，那就先出一个计划的计划吧。

望共勉。