构建之法
首发于构建之法
Build To Win

Build To Win

前不久和一些朋友在讨论 《构建之法》的一些问题,例如,“构建之法这本讲软件工程的书为什么要讲创新”? 我解释说,人们出于很多不同的目的构建软件,我在《构建之法》的第二版(多看版)提到过不同的驱动模型。 在这里更详细地分享一下,希望各路专家多提意见:

Build To Learn

在很多情况下,写软件,构建系统的目的是做进一步的试验,试图发现客观规律,或某个试验方法的优点与缺点。这些项目经常是科研论文的基础工作。大学IT 专业的各种大作业 (实现某算法,做一个编译器,模拟一些操作系统的功能,做一个图书馆管理系统,等) 都是通过构建软件来学习其中的原理。好多学生的大作业是想 Learn 一些东西,但是如果老师抓得不紧,未必能学到什么。Build To Learn 未必都是小规模的,我想到的最大的Build To Learn 项目是欧洲核子研究组织 (CERN) 的粒子加速器:

(知乎专栏的编辑器在IE11中无法插入图片,只好加一个链接


其中一个加速器长度为27公里,需要大量的土木,电力,电机工程,计算机网络工程的基础建设及运营,所有这些,都是为了 Learn – 研究那些肉眼根本看不见,也未见得和大众的现实生活有关的各种粒子们。

这种类型的项目未必成功率高,许多科学项目,花了大价钱去Build,但是还没有来得及 Learn,项目就下马了

我在微软亚洲研究院参与了不少这样的项目,当时没有理解这类项目的特殊性。例如,我们工程团队和一个研究小组合作开展一个项目,用某种机器学习的方法做文档中实体抽取 (Entity Extraction) 和实体之间关系的抽取,然后展现它们之间的各种相关性。项目进展到了后期,我注意到,我们所用的方法虽然非常强大,但是有一定的局限性,如果结合一些已知的初级方法,会得到更好的效果。但是研究员非常坚持只用他们设计的方法,我很纳闷,几经争执和讨论,原来两边想法不一样。研究员的想法是:

我要单纯地用我的方法,证明这个方法相对于其他方法的优点。 (然后我就可以发论文了)

我(工程角度)的想法是:

用所有能帮上忙的方法,做出好的结果。(我们就可以出产品了)

从科学研究的角度来说,研究员的想法是挺严谨的,而且是正确的态度. 他们认为科研项目就应该是 Build To Learn 的过程。通过严谨的开发和数据收集,展示某个新算法的价值,发表文章:“我们的新做法在 X 的条件下,提高了 Y 的效率”。以后别人就可以引用此文章,把探索进行下去。

Build To Learn 中的Learn还有一个维度,是向市场、用户学习。MVP (Minimal Viable Product,最小可用产品)就是这一思想的体现,把产品核心功能搞出来就扔到目标用户中,看看反馈,再决定下一步的行动。

科学研究和工程对于失败的态度是很不一样的,在我和众多研究员合作的过程中,倒还没有看到像费曼先生那样急切证明自己错误的人:

和有这种胸怀的人合作, 一定很有意思, 一定能 learn. :)

Build To Show

为了突出地展现某个技术的作用,团队往往会开发一些演示为目的的软件,他们很吸引眼球,经常获得新闻报道,但是未必全面或实用。微软公司每年举办一个TechFest (技术节),都是全世界各地研究院去展示各自的新鲜玩意, 展会的前一天是媒体开放日,开放部分项目给新闻记者采访,记者当然喜欢那些比较吸引眼球的项目,有一年我参与的项目被记者采访,摄影记者在狭小的展位里调整了半天镜头,就想把项目的花哨的界面包括进去。其实吸引眼球的项目太多了。有一年的一个展示是用WiFi 冲咖啡,你用任何智能手机,在WiFi 联网界面上就可以点击 “冲咖啡”,这当然比较酷,也有一定的技术含量,当时挤到展台喝咖啡的人也不少,但后来就没有下文了。 相反,倒是一些不那么热闹的技术,转化到了各种具体的产品中。

为赋新词强说愁,谁不喜欢Show 一下风采呢?曾经我所在的产品团队的PM 设计了一个功能,这个功能在程序启动的时候开启, 显示它的界面, 同时要发好几个同步网络请求,我作为程序员,就建议这个功能默认是关闭的,如果用户得特别需要,他可以去 “选项“ 页面,激活这个功能。 PM 说,那这样我的功能就没有 Visibility 了啊。哦,他隐含的意思是 - 我要Show 给大家看,这就是我设计的功能!

有一年,我去某著名示范性软件学院考察,老师带着学生演示了他们做的优秀项目 - XXX信息管理系统,学生展示得非常流利,说这个系统多么实用,多么地解决了用户的痛点。。。但是,他演示查询结果的时候,我看到页面上只有一个记录,其中只有一个数据字段有一个”圡“字,其余所有字段都是空的。我就问,这是真的数据么?

学生楞了一下,说,是有真的数据,但是在某个地方,这个会议室没有联网……

我说,我看到会议室有网线接口,请接上网线吧,我们可以等。

