工作记忆 vs. 长期记忆

fish_memory

长期一来一直有个说法:“鱼的记忆只有七秒,7秒之后它就不会记得曾经的事情了,所有的一切又都会变成崭新的开始。所以,在那一方小小的鱼缸里面,它永远不会觉得无聊。” 当然这个美丽的谣言已经被一些死硬理派得人非常煞风景的辟谣了。

但是有一个科学的事实是关于工作记忆长期记忆的。根据coursera上的《如何学习困难主题》这门课的介绍,人的工作记忆——相当于内存——只有四个格子,而人的长期记忆——相当于硬盘——则有着几乎无法穷尽的存储空间。

就像内存占满后电脑的运行速度就会极大下降一样,极其有限的工作记忆空间被占满后,人几乎就没有办法处理任何新的问题了,而且如果长期如此会对心理和生理都造成很严重的负面影响。

在课中提到有些脑损伤的患者只剩下了一个工作记忆空间,而我们完成几乎任何事情都需要至少两个空间的内容产生关联来实现,比如拿杯子倒杯水,该患者拿起杯子就忘了水,想起水就忘了杯子,导致非常简单的事情都无法完成。

我们自己在生活中也经常会体会到,当脑子里被好几件事情占据的时候,思维能力会大幅下降,几乎没有办法进行深度思考。

就目前对大脑的研究结果表明工作记忆空间无法通过训练来增加,因此我们必须要善用有限的工作记忆空间。 在这个方面必须要推荐GTD(getting thing done)这种任务管理方法以及这种工作方法的专著:《搞定》

gtd

GTD的方法可以有效的把占用工作记忆空间的事情落实到工作蓝里,通过纸笔或者有效的软件确保既不丢失任务又不占用大脑,做到心静止水

当前我们的问题经常是工作记忆使用过度,而长期记忆又利用不足,在《浅薄:互联网如何毒化了我们的大脑》一书中,作者指出:在我们创造技术的同时,技术也一直在重塑我们的大脑,像谷歌这样强大的搜索工具让用户越来越不愿意在自己的大脑里记忆东西。

shallows

反正在需要的时候总能从谷歌上搜到,我为什么要背下来记在脑子里呢?

我认为这种观点是非常错误的。

在这个崇尚创新的时代,有很多创新其实是跨领域的碰撞,也就是联想。 创新经常在不经意间发生,这是因为当你处于放松、不专注的状态时,大脑会拿你工作记忆里的东西去和你的长期记忆里的东西随意的匹配和关联,所以经常会在不刻意去想某个难题的时候突然跳出答案来。 而当你的长期记忆空间里空空如也的时候又哪有什么灵感可以出现呢?

写到这里,我突然想起最近在知乎上有人问:让孩子背诵他们根本不懂的古诗词、古文有什么意义?

@亚尔斯兰战记 有个很有意思的回答:

因为长大了以后我们面对三千世界里的无数美景时,脑子里出现的不是“我艹”,“牛B”

而是“落霞与孤鹜齐飞,秋水共长天一色”

小孩子有个理解力很差而记忆力超强的阶段,这个阶段就是上帝设计来让小孩子背东西的,不需要理解,长大后在经历世事的时候自然会去联想到,会去理解。而你不背,将来就真得只能“我艹”,“牛B”了

对于成年人来说,理解力强了,而记忆的能力下降了,怎么办呢? 这里推荐一个软件,叫做anki
anki_invest
这是一种记忆卡片,你在卡片正面写上问题,在背面写上答案,你只要每天打开一次这个软件,他会根据长期记忆的遗忘曲线原理,在恰当的时候提示你背卡片,从而不费劲的把你想记住的东西变成长期记忆。

希望大家都能用好自己的大脑,发挥更高的效率!

Share

职业女性确实处于劣势吗?

源起

前两天,在一个武汉本地程序员聚集的技术社区微信群里某位群友发了两张图片:

8b1ece2agw1eqsw4fbiytj20fe0a6q8i

8b1ece2agw1eqsw4dzf8ej20fe09v0z9

这是某个IT公司的招聘宣传,为程序员提供的鼓励师。

(由于图片出现在愚人节期间,不确定该公司是真的有这样的人员配备,还是恶作剧的,此处暂且存疑)

马上群里就有一位X君跳出来说这种事情就是混蛋啊,怎么女人就得给男人端茶倒水擦汗啊。

另外一位Y君就说没有啊,这就是开个玩笑啊,不要这么较真啊。

X君继续说:!@#¥%……&*啊

Y君回应:*&……%¥#@!啊

于是,你也可以猜到的,这中间X君就说了IT行业对于女性从业者存在歧视,收入不平等之类的话。

这让我颇为感慨:武汉也无非是这样。武大的樱花烂熳的时节,群中却有这样标致极了的讨论。其实,又何止武汉呢?

正当X君与Y君酣战之时,有另外一位群友问声称存在收入歧视的X君是否有数据支持其观点。

恰巧我这周正在看《胡适文选》。胡适之先生反复提醒读者要有怀疑精神,凡事要讲求证据,要用科学的手段得出科学的结论。

