手机壳干架的软件工程指南

返回首页答疑记录

手机壳干架的软件工程指南

潘加宇 [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所示。