为什么需求反复变化？

扬帆

请讨论！

扬帆

项目需求范围管理。

lifegame

需求反复变化原因有二：

- 甲乙双方对需求的理解都是个渐进和曲折的过程；
- 项目环境（包括业务、技术、管理等）的变化太快；

尽管“项目需求范围管理”的例行工作本身不可或缺，
但传统的项目需求管理难以从根本上解决需求反复变化的问题，
因为它往往都是在变更发生之后，被动地评估和控制变更的风险和成本，
而想在项目开始之前跟甲方约定详细的需求范围的做法，
对于IT项目来说，往往无济于事。

因此，要从根本上解决需求变化的问题，针对以上两个需求变化的原因，我们可以：

- 在项目资源安排上，要有一拨专家组，
  对该领域进行业务分析，而不仅仅是对该项目进行需求分析。
  这样以来，将来的大部分需求变更都会成为意料之中、掌控之内的事情，
  而且确保项目需求变更的评估标准符合医院中远期的IT战略。
  诚然，不是每个项目经理或者院长和CIO能够在项目经费有限的情况下，
  具有这种长远的眼光。

- 在项目进度安排上，采用小步快跑的策略。
  很多人都在提迭代的概念，这里就不多说了。
  只是提醒一下，在每次迭代里面一般是不允许处理新的需求变更的，
  要有变更也必须留待下次迭代再来考虑，这点要跟甲方充分沟通。
  当然，做计划的时候也可以根据需求变更的频率和项目本身的技术要求，
  在迭代周期的长短上灵活取舍。

mouse

说的不错

lifegame

楼上提到一个很现实的问题，国内很多具有“专家”头衔的人确实是名不副实。

这个问题在这里也没法说开去，里面涉及的体制、政治、人才的问题太多了。不过也怨不得人，有史以来都是千里马多过伯乐。

而且这个问题也是属于项目管理之外的问题了，这里提出来可能可以作为项目经理的参考而已。因为理想情况下这个医疗领域业务和IT战略的专家组是直接汇报给负责信息化的院长或者CIO的，项目经理可以是这个组的成员，但项目组本身是跟专家组平行的。前者主要关注短期目标的达成，后者主要关注中长期的业务和技术规范制定。

BTW，我想大多数现存的家庭发生矛盾的时候一般都是内部解决的吧，要是都闹到三姑六姨那边去了，估计这个家庭也岌岌可危了。

老包

3# lifegame

记得在翻译van Bemmel的《医学信息学》一书时，有些内容很让我吃惊。该书说医院IT项目投资中，30%资金放在系统开发上，70%资金放在系统调试上（我没有去翻原文，具体比例记不清楚了）。我反复思考过这个问题，我想主要是因为系统在医院环境实施十分复杂，所以精力和投资重点应放在开发后的调试和实施中。

所以我的理解是医院的IT项目与汽车，飞机，电视机等传统产品不同，需求变化大是其特点（也许带有服务性产品的意味），所以产品定价等都应有新的思维。也用婚姻来说事，俗话说“大姑娘十八变，临到上轿变三变”，这也许本身就是婚姻的特点。

所以我想也许应该：
1.充分估计医院IT项目的变化性，并以此确定相应的保证双方利害关系的方法和措施；
2.事前尽可能详尽地设计合同，但事前双方应充分认识这只能具有相对的完备性，要留有余地允许需求改变，也允许要求追加投资的额度。

扬帆

需求管理贯穿整个HIS项目生命周期，需求总是存在，变更是永恒的。如何高效收集整理需求，如何应对需求导致的变更管理，如果不纳入计划和监管，将需求失控、成本失控、质量失控、进度失控。
举一个简单的例子：
   一些HIS工程人员在前期调研过程中，到医院每个科室发需求收集表，收集上来后，大部分是重复问题，一部分与HIS基本无关，还有部分各科室之间相互矛盾。HIS工程人员陷入困境。
    聪明的做法，制定合适的需求收集表格，由医院信息化领导小组或医院办公室下发通知，各科室认真讨论需求，填写好需求收集表格后，由科室主任和护士长签名，医生的送医务科，护士的送护理部，药剂的送药剂科，收费的送财务科等等，由各行政主管部门归类整理后统一提交。
    记住：不同子系统，只确定唯一需求接口人，你将过滤出80%以上无为的需求。