24 | 3C方案设计法:怎么让你的方案有理有据?

2021-01-25 李运华
大厂晋升指南
进入课程

讲述:安晓辉

时长11:44大小10.76M

你好,我是华仔。
上一讲我介绍了用来制定工作规划的 OKR 规划法。在完成事前规划之后,我们就到了事中执行阶段。
在执行阶段,你可能经常遇到这样的情况,领导审批或者跨部门同事协作的时候,别人对你的想法提出挑战。
比如你提出了一个方案,其他人针对你的方案提了很多疑问,而这些疑问确实是你在做方案时没有考虑到的;或者有人提出了其它的方案,你一时也无法明确地证明你的方案优于别人的方案。
所以在一开始的时候,你就要设计出有理有据的方案,这样才能让别人更加理解、支持和配合你。

3C 方案设计法

要怎么设计呢?我总结出了一个 3C 方案设计法,也就是每次做事的时候都至少设计 3 个方案,然后选择最优的 1 个或者几个方案去执行
这里的 C 代表 Choice,选择。
3C 方案设计法最典型的应用场景就是基于上一级的 OKR 来制定自己的 OKR。
比如你是负责买量的运营人员,你的 Team Leader 基于上一级业务 OKR,分解出运营团队的某个 KR 是“新用户买量 60 万”,现在交给你来负责执行。
你会发现买量的渠道有很多种,包括抖音、快手、头条、百度、QQ 和微信等。不同的渠道用户特性不同,方式不同,投入产出也不同,你不能每个渠道都买一点,而应该聚焦几个效果好的渠道。
但到底哪几个渠道才是好的呢?你不能简单地凭感觉拍脑袋,而应该有理有据地推导出来。
具体来说,就是提出不同渠道买量的方案,对比这些方案的优缺点、投入成本和买量效果等。如果最后你判断“抖音买量 50 万”和“百度买量 20 万”这两个方案比较好,那么就把这两个方案作为自己的 KR。
向上汇报的时候,你一定会遇到很多挑战,比如“为什么是抖音而不是快手?”“百度的优势在哪里?”
但是这些问题你都有答案,因为你使用 3C 方案设计法的过程,其实就是在不断澄清各种可能的问题。
当然,3C 方案设计法不局限于业务规划和业务方案设计,它也可以用来做技术方案,也可以用来做管理方案;既适合比较重大的事项,也适合日常的判断选择。
下面是几个应用的实例:

三个阶段选出最终方案

3C 方案设计法的使用过程可以分为三个阶段,每个阶段都能够从不同的角度帮助你完善思考,提升方案的说服力。
第一个阶段是预研阶段,你需要设计出 3~5 个备选方案。
这个过程会促使你思考多种可能性,避免思维狭隘错过了更好的方案;而研究不同方案的优缺点可以帮助你系统理解某个领域的知识和技能。
你可能并不一定能很快想出 3 个备选方案,这恰恰说明你对当前的领域或者事情还没有全面的理解和思考,你需要强迫自己一定要想出 3 个备选方案,这个探索的过程就是一个自我提升的过程。
第二个阶段是讨论阶段,你需要把备选方案向上级汇报,或者给其他人评审。
这个过程会让其他人的信息、观点和疑问输入到你的大脑中,进一步全面完善你对每个方案的优缺点、依赖条件和所需资源的理解。
第三个阶段是决策阶段,你需要挑选出最终的方案。
一般来说,如果是互斥的方案,那么选出 1 个最优的落地就行了。
比如新招聘的员工表现不太理想,方案 1 是“立即辞退”,方案 2 是“不辞退,加大培养力度”,方案 3 是“延长试用期 1 个月”,你最终只能挑选 1 个方案落地。
如果是可以并行的方案,那么“3 选 2”或“5 选 3”也是可以的,但是不建议“3 选 3”或“5 选 4”,因为这样执行的时候会没有重点。
列出一些备选方案,只能说明你对领域有一定了解;选出合适的最终方案,才能说明你已经掌握了这个领域,能做到理论和实践相结合。
决策的过程会让你重新审视自己原来提出的方案,尤其是最初倾向的方案,帮助你发现方案的问题、理解的问题、乃至自己决策标准的问题。

3C 方案设计法会耽误效率吗?

