本篇内容

方案及工作说明书的制定和规范

为项目需求、角色和文化进行规划

3.1 方案

在邀到潜在客户开始－项新项目时也会遇到类似情形，那些感觉良好的欢快时光很快会被“噢，真是扯淡”这样的抱怨取代。此时就应该提前写好方案（proposals）。不要立即着手工作，花时间定义你和新客户的业务关系及交往规则。

在很多情况下，承包商和他们的客户在关系开始时相信他们的想法已经达成了共识，而事实上含糊不清随时到来。你不可能预见所有的意外，一份详细的书面协议是你最好的防御，也是你确保你以后不在法庭上辩论你们关系的最佳方法。你在书面协议中将你和客户之间关系的条款和数据定义得越清楚，你就越不可能和缔约方在以后发生争议。——Jean Marc Favreatu

新项目和新人总是令人振奋。经常在一种不要 ”终止交易” 的期望下导致抛出一份和稀泥方案，但在任何关系中，“蜜月”感觉可能最终走向负面。承诺可以被关系的任何一方先打破。撰写良好的方案会给客户一种稳定和保障感，可以缓和可能的担心。方案让你可以定义条款，以在情况发生变化时保护双方。如果客户没有及时给你提供所需资源，你的进度会延期；你需要使他们清楚，他们对项目成功所应承担的义务。如果客户损失投资并终止项目，并且你并没有一份协议或其他形式的合同在手，那么你可能面临无法获得已完成工作的报酬的风险。

3.2 创建方案

越快确认和签署方案，你就可越快开始工作，最重要的是，开始获取工作报酬。

良好方案的核心要素如下。

标题页
修订历史
项目概览
项目方法
附加成本和费用
项目报价
工作范围
假定
交付件
所有权及权益
付款计划
确认和签收

3.2.1 标题页

标题页是介绍文档的简单页。标题页很有趣：可以从风格和信息的角度来考虑，创建方式很多。

客户公司名称
客户公司标志（如果获许使用）
项目标题
文档类型（方案）
提交日期
自己的（公司）名称
方案作者
费用
提案版本
保密条款

你的第一份方案，要包括除了客户公司标志、费用和（可能的）项目参考号之外的所有其他元素。

3.2.2 修订历史

修订历史是方案的一部分，用于标识从原始版开始，修改了多少次。通常，最好包括版本号、日期、修订者以及版本注释，比如修订了什么，让阅读者可以了解修订情况

修订历史表示例

版本	章节	描述	编辑	日期
1.0		原始文档	REU	2018.5.3
1.1	设想	更新以反映软件需求	REU	2018.5.5

有时，客户会修田方案并要求你做出进一步的改进。如果你选择跟进客户并进行这些修改，你应当借此机会将文档从版本1.x改为2.0。
从本质上讲，当客户认可方案并且双方都同意上面的条款时，你就可以开始工作了。当请求进行额外修改时，你需要仔细审查。这可以保证费用依然合理，并且双方都对修订有一个清晰的理解，以及项目应从哪个阶段重新开始（如果有必要）。你应当解释清楚，为何此次修订在修订历史中构成了一个全新版本。

3.2.3 项目概览

概览部分是你用自己语言对工作项目进行的描述。此描述将给客户提供你对产品前景的想法，并提示他们在方案的其他部分都会读到些什么。

如

［公司名称］正在尝试创建一个新的在线网站。此网站可以让［公司名称］客户在线搜索和购买产品， 以及获得其他可以从公司获取的服务和回应。Web网站的目标

概述你对项目的建议方案和方法是不错的主意

1	方案将详述［你公司名称］对于设计和开发［客户公司名称］网站的建议和方法。在预期完成日期［完成日期］前，将会......

3.2.4 项目方法

项目方法将依赖于你所承担项目的类型。这是向客户展示如何计划和开展项目的好机会。需在其中定义参与规则并设定未来工作预期。

PURITE Process TM：以给（潜在）客户进行展示，在许多方案中都可以看到其应用。整个过程的定义通常如下：

P-Prepare（准备）。每个方案都需投入一部分时间来理解你的行业、竞争对手以及他们的经营方式，以在需求搜集开始前尽可能多地了解情况。
U-Understand（理解）。我们通过与你们的领域专家和/或用户紧密合作来定义需求，以更好地完成项目。
A-Render（实施）。在实施阶段我们建立并开发项目/产品的各个部分。根据我们的经验，任何开发过程都需要大量埋头、专注的工作，同时还要求和团队即时、开放的沟通。它还要求我们…
I-Iterate（迭代）。迭代过程在项目的整个生命周期中不断重复。我们尽可能快速地将项目投入应用，这通常要求在开发周期中进行多次迭代。这需要直接及时地投入你和你的资源。最终结果就是你定义并帮助创建的那个产品。
T-Test（测试）。我们在实施阶段的整个过程中都进行测试，并且，我们还额外要求测试团队和对应的用户群／受众执行基于目标的测试。通过这轮额外测试，确保遗留下来的问题尽可能的少，并提交一个经历过多层次严格评估的项目。
E-Enable（启用）。在成功完成前述5个阶段并得到你的签字同意后，我们将启动方案并将其上线。

