世上无易事

要是我问你，跑百米容易还是跑马拉松容易？这还用问！当然是跑百米容易了，是吧？其实我想问的是：亚洲运动员要拿奥运冠军，是跑百米容易还是跑马拉松容易？答案似乎就颠倒过来了。近邻韩国和日本都已经出过奥运马拉松冠军，比起拿百米冠军，概率要大多了。

有了上面这个问题垫底，你应该可以猜到下面这个问题的意图：现在开发软件容易还是二十年前开发软件容易？现在的软件开发是可视化编程，就着框架搭积木，看起来容易多了。可惜，当我们的问题变成：通过开发软件来赚钱，比起二十年前是不是变得更容易了？答案也颠倒过来了。门槛的降低使得竞争者大量涌入，拉低了软件公司的利润和程序员的入职薪水，更要命的是，客户的胃口变得越来越大。二十年前，史玉柱在《计算机世界》登一个广告“M6401，历史性的突破”，然后就可以等到订单，这样的成功现在还能复制吗？

当我们从市场竞争的视角去看问题的时候，容易的事情就变得不容易了。不过，很多开发人员还没有学会市场思维，还是保持着学校里的学生思维。在此举几个场景为例，这些场景在我为不同团队提供服务时发生过很多次，令我印象深刻。

在给某单位做一个项目时，开发人员A自作主张加进去一些用例。我认为这些用例和客户的愿景关系不大，可以去掉。A反问道：如果做一个通用的产品在市场上卖呢？

“如果”——开发人员很喜欢用这个学生味十足的词。是否做通用产品，这可是一个重大的商业决策，开发人员却认为将这个系统变成通用产品拿到市场上卖（目标客户变了）是一件轻而易举的事情。事实上，这涉及到整个愿景的转变，甚至公司战略的转变，而且需求受影响的可能不只是当前这个系统。市场是残酷的，谁吃肉谁喝西北风，可不能随便“如果”。少说一些“如果”，多做一些调研吧！看看客户的老大什么意思，自家老总什么意思，市场的战局如何，尽量向最佳答案靠拢。

开发人员B在写某信贷风险系统的愿景时写道：本系统的目标是，银行风险部能够对贷款做风险评估。我问道：难道银行以前不能做风险评估吗？B认真地回答：不能啊，有我们的系统才行！

很多时候我们把自己开发的系统（噢，对，现在流行叫××平台了）想得太牛了，以为没有我们的系统，业务组织就玩不转了。其实，我们开发的系统只是组织里面的小零件，和组织厕所里的马桶没有本质区别。组织里面还有很多系统，其中最值钱的是千百年来一直在使用、现在依然是最复杂的系统——人肉系统，它由“父母公司”开发、“老师公司”不断升级、公司以每月每人几千上万的租金租用。所以，有时为了抵消开发人员这种“致命的自负”，我会故意将“系统”称为“马桶”——你做这个马桶是干什么的？

我和开发人员C聊天。我问：你最近做什么项目？C回答：我在做一个Java项目。

对吗？对的！这个项目对于开发人员C来说确实就是一个“Java项目”，因为他不关心项目的核心领域是医院、物流还是保险，他只关心这个项目能不能提升他的Java技能、对以后的职业生涯有无帮助，所以他把这个项目叫做“Java项目”十分正确。可惜，这是从开发人员的角度看问题，而没有从客户的角度看问题。并不只是刚参加工作的Java程序员会这样回答，有一次，我问一位有将近十年开发工作经验的架构师最近做什么项目，架构师回答：在做一个数据仓库项目。继续聊下去，我才知道其实他做的是某通信公司的客户关系管理系统，里面用到了数据仓库，而数据仓库的知识恰好是他比较缺乏而且感兴趣学习的，所以他干脆把这个项目称为“数据仓库项目”了！

开发人员D喜欢钻研“底层”，明明分配给他的工作是编写一段计费的C#代码，他偏偏要花时间深入研究到编译器、操作系统甚至硬件，而且确实也搞清楚了一些门道。虽然工作是耽搁了，但D获得了“勤奋好钻研”的名声。

其实软件开发还有另一个更值得钻研的“底层”：怎样才能使这段代码更容易维护和扩展？这段代码达到的功能和性能对涉众意味着什么？……过分热衷于钻研“底层”，我认为这样的行为更像是偷懒而不是勤奋，毕竟比起离开电脑去搞清楚质管部和生产部之间有什么利益上的冲突，研究MSIL的语法要容易得多、愉快得多。我们不要忘记，能带来利润的是另一个更深不可测的“底层”——藏在涉众心底里的各种希望和担心。

两个底层

和“底层”一样带着光环的是“技术”一词，有趣的是，不少开发人员说到“技术”的时候，含义就是“我懂得或感兴趣的那点东西”，不懂且不感兴趣的就称为“业务”。例如，开发部的程序员认为“Java编码是技术，产品部那帮需求人员做的是业务”；产品部的需求人员则认为“我做的是技术，客户那帮报关员做的才是业务”；报关员也会说“Kao！我做的当然是技术，我薪水比你还高呢”。所以，我经常用“核心域”、“非核心域”来代替“业务”、“技术”。

计算机科学不是软件工程

造成以上问题的根源，我认为部分原因来自开发人员对计算机科学和软件工程的区别认识不清。软件工程和计算机科学的关键区别在于人。软件是为人开发的，所以我们要做需求；软件是由人开发的，所以我们要做设计。考虑到人的因素，软件工程更接近于经济学，而非计算机科学。“程序员”这个职业，软件工程的成分要比计算机科学的成分大。

现在的大学计算机教育，基本还是以教授计算机科学为主，所教的软件工程仅是聊胜于无。这本来也没什么问题，毕竟象牙塔里的教授要教出好的软件工程也不容易，开发人员还是要在业界历练学习。不过，因为软件工程看起来没有计算机科学那么“深奥”，开发人员常会误认为某人只要对计算机科学的某个领域有一定研究，他对软件工程所发表的见解也一定是有道理的！这时问题就大了。

事实上，以我的所见所闻，即使是拿到了名校计算机专业的硕士、博士学位，又在著名IT公司的研究院做研究多年，一张口仍然是“软件工程盲”的人士，并不鲜见。上海的张恂先生2002年曾经和我一起写作《驳UML三大“硬伤”论》，这些年，张先生一直高举软件工程大旗，多次批驳过类似的现象。

同样作为一名软件工程的研究者，我没有轻视计算机科学研究的意思，只是稍作提醒其中的区别，双方的研究者应该互相尊重。

因篇幅所限，先谈到这里。后面我将从执行者和用例开始，谈谈里面的市场思维——“小人圈圈不简单”。

作者简介：

潘加宇，UMLChina首席专家。1999年创建UMLChina，潜心研究需求和设计技能。2002年开始对外提供UML需求和设计的技术指导和训练服务

Via：《程序员》