胡适之先生之言于我心有戚戚焉,于是我便想要搜罗数据,深入了解一下这个话题,算作是对胡适之先生的遥远致敬。

以上,为源起。

定题

近来我正尝试着自我疏离本性中近似于周树人先生的那一部分。

便不太愿用“歧视”这个颇为尖刻的词汇,因而本文的标题中用了“劣势”这一稍为中性的说法。

既然要考据,就不妨把话题放大些,不独观察IT行业的女性,莫若把视角扩宽到整个职业女性上去。

再加上我不是专业的考据家,并没有投入大量时间精力去搜索资料,交叉引证也不够详备,那就不能怕会过谦,也在标题上加上“不甚严谨”这几个字。

于是便有了这个颇显啰嗦的标题:《职业女性确实处于劣势吗?记一次不甚严谨的考据 – 向胡适之先生的遥远致敬》。

是为题目由来。

开篇

我是一个颇为庸俗的人,也时常会被称为理性的人。

于是,别人看待职业女性的眼光、上司是否会给小鞋穿、同事是否会区别对待等等这些无法量化,难以考量的因素均不采用。

我就只认准了:

在一个行业中具有某种特征的人群占多数就可以被称作是有优势的

在一个行业中具有某种特征的人群挣钱多就可以被称作是有优势的

这两条考校标准。

所以接下来通篇都围绕着人数多寡和挣钱多少展开。

什么行业收入高?

中华人民共和国国家统计局,中国统计年鉴(2014)中有一个条目:按行业分城镇单位就业人员平均工资,以Excel格式提供:

(这一行Excel实在是太长了,我把它分开截了两张图)

8b1ece2agw1eqsy6hday7j21wc090q76

8b1ece2agw1eqsy4ojncwj21dq09a0wn

 

其中收入最高的三个行业标记为了红色,分别为金融,IT和科研。

原数据可以在这里找到:
http://www.stats.gov.cn/tjsj/ndsj/2014/indexch.htm

点击左侧的“四、就业和工资”然后点击第“4-15”项,里面可以下载Excel。

或者也可以直接通过这个链接下载Excel:
http://www.stats.gov.cn/tjsj/ndsj/2014/zk/html/Z0415C.xls

那接下来就按图索骥,考量这三个行业中女性的状况。

(为什么只有三个?笔者精力有限,只求管窥,不求完全覆盖)

金融

搜寻良久,实在是找不到国内的资料,只好拿些英文的资料作为旁证了。

以下是来自美国的公平就业机会委员会(Equal Employment Opportunity Commission,缩写为EEOC)2006年发布的一份报告中关于女性金融从业者比例的图表:

8b1ece2agw1eqtfg16y00j210q0gg7ez

从最后一行的汇总信息可以看出,经理级别的职位,女性占18%左右。

专业从业者中,女性约为26%。

技术与销售类的职位则只有个位数的百分点。

但到了书记员,抄写员(Clerical,表中最后一列)这一类的职位,却有43%是女性。

由此不难观察到,在美国,金融这个高薪行业中女性在做着勤务工作,升到经理职位的甚少。

这份报告的出处:
http://www.eeoc.gov/eeoc/statistics/reports/finance/finance.pdf

公平就业机会委员会的wiki页面:http://zh.wikipedia.org/wiki/公平就业机会委员会

而另外一份来自于英国平等与人权委员会(Equality and Human Rights Commission,EHRC)2009年春季发布的报告则有些不同:

8b1ece2agw1eqtfj8tpjsj214010ahcb

从这张男女性别比例的图表可以看出,英国的金融行业男女从业人数基本一比一,差距不大。
从最后一行的汇总数据来看,女性还比男性多一个百分点。

而下面这张出自同一报告的关于收入差距的图表,则显露了另外的信息:

8b1ece2agw1eqtfg31dloj218c14qe6v

英国金融行业中,全职工作的男性年收入比全职工作的女性多55%。

而在全社会所有行业中,这个数字也有28%。

可见在英国女性虽然以同等的人数参与进了金融行业,但是却没有拿到哪怕是接近同等的薪水。

这份报告的出处:
http://www.equalityhumanrights.com/sites/default/files/documents/download__finance_gender_analyis_research.pdf

平等与人权委员会的wiki页面:http://en.wikipedia.org/wiki/Equality_and_Human_Rights_Commission

IT

接下来开始看三大高收入行业中的第二名:IT行业中女性的状况。

我找到了一份来自美国的非营利机构:National Center for Women & Information Technology (NCWIT)在2009年发布的报告。

(没找到这个机构确切的中文翻译,就保留原文吧)

报告中有一张女性IT从业人员比例随年份变化的趋势图

8b1ece2agw1eqszx7ctf5j20vc0jujte

容易看出,从上个世纪八十年代中期到九十年代初期,女性IT从业者比例在攀升,从30%增长到37%左右。

在此之后则一路下降,到2008年已经减少到了25%左右。

出自同一报告的还有另外一张男女收入差距随工作经验变化的趋势图

8b1ece2agw1eqszx63er1j20vk0h8jto

