需求与商业模式创新-需求6-涉众分析与硬采样

Book6-涉众分析与硬采样

1. 什么是涉众

1.1. 获取的源头

1. 人脑外知识：科学规律
2. 人脑内知识
   1. 困难，有很多问题
      1. 如何寻找合适的人？
      2. 如何有效的与他们进行交流？

1.2. 涉众

1. 所有能够影响软件系统的实现(系统决策者、开发者、利益所在者)或者会被实现后的软件系统所影响的(已有产品更新、全新产品开发)关键个人和团体(stakeholder)。

2. 涉众分析概述

2.1. 企业信息系统的涉众：业务驱动

1. 涉众分析围绕一个组织的各个部门内的员工所负责的业务展开：所有的描述和胜败条件都和业务直接相关
2. 此类涉众分析的难度随着组织机构的0增长而增加

2.2. 涉众分析工作的差异性—视所开发系统的情况而定

信息系统的四种类型

1. 小型系统(Small System)
   1. 小型系统是指那些能够支持组织的部分工作，但又不会影响整个组织基础工作的信息系统，比如企业人事管理。
   2. 关注于某个特定问题
   3. 功能较为固定，界限较为清晰
   4. 涉众有限且明显，默认涉众处于就绪态，不需要专门进行涉众分析。
2. 组织级系统(Organization-Wide System)
   1. 其功能能够影响整个组织基础工作的系统，它的功能在质量上和小型系统有着明显的差异。
   2. 它可能会影响用户群体之外的组织内其他群体，甚至改变组织现存的权力结构
   3. 用户不再有限和明显，而且用户之外的其他群体尤其不明显
   4. 发现直接和间接群体，防止抵制，尤其要发现那些不直接与系统互动，但会简介影响系统或被系统影响的群体。
   5. 分析组织内各类人群的互动关系
3. 战略信息系统(Strategic Information System)
   1. 作为组织战略决策而得以开发的系统
   2. 无法根据现有的业务和技术状况来确定系统将来的应用效果
   3. 系统的影响范围也难以确定，
   4. 涉众数量更多而且更加难以确定
   5. 在业务环境内分析各种可能的机遇和风险，并据此发现可能的涉众，防止抵制
   6. 分析组织内各类人群的互动关系，各种风险/机遇对既有互动关系的影响
4. 组织间系统(Inter-Organizational Systems)
   1. 通过系统自身的实施建立或增强组织之间的合作关系
   2. 系统的很多决定不是单个组织所能控制的
   3. 在主动参与和抵制系统的问题上有着更多的困难
   4. 涉众比组织内系统的涉众更加难以寻找和选择
   5. 考虑组织之间的合作关系和利益分配方案，在组织的大框架下进行涉众的寻找和选择
   6. 分析组织间的互动关系，分析关系到组织间互动的各类人群在组织内的互动关系

2.3. 互联网产品的涉众：人性驱动，但也有围绕业务的利益冲突

1. 补充：大众型产品
   1. 例如搜索引擎、电子商务、移动互联网应用等等
   2. 分析产品定位人群(用户绘像)
   3. 产品功能在用户社会关系网中的关联作用，能否帮助解决生活中的问题
   4. 分析用户与社会关系的互动(场景)
2. 互联网产品也需要展开基于业务的涉众分析
   1. 平台商业模式中如何补贴多个客户群体的收益流
   2. 某款产品的新功能是否会冲击同一个公司的其它产品

2.4. 涉众分析的过程

2.5. 涉众分析的过程

1. Suzanne Robertson：涉众分析与前景与范围的定义是交织进行的，互为依赖

2. 涉众识别:寻找软件系统的涉众类别。
3. 涉众描述:
   1. 描述不同涉众类别的简单特征，包括个人特征和工作特征。
   2. 描述不同涉众类别的复杂特征，包括关注点和兴趣取向，重要性和影响力，输赢条件和受影响程度。
4. 涉众评估:
   1. 为涉众类别划分优先级。
   2. 评估不同涉众类别的风险，化解风险。
   3. 分析涉众冲突,实现共赢。
5. 涉众代表选择:从每种涉众类别中选择代表。
6. 制定涉众代表参与需求开发乃至软件系统的参与策略。

3. 涉众识别

3.1. 发现所有的关键涉众类别

3.1.1. 发现所有涉众类别