这时候,学校的老师赶紧出面打圆场,这个”Build To Show“ 的项目才没有砸锅。

要在短时间内Show 出一个项目的价值,这需要提炼出项目的核心价值,并且言简意赅地表达,打动别人。NABCD (现代软件工程讲义 如何提出靠谱的项目建议 NABCD)就是一个比较有效的框架。

Build To Serve

很多组织都有许多内部软件服务,例如内部人事流程的服务,它们的目的就是要维持组织的正常运转, 这些软件当然很有意义,但是他们的目的是“服务特定人群”。做这种软件,最忌讳折腾用户,达到 It Just Works” 最好。 我在一个伟大的公司里使用过很多内部工具,其中一个用来管理员工的绩效,每年其实大家用它最多的时候就是两次,每次相隔半年。但是每到这个时候,这个工具就会变得很慢,好几年都是这样。有一年,它有一次突然改版了! (我想,终于能变快一点了!),不料,它的界面变成了各种大色块的设计,速度没有变快,连原来熟悉的操作都要找半天。

从某种意义上说,为开发者提供的开发平台,工具包(SDK)等,也可以算是 Build To Serve, 也是要避免折腾用户, 有一个开发平台,原来说 XNA 方式很酷,后来又改为 SilverLight, 等大家上手比较熟悉了… 嗨,切克闹,原来的方式又被颠覆了,不推荐使用,咱们改为 Universal App的方法了!这是Build To Serve, 还是Build To zheteng?

Build To Serve 的软件服务,并不是说一成不变,做一个安静的美男子,而是要根据用户的需求,稳妥地演变。 很多学校以前开发的内部系统只支持IE6,当年是挺先进的,但是现在就大大落伍了,但是这些系统就是不改! 搞得一些老师为了用这个系统,不得不装一个有IE6 的虚拟机。我不知道装虚拟机不熟练的老师怎么过这一关。

既然是Serve, 就要有Compliance (合规)的要求, 例如,相关法规要求你的软件能保证用户数据安全,要求色盲、色弱的用户都能使用,要求你必须支持没有鼠标的用户... 这些未必是工程师最想做的功能,但是不得不做。

说到这里,我自我表扬一下…大约在2006年的时候,利用实习生培训的机会,我带领几个实习生开发了微软亚洲研究院的实习生面试和绩效管理系统。 它运行起来不错,08年的时候做过一次小的增量修改,后来就一直平稳运行到现在。 (当年主要的开发者早已毕业,听说已经换了5个公司了... 他一定会来留言的)

Build To Win

“在市场上赢“ 为目标而构建软件。这也是种种学术发现,技术突破,流程创新,灵光闪现最好的试金石。

传统教材里谈的软件工程,都是在没有竞争的环境下做软件,仿佛从真空中,来了需求 -- 客户求我做一个图书馆管理系统,或者某企业来了某个需求…… 仿佛软件团队 “吃定了” 这个项目。这个团队的人都是技术能手,按部就班地搞需求分析,设计……,等等。但是在现实中,由一群水平参差不齐的人组成的团队,要从用户那里,从生活中,从相关技术的进步中,从超前的设想中…… 挖掘需求,提出需求,解决需求。 同时,你要跑赢对手(不光是科班出身的,连卖空调的,讲相声的,搞外语培训失败的,国外潜逃好久的,都可能是你的竞争对手), 你要跑赢技术和行业发展的浪潮,你还要跑赢时间和烧钱的速…… 你要赢,但是需求并不都是从用户那里来, 还有下面这些来源:

  • 公司的商业模式 - 你有一个很好的反病毒软件,是免费的。现在公司需要你让这个软件赚钱!不然大家都失业,这就是软件的需求。用户并没有提这个需求。

  • 你的软件做得好,还有一些要求是没有明文规定的,例如你搞了一个网站,结果一些人要求你随时能删掉帖子,屏蔽用户,删掉用户,但是相关帖子要留给有关部门看到!这些都不是用户直接提的需求。

  • 工程师在工作中,发现原来的代码要重构,架构要调整,否则软件无法继续维护和开发下去。这个需求也和用户无关,甚至相矛盾。

  • 互联网相关的软件还有许多收集用户数据的需求,搜索引擎还要花时间和地方来显示广告(并且引诱用户点击广告),这也未必是最终用户主动提出的。

由鸡,猪,和鹦鹉组成的团队怎么赢? 要创新,但创新有规律么?如何平衡种种矛盾,走出一条理性的,不要拼命加班的道路,还能得到合适的回报? 这是我看到的所有软件工程教科书没有讲的,也是我想在《构建之法》这本书里面探讨的。

“文无第一,武无第二”, 科研需要百花齐放, 不必用一个维度来评判。 在Build To Show 的场景中,大家各显身手,用各种办法展现技术,的确很难在单一的维度上确定谁赢谁输。但是,在Build To Win 的场景中,往往市场就是那么一块, 竞争对手占了70%, 你就只剩下 30%; 如果对手们占了99%, 你就只剩 1% (例如2014 - 2015年的必应搜索和WP在中国的市场份额)。 这个时候,软件团队不能停留在 Build To Show 的幻想中 --

