所以事实上架构角色与项目管理角色都在关注记事本的规模问题，但仍然存在着一些不同。例如，如果相较于复杂的jEdit、Editplus,或者便捷一些的Notepad++、Win32pad等来说，有人提出了类似“设置字体颜色与背景颜色”这样的特性时，架构角色可能会首先考虑以下因素。

(1)记事本作为操作系统的默认组件，其外观表现和交互特性应当是由系统的全局设置来控制的。对于前者，例如桌面主题导致的记事本前景与背景变化；对于后者，例如系统默认打印设备的设置，或者输入法设置。

(2)如果操作系统的默认设置不能影响到记事本，则系统的其他默认组件也会存在类似的问题或需求，这意味着整体实施的复杂度会增加。

(3)类似于jEdit、EditPlus等产品的用户只是操作系统用户群体的一个较小子集，其需求不具有代表性。

(4)以记事本通常处理的文本长度来说，是不需要用颜色来区分文本的不同部分的。

对于项目管理角色来说，他否决这项需求的理由会更简单直接：(1)在当前的记事本版本中，未定义该项特性；(2)该项特性与原始的设定“文本处理工具”没有必然关系，可以延后决定；(3)该项特性在来自产品、市场等各方的报告中有明显分歧，存在实施风险；(4)在项目实施阶段，增加该特性对项目过程控制存在不确定的影响。yipindushu.com

然而与上述两类思考不同，技术实现角色将更多地关注实现的细节问题。其中一类问题是与项目经理共同关注的，通常与项目背景以及实施环境有关系。例如：(1)可能的代码量与要求的代码质量；(2)后续维护人员的水平以及因此所需要的注释详细程度；(3)开发环境与测试环境的部署以及性能。

当然，类似于在何种团队中工作，以及开发部门中是否可以玩桌游等，也是技术实现角色经常关注的问题。不过这类问题的特点是：与具体项目并没有关系，因此大多数情况下会由公司的技术部门或整体组织来平衡①。

在具体的项目中，开发人员通常更关注的是另一类更加细节的专业问题，例如：(1)产品性能的具体要求，例如运行在何种设备上，以及定量的稳定性要求如何；(2)采用的语言、框架、程序库，其技术复杂度如何，以及资料是否翔实等；(3)待处理的标准文本格式规范，例如UTF-8编码以及BOM头规格；(4)需测试操作系统初始环境中所有类型的文本，包括.ini、.xml和.reg等；(5)该产品应由多行(ES_MULTILINE)的Edit来实现。

①不过对于一个时间跨度很大，或者会持续多个阶段的项目来说，这些问题可能就落到了项目经理的头上，因为他也担负着团队建设的责任。

这些问题的部分或全部也会对项目的规模构成影响，从而改变项目原始目标的设定。例如说，如果记事本不是由标准的Edit来实现，而是使用RichEdit来实现，那么它就具有了与写字板①相同的规模与特性。所以架构师同时也需要站在技术实现的角度上，考虑技术的选型问题，因为只有架构师知道“系统的其他部分还存在一个使用了RichEdit组件的写字板产品”,并且又具有控制记事本向写字板演化的职责。

【我们看到：】

□架构角色不单单关注记事本自身的规模，还关注其外在系统的规模，以及二者的关系，例如他关注记事本与写字板之间同质问题，并设定原则来辨识它们：□技术实现角色则关注实现技术是否便捷、有效，以及是否能把控实现过程，他的这些需求来自于对项目产出的责任，以及对自身实现能力的衡量；□而对于项目管理角色来说，一旦产品规格书上有确定描述，他就不需要关注“该项目是不是把记事本做成了写字板”。

当然，架构师就要为类似的规模失控问题挨板子——这也可能是产品架构师的问题。不过要到本书的最后一部分，我们才会来讨论架构角色的分类问题。