可以看出,入行初期男女收入没太大区别,但从第三年开始,逐渐拉开差距,由3%增加到12%。

好了,又是一个高薪行业。女性只占其中的四分之一,而且收入还比男性少。

报告出处:http://www.ncwit.org/sites/default/files/legacy/pdf/NCWIT_TheFacts_rev2010.pdf

NCWIT的wiki页面:http://en.wikipedia.org/wiki/National_Center_for_Women_%26_Information_Technology

科研

高薪行业之三,科研。

找到了两份来自欧盟的报告。

第一份报告中有一张科研行业中女性从业者比例的图表,数据采集自1999年:

8b1ece2agw1eqtgj4x3wdj20w80pcwhe

不难看出,其中希腊和葡萄牙的女性科研工作人员较多,占有41%和43%。

德国和匈牙利则很低,女性只有14%到19%。

其他八个国家大致是落在26%到33%这个区间。

第二份报告发布于2012年,其中有一张男女收入差距的图表:

8b1ece2agw1eqtgj4s92yj20ty0t6wl8

该图表数据统计于2002年和2006年,从中不难看出,女性在科研行业的各个分支中收入比男性低20%到40%。

由此可见,在欧洲,科研行业作为一个高薪行业,其中女性从业人员较少。
即便进入这个行业的女性,其收入也要较男性低。

第一份报告出处:https://ec.europa.eu/research/swafs/pdf/pub_gender_equality/wir_final.pdf

第二份报告出处:http://ec.europa.eu/research/science-society/document_library/pdf_06/meta-analysis-of-gender-and-science-research-synthesis-report.pdf

发布报告的欧盟网站:http://ec.europa.eu/index_en.htm

小结

以上观察了三个薪水最高的行业:金融,IT和科研,这三个行业中都呈现出了女性从业人员少于男性,且收入低于男性的态势。

如果这条结论和以上干巴巴的数据无法让您获得感性的认知的话,那我们再结合其他数据做个分析。

以下是来源于非营利组织National Association of Colleges and Employers (NACE)的一份报告中关于平均年工资涨幅的数据:

8b1ece2agw1eqtzeznwmwj21020eqwgt

可以从最后一行看出,平均工资涨幅是每年7.5%。

这意味着什么呢?

[1] pry(main)> Math.log(1.55,1.075)
=> 6.059885534213904
[2] pry(main)> Math.log(1.12,1.075)
=> 1.5670305391527257
[3] pry(main)> Math.log(1.20,1.075)
=> 2.5210161634544224
[4] pry(main)> Math.log(1.40,1.075)
=> 4.652504958776575

如果您不是IT行业的看不懂上面的代码没关系,我来解释一下。

这意味着,如果您是一名金融行业的女性从业者,您旁边座位上是一名和您同时进公司的男同事。
你们的关系很好,他甚至都不介意让您看他的工资单。这给在公司属于珍稀物种的您带来了不少宽慰。
但是经过分析自己历年的工资涨幅,您会发现如果您想要和他赚到一样多的钱的话,您还要再工作六年才行。

而这个数字在IT行业是一年半

在科研行业是两年半四年半

以上引用报告出处:https://www.naceweb.org/uploadedFiles/Content/static-assets/downloads/executive-summary/2014-september-salary-survey-executive-summary.pdf

NACE的wiki页面:http://en.wikipedia.org/wiki/National_Association_of_Colleges_and_Employers

然后呢?

以上仅仅是通过交叉引证来描述了职业女性的状况。是属于实证性的表述(positive statement)。

而关于职业女性应该处于何种状况,那是属于规范性的表述(normative statement),本文就不涉及了。

女性在这些高薪行业中人数少于男性,这是好事吗?这是坏事吗?

女性在这些高薪行业中收入低于男性,应该如何评价这件事呢?

金融,IT和科研,听起来都是理工宅男的专长啊,女的少不是属于正常现象吗?

女性的收入低于男性,那有可能是她们干活不给力啊,那收入低就是应该的吧?

所有这些问题,都属于价值判断。通过上面引用的数据,以及常识的积累,我对这些问题会有确定性的判断。
想来你也能猜到我的判断是什么。但是我不把它说出来,留待读者自己得出结论

最后

如果您觉得这篇博客写的还可以,请用手机支付宝扫描下面的二维码:

我会把收到的巨款用来置装,美容,健身。

然后穿的花枝招展,抹的五彩绚烂,露出两条人鱼线。

站在女程序员们旁边,给她们端茶倒水擦汗。

并且忘掉我也可以是一个独立的个体,也可以通过某种其他的方式体现自我价值。

成为一名雄性鼓励师,从此人生走上巅峰。

最后的后面

最后的后面怎么还有呢?因为标题已经啰嗦了,索性结尾也啰嗦一下。

说是不严谨的考据,但是还是用了十几个番茄钟,五六次git commit,三四次审校。

8b1ece2agw1eqtkcps0zaj21g60zejya

8b1ece2agw1eqtkec0012j21fq0ku7a1

七易其稿也不过是如此的两倍嘛。

不过从此以后,我要与这样的辛劳说再见了。我要成为一个靠性别,靠脸,靠身材吃饭的男人。

