谈谈软件项目中的用户配合工作

谈谈软件项目中的用户配合工作 摘要 本文是在我就项目管理与一些客户做交流的时候的一个简要发言的基础上写成的，既作为一篇简要的论文，也想借此抛砖引玉，与同行探讨一下业界未给予充分重视的一个问题：即对一个成功的软件项目尤其是大型软件项目而言，用户方应该做那些关键的配合工作，以促进项目的成功开展。通过这个问题的研究与宣传，可以很好地提高用户自身的项目管理意识与合作意识，利于项目双方在项目中的协作工作；同时这个问题实质也是我们开发方管理人员、项目经理在项目管理活动中需要密切注意的一个方面：即如何来引导用户以协作我们。 文章中谈到的用户配合工作是指：项目开展的各项工作中，在以开发方项目组为主要方面的情况下，从利于项目正常进展的角度，用户需要进行的协助工作。一般地，项目中用户进行的各项工作都具有协助性，如协助系统的需求调研；准备用户运行环境；组织一线人员培训、试用；为利于项目正常进展进行的监督工作等等。而就这些工作的意义，本文仅讨论关键性的协助活动。另外，为推动的项目的顺利进行，用户方的按时付款也是一项重要的配合工作，但由于实际中的项目，对用户的催款、收款多由别于项目组的其他专门渠道进行，因此未在本文中予以讨论。 文章按软件项目生命周期的一般划分（瀑布模型）来叙述周期中各阶段用户关键的配合工作。实际上，作为项目协作方的用户，所有这些配合工作也应是用户方的义务内容之一。关键字 软件项目 配合工作前言 一个软件项目（系统集成项目的一个子项目或单独的一个软件项目）的成功涉及的因素、方面非常多，其中，无疑地，用户方的积极、科学的配合工作是项目成功的基本因素之一，这在当前软件项目越来越复杂、规模越来越庞大、用户个性化越来越鲜明的背景下表现尤其明显。用户方不配合比如，需求迟迟不予确定，变来变去；软硬件资源迟迟不能到位；用户内部钳制，项目推动困难重重等等，任何一个情况发生，项目基本是注定要失败的。所谓的失败，倒不是项目一定被终止，而主要是项目在完成时已往往较大地甚至很大地超出了预期的、合同规定的进度、成本要求。纵观当前行业内各种或多或少不算成功的软件项目，多少都与用户的配合工作有密切关系。这次参加高级项目经理培训，对学员就项目管理中最棘手的问题的调查，列首位就是用户的需求不规则变更问题。而这个问题也与用户配合工作是否到位关系极其密切。可见，用户方的积极、合理的配合工作是何等之重要！在项目管理中引导好用户积极、合理地配合我们是何等之重要！ 但是，在项目过程中用户应如何合理地来配合我们开发方呢？在多数的项目环境中，这个问题并未得到很好的解决，故而发生了上述的各种现象。其原因，除了其他各种因由外，更多情况下，一是开发方在项目管理中不知道如何系统合理地引导甚至要求用户的配合工作，而更多是一味按用户要求办，怕得罪用户；一是用户方未充分认识应如何来配合项目的开发，而往往以为 “用户是上帝”，主要地，提要求就可以了。本文拟根据自己多年软件项目的经验，谈谈这个问题，以便为项目中，用户规范自己的配合工作、项目管理者引导用户的配合提供参考。当然，用户是否配合开发方的工作，是一项复杂的系统问题，涉及到如客户关系是否到位，开发方的项目队伍水平如何、用户方的项目管理意识如何等等广远的方面。本文则仅研究如何配合的问题。 本质地，软件项目进行中用户对项目组的配合是一个双方紧密合作，及时沟通，共同把项目做好的协作过程。由于软件项目的复杂性以及项目生命周期中不同阶段各具特点，因此，项目的不同阶段，用户对项目组的配合工作有所不同。本文将按照软件项目生命周期的一般划分，即：项目启动、需求获取、需求分析、设计、编码、系统测试、实施（含关闭）来对不同阶段中用户对项目组的配合工作进行叙述。当前，由于软件技术、需求、方法论等的发展，迭代式的生命周期应用相对普遍。除项目启动外，将上述的不同阶段视为活动，则本文的叙述也在一般意义上适用于迭代式的生命周期的情形。另外，本文主要是基于一些中大型软件项目总结出来的，对小型软件项目的情况可能有所不同。项目启动 项目启动作为一个项目的起步阶段往往是明确目标、建立项目组织、制定计划的时期。在这个阶段，为利于项目的全局发展，用户方面应进行的一些主要配合工作如下：l 明确系统上马的目标，成立自己的项目实施小组与领导小组，以形成落实项目各项工作的责任者与组织者，并形成与开发方项目组的唯一接口； 这项工作非常重要，即所谓目标与组织问题。这个问题解决得好，意味着项目成功有了基石。就组织而言，多数的项目中，用户方的项目实施小组由信息处室或信息中心的人员组成。最好，实施小组也能包括一线业务部门的骨干人员、领导人员，此将有利于项目需求的获取以及实施。对领导小组则必须要有决策权、资源调配权的人员组成，否则将不起作用。l 参加项目组组织的项目计划的评审，确定并把握项目进度、风险，形成项目章程等规范； 一般的大型项目，开发方都应制定详细的项目计划并对计划评审。对项目是否制定有项目计划并按计划的指导来开展项目也是考量一个开发商项目管理规范性的标准之一，是项目成功的重要因素。用户方应参加开发方项目组组织的项目计划的评审，既能监督开发方项目进度安排、资源配备是否合理，风险把握是否充分等，也能充分表达自己的要求与建议，协助开发方进度、质量、风险等方面更合理的把握与安排。同时，还能对自己在项目进展中需要进行配合的工作有总体的把握。 一般大型项目还需单独形成项目章程规范。这些规范规定了项目双方在项目进展中的义务与协作关系、问题处理程序、需求变更程序等。用户方应积极参与讨论，协助开发方来予以制定。l 与开发方协商建立良好的沟通机制，如周例会制度、来往文件的流程形式等； 本部分可以包含在项目章程中。对涉及部门很多、地理范围很大的项目，用户方自己内部还应建立稳定、良好的沟通机制。l 动员组织内相关人员； 项目涉及的部门、人员越多，地理范围越广，动员越为重要。对组织内相关部门、人员进行动员，提高大家的热情、预先初步确定大家的行动步骤无疑为项目的前期调研与后期实施打下了基础。l 开始规划用户方环境等资源； 计算机环境等资源要求越多，而资金又可能紧张的用户，这项工作越为重要。 对这个基础阶段需要强调一点：用户方各级领导尤其是决策者的重视与决心是项目成功的关键。一个项目开发中的许多难点来自于用户方，所有这些难点的解决离不开用户方各级领导的重视与决心。这是用户方配合工作中的核心所在。需求获取 需求获取中用户方面应进行的一些主要配合工作如下：l 按项目计划或章程的规定进行监督与沟通工作：从项目组获取相关报告以监督项目进度、风险、质量状况；定期举行沟通会议沟通并处理发现的问题； 即按项目启动时确定的计划或章程、沟通机制进行相关工作。相关报告可能包括周报告、月报告；质量报告；问题追踪报告等等。本项工作是贯穿整个项目期间的工作。l 在协调好内部工作，重点是一线用户工作的基础上，与开发方项目组共同确定需求调研计划与调研流程； 需求的调研由于涉及到与参与的一线人员的工作冲突，故必须注意事先协调。要协助开发方项目组制定调研计划与流程，安排好调研时间、涉及的各业务部门与人员的调研顺序、调研的产出等。流程方面主要根据业务特点与开发方共同确定调研的方式，如举行调研会议或问卷式调研或原型法调研等等。l 协助并监督项目组按需求调研计划与流程开展的调研活动，及时处理其中出现的问题，如资源的协调，调研计划的变更等；l 组织业务骨干、领导参与需求的评审并进行确认。对存在争议不能确定的业务流程或需求，及时组织相关部门、专家、领导研究后予以确定； 本项配合工作非常重要。对开发方就调研形成的需求举行的评审，用户方必须组织业务骨干、领导参加，或者就以用户方为主来组织该项评审工作。用户参与或组织需求评审以及对评审后的需求进行确认是一项重要的质量保证与风险规避手段。通过评审，用户、项目开发方可以对需求的产出进行仔细的再交流、沟通，不仅利于用户对需求产出质量的确认，而且可达到各项目利害关系者对需求的一致认识。这样可以很大地提高需求的质量并降低项目的风险。同时，需求评审的形式应注意按一定的流程或方法进行，如评审应采用正式的会议形式；对需求进行分解，各参加评审的业务处室只集中精力评审自己业务相关需求；评审时先组织阅读一下需求文档以检查缺陷或者评审会议上由开发方需求调研人员将调研形成的需求进行详细讲解等。当然，通过评审会议的形式，需要投入的人力、时间比较大，这是它的缺点，但相对需求不明确、质量差导致返工的风险，这些投入是非常必要的。l 配合项目组基线化需求，以作为以后一切项目工作的基础；l 按计划或章程中确定的需求变更程序进行需求变更。对超出合同等的需求变更进行严格控制、评审与把关； 本项配合工作也非常重要。由于项目进行过程中用户业务的变化、初始需求调研时难免的错漏等原因，需求的变更是难免的。但需求的变更必须按一定的工程化程序进行，否则，必然引起开发方项目组的无所适从以及大量的返工，导致项目的失败。 超出合同等的需求变更也是经常存在的。对这类需求变更用户方尤其需要进行严格控制、评审与把关。在把关后确实需要开发方开发的，应适当增加项目的工期、合同款项。这并不违反“用户是上帝”这一原则。因为如果需求有较大的扩充，而工期、投入不增加，则质量必然没有保障，为弥补质量缺陷，即使用户方也可能得不偿失。l 参加里程碑会议，总结经验，调整各自的行动策略； 本项目工作也往往是为用户忽视的一项工作。参加里程碑会议，及时总结经验，规避风险，调整策略对项目成功是重要的。里程碑会议，有时不够规范的开发方也会忽视进行，这时候，用户应主动要求开发方举行该会议。 本项配合工作各阶段均应进行。需求分析 需求分析中用户方面应进行的一些主要配合工作如下：l 按计划或章程的规定进行沟通工作； 参“需求获取”中的初始项进行。l 配合项目组系统界面的分析设计工作，组织一线操作人员、业务骨干、领导确定系统的界面风格、布局、操作方式； 多数项目会在需求分析中做系统的界面分析设计工作，用户应及时组织相关人员予以确认，及时提出建议。这项工作如果遗留到项目后期来做或者初始时用户配合不充分，将不可避免导致大的返工。l 参加里程碑会议，总结经验，调整各自的行动策略 参“需求获取”中的相关项进行。系统设计 系统设计中用户方面应进行的一些主要配合工作如下：l 按计划或章程的规定进行沟通工作；l 必要可参与或组织系统设计评审； 一般说，系统设计用户没有必要一定参加。但对非常重要的项目，建议用户参与或组织系统设计评审，并且如果可行，可聘请行业内专家协助进行。主要目的是规避风险，防止早期设计上的重大缺陷。另外，用户参与或组织的评审应主要集中在系统架构设计上，而不是模块级的详细设计上。l 参加里程碑会议，总结经验，调整各自的行动策略；编码与系统测试 编码与系统测试中用户方面应进行的一些主要配合工作如下：l 按计划或章程的规定进行沟通工作；l 参加里程碑会议，总结经验，调整各自的行动策略；系统实施 系统实施阶段用户方需配合的工作也比较多，如下：l 按计划或章程的规定进行沟通工作；l 及时准备系统确认测试、培训、试运行要求的环境与资源； 对那些跨地区的项目，这项工作尤为重要。或者需要将各地的操作人员集中到某一地进行确认测试、培训；或者需要为各地建立试运行环境。这都需要用户方充分估计其中可能出现的复杂性问题，及时作好应对工作。l 与项目组协调制定确认测试计划，组织相关部门、人员按计划进行确认测试，及时提交确认测试报告。必要还可组织现场环境下的性能测试； 对测试中发现的缺陷必须按计划中规定流程进行处理，如按一定的规范搜集发现的缺陷；重大缺陷规定开发方立即修改；一般的缺陷应按周期要求开发方修改；微小的缺陷可以暂时不予修改等。l 与项目组协调制定培训计划，组织相关部门、人员进行培训，及时检查培训的效果以对培训方式进行改进；l 与项目开发组协调制定试运行计划，协调好资源，组织相关部门、人员进行试运行； 同样，对试运行中发现的缺陷必须按计划中规定流程进行处理。另外，对试运行发现的需求变更也应注意按需求变更程序处理。l 组织相关人员验收，关闭项目；l 参加里程碑会议，总结本次项目中双方的合作经验，便于以后的协作； 在上述整个软件项目的生命周期中，用户方最核心的配合工作在组织方面与需求方面。用户方的这些配合工作如果很成功，在多数项目中，将最大地规避项目面临的各种风险，极大地促进项目的成功。 也正是因为上述用户配合