作者：naven 2005-5-10
“
软件工程
”
的学科至少包括三个重要的组成部分：产品设计、系统构架设计和项目控制，而相应地，软件开发队伍中也有三个重要角色：产品经理、系统架构师和项目经理。这三个角色直接关系着项目的成功或失败。以下是对这三个角色的分工的具体介绍：（部分摘自《程序员》，作者：刘天北）
《人月神话》一书的读者都能理解“概念完整性”对于软件系统的重要性。概念完整性指的是，软件系统作为一个整体，对于使用者体现出的概念上的一致性、清晰度和简洁度。按照该书作者
Brooks
的看法，概念完整性是设计软件时需要考虑的首要因素，而为了确保概念完整性，应该要求：
1
）区分系统设计和系统实现工作；
2
）系统设计的工作由一个人或不多的几个达成共识的人完成。这里谈的“系统设计”，基本上对应于我说的“产品设计”，即，确定软件系统的功能、性能指标、交互模式等方面的需求。质言之，产品设计者决定“做什么”的问题，而把“怎么做”的问题留给实现人员（
implementers
）来完成。
这样就引入了第一组工作划分。这里的重点是，产品设计应该由专人负责，而不是交给“程序员”代庖。相反的实践，即让具体开发者确定产品设计细节的做法，在国内软件业似乎仍很常见，但正如《人月神话》所言，这是一种非常危险的尝试。首先，如果产品的各个设计细节由多个开发者按各自的设想确定，那么概念完整性就几乎一定会被破坏。其次，具体开发者往往更注重系统实现中的技术因素，而对最终使用者的需求、动机和感受都缺乏体认，因而单纯出自程序员的产品设计，总是会偏离使用者对业务和易用性的实际需要，很难获得用户的欣赏——有一个略显过分的比喻甚至说，让程序员做产品设计，无异于让精神病患者们自己运营疯人院。
而谈到产品设计或系统需求确定，另一种流行的误解是，这应该是客户的任务：“需求调研人”至多需要记录下客户的所有需求，就能形成完美的需求规格设计书。天知道（至少，任何做过委托开发的人都知道）这种论调和国内客户的实际情况之间的差距。不止一次，我拿到的全部客户需求就是：开发一套电子商务系统。句号。设计产品或确定系统需求不仅需要行业、领域经验（这是“客户”的优势所在），更需要大量同类系统的使用经验（甚至开发经验）以及较强的抽象能力、表达能力等等。而目前很多客户，由于接触同类系统有限，自身业务流程也远未标准化，若指望他们提出清晰、明确的需求，好比是让一个只会喊“饿”的小孩儿进饭馆点菜。开发团队必须委派专人，通过耐心诱导和反复尝试才能获知他们的实际需要。
负责产品设计的“专人”通常称为“产品经理”。理想的产品经理，应同时具备较高的商业素质和较强的技术背景。
具体地说，首先，一个优秀的产品经理要有深厚的领域经验，也就是说，对该软件系统要应用到的业务领域非常之熟悉。比如，开发房地产销售软件的产品经理，应该对房地产公司的标准销售流程了如指掌，甚至比大多数销售人员还要清楚。如果开发的是通用产品，他
/
她还具备对市场、潜在客户需求的深刻洞察力。
其次，他
/
她应该善于完成从使用者视角到开发者视角的转化，善于将繁复的实际业务抽象为概念模型和人机交互操作。
再次，他
/
她在技术方面也应该具备足够的知识，能对特定需求的可行性做出初步的衡量，能够做出方案选型的抉择。功能需求往往符合
Pareto's Principle
（
20-80
原则），怎样设计一个开发代价最小，而覆盖需求最多的功能集，怎样确定各个功能在实现时的优先度，是产品经理必须懂得的艺术。另外产品经理应该知道采用特定开发平台、特定工具产品的优势和代价，并从商业角度出发做出选择。
最后，他
/
她还应该能够确定系统在人机交互方面的主要特征。程序员设计的产品为世人讥评，很大程度上要归咎于糟糕的交互（
UI
）设计。产品经理应该能够从商业角度出发，了解特定客户
/
潜在客户群在人机交互方面的需求，并能衡量特定的人机交互模式的实现难度——在很多场合中，某个微小的操作模式的变化会导致整个系统实现构架的变化，因此，尽早确定
UI
的主要特征，并要求它们在整个系统内保持一致，对于概念完整性和系统技术构架都是至关重要的。
对一次软件开发来说，产品设计是源头，是核心。因而产品经理的工作质量也直接关系到开发的成败。记得一位业内资深人士曾说，合格的产品经理需要一份
MBA
学历，再加上原先若干年的技术开发经验。
综合考虑以上素质，我相信他提出了相当中肯的要求。
系统构架，是对已确定的需求的技术实现构架。与产品设计相比，系统构架设计的工作更明确，而目前该领域也已经形成了较为成熟、完善的方法论和一整套易于掌握、传授的知识。相应地，系统架构师是一个不折不扣的技术人员，主要着眼于系统的“技术实现”。他
/
她的责任是最终确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点。因此他
/
她应该是特定的开发平台、语言、工具的大师，对常见应用场景能马上给出最恰当的解决方案，同时要对所属的开发团队有足够的了解，能够评估自己的团队实现特定的功能需求需要的代价。
这里，最容易导致误解的部分是产品经理和系统架构师的区别。我感到现有的不少论述和实践都倾向于将二者混为一谈。但在我看来，如果把开发软件比作摄制电影，产品经理之于系统架构师，就正像编剧之于导演。产品经理虽然要有一定技术背景，但仍应属于“商业人士（
business people
）”，而系统架构师则肯定是一个技术专家。
二者看待问题的立场、角度和出发点完全不同。当然，就像有时电影导演也出任编剧（甚至存在“作家电影”流派），对于特定的开发领域或项目，产品经理和系统架构师这两种角色的重合也可能是无害、甚至有益的（我能想到的一个领域是编程语言的设计），但即使如此，不加区别地对待需求和实现、产品设计和系统构架设计，肯定是危险的。如果你处在一人权充两种角色的情况下，你应该时刻意识到自己目前进行的是哪一种职责，并据此调节视角和思路。
我感到这两种角色的含混还来自人们对“
architect
”这个表达方式的不同用法。
Architect
和
architecture
，这组显然是借自建筑学的隐喻，经常被不加区别地使用在产品设计和技术实现这两个不同的方面。
Brooks
本人在《人月神话》做出的“
architect
”和“
implementer
”区分，基本上对应于我在上面谈到的“产品设计”和“技术实现”，但是由于“技术构架”本身也可以称作
architecture
，所以一般谈到
system architecture
或
system architect
时，人们关注的却主要是技术实现方面。正如
Martin Fowler
所说，人人都想被称为
architect
而不只是
engineer
，所以这里用语的含混可能也体现了不同领域的人们对
architect
这个好词的争夺。
如果继续上面的电影隐喻，那么摄制组中的“制片”职责也就对应于我所说的“项目控制”。显而易见，项目控制工作与上面谈到的产品设计、构架设计都不同，如果说产品设计偏重于“商业”、系统构架设计偏重于“技术”，那么项目控制注重的就是“管理”。它主要关注的是项目本身的进度、质量等方面。软件开发项目需要专人负责这些内容，我愿意称此为“项目经理”。
项目控制
/
管理已经形成了一个专门的学科（
Project Management
），对于软件项目经理，其职责也未脱离该学科的描述，包括项目计划、进度跟踪
/
监控、质量保证、配置
/
发布
/
版本
/
变更管理、人员绩效评估等方面。优秀的项目经理需要的素质，并不仅在于会使用几种软件或是了解若干抽象的方法论原则，更重要的在于从大量项目实践中获得的宝贵经验，以及交流、协调、激励的能力，甚至还应具备某种个性魅力或领袖气质（
charisma
）。通俗地说，也许学校里的学生会主席要比“学习尖子”更适合这样的职位。
由此可见，项目经理和系统架构师在职责上有很大差异。混同这两个角色，往往也会导致低效、无序的开发
。特别是，从性格因素上讲，单纯的技术人员倾向于忽视“人”的因素，而这正是管理活动的一个主要方面。另外，就像战争中的空军掩护（
air cover
）一样，专职的项目经理能够应付开发过程中大量的偶发事件和杂务，对于一个规模稍大的项目（《人月神话》似乎说的是
6
个人以上），这些杂务本身就能占用一个全职工作者的几乎全部时间。
1、
产品经理（
Project Engineer
）：负责产品的设计，包括
UI
、功能和其他产品的方方面面，主要是从用户角度和市场角度规划产品的“模样”。负责“是什么”。
2、
系统架构师（
System Architector
）：负责产品的实现，主要是产品的技术实现的架构，使用什么技术、模块的设计、接口的设计及模块的协作等。负责“怎么做”。
3、
项目经理（
Project Manager
）：负责项目实施的总控，保证各个资源的合理分配，掌控项目的总体进度。
4、
系统设计师（
System Designer
）：负责对系统架构师分配的工作和模块在架构的师设计的范围内进行具体的设计和规划，分离出小的功能，详细到函数，即详细设计。
5、
开发人员（
Programmer
）：负责对系统设计师分配的工作的实现，即编码开发。
6、
测试人员（
Tester
）：这是另一独立的角色，真正的测试人员的工作应该从项目发布
BETA
版时开始各个方面全面的测试和评估。
BETA
版之前的测试工作应该由上面的角色完成。
仍以电影的制作比喻：产品经理相当于编剧，系统架构师相当于导演，项目经理相当于制片，系统设计师相当于灯光、场景等负责人，开发人员相当于具体的演员，而测试人员相当于电影局的审查人员。
一个较大项目的进行，必须要具备这些不同角色各自负责不同工作的人员组成，即使某个人综合了不同角色的工作，工作也应该如此合理分配。各人的职责也不应该混绕交叉，比如：产品经理不应该关注实现的技术，架构师也不应该关注资源的配置（但他要充分理解产品经理的意图），项目经理则不应该干涉产品的设计及实现。另外一种情况，项目经理主要是总控项目的进展，但不应该自行评估整个项目工程的工时。评估项目的工时需要项目经理和产品经理、架构师通盘考虑，综合各方面因素得出，甚至需要系统设计师参与。架构师负责整个项目实现的预计工时的估算，系统设计师估算自己的模块内部的预计工时，而项目经理负责估算其他不定因素的工时（如开会、审批等），把这些综合在一起才能评估出真实的项目工时。任何一个人都不应当去独立评估全部的项目工时，或者评估别人工作的工时。只有这样分工明细且协调配合才能保障项目的成功实施。