一、第一课：两个人写代码的真相
新来的四个同事到了：阿杰、小雯、大刘、阿婷。云间书店技术部正式成立——六个人，一台共享服务器，一堆"之前只有老周和小陈看得懂"的代码。
第一天下午，小陈就发现了不对劲。
他正在改收银模块的 apply_discount 函数，改到一半想去倒杯水。回来时，屏幕上多了一行注释：
# 阿杰：这段逻辑我看不懂，先注掉再说
# if total > threshold:
# total = total * rate
"师傅！！"小陈冲进老周办公室，"有人把我代码注释掉了！我改了一下午的折扣逻辑！"
老周过去看了一眼，很平静："正常。阿杰昨天接手了会员模块，他也改了 apply_discount——他觉得你的写法跟他理解的不一样，就'帮忙'改成了他的版本。你们俩同时改同一个文件，后保存的人覆盖先保存的人。这叫覆盖写（overwrite）。"
"这不叫正常吧！"小陈快炸了。
"在没有任何协作工具的情况下，这就是正常。"老周说，"两个人写代码，靠的是默契——我知道你改了哪块，你知道我改了哪块，我们错开。但六个人还靠默契？ 你告诉我，六个人的'默契'怎么约定？"
小陈愣住了。
"这就是管理第一课的根问题——"老周在白板上写下：
根：为什么需要管理？因为"一群聪明人"不等于"一支团队"。
二、个人开发 vs 团队开发：麻烦从哪来
老周画了个对比：
个人开发（老周一个人写收银机）：
你改代码 → 你跑 → 你上线 → 你背锅
麻烦：自己跟自己打架（少，可控）
团队开发（六个人写网店）：
你改代码 → 别人也在改 → 合到一起 → 谁上线？谁背锅？
麻烦：
① 代码互相覆盖（同一文件同时改）
② 需求口径不一（六个人对"打折"理解不同）
③ 没人知道谁在做什么
④ 上线了出问题，不知道是谁改的
⑤ 新人看不懂老人代码，老人改不动新人代码
"个人开发的流程是一条线；团队开发的流程是一张网。"老周说，"管理的本质，就是把这张网理顺——让六个人既能并行干活，又不互相踩脚。"
"那怎么理顺？"小陈问。
"别急，这就是整棵家族树要解决的问题。但在往上爬之前，你要先记住管理的第一原则："
任何管理实践，都是在"增加一点规矩"和"减少一点自由"之间做交易，换取"协作不出错"。
"规矩太松，六个人互相踩脚；规矩太紧，六个人寸步难行。优秀的管理者，是在找那个'刚好不踩脚'的平衡点。"
三、团队的第一个里程碑：把"改代码"变成"有迹可循"
老周说，管理不是从大道理开始的，是从具体动作开始的。六个人的技术部，第一个动作是三个"小规矩"：
3.1 规矩一：改代码先打招呼
团队约定（第一条）：
1. 改共享文件前，在群里说一声："我要动 apply_discount，谁也在改？"
2. 改动完成后，@ 全组："改完了，涉及打折逻辑，大家注意。"
"这是最原始但最有效的'协作协议'。不需要工具，只需要习惯。但它只能解决'打招呼'，解决不了'我不在时别人改了'——所以我们需要更硬的手段，那就是下一章的版本控制。"
3.2 规矩二：代码必须有"主人"
老周把模块分给每个人：
模块负责人：
收银/订单 → 小陈
会员/积分 → 阿杰
库存/物流 → 大刘
报表/数据 → 小雯
支付/对账 → 阿婷
架构/底层 → 老周（兜底）
"每个模块有且只有一个'主人'。别人要改，先跟主人商量。这样出了问题，立刻知道找谁——这解决了'没人知道谁在做什么'和'出问题不知道找谁'。"
3.3 规矩三：定义"完成"
"最致命的一个问题：六个人对'做完了'的理解不一样。"老周说，"阿杰觉得'代码写完'就是完成，小雯觉得'测过'才是完成，王姐觉得'上线能跑'才是完成。你们说，哪个对？"
"……都对吧？"
"都对，但口径必须统一。我们技术部定义'完成 = 代码写完了 + 本地测过了 + 别人评审过了 + 测试环境验证过了'。以后任何人在群里说'这个需求完成了'，就是指这一整套，不是'我代码写完了'。"
云间书店技术部 · 完成的定义（DoD, Definition of Done）：
□ 代码编写完成
□ 本地/单元测试通过
□ 通过至少一位同事的代码评审
□ 在测试环境验证通过
□ 相关文档（如有）已更新
"这一条看着简单，但它解决了团队 80% 的'我以为你说完了'的扯皮。"
四、根：这棵树的种子
老周把第一章的地图补上：
根：为什么需要管理？── 个人开发 → 团队开发
├── 问题①：代码互相覆盖 → 需要"协作协议"
├── 问题②：需求口径不一 → 需要"完成的定义"
├── 问题③：没人知道谁在做什么 → 需要"模块主人"
└── 问题④：出问题找不到人 → 需要"责任到人"
第一层（预告）：需求管理
└── 场景：王姐一句话，程序员加班一个月
"小陈，这一章没讲任何工具、任何框架，只讲了三个'约定'。"老周说，"但你要明白——软件工程管理的根，不是工具，是'人跟人怎么协作'的约定。 工具只是把约定固化成机器能强制执行的规则。"
"接下来，咱们要开始用真正的'工具'来加固这些约定了。"老周顿了顿，"你猜猜，第一个要上的工具是什么？"
小陈想了想："先把'代码互相覆盖'解决掉？"
"对。版本控制——让所有人的代码改动能被记录、被合并、被追溯。那是下一章的事。但在那之前，我还有个更头疼的问题要跟你交代——"老周压低声音，"王姐刚才在群里发了一段话，你看了吗？"
小陈掏出手机。群里，王姐发的是：
"@技术部 客户反馈说结算页太慢了，这个优化一下；顺便把'满减'活动加上，下周就要上线；哦对，库存报表格式也改一下，销售那边催。"
小陈看完，脸都绿了："这……她说了三个需求，但每一个都不清楚：多慢算慢？满减怎么减？报表改成什么样？"
"这就是第一章预告的麻烦——需求管理。她一句话，我们可能加班一个月，还未必是她要的。走吧，下一章，我们专门治这个病。"