——托马斯·布朗 《医生的宗 教》I.19
1
“三”据说是玄学家们偏爱的数字。对于这种怪癖或狂热,我只能自认免疫力不足:在“三段论、三权分立、三位一体...”这个似乎无休止的列表上,我甚至想再加上一点儿自己的贡献——在我看来,通常称为“软件工程”的学科至少包括三个重要的组成部分:产品设计、系统构架设计和项目控制,而相应地,软件开发队伍中也有三个重要角色:产品经理、系统架构师和项目经理。
《人月神话》一书的读者都能理解“概念完整性”对于软件系统的重要性。概念完整性指的是,软件系统作为一个整体,对于使用者体现出的概念上的一致性、清晰度和简洁度。按照该书作者Brooks的看法,概念完整性是设计软件时需要考虑的首要因素,而为了确保概念完整性,应该要求:
1) 区分系统设计和系统实现工作;
2) 系统设计的工作由一个人或不多的几个达成共识的人完成。
这里谈的“系统设计”,基本上对应于我说的“产品设计”,即,确定软件系统的功能、性能指标、交互模式等方面的需求。质言之,产品设计者决定“做什么”的问题,而把“怎么做”的问题留给实现人员(implementers)来完成。
这样就引入了第一组工作划分。这里的重点是,产品设计应该由专人负责,而不是交给“程序员”代庖。相反的实践,即让具体开发者确定产品设计细节的做法,在国内软件业似乎仍很常见,但正如《人月神话》所言,这是一种非常危险的尝试。首先,如果产品的各个设计细节由多个开发者按各自的设想确定,那么概念完整性就几乎一定会被破坏。其次,具体开发者往往更注重系统实现中的技术因素,而对最终使用者的需求、动机和感受都缺乏体认,因而单纯出自程序员的产品设计,总是会偏离使用者对业务和易用性的实际需要,很难获得用户的欣赏——有一个略显过分的比喻甚至说,让程序员做产品设计,无异于让精神病患者们自己运营疯人院。
而谈到产品设计或系统需求确定,另一种流行的误解是,这应该是客户的任务:“需求调研人”至多需要记录下客户的所有需求,就能形成完美的需求规格设计书。天知道(至少,任何做过委托开发的人都知道)这种论调和国内客户的实际情况之间的差距。不止一次,我拿到的全部客户需求就是:开发一套电子商务系统。设计产品或确定系统需求不仅需要行业、领域经验(这是“客户”的优势所在),更需要大量同类系统的使用经验(甚至开发经验)以及较强的抽象能力、表达能力等等。而目前很多客户,由于接触同类系统有限,自身业务流程也远未标准化,若指望他们提出清晰、明确的需求,好比是让一个只会喊“饿”的小孩儿进饭馆点菜。开发团队必须委派专人,通过耐心诱导和反复尝试才能获知他们的实际需要。
负责产品设计的“专人”通常称为“产品经理”。我心目中理想的产品经理,应同时具备较高的商业素质和较强的技术背景。
具体地说,首先,一个优秀的产品经理要有深厚的领域经验,也就是说,对该软件系统要应用到的业务领域非常之熟悉。比如,开发房地产销售软件的产品经理,应该对房地产公司的标准销售流程了如指掌,甚至比大多数销售人员还要清楚。如果开发的是通用产品,他/她还具备对市场、潜在客户需求的深刻洞察力。
其次,他/她应该善于完成从使用者视角到开发者视角的转化,善于将繁复的实际业务抽象为概念模型和人机交互操作。
再次,他/她在技术方面也应该具备足够的知识,能对特定需求的可行性做出初步的衡量,能够做出方案选型的抉择。功能需求往往符合Pareto's Principle(20-80原则),怎样设计一个开发代价最小,而覆盖需求最多的功能集,怎样确定各个功能在实现时的优先度,是产品经理必须懂得的艺术。另外产品经理应该知道采用特定开发平台、特定工具产品的优势和代价,并从商业角度出发做出选择。
最后,他/她还应该能够确定系统在人机交互方面的主要特征。程序员设计的产品为世人讥评,很大程度上要归咎于糟糕的交互(UI)设计。产品经理应该能够从商业角度出发,了解特定客户/潜在客户群在人机交互方面的需求,并能衡量特定的人机交互模式的实现难度——在很多场合中,某个微小操作模式的变化会导致整个系统实现构架的变化,因此,尽早确定UI的主要特征,并要求它们在整个系统内保持一致,对于概念完整性和系统技术构架都是至关重要的。
对一次软件开发来说,产品设计是源头,是核心。因而产品经理的工作质量也直接关系到开发的成败。记得一位业内资深人士曾说,合格的产品经理需要一份MBA学历,再加上原先若干年的技术开发经验。综合考虑以上素质,我相信他提出了相当中肯的要求。
如上所述,产品设计是一个复杂、困难的过程,其中充斥着争论和妥协、权衡和决断,并且,根据软件处理的实际业务不同,这个过程的内涵也千差万别。让我们暂时告别这段恶魔般的旅程,轻快地考察另一个较为清晰的领域:“系统构架设计”。