你可能会担心,每次都要做 3 个方案,要花不少时间吧,这个 3C 方案设计法会不会耽误做事效率啊?
其实这是一种片面的理解。
首先,虽然前期准备的时间变长了,但是做一件事的整体效率变高了。
“前期匆匆忙忙赶工,后期急急忙忙返工”,这样的情况你肯定遇到过吧?
如果你在前期预研的时候先选出更好的方案,那么更有可能一次就拿到好的结果。一次就把事情做好,肯定比重复好几次效率更高。
其次,虽然负责人投入的精力变多了,但是整个团队的效率变高了。
“方案潦潦草草,讨论轰轰烈烈”,这种情况你肯定也深有体会吧?
如果负责人在设计方案的时候投入更多的精力,那么后续整个团队讨论决策和执行的效率都会提高。
正是因为考虑到效率,3C 方案设计法才提倡准备 3~5 个备选方案。
如果超过 5 个,讨论和决策时需要投入的时间和精力太多。但是少于 3 个也不好,1 个方案容易出现思维狭隘的问题,2 个方案容易出现选择困难的问题,所以说:
1 个方案是陷阱,2 个方案是困境,3 个方案是选择

对晋升的帮助

我指导团队成员晋升或者自己担任晋升评委的时候,经常遇到这样的场景:
申请者在自述环节自信满满地介绍他做过的某个漂亮的项目,列出了 3~5 个闪光点,并且贴出了详细的数据来证明效果。
然而到了答辩环节,评委只是简单地问了一句“你为什么采取这个方案”,他就卡住了,要么支支吾吾,要么就说一些比较虚的内容,比如这个方案性能高、可靠性高之类的。
然后评委再问一句“性能有多高,跟谁比性能高”,他就彻底答不上来了。
有时候我甚至能从申请者的眼中看出不可思议的表情,仿佛在说:“采取这个方案不是自然而然的吗?还有什么为什么啊?我都列出了这么多优点,选这个方案还用说吗?”
他们当中的大部分人在晋升失败后,都不会认为是自己专业能力不行,而会觉得是自己的口才不行,临场反应不好,甚至有人真的开始去买本书来尝试提升自己的口才。
其实这样的理解是错误的。明明是自己做得很漂亮的事情,结果却在晋升的时候答得不好,根本原因不是口才问题,而是在做事的时候没有深入思考和真正理解。
我也见过所谓口才好的申请者,临场反应能力很强,随便问个问题都能说上 2~3 分钟。但是在评委听来,他说的内容完全是临时拼凑,甚至是瞎扯淡。
有时候评委实在受不了了,还会直接打断正在滔滔不绝地讲废话的申请者。
与其这样回答,还不如直接说不知道。
站在评委视角看,他们在判断申请者能力的时候,需要甄别把事情做好的真正原因
是因为他自己掌握了相关能力?
还是因为有个厉害的主管直接告诉他怎么做?
又或者是他直接照搬了其他项目的经验?
甚至只是因为他这次运气好?
……
而最常见的甄别方法,就是问“为什么”
为什么你采取这个方案?
为什么你觉得这个方案好?
为什么不采用另外一种方案?
为什么有某某缺点你还是选择这个方案?
……
所以,如果你想提高自己的晋升成功率,首先要认识到回答问题不能光靠临场反应,更重要的是在平时做事情的时候就要逐步积累,正所谓“台上一分钟,台下十年功”。
晋升答辩的时候,在评委看来:
你能够想出 3 个以上的方案,说明你对领域有系统和全面的理解,或者做事考虑非常周全;
能够详细的分析多个备选方案的优缺点,说明你对领域有深入的理解;
而能够从多个方案中选出落地的方案并最终拿到结果,说明你有一套成熟的评价标准或者原则,展现了你的决策能力。
有的主管可能只是简单地跟你提出“你要加深理解”“全面思考”“深入思考”“明白背后的原因”等比较虚的要求,你听完后还是一脸懵逼。
但是学完这一讲,我想你就知道应该怎么做。只要按照 3C 方案设计法来做事,就自然就能满足这些要求。
我曾经带过一个团队成员,他之前 3 次晋升 P7 都失败了,自己总结的原因都是“太紧张了,口才不好”(他确实比较腼腆内向一些)。
我跟他指出,口才不是关键原因,关键是平时的思考和积累太少,然后在接下来的一年里严格要求他按照“3C 方案设计法”来实践:
重大技术方案设计要做 3 个备选方案
团队管理相关的措施想三个可选方案
每年的团队规划方向也要求想 3 个
一年之后,他再次申请晋升,答辩结束后他就跟我说:“我不怎么紧张了,因为大部分评委的问题,我平时自己都已经想过了。”最后果然顺利地通过了。

