这几类需求有毒，设计师们请绕行(2)

这是第18次的白日梦 预计阅读时长5分钟

没想到上篇文章不小心火了一把，看来设计师同僚们平时真的受了不小委屈，当然还有好多朋友提供了非常多我没想到的“毒药”素材，所以周末加个班，把上周已经准备好的几味烈性毒药献上，大家慢慢品尝 (￣y▽￣)~*

 “xxx提出”的需求 

• 类比毒药：一氧化碳

• 毒性：★★★☆☆

• 特点：无色无味，杀人于无形

这类“毒药”之所以“杀人于无形”是因为刨去“xxx提出的”这几个字，它跟大多数需求一毛一样，但关键就在这几个字上。比如，产品跑过来说“这个需求是市场那边因为业务变动要加的”，字面上解读：

1. 这个需求的owner并不是产品经理 

2. 对这个需求的背景最了解的是需求的owner而不是产品经理。

这种情况其实很常见，但遇到“不太行”的产品，结果就会变成产品经理只是需求方和设计师之间的传话筒，有些问题还会被传“变味”而增加沟通成本。而当“xxx”变成大老板，既“这个需求是大老板”提出的，毒性就会更猛烈，甚至你对需求稍有质疑就会受到来自产品经理的成吨暴击，毕竟老大提的你懂的。所以遇上这种情况，尤其是在产品经理不专业或不上心时，设计师的前期沟通和对需求理解的工作量会成倍增加，因为你不确定产品经理给你描述的需求是不是需求方真正想要的需求。

解毒方法：

首先，需要先发现“中毒了”。比如多问一些为什么，总是能发现破绽的。比方说发现产品经理对需求的前因后果、逻辑链路等任何环节有不清楚的地方，或者频频搬出诸如“这个是xxx那边提的，我在问问他”这种话，这时候就要警惕了。再比如，如果有条件，你可以找到需求的owner简单问一下，看和产品经理描述的是否有出入，这在一定程度上也可以保证后续设计会不跑偏。

其次，当发现“中毒了”以后，需要快速“解毒”。这时候就看你的能力了。由于以上情况基本不会出现在与合格的产品经理合作的过程中，所以当发现自己“中毒”时，“队友”是靠不上了，只能靠自己。如果能力强，你可以直接跳过产品经理跟需求方直接沟通；如果能力不足以跳过产品，这时候就建议拉上产品和需求方一起开个小会对需求再次明确下，以统一理解。当然，如果owner的级别比你高太多只有评审的时候才能见一面，我建议在讲解具体设计方案时能把需求拆解成设计目标的过程简略说一下，如果出现需求理解偏差，这时候锅就不在你这里了（对，就是要留一手呀）。

最后还是那句话，始终对产品经理的需求描述持怀疑态度是设计师职场生存的必备素质。

 紧急需求 

• 类比毒药：马钱子碱

• 毒性：★★★☆☆

• 特点：小剂量不致命，但非常痛苦，非常痛苦，非常痛苦

工作中难免遇到紧急情况需要立刻处理，但经常性的需要加班加点“救火”就不正常了。紧急需求一般会有以下几种情况：

1. 由于某些外部突发情况需要处理而产生的需求，大到国家政策突然变化、业务出现调整这些不可预知的重大变化，小到突发的新闻热点等。

2. 由于内部失误产生的需求，比如A需求设计完了才发现会对其他模块产生影响，从而产生需要紧急处理的B需求。

3. 大boss突然想到的需求。

根据不同的情况，解毒方法也有所差异，但很难从根处避免，要不互联网公司也不会成为加班重灾区了。

解毒方法：

对于第一种情况，其实很难避免，谁没遇上个紧急情况呀？不过针对紧急情况的处理机制还是需要储备的，具体方法因产品而异，不过再严密的防护也难免特例，所以遇上这种情况也只能“硬抗了”。当然事后的复盘很重要。看看哪些“突发情况”是可以找到共性并做好预防。

第二种情况应该属于失误了。常见的几种有：产品或设计对业务了解不透发生“撞车”；需求排期失误使得原来可以正常开发的需求变得“时间紧迫”；突然想到的需求。对这几种内部失误，最好的解毒方法就是做好事后复盘：找到问题产生的前因后果，需求撞车这种问题为什么没有在需求评审或交互评审中暴露出来？为什么没有评估好需求排期？哪个环节延误使得整体排期紧张？是否需要增加一个机制确保产品提需求不能太随意？...当然复盘的同时也能骗顿炸鸡，美滋滋。

第三种么，我只能说：老板，您高兴就好。

 产品们嘴里的“简单需求” 

• 类比毒药：相思子毒素

• 毒性：★★★★☆

• 特点：看上去很美好，实际剧毒无比 

就像不会有人想到“此物最相思”的红豆会含有剧毒一样，产品经理信誓旦旦说的“简单需求”也可能并不“简单”。尤其是这个需求还没跟研发对过，你就更需要一百个小心了，因为任何一个需求都不会简单，要不为啥之前版本不顺手做掉呢？所以当一个产品经理找你做一个“简单需求”时，真的别天真的相信了。

那为啥又说是“剧毒”呢？因为如果一个不简单的需求被产品经理描述的很简单，那只会有两种情况：要么他没深入思考，想“简单”了；要么工期紧张，他想忽悠你加班。这两种情况都当“毒”，因为你会高高兴兴的预估一个定稿日期，然后发现越来越多的坑要填，越来越大的工作量。你要增加工期，项目经理会质疑你的职业素养（都高级设计师了工作量还预估不好），结果只能帮人擦屎自己闻臭，默默的加班。

解毒方法：

真不好意思，又要扯到需求理解上了。因为上面的两种情况，问题都出在“需求”理解上（所以你看有一个靠谱的上游工友多么重要）。早早发现“简单”表象之后的“不简单”是“解毒”的唯一方法。

那有哪些增加工作量的“坑”是我们很容易忽视的呢？

1. 历史遗留问题：还是那个逻辑，要是很简单，为啥之前版本没有顺手就做了？可能背后就会有难以逾越的坎。可能是技术上的瓶颈、可能是为了和另一处的统一、甚至可能是历史遗留“巨坑”的一个小小表象。

2. 技术瓶颈：可能看上去简单的需求，实现上并不简单，最后倒逼着改方案。

3. 遗漏了相关联的其他功能点：产品经理可能没想到一个子页面的改动可能会影响到多个其他子页面的改动。尤其是功能复杂的产品，真的会“牵一发而动全身”。

所以说，要解毒，需要做到：

1. 尽可能了解之前的背景。自己做的需求，最好留下过程稿，方便想起当时决策的细节；别人做的需求，最好能去问下这里会不会有坑。

2. 找研发聊一下方案的可行性，当然，做任何需求这都是必要的。

3. 需要对产品的各功能模块都有大致的了解。

但说到底，排期的时候能尽量多争取设计时间才是硬道理，什么时候都不要忘了给自己留下buffer时间，切记，切记。

好了，分两篇讲了六种“毒需求”，要是小伙伴们还意犹未尽，欢迎留言讨论，说出你平时见过的“奇葩”需求。等我有空了再凑一篇。下次要回归严肃的技术贴了(•̀ᴗ•́)و ̑̑