PURITE过程到此并未结束。在项目完成后，我们定期和客户沟通。我们将继续评估你的满意度，了解不断变化的目标和项目改进，并协助你为未来项目的开展确定最佳方法。

你的项目既可以定义得如上面那般详细也可以像下面这样简洁：
规划、定义、开发、扩展

规划整体策略。
定义详细项目需求。
开发、测试、改进和发布产品。
根据项目开发、测试和发布后获得的改进建议来扩展项目。

3.2.5 工作范围

工作范围的部分用于描述项目的工作分配。即描述项目的哪些部分由你负责，哪些部分由客户负责。
这一块的意图在于分清谁负责项目中的哪一部分、项目中都包含哪些内容以及估计价格。
下面是关于工作范围的一个简单示例。

1
2
3

我们受［客户公司名称 1 委托， 提供创建［项目名称］的服务。
［你公司的名称】将专注于［客户公司名称］网站的［用户体验设计事务 1 。［客户公司名称］将根据项目计划提供［项目名称］各方面的详细解答。
［客户公司名称］将提供任何项目所必需的资源， 包括字体、 颜色方案、 品牌标准等。

3.2.6 假定

方案的假定（ Assumptions）部分是清楚陈述的好地方，不要留下争议空间，为了保证成功，客户需要提供些什么。即，这里都是你事先假定好的条件，并传达给客户，你可以访问这些资源，或资源将会分配给你，以保证项目成功。
事实上，被称为假定的此部分其实是期望。称之为假定，其实是为了体现一种礼貌。

下面是如何撰写假定的例子

    假定
    ［客户公司名］必须提供下列条件和资源。如未能及时完善地准备好条件和资源，可能会导致项目的失败或延期。
    需要下列条件和资源。
    可及时访问所有需要的［客户公司名称］员工。
    及时访问［项目］需要的当前状态的资产， 如果可能，包括源文件。
内容，包括但不仅限于列出条目的各种文件、 图像、 音频等。

3.2.7 交付件

交付件（deliverables）是你创建并提交给客户的工作产品。建议你在项目接近完成时，单独提交状态报告，但也可将其加入项目的交付件。

交付件
    ［你公司名称］通过项目提供交付件。针对［客户公司名称 1 ，我们提供下列交付件
    创意简报
    项目的第一步是创意简报（Creative Brief ）。此文档可帮助我们建立关于项目快速 有效的高层次总览。创意简报的目的是为了澄清用户的需求和目标， 并定义出所有与项目有关的特殊资源和约束。

3.2.8 所有权及权益

你将允许你的客户使用你的产品到什么程度，有多种方式定义这些权益，但通常你的成果可划归到下面两类。

受雇工作(work for hire)。
授权工作(licensed work)。

受雇工作（法律界称之为 “雇佣下完成的工作”）项目的版权被认为属于支付报酬的一方，而不属于完成实际工作的一方。这意味着，当受雇完成一项项目工作时，你不会拥有成果的所有权，你所产出的项目相关的每样东西都属于客户。这通常意味着没有后续的 “维护” 工作（以及相应的收益），客户可能决定在项目完成后由自己来维护。当客户要求这样的条款时，不要犹疑；这很常见。当你全职受雇于某公司来完成项目时，这基本是一种标准的雇佣关系。这也是审视定价模式的一个机会——许多项目会提高收费以弥补未来可能的收益损失。

授权型项目让你拥有工作的版权，然后授予对方复制或发布的权利。你可在授权许可协议中写进自己期望的条款。你可以充分利用你作品的版权，你拥有你作品的所有原创版权，并且只给你客户提供受限使用的作品，你可以采用多种方法来授权你的作品，包括作品的无修改、非商业以及其他符合你情况的授权方式。

3.2.9 附加成本和费用

让你的客户知道项目报价是否包含外部资源的费用。
例如，一些项目需要从第3方购买图库图片。你可以从你的费用中出钱购买图片（带有相应的授权），也可以将购买图片的费用单独列出，交由客户支付。你也可能希望让客户了解你提供的服务——这是推广这些服务的好机会。

下面展示了如何处理额外的成本和花费：

额外的成本和花费
    在需要外部资源（如内容、 图片、 字体等）时，将会列出， 并由［客户公司名］来支付。
    此外， ［你公司名称］将以非常低的管理费来提供主机服务－一－包括配置、 基于Web的邮箱一一低至25美元每月，加上起始费用25美元。如果［客户公司名］希 望购买 “维护 ” 包， ［你公司名］将会创建一个双方认可并都可受益的服务包。
    如果你预计到任何旅行以及旅行相关的费用， 包括酒店、 汽车租赁、 日常花费等。你需要详细说明这些费用由谁支付以及如何提供发票。

3.2.10 项目报价

