先说下标题，所谓独立推项目跟之前的推项目（最多只能叫跟项目）区别在哪里。
| 跟项目 | 推项目 | |
|---|---|---|
| 项目来源 | 主版本的大项目，分了一小块给我来跟 | 由我向上面发起 |
| 需求定义 | PM 说啥就干啥，PM 说砍啥就砍啥 | 共同协商，我拍板 |
| 风险处理 | 报给大版本负责人 | 自己消化，消化不了就背延期的锅 |
| 资源排期 | 整体安排，各别协调 | 啥啥没有，自己想办法 |
最明显的区别是，凡事没有退路。心(pi)态(gu)变换导致很多做事方法完全不一样
注：后面每个大标题都表示一块项目管理的工作内容，不分先后，重点写自己做的不好的，可以挑自己感兴趣的看。
为了便于后面描述，这里简单介绍下这个项目，简单说，我们做的就是统一实体的唯一标识。
比如用户的唯一标识是什么，至少我见过几种方式：user_id、id_card、phone、email等等。 不同系统存一个用户用的标识不一样，通信的时候非常麻烦，来回转换。
然而，我们系统内的情况更复杂：
- 我们有10+种主要实体（课程、电子书、音视频等等）
- 每个实体要对接8+种通用服务（收藏、进度等等）
- 超过一半的实体都用了两种以上的标识（数字 ID、别名 alias、甚至还有人用课程关联的视频 ID 作为课程的 ID）
在我的理解里，N种实体，M 种抽象服务，如果抽象得当，那么对接成本应该是 N+M。但在这种实际情况下，对接成本可能到了 NM2.5。
除了开发成本，带来的问题更加可怕。
- 用户反馈收藏的课程不见了，一查发现，收藏接口传的音频 ID，取收藏数据传的视频 ID，其实应该传课程 ID。
- 某节课程的所有用户留言都不见了，一查发现，留言系统用的“课程所关联的音频ID”作为课程ID ，然而这批课程换了一批音频，音频 ID 全变了。数据也自然都对不上了。你说赶紧洗数据吧，可是都不知道哪些音频改过
后来我实在受不了这些祖传屎山了，就找老板讨个规范。老板一听很高兴，把我跟几个端的 leader拉了个小群，提了一下这个问题，说统一业务模型很重要、隔离系统边界很重要。xxx 来负责，先把接口搞干净。
于是就稀里糊涂地接了这个活，坦白说，这个事情技术难度只能算中等偏上，也就是一点点抽象能力。但它极大考验协调和项目管理能力。具体说，需要配合的人非常多，因为各个端都得改一通，在我司极少有项目需要牵扯这么多人和端。而且，我的职级也不高，要让这么多人因为我一句负面的吐槽就听我号令，实在是痴人说梦。
光我说难不算，我也问过几个leader意见。客户端某端负责人说，你们这么折腾，就相当于把 App 重写一遍。一位架构师告诉我说，去年就想搞了，但是端上的阻力太大，就不了了之了。
最后给我的感觉就是：大概率不成，全当一次历练吧。
万幸中的万幸，经过一个多月的鏖战，总算是上线交付，得到的评价还不错。
后面就来说说一些过程中遇到的问题
最耗精力的工作内容：划清项目范围边界。
一般随版本走的的产品需求，在开工前80%的需求都是确定的，时间点也是固定的，资源也比较足，按部就班地做一般不会出问题。
但是技术改造就很麻烦，名义上是一个独立项目，可以做完后单独发版，没有明确deadline。但实际上，每个人都会先做火烧眉毛的事情，没有 deadline说明还能放一放。而且老板那里肯定会有个心理预期的，不能一直拖。于是大家一起简单梳理了接口范围，定了个“一个月”。
技术改造还有个问题，准确的成本要看到代码才知晓。我们也是真正开工的时候才发现，这个技术改造跟其他6个技术改造项目有关联，比如迁移新接口、迁移新路由、 服务化改造、部分系统重构等等。这些改造目前都算是“重要不紧急”，很多都是说要做，但是做了一半就放在那里了。一说这次要动那部分的代码，都想着能不能“顺手”把哪个改造也一起做了。
如果拒绝有什么影响呢：
- 面上的，减少项目成果，降低项目意义和价值。像是做了个半吊子工程
- 部分代码要改，但改的不是最终版本，还要兼容，后面可能还要返工。这点会严重打击开发的积极性
如果接受，自然能避免这两个问题，但是会有其他问题
- 改动代码范围变多，质量风险会大大提高
- 项目范围膨胀，极有肯能严重延期或烂尾。
- 这两点都算是项目的命根子，如果发生这类问题，约等于成果为0，前功尽弃
为了在这些矛盾点做取舍，我们耗费了大量的精力去讨论、调整项目的边界。如果一件事情不做，项目意义是否会丢失，丢下的有什么补救措施，是否还需要二次开工。如果做了，对我们目标帮助到底有多大，会引入多少风险，需要多少资源开销。
最开始的时候风险看起来不多，可以考虑多做一点，也很容易借此把大家团结到贼船上。到了中期，我们对整个项目的时间点已经有了比较清晰的预估，也提前协调好了测试资源和上线准备。但与此同时，整个项目有不断膨胀的趋势，我们几个主要负责人调整策略，一切以项目按时按质交付为第一目标。遇到任何带来风险的包袱，果断丢下。最终卡在边缘完成了交付。
项目目标同步不到位
这个跟上面的相反，范围不清晰会引来项目膨胀，但目标不明确，会在开发过程中丢三落四。
最广为熟知的案例莫过于造秋千。当工程师认为要做的只是在树上挂两根绳子时，整个项目已经在脱离目标和计划了。很多工程师最终得到的任务是给接口加两个字段，至于字段最后干嘛用，也不是特别清楚，更不用说加的对不对了。
同样，我们耗费了很多精力去说明白我们到底要做什么，要向大家确认，做的事情跟目标是否一致。
去年锁元老师带我们做了一个叫项目管理ABC的小游戏，我非常推荐刚开始接触项目管理的同学去玩两把。每次想到这个游戏和凄惨的结果，都觉得好像还有什么没跟大家交代清楚。
规范型项目，项目的意义和愿景要深入人心
我以为有了目标，这事就算结了。直到我发现有一位同学，在参与这次技术改造时，很配合地把那些乱七八糟的接口都改成了约定的 ID，结果在新开的项目和接口里又用回了乱七八糟的标识。交流之后发现，在他理解上，只是以为我们要把那部分接口改一下，为什么要改，不关心。也不会意识到以后新的接口应该按规范的方式来。
这件事情一开始我以为是规范没有确立导致的，加个明文规范：“强制必须使用业务主键来通信”。后来发现，这个规范其实跟没有一样，因为什么是“业务主键”完全是由开发自己说了算。
在我的意识里，所谓的 MySQL范式可能是不言而喻的，但是对于很多人来说，根本分不清何为实体（entity），何为标识（Identity）和属性（property）。你得去跟他们讲明白，举例子，为什么这个字段是ID而那个字段不能是 ID。在别人看来，可能也只是你的一厢情愿。
必须承认这里有个困局，一般项目宣讲会上，愿景、意义、目标普遍被认为是假大空，也是大家最不想听的，通常得到的反馈就是“你啰嗦了那么半天，我就想知道我具体要怎么做”。对于这一点，我自己也一直也没有什么好办法。目前唯一在尝试的，就是在过程中面对成员的困惑时，借机再用意义目标来引导。通常这个时候我讲的也更容易被接受。
最惨的一个教训：拆分到具体可观测的小任务。
站会的时候，我们得到了开发同学的答复：某个接口已改完。后来发现，所谓“改完”。。
这个问题以前就经常遇到，就连《人月神话》里也提过“已完成80%”的梗。但是直到自己的角色成了“项目负责人”，才真正开始思考怎样减少这类风险。
代码未动，计划先行。
计划不一定是把准确的尺子，但一定是任何情况下的行动指南。
最尴尬的问题：砍掉的范围，如何给后人交代
最没脾气的错误：对客户端的了解和发言权远少于后端
经常会面对这样一个场景，客户端告诉你这个太复杂，他那边不好处理。这个时候，即便你的意义愿景再牛逼，目标再清晰，这个时候也发挥不了什么用。
我的一个经验是，主动走进客户端，了解他们的架构。通常情况下，你会发现他们说太复杂是按照要改5个模块算的，当你看了他们的架构后，可能只需要改2个模块就够了。这个过程中，也花了不少时间跟客户端同学在一块，人手把手地给我讲客户端的一些东西。就这次的案例来说，我觉得还是很值得的。
你可能会问，这是否在质疑客户端的专业能力和架构能力。我觉得并没有，之所以能帮他们找到答案，并不是专业能力的差距，更多地是对项目目标的清晰认识和坚持，而他们，正因为对代码太熟了，更容易忘记自己当下的目的。举个不恰当的例子，我觉得我的器官缺一不可，结果一位盲人说，就算没有眼睛也可以活得不差。显然这位盲人并不是在说我眼睛没用。
应对突发状况：灰度前2个小时发现新问题
可以有两分钟的情绪宣泄期，但作为“负责人”，一定要尽快冷静，召集相关的人，商量解决方案，做好接下来的安排。
