下载掌阅APP，畅读海量书库
立即打开
数据保护工作会影响本组织的各个方面。你需要听取各种人员的意见并征得他们的同意，其中有技术人员，也有非技术人员。明白这一点之后，你就应该召集几个团队，建立各种评审委员会（review board）。这些委员会负责针对你要构建的服务，提出设计与运作方面的要求，并给你的方案提供反馈意见。
与这些团队商议时，你需要拿出一些文档，让大家了解与这次会谈的议程有关的信息，这些文档将来还可以作为参考资料使用。下面给出几条你在构建这种文档时所应遵循的标准。
下面是一份模板，适用于我们在这个过程中所要创建的各种文档。无论具体创建的是何种文档，都应该遵循这样一套基本的结构。
文档开头的目标阐述
尽可能简洁地阐述这份文档的目标，篇幅控制在一段或两段之内。
执行纲要
如果创建这份文档是为了提供设计方案，或是为了对测试结果发表结论，那么一定要在此部分给拥有审批权的人提供足够的信息。大家都知道，这些人不会把整篇文档都看完。
修订历史
所有的文档都应该及时更新，也就是说，它必须跟生活一样，随时应对变化。如果项目正处在某个比较活跃的阶段，那么每周（甚至每天）都有可能要做出好几次修改。你要准备一张小表格，在里面列出文档的修订号、修订日期、修订人以及一组描述修订要点的条目。这张表格可以帮助你了解正在看的是哪个版本，并且让你知道文档是经过了怎样的修订才变成现在这样的。
签名页
数据保护计划对你的组织至关重要，因此在开发这样一个项目时，必须明确责任。你要确保每一位关键的审批人与主题专家（Subject Matter Expert, SME）都愿意遵循该计划，并在文档的最终版（也就是确定版）上签名。签了名，还意味着文档的内容至此已经完备（当然，这指的是在它下次接受修改之前是完备的）。
工作策略/工作范围
有时，阐明工作策略或工作范围，也有助于把该文档所要强调的某些主题给界定清楚。
词汇表（术语表）
用来总结并阐明文档里使用的术语，这对参与审批的非主题专家来说尤其有帮助。
附录
如果存在一些不需要放在正文里的材料与辅助信息，那么可以将其作为附录，写在正文之后。
写到这里的时候，笔者想起本书中的所有内容都会由大约20名技术编辑来评审。有这么多人能给这个写作项目（也就是本书）提供意见，真的很棒。建立一套良好的评审体制，能够帮助你聚合不同的观点，让你不会忽略掉某个与该系统的部件或需求有重要关系的意见。下面这套流程要反复执行好多轮。该流程分为这样几个环节：
需求评审
你应该安排各个部门的成员都来参与需求评审这一环节，而且还要有一名高管，以确保整个组织都能对这个项目感到满意。CIO（Chief Information Officer，首席信息官）是很合适的人选，因为这样的人既了解组织所使用的技术，又知道组织会以何种策略来使用这些技术。
设计评审
你应该从那些与特定技术有关的团队里选择成员来组成设计评审委员会（Design Review Board, DRB），这些人能够提供自己的见解，让你知道某项技术应该如何在本组织中实现。[某些组织会把这个委员会叫作架构评审委员会（Architecture Review Board, ARB）其实是同一个意思。]如果组织比较大，那么一定要把系统工程、数据库工程、存储与网络工程以及网络安全方面的人员都召集进来。他们能够对基础设施的设计方案做出评审，并针对如何改进新服务的集成与运作而提出建议。在设计评审这个大的环节里面，应该安排一个叫作初步设计评审（Preliminary Design Review, PDR）的小环节。你应该先让设计方案经历这个小环节，以确保该方案已经遵守了相关的要求。另外你还应该安排一个叫作生产准备状态评审（Production Readiness Review, PRR）的小环节，这个小环节是在设计方案已全部做好并经过最终测试之后执行的，它的目标是让大家都能够最后再看一遍，以确认没有漏掉什么东西。
操作评审
你应该把在生产环境（也就是正式的工作环境）中运行该服务的运营团队召集在一起，让他们参与这一环节，以充分了解自己所要执行的是什么样的操作。完成操作评审（operation review，也叫运营评审）后，应该形成一份使用说明，以充当该系统的用户手册。
变更评审
最后，应该有一个变更咨询委员会（Change Advisory Board, CAB），该委员会应该是技术组织里的一部分，用来在实施最终方案之前，把方案里有可能对本组织的日常运营造成影响的那些变化之处审核一遍。CAB的职责是检查方案里提到的变化对本组织是否合适，以防其破坏该组织的整体工作。做完操作评审之后，应该先对方案做变更评审，然后再正式上线。
项目管理
要使用稳健的项目管理手段来推进数据保护计划，这可以帮助你协调工作，给相关人员提供资源并安排好各项任务的时间。这还会让你总是能够按时拿出应该交付的东西，并确保这个计划顺利施行。
一开始就要把项目管理方面的人召集进来。因为对于大多数技术组织来说，这些人知道组织里面发生的情况，并且能够对此予以控制。