1. 涉众类别需要细分，发现所有类别：每一类涉众的所有成员都能够一致、稳定的从相同立场、相同视角来看待相同的软件系统：不同涉众看待系统视角不同
2. 发现比较关键的涉众：需要分析他们各自的赢利条件，以在相互妥协中尽力实现一个共赢的结局，最简单的区分特征是任务。
3. 涉众群体不是固定不变的，需要持续维护：对涉众的理解不是一个完成之后就可以结束的活动，而是应该在完成之后继续保持适当的关注

3.1.2. 过滤非关键涉众的类别：判定方法涉众互动

1. 如果互动及其关注点属于项目的目标与范围，并且其影响关乎软件系统成败和实现，那么涉众就属于关键涉众
2. 过滤标准：分析一个涉众类别的任务或他们与外界的交互活动，如果这些属于项目范围，服务于系统目标(业务需求)的满足，则是。
3. 例如,在一个社会服务领域救护车调度系统的开发中建立的初始涉众类别及其交互如图6-3所示。因为“救护车分配”“事件描述”和“事件警告”都是系统设想的重要业务需求，所以紧急事件操作员、救护车工作队、医院就都属于关键涉众。系统没有“让请求帮助更便利”的目标，所以病人和警察就是非关键的涉众,可以过滤掉。

3.1.3. 维护涉众类别

1. 软件系统的涉众全体不是固定不变的。
2. 涉众可能发生兴趣和关注点转移，甚至产生冲突。

3.2. 涉众识别方法

1. 简单方法：先膨胀后收缩(Expand $\Rightarrow$ Shrink)
2. 经验方法：检查列表(Checklist)
3. 经典方法：涉众网络

3.2.1. 先膨胀后收缩

1. 膨胀：在该阶段，需求工程师在收集到背景资料后，凭借自己的经验，尽可能多地列出涉众类别，越多越好。
2. 收缩：在该阶段，需求工程师判断是否有两类或多类涉众的立场是一样的，将一样的多个类别进行合并。
3. 简单易用：如果涉众群体比较复杂，可能会出现遗漏。

3.2.2. 检查列表：经典列表

1. 用户: 最终使用和操作产品的人，关注软件功能，用户都是主要的信息来源，只要用户群体能够确定，就应该受到重视。
2. 客户: 为软件系统的开发付费的人：关注经济上的成本、收益，对系统运行环境、技术限制和法律法规约束等都有自己的要求，可作为用户替代源。
   1. 定制软件开发：用户中的领导或代表
   2. 委托软件开发：因待开发的软件系统而和用户存在某种联系，但它们本身不是软件系统的用户。
3. 开发者: 负责实现软件系统的人：关注技术上的成本和收益，关注特殊的技术处理技术。
4. 管理者：参与软件系统开发事务管理的人，关注系统的开发进程
   1. 投资方管理者：关心整个软件系统的开发进程，视时间为第一要素。
   2. 执行负责人：投资方在项目管理中的代表。
   3. 项目管理者：开发方负责管理项目日常工作。
5. 领域专家: 在问题域中具有丰富知识的专家，关注软件中的知识，更具有概括性和综合性，不局限于自己的视角。
6. 政府力量：法律法规、长远规划、政策意向等：起约束和指导作用
7. 市场力量：组织中的市场部门人员：关注用户的想法，也可以是重要的用户替代源。
8. 维护人员：系统的非功能属性，例如质量，关心易维护性。

3.2.2.1. 优点

清晰、明确、易于使用，相对较为全面、系统

3.2.2.2. 缺点

有些类别太粗，尤其是用户作为一个类别是远远不够的

3.2.3. 涉众网络

1. 适用于非常复杂情况下的涉众识别，并且能够保证识别结果正确性和完整性。
2. 一般2-3次就足够了。

3.2.3.1. 基本思路

1. 所有涉众群体的互动可以形成一个网络，每类涉众都是一个网络节点，如果两个类别间存在互动就存在一条边。
2. 涉众网络是一个连通图。
3. 从涉众网络的任一点出发进行遍历，就可以找到所有的节点一所有的涉 众类别。

3.2.3.2. 基本过程

