三个人，两套系统，还要自己做开发。第一年我最大的问题是舍不得放手，很多本该分出去的活自己熬夜做完了，结果别人没机会上手。改过来花了大概四个月。这篇记了四件具体的事，其中两件我处理得不好，写下来提醒自己。
一、这个团队是什么样的
要交代一下背景，不然下面的事看不出难度。团队连我三个人，管两套内部系统：一套是订单管理，内部叫 OrderHub，.NET 6 加 Vue 2，大概六十个页面；另一套是对账结算，叫 Settle，最早的代码是 2017 年的 WebForms 迁过来的，还在用 ASP.NET MVC 5。两套都要维护、都要接新需求，两套我都是主要开发。
另外两个人：老陈比我早入行六年，SQL 写得比我好，报表和对账逻辑基本靠他，但不愿意碰前端；小吴是 2023 年毕业的，进来一年多，C# 基础扎实，写代码快，问题是没接触过线上问题，一遇到报错就慌。名义上我是组长，实际上前半年我跟他们一样在排期里领活。
第一年真正的困难不是技术，是我一天里的注意力要切四五次：早上评审需求，上午写 OrderHub 的接口，下午被 Settle 的一个对账差异叫走，晚上回来发现自己上午写的东西忘了为什么这么写。这种状态持续了大概三个月。
二、分工我一开始定错了
我最开始按"层"分：老陈负责所有 SQL 和存储过程，小吴写业务逻辑，我写接口和前端。听起来很合理，做了两个月就崩了。崩的原因是责任不到人——一个需求从对账规则改到接口字段再到页面校验，要过三个人，谁都觉得自己那部分没问题，出问题的时候三个人一起查，反而更慢。
2024 年 9 月改成按系统加按模块混合：OrderHub 归我和小吴，Settle 归老陈，我只在 Settle 的 SQL 部分做评审；OrderHub 内部再按模块切，小吴负责导出和报表，我负责订单主流程。改完之后最明显的变化是，线上出问题的时候不用再问一遍"这个是谁写的"。
代价是一个人身上会积压。老陈一个人扛 Settle，2024 年 11 月他请了三天假，那三天我连他自己写的存储过程都看不太懂。这件事我到现在也没解决，只是把关键的两个存储过程逼着他写了注释。
三、第一次放手，放砸了
2024 年 7 月，我想着要给小吴压点担子，把"订单导出 Excel 重构"分给了他。需求是原来的导出超过 5 万行就超时，要改成分页查询加流式写文件。我跟他讲了一次思路，大概二十分钟，讲完问他有没有问题，他说没有。
然后我就不管了。这中间的三周我没问过一次进度——我当时觉得问进度就是不信任人。等到了交付前一天我去看代码，发现他用的是把数据全查出来再用 EPPlus 一次性写，跟我说的完全是两回事。我当时有点上头，说了句"这个重做吧"，然后自己从晚上八点写到凌晨两点，改成 IDataReader 逐行读、OpenXmlWriter 流式写，第二天早上交了。
交是交了，但这次放手彻底失败。我后来看他的提交记录才发现，他其实在第一周就卡住了，卡在 EPPlus 的 SaveAs 会一次性把数据放进内存，他试过换 LoadFromDataReader 但没调通，之后就一直在原地绕。他没来问我，因为"我说过有问题就来问"，但问的前提是知道问题在哪，他那时候连自己卡在哪都说不清。
这件事我的责任占大头，而且是两个：一是交待得太粗，只说了方向没说验收标准，也没拆中间节点；二是我在最后一天才介入，等于前面三周的检查点一个都没设。最糟的是我自己熬夜重写了一遍，这传递的信号是"反正最后周牧会兜底"——这个信号后来花了很久才收回。
四、第二次放手，成了
2024 年 11 月，Settle 那边要做对账差异的自动核对。这次我换了个做法：和小吴一起把任务拆成四块，每块一个半天，每块结束我们一起看十分钟代码。第一块只做"把差异数据查出来"，只有三十行 SQL 和一个接口，做完我看了一眼，指出字段命名和现有代码不一致，改了。后面三块他就基本不用我盯了。
关键差别其实不是"勤检查"，是我把第一块切得足够小，小到他一定能做成。他做成一次之后，后面三块我心里有底，他也有底。三周的活最后做了九天，比我自己做慢了大概三天，但这次的代码至今还在跑，改动也是他在维护——我不在那家公司之后，这套逻辑还是他的。
另外还有一条我改了：不再说"有问题来问我"，改成每天固定一个十五分钟的碰头，我主动问"卡在哪"。问和不问差别很大，"卡在哪"这三个字逼他把模糊的困难说具体，说具体的过程中他自己经常就想明白了。
我第一次放手失败之后，有大概两个月又回到了什么都自己写的状态，理由是"教他的时间够我写两遍"。这个理由在当时完全成立，只是它永远成立，所以永远交不出去。真正让我改过来的是 2024 年 11 月那次线上事故——我一个人扛着的时候，凌晨两点没人能替我分担，那次复盘我写在另一篇里。
五、两件我处理得不好的
第一件是需求评审。我习惯在评审会上直接把实现方案讲出来，讲完问"有没有意见"，通常没人说话。我以为这是效率高，后来老陈私下跟我说，他其实对其中一个表结构调整有看法，但"方案你已经想好了，我再说就是抬杠"。我后来改成评审只过需求和验收标准，实现方案放到会后单独讨论，但说实话改得不够彻底，现在还是经常忍不住当场把方案说了。
第二件是订单主流程我到最后也没交出去。那部分是我 2020 年写的，改起来我心里有数，交给别人我要花双倍时间解释。结果是只要涉及订单状态流转的需求，全都落在我头上，2025 年 3 月我连续两周加班就是在改这块。我知道这是错的，但这一年里我没有真的去改它。
六、技术转管理，我到现在没想通的
写代码的产出是可见的，一天写了多少行、解决了几个 bug，自己清楚。带人的产出大部分时候看不见，你花两小时跟人讲清楚一个问题，这两个小时在任何地方都不会被记上一笔。第一年我的实际感受是：写代码的时间从七成掉到三成，但心里对"我今天做了什么"的确信度掉得更多。
我没想通的是技术能力该怎么维持。这一年我明显感觉自己写代码的熟练度在下降，特别是新东西——2024 年 .NET 8 出来的时候我只是草草看了一眼，以前我会专门花一个周末做实验。而同时我也清楚，如果我连新技术都不碰，一年后我给不了团队任何技术判断。这个矛盾我到现在没有答案，我现在的做法很笨：每周留半天写代码，雷打不动，写什么都行。
（这篇是 2025 年 5 月写的，动笔的时候这个团队刚交出去。回头看第一年做对的只有一件事，就是后半段开始每天问"卡在哪"。做错的比我写下来的多。）