05 大项目 把握关键点，谋定而后动

对技术 Leader 来讲，团队的开发模式多以项目制或敏捷迭代为主，不论哪种方式，项目管理都是最主要的工作之一。在互联网公司中，日常迭代和重点项目的同步进行几乎成了常态，你也会遇到一些特殊的项目，比如“一号工程（老板项目）”“技改项目（核心系统重写）”“倒排期的重大业务（11.11 和 618 的大促、新业务新产品研发）”。这些项目我统称为“大项目”。

大项目因为时间投入大、人员规模大、系统更大，和日常迭代项目在“项目管理”和具体做法上存在很多不同，在成员的协同、事务的推进上也存在困难，而你要具备解决这些困难的能力，有两个原因。

• 公司基于战略规划等目的，一定会启动大项目，你必须具备处理这类项目的能力，并不断抽象与思考，形成自己的方法论。这是环境对你的要求。

• 我观察后发现，一些公认出色的同学，往往是在大项目中脱颖而出的（这个因果关系在我所经历的互联网公司中近乎100%）。优秀者一般都会重点参与或主导几次重要的项目来证明自己，进而在未来得到更大的发展空间。

由此可见，大项目在技术工作中很重要，今天我想结合自己的一些经历与思考，具体聊一聊这些特殊的大项目中，你要重点注意什么，怎么去解决问题。

认清异同，做到心中有数

想解决一个问题，先要定义清楚问题，一般而言，要想认清大项目，我建议你以常规项目为参照物，通过对比二者特征总结差异点。一般项目迭代的常规流程如下：

这个流程并不复杂，大多是自上而下敲定需求内容和优先级，做好时间预估后就进入开发流程，有时受开发周期的影响，会压缩一些环节上的时间（比如方案设计、开发自测等），将大部分时间花在业务逻辑的实现上。在这个常规流程中，技术团队的重心是把执行做到位，你要更关注过程管控，确保系统交付。

大项目与常规项目的核心差异点，我认为主要在于这个“大”字上，你可以从三个方面去理解。

• 出发点不同，业务期望更大

在大部分互联网公司中，产品研发模式侧重敏捷迭代：项目小步快跑，尽早试错、及时调整，通过逐步完善系统实现量变积累质变。大项目完全相反，不再小步快跑，而是“蓄力憋大招”，希望以此建立公司的竞争优势。

以双十一为例，阿里相关团队要提前 3~5 个月进入双十一专项（最核心的团队半年前就会 ALL IN ）。这类项目投入巨大，自然有极高的业务目标，比如双十一和 618 主打 GMV，历史新高的 GMV 映射到产品技术上，就要有更多、更复杂的营销玩法，系统也要有更强的负载能力。

• 规模不同，复杂度更高

日常迭代项目一般以周为单位，以小组为执行单元，需要跨部门协作的往往是单点的需求（比如某个接口需要大家一起联调）。又因为需求和交付产物拆分得足够小，关联性也不强，即使在迭代周期内遇到一些意外情况（比如开发人员突然短缺、需求紧急变更）也只会让一小部分业务受阻，不会影响全部的项目。

而大项目往往是重新建立一个产品或体系，以月为单位，涉及的人员跨多个部门甚至整个公司（协作者会变成几十甚至上百人）。需求拆分的粒度并不细，并且随着项目推进可能会持续识别到新的需求，这就让整个项目处于动态变化的过程中，增加了系统复杂度和项目难度。

项目规模变大后，会放大很多问题，比如你会发现跨部门沟通协同比系统 Bug 难处理，开会汇报项目进度比写代码更花时间。除此之外，项目往往会倒排期，开发资源永远不够，组织与组织间协同效率低下等问题在大项目中极其常见。

• 结果评判标准不同，影响更大

在日常迭代项目中，我们往往只关心交付的时间、质量，无法在短期内判定业务上的效果。可对大项目来说，最初立项就是奔着业务效果去的，所以相对而言，它可以容忍项目过程中的一些不顺利，但看重业务目标的达成情况。如果没达成业务目标，会浪费之前投入的资源与时间，从而在竞争中处于劣势，所以很多公司是把自己“折腾”没的。

除了业务层面的宏观影响，项目的交付直接影响相关人的绩效 KPI，也间接影响年终奖、晋升。

总的来说，大项目对你的要求与常规项目有很大不同，除了把项目管理的基本功做到位，还要考虑如何达成业务结果，如何协同人与团队，如何解决各种突发问题。最关键的就是你要脱离系统交付的角色定位，站在团队实现业务结果的角度去考虑问题，认识到系统的交付并不等于项目的结果，要在业务的思考上迈出一大步。

把握关键点，谋定而后动

前面我提到，大项目中系统的交付固然重要，但更关键的还要看项目目的是否达成，关注效果更重于关注交付，这是大项目的核心特征。