1. 从一些比较容易发现的涉众出发，通常包括客户、管理者和相关的投资者，又称涉众基线。
2. 由初始涉众集体讨论，进行头脑风暴，列出一个涉众类别列表，注意使用能代表特征的名称，以达到涉众细分的目的。
3. 对上一步产生的涉众类别列表进行分析，判断其与软件系统的相关性。进行分析时，要根据各个涉众列表的行为把他们和软件系统联系起来,建立一个交互网络，这个网络包含有涉众与软件系统之间的交互，也包含有涉众类别之间的交互。通过交互网络，可以直观地确定各个涉众类别和软件系统的相关性以及它们对软件系统的关键性。最后，缩减为一个关键涉众类别列表
4. 由上一步的各个关键涉众类别选择代表，集中讨论，列出新的涉众类别列表，如果涉众类别列表趋于稳定，就结束涉众识别过程，否则转向第2步

4. 涉众描述

4.1. 应该描述哪些内容

1. 涉众特征描述应该尽可能包含所有涉众有可能对产品研制成功有贡献的内容，下图是干预模型，用来解释怎样让软件系统的开发与应用获得成功。
2. 组织的成功是指组织能够通过满足自己的要求和完成自己的任务来创造价值。
3. 要求的满足和任务的完成依赖于一系列细节功能的满足和一系列细节活动的完成，也就是说，要求的满足和任务的完成来自于一些基础的决策与行动,这些基础的决策和行动说明组织的本质,引导组织的活动，反映组织的目的。
4. 基础决策和行动的产生要求更进一步的内容:
   1. 将参与者有效地组织起来,让他们有能力执行这些决策与行动。
   2. 在为明确的问题寻找解决方案的过程中发现重要的干预措施，保证基础决策与行动都是能够帮助解决问题的决策与行动。
   3. 围绕干预措施建立赢家联盟，让参与者能够积极主动地执行基础决策与行动。
   4. 给赢家联盟的参与者以权力,让他们帮助实现、监控和评估重要千预，即调动其主人翁精神。

5. L1：根据软件系统的功能前景寻找涉众
6. L2：从涉众对象那里获取需求
7. L3：分析涉众的输赢条件，实施共赢策略
8. L4：了解涉众实现、监控和评估软件系统的能力，分析涉众的力量和影响范围；了解涉众实现、监控和评估软件系统的意愿，即分析涉众的关注点和兴趣取向。
9. L5：了解涉众的个人特征和工作特征，以便在涉众固定的情况下对软件系统的功能进行合理的调整。

4.2. 涉众简单特征描述

1. 关注任务、使用频率，经验

4.3. 涉众深度信息描述

1. 对项目的关注点和兴趣所在，态度是反对还是赞同
2. 对项目的期望，成为项目赢家的条件
3. 可能受到的项目的影响，影响的具体内容及影响程度
4. 可以对项目施加的影响，力量的施加点及其强度

5. 涉众评估

5.1. 优先级评估

1. 涉众并不是完全平等的，有些涉众比其他涉众更为重要
2. 优先考虑涉众的基本特征，尤其是任务特征：不一定出钱多的涉众就重要，可能使用系统更多或更重要功能、使用系统更频繁、规模更大的用户群体具有更高的优先级。

3. 基于涉众扩展特征进行涉众优先级的评估：Power/Interest图
   1. 参与者：系统的实际使用者，对系统成功有较大影响力，对系统也有较大影响力，优先级最高。
   2. 环境设定者：很少使用系统，但是由于政治、经济等因素对系统有比较大的影响，优先级次之，最常见的是政府和管理者。
   3. 被影响者：可能是系统直接使用者，也可能是因为系统出现被剥夺了部分利益的输家，受影响大，能影响少，优先级一般低于环境设定这，但是特殊情况下也可能高于环境设定者。
   4. 观众：不受影响，也不影响，优先级最低，比如环境专家和市场力量。

5.2. 风险评估

5.2.1. 分析态度Power/Attitude图

1. 强反对者是需要重点分析的。
2. 涉众的关注点和兴趣去向也是重要内容，一般环境设定者是项目高风险因素。
3. 对于高风险的涉众类别，要尽可能澄清各个涉众类别的角色和指着，发现项目对他们的依赖和假设条件，分析实际情况与预期不一致时可能出现的风险，并提前化解。

5.2.2. 化解涉众风险策略

1. 一方面提高环境设定者对系统的关注，转化为参与者
2. 一方面消除强反对者的反对原因，变为强支持者
3. 给予被影响者一些发表和实现自身意见的全体，环节忧虑。

