聊游戏策划这个岗位,我这些年被问得最多的一句话就是:什么样的人能干这行,什么样的人能把这行干到顶尖。市面上讲“策划能力模型”的内容不少,但大多停在“要有逻辑、要懂玩家、要会沟通”这种正确却没法落地的层面。我自己带过人,也被人带过,面试过上百份简历,慢慢攒出了一套相对粗暴但好用的判断标准——30项核心条件。这篇就把它掰开揉碎讲清楚:这30项条件分别是什么、为什么是这30项、怎么用它做自我诊断、怎么按优先级补齐短板,以及哪些坑是新人最容易踩而我当年也踩过的。不管你是刚入行想搞清楚方向的新人,还是做了几年开始遇到瓶颈的老策划,或者只是对“游戏策划圣体”这个说法好奇的路人,都能从里面拿到能直接用的东西。
1. 先把30项条件这件事说透:它到底解决什么问题
很多人一提“能力模型”就头大,觉得是HR搞出来考核人的表格。我一开始也这么想,直到自己开始带项目,才发现问题不在模型本身,而在于大部分模型是“描述型的”——它告诉你优秀的人长什么样,却不告诉你从现在的自己走到那个样子要经过哪几步。30项核心条件我想做成“诊断型的”,它的目标不是评优,而是定位:让你知道自己的短板在哪个格子里,而不是笼统地觉得“我还不够强”。
1.1 策划岗的真实分工,决定了条件必须分三层
先说说现实。策划这个title下面藏着完全不同的活:有人天天写表做数值,有人趴在地上摆白盒关卡,有人写系统规则文档写到凌晨,有人跟美术对着一版UI稿吵一下午,有人负责整个项目的世界观和台词。你让一个擅长写剧情的人去做经济系统平衡,他会痛苦;你让一个数值敏感的人去写对白,他能写出说明书。
所以30项条件我按三层来排:底层素质、专业技能、高阶判断。底层素质决定你能不能入行并且活下来,专业技能决定你能不能独立干活,高阶判断决定你能不能带项目、做决策、成为那个“方案拍板的人”。这三层不是并列关系,是叠加关系——底层不过关,专业技能再花哨也走不远;专业技能不扎实,高阶判断就是空中楼阁。
这里要强调一个常被忽略的点:这三层的比例不是平均的。底层素质大概占8项,专业技能12项,高阶10项。为什么底层反而少?因为底层素质的单项权重极高,一项不合格基本就是一票否决。比如“能接受自己的方案被推翻”这一条,做不到的人在这行待不过两年,不管他多有才华。
1.2 为什么是30项,而不是10项或者100项
有人会问,30这个数字是怎么来的。说实话它不是精确计算的结果,是我在实际带人过程中反复增删收敛出来的。10项太粗,粗到“有逻辑”这种描述根本无法指导行动;100项太细,细到你会陷入工具焦虑,光打勾就花一周。
30项刚好落在一个舒服的区间:每一项都能对应到一个具体的行为或产出物,你能拿它去回看自己过去半年的工作记录,判断“我到底做到了没有”。比如“会做数值基础建模”,对应的行为就是“能不能独立搭出一个产出消耗闭环的表格并用它跑通一轮模拟”;比如“能用一句话讲清核心体验”,对应的行为就是“你向一个非本行业的朋友介绍你的项目,他能不能在30秒内说出这游戏好玩在哪”。
注意:这套条件不是招聘JD,不要拿它逐条去卡候选人。真实招聘看的是“有没有至少两项明显长板+其余项不拖后腿”,全项达标的人基本不存在,真有也不会来面你这个岗位。
1.3 这套条件最适合谁用
我把它推荐给三类人。第一类是入行1-3年的新人,用来做年度自评,找出最该补的两三个短板,避免东一榔头西一棒子。第二类是准备转岗的人,比如从运营、测试、文案转策划,用它对照一下缺口在哪,心里有底。第三类是带人的主策或者制作人,把它改成团队内的能力对照表,比空泛地说“你要多思考”有效得多。
不适合什么人?不适合用它来给自己打鸡血。这套东西的用法是“找差距”,不是“刷成就”。我见过有人拿它当清单,一条条打勾,全打完了发现自己还是不会做项目——因为打勾是自我评价,做项目是外部验证,两者中间隔着一整个真实世界的复杂度。
2. 底层素质的8项条件:决定你能不能在这行活下来
底层素质这一层,我的判断标准很朴素:这些能力如果在入职前就不具备,入职后也很难通过培训补上。它们更像性格和习惯的延伸,而不是知识点。所以面试的时候我会重点看这几项,专业技能反而可以放一放——技能能教,习惯很难改。
2.1 前三项:把话说清楚、把问题拆小、把需求听明白
第1项,能把话说清楚。这一项看着像废话,但我可以负责任地说,它淘汰掉的人比任何专业技能都多。策划的核心产出物是“让别人按你的想法行动”,而让别人行动的前提是别人能看懂你写的东西。一份策划案如果程序看完要来回问五遍“这里到底是什么意思”,那这份案子的价值就是负的,因为它消耗了别人的时间。
什么叫“说清楚”?不是文采好,是信息完整、无歧义、有优先级。我自己写文档有个笨办法:写完先放两小时,回来以“我完全不知道这个项目”的视角重读一遍,凡是需要脑补的地方全部补上。这个习惯让我少挨了很多骂。
第2项,能把问题拆小。策划每天面对的都是模糊需求:“这个玩法不好玩,你优化一下”“留存掉了,你分析一下”。这类需求没法直接执行,必须拆。拆解的关键不是拆得细,而是拆完之后每一块都能独立验证。
举个真实场景:某项目组发现新手期流失严重,讨论半天都在说“新手引导太长”。后来有人把它拆成三段——注册到第一次战斗、第一次战斗到第一次获得奖励、第一次奖励到第一次自主选择——一测数据,问题出在第二段,奖励发放的反馈太弱,玩家不知道自己获得了什么。拆解的价值就在这,它把一个没法下手的大问题,变成了一个改一个动效就能验证的小问题。
第3项,能听懂别人在说什么。这一项比前两项更隐蔽。很多人以为自己听懂了,其实只听到了字面意思。程序说“这个做不了”,可能意思是“这个做不了,但换个做法可以”;美术说“这个风格我不太擅长”,可能意思是“给我更明确的参考”;主策说“再想想”,可能意思是“这个方向不对,但我不想打击你”。
听懂的诀窍是追问一层。对方说完,你复述一遍:“你的意思是不是……”,或者直接问“如果一定要做,卡点具体在哪”。这个动作看着笨,但能省掉大量返工。
2.2 中间三项:扛得住推翻、找得到信息、耐得住长周期
第4项,能接受自己的方案被推翻。我把这一项单独拎出来,因为它是最容易劝退新人的一关。你花三天写的方案,评审会上十分钟被否掉,而且否得有理有据。这时候有两种反应:一种是觉得被针对,开始防御性辩论;另一种是把否决理由记下来,回去改。
这行做久了你会发现,方案被推翻是常态,不是失败。一个方案能活到上线,中间大概要经历五到八轮大改。真正的失败是“因为怕被推翻,所以只提最保守的方案”——这种人三年后还在原地,因为他从来没试过边界在哪。
第5项,能主动找信息。策划是信息的枢纽,上游接需求,下游对接程序美术,外面还有玩家和竞品。指望别人把信息喂到你嘴边是不现实的。我见过做得好的同事,都有个共同习惯:自己建信息库。
具体怎么做?比如做竞品拆解,不是看一遍就算,而是截图存档、按模块归类、记录版本变化。比如做用户反馈,不是等运营给报表,而是自己去社区翻帖子、看评论区。这些动作没人要求,但半年后差距就出来了——讨论同一个问题,别人靠印象,你靠记录。
第6项,耐得住长周期没有正反馈。游戏开发的反馈周期极长。你改了一个数值,可能要两个月后才能在上线数据里看到效果;你写的一段剧情,可能因为版本排期被砍掉,永远不会有人看到。这跟很多人的预期是反的——他们以为做游戏是天天玩、天天有灵感,实际上是天天对表格、天天改文档。
能扛住这一项的,往往是那种能从过程本身获得满足感的人。改一版表格,看到曲线变平滑了,他能开心一下午。这种特质很难伪装,也很难培养。
2.3 后两项:跨职能协作与足够的游戏阅历
第7项,能跟程序美术把事掰扯清楚又不结仇。这一项本质上是“在坚持目标和维护关系之间找平衡”。太软,你的设计会被一路砍到面目全非;太硬,下次没人愿意配合你。
我的经验是:对目标强硬,对方案柔软。目标层面不含糊——“这个功能必须让玩家在3秒内知道自己赢了”,方案层面开放——“用动效还是用音效还是用文字,你们定,我配合”。这样对方感受到的是“这个人有主见但不难搞”,协作成本大幅下降。
第8项,有足够的游戏阅历广度。注意是广度,不一定是深度。只玩一个品类的人,设计思路会被死死框住。我自己有个习惯,每年强制自己玩三款“我平时绝对不会碰”的游戏,哪怕只玩五小时。这五小时的价值不在于玩懂,而在于知道“原来这个问题还有这种解法”。
这一项还有个隐藏价值:帮你建立横向参照系。讨论一个成长曲线的问题,你能想到三个不同品类的处理方式,讨论的质量立刻不一样。
3. 专业技能的12项条件:决定你能不能独立干活
如果说底层素质是“人”的问题,专业技能就是“活”的问题。这一层的12项,每一项都对应一个能拿出来的产出物。我建议自评的时候不要凭感觉,直接翻自己过去一年的工作记录,看有没有对应的东西。
3.1 文档、表格与数值建模:最枯燥也最见功底的三项
第9项,掌握至少一种能落地的文档规范。策划案不是写作文,它的读者是程序、美术、测试、运营,每个人关心的部分不一样。所以好的策划案要有清晰的分区:这一段是给程序看的功能逻辑,这一段是给美术看的视觉描述,这一段是给测试看的验收标准。
我自己的模板大概包含几块:需求背景(为什么做)、玩家体验目标(玩家应该感受到什么)、功能流程(分步骤描述)、边界情况(异常怎么处理)、验收标准(怎么算做完)。其中边界情况是最容易被漏掉也最容易出事的部分——正常流程谁都想得到,出问题的永远是“玩家断线了怎么办”“道具满了怎么办”“重复点击怎么办”。
第10项,会做数值基础建模。这一项不是要求你会高深数学,而是要求你能用表格把“产出—消耗—成长”这条链跑通。很多新人一听到数值就躲,觉得那是专人干的活。但只要你要独立负责一个系统,数值能力就是绕不过去的。
入门路径我建议这样走:先做一个最简单的成长曲线,设定“玩家从1级到10级,每级需要的经验值”,然后用表格画出曲线,看它是不是前期快后期慢。再往后加变量:每日可获得经验、玩家留存分布、卡点设计。做完这一轮,你对数值的感觉就有了。
第11项,懂经济系统的产出与消耗平衡。这一项和第10项是连着的,但视角不同。数值看的是成长曲线,经济看的是资源的进出总量。核心问题只有一个:玩家每天产出多少资源,系统每天消耗多少资源,两者的差额会不会导致通胀或者卡死。
这里有个特别好用的自查方法:把所有资源列成一张表,横轴是时间(第1天、第7天、第30天),纵轴是存量。如果曲线一路往上冲不回头,说明消耗端不足,中期会通胀;如果曲线在第3天就贴地,说明产出不足,玩家会被卡走。这个方法粗糙但极有效,我现在做任何带资源的系统都会先跑一遍。
提示:经济系统的坑往往不在数值本身,而在“玩家会找到你没预想到的路径”。所以任何经济设计都要问一句“有没有可能被套利”,这个问法能挡掉大部分事故。
第12项,会设计战斗节奏与手感反馈。这一项偏感官,但它是有方法论的。战斗节奏的核心是“张弛”——连续高压会让玩家疲劳,连续低压会让玩家无聊。我通常把它拆成三段来看:进入战斗的引导期(给玩家熟悉敌人)、战斗中段的变化期(加入新机制或压力提升)、收尾的释放期(给一个明确的胜利爽点)。
手感反馈则是另一套逻辑,它更依赖多通道叠加:视觉(打击特效、受击抖动)、听觉(音效层次)、操作(输入延迟、镜头反馈)、数值(伤害数字跳动)。任何一个通道缺失,手感都会“轻”。这也是为什么很多小团队做出来的战斗总感觉差一口气——不是设计不对,是反馈通道只做了两个。
3.2 关卡、交互与规则描述:把想法变成可执行的东西
第13项,会做关卡白盒与节奏铺排。白盒就是用最简单的几何体把关卡搭出来,先不追求好看,只验证“走位舒不舒服、视野够不够、难度曲线顺不顺”。这一项的价值在于它能把争论变成验证——两个人对着文档吵半天,不如搭个白盒一起跑一遍,五分钟就分出对错。
白盒阶段我建议只关注三件事:路径是否清晰(玩家知不知道自己该往哪走)、威胁是否可读(玩家能不能提前判断危险)、节奏是否有起伏(有没有喘息的空间)。这三件事定下来,美术进场才有意义。
第14项,懂交互流程与信息层级。交互设计的核心不是好看,是减少玩家的认知负担。玩家打开一个界面,第一眼应该看到最重要的信息,第二眼看到能做的操作,第三眼才看到次要说明。层级乱了的界面,玩家的第一反应是“我不知道该干嘛”,然后关掉。
判断层级有没有做对,有个土办法:把界面截图给别人看三秒,然后问他“这个界面是干什么的、我该点哪”。答不上来就是层级有问题。这个方法我用过无数次,比任何理论都好使。
第15项,会写无歧义的规则描述。这一项是第9项的加强版。功能流程能写清楚只是及格,规则描述无歧义才是本事。区别在哪?功能流程描述的是“玩家点了按钮会发生什么”,规则描述的是“在所有可能的情况下,系统应该怎么响应”。
比如“使用道具”这个动作,规则描述要覆盖:道具不存在怎么办、数量不足怎么办、使用中被打断怎么办、使用后触发连锁效果怎么办、并发操作怎么办。写全这些,程序才能一次做对,测试才能一次测全。
第16项,有基础的程序思维。不是要求你会写代码,而是要求你理解几个基本概念:状态机(一个东西有几种状态、怎么切换)、事件(什么事发生了要通知谁)、数据驱动(哪些东西应该配表而不是写死)。有了这层理解,你跟程序沟通的效率会翻倍,因为你提的需求是“可实现的形状”。
我见过最典型的反例是:需求里写“玩家情绪低落时给他一个惊喜”,程序看完直接沉默。这需求没错,但它没法翻译成可执行的逻辑。改成“玩家连续三次战斗失败后,第四次进入战斗时触发特殊演出”,立刻就能做了。差别就在于有没有程序思维。
第17项,会做原型验证。原型可以是纸面的、可以是表格模拟、可以是引擎里搭个粗糙版本。核心目的只有一个:在投入正式资源之前,先确认这个东西成不成立。很多团队跳过这一步直接开工,做完才发现不好玩,代价是几十人月。
原型阶段最忌讳追求完整。我自己做原型的标准是“能回答一个具体问题就停”——比如我要验证“这个战斗循环有没有节奏感”,那就只做战斗,其他全砍掉。
3.3 文案叙事、用户研究与数据指标:容易被低估的三项
第18项,有文案与叙事的基本功。这一项不是只有剧情策划才需要。任何策划写的文档、写的提示语、写的活动说明,都在跟玩家对话。文字啰嗦、语气不对,玩家对游戏的印象就掉一档。
基本功的最低要求是:准确、简洁、有语气一致性。提示语不能有歧义(“确定要退出吗”这种要写清退出了会怎样),活动说明不能有歧义(奖励发放时间、领取条件必须明确),整体语气要跟游戏的世界观一致。
第19项,会做竞品拆解与用户研究。竞品拆解不是“玩一遍写个感想”,而是有结构的观察:它的核心循环是什么、它靠什么留住人、它的付费点在哪、它的版本迭代节奏是什么。用户研究也不是“看评论区”,而是能区分“玩家的表达”和“玩家的真实需求”——玩家说“太难了”,可能真实需求是“我需要更清晰的反馈”,而不是“把难度调低”。
第20项,掌握数据埋点与指标定义。这一项是很多新人的盲区。你不定义指标,就没法验证自己的设计。最基础的一组指标是:进入率(有多少人到了这个功能)、完成率(有多少人走完了)、留存贡献(用过这个功能的人留存是不是更高)。
埋点设计的关键是先想清楚要回答什么问题,再决定埋什么。反过来做的话,埋了一堆点,最后发现回答不了任何一个具体问题,白费功夫。
4. 高阶判断的10项条件:决定你能不能成为顶尖
前面两层加起来20项,做到的人已经能独当一面。但“能干活”和“顶尖”之间隔着一段很长的路。这10项条件,我自己也是在带项目之后才慢慢有感觉的。
4.1 核心体验、创新判断与取舍能力
第21项,能用一句话讲清核心体验。这一项是分水岭。能讲清楚的人,做设计时知道什么该保什么该砍;讲不清楚的人,只能靠堆功能。判断方法是:你说完这句话,听的人能立刻想象出玩家在干什么、感受是什么。
比如“这是一款让玩家在有限资源下做艰难取舍的游戏”——听完你就知道重点在决策压力,而不是战斗爽感。反过来,“这是一款融合了多种玩法的开放世界冒险游戏”这种话,等于什么都没说。
第22项,能判断一个玩法到底新不新。这行的“创新”大部分是重组,真正的新东西很少。所以判断的重点不是“有没有人做过”,而是“这个组合有没有产生新的体验”。我自己的判断方法是问三个问题:它改变了玩家的什么决策?它带来了什么新的约束?它让玩家产生了什么以前没有的情绪?
三个问题都答不上来,那大概率是换皮。
第23项,能做取舍与优先级排序。项目永远资源不足,所以策划的核心工作之一就是排序。排序的原则不是“哪个最重要”,而是**“哪个不做会死,哪个不做只是少赚”**。前者是底线,后者是加分项。资源不够的时候,先保底线。
这一项还有一个更难的部分:砍自己最喜欢的设计。我砍过好几个自己写得很爽的方案,砍的时候确实难受,但回头看,那些方案如果不砍,会拖垮整个版本的节奏。
第24项,有商业模型与付费设计意识。这一项跟“良心”不冲突。理解商业模型,是为了知道项目的钱从哪来、成本结构是什么、哪些设计会影响收入。有了这层意识,你在做设计时会自然考虑“这个功能对留存有什么用、对转化有什么用”,而不是只考虑好不好玩。
第25项,能带领团队对齐愿景。这一项是从“做好自己的活”到“让别人也做好”的跨越。对齐愿景不是开会喊口号,而是让团队每个人在遇到具体取舍时,能做出和你一致的决定。方法很朴素:反复讲、用案例讲、在每次决策时把理由讲出来。
4.2 审美、决策、复盘、迁移与长期主义
第26项,有审美与品味判断力。品味这东西看着虚,但它是所有“差一点”的来源。同样的功能,有人做出来就是顺手,有人做出来就是别扭,差别往往在那些说不清的地方——间距、动效时长、文字节奏、反馈的轻重。
培养品味的办法只有一个:大量接触好的东西,并且试着说出它好在哪。说不出来就还没有真正理解。
第27项,能在不确定性中做决策。游戏开发本质上是高不确定性的工作,你永远不可能有完整信息。这一项要求的是:在信息不足时能给出一个“当前最优解”,并且保留调整空间。
我的做法是:决策时明确标注“这个判断基于什么假设”,假设被推翻时立刻重估。这样既不会因为怕错而不决策,也不会因为决策了就死不回头。
第28项,能复盘失败并提炼方法论。复盘最怕变成追责会,或者变成“下次注意”的空话。有效的复盘要落到可复用的规则上。比如“这次活动参与率低,原因是我们把入口放在了三级界面”,提炼出来的规则就是“重要活动的入口层级不超过二级”。这种规则攒多了,就是个人的方法论。
第29项,有跨品类迁移与创新能力。这一项是第22项的延伸。真正的创新往往来自跨领域的类比:把某个品类的机制搬到另一个品类,产生新的化学反应。这要求你不仅有广度,还要有“抽象的中间层”——能把具体机制抽象成通用结构,再套到新场景里。
第30项,长期主义与持续输出。这一项听着像鸡汤,但它是最实在的一条。这行的知识更新极快,三年前的方法今天可能完全失效。能走远的人,都有持续学习和持续输出的习惯——写复盘、做拆解、跟同行交流。
5. 把30项条件用起来:自测表与补短板路线
条件列完了,但列完不等于有用。我自己用下来的经验是,这套东西的价值全在“怎么用”上。用得不对,它会变成焦虑制造机;用对了,它是一张地图。
5.1 自测表的打分方式与判读标准
打分不要用1到10分,太主观,人会本能地往中间靠。我建议用三档:能做到(有产出物为证)、勉强能做到(需要别人帮忙)、做不到。三档的好处是逼你去翻证据,而不是凭感觉。
| 层级 | 条件数量 | 判读标准 | 常见状态 |
|---|---|---|---|
| 底层素质 | 8项 | 出现2项以上“做不到”,先别急着补技能 | 新人普遍在这一层有1到3项缺口 |
| 专业技能 | 12项 | 出现4项以上“勉强”,说明还不到独立负责系统的阶段 | 1到3年的人普遍在这一层卡住 |
| 高阶判断 | 10项 | 大部分“勉强”是正常的,这一层靠项目历练 | 通常需要有主导项目的经历才会明显提升 |
判读的关键不是总分,而是分布。如果底层有硬伤,专业技能再高也会在某个节点崩掉;如果专业技能很整齐但高阶全是“勉强”,那说明你缺的是主导项目的机会,而不是能力本身。
5.2 按阶段补短板的具体路线
入行0到1年,重点只放在三项:把话说清楚、把问题拆小、掌握一种文档规范。其他全部先放一放。这三项扎实了,你在团队里的口碑就立住了,后面才有机会接触更核心的活。
1到3年,重点补数值建模、规则描述、原型验证、数据指标这四项。这四项是“独立负责一个系统”的门槛。补法不是看书,而是主动申请一个小系统从头做到尾,做完一遍比看十本书管用。
3到5年,重点转向核心体验表达、取舍排序、商业意识、复盘方法论。这一阶段最有效的方式是跟着一个完整项目走一遍从立项到上线的全流程,中间每一个决策点都问自己“如果是我,我会怎么定”。
5年以上,重点在愿景对齐、不确定性决策、跨品类迁移。这一层没什么标准路径,基本靠带团队和跨项目经验堆出来。
注意:不要试图同时补五项以上。人的精力有限,同时推进多项的结果通常是每项都停在“知道”层面,没到“会用”层面。我自己的习惯是一年只定两个重点,年底回看。
6. 常见问题与踩坑实录
这一节是我这些年被问得最多的问题,以及我自己踩过的坑。有些坑现在想起来还挺丢人,但确实有用。
6.1 高频疑问与对应解法
| 常见疑问 | 背后的真实问题 | 我的处理方式 |
|---|---|---|
| 我玩的游戏不够多,是不是做不了策划 | 把阅历等同于数量 | 广度比数量重要,一年认真玩三款不同品类,比无脑刷三十款有用 |
| 我不会数值,能不能只做系统 | 把数值当成单独的工种 | 只要独立负责系统,数值就绕不开,先从最简单的成长曲线开始 |
| 我的方案总被否定,是不是不适合这行 | 把否定等同于能力否定 | 记录每次否定的理由,三个月后回看,如果理由开始重复,说明你在同一个点上没进步 |
| 想法很多但落不了地 | 缺拆解和验证习惯 | 每个想法强制写一句“怎么用最小成本验证它” |
| 跟程序沟通总是不顺 | 需求描述不可执行 | 提需求前先自问“这个需求能不能翻译成状态和事件” |
| 做了两年感觉没成长 | 一直在做执行,没碰过决策 | 主动申请参与一次立项讨论,哪怕只是旁听 |
6.2 几个我踩过的坑,以及从中提炼的规则
坑一:把文档写得越厚越有安全感。刚入行时我写策划案,动辄三四十页,觉得写得越全越显得专业。结果程序根本不看,直接来找我口头问。后来我才明白,文档的价值不在于长度,而在于程序能不能照着它一次做对。现在我写文档,先写一页纸的核心逻辑,确认对方看懂了,再补细节。
坑二:用“玩家会喜欢”来支撑设计。这句话是万能挡箭牌,但它什么也没说明。我现在要求自己每次想说这句话时,替换成具体的推测:“玩家在这个节点会因为缺少正反馈而流失,所以加一个即时奖励”。推测可以被验证,口号不能。
坑三:原型阶段追求完整。有次做一个小玩法,我在原型阶段就把美术资源、音效、UI全配齐了,花了三周。结果一测,核心循环不好玩,全废。从那以后我给自己定了条规矩:原型阶段只做能回答一个问题的最小版本,问题答完立刻停手。
坑四:复盘的结论写成“下次注意”。这种复盘等于没做。现在我的复盘必须落到一句可以检查的规则上,比如“所有涉及资源产出的改动,必须同时给出消耗端的调整方案”,这种规则写进团队文档,下次直接查。
坑五:把“不被否定”当成目标。有一段时间我提的方案总是最保守的那种,因为保守的方案不容易被挑毛病。短期看很安全,长期看毫无成长。后来我想明白一件事:方案被否定的成本,远低于不提方案的成本。前者只是浪费几天,后者浪费的是整个人的成长曲线。
6.3 从用人视角补一句:我最看重哪几项
如果让我只保留五项来挑人,我会选:把话说清楚、把问题拆小、能接受方案被推翻、会做原型验证、能用一句话讲清核心体验。这五项覆盖了“能不能沟通”“能不能落地”“能不能扛”“有没有判断力”四个维度,基本能判断一个人是能干活还是有潜力。
反过来说,我最怕遇到的是那种“什么都能聊两句,但拿不出一个完整产出物”的人。聊设计谁都会聊,把东西做出来并且做成,才是这行的分水岭。