以核心系统的重构（重写）项目为例，要想重写，就要投入大量时间，承担极高的系统风险，为什么要重写呢？答案可能是“系统是其他团队开发好交接到手里的，不好维护。”或者“最早的设计实现有问题，必须大改。”这时，你要明确重构到底是目的还是手段？是否一定要做重构？

在我看来，重构除了解决过去的问题，更要预防未来的问题，这样才能平衡好投入产出比。如果单纯考虑解决过去的问题，忽略系统未来的演进方向，过不了多久就会回到原状。不要为了重构而重构，要知道你要的结果是什么。

为了确保大项目成功，关键点应该是制定完备的计划，因为想清楚比做到位更重要。从我的经验来看，大项目的失败存在一个共性的问题：围绕业务结果的思考、计划不足，目标的定义不清晰或没有充分同步给所有相关人，项目同学知其然而不知其所以然。连目标都没有共识，何谈执行到位，项目成功？

所以我认为越是重大的项目，在计划、设计、准备上投入的精力就应该越多，谋定而后动。 我建议你围绕业务、技术、团队等几个方面，把 WHY、WHAT、WHO、HOW 问明白，想清楚。

WHY（项目为什么做）。 很多 Leader 因为习惯做执行和交付，或者觉得即使有不一样的观点也无法改变什么，所以并不热衷去探究项目背后的 WHY。不清楚 WHY，当你要解决困难时，就会缺少核心的逻辑依据，并且你很难识别真正的需求，很难判断业务想要的功能和想解决的问题到底是不是同一件事儿。

WHAT（项目做成什么样）。 WHY 是在确定项目的动机和目标，WHAT 是确定项目的具体形态，简单来说就是要做怎样的产品和系统来实现目标。比如每年的双十一大促，会推出新的玩法和营销活动。如果参与这样的“ Super ”项目，你至少应该搞清楚以下两点。

WHO（哪些人来一起做项目）。 很多问题不仅仅是系统的问题，人也是其中的关键因素，而你需要确定项目的核心人员并罗列项目所有的关联方。

HOW（启动项目后如何做）。 明确了业务目标、结果期望和相关人之后，就进入项目的执行过程，在常规项目管理的基础上，你要注意这样两点。

• 合理拆分任务（模块）是项目成功的一半：大项目是把最终的效果打包放在一起去设计规划，在执行过程中一定会被分治。关键在于你要等所有人对最终架构达成共识后，再去按照团队、业务领域、具体场景任务等维度拆分任务和模块，以终为始，从最终要的结果来确定如何开始拆分（最终架构的形态应该以产品和系统的全局架构大图为参照）。

• 保持风险意识，敬畏墨菲定律：大项目在推进过程中极易发生突发情况和概率性事件，你要做好预案，比如项目排期上一定要预留足够的 Buffer，提前确定好紧急处理问题的机制等。

做好充分的准备之后，可以召开立项会，将 WHY、WHAT、WHO、HOW 的信息与思考同步给项目相关人员。通过 Kick Off 会议确定项目的基调、同步必要信息，为项目推进扫清障碍。

如何处理棘手问题

大项目复杂度极高，容易产生很多棘手问题，而处理这些问题的核心原则是：以最终结果为导向，借助所有可能的帮助与资源，在不违背原则的前提下适当平衡与妥协，达成目标。接下来，我就从人和事两个维度分享一些曾经踩过的坑，希望能对你有所启发。

问题一：缺兵少将怎么办？

项目中人不够已经成了一个常态，比如部门内一套核心系统要重写，而团队无法一边持续迭代、一边在规定时间内完成重写，如果所有人 ALL IN 重写，系统迭代要暂停 2~3 个月，业务上无法接受。如果拉长周期，将重写项目持续半年，不仅会增加意外风险，并且很长一段时间内重写项目无法创造价值，会变成团队的负担。

如果你遇到类似的情况，需要在内部腾挪的同时，以项目的价值与收益为本金，借助上级组织的力量从其他团队借人。如果你有过“借人”或“被借”的经历，大概会对其深恶痛绝，因为这种方法会产生很多新问题，比如其他团队的同学不熟悉业务和系统（进入状态的成本很高），或者你们之间没有汇报关系，在工作安排和任务执行上并不通畅。

所以，我并不建议大项目时常通过借人来补充项目成员， 人员的经常借调本身体现的就是权责不匹配，会导致一系列问题。好的方式应该是在组织内，让项目组的跨组织结构成为常态与共识，设计灵活的绩效、考核、汇报体系，让每个人都可以按需灵活地加入项目组。另外项目组人时你要注意以下几点。

• 当项目开始时，从更大的范围内寻找合适的同学，而不是看你团队有哪些人。