5.3. 共赢分析

5.3.1. 发现冲突(建立Stakeholder/Issue关系图)

1. 列出系统的所有涉众类别，明确描述他们的兴趣和对系统的期望
2. 从涉众们的兴趣和期望中发现背后涉及的共同问题(Issue)
3. 建立涉众类别和问题的关联，如果某个涉众类别对一个Issue存在兴趣，那么该涉众类别和这个Issue就存在关联关系
4. 对每一个Stakeholder-Issue关系，标明该关系上面所被寄予的期望

1. 如果某个Stakeholder-Issue关系上所寄予的期望与项目的业务需求无法保持一致，那么它关联的涉众就在该Issue的问题上和项目整体目标存在冲突
   1. 涉众和项目负责人互相调整、折中
   2. 重新评估项目的可行性
2. 如果Stakeholder/Issue关系图中某个Issue所关联的不同关系标识有互相冲突的期望，那么就意味着它所关联的涉众在该Issue上存在需求冲突
   1. 分析各冲突方成为项目赢家的条件
   2. 适当的调整，化解冲突
   3. 分析项目在该Issue上的目标、约束和可选方案，并提供给冲突方进行权衡，促进他们之间协商解决

5.4. 阅文的免费模式能否与订阅模式共赢？

1. Issue：免费带来的更多流量与写手身份转换
2. Stakeholder：
   1. 头部与底部写手、普通读者：可以接受
   2. 腰部写手：影响收入，进一步弱化保障
   3. 核心读者：担忧文章质量下降
3. 能否共赢：免费与订阅在多大程度上共存
   1. 免费创作与订阅写作区分开，但共存
   2. 同时成为免费与订阅写手，或先从免费写手做起
   3. 可能达成共赢的Issue：利用免费阅读模式为平台引流
   4. 较难达成共赢的Issue：平台对IP的强力掌控与作者本身的著作权主张

6. 涉众代表选择

6.1. 代表采样

1. 完整采样: 每种涉众类别都有自己的代表，选择出来的代表要能够完整的代表涉众，尤其不要遗漏关键涉众类别，不可以用某一类代替另一类。
2. 态度积极: 确保涉众愿意且有精力提供帮助，尤其是领域专家。
3. 数量适中
   1. 太少：个人看法倾轧群体共同看法
   2. 太多：达成一致困难
   3. 代表数量的准确数字要视项目的上下文环境来确定，一般6-10
4. 比例恰当：分布的基准是代表们的个人特征，混合以下两种技能。
   1. 计算机技能
   2. 业务技能
5. 如果找不到涉众类别代表，则可以使用用户替代源

6.2. 用户代替源

1. 因为业务关系而和用户频繁接触的人，能够代替他们发表看法
   1. 拥有类似系统经验的系统分析人员
   2. 与用户直接联系的技术支持人员
   3. 服务咨询人员
   4. 内部或外部顾问，通常指领域专家
   5. 用户方管理者
   6. 市场人员
   7. 拥有相关知识的开发源
2. 尽量避免使用

7. 涉众参与策略制定

7.1. 制定涉众参与的基本策略

1. 正确的策略：让代表们在合适的时间参与合适的工作
2. 涉众A是只有开始的时候告知，而涉众I则是要全称参与。

7.2. 敏捷方法-用户参与(User Involvement)

1. 基本思想：建立和用户的直接联系，用户参与软件系统开发的整个过程
   1. 尽早关注用户和用户执行
   2. 按照用户反馈调整
2. 用户参与的影响
   1. 为其设计
   2. 与其设计
   3. 由其设计
3. 反馈设计：最终的软件系统是和用户的活动行为密切相关的

8. 利用目标模型进行涉众分析

8.1. 利用主题依赖模型描述涉众互动

8.1.1. 主体依赖模型ADM(Actor Dependency Model)

