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

潘加宇 [2018/8/17]

最近“产品经理和程序员因需求干架”的段子疯传IT圈。

shoujike01.png

图1 传说中的干架剧本

下面我用软件工程的观点来剖析这件事情。

(1)需求不是为了指导设计而做的

这里的产品经理,我定义为需求人员。程序员,我定义为设计人员。关于需求和设计,我在《软件方法》第1章中专门阐述(http://www.umlchina.com/book/softmeth_01.htm)。其中有一道自测题是这样的:

★软件开发中需求工作的目的是____。

 A) 让系统更加好卖

 B) 更好地指导设计

 C) 对系统做概要的描述

 D) 满足软件工程需求规范

如果您选了B,那就掉入陷阱了。需求不是为了指导设计而做的。需求要考虑的是在当前的市场和竞争现状下,系统至少要达到什么功能和性能,才能够被目标客户所接受。至于本公司设计人员会不会做,怎么做,或者由其他公司的设计人员来做,或者由猫、狗、外星人来做,是无所谓的。

如果需求人员通过切实的现状调研和建模(很多产品经理不具备这个能力而瞎指挥,导致了冲突的产生,这是后文会说的问题。),推导出公司推出的新产品应该封装根据手机壳颜色切换主题的逻辑,只有这样公司才能在残酷的竞争中杀出一条血路,那么真的是再难也得想办法往这个方向努力。(事实上,在新闻价值的烘托之下,如果有公司现在推出这样的产品,很可能吸引到很多注意力)

就像人生病了,病情就摆在那里,该吃什么药,动什么手术才有生机,和病人有没有钱买药,附近有没有医生有能力手术没有关系。

不了解“需求不需要考虑设计”,就会出现各种奇葩的需求规约。有的需求规约里写上了编码规范,有的需求规约里详细给出了界面设计图、数据库设计图,甚至有的需求规约连伪代码都写上了,生怕如果不这样手把手教设计人员,设计人员不会做。

不了解“需求不需要考虑设计”,还会带来下面这种思维颠倒:先拍脑袋实现,然后再从实现反推其他工作流的内容。例如下面的对话:

A:这个不应该是系统的用例(如果您不理解什么叫“用例”,就先把它理解为“功能”好了)。

B:是的!我都写好了,运行一下给你看,这个系统确实提供了这个用例。

是否系统的用例应该以“好卖”来判断。权衡涉众利益之后觉得应该有,系统就有,不该有就没有,而不是我写好了代码,所以就应该有。

还有某些设计人员的“面向对象设计思想”是这样的:

A:这两个类关系不应该是泛化,而是关联。

B:是泛化,不信我打开代码给你看,或者逆向工程转出类图给你看。

是否泛化关系应该以“符合领域内涵”来判断,而不是先写好代码“人是猪的一种”(肯定能编译通过,正常运行),再用写好的代码来证明“人是猪的一种”。

“投币法”可以帮助需求人员排除设计人员的影响。

投币法

为了锁死人类的软件技术,三体人派出智子监控所有软件开发人员的行为,一旦发现某人有编制软件的行为,将在该人的大脑中产生长达十分钟的电击信号,让其痛不欲生。为了使将来的奴隶——人类的生活不至于倒退,三体人在地球上安放了很多软件开发机。只要对着开发机说清楚软件的功能和性能并投币,开发机将生成所需软件并部署好。

(2)需求人员要提升自己的需求技能

需求人员要认识到:做好需求需要掌握需求技能,以及反过来,掌握需求技能对做好需求是有帮助的。

遗憾的是,许多需求人员之所以在需求岗位上,并不是因为他掌握了该掌握的需求技能,可能只是因为他工作年限足够长该换到需求岗位了——和许多年龄到了就上岗的夫妻和父母相似。

许多时候,需求人员没有意识到“做好需求需要掌握需求技能”,把需求工作想得太容易,以为只要愿意花时间去做就能做好。经常可以听到“采集需求”这样的表述,好像需求是蘑菇,乖乖地躺在森林里,需要时就可以像采蘑菇的小姑娘一样,一个,两个,三个,四个……把它们都采回来。哪有这么容易!需求不是蘑菇。需求人员要能够像猎人一样,用锐利的眼睛发现隐藏在丛林中的猎物;像侦探一样,用慎密的思维判断出伪装成好人的凶手。

