项目Cycle Time的一种确定方式

这篇笔记源于工作中的一次讨论，主要关于某些项目的标准周期的确定方法。

问题背景：由于Operation组提出的审查样本量和目标数据点的不定性，导致我们无法估计一次项目下来所需要的标准周期，即使我们已经有了很多经验得出的数字，也无法判断项目的效率。

-----------------------------------------------------------------------------

思考下来，我目前所能想到最合理的确定方式如下：

首先定义始末点，然后再对项目进行分块，细化之后一些模块的时长是一个定值不随样本量大小变化（这种模块的时长如果变化很大，也就意味事后需要进入LSS环节了），然后把所有这种相对定值确定好，再讨论未知变量，在给定项目里面常见未知变量一般是Resource和Sample Quantity。

-----------------------------------------------------------------------------

例，常规项目-埃思普特亨立数据质量 （大前提，目标数据点Coverage稳定）

项目周期始末：

Start: 拿到整个抽出的数据

End: 与Operation组就此项目中的所有Cases达成一致

其中四个不同环节：

1. 得到的数据进行抽样复查（是否有异样，即抽数错误）和制作审计模板： 2天   （变动大意味需要LSS）

2. 进行审查： 可以知道一人一天做4个Sample, 样本量为未知数Xsample, 审计人员为未知数Xresource; 另有一个较自动的查D-T过程为时1天，有时它没有被operation组要求。

3. Operation组确认结果和我组复查结果： 5天 （变动大意味需要LSS）

4. 等待operation组sign-off一切，以及让他们准备action items：2天  （变动大意味需要LSS）

然后可以对环节二展开讨论，

此处便是简单的 Xsample/(4*Xresource)。

综上： 我们可以得到一个一元一次方程： Cycle Time = 11+1*(D-T True or False)+ Xsample*Xresource/4

这里我们可以把Xsample/Xresource看作一个未知数，那么其实就是第一象限的两条直线了，斜率0.25。

后记：自己的计算能力和逻辑性还是很差，有了思路之后，环节二的计算一开始被自己弄得很复杂。还想要找基数，其实针对这样的项目根本不必。另外，如果数据点coverage 有变动，那么建议用trial audit 的人均水平去估计环节二的算式。但是其他环节风险也就上去了。所以第一次，不如完全凭其他项目累积的经验去摸索，而且第一次做一个新项目Cycle Time标准化真的有必要吗？