前言:
目前咱们对“高通文档”大体比较关怀,看官们都想要了解一些“高通文档”的相关文章。那么小编同时在网络上收集了一些对于“高通文档””的相关内容,希望朋友们能喜欢,大家一起来学习一下吧!本文节选自美国高通公司高级文档工程师 Geetha Haridas 2023 年 4 月博客。
估算通常是文档开发生命周期中被忽视的一个方面,特别是在需要作者被动工作并在短时间内满足多个截止日期的环境中。尽管一定程度的项目不确定性是不可避免的,但不去估算文档可能会对生成的文档质量产生重大影响。例如,文档工程师可能会在最后一刻吸收太多工作,并且可能没有时间自我检查他们的文档,从而影响他们创作的工作质量。
因此,在同意截止日期之前,评估完成项目所需的时间和精力,然后规划工作进度极为重要。同样重要的是要确保项目不是根据个人经验进行估计的,并且估计值与所有参与的贡献者相关,特别是当一个项目涉及多个文档工程师时。
本文提供了一个评估项目的框架,特别是在产品文档的背景下。文章介绍了 T 恤尺码法(快速估算法)和三点估算法,并总结了使用这些方法的优缺点。最后,本文提供了一个清单,重点介绍了估算项目时需要考虑的一些常规问题。
快速估算法
快速估算方法可用于根据项目的“规模”提供快速估算。该模型表明,可以根据项目的规模对项目进行分类并进行相应的估算。每个大小对应于特定的天数,如以下示例所示。
图 1:快速估算方法
要使用的规模
小型和中型等规模的定义完全取决于组织中项目的性质和规模。您可能会根据过去完成类似项目所需的时间得出示例估算。下表提供了一个示例。
规模
天
示例项目
小
2-15
快速入门指南。
中
15-25日
应用说明。
大
25-35
软件安装指南,从头开始编写。
特大
35-55
配置指南,从头开始编写。
超大
55+
涵盖安装和配置的实施指南,从头开始编写。
好处您可以提供快速估算,而无需进行详细的工作分解或任务分析。因此,这种方法可以节省时间。使用历史数据对项目进行分类可以得出合理的估计。缺点
该方法没有考虑项目的不确定性或复杂性。然而,由于该方法涉及估计范围而不是绝对值,因此该方法可以解释项目复杂性和/或作者不同产品知识的任何差异。
三点估算法
三点估算方法涉及得出一组三个估算,以确定在不同场景下完成项目所需的工作量:
最乐观估计 (O),如果一切按计划进行并且项目或资源方面不存在不确定性,则有可能出现这种情况。温和估计 (M),如果存在一些与项目或资源相关的不确定性,例如对要开发的功能缺乏一致意见或缺乏用于技术审查的专用资源,则可能出现这种情况。悲观估计 (P),如果存在大量项目和/或资源相关的不确定性,则可能出现这种情况,例如,如果项目范围可能完全改变和/或您的作者对您的组织来说是全新的。
然后使用公式计算平均估算值:(O+4M+P)/6,如以下示例:
任务
投入(以天为单位)
乐观(O)
温和 (M)
悲观(P)
写八个程序 procedure
6
7.5
8
写两个概述 overview
4
5
5.5
写一个介绍 introduction
2
2.5
3
创建流程图 flowchart
0.5
0.75
1
汇总
12.5 (13)
15.75 (16)
17.5 (18)
估计值 = [13 + (4 X 16) + 18] / 6 = 15.8333(16 天)
为了使团队中的文档工程师的工作更容易一致地进行估算,您可以根据您使用的工具和生成的信息类型定义与每个人相关的基值。下表显示了各种文档任务的工作量估计示例(以天为单位)。
任务
简单的
中等复杂
高度复杂
介绍
1
2
3
概述
0.5
1
2
程序
0.5
1
2
图形
0.25
0.5
1
词汇表
1
2
3
好处该方法考虑了项目的复杂性和文档工程师个人的产品知识。该估算是基于公式的,因此易于计算。该公式还可以内置到电子表格中使文档工程师更容易使用。作者可以生成一系列适用于不同项目和场景的估计。该方法比单点估计更实用、更可靠。缺点
根据他们的经验,文档工程师个人可能仍会得出不同的估计。然而,估计的范围(乐观、温和和悲观)应该有助于解释任何差异。
过程
项目应使用的估算方法取决于几个因素,例如:
项目的总体规模/复杂性。例如,简单的项目可能不需要详细的估计和规范。确定项目规模的请求的紧迫性。可能会有临时但关键的项目评估请求,例如根据项目的优先级分配创作资源。项目当前所处的阶段。如果项目处于非常早期的阶段,可能无法进行详细的估算。
以下流程图显示了可用于估算文档项目的流程。
图2:估算过程
该流程图概述了以下过程:
提出估算请求后,创建快速估算以评估总体工作量。不要在项目的早期阶段创建详细的估算,因为项目的范围可能会发生变化。如果项目稳定,但快速估算小于或等于 5 天,则仅使用项目的快速估算 - 详细估算和文档规范仅对中型到大型项目有用。如果项目稳定且快速估算超过5天,则计算三点估算。清单
除了实际的文档更新(包括编写概念、概述、过程和创建图表)之外,各种其他因素也可能会影响您的估计。以下清单提供了您在估算项目时可以考虑的其他项:
现有文档(文本和图形)的质量已经过评估。如果合适,现有文档的任何进一步改进均已确定并加以说明。
对其他团队的依赖性和/或当前不可用的任何信息已被识别并说明。
如果内容可以重复使用,则可以使用适当版本的源文件。
以前版本中任何突出的文档错误都已得到审查和解释。
文档更新对其他指南/项目的任何影响均已确定并传达。
意外任务的额外时间已包含在估算中。
结论
文档估算是规划过程中不可或缺的一部分,可用于评估工作量、安排项目以及分配足够的时间来生成高质量文档。估算并不总是一个涉及复杂程序的详细过程。您可以根据项目所处的阶段和所涉及工作的复杂性来使用适当的技术。通过始终如一地使用这些技术,估算过程可以变得更加容易,并允许您主动识别和处理可能影响项目的方面。
参考
美国高通公司是 DITA XML 结构化编写标准的早期采用者。