将需求陈述清楚，对不能确定的因素，应提出几种可能的实施方案供开发方参考，以保证开发方系统设计时，将不确定因素设计成灵活可变的功能。

  其实，需求分析报告是对系统需求的书面表达形式。由于需求分析报告是采用软件设计的术语编写的，因此常常令计算机背景知识较少的用户方难以理解，也就很难发现需求报告中与实际需求不符之处，更难提出建设性的意见。特别是那些编写得较差的需求分析报告，用户方更是不知所云。

  因此，用户方的项目管理人员一定要要求开发方对需求分析报告进行进一步更详细的解释，以便用户方准确地理解需求分析报告内容，能及早地发现需求与实际的偏差。这也是对需求分析工作的总结与确认。

  用户方说：“计算机应该能实现这个功能，为什么会做不到？”用户方往往容易过高地估计计算机的软件开发工具的能力，总认为它一定能实现任何所需功能，期望值过高，所以经常会对所设计的软件大失所望。其实任何技术均有其一定的局限性，计算机系统也不例外，系统开发的最终结果只能达到有限的目标。

因此，双方应详细制定系统最终实现的目标，切不可用一些简单的术语来笼统概括需求，例如：“实现办公自动化”、“建立现代化的 MIS系统”这种抽象的术语只能将用户对 MIS系统的理解引入误区。

  总之，用户方与开发方的关系是项目管理所要处理的最重要的关系之一，增加沟通和减少误解是处理好这个关系的关键。所以项目管理人员要有效地安排开发方软件人员与需求方使用人员的交流，保证有畅通的交流渠道。在交流中用户方要尽量避免含糊不清的需求，而开发方要杜绝敷衍了事、得过且过的行为。

３．２　用户方项目管理人员与使用人员（业务人员）及决策层的关系　　

  用户方项目管理人员与系统使用人员的关系是十分微妙的。一方面，MIS 系统使使用人员减轻工作强度、提高工作效率；而另一方面，MIS 系统改变了现行的工作管理模式，使使用人员失去了一定的灵活性和随意性。但是 MIS系统的成功与否有赖于使用人员的检验。再好的系统，如果使用人员不愿意用，也不能说获得了成功。特别是在MIS系统的试运行阶段，使用人员对 MIS系统的使用实际上是对系统的深入测试，他们将发现许多在软件测试时疏漏的程序错误，从而有助于帮助开发方进一步完善软件功能，提高软件的实用性、稳定性及可靠性。因此，如何鼓励使用人员使用 MIS系统，帮助他们克服对新的工作模式的畏难情绪，也成为项目管理的任务之一。

  用户方的决策人士是用户方项目管理人员领导，由于行政手段是推行 MIS系统使用的有力手段之一，他对项目的支持是使 MIS系统开发成功关键与顺利实施的保证。因此用户方项目管理人员应随时与决策层沟通，取得其鼎力支持，这也是保证软件开发、使用成功的一个致关重要的因素。  

  任何一种新的工作方式，均必然有其适应及完善过程，用户方的项目管理人员、决策层及使用人员必须充分认识到这一点。当出现问题时，用户方项目管理人员应迅速分析问题，正确判断哪些问题属于不适应新的工作模式引起的，哪些问题属于操作不当引起的，哪些问题属于 MIS系统本身不完善引起的。对于那些由于不适应新的工作模式引起的问题，项目管理人员应引导使用人员迅速适应新的工作模式，必要时也要说服用户方的决策层采用行政手段推动实施；对于那些由于操作方法不当引起的问题，项目管理人员应培训使用人员正确操作系统；而对于那些由于 MIS系统本身不完善引起的问题，项目管理人员应迅速与开发方协调，尽快排除系统中的错误。

  在系统试运行初期，使用人员常抱怨说：“这个界面不方便，不好用”。

  在软件界面设计方面，用户方管理人员应注意提醒开发方注重其实用性、简便性、易操作性，要注意现行工作模式的特点，照顾使用人员的工作习惯，以便降低系统的使用难度。这将有利于新系统的顺利实施，有助于工作方式的顺利过渡。

  综上所述，项目管理人员应时刻注意取得决策层的理解与支持；要帮助使用人员尽快地适应新的工作方式，帮助他们解决使用中遇到的问题；并使系统在使用中不断地得以完善。

３．３　项目管理人员与软件编程人员的关系　　

  项目管理人员与软件编程人员的关系处理得如何将直接影响软件编程人员的积极性。在 MIS项目开发中，项目管理人员经常处在两面夹攻的地位。一面是使用人员，而另一面是软件编程人员。当使用人员对系统提出问题，并要求改动时，除了最简单的界面修改外，软件编程人员往往总是找出各种理由(如影响进度、系统结构会打乱、性能会受影响等)予以否定。而这正是引起开发方与用户方矛盾的最经常的原因。

  作为项目管理人员，既要满足用户方的需求变化，又要充分调动开发人员的积极性。由于系统分析不够准确，用户方业务需求的改变等诸多因素，均会导致要求开发方修改程序。作为项目管理人员应及早提醒开发方程序修改的必要性，在实际运作过程中用户方管理人员应尽早介入开发工作，及时发现问题，解决问题。在系统试运行阶段，将用户方不断提出的需求改动加以归纳整理，集中问题与开发方一起讨论解决方案。这样既

上一页  [1] [2] [3]  下一页