书接上文：新晋总监生存指南三——OKR实践
如何追到一个女孩、如何进入一家公司、如何面试一个人、如何成为一个幽默的人、如何评价一个人、如何成为老马那样的人？
类似这种问题其实都是有迹可循的，不是说我们一定能成为像老马一样的人（其实就是不能），但是总有路径能让我们接近老马，比如成为老马的儿子。
所谓路径即“方法论”，掌握合适的方法论，能让你更容易追到这个女孩，如果追不到可能只是因为你穷。
言归正传，今天的目的不是教大家如何去追女孩子，毕竟那是一件非常简单的事情， 今天的目的是将之前带项目的一些经验分享给大家，并且希望这些知识对可以让大家后面少走一些弯路。
一、项目概述
所谓项目，即为创造独特的产品、服务或成果，而进行的“临时性”工作。
所谓项目管理，即通过运用管理的知识、工具、技能和技术于项目上，来解决项目的问题或达到项目的目标。
根据这几年的经验，项目管理事实上是一门实践的学问，正因为是实践而得来的，面对同样的场景，不同的人处理的方式会不尽相同，但是其基础的思维框架是大同小异的，只有通过不停的实践，才能真正掌握项目管理的精髓，成为好的项目实践者。
作为一个全局负责人的话需要特别有节奏感，这个节奏感，如王者荣耀打野一般，需要掌握大龙小龙刷新的时间点、需要在合适的时间点去推塔，也就是在正确的时间做正确的事情，暴露正确的信息，不要乱带节奏，导致团战失利，这个就是所谓的意识，这个意识，再说直白一点就是：对一件事的时间点（事件点）的敏感，而后对信息的正确处理。
着眼于产研的项目（适用于A级项目，更大的项目会更复杂），作为一个技术Owner（技术侧负责人）需要知道自己的几个发力点：
① 产品运营驱动
② 技术Owner驱动
③ 测试驱动
④ 商务运营驱动
⑤ Owner复盘
可以看到，事实上技术Owner的发力主要点应该是第二阶段，这个阶段也是信息对齐、需求梳理的重要阶段，早一步进介入，需求产出受挫容易白费力；晚一步介入，需求不清，会导致研发、测试走弯路而项目延期甚至流产，在合适的时间点将推动项目运行的主导权交给对应的队友，才更容易成功。当然从头至尾的信息传递、收集都是一个技术Owner需要做好的。
PS：这里以王者荣耀为例，前期是打野的节奏，因为打野大局观最好；后期是法师和射手的节奏，因为后期要团战，就算1V1，刺客也未必打得过射手了；前期刺客不抓边、后期刺客非要单杀，都是在丢失节奏。
以一张业内草图做说明是：
技术Owner的职责主要在实施和控制这里，这里我们最常见的问题也出来了：
一、需求变更致项目风险极高，比如：
某次项目由于时间特性，项目截止点早已确定，却产生了6次大的需求变更（小的修改太多，无法统计）、需求评审7次，所有的这一切极大的加大了项目风险。
从这次项目的实践数据来说：一阶段功能就有84个BUG，二阶段功能竟高达210个BUG，历史罕见而又符合预期
我们要如何应对这种时间点固定，上游需求不停更改的项目？
二、资源变更致项目风险高，比如：
某项目在项目开始接手时的优先级很高到最后要为营收类需求让路，资源被抽调到更高优先级需求，打乱排期而没有重新订立新的基线，对项目管理整体而言是致命的，其风险见：
要如何应对这种资源不足的情况？
项目中会遇到的问题太多，我们在文章中尽可能的覆盖，所以来解决问题吧！
如何立项获取资源
做项目之前，第一要务是抓人，没人一切都是空谈，不同的团队获取资源的规则不同，一般来说有两个方式可以要到资源：
一、以OKR的方式组织人员
OKR从机制上说强调的是上下左右对齐，只要你真的了解团队的痛点，又有解决这些痛点的目标，那么对这个目标有兴趣的同学可以自主加入，这里的流程是：
① 提出OKR
② 对齐OKR过程中吸引相关OKR人员
③ 形成OKR 项目组
④ 开始执行
二、以立项的方式组织人员
如果目标是独一份的，没有人有与你相同的目标，而你的目标又具有战略性，并且足够重要，那么这个时候就可以走申请立项的流程：
① 准备你的方案
② 拉管理层讨论方案
③ 确认项目周期，周期目标以及资源投入
④ 各团队准备资源
⑤ 形成项目组
⑥ 执行&复盘
三、公司级项目
这类自上而下的工作类项目，一般而言，资源是可保障的。
项目组成立了，但是很多队友的能力情况，我们并不清楚，这个时候该怎么办呢？
一、这个时候建议你先直接听取其经理的建议，然后持续观察，了解队友的真实实力，再做合理的安排！这里主要考察执行力即可：
二、没有人能一打五，信任你的队友，不同的角色有他该有的责任！
三、让专业的人做专业的事情，不要不懂装懂瞎指挥。不要去质疑专业同学的内容，因为你看不懂，你需要关注的是他的进度！
二、项目启动模板
从执行角度看，一个项目的完整周期是这样的：
项目是十分复杂的事情，而刚好这件复杂的事，还会涉及非常多的人，本来要做好一件复杂的事情就很难了，然后一件事情涉及的人越多，那么会更难：
除了事情本身专业度所带来的困难，一般来说最大难度来源于两方面：
① 沟通过程中产生的信息不同步
② 做一件特定的事情（一类事情），总是会出错
所以我们需要相对完善的方法论降低这种难度，首先我们需要一套【机制】来保证我们多数的信息的上下文，以便我们要追溯某一段信息的时候无从下手；其次我们需要一类清单，这种清单记录了我们之前做某一类事情犯过的错，清除所有的错误可能，那么我们就会更容易达到成功，所以这里给出了项目启动模板：
标红的部分是必须提供的，有了项目启动模板后，我们会将之前的项目思想打散到这个机制中，让你不知不觉便掌握我们所谓的节奏感。其中项目日历大概如此：
三、确认风险
综上所述，项目旁枝错节过多，一个技术Owner想要把握每一个细节无异于痴人说梦，这里便要求相信队友（PS：王者荣耀再牛逼的英雄也不能一打五！）。
但是相信不是不作为，在我看来，一个技术Owner的80%精力应该放到最重要的风险管理，项目初便需要确认项目的风险点！！！
确认风险点，规避风险点，设计风险已发生的解决方案，是一个项目的重中之重！！！
那么，如何规避风险呢？首先得找到风险点，于是需要定义什么是风险点。我们做一个项目，需要穷举（尽你之能）什么是我们绝对不能接受的情况，这个可以是：
① 项目延期XX天（会不会延期、信息不同步等等因素）
② APP崩溃
③ 订单不能支付
④ 某页面打不开
⑤ 充值有漏洞
⑥ 结算延迟超过底线
⑦ ......
不同项目会有不同的风险点，首先穷举这些风险点，然后再看看我们要处理哪些风险点，这里的规则是：这个事情会不会发生，如果发生你能不能承担。
一旦确定要处理的风险点后，那么技术Owner的工作便已经确定下来了：解决掉所有的风险点，其他全部交给队友（风险点产出时间见上面最复杂那个图）
这里担心各位疑惑，再啰嗦几句如何确认风险点：
① 项目初期，根据过往经验（有些项目是周而复始的、有些项目是同一类型的），判断可能会有什么问题（技术Owner越高阶，此能力越强），开始私下拉人讨论方案
② 技术评审阶段，让所有同学提出风险点，最终确认项目日历
③ 评审结束后马上整理所有风险点，并且私下了解细节，再拉风险评估会（技术评审后一天内），与队友确认风险点，并要求队友提供对应方案
④ 如果风险点技术侧不能绕过，马上拉运营、产品商量规避方案
⑤ 如果不能完全规避，与对应同学设计如果已经出问题的项目补救方案，和触发机制
这里会有很多的案例，都有环境因素不方便提出，大家可以*整理自己公司的案例。
当然，虽然我们期望能前置所有的风险点，但这往往是不可能的，风险可能在项目的任何阶段（包括结束阶段）爆发，所以项目日会很重要！！！
四、项目日会怎么开
所谓项目日会，也是执行日志（用以追溯整个项目）重要的内容来源，很多同学常见的问题是：日会时候各自说下你做了什么，我做了什么，然后自以为是的拼出了一个“虚假的”项目完成度，这是大错特错的！
项目日会的真正意义是用来暴露风险的！或者说项目日会是用来帮助你梳理项目风险点的，这里真实的流程是：
① 开项目日会，对照项目日历（时间表）看看今天应该达到什么进度
② 哪些模块晚于这个进度，找出为什么
③ 清理出要帮助那些队友的清单，并且当天重点帮助解决
④ 如果日会暴露出项目风险点，必须马上升级
⑤ 不停的处理日会中暴露的清单
其中很关键一点是确定谁在什么时间点达到什么！并且我们需要记录项目过程指标数据：
如此一来可以反映出当前真实的项目状态，大家也知道症结点（风险点）在哪，而技术Owner需要将更多的精力投入到这个风险点，如此下来可以进入项目提测阶段，技术Owner需要将节奏点的大棒交给测试同学了。
五、测试阶段做什么
开发联调结束，终于进入了测试阶段，这个时候研发同学很难再自己找出问题，技术Owner同学也不需要对着case一个个过，但是这不代表技术Owner的工作结束了，他需要做的事是：
① 通过测试同学的视角找出当前项目的风险点是什么，纳入日会todolist，然后去解决
② 站在研发的角度协助测试同学补足测试方案（可能不需要），因为测试同学可能会因为环境问题、数据问题、边界问题无法完整覆盖整个case，技术Owner要带领研发同学补足测试同学的短板（可能没有短板，那当然最好）
这个阶段结束后，便需要进行非常重要的预演环节
六、如何预演
预演是非常重要的环节，很多bug都可以在预演环节被干掉，这里不是因为测试同学不努力，不能把那些BUG过掉，是因为：
① 预演环境有真实的庞大数据
② 预演环境的能还原真实的QPS，会覆盖掉很多边界场景
③ 有些测试必须在生产环境进行
④ 预演需要做方案，不能引起线上脏数据
有了这些东西就可以进行预演了，然后这里有一个最大原则：预演请务必尽可能还原真实场景，包括时间点的设置！！！
预演前，越是紧张的时候越是容易出错，所以我们需要准备一个上线清单&执行流程，他大概长这样，可以设置得更严格：
这里再突出强调下几个点：
① 尽量还原真实场景，特别是真实还原时间要求，如果一些环节涉及人太多需要重复进行
② 一旦确定执行流程，拒绝任何骚操作，拒绝任何加塞！！！
至此一个项目就接近尾声了，我们便会进入复盘环节
七、如何复盘
复盘相关的文章网上居多，比如这个很好：
https://www.jianshu.com/p/48a37c310639
这里而外提一点就是，很多技术Owner的复盘只是到执行侧结束便停止，也许可以将目光看的更远，除了业务侧，也需要知道项目侧的复盘。
八、结语
至此，项目执行指南的主要部分介绍就结束了，带项目如打游戏，是一个人能力的体现，这个能力包括：
① 实际能力水平
② 个人魅力（势能），比如梦泪打野辅助就跟愿意跟随
③ 环境（团队）加成
结合之前的文章，我们放出一张图：
不同的项目需要不同的能力与势能，要带好一个项目，大家可以从这方面努力。抛开基础能力问题，做成一件事最重要的就是持之以恒的认真，而能力的进步也是源于此。
“我只是个举人出身，出生于海岛蛮夷之地，没有你谭子理的举荐，我连区区七品县令也当不上，最多当满这届南平教谕就回家侍候老母了。我不明白，赵中丞、谭大人你们何以把我海瑞看得如此之重！”“无非是我海瑞办事认真而已。”
——大明王朝
这里再回顾第一篇中的五维能力模型，持之以恒，这个可能会影响我们走到什么位置吧。工作中有很多不平事，成为某个关键角色后也容易产生很多委屈，事实上我有时候也非常负能量，及时排解即可。
九、QA案例库
9.1 项目出问题怎么办
Q1：想知道面对陌生的环境下，时间紧，人不足，所有人做的事陌生，风险点评估不全，这种怎么带，如何把控。
Q2：1.在高压时如何处理团队的负面情绪（如何协调好团队分工）2.如何收集项目数据（维度）3.怎么感知风险
多数同学都是王者荣耀玩家，这个问题其实就是在说我们面对逆风怎么办？那么逆风翻盘的常见错误是：
一、 任何形式的放弃
包括放弃技术评审、放弃风险预估、放弃技术方案，越是逆风的情况下，关键的风险预估越是必不可少，因为所有的必要步骤都是对你项目失败的兜底方案，只要你一个个放弃这些兜底，那无异于在裸奔，失败的风险大大提高。
这里一个真实案例是之前一次重要项目，由于项目资源紧张，核心开发技术方案迟迟不能给出，一段时间里面甚至想放弃写技术方案，直接上手代码，这里可能的风险是：
① 项目压力大的时候容易做错误的决定
② 没有技术方案，就是没有计划，没有计划的事情失败的概率会高很多
③ 在极大的压力下，失败的第一步会导致持续的失败从而引发雪崩
我们当时的处理方式是，与王者荣耀的方式是一样的，法师死了（该同学时间不够），打野（技术Owner）补位守中塔（想方案），等他复活（缓过劲来）。所以很多边界问题、困难的点，已经由技术Owner帮助补齐，不至于让这条线成为败因。
在这个案例里面技术Owner的补位非常关键，而技术Owner补位的前提是：
① 提前梳理项目风险点，知道哪里容易成为突破口
② 技术Owner深入业务，而不是瞎指挥
二、任何形式的团队内讧（甩锅）
王者逆风不重要，队友心态很重要，一旦队友心态崩了，那么马上就会引起吵架，整个团队散了，失败也就不远了：
真实案例抽象，有个项目选取了不是最合适的技术Owner，所以有了这个故事。
小王第一次做技术Owner，十分想做好这个事情，但是他势能不足，所以团队的小伙伴有些我行我素，弱小的小王尽力的推进着整体项目，但在执行过程中依旧出了很多问题，于是他跟组员在群里吵起来了，双方经理看不下去，也加入了争吵的队列，这里的两个点是：
① 技术Owner认为对应同学对项目不上心
② 一线同学觉得技术Owner不懂瞎指挥
双方经理也各执一词，执行情况十分糟糕，最后项目也出了一些事故，大家都收到了惨痛的教训，回顾这个事情，这里就出现了几个关键问题：
① 执行不当，没有提前找到项目风险点，或者说之前的兜底方案不足，也没人补位，项目进入逆风。
② 逆风时候，整个项目成员开始甩锅吵架。
③ 技术Owner这里不出于大局的考虑，稳住团队心态争取最后的胜利，而是开始抱怨委屈加入战斗（我尼玛4-8的开局被你们这些犊子拖成这样？）。
④ 双方队员教练（经理），没有去协助稳住局面，而是加入了甩锅、吵架环节。
有了以上表现后，这个项目多半是做砸了，我们这里比较好的情况是，更高的leader乃至教练介入，将纷争抹平了，最后项目顺利上线，后面虽然出了一些问题，但整体项目成员的心态已经好了很多，所以解决这个问题的方案是：
① 技术Owner决不能参与吵架，更不能甩锅！！！leader绝不允许加入战斗！！！！！！
② 在团队逆风或者出现矛盾时，更多的去发现项目风险点，解决项目风险点
③ 当技术Owner感觉控制不了局面时要及时上抛问题求助
总而言之，败方MVP无意义！
9.2 团队逆风怎么办
Q1：人的因素，例如如果一个项目有新人该怎么处理，技术Owner本身节奏有问题该怎么处理？技术Owner的时间分配，技术Owner期间时间是被打算的，不好安排自己的工作。
Q2：1.在高压时如何处理团队的负面情绪（如何协调好团队分工）2.如何收集项目数据（维度）3.怎么感知风险。
前面大概回答了一些这些问题，这个问题很典型，为了规避工作敏感性，这里依旧从王者的角度来说，需要两个层面的能力：
① 意识能力
② 操作能力
比如如何感知风险是常见的意识能力的体现；如何做时间管理就是操作能力的体现。这样说依旧有点虚，这里做一个类比，意识能力的四个维度是：
① 你知道草丛里面有人，所以你不进去
② 你知道草丛里面有人，并且有什么人，所以你不进去
③ 你知道草丛里面有什么人，并且你告诉了你队友
④ 你知道草丛里面有人，并且告诉了队友，并且制定了合适的战略取得了成功
而操作能力的维度是：
① 队友告诉草里有人，但我脑袋一热非要冲过去，并且死了
② 队友告诉草里有2个人，我评估了自己的操作水平，冲了上去并且死了
③ 队友告诉草里有3个人，我评估了自己的操作水平，对面的经济情况，依旧冲了上去，并且拿了三杀！
意识好便不需要以少打多，很难进入逆风；操作好就算进入逆风也能Carry全场，但是任何形式的死扛都是有风险的，没人能一打五，思维一定要清晰，所以意识 > 操作
而好的技术Owner对意识、操作有一定要求！
上面的回答很简单，但是提的问题却很复杂，相当于一个白银的同学问王者，你为什么知道草丛里面有人或者你为什么能一打三？
回到项目，为什么有些技术Owner能够很快发现项目的风险点；又为什么有些技术Owner能轻松化解项目中的风险点，这里有两个答案：
① 第一个很简单，多带项目，多看复盘
② 第二个很复杂，需要天赋，提升软素质
正如一般同学上王者很容易，但上王者百星很难是一个道理，没有什么事情能一蹴而就，我的知识，说一次也不能变成你的知识。
可以做的就是提供更多已经实践的方法论，留给有心的同学去学习，比如这篇文章。
前面是在说一个技术Owner如何不会崩（其实整篇文章都在教大家如何不要把项目带崩），这里的主旨依旧只有一个：提高意识，提高操作，更落地一点的回答是提前找到你项目中的风险点，并且干掉他。
但不可避免，我们依旧会遇到技术Owner已经崩了的场景，正如上一个大问题所述，这里事实上我们是有一个机制的，要么技术Owner自己会上抛风险，要么我们测试的同学会上升风险，如果我的李白已经不能翻盘了，那么就让梦泪来操作我的李白吧，也就是换他的leader给他兜底！
9.3 如何处理三方依赖
Q1：方案设计时遇到问题：A、B两个方案都可以满足目标。A：偏一次性方案；B：通用方案。工期都满足的前提如果选A，后续功能开放，又需要额外的重复工作；选B，执行方不一定有动力，推进阻力大
这个问题看上去很简单，处理的时候却很复杂，这里问题稍微升级就变成了，项目要不要做基础技术建设？更夸张一点，我要用Word要不要开发操作系统？
PS：这里YY的一句就是，100个顶尖科学家回答古代也很难产出，原因便是三方基建依赖。
其实答案很明显，站在技术Owner的角度，任何可能引起风险的因素都应该被干掉，所以是不做；但是站在更高的角色来说是可以做，只不过是什么时候做罢了：
① 项目资源宽松则规划做起来
② 项目资源紧急，则复盘后规划做起来
处理的三大原则：
① 你的项目不应该推动“其他项目”建设（例：活动不应该推动基础能力建设）
② 如果“其他项目”是你项目的关键实现路径，那么你必须推动其实现。规则二大于规则一
③ 如果“其他项目”一些特性不是你的项目依赖的，那么不做处理
这个问题再引申一下是，如果第三方项目出了事故怎么办，这里的回答是：
① 如果你依赖的“其他项目”核心路径出问题，需要你推动处理，如果是因为你的项目而开发的模块出问题，需要共同承担
② 如果“其他项目”由于历史问题出问题，影响你的项目，需要push处理，他们自己承担后果；如果不影响你的项目，需要善意提醒即可
之前leader有一句话我很赞同：
主责对齐根因，整套惩罚方案看价值导向。前一句是法理，后一句是引导，引导是众多利害之中，让群众关注什么，前者看历史，后者顾未来
如果“其他项目”是你项目的核心依赖项目，那么该项目便是你项目的子项，你对“其他项目”参与配合的同学有绝对的“使用权”，你可以要求他放下其他工作，而专注于你的项目，除非得到你的允许
如果你的项目获得了什么荣耀，那么你核心依赖的项目也应该共享该荣耀
9.4 如何处理事故
虽然学了很多方法论，却依然出了事故，这个时候大家不要灰心，放平心态即可，因为一个项目越大出事故的概率越高，到一定规模的时候，不出问题反而是奇怪的。要做的是不在同一个地方摔倒（事实上还是容易在一个地方跌倒，原因是那个地方就是容易跌倒......）！
出问题是不可避免的，一定要复盘反思当初哪一步决策走错了，再给一次机会能不能更好，下次突发了能不能快速carry。
虽然出事故不可怕，可怕的是我不知会出什么事故，所以事故需要分为两类：
① 在项目过程中整理出来的项目风险点
② 预料之外的事故
这里处理的办法是，如果是预期中的风险点，那么在【技术评审】后一定会有【风险评估会】来处理这个问题，如果评估不能规避，那么就需要提供已经成事实的项目补救方案，这个时候出事故便按照补救方案操作即可。
比较难办的是出现了不可预知的事故，这个时候的处理原则可以是：
① 及时上报
② 及时集合相关同学商量初步方案
③ 以对用户影响最小的方案执行，技术Owner要敢于背锅，敢于下决定
④ 收集足够的信息，为恢复问题做准备
⑤ 复盘，规避类似问题发生
这里需要注意一点是：不同公司处理方法论不一样，切不可生搬硬套！
9.5 复盘做了那么多，有用么？
Q：复盘本意是好的，但是怎样付诸实践我觉得更重要，希望在文档里面列一些比较实际意义的案例，怎么解决此问题
这个问题是很多同学的疑惑，这个问题其实引申一下就是，我做了那么多CaseStudy（后续有文章介绍），又有什么用了呢？
抖机灵的说法是：容易在一个地方跌倒，原因是那个地方就是容易跌倒......
进一步探讨，一线同学的意识形态比较低，会更关注在具体问题本身，或者如何解决特定的问题，这个可能会导致一个错觉：CS的会上，有很多大佬们的正确主义，基于正确的道德制高点，提出的绝对正确的废话，这种东西似乎对一线同学指导意义是有限的。
这种认识一定在我们一线的同学中存在，如果不存在大家都是leader了，比如有多少同学会认为这篇文章是无用的废话呢？
正是因为我们做了很多复盘、CS，我们才会沉淀更多的方法论。
所有的这些东西，都是需要大家把自己的视角往上提一个层次才会有用，带有关注的眼光才能发现很多事物真正的价值。
很多一线的同学看到了在一个复盘、CS中的一个具体的问题没有去解决，但是大家没有意识到，这里主要的原因是解决事件层面的问题多数时候是无效的，比如此图：
规则如此，一旦有外部刺激就一定会出事件，正如红灯停，做项目就一定有BUG一般。
这里的点是，管理不会解决你看到的这一个问题，管理会设法去解决这一类问题，或者是大家都忘了，需要提醒，所以重复的CaseStudy才会不停的上演，因为大家还需要努力，CS以及复盘todo也确实为部门宏观建设提供了信息输入，而这一切中很大一部分其实是偏自律、个人问题导致的部分，当事人自身应尽的责任或义务或规范或标准，不能完全期待管理给出解决方案，这也是为什么会有上文中的OKR：
OKR的意义是帮助团队培育目标导向与结果意识，并且加强我们的跨部门合作，进一步帮我们识别团队中隐藏的潜力股（人才），并且给他们塑造表现自己的舞台
于是在以人为本的前提下，这句话就是团队中核心的人才会提出帮助团队前进的目标并获取资源执行，而比较功利的说法是提出好的OKR并且成功获得资源执行的人会成为团队核心人才，这里的需要我们思考的点是：
① 好的OKR需要善于思考并且真实了解团队痛点的人提出
② 团队资源是有限的，所以只有好的OKR才会获取资源并执行下去
9.6 需求频繁变化怎么办
需求变更，在每一个项目中不停的上演，这个是上游项目把控不力的表现，而所有的这一切被技术Owner给C点了，事实上是技术Owner在补位
虽说如此，正如不会出现不出事故的项目一样，也没有需求能做到100%完整。
我们要如何应对这种时间点固定，上游需求不停更改的项目？
解决这个问题的方案其实更简单，两个字足以：加班
如果加班不足以解决问题，那么需要向上申请资源，如果项目足够重要，那么上游会给予你足够的资源。当然，加班也是不可避免的
原则很简单（上游并不是不讲道理的）：
① 你影响我项目的总体目标就做二期
② 如果不是核心功能，我不会给你加
凡是预则立，不预则废，可以有一次项目频繁变更需求，如果这个是常态的话，就需要复盘，那么这个团队往往就会出问题或者出现变革。
另外，要提前切入业务方，做一个研发接下来的季度乃至半年规划，前置准备，包括技术、流程和组织结构的准备，不要到业务来时溃不成军。