1.常规项目

技术团队的重心是把执行做到位，你要更关注过程管控，确保系统交付

2.大项目：

什么是大项目，他有什么特点

大项目时间投入大、人员规模大、系统更大，复杂度高，协同难度大，在成员的协同、事务的推进上也存在困难，而你要具备解决这些困难的能力

常见项目有：一号工程项目，系统重构项目，新产品开发项目，

去年在疫情期间完成系统重构，在多次封控的基础上，我们顺利完成重构系统上线，有些回过头，如果看看简单，如果这样想，再来一个大的项目，你来试试，你怎么入手的呢

二、大项目，抓住重点，谋定而后动

我认为越是重大的项目，在计划、设计、准备上投入的精力就应该越多，谋定而后动

我总结几点：

业务、技术、团队等几个方面，把 WHY、WHAT、WHO、HOW 问明白，想清楚

WHY（项目为什么做）。很多 Leader 因为习惯做执行和交付，或者觉得即使有不一样的观点也无法改变什么，所以并不热衷去探究项目背后的 WHY。不清楚 WHY，当你要解决困难时，就会缺少核心的逻辑依据，并且你很难识别真正的需求，很难判断业务想要的功能和想解决的问题到底是不是同一件事儿。
WHAT（项目做成什么样）。 WHY 是在确定项目的动机和目标，WHAT 是确定项目的具体形态，简单来说就是要做怎样的产品和系统来实现目标。比如每年的需求中，那些环节，严重阻碍我们业务开展，特别是新业务。如果参与这样的“ Super ”项目，你至少应该搞清楚以下两点。

WHO（哪些人来一起做项目）。很多问题不仅仅是系统的问题，人也是其中的关键因素，而你需要确定项目的核心人员并罗列项目所有的关联方。
HOW（启动项目后如何做）。明确了业务目标、结果期望和相关人之后，就进入项目的执行过程，在常规项目管理的基础上，你要注意这样两点。

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

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

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

三、如何处理棘手问题，

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

人才盘点，能力匹配，产品需求，目标管理，任务分解，团队氛围等，在这个过程千万不要加新人，不然越大越忙，不要搞大的培训，因为对时间，进度，成本等影响很大，要给方向，给方案
1.问题一：缺兵少将怎么办？
项目中人不够已经成了一个常态，比如部门内一套核心系统要重写，而团队无法一边持续迭代、一边在规定时间内完成重写，如果所有人 ALL IN 重写，系统迭代要暂停 2~3 个月，业务上无法接受。如果拉长周期，将重写项目持续半年，不仅会增加意外风险，并且很长一段时间内重写项目无法创造价值，会变成团队的负担。
如果你遇到类似的情况，需要在内部腾挪的同时，以项目的价值与收益为本金，借助上级组织的力量从其他团队借人。如果你有过“借人”或“被借”的经历，大概会对其深恶痛绝，因为这种方法会产生很多新问题，比如其他团队的同学不熟悉业务和系统（进入状态的成本很高），或者你们之间没有汇报关系，在工作安排和任务执行上并不通畅。
所以，我并不建议大项目时常通过借人来补充项目成员，人员的经常借调本身体现的就是权责不匹配，会导致一系列问题。好的方式应该是在组织内，让项目组的跨组织结构成为常态与共识，设计灵活的绩效、考核、汇报体系，让每个人都可以按需灵活地加入项目组。另外项目组人时你要注意以下几点。

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

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

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

最后，有时不仅要解决“缺兵”的问题，还要认真考虑是否“少将”？要充分考虑当前的人员是否适合做项目的 Owner，以我的经验来看，项目 Owner 几乎决定了项目成败的 80%，如果 Owner 能力不足，你要给予帮助和支持，或者另找他人，乃至上级的帮助，不要在 Owner 的人选上妥协，毕竟项目成败才是关键。
2.问题二：推不动的到底是人还是事？
你是否有类似的经历：一些功能或模块经常会出现大家都不做，要么抢着做的情况（比如双十一新增的活动玩法会让很多相关团队都做到自己负责的系统中），这会阻塞项目进展。
之前，我有很长的时间是负责公司的订单交易系统，熟悉这个领域的同学肯定知道，订单系统是一个大杂烩，任何业务都想加一个字段到订单表上。最开始，我经常会为了是否让一个数据加入订单系统而和别人争论，因为我担心不干净的设计会拖累系统的稳定性和可维护性。
由这两种情况你会发现，事情推不动的背后跟人和组织有很大关系，处理不当会加剧不同关联方的冲突，你必须处理好类似的问题，我提供给你 3 点建议。

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

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

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

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

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

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

项目变化和老板 CR 之所以难处理就在于它会打乱项目原本的计划节奏，本来一环扣一环的时间安排、人力安排、任务与模块安排都要重新编排、组合、解决冲突，单点的风险通过链路传递到整个项目链路上，产生了极强的联动效应。
我给你的建议是保持平常心，几乎所有的项目都会遇到类似的情况，出现负面情绪只会增加你解决问题的难度，你要做好两点。

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

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

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

四、总结

大项目是技术 Leader 的试炼场，不仅考验你的技术能力，还会从产品、业务、沟通、事务推进等多方面考验其综合能力。而经历过大项目毒打的同学在处理别的问题时，会更加从容。
所以，如果你在实际的工作中，有机会参与或主导类似的项目大可放手一试，这样会极大提高你解决问题的能力。今天这一讲我想强调这样三个重点：

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

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

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