项目后期的工作量估算（兼谈后期需求控制）

通常一个项目都会有某个里程碑代表项目告一段落，可能是商务到款/初验/上线/专家评审会/……等等。
然而在这个节点之后，还有多少工作量呢？
有些项目可能一点工作量都没有，有些项目的工作量可能极大，应该如何界定和估算项目后期的工作量呢？

关键在于评估当前版本对用户需求的满足程度，假设有若干个“用户”“接触”过这个系统
用户类型：用户方领导、用户方的IT人员、用户方业务代表、该系统的正式用户、不知道从哪里找来的“专家”
用户个性：负责、应付、挑剔、糨糊
接触类型：看、简单试用、测试、正式使用。
接触次数和时间：短时间的频繁接触、长时间的非频繁接触、长时间的频繁接触

评论

11 楼 clamp 2006-11-03  

上面最后一句话的前提是：商务上该项目有继续维护的价值。

10 楼 clamp 2006-11-03  

在业务架构和技术架构稳定的前提下，后期项目控制的关键在于如何让项目组成员（往往人数较少、能力较弱）比较好的理解现有的业务架构和技术架构，以及如何比较好的遵循现有测试和发布过程。

如果是从项目实施阶段一直延续下来的人员，即使能力较弱，也可以较好的控制，但是如果是新进人员，无论能力强弱，也很难很好的控制。

如果一个项目的后期维护人员变动比较频繁，那么有必要在适当的时机投入人力对其进行重构。

9 楼 clamp 2006-11-03  

假设业务架构和技术架构已经建立并相对稳定，在这种意义上的“后期”，那么其工作量主要取决于后期需求管理和控制的水平，以及版本测试和发布的流程。版本混乱、缺乏比较完整的测试和发布流程，都会引起工作量的大幅度上升。
以我们目前的过程和控制力度，后期工作量在5%-20%之间。

如果业务架构或技术架构仍未稳定，那么即使进行了商务上的初验，也不能认为进入后期，其工作量估算仍然应当按照中期工作量估算模式来进行。

8 楼 clamp 2006-11-02  

在这一点上,我对XP的某些实践持保留态度

1、重构的成本并不是零，通常情况下重构对客户来说是效果不可见而工作量可见的，必然会影响对客户交付物的效果，需要仔细的计划重构的时间进度。
2、很多情况下，重构之后原有系统的架构趋于复杂化，导致新的变化必须要考虑对原有架构的影响。
例如原来有A1、A2、3三个类，从中抽取出比较类似的功能作为基类A，A1、A2、A3继承。今后新增内容就一定要考虑是变动A，还是新增A4，变动A是否对A1、A2、A3产生影响等等。

以我目前所接触的程序员群体来说，如果这两点都能很好的做到，那么我认为这个程序员最起码值10000以上的月薪。但是这样的人往往不适合也不愿意待在一个后期项目中。

而如果我用月薪5000以下的程序员，那么就必须要控制任何会引起较大规模重构的需求。

7 楼 clamp 2006-10-31  

后期和中期的界限在于：架构不再改动，架构包括技术架构和业务架构

基于以下考虑：
1、一个稳定的业务架构和技术架构有利于保持概念的稳定性，有利于和用户的沟通，用户在长期的使用过程中也比较容易接受架构所蕴含的一些概念。也有利于维护、支持人员的工作。
2、到了后期一般团队会有所收缩，而抽出的往往是骨干，留下的人无论能力和精力都不足以保证较大规模重构的有效性。

因此，判断是否进入了后期，首先要判断的是业务架构和技术架构的稳定性。

6 楼 clamp 2006-10-31  

对于这些要求我的评估是这样的
1、当场就拒掉了
2、岔开了话题，未写入意见列表，B事后也不会来关心这件事情
3、C的要求呢倒是我们一个隐含的问题，因为这个系统赶的比较急，所以各个模块预留的日志接口没实现几个，这部分倒是要补的，毕竟对于以后的维护是很有好处的。不过公开就不必了。

该还的总是要还的，不该还的就要坚决拒掉，这是我的一贯的原则

5 楼 clamp 2006-10-31  

今天的一个项目验收会上就碰到了类似的问题：
1、与会人员A要求查询结果可以导出为pdf（已经提供了导出到excel）。理由是pdf不能改，excel可以改。
2、与会人员B要求某个查询条件复杂化。
3、与会人员C要求所有的操作都得有日志记录，并且要公开。
但是所有的A/B/C都不会来使用这个系统……

4 楼 clamp 2006-10-30  

虽然是最终用户，但是由于利益冲突关系，故意挑剔，不想使用这套系统，出一些似是而非的难题。

比如手头有很多老的数据是用excel维护的，不愿意手工录入，要求提供数据倒换功能。
或者要求减少系统中的约束条件，从而削弱系统的管理意图。
包括把字段从必填改为选填、流程的时间限制放宽等

这种情况就要具体情况具体分析了，很考验项目经理谈判的功力。

3 楼 clamp 2006-10-30  

另外一种很忌讳的情况是乱比较，比如拿B/S和C/S比较，从而提出一堆要求。

除非技术框架已经支持，否则这种情况也应当拒绝。

2 楼 clamp 2006-10-30  

让我非常头痛的是所谓的“专家测试”，这种情况下一般对功能的完备性要求很高，但是对业务逻辑却测的很少，结果往往是提了很多纯技术性要求，但无法反映真实的业务需求，虽然投入了大量的工作量实际效果却不好。

这是我非常忌讳的一种情况，除非有充足的商务上的理由，否则我会尽量避免。

1 楼 clamp 2006-10-30  

一般而言，越是正式用户、接触的越深入、接触时间越长越频繁，意味着系统越满足用户需求，然而这里存在着“物极必反”的现象，当满足程度极高的时候，用户会产生更高层次的需求或者是新的业务范围，从而大大超出原有项目范围，带来极大的工作量，所以要十分小心的识别这种情况，果断加以控制。

以下几种要求都是可能的征兆：
1、增加用户方也不能完全说清楚业务含义的字段。往往意味着新的业务范围
2、对报表的灵活性要求大幅度增加。往往会迈向商务智能分析或数据仓库。
3、增加用户管理的层级。往往意味着系统推广。
……