最近因为业务的原因，需要开发的项目多了很多，虽然项目的开发时间都已经排期到一个月以后，但是每周还会有很多需求评审进行。在如此多的需求评审中逐渐暴露出了一些问题，即评审的效率，一方面随着业务做的时间越来越长，系统越做越复杂，很多流程和细节，PM不懂，研发如果不看代码梳理也不懂。另一方面，项目做的越多，遇到过的重复问题会越来越多，理论上重复问题的处理会越来越游刃有余，不会在相同的问题上犯错，但真实开发中还是常常会在相似的问题上载跟头。需求评审本来应该是一个很重要的环节，理想情况下，在评审前就要做大量的调研，设计合理的产品流程，考虑异常细节流程，把模糊的地方都确定下来，准备几种解决方案在会上讨论。可惜真实情况还是会有很多问题，比如在开发过程中，甚至上线后才发现有很多异常点没有考虑到。可能是PM在产品设计的时候考虑不周，或者是研发在系统设计时的疏忽，引入的代码bug等。把产品细节的方方面面都考虑清楚很难，前面提到的，系统可能随着迭代上升到一个人类难以驾驭理解的复杂度。还有市场可能不容许你有那么多的时间打磨设计，只能线上一版看看效果。再比如产品和研发本身在评审上没有发现并提出足够多的问题，导致评审的效果并不好。排除对评审本身的态度问题和重视程度（实际上很多人因为手头上有太多的事要做，不得不在评审的时候去做一些其它工作）。在一个多小时的评审去发现并列举出一个需求的所有问题本身也挺难的，可以说有点理想化，甚至有些过分。在我的认知中，这个事一直没有特别好的解决方案，无非就是多收集案例，多做总结，多梳理各种异常情况，多卡控流程等等，没有一种让我操作起来很舒服的方式。直到有一次玩游戏给了我一些灵感。
灵感
这是一个名字叫《昆特牌-王权的陨落》的卡牌类游戏，昆特牌本来是CD Projekt公司放在《巫师3》中一个小游戏，没想到在玩家中的反响很好，就单独拿出来做了一个游戏。游戏用打牌模拟战争，对现实战争做了很好的抽象，比如投石车牌攻击建筑牌有加成，浓雾天气牌能压制弓箭手牌，战鼓牌能提升所有己方牌攻击力等等。这种卡牌游戏会建立很多规则，游戏的机制和玩法基于这套规则。比如手牌数量限制，魔免牌不能被指向性技能当作目标，某个阵营可以先抽牌等等。为了让卡牌游戏可玩性高同时逻辑完备，设计师设定了非常多规则，但是这些复杂的规则如果一开始就全部呈现给用户是一个很劝退的行为，好比没玩游戏前就先给了你一本法律书，里面写满了各种条条框框的规则。为了能够很好的控制复杂度，这个游戏用一种类似标签的东西描述游戏的种种规则，玩的多了，我不需要在看去挨个点开每张牌或者每局游戏的说明，只要看到标签，就能想到这这局游戏有哪些规则和目标。我来用游戏中的一张卡牌来解释一下。
瓦米尔的号角
永久【坚韧】
每打出1个友军单位，便使其获得1点【强化】和1点【护甲】。
【指令】： 移至己方另一排。
【坚韧】 一种状态，小局结束后留场，若受到增益，则战力恢复至基础值。
【强化】 提高单位的基础战力。
【护甲】 为单位吸收一定数额的伤害，随后移除相应的护甲层数。
【指令】 手动触发的能力。打出后，单位要“待命”1回合才能使用其“指令”能力，但“神器”可在打出后立刻使用。
首先游戏会对一张卡牌做一些使用规则上的描述，然后对关键字进行加深加色在后续详细解释。这些关键字可以理解为是游戏基本的规则，游戏的玩法就是建立在这套基本规则上的，所以它们很容易被复用。
除了规则标签，游戏设计师还在玩法上做了一些标签，来对此回合做一些定义和描述。
【标准战斗】 在三局两胜中获得更多点数来赢得战斗。
【解谜挑战】 完成特殊规则以获胜。
【快速战斗】 本场战斗只有一小局。
【预设牌组】 本场战斗将有特殊卡牌登场。
建立标签
就像我之前提到的那样，玩过几回合后，你只要看到这些标签的字，就能想起玩法和注意事项。这给了我很大的灵感，我尝试给需求评审打一些标签，并放到需求文档的评论区，我给他们的需求评审标签可能看上去像是这样：
【补贴优惠】 此需求涉及补贴优惠，需要考虑被羊毛党获取优惠的风险处理。
【价格选择】 此需求需要选择最低价，是否需要高舱产品，是否需要特殊产品，是否需要全价经济舱，价格相同优先级应当如何确定。
【低价库】 此项目使用低价库，此价格全C端用户共用，无用户画像，无风控，不带伪装立减，不带优惠券，不带mis券等。
这些标签会基于项目的关键功能体现出这些功能的注意事项，而这些注意事项，各种异常处理流程都是可以复用的。毕竟大部分软件功能设计背后的思路都大同小异。
除此之外我还模仿前面提到对游戏回合定义的标签，来对需求文档做一些定义。
【大型项目】 此项目开发时间超过10PD，如果上线时间已经到达周五则无法在周五上线。
【无QA】 此项目没有QA测试，需要RD自行测试，但需要QA和PM验收。
注意我的需求评审标签，只有一个标题+简短的描述，更详细的说明和问题点注意事项，我会放到详情链接里。
【字段渲染】 此需求涉及字段的折叠，截取，拼接，模板替换等，可能会导致文本意思与原始发生歧义。（详情和历史case见链接：xxx）
【流水号】 此项目使用了流水号，需要考虑流水号唯一性，是否暴露日订单量等关键信息。（详情和历史case见链接：xxx）
【远程日志】 此项目使用了远程上报日志，需要评估日志带来的服务资金损耗（关于日志的耗资评估详见XX），（关于日志的一些优化手段详见XX）。
久而久之，我会建设更多，更完善的标签，形成一套评审标签库，无论时PM，RD，OP还是QA，都能从理解我的标签语言，知道这个标签代表什么意思，仿佛所有的需求都是基于这套“底层规则”建立的。
说到这里，我们可以思考一下，标签到底是什么？它更像是一种在团队内部定义的语言，在团队内部达成共识，能够降低沟通的成本，高效合作，类似于DDD里面的UBIQUITOUS LANGUAGE统一语言。随着自己的整理和收集，标签库会不断的壮大和完善，我的初版标签库已经整理了50个左右的标签，我其实期望是建设约150个左右的标签，这个数字是基于邓巴数字设计的，我考虑到过多的数量的标签可能难以维护，超出大部分人的处理范围了。
文艺设计
设计师为了让游戏更加有趣，对卡牌增加了一些艺术设计，比如使用四个部分来描述一张卡牌的，下面是一张游戏中的卡牌。
刺骨冰霜
每回合开始时，对此排战力最低的单位造成2点伤害。
寒霜凛冽的好处就是尸体不会腐烂得那么快。
可以看到，这四个部分分别是：标题，描述，绘画，文学性总结。这四个部分，标题就是我们前面提到的标签，偶尔也可以取的信达雅一点，好处是更容易记住。描述是比较专业的规则介绍，偏严肃一点。绘画能让卡牌显得更直观更有画面感，毕竟一图胜千言。而文学性总结，把游戏带有的艺术性拔高了一层，尤其是有文化，喜欢阅读的玩家会很在乎游戏的文本质量。
所以我也可以画一些配图，写一些调侃的话语，来迭代我的标签库，也算是在枯燥的工作中“苦中作乐”了，下面是我设计的一个需求标签卡牌。
合法插队
此项目未正常排期，是一个临时方案但是高优解决的项目。
贵宾厅快速安检通道，我有金卡！让我先走！
这看上去非常酷，可能会让更多觉得有趣的人参与到其中来建设评审标签库，像git库的管理那样，很多人都可以提交自己的idea，把最终合并的权力掌握在几个关键人物的手中即可。看上去如果有足够的时间和精力，我甚至可以打造一款基于项目开发的卡牌桌游，取名叫《产品杀》还是什么的。
扩展思维
这种标签不仅仅能用在需求评审上，在技术评审，甚至是code review上也能良好的工作。
技术评审
【时间处理】 此功能涉及时间，日期处理，日期处理常见CASE详见XXX。
【分布式缓存】 此项目使用了分布式缓存，需要有缓存QPS,容量，一致性评估的，并评估未来大key大value情况。
【资源审批】 此项目涉及外部资源的审批，可能会因为资源的审批流程较慢，导致项目延期，建议早做申请准备。
code review
【枚举定义】 这个项目的枚举定义，存在接口版本无法直接升级或存在交集等问题，建议修改（详情规范见xx）。
【写死】 此项目因为一些特殊原因，对一些关键性逻辑或变量进行了硬编码处理，希望在后续考虑迁移。
总结
最后总结一下，我在工作中遇到的问题是大量重复的需求评审没有很好的总结沉淀下来，导致很多重复的工作，并犯相同的错误。一款卡牌游戏的标签系统给了我灵感，让我去建设一套评审标签库，这些标签可以很好的标注出需求的关键点，注意事项，并可以被重复的使用起来。