<!--原文发表于2018年8月17日，换了更高清图片，重新排版重发。-->
最近“产品经理和程序员因需求干架”的段子疯传IT圈。
图1 传说中的干架剧本
下面我用软件工程的观点来剖析这件事情。
（1）需求不是为了指导设计而做的
这里的产品经理，我定义为需求人员。程序员，我定义为设计人员。关于需求和设计，我在《软件方法》第1章中专门阐述（http://www.umlchina.com/book/softmeth_01.htm）。其中有一道自测题是这样的：
★软件开发中需求工作的目的是____。
A) 让系统更加好卖
B) 更好地指导设计
C) 对系统做概要的描述
D) 满足软件工程需求规范
如果您选了B，那就掉入陷阱了。需求不是为了指导设计而做的。需求要考虑的是在当前的市场和竞争现状下，系统至少要达到什么功能和性能，才能够被目标客户所接受。至于本公司设计人员会不会做，怎么做，或者由其他公司的设计人员来做，或者由猫、狗、外星人来做，是无所谓的。
如果需求人员通过切实的现状调研和建模（很多产品经理不具备这个能力而瞎指挥，导致了冲突的产生，这是后文会说的问题。），推导出公司推出的新产品应该封装根据手机壳颜色切换主题的逻辑，只有这样公司才能在残酷的竞争中杀出一条血路，那么真的是再难也得想办法往这个方向努力。（事实上，在新闻价值的烘托之下，如果有公司现在推出这样的产品，很可能吸引到很多注意力）
就像人生病了，病情就摆在那里，该吃什么药，动什么手术才有生机，和病人有没有钱买药，附近有没有医生有能力手术没有关系。
不了解“需求不需要考虑设计”，就会出现各种奇葩的需求规约。有的需求规约里写上了编码规范，有的需求规约里详细给出了界面设计图、数据库设计图，甚至有的需求规约连伪代码都写上了，生怕如果不这样手把手教设计人员，设计人员不会做。
不了解“需求不需要考虑设计”，还会带来下面这种思维颠倒：先拍脑袋实现，然后再从实现反推其他工作流的内容。例如下面的对话：
A：这个不应该是系统的用例（如果您不理解什么叫“用例”，就先把它理解为“功能”好了）。
B：是的！我都写好了，运行一下给你看，这个系统确实提供了这个用例。
是否系统的用例应该以“好卖”来判断。权衡涉众利益之后觉得应该有，系统就有，不该有就没有，而不是我写好了代码，所以就应该有。
还有某些设计人员的“面向对象设计思想”是这样的：
A：这两个类关系不应该是泛化，而是关联。
B：是泛化，不信我打开代码给你看，或者逆向工程转出类图给你看。
是否泛化关系应该以“符合领域内涵”来判断，而不是先写好代码“人是猪的一种”（肯定能编译通过，正常运行），再用写好的代码来证明“人是猪的一种”。
“投币法”可以帮助需求人员排除设计人员的影响。
投币法
为了锁死人类的软件技术，三体人派出智子监控所有软件开发人员的行为，一旦发现某人有编制软件的行为，将在该人的大脑中产生长达十分钟的电击信号，让其痛不欲生。为了使将来的奴隶——人类的生活不至于倒退，三体人在地球上安放了很多软件开发机。只要对着开发机说清楚软件的功能和性能并投币，开发机将生成所需软件并部署好。
（2）需求人员要提升自己的需求技能
需求人员要认识到：做好需求需要掌握需求技能，以及反过来，掌握需求技能对做好需求是有帮助的。
遗憾的是，许多需求人员之所以在需求岗位上，并不是因为他掌握了该掌握的需求技能，可能只是因为他工作年限足够长该换到需求岗位了——和许多年龄到了就上岗的夫妻和父母相似。
许多时候，需求人员没有意识到“做好需求需要掌握需求技能”，把需求工作想得太容易，以为只要愿意花时间去做就能做好。经常可以听到“采集需求”这样的表述，好像需求是蘑菇，乖乖地躺在森林里，需要时就可以像采蘑菇的小姑娘一样，一个，两个，三个，四个……把它们都采回来。哪有这么容易！需求不是蘑菇。需求人员要能够像猎人一样，用锐利的眼睛发现隐藏在丛林中的猎物；像侦探一样，用慎密的思维判断出伪装成好人的凶手。
有的时候，需求人员没有意识到“掌握需求技能对做好需求是有帮助的”，把需求工作想得太难，认为没有办法把需求做好。由于没有掌握需求技能，开发团队往往觉得无从下手，干脆破罐子破摔，有意无意地压缩需求工作时间，或者借“敏捷”的名义直接跳过。
高质量的需求需要需求人员洒下汗水，通过高质量的启发、建模、推导而得到。不过据我的观察，很多需求人员，特别是互联网公司的产品经理，只擅长这一招鲜——头脑风暴得出界面原型。如果侥幸成功（其实很多成功是公司烧钱所致，并非产品有超人之处），就拼命鼓吹“原型大法好”，因为他就会这个。
头脑风暴是逃避深入第一线辛苦调研、安心闭门造车的借口。界面原型只是需求的一种视图，而且是和低级别涉众交流其岗位工作的视图。对于更高级别的涉众，需要其他形式的视图。和整天在电脑前面劳作的小科员通过界面原型交流还可以。“局长，这些是系统80个功能的界面原型，我一个一个展示给你看”，难道和局长交流也这样吗？
我觉得有两项需求技能最值得花时间掌握：（1）使用业务序列图描述业务流程（2）寻找用例的涉众利益。
具体的方法学详情，可以看我写的《软件方法》一书。我在这里先举个网约车的例子：
图2 待改进的业务流程-扬招出租车
图3 改进后的业务流程-网约车（1）
图4 改进后的业务流程-网约车（2）
从上面的业务序列图对比，可以看到IT系统改进业务流程的几种常见模式：
（1）改进模式一：物流变成信息流
和信息的光电运输比起来，用其他手段运输的物的流转速度就显得太慢了，而且运输成本会随着距离的增加而明显增加。如果同类物的不同实例之间可以相互取代，那么可以提炼物中包含的部分或全部有价值的信息，在需要发生物流的地方，改为通过软件系统交换信息，需要物的时候再将信息变成物，这样可以大大增加流转速度和降低流转成本，如图5所示。
图5 改进模式一：物流变成信息流
（2）改进模式二：改善信息流转
软件系统越来越多，而各个软件系统之间沟通不畅，导致一个人为了达到某个目的可能需要和多个软件系统打交道，如果把各软件系统之间的协调工作改为由一个软件系统来完成，人只需要和单个软件系统打交道，信息的流转就改进了，如图6所示。
图6 改进模式二，改善信息流转
（3）改进模式三：封装领域逻辑
在业务流程中，有很多步骤是由人脑来判断和计算的，领域逻辑封装在人脑中。相对于计算机，人脑存在成本高、状态不稳定、会徇私舞弊等问题。如果能够提炼人脑中封装的领域逻辑，改为封装到软件系统中，用软件系统代替人脑，业务流程就得到了改进。如图7所示。
图7 改进模式三，封装领域逻辑
下面我们通过描述已婚女性出轨的场景来寻找以上改进模式，为“根据手机壳换主题”的需求找到证据。
愿景如下：
目标人群：已婚出轨女性
【此处需要向女性读者说明：出轨男女皆有，之所以此处写女性，是因为手机换壳类似于换衣服，女性更典型。如果需求是“根据所喝酒的种类换手机主题”，那就选男性。如有冒犯，多多见谅。】
老大：出轨女、超市收银员 木下纱和
目标：在和丈夫相处前快速隐藏手机里的出轨证据
度量：隐藏好手机里的出轨证据的时刻-丈夫离自己距离小于10米的时刻
改进前的业务序列图如图8所示。
图8 出轨女隐藏出轨证据-改进前
可以先应用改进二“改善信息流转”和改进三“封装领域逻辑”，得到图9。
图9 出轨女隐藏出轨证据-第一次改进
如果可能，还可以把“判断丈夫是否靠近” 的逻辑封装在IT系统中（实现手段，例如在丈夫身上埋个传感器），如果是这样，就免去换壳这一步了，如图10。
图10 出轨女隐藏出轨证据-第二次改进