有的时候,需求人员没有意识到“掌握需求技能对做好需求是有帮助的”,把需求工作想得太难,认为没有办法把需求做好。由于没有掌握需求技能,开发团队往往觉得无从下手,干脆破罐子破摔,有意无意地压缩需求工作时间,或者借“敏捷”的名义直接跳过。

高质量的需求需要需求人员洒下汗水,通过高质量的启发、建模、推导而得到。不过据我的观察,很多需求人员,特别是互联网公司的产品经理,只擅长这一招鲜——头脑风暴得出界面原型。如果侥幸成功(其实很多成功是公司烧钱所致,并非产品有超人之处),就拼命鼓吹“原型大法好”,因为他就会这个。

头脑风暴是逃避深入第一线辛苦调研、安心闭门造车的借口。界面原型只是需求的一种视图,而且是和低级别涉众交流其岗位工作的视图。对于更高级别的涉众,需要其他形式的视图。和整天在电脑前面劳作的小科员通过界面原型交流还可以。 “局长,这些是系统80个功能的界面原型,我一个一个展示给你看”,难道和局长交流也这样吗?

我觉得有两项需求技能最值得花时间掌握:(1)使用业务序列图描述业务流程(2)寻找用例的涉众利益。

具体的方法学详情,可以看我写的《软件方法》一书。我在这里先举个网约车的例子:

shoujike02.png

图2 待改进的业务流程-扬招出租车

shoujike03.png

图3 改进后的业务流程-网约车(1)

shoujike04.png

图4 改进后的业务流程-网约车(2)

从上面的业务序列图对比,可以看到IT系统改进业务流程的几种常见模式:

(1)改进模式一:物流变成信息流

和信息的光电运输比起来,用其他手段运输的物的流转速度就显得太慢了,而且运输成本会随着距离的增加而明显增加。如果同类物的不同实例之间可以相互取代,那么可以提炼物中包含的部分或全部有价值的信息,在需要发生物流的地方,改为通过软件系统交换信息,需要物的时候再将信息变成物,这样可以大大增加流转速度和降低流转成本,如图5所示。

shoujike05.png

图5 改进模式一:物流变成信息流

(2)改进模式二:改善信息流转

软件系统越来越多,而各个软件系统之间沟通不畅,导致一个人为了达到某个目的可能需要和多个软件系统打交道,如果把各软件系统之间的协调工作改为由一个软件系统来完成,人只需要和单个软件系统打交道,信息的流转就改进了,如图6所示。

shoujike06.png

图6 改进模式二,改善信息流转

(3)改进模式三:封装领域逻辑

在业务流程中,有很多步骤是由人脑来判断和计算的,领域逻辑封装在人脑中。相对于计算机,人脑存在成本高、状态不稳定、会徇私舞弊等问题。如果能够提炼人脑中封装的领域逻辑,改为封装到软件系统中,用软件系统代替人脑,业务流程就得到了改进。如图7所示。

shoujike07.png

图7 改进模式三,封装领域逻辑

下面我们通过描述已婚女性出轨的场景来寻找以上改进模式,为“根据手机壳换主题”的需求找到证据。

愿景如下:

目标人群:已婚出轨女性

【此处需要向女性读者说明:出轨男女皆有,之所以此处写女性,是因为手机换壳类似于换衣服,女性更典型。如果需求是“根据所喝酒的种类换手机主题”,那就选男性。如有冒犯,多多见谅。】

老大:出轨女、超市收银员 木下纱和

目标:在和丈夫相处前快速隐藏手机里的出轨证据

度量:隐藏好手机里的出轨证据的时刻-丈夫离自己距离小于10米的时刻

改进前的业务序列图如图8所示。

shoujike08.png

图8 出轨女隐藏出轨证据-改进前

可以先应用改进二“改善信息流转”和改进三“封装领域逻辑”,得到图9。

shoujike09.png

图9 出轨女隐藏出轨证据-第一次改进

如果可能,还可以把“判断丈夫是否靠近” 的逻辑封装在IT系统中(实现手段,例如在丈夫身上埋个传感器),如果是这样,就免去换壳这一步了,如图10。

shoujike10.png

图10 出轨女隐藏出轨证据-第二次改进

weixinpanjiayu2.jpg