所以,你懂的,趁我还能靠智识谋生,扫码吧。

别跑,说的就是你,别骗我,我知道你余额宝收益好几十块钱一天呢。

难道你就不想为一位志存高远的未来雄性鼓励师提供一些帮助吗?

(胆敢说我最终还是免不了被周树人附体的善款要x2)

现在,请回到页面的最上端,再看一遍那两张图片,请问您现在看到的东西和读本文之前还一样吗?

原文链接:http://cuipengfei.me/blog/2015/04/04/women-in-finance-it-and-r-and-d/

Share

看板和利特尔法则

利特尔法则(Little’s Law)作为一个非常朴素的原理,为看板方法奠定了一个理论基础,看似简单的公式背后却有其复杂的一面。

一、利特尔法则

利特尔法则的公式是这样的:

平均吞吐率=在制品数量/平均前置时间

举个例子,假设你正在排队买快餐,在你前面有19个人在排队,你是第20个,已知收银窗口每分钟能处理一个人的点餐需求,求解你的等待时间。

如果你已经决定要排队,并且站到了队尾,那么在制品数量就是20(个),平均吞吐率是1(人/分钟)。
从你站到队尾的时候开始,一直到你点完餐,这个时间就是你的“前置时间”。
即使我们没有学习过利特尔法则,也可以轻易地算出来:

    1 = 20 / x
    x = 20(分钟)

因为在一段时间之内,保持工作量饱满的话,我们每天能做多少工作基本是一定的,所以吞吐率基本上不会发生太大变化。
如果这个时候我们想缩短平均前置时间,也就是等待的时间,利特尔法则告诉我们:可以通过减少在制品数量来达成这个目标。
在这个例子中,就是减少排队者的数量。

这也很好理解,10个人的队列和20个人的队列,前者需要等待的时间会更短。 [1]

二、限制在制品的意义

如上面所说,在制品数量和前置时间是成正比的,缩短前置时间的最有效手段就是减少在制品数量。

前置时间的增长会导致交付周期变长,这一点基本毋庸置疑。

前置时间的增长会导致交付的可预测性下降,俗话说“夜长梦多”,长时间停留在某一个阶段会带来一些额外的风险。

如果我们的交付周期比需求变化周期更长,那么会有更多的紧急任务,所以交付周期变长会导致更多的紧急任务。

如果我们管理不好紧急任务的插入,会增大我们的在制品数量。

如果交付团队的可预测性很低的话,那么会影响到IT研发组织和业务部门的信任关系,当业务部门无法预测一个需求提交给研发部门什么时候能交付的时候,那么唯一可行的手段就是一次性把要做的事情全部都压给研发部门,直接增大了研发部门的在制品数量。

同时在制品数量的增长会带来的另外一个后果就是故障发现得很晚,这一点在过去三四十年的软件工程方法论中都得到了验证。

发现的故障需要资源和时间来进行修复,带来的就是在制品数量的上升和前置时间的增长。

以上所有的事情我们放到同一张图中,可以看到下面的情况,实线表示两者之间存在因果关系,同时还是正比的,因增大,果也会增大。虚线表示两者之间存在的因果关系是反比的,因增大,果会减小。

22484-4c2d36ae3b6f766f

因果回路图

而在这众多因素之中,只有在制品数量是我们能够最有效的直接加以干预的。
而只有前置时间我们是可以直接观测的。

就像我们正在开车一样,我们踩油门的时候,速度表会发生变化,从60迈到100迈,但我们真正关心的并不是仪表盘的变化,而是真正汽车行驶的速度。

所以我们采用控制在制品数量的手段,通过观测前置时间的变化来观察我们的改进是否有效,但更重要的是整个系统是否正在向着更好的方向迈进。

三、在制品数量是不是越低越好

我们用直觉感受一下,在制品数量如果越低越好,那限制到1怎么样?限制到0怎么样呢?

很显然,在制品数量如果过低的话,团队成员可能会产生空闲的现象,很大一部分产能会被浪费掉,那在制品数量限制到多少是最合适的呢?

我们都知道,一个任务如果2周能完成,两件任务串行,需要的时间是4周,但两件任务并行,绝不是2周能完成,有可能5周的时间都完成不了,所以直觉上在制品数量过高也不能带来产能的上升。

所以一个朴素的原则就是:
团队中每个人在任意时刻,手中只有一件事的时候,效率是最高的。团队的在制品数量低于这个值,会造成产能的浪费,如果高于这个值,会造成前置时间的变长。

那我们再用定量的方式模拟一下吧。

假设我们有一个三阶段的开发流程:分析、开发、测试,平均每张卡片需要4天时间分析、5天时间开发、6天时间测试。

为了简化计算,我们把分析、开发、测试三个阶段设一个总的在制品数量限制。 [2]

22484-5996f0d58c826265

模拟看板

当我们有1个分析人员、1个开发人员、1个测试人员的时候,会得到下面这个结果:

WIP平均前置时间平均产能1150.072150.133180.164240.165290.166350.167410.168470.169520.1610580.16

22484-b95912514fb62b9e