1. 目标依赖(goal dependency)：依赖者希望被依赖者满足一个条件，但不会规定怎样满足该条件。
2. 软目标依赖(soft goal dependency)：一种特殊类型的目标依赖，其条件是无法量化描述的。
3. 任务依赖(task dependency)：依赖者希望被依赖者执行特定任务。任务依赖比目标依赖更加具体，因为满足条件可以执行很多任务，被依赖者有自己的选择权。而任务依赖直接为被依赖者规定了任务。
4. 资源依赖(resource dependency)：依赖者希望被依赖者提供资源实体(抽象信息或者实物材料)为自己所用，但不关注提供资源需要被依赖者执行的行为和解决的问题。
5. 每个主题的期望都需要由其他主题来满足，每个主题提供的资源、职责要由其他主题来消费，联合起来就可以充分、完备描述涉众之间的互动，了解涉众的社会互动性。

8.1.2. B站的关键涉众类别

1. 一般Up主与观众：目标是流畅、有趣的中视频观看，任务是为平台带来流量和关注度，占用大量带宽和审核资源，被补贴
2. "二次元"核心Up主与观众：目标是垂直、核心的动漫内容消费，任务是为平台带来收益和核心社区，强力的粘性消费补贴平台其他用户
3. 前者追求流畅视频体验(软目标)、占带宽多(资源)，产品粘性与消费能力较弱(任务)；后者则相反(高粘性游戏运营，主要收入)
   1. 后者在事实上补贴前者，需要注意(A站欢迎回家)
   2. B站策略：大会员+社区+电商 VS 宅向内容与营销

8.1.3. ADM示例二

8.2. 利用目标模型深入评估涉众

1. 目标模型框架I*
2. 将目标模型的Goal分配到Actor
   1. 根据Goal的优先级安排Actor的优先级
   2. 根据Goal的风险确定Actor的风险
3. 根据目标分析深入分析Actor间的互动
   1. 发现Actor之间的冲突
   2. 根据Goal的冲突情况协商解决Actor间冲突
4. 根据目标的优先级安排主体的优先级。
5. 根据目标的风险确定主体的风险。
6. 根据目标分析深人分析主体间的互动:
   1. 根据目标冲突可以发现深层次的主体冲突。
   2. 根据目标的冲突情况协商解决主体间的冲突。

9. 硬数据类型

1. 对实际业务加工和抽象之后的结果，是一种精化过的知识。

9.1. 定量硬数据

1. 数据收集表格
   1. 反映了组织的信息流
   2. 收集正在使用的每张空白表格表格、填写和分发说明
   3. 对比填写好的表格
      1. 表格中是否有从来都不填写的数据项
      2. 应该收到表格的人是否真的收到了
      3. 他们是否按照正常程序使用、存储和丢弃表格
      4. 等等
2. 统计报表
   1. 反映了组织过去的主要业务和业务目标
   2. 统计规则也是一种丰富的知识，统计项分解为细节业务数据的过程往往也就是组织目标分解到具体业务的过程
   3. 根据实际工作填写过的统计报表，就可以发现组织实际的业务执行状况，从中发现组织面临的具体问题

9.2. 定性硬数据

1. 整个组织的描述文档
   1. 组织结构图：帮助发现项目的关键涉众
   2. 门户网站：反映组织的业务开展状况
   3. 业务指导文档：比如工作指南和规章手册：解释业务的详细执行过程，反映业务的具体细节
   4. 业务备忘
      1. 反映业务的实际执行情况
      2. 形成对组织工作过程的清晰理解

9.3. 采样数量

1. $样本大小=p\ast (1-p)\ast (\frac{确定性因子}{可接受的错误}{)}^2$
2. P是差异样本比例，未知的情况下设为0.25

9.4. 采样数量示例

1. 每10张发票中就有1张发票与常规情况不同
2. 希望发票样本中包含所有的情况具有90%的确定性
3. 样本大小为：$SS=0.10\times (1-0.10)\times (\frac{1.645}{0.10}{)}^2=25$

9.5. 采样方式

1. 随机抽样：随机地采样数据
2. 分层抽样：考虑系统的分层，从每一层中随机抽取一个样本

10. 本章小结

1. 涉众是软件项目当中的重要力量
   1. 涉众的合作与参与是项目成功的必要条件
   2. 涉众对产品的接受度和满意度也是成功的一个衡量标准
2. 对于复杂的系统，涉众力量的有效发挥并不是一件容易的任务
   1. 对必要内容的关注和一个完整的过程可以帮助项目利用涉众的力量
   2. 对涉众的分析需要很多的分析方法和技巧
3. 硬数据也是需求获取当中一个非常重要的源头
   1. 不同的硬数据有着不同的贡献
   2. 对硬数据的有效采样是发挥硬数据作用的必要前提