小结

现在,我们回顾一下这一讲的重点内容。
3C 方案设计法就是每次做事的时候都至少设计 3 个方案,然后选择最优的 1 个或者几个方案去执行。
3C 方案设计法分为三个阶段,预研阶段设计出 3~5 个备选方案,讨论阶段把备选方案向上级汇报或给其他人评审,决策阶段选出最终的方案。
3C 方案设计法的好处包括:帮助系统地梳理一个领域;对每个方案理解得更全面;发现最初的方案和决策标准的问题;提升整体流程和整个团队的工作效率等。
评委在晋升答辩时喜欢问为什么,是为了甄别你把事情做好的原因。按照 3C 方案设计法来做事,就能在平时的工作中逐步积累,提前想好评委问题的答案。

思考题

这就是今天的全部内容,留一道课后思考题给你吧。假设主管给你安排了一个研究某个开源项目的任务,但你手上的业务开发任务又很重,请按照 3C 方案设计法来 3 个应对方案,并给出最终选择的方案和理由。
欢迎你把答案写到留言区,和我一起讨论。相信经过深度思考的回答,也会让你对知识的理解更加深刻。
unpreview
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
上一篇
23 | OKR规划法:Team Leader 怎么做团队规划?
下一篇
25 | PDCA执行法:怎么推动落地才能“步步为赢”?
 写留言