折线图这个实验可以重复,有兴趣的同学可以自己写代码重复一下。

结论

  1. 减少在制品数量可以缩短前置时间,但前置时间的缩短是有极限的,就像我们不可能让10个妈妈在1个月之内完成怀孕的全过程一样。
  2. 增加在制品数量可以提升平均产能,但平均产能的提升是有极限的,1个人每天8小时的产能再想提升只有加班加点。
  3. 最短的前置时间和最大的平均产能不可并存,在“平均每人手头有一件事”的时候,在制品数量稍微小一点,可以达到最短的前置时间,在制品数量稍微大一点,可以达到最大的产能。至于各个组织如何选择,看自己的需求了。

[1]: 道理看似很简单,但放在软件研发领域就变得非常复杂,我们需要平衡需求和产能之间的关系,控制队列长度实际上就是在控制期望和承诺。在尊重事实的前提下,我们尽量让队列的长度变短,不去承诺不切实际的东西。

[2]: 所谓“排队”,实际上软件开发真正的“收银窗口”就是最终交付的环节,在这个环节之前的所有需求其实都是一个队列,队列的末尾就是我们最近承诺的一个需求。所以一旦我们承诺了无法立刻着手的需求,那么就会产生极大的浪费。

Share

实战:持续交付中的业务分析

在需要频繁交付、不断收集用户反馈、拥抱变化、追求业务敏捷的项目中,软件的开发和交付是迭代式进行的。在这样的项目团队中,BA(业务分析师)通常需要在一个开发迭代开始之前完成该迭代开发任务的分析。但在特殊情况下,从收集客户需求到将功能细节传达给开发团队的周期会缩短到一至两天。BA可以用于思考和分析的时间远远少于可以预先做出所有设计的瀑布式项目。

那么在这样的敏捷项目中,BA如何能够适应这种交付模式,完成高质量的业务分析,协同团队为客户交付高价值的软件呢?

项目背景

ABC公司是一家知名的国际性会计师事务所,业务规模庞大,分支机构遍布全球170多个国家。

ThoughtWorks受邀对其“全球派遣服务(International Assignment Service)”业务部门提供IT解决方案,以及软件系统的开发。该系统包括收集其客户的全球派遣雇员的报税数据,以及管理ABC公司税务咨询师对这些数据的进行审核、汇算和出具报告的业务流程;逐步替换其目前已远远不能满足业务和性能需求的遗留系统。

该系统主要有两类用户,一类是ABC公司客户方被派往不同国家工作的雇员(以下简称Mary),这些雇员使用该系统填入报税需要的数据。另一类用户是ABC公司的税务咨询师(以下简称Kim),负责审核、处理Mary提交的数据。

BA在该项目中面临的主要挑战

  • 该项目为分布式开发,ABC公司的决策方在美国,而ThoughtWorks的开发团队在中国,沟通反馈周期有时较长。
  • 由于ABC公司对用户体验的重视,需要频繁交付软件,以便收集用户反馈并及时调整解决方案和后续开发计划。这大大缩短了从收集需求、开始分析到进入开发的周期,增加了分析中出现缺陷的风险。
  • 当开发过程中发现问题时,无法马上与客户取得沟通,开发进度可能会受到影响。

识别业务价值

业务分析的重要性在于首先做正确的事情。理解客户的业务,关注需求背后的价值可以帮助项目团队在软件的设计方面做出正确的选择。

而我们面临的困难是,客户提出的需求,往往都是直接的软件功能,而不是需要解决的业务问题。如果BA只专注于针对客户需要的功能进行系统分析,就丧失了帮助客户优化解决方案以及改进业务流程的机会。

如何寻找业务价值?

以敏捷开发方法中的用户故事为例,找出客户要解决的业务问题的一个简单办法是,用以下方式概括每个用户故事的内容:

As…(角色),I want to…(完成什么样的功能),So that…(解决什么问题,带来什么价值)

“So that…”说明了该故事的业务价值,即要解决的业务问题。准确的寻找业务价值将有利于我们设计出最适合的“I want to”,这很可能优于客户直接提出的功能要求。

需要注意的是,不要把解决方案或功能当成该用户故事的价值。以ABC公司业务系统中的一个用户故事为例,BA对该需求业务价值的了解程度将直接影响到解决方案的优劣。

作为(As…) 我想要(I want to…) 以便(So that…) 是否阐明了价值?
Mary 即时浏览我的行程统计数据 了解我在各个国家或地区停留的时间以及从事的活动
Mary 即时浏览我的行程统计数据 我可以迅速地检查我所输入的在各国家或地区停留时间及从事活动的数据是否正确(以保证我可以依照法律要求提交准确的报税数据)

在该用户故事的两种不同表述中,由于第一种表述只说明了需要的功能,没有说明业务价值,在功能设计时,我们可能会将“行程统计数据”的内容设计的过于详细而造成浪费,使用户不明白此功能的意图。而第二种表述的业务目标就非常明确,可以帮助我们更加容易地设计出适合的解决方案。

此外,BA在了解客户的业务问题时,最好请客户提供一些真实案例/场景来证实其观点并加深自己的理解。