• 将参与项目的同学在一定时间内的汇报关系和绩效考核汇总到项目组中，由项目负责人根据实际情况重新安排每个人的权责，并确定绩效的绑定关系与比例。

• 项目交付并不等于结束，所有人的绩效结果都应和项目目标的达成情况紧密且长期关联。

最后，有时不仅要解决“缺兵”的问题，还要认真考虑是否“少将”？要充分考虑当前的人员是否适合做项目的 Owner，以我的经验来看，项目 Owner 几乎决定了项目成败的 80%，如果 Owner 能力不足，你要给予帮助和支持，或者另找他人，乃至上级的帮助，不要在 Owner 的人选上妥协，毕竟项目成败才是关键。

问题二：推不动的到底是人还是事？

你是否有类似的经历：一些功能或模块经常会出现大家都不做，要么抢着做的情况（比如双十一新增的活动玩法会让很多相关团队都做到自己负责的系统中），这会阻塞项目进展。

之前，我有很长的时间是负责公司的订单交易系统，熟悉这个领域的同学肯定知道，订单系统是一个大杂烩，任何业务都想加一个字段到订单表上。最开始，我经常会为了是否让一个数据加入订单系统而和别人争论，因为我担心不干净的设计会拖累系统的稳定性和可维护性。

由这两种情况你会发现，事情推不动的背后跟人和组织有很大关系，处理不当会加剧不同关联方的冲突，你必须处理好类似的问题，我提供给你 3 点建议。

• 搞明白冲突现象下的利益诉求： 不同关联方产生观点冲突的现象背后其实是利益冲突，你要搞清楚彼此的顾虑。比如我不愿想让某个系统字段落到订单中，主要是考虑到订单系统的可维护以及稳定性，如果你能解决我的顾虑，会容易说服我。

• 为项目结果适当妥协： 在很多情况下，我们无法做出完美的方案，可能就是要在系统内通过很糟糕的实现去实现需求。项目没有 100% 完美，抓住核心原则不放弃，可控部分适当妥协换取项目前进是很好的策略。

• 通过项目地位和决策机制推动项目： 大项目往往是公司重大战略下的产物，一般情况下，不会有人去反对公司的某项既定战略，而你可以通过大项目的重要性在体系内争取更多的资源和帮助。如果你面临一些冲突，要学会利用决策机制，通过更高级别成员的沟通决策拿到解决方案。

问题三：一定会有项目变更吗？

对你来说，最难处理的就是突如其来的变化，变化意味着要调整之前的计划，又会出现新的困难与问题。常见的变化往往有两种：

• 项目演进过程中识别出之前未能识别或考虑缺失的点，导致方案需要调整

• 出自老板的需求变更，很多情况下都是要新增内容。

项目变化和老板 CR 之所以难处理就在于它会打乱项目原本的计划节奏，本来一环扣一环的时间安排、人力安排、任务与模块安排都要重新编排、组合、解决冲突，单点的风险通过链路传递到整个项目链路上，产生了极强的联动效应。

我给你的建议是保持平常心，几乎所有的项目都会遇到类似的情况，出现负面情绪只会增加你解决问题的难度，你要做好两点。

• 由外至内解决，先从优先级调整、新增资源、调整排期入手，不行就考虑压缩时间、调整方案乃至加班。做好 ROI 和风险的权衡，不要为了解决 A 问题制造更难解决的 B 问题。

• 统一变更管理，所有的变更都应该统一管理、审核、评估、记录最后广播给项目全员，确保大家信息一致，对终点的认识没有误差。

另外分享一个我自己的经验，如果你被老板频繁的变更所困扰，试着多做汇报，让他对项目的进展与正在解决的困难有更直观的感受，这样他对新变化带来的不确定性风险会有更强的同理心。

本节小结

大项目是技术 Leader 的试炼场，不仅考验你的技术能力，还会从产品、业务、沟通、事务推进等多方面考验其综合能力。而经历过大项目毒打的同学在处理别的问题时，会更加从容。

所以，如果你在实际的工作中，有机会参与或主导类似的项目大可放手一试，这样会极大提高你解决问题的能力。今天这一讲我想强调这样三个重点：

• 驾驭大项目是你的试金石和分水岭，对自己职业规划有一定要求的同学一定不要放过打磨修炼的机会。

• 在大项目中，往往人的问题会比技术与系统的问题难解决，因为与人相关的问题未必完全理性和逻辑，那么此时你也不妨看看感性的沟通与交流是不是有更好的效果。

• 时刻牢记你将项目按时上线没有故障只是做到了60分，更关键的是业务效果，所以除了盯紧开发过程外，还要在最开始的业务与产品设计阶段就投身其中。

留个作业：在你过往的大项目经历中，有哪些让你印象深刻的困难与问题，你是如何解决它们的，分享出来吧，我们下一讲见。