2006-10-21

项目前期的工作量估算

关键字: 项目 工作量
工作量估算是商务报价、人力资源调配、进度安排等各项工作的重要依据。
我的工作之一是在项目前期进行工作量估算。
大多数情况下，所能获得的信息都是不完全的（包括业务和技术方面），如何突破这些不完全的信息迷雾，是我一直极为头痛的问题。
目前主要通过评估以下要素来得出，针对这些要素，要尽可能获得比较确实的信息，如果无法获得，则需要根据经验进行评估。
功能性需求：业务对象的数量、业务对象间相互关联的数量、单个业务对象的逻辑复杂度
流程数量、各流程间相互关联的情况、单个流程的节点数量、授权要求
非功能性需求：用户数、稳定性要求、可靠性要求、运行时间要求、响应速度要求、安全性要求、可扩展性要求、可维护性要求、特定技术要求
涉众评估：团队关键角色（包括甲方和乙方，如为联合项目，还应当包括第三方）、非关键角色的期望水准、涉及利益团体数、涉及利益团体的相互关系、风险承担人的态度和执行力
其他：关键资源、不可抗拒力、可选择的实施路径
评论
clamp 2006-10-28
总结：
项目前期最主要的目的还是风险预防，其工作量估算非常可能有极大的偏差。
然而大多数情况下乙方被迫在此阶段做出商务报价，从而把大量的风险都转移到了后续的项目实施阶段。
clamp 2006-10-25
前提条件，影响项目成败或者估算工作量：
1、技术框架。硬件平台、第三方软件、软件体系架构等
2、涉及利益团体的相互博弈关系
3、团队关键角色（包括用户方和己方）
4、特定时间节点和特定资源、特定技术要求。
clamp 2006-10-24
回头又看了一下，发现小结的东西比较“废话”。

再回顾一下自己考虑这个问题的背景，以前做工作量评估的时候基本是以个人经验直接思考得出最终结果，有时按模块分一下，有时加个风险值，具体在哪种情况下应该考虑哪些参数完全以个人经验为准。
经过一段时间的工作之后，一方面积累了一些经验，想归纳一下，另一方面做评估的人手也增加了，而不同人的经验不完全一致，也需要统一。
所以就有了一开始的思考，把所有要素列出来之后，我又觉得过于复杂了，如果在一开始就引入所有的参数并对无法获取的参数取估计值，由于各参数之间相互的影响，反而会造成范围过大，“欲速则不达”。因此在早期引入的参数不必过多。
有必要将早期再细分为以风险估计为主的估算和以工作量为主的估算。
只有将风险降低到一定级别以后，以工作量为主的估算才有意义。
clamp 2006-10-23
小结一下:
1、首先明确对工作量评估影响最大的要素。
1）技术架构。2）业务范围和要求
2、对于其他要素，若无法获取则可以用经验值或期望值来初步估算，等待进一步细化和明确。注意：某些要素在细化和明确以后可能会导致无法估算工作量。例如进度要求过紧等。
3、基于技术架构，对于业务对象进行逐个分析，折算成基准功能点，然后得出基准工作量。
4、根据调研的持续进行，对原有的假设参数进行不断的调整，从而不断精化这个值。
clamp 2006-10-23
(似乎不能改自己的评论,只好继续写修改意见了)

如果既非成熟团队也无业务经验,由于其风险偏差过大,个人认为不宜采用自下而上的估算方法,而应该由核心人员根据自己的经验直接估算总量(往往只能得出量级),然后祈祷自己的运气了.
clamp 2006-10-23
看一个具体的例子:
工作负荷管理:工作负荷分析在这里主要是对销售员作工作量统计分析，根据系统提供的销售日志功能，对销售员的工作量作分析和统计。

从这段话里可以提取出一个业务对象:工作量.
本功能主要为统计分析,其原始信息来自于其他对象(销售员\销售日志),不计入本功能的直接工作量.
工作量的属性可以包括精度(按照人月\人日\人时统计)和权重分配(是否要区分加班\节假日等)
其统计分析的复杂度依赖于工作量、销售员和销售日志等多个对象的维度.

基准功能点设为：
精度为人日、考虑单变量权重分配、最多不超过三个关联维度的单个统计报表，其界面展示方式为技术框架所支持的标准界面。

假设涉及利益单位为3个，每个利益单位折合基准功能点为5个，
则此模块中包含15个基准功能点。

每个基准功能点折合工作量估算为10人日（包括分析、开发、测试）。

总的基准工作量为150人日（约合7.5人月）

假设无特定技术要求。
若为成熟团队且有业务经验，风险值设为30%，若为非成熟团队，再加50%风险，若无业务经验，再加100%风险。


以上参数随着调研的进一步深入会不断的调整和精化，从而持续的提升准确度。
clamp 2006-10-21
业务对象（数量、关联关系、逻辑复杂度）：
业务对象还是一个比较容易理解的概念，但是为了估算工作量方便，需要把一些比较复杂的业务对象切割或折算成一些比较简单的对象。
针对业务对象中的属性类型的不同，其工作量的估算也会有所差异。
1、字符串型。纯粹的字符串信息，相关的业务逻辑一般情况下只有增删改。通常有是否为空的逻辑判断。过长的字符串往往意味着分析不完全，很可能有进一步拆分的可能性。
2、选择型/规则字符串型/数值型/日期型。通常会涉及到业务逻辑，即使在增删改时不涉及到，在统计时也会涉及到。需要特别注意分支逻辑的数量，如果针对某一属性的分支逻辑数量过多，则应当考虑是否将其拆分成若干个子对象。
3、关联型。用于和其他对象关联的属性，几乎总是涉及到业务逻辑
4、允许复选或同时存在多个值的属性，要么需要拆分出新的业务对象，要么需要增加原有对象的复杂度
发表评论

您还没有登录，请登录后发表评论

clamp
搜索本博客
存档
最新评论
  • 数学和软件
    对我们一般程序员来讲，如果将两者结合起来，是有相当难度的。不但要掌大量高等数学知 ...
    -- by blackanger
  • 数学和软件
    我觉得软件开发有个三个主要问题：做什么；怎么做；为什么这么做。数学有助于后两个问 ...
    -- by cookoo
  • 数学和软件
    hurricane1026 写道庄表伟 写道数学<>逻辑学 软件开发，更 ...
    -- by cookoo
  • 数学和软件(3)——从勾股 ...
    不否认软件和数学有一定的关系，但是这样的对应关系是不是有点牵强了。。。 。。。 ...
    -- by blackanger
  • 数学和软件
    我的理解是： 数学好的人，可以把软件用纯数学的语言来描述，这种方式也许只能数学水 ...
    -- by blackanger