避免分析错误

在实际工作中,我们发现有以下两个方面的分析工作容易被BA忽略,而做出错误的决定。

    1. 客户要求实现某些现有业务流程或遗留系统的功能

例如,客户需求的功能,是当前遗留系统中已经使用多年、且未收到过任何抱怨的功能。所以客户和BA往往认为这个功能是合理的,忽略了深入的分析和思考。而这种思考不全面而做出的决定可能会与可以预见的新功能产生冲突。

在ABC公司的遗留系统中,用来收集报税数据的问卷内容是通过excel表来维护的,而Mary在前台也是通过下载excel问卷,填写完毕后再上传。

在新开发的系统中,问卷被改为在线方式,并辅助以其他必要功能提升Mary的用户体验和满意度。但由于客户方的员工都是财务背景出身,非常喜欢使用excel表,而之前用excel表维护问卷内容也被证明是非常有效的,所以客户坚持在新系统中延用这种方式。经过仔细的分析,我们发现在针对提高Mary用户体验的新功能上线后,使用excel表维护问卷内容将大大增加维护的工作量及错误率,而这与项目的相关目标背道而驰。ThoughtWorks在列举了问题的细节后,说服客户采用了新的解决方案。

    1. 客户要求利用新的IT系统改变当前的业务流程

客户发现目前的业务流程有不合理的地方,希望在新的IT系统里直接改变这些流程。如果不经过仔细的分析,这种做法可能会很危险,业务流程的盲目改变可能会对一部分用户造成麻烦,为客户实施该软件形成强大阻力。那么了解清楚目前这些流程存在的价值和原因事关重要,从而可以帮助我们为客户提供科学的、逐步优化其流程的IT解决方案。

在ABC公司的业务流程中,Kim和Mary之间的一些交流是通过邮件来完成的。这里存在两个业务风险:1)Kim和Mary交流的重要信息被散落在各自的邮件里,系统无法记录,在遇到法律问题时,难以划分责任;2)Kim和Mary可能会使用邮件发送一些保密性较强的内容,如果发错,后果不堪设想。

在开发新系统时,客户要求我们增加了一个消息功能,使Kim和Mary之间的交流可以方便地在系统内部完成。该功能上线后,很好地化解了这两个业务风险,同时收到了Mary这类用户的良好反馈。然而这对该会计师事务所在某些国家分支机构里的Kim这类用户的工作却带来了不小的影响。由于之前使用邮件系统,Kim可以将Mary的邮件转发给相关的同事,并利用邮件丰富的功能进行结果的跟踪。而新上线的消息功能达不到邮件的所有要求,所以增加了他们的工作难度。此外,由于Mary对这个功能的青睐,发送消息的数量远远超过了在使用遗留系统时发送邮件的数量,超过了客户想提高Mary的满意度而在短期内所能承受的代价。

在遇到以上问题时,我们与客户一同分析,提出了折中的解决方案,花费了较少的代价将消息系统和客户的邮件进行集成,同时帮助客户制定了对此项业务流程改进和配套IT解决方案的蓝图。

理清需求优先级

在频繁上线的项目中,其中一个重要的实践是确定需求的优先级,使得重要的功能能够先被开发出来投入使用以便及时收集用户反馈。一般的做法是要求客户排好需求优先级,然后与项目相关成员一同制订迭代开发和上线计划。但由于客户决策方所处角色以及思维角度的局限性,对优先级的评定可能存在盲目。建议BA参照以下价值维度帮助客户对优先级进行评定。

从客户价值维度分析需求优先级

需求价值维度分析图

价值维度 说明
愿景目标 该功能点是否契合项目的愿景和业务目标?与项目目标的契合程度越高者优先级越高
时间限制 客户的业务是否有一定的时间表?如果该功能点必须在某时间点前投入使用,则该需求必须被排入相应时间的发布计划中
市场卖点 该功能点是否是吸引特定目标用户的卖点?如果客户的资金存在问题或者需要市场的快速认可,则可以考虑将该需求列为高优先级
有无替代方案 该功能点有无方便的替代方案?如果有简单易行的替代方案,则该需求的优先级较低
客户内部政治因素 该功能点是否存在客户内部的政治因素?例如某功能只对小部分用户提供价值,但会决定客户内部某个重要组织对这个项目的投资和评价,则可以考虑将该需求列为高优先级
投资收益 该功能点的开发成本和客户所能获得的收益是否匹配?例如客户某工作流程浪费了一个小组人员大量时间,但对其他部门或工作环节无影响。如果开发相应的软件功能造成的投入大于客户在一定时期内可以节省的资金,则该需求的优先级较低
技术依赖性 其他需求是否依赖于该功能点?如果依赖于这个功能点的需求优先级高,那么该功能的优先级应更高

技术风险对优先级的影响

除了来自客户方面的决定因素,我们还应考虑技术实现方面的影响。如果一些技术风险较高的功能可以先进入开发阶段,则问题会尽早地被暴露。开发人员在项目早期解决这些问题会有利于开发成本的节约。所以除以上客户价值维度外,应再参考以下矩阵来权衡需求的优先级。