精选留言(8)

  • 2021-01-26
    1. 优先级调度,先做价值最大的端到端任务,在做低的任务,优点:保证利益最大化,缺点:另一个任务饿死导致落地推迟。
    2.权重调度,按照重要性的比重分配资源,两手同时进行,优点:一方都不会饿死,缺点:完成的时间相对拉长,前提条件是任务需求没有那么紧急
    3. 增加人手资源:两个任务都能得到调度,并发执行。优点:两者可以很快落地 缺点:成本增加
    展开

    作者回复: 挺好的分析,具体选哪个的话还要结合实际的情况来做判断。

    2
  • 2021-01-25
    1.制定开源项目和开发任务的优先级,先做优先级高的,再做优先级低的。
    2.告知领导手头任务重,能不能研究开源项目的任务先交给其他人做。
    3.合理分配时间比例,规划好两个任务每周的进展,按照规划方案进行工作。
    展开

    作者回复: 第1个方案的关键点就是你自己要给出哪个优先级高的判断。一般来说开发任务是紧急不一定重要,开源项目研究可能是重要不紧急。

    第2个考虑不太周全,将开源项目研究任务“先”交给别人做,后面就算你有时间了,也不太会交给你做,所以可以稍微调整一下:将已有的开发任务分一些给其他人。

    第3个比较虚,应该要明确具体如何“合理分配”,然后再看是否可行。

    3
  • 2021-02-07
    有个问题,设计系统的时候,主体架构只能想到一个方案,也需要有3C吗?具体实现方案可能有3C,但实际情况是,第一反应就只有一个选择,其他的已经默认排除了,这种情况应该怎么做?

    作者回复: 这就是有问题的,为什么默认排除了呢?排除的理由是什么?
    这样做很容易出现文中说的现象,别人对你的方案提出很多质疑和挑战

  • 2021-01-29
    1.若该开源项目应用到核心系统,是业内主推技术,相对于手上业务重要,可以将手上的事情整理好,交接给其他同事,自己全力投入。
    2.若该开源项目不是很重要,可以将开源项目安排其他同事,自己仍然主要投入在开发工作,定期关注开源项目进度。
    3.若开源项目,和开发任务都很重要,自己两个都想尝试,可以拉人一起,一边将开发项目部分分出去。另外来源项目,也可以分部分出去。两个都定期跟踪进度。
    展开

    作者回复: 第2条不妥,主管安排给你,你直接又安排给别人,这样的话为何主管不直接安排给别人呢?

    主管安排给你一般都是有原因的,尤其是你的任务比较紧,主管其实也知道的,这种情况下还是安排给你,你可以想想可能的原因。

  • 2021-01-27
    1. 自己做:跟主管沟通看下手上的业务开发任务是否可以拆解,排优先级,分段上线,比如本来要1个版本全部上线的,能否拆成两个版本,或者先简单做,后面再迭代优化,匀出一部分时间来研究开源项目;
    2. 给别人做: 和主管沟通,说明自己手上的业务开发任务重,无法兼顾,能不能把其中一项任务交给其他人;
    3. 和其他人一起做:拆分业务开发任务和开源项目研究具体事项,结合小组其他成员的工作量,看下哪些可以给团队小组的其他成员分担的。

    优先选择方案3,原因:1. 不影响业务功能上线;2. 团队成员一起参与开源项目的研究,后续如果要引入该开源项目或者向该开源项目借鉴的话,团队成员都已经比较熟悉该开源项目了,减少培训的成本
    展开

    作者回复: 方案1的话不太具备可操作性,一般来说站在业务方和项目经理的角度,不太能够接受因为这样的原因而重新安排业务。

    方案2你最好明确要将哪项任务给别人做,你可以结合自己的晋升需求来看,如果研究开源项目对你晋升作用不大,也可以交给别人。

    方案3分析不错。:)

  • 2021-01-27
    1 先进先出:先完成开发任务,再完成开源项目。优:不会出现上下文切换,专心完成一件事再做下一件事效率高一些。缺:如果开发任务没有研究开源项目那么重要且紧急,产出的价值就不是最高。
    2 按照重要紧急划分,优先做重要紧急的。如果开源项目是重要但不紧急,而开发任务紧急但不重要,那把开发任务进行拆分,拆分成一部分给其它人接手。或者拆分开源项目的研究内容,并分工合作。优:自己能给公司产生更大价值。缺:如果拆分开发任务给其它人做的话,其它人要熟悉需求背景和开发进度,整体效率没那么高。
    3 后进先出。优先做最新被安排的事情。没想到有什么优点。缺点:最早被安排的那些事可能一直完不成。
    综上所述,方案2更合理一些,因为产出价值更高一些
    3
    展开

    作者回复: 分析的不错,最终选方案2是比较合理的

  • 2021-01-26
    1.把自己手头上的任务与新任务的收益作一个排序,看那一个因子最大,按这个排序来进行时间排期,给出一个任务完成时间的排期;
    2.新的开源技术进行拆分,分成几大块,按组内人员感兴趣的认领,按所需的时间,定出每天或每周的技术分享,落到实处,把优缺点分析以及与当下如何与业务结合的点做出来;
    3.看下现在公司内或业界有无分析和应用场景,有技术大会的参加大会、有已应用的可以请相关技术来公司做下分享,快速了解技术,以及适不适合自己业务或与未来是否有应用的可能性
    展开

    作者回复: 你说的好像不是3个备选方案,而是一个方案的不同步骤,你可以看看其他人的评论。

  • 2021-01-26
    两个任务:研究开源项目 + 业务开发;
    冲突点:时间不足;
    解决核心:找到重合部分提高效率。拆分开源项目的研究任务,整理和业务相关的任务,排优先级和任务依赖关系。拆分业务开发任务,根据与核心目标关系打分,排优先级。

    方案:
    1.业务优先,优先完成业务高优任务,穿插完成开源调研的核心并对业务有帮助的部分;
    2.调研优先,优先完成开源项目的核心部分调研,穿插完成业务的高优任务;
    3.动态规划,业务高优、调研高优和对业务有帮助的调研任务三项并行,按照具体情况动态调整当天具体任务;

    建议使用第三条,业务优先可能会出现调研的饥饿等待现象,调研优先可能会影响业务拓展,调研配合业务开发,动态安排当天任务相对能兼顾业务需求和技术需求,并利用技术进步给业务带来的红利。
    展开

    作者回复: 不建议选第3个,因为你还要考虑最后的产出,3项并行的话,看起来都在做,但是到了某个时间点一看,好像没有哪个有明显的结果。

    整体来看,你的思路还是局限于全部自己来做,其实可以更开阔一些,例如考虑把一些任务分给其他人,具体分哪些,如何分,这个你可以有了初步方案后跟主管讨论确认。

×
拖拽到此处
图片将完成下载