如何达成合适的价格主要靠你自己，但这里有一些小技巧估计一下项目将会花费你多长时间——包括一定数量的改进，估计出一个合理的项目管理时间，这可能占到25%；然后确定一下你希望的小时费率，并计算出总数。有各种计算公式可帮你完成这项工作。比如给项目的各个部分带上难度值，帮助你为客户提供一个成本范围。
多数情况下，主要依靠经验来给项目估价——从时间和材料的角度。你如何确定你的费率呢？通过搜索薪酬调查和外包费率，研究他人如何收费以作为参照。
下面展示了如何对项目报价进行分解。

项目报价
   ［你公司名称｝假定所有的内容由［客户公司名称］提供。如果要求［你公司名称］提供内容方面的服务， 项目估算需要重新计算。
    ［你公司名称］的估算允许需求和费用方面的灵活性。
    估算示例如下
    估算1     
    ［你公司名称］估算［客户公司名称］的［项目 1]，无交互性的内容。。。。。。

3.2.11 付款计划

有种说法是，所有的自由职业者的项目都是在工作开始前付款50%，当项目完成时，再付剩下的50%。
制定付款计划有多种方式，从预先确定提交发票的时间节点到基于里程碑的支付。聪明的方法是在项目中制定定期的带有详细发票的付款计划。此方法应该让客户清楚了解什么已经完成、什么还有待完成。

［你公司名称］典型的支付计划是项目开始前收取项目预算的XX%。
［你公司名称］将会在每月的1日和15日提交发票 ， 付款应该在14日内完成。
一旦项目完成， ［你公司名称］将全部工作成果提交给［客户公司名称］。－旦确认提交的东西满意， ［你公司名称］将返还预付款中的超出部分或［你公司名称］将提交未被预付款支付部分的发票。
注。 如果［项目］暂停已超过15天无进展 ， ［你公司名称］应该为超过预付款的未支付费用开出一份最终发票并附加项目重新开始时的优先取舍权。

尽管这不是必要的，但有一个关于项目如果被暂停段较长时间该如何处理的备忘会非常有帮助。这样的条款可以帮助你确保项目按预定轨道前进，并且给你和你的客户一个讨论点。如果你很长时间不再为他们工作，你希望能够继续前行，可寻找其他工作来填补空白。

3.2.12 确认和签收

保证你有一份方案协议非常重要，但仅有它还不够。协议方案真的并不意味什么，除非你客户公司里合适的人对其进行了确认和签收（sign-offs）。
签收很简单清楚。一旦你创建完协议方案文档，你将其提供给客户确认和签收，证明其是你们两个公司之间的协议。总要准备两份——每方一份——并确保两份都进行签署。

1
2
3

确认
    本协议方案完全由［客户公司名称］确认和同意。这个方案必须由｛客户公司名称］授权代表签上名字和日期以产生效力。此外， 一份引用本协议方案的采购订单也可替代本签字文档（但是， 上面任何预先列出的其他条款都将被认为无效）。
    此协议方案构成双方之间需要遵守的全部协议。此方案合并并取代了此前所有的口头或书面协议、讨论、协商 、承诺、纸面文件和谅解备忘录。这包含但不仅限于包含在任何销售材料、简介、或其他书面材料广告材料中的陈述，并且 是双方完整和排他性的协议。双方确认并同意依据本协议条款执行，并明确拒绝执行协议中没有的表述、陈述和条款。

3.3 工作说明书

工作说明书是对项目目标的高度总结，你应该将其放到2~3页的篇幅中（不包括封面）。工作说明书通常在你开始详细描述需求前写好，尽管主要依赖于你的客户和项目需求，你仍可选择创建一个能最好满足你需要的混合文档。
通常，工作说明书应当尽早形成，以在你的团队和客户利益相关方之间达成共识。工作说明书定义项目的输入和输出，以及假定和限制条件。在此处，客户一般不会要求你提供将要完成工作的大概估计” ，在这里回答这些数据有风险。建议你最好避免无详细定义的特性和承诺。在还没有撰写协议方案和需求文档时，你不可能知道项目将花费多少。这就是说，你必须在这一点上做出判断。如果你的工作项目是一个基本型网站，并且你以前曾成功完成过几个类似的网站或已经为同样的客户工作过，那么你有一些回旋余地。记住，小心带来的差错总是好过项目开始后的尴尬。

工作清单应该是2~3页，至少要包含下列内容。

标题页
修订历史
项目参考号
项目总结
开始日期
结束日期
费率/价格
项目预期
活动和交付件
分项成本和付款时间表
确认和签字

这些项目看起来熟悉吗？你可以通过精简协议方案来形成一份工作清单。
你现在已经了解了如何组织这两种类型的文档，这些文档让你可以识别将要为客户完成的工作。这些文档应该成为客户执行项目的基础，并且给你和你的客户提供一份定义良好的项目前进指令集。

（完）

《UX设计之道》—3.给咨询师和自由职业者的建议