“可是我们的Demo 也很独特啊,我们的某个功能也另辟蹊径了啊... 某个VP 也喜欢我们的想法啊...”。

你要面对现实, 你有多少市场份额? 你要正面冲上去打,用更好的产品去赢。

There comes a time in every company's life where it must fight for its life. if you find yourself running when you should be fighting, you need to ask yourself, "if our company isn't good enough to win, then do we need to exist at all"?

(Ben Horowitz, "The Hard Thing About Hard Things")

工程能力很重要

良好的工程能力,在各种类型的项目中都能够发挥关键作用。 我刚到微软亚洲研究院的时候,曾经有研究员抱怨说,他们的研究项目通常是这样的模式:

一个实习生花几个月的时间搞好了某系统,但是只有那位实习生亲自操作的时候,才能正常运行,其他人操作,则问题多多,经常崩溃。等到实习生差不多搞定所有毛病的时候, 他毕业了。 然后新来的实习生表示看不懂师兄的代码,决定重新搞,这一晃又是几个月,然后同样的模式重复。。。

研究员期望一个 鲁棒的Build To Learn 的系统,可以快速地做各种实验,但是得到的是一个不断低水平重复的 “系统“,没法做一流的研究。

在前面提到的 Build To Learn 的项目中,研究员设计了一个算法,这个算法跑起来的时候,需要 16G 的内存 (这是2008年),如果内存不够,算法就出错。我们提意见说,这个地方可以优化呀!研究员说,不用啊,我们一直用16G 内存的机器跑这个算法就好了!但是到了技术转化阶段,我们要把这一系列的算法放到正式产品中,产品组的开发经理听到这个16G的要求,吓了一大跳 --

“我们的产品会卖给千千万万的中小企业,你怎么能假设他们都有16G内存,而且我们还要在机器上跑众多的服务啊!”

后来我们的工程师花了一些时间,把这个算法的内存降低到了10M(一千多倍的改进),终于把这一系列的算法放进了商业产品中。

另外一个研究员在出差做演示之前,向实习生建议,演示程序的某个算法应该允许好几个参数。结果实习生通过邮件发出来几个巨大的EXE 文件,因为他不懂得怎么用一个EXE 加上参数文件来动态调整算法,研究员哭笑不得。 没有良好的工程能力,就没法做高质量的研发。 这是我在微软亚洲研究院和其他部门开展实习生和新员工的 “软件工程培训“ 的原因之一,因为这个缘故,很多人叫我 ”邹老师“ 。

没有高低贵贱之分

你到了一个公司, 团队里有很多角色, 也有很多分工,每天也写一些程序或测试脚本,目的是什么? 我现在在微软也是一个管理者,新来的实习生会问, 我在这里的工作就是实现别人给的需求么?

也对,也不对。 我们在这里就是要 Build To Win, Do whatever necessary to win.

当然,在工作中也有时候要做一些短平快的项目,我们要最终推向市场,赢得用户,还是给某个VP 看看,show 一下就算了? 后者的情况还不少,这需要大家注意。

我曾经和研究员合作过一个项目, 在第一个会议上,研究员说,不如明天就上线吧! 我问这个网站做过压力测试么? 对方回答,这个项目已经给很多老大都 show 过了, 大家都叫好,也在全体大会上演示过,一些员工也用过,都没有问题的! 我说,不如这样,我们模拟100个用户同时使用,如果能坚持24小时,那就发布。

结果压力测试7秒钟之后网站就崩溃了。 改了这个bug,继续测试,一分钟后又崩溃了。。。

不断改进代码一个月之后,终于通过了压力测试,正式发布了。有一天中央台报道了这个网站,导致很多人来访问,流量一下到了平时的一万倍,但网站依然没问题。

也许有人读了这个文章,觉得只有 Build To Win 最风光,是真理,道路和方向。其实各种软件构建的方式都各有其适用范围,相互的界限也没有那么分明。 一个计算机专业的博士生,他在学习的过程中做过很多 Build To Learn 的项目和大作业,还搞过模式识别,机器学习,一拍脑袋就有想法的 Build To Show 的各种项目, 现在他来到一个世界级的公司,领导要他Build To Win, 他搞了几个月,意识到:

我一生的学识、梦想和精力,都投入到"如何让用户点击更多的页面广告"的事业上了 。

这是高还是低?真不好说。

另外,请看题: 阅读这个博客: 毕业设计我做了个单页面应用,答辩时却被批。 作者是想做什么样的项目,而评审的老师有什么样的期望值?

注:这些各种 Build To 类型,是以前在微软亚洲研究院工作的时候和同事们讨论的时候用的名词,不知道是否有明确和严格的定义。 当然,各种类型是互相有重合的。 Build To Win 这个想法倒是我在写《构建之法》的过程中逐渐明确的。

注:有一本书叫 Built To Last, 我还没读过。

注:题图 -- 据说是粒子加速器鸟瞰图

编辑于 2017-03-27

文章被以下专栏收录