需求优先级矩阵

客户价值维度和需求优先级矩阵并不是优先级高低的计算器,而是与客户以及团队沟通交流的工具。不同项目的影响维度也会有所不同。由于各项因素的复杂性,客户价值维度和技术风险因素需综合考虑,不可以权重来计算。BA可以与客户对以上因素的内容达成一致,使得客户在评定需求优先级时可以快速、准确地做出判断。同时,通过对价值维度的分析,我们将有机会清晰地了解到功能优先级高或低的原因,以便我们能够准确地编制项目开发和上线计划,并合理地划分用户故事范围。

借助价值维度分析,管理客户期望值

有些客户的决策人可能会依据自己的喜好划分优先级,这对于项目能够按目标成功交付造成一定的风险。此外,客户在功能的设计和验收阶段也容易对单个功能追求完美,造成额外工作量,增加项目范围。而这部分额外工作可能并不合理或者价值较低。长期如此,团队在开发过程中将逐渐偏离项目目标。如果能借助优先级维度对这些额外需求进行分析,则可以提供更有说服力的依据,帮助客户做出正确决定,达成BA和项目经理对客户期望值的有效管理,从而降低交付风险。

发挥团队其他成员在业务分析中的作用

在频繁交付的项目中,如果BA独自承担业务分析工作,难免会出现疏漏。ThoughtWorks曾与ABC公司的IT部门合作完成其业务系统的一些集成工作。在合作过程中发现,ABC公司IT部门的开发人员在业务分析中参与度很低,由此造成了如下问题:

  1. BA需要写大量需求文档,故从需求分析到软件交付的周期较长
  2. 设计缺陷的发现滞后
  3. 在需要频繁交付的情况下,解决方案质量较差,方案优化能力较弱

而ThoughtWorks的开发人员由于在业务分析中的参与度较高,则有效地避免了以上问题。

开发人员如何参与分析

开发人员是软件功能的实现人员,对方案的实现工作量有较准确的估计。在明确项目目标或业务问题后,BA如果能够和开发人员一同分析解决方案,将更有效地为客户找到兼顾成本和效果的方案。

在收集到客户需求后,BA可根据业务价值对需求进行分析,判断客户提出的功能或解决方案是否能很好地满足该业务价值或要解决的业务问题;或者按照自己的理解设计出满足该业务价值的功能或解决方案。

完成上述工作之后,BA应与开发人员就需求和业务价值进行充分沟通,验证功能实现的可行性,同时积极探寻更优方法。如果开发人员提出符合业务价值的不同方案,BA则可以要求开发人员提供一些关于开发工作量、方案优劣、技术风险方面的比较数据,从而帮助自己有效地与客户沟通并挑选最佳方案。甚至可以根据分析结果帮助客户调整该需求的优先级。对于技术难度和风险较高的功能点,建议邀请资深开发人员参与讨论。

与开发人员沟通中遇到的挑战与解决方法

由于上述方法需要与开发人员大量沟通,有些BA在应用以上实践时也遇到了以下挑战。

    1. 开发人员缺少参与业务分析的热情

在ThoughtWorks,大多数开发人员都喜欢积极思考、主动为业务分析提供帮助,大大减少了需求分析上的漏洞。然而在ABC公司的IT部门中,开发人员很少主动为业务分析出谋划策,尤其是团队中资历较浅的成员,甚至不愿意参与解决方案的讨论。团队成员的优势没有得到充分发挥,开发人员只管按需求埋头苦干,结果功能和解决方案的问题往往在测试或者验收阶段才暴露出来,不可避免地造成了浪费。

站在开发人员成长的角度,从ThoughtWorks实践来看,积极地理解业务、思考解决方案能够更快地提高技术能力。故此BA可以找出一些实际案例,协同项目经理与团队各成员进行沟通,鼓励大家积极参与业务分析,逐步形成开发人员与BA协作的良好氛围。

    1. 开发人员容易就客户需求或解决方案产生争论

开发人员在积极参于分析的过程中,有时会对软件功能的价值吹毛求疵,在细节上与BA产生较多争论,使BA在应付开发人员的问题以及与客户求证答案之间疲于奔命。

解决此类问题,可采取以下方法:

  • BA在收集需求时,尽可能充分地了解客户要解决的业务问题,以便能够快速回答开发人员的问题
  • 面对开发人员对解决方案的质疑时,应保持良好的心态,清楚地了解开发人员顾虑的问题和原因
  • 如果自己掌握的信息确实不能证明现行方案的合理性时,协同开发人员,找到更优方案并与现行方案进行优缺点比较
  • 将新旧方案与客户沟通,则可快速帮助客户做出判断

不要忽略测试人员在业务分析中的贡献

由于测试人员所处角度和对细节的关注,往往可以发现一些功能细节的设计漏洞。所以在用户故事进入开发前,BA与质量保证人员对相关业务价值进行充分沟通,会在功能进入开发之前为BA创造更正设计缺陷的机会。

做为质量保证人员,如果充分了解功能背后的业务价值,相对于只了解功能需求,将可以写出更加完善的测试用例,提高测试覆盖率。这会为交付高质量的软件把好最后一道关。

