|
系统构架，是对已确定的需求的技术实现构架。与产品设计相比，系统构架设计的工作更明确，而目前该领域也已经形成了较为成熟、完善的方法论和一整套易于掌握、传授的知识。相应地，系统架构师是一个不折不扣的技术人员，主要着眼于系统的“技术实现”。他/她的责任是最终确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点。因此他/她应该是特定的开发平台、语言、工具的大师，对常见应用场景能马上给出最恰当的解决方案，同时要对所属的开发团队有足够的了解，能够评估自己的团队实现特定的功能需求需要的代价。
这里，最容易导致误解的部分是产品经理和系统架构师的区别。我感到现有的不少论述和实践都倾向于将二者混为一谈。但在我看来，如果把开发软件比作摄制电影，产品经理之于系统架构师，就正像编剧之于导演。产品经理虽然要有一定技术背景，但仍应属于“商业人士（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
2
3
4
下一页>>
| 