11. 实例分析

1. 在开发过程中，因都是平时工作中接触的业务范围，因此开发时以为满足了功能需要，实现了软件预定的管理和统计功能，那么开发就是成功的
2. 其结果是，在软件测试阶段，各等级的用户都反映出相对一致的意见。其中，反映最多的就是系统维护和操作太复杂，甚至经常报告说服务器和软件不稳定，不匹配。经认真调研，发现问题虽然有一点，但绝非基层报告的那么严重，软件应该是可以满足日常工作的。
3. 结果：2003年，我处信息化还没有普及，尤其是基层领导，个别甚至是电脑盲。而我们的软件，为提高使用效率，设置了大量的快捷键操作方式，这让个别领导感觉难以接受。后来，我们对软件的操作界面和菜单进行了优化和简化，而用单选框选择代替了审批。通过一系列的修改和完善，反对该软件的人渐渐少了。
4. 在系统上线后，首先表达不满的是申请接水及变更业务的用户。我们发现，由于柜面人员需要向系统中录入申请信息并且扫描、上传部分重要文件，这延长了柜面办理业务的时间，造成用户业务申请的等待时间增长。
5. 我们在涉众识别的时候，遗漏那些不使用系统(非参与者)但是被影响的人，——在本项目中就是直接到柜面申请接水及变更业务的人。然而接水及变更业务的申请人是自来水公司的客户，非常重要。
6. 系统上线后，一线用户普遍向我们反映系统操作的风格不符合他们的习惯，使用起来不方便，造成他们操作效率很低。
7. 经过了解分析，我们发现：在对外服务平台项目之前，自来水公司内部开发人员开发了一套简单的对外服务管理系统。虽然该系统非常简单，功能有限，但是该系统已经使用了相当长的一段时间，用户已经习惯了该系统的操作风格。然而我们直接判断该系统是落后的，功能不健全的，我们要作一个全新的系统，所以没有过多的关注该系统
8. 当业务流程进入到与施工方相关的任务时，流程多半停滞下来，但现实中的因为仍在继续办理。经过了解，我们得知：由于系统中要求施工方填写的部分信息属于机密信息，但系统中并未对这些内容作保密处理。
9. 在系统上线前，我们需要将用户收集积累的水表信息导入到系统中。在导入时，我们发现用户提供的水表号信息有大量的重复现象。而在系统设计时，水表号是主键。这是一个非常严重的问题。

11.1. 课堂分析

1. 在当前流行的亲子项目中(亲子班、亲子电影、亲子围棋等)，谁是用户？谁是客户？用户和客户谁的优先级更高？从Interest和Attitude的角度出发，如何化解项目风险？
2. 首先明确矩阵中的角色，其次依据策略展开分析

11.2. 课堂分析

1. 手机游戏的参与者、环境设定者、被影响者、观众？如何化解风险？
2. 手机游戏的强支持者、强反对者、弱支持者、弱反对者？如何化解风险？

11.3. 思考题

1. Phil Ittup是系统分析员团队中的一员，他受委任去与组织成员面谈，为系统研究收集材料。企业称为Fall Back工业，它有5个管理层。此外，生产、会计、营销、系统、物流和高层管理是将受到所建议的系统影响的职能区域。每个阶层大约有40人。生产层共有80人，会计层有35人，营销层有42人，系统层有10人，物流层有28人。高层管理有5人。Phil应该怎样选择面谈对象？为什么？
2. Maverick公司是一家有15年历史的国内货物运输公司，假设你的小组担当Maverick公司的系统分析与设计团队，为Maverick公司的所有业务设计一个计算机化或者增强设计计算机化的项目。Maverick主要进行卡车零运，管理人员按照实时处理(Just In Time)原则工作。在这个原则指导下，他们建立了包括发货人、收货人和承运公司的伙伴关系，目的是准时运输和交付生产线上需要的材料。Maverick主张用626台拖拉机拖运货物，它拥有45000平方英尺的仓库和21000平方英尺的办公场地。
   1. 制定分析Maverick公司的信息需求时，应当收集的硬数据列表。(提示：想像一下该公司要开展的工作，应该会有哪些登记表格)。
   2. 设计一种采样机制，使得小组在不必查看这家公司15年来产生的所有文档的情况下，形成对该公司的清晰认识。