结语

业务分析是困难的,特别是我们面对未知领域的时候。如果只是简单地按照客户的具体需求进行软件开发,那么我们交付给客户的价值将非常有限。然而识别业务价值、帮助客户分析需求优先级、保障团队协作,将有效提升团队对软件的设计能力,解决客户真正的业务问题,交付更大价值。

作为一名业务分析人员,当您在尝试以上实践时,可能会发现自己对客户业务的理解变得更加深刻。在与客户的沟通中,也能够更加容易地提出有价值的问题以及建议,从而提升客户对项目团队的信任,为成功交付项目打下良好基础。

*注:“客户价值维度”的概念由ThoughtWorks咨询师李光磊提出。在此对李光磊表示感谢。


Share

软件系统的稳定性

软件系统的稳定性,主要决定于整体的系统架构设计,然而也不可忽略编程的细节,正所谓“千里之堤,溃于蚁穴”,一旦考虑不周,看似无关紧要的代码片段可能会带来整体软件系统的崩溃。这正是我阅读Release It!的直接感受。究其原因,一方面是程序员对代码质量的追求不够,在项目进度的压力下,只考虑了功能实现,而不用过多的追求质量属性;第二则是对编程语言的正确编码方式不够了解,不知如何有效而正确的编码;第三则是知识量的不足,在编程时没有意识到实现会对哪些因素造成影响。

例如在Release It!一书中,给出了如下的Java代码片段:

package com.example.cf.flightsearch; 
//... 
public class FlightSearch implements SessionBean {
    private MonitoredDataSource connectionPool;
    public List lookupByCity(. . .) throws SQLException, RemoteException { 
        Connection conn = null; 
        Statement stmt = null;
        try { 
            conn = connectionPool.getConnection(); 
            stmt = conn.createStatement();

            // Do the lookup logic
            // return a list of results
        } finally { 
            if (stmt != null) {
                stmt.close();
            }
            if (conn != null) { 
                conn.close();
            }
        }
    }
}

正是这一小段代码,是造成Airline系统崩溃的罪魁祸首。程序员充分地考虑了资源的释放,但在这段代码中他却没有对多个资源的释放给予足够的重视,而是以释放单资源的做法去处理多资源。在finally语句块中,如果释放Statement资源的操作失败了,就可能抛出异常,因为在finally中并没有捕获这种异常,就会导致后面的conn.close()语句没有执行,从而导致Connection资源未能及时释放。最终导致连接池中存放了大量未能及时释放的Connection资源,却不能得到使用,直到连接池满。当后续请求lookupByCity()时,就会在调用connectionPool.getConnection()方法时被阻塞。这些被阻塞的请求会越来越多,最后导致资源耗尽,整个系统崩溃。

Release It!的作者对Java中同步方法的使用也提出了警告。同步方法虽然可以较好地解决并发问题,在一定程度上可以避免出现资源抢占、竟态条件和死锁的情况。但它的一个副作用同步锁可能导致线程阻塞。这就要求同步方法的执行时间不能太长。此外,Java的接口方法是不能标记synchronized关键字。当我们在调用封装好的第三方API时,基于“面向接口设计”的原理,可能调用者只知道公开的接口方法,却不知道实现类事实上将其实现为同步方法,这种未知性就可能存在隐患。

假设有这样的一个接口:

public interface GlobalObjectCache {
    public Object get(String id);
}

如果接口方法get()的实现如下:

public synchronized Object get(String id){
    Object obj = items.get(id); 
    if(obj == null) {
        obj = create(id); 
        items.put(id, obj);
    } 
    return obj;
}

protected Object create(String id) {
    //...
}

这段代码很简单,当调用者试图根据id获得目标对象时,首先会在Cache中寻找,如果有就直接返回;否则通过create()方法获得目标对象,然后再将它存储到Cache中。create()方法是该类定义的一个非final方法,它执行了DB的查询功能。现在,假设使用该类的用户对它进行了扩展,例如定义RemoteAvailabilityCache类派生该类,并重写create()方法,将原来的本地调用改为远程调用。问题出现了。由于采用create()方法是远程调用,当服务端比较繁忙时,发出的远程调用请求可能会被阻塞。由于get()方法是同步方法,在方法体内,每次只能有一个线程访问它,直到方法执行完毕释放锁。现在create()方法被阻塞,就会导致其他试图调用RemoteAvailabilityCache对象的get()方法的线程随之而被阻塞。进而可能导致系统崩溃。

当然,我们可以认为这种扩展本身是不合理的。但从设计的角度来看,它并没有违背Liskove替换原则。从接口的角度看,它的行为也没有发生任何改变,仅仅是实现发生了变化。如果不是同步方法,则一个调用线程的阻塞并不会影响到其他调用线程,问题就可以避免了。当然,这里的同步方法本身是合理的,因为只有采取同步的方式才能保证对Cache的读取是支持并发的。书中给出这个例子,无非是要说明同步方法潜在的危险,提示我们在编写代码时,需要考虑周全。

本文原文出自:http://zhangyi.farbox.com/post/stable-software-system

Share