如何做好软件项目的验收管理工作.doc

怎样做好软件项目验收管理工作

　　项目验收是企业乃至每个项目组员都想要结果, 一旦验收对企业来说就是, 能够收验收阶段款了, 不需要再投入那么多人力到项目当中, 项目最终能够告一段落, 大家都能够轻松一下了。项目验收是一系列细致工作完成到位结果, 而不是某一点成功或某个人能力就能够促成事情。一个项目验收, 通常是由一系列验收准备工作组成。假如我们在最终验收前, 已经将很多阶段工作细化并得到认可实施, 那么项目验收也就是水到渠成事情了。
　　首先我们要明确进入验收前提。很多人都认为只要我们完成了协议中要求内容, 完成了需求规格说明中要求工作, 而且按协议试运行了多个月, 应该就能够验收了。就能够拿着协议或技术协议与用户谈论验收相关事宜了。
　　但实际上用户往往不一样意在此时验收。她们判定往往不是招标书、 协议、 技术协议、 需求规格说明书等文档。其实这些文档不管做得怎样细致, 对用户而言并没太大参考价值。用户关心是她们业务是否真地在系统中运作, 而且运行良好, 并以此作为检验项目验收标准。当然有项目也能够经过商务运作, 在业务实现不太好情况下验收。
　　1、 在项目实施过程中重视里程碑确定, 制订阶段性目标
　　假如要做好一个项目, 完成项目验收条件, 关键还是以业务是否可用作为衡量。不是一定得实现全部用户需求(这里指是口头上需求, 假如落实到文字上还是要实现), 也不是只有将部分所谓技术难点处理用户就会同意验收, 而是我们能够完成一定阶段应用业务目标。
　　我们从进行需求调研时候就要主动控制项目边界, 将一个一个业务流依据用户方实际情况合理组织实施次序, 形成我们项目实施计划中里程碑点, 明确达成里程碑点条件, 并得到双方一致正式认可。
　　没有双方高度达成一致里程碑认可, 也就是没有项目目标约定, 没有目标约定项目实施计划一定会常常变更内容、 变更初始设定目标, 造成计划不可控制, 更谈不上验收。
　　很多人期望经过具体系统需求规格说明书来定义项目要实现内容和业务目标, 这是很有必需, 但需求规格说明书得到认可并非是经过用户审核就能够结果, 应该想措施让用户一起参与到需求规格说明书制订过程中来, 变成用户自己推导出来业务实施目标, 未来才不轻易变形。
　　2、 主动主动地与用户进行沟通
　　项目中一定要有沟通策略, 和高管怎样汇报工作进展, 取得支持? 和中层怎样就业务目标不停确定, 逐步清楚? 和基层怎样就项目应用操作模式达成一致, 连续改善? 都需要经过沟通反馈完成。
　　沟通作用对于高管是让她们清楚我们一直根据项目目标前进, 每个阶段工作进展是否顺利, 影响项目正常运做原因是什么, 需要哪些资源帮助。和高管沟通比较多话, 第一个好处是高管常常听汇报就知道项目进展程度, 能够安排反馈检验, 看是否含有我们所说进展, 这么一旦认可了各个阶段目标后, 最终要求高管签字确定也就顺理成章了。
　　给高管汇报技巧就是简练明了, 真实客观, 有理有据分析问题, 提出对策提议请其决议即可。
　　中层往往是项目关键推进力量和实际实施者, 也往往是对具体业务需求最关键要求者, 她们对企业实际运做过程最清楚, 提出要求最具体, 而且项目验收是否没有中层同意往往也是不太轻易做到。
　　往往经过前期业务调研只能对企业项目目标有一个大, 宏观认识, 但怎样细化并最终落实并非是一步到位过程。所以在整个项目过程中, 双方项目组要不停沟通, 尤其是企业中层沟通, 才能逐步认识越来越深刻, 最终达成一致。
　　和基层沟通关键表现对最终用户关心, 定时主动和最终用户沟通, 消除部分怨气, 让用户能坚持用下去, 这个时候我们往往发觉很多用户真是非常好相处, 尽管软件还有很多值得改善地方, 但她们一旦认可我们团体, 反而会尽心尽力帮助我们推进项目进行。
　　现在我们企业通常要求每个项目经理在项目进行中都要填写详尽项目月报, 反应项目进度, 与计划偏差, 完成项目内容, 投入人力, 现在项目存在问题, 以及估计项目下月进度等等。将进度月报交部门责任人、 项目管理中心、 总经办审阅。
　　类似地也要制订针对用户月报甚至是周报, 将相关信息反应到用户方责任人, 及相关高层。能够先发邮件, 然后还要电话落实收到并口头简明汇报, 尤其是高管层, 千万不要认为发了就等于他人会去看, 一定要口头跟进汇报一次, 确保用户各方面责任人对项目进展做到心中有数。
　　在项目过程中, 我们也需要注意平时做人积累, 比如要做到讲诚信, 讲标准。关键是三条: 1)做不到事情千万别随意承诺;2)承诺事情一定要努力做到;3)每次做到事情都进步一点点。按这三条做事, 即使在系统使用过程中总会有这么或那样部分不方便, 用户也会慢慢接收稍微长一点响应周期, 也会用更多主动性眼光看现在问题, 也相信问题一定有些人响应, 也一定能够得四处理。进而使我们和用户之间形成一个较为友好关系。
　　3、 写好备忘录和问题跟踪统计
　　在一个漫长项目周期中, 很多工作做了也就做了, 认可了也就认可了, 时间一长也就忘记了很多承诺和约定, 到了验收时候就可能重新翻出来, 这种事情很多人可能都经历过, 明明说能够先不做内容最终验收时候又成了必需条件。
　　每次备忘录要口头交流认可后才打印签字确定阶段性工作结果。下次工作则依据前次备忘录双方约定继续进行, 保障项目在每次工作基础上不停前进, 并用备忘录约束双方行为。
　　同时我们提议在搜集项目出现多种问题时, 采取问题跟踪统计表形式, 这么能够一目了然地显示出我们曾经搜集到多种问题, 现在处理情况, 以及还有什么问题没有处理, 准备什么时候处理。这么用户和我们都会对现在情况非常了解, 经过不停地处理出现问题, 来收敛可能出现问题, 当存在问题越来越少时, 也就表示我们系统已经在靠近验收标准了。
　　4、 验收阶段准备工作及注意事项
　　当系统经过一段试运行, 含有验收各项条件以后, 我们就需要着手验收阶段准备工作了。首先我们需要把到现在为止完成工作进行一个总结, 列出我们已经完成各项目工作结果、 各类文档, 对协议以及各类约定技术文档中相关内容进行自查, 要根本了解系统现在完成情况怎样, 是否已经完成了与用户方达成各项书面约定以及口头约定, 没有完成, 假如是书面约定, 准备采取什么策略去深入完成或者采取一定回避方法, 使用户在验收时候不再提出这些未实现需求。
　　做一个具体验收计划是非常必需, 能够用来作为验收阶段工作指导。这就需要与用户进行具体沟通, 再次明确验收前需要完成工作, 尽可能避免用户方在此阶段提出过多更改需求, 这是极为关键。验收计划中不光要有需要继续完成工作, 还需要有一个相对固定工期, 使双方都继续朝着这个方向去努力, 预防无限制拖延。
　　我们很多项目碰到部分常见问题就是软件开发完以后, 很多用户也不使用, 假如我们去催促她们时候, 就常常推脱工作太忙, 还有其它事要做等等, 或者也就是应付一下随便提一两个小问题。而等我们提出要验收时候, 她们又总是认为这也不满意那也不满意, 总而言之是怕负担对应责任, 不愿意验收。
　　针对这种情况我想关键还是想措施让用户尽可能把系统使用起来, 只有在使用中才能发觉问题, 我们也才能处理问题, 使系统能愈加好地运行。假如是基层人员不愿意使用, 我们能够走上层路线, 使用户高层了解项目正常运行关键性, 也使她们意识到项目验收关键性, 意识到无限制地拖延下去会对政府机会权威、 形象和企业收益造成不好影响, 利用她们主观主动性克制拖沓工作作风。假如项目经理在这方面没有太多措施时候, 能够让市场人员动用部分商业运作手段, 或者提请企业高层出面与用户方高层尽早沟通, 明确系统运行各项工作。
　　还有一个情况就是用户无穷尽地提出部分需求, 部分关键领导对系统指指点点, 随便一句话, 就要进行需求变更, 项目范围不停扩大, 造成项目试运行一直无法结束。甚至部分用户追求系统完美, 提出了很多高难度需求, 造成我们需要投入较多精力去处理。
　　这种情况, 我认为是部分政府主管领导对电子政务认识上存在一定误区, 认为这么一个系统就应该能够处理全部问题。其实信息系统只是政府管理工作一个辅助性手段, 信息化不是一步到位工程, 而是一个长久、 不停改善系统工程。我们应该想法让她们结合实际情况, 提出她们真正需要处理问题, 而不是依靠她们长官意志, 提出部分不切合实际、 易变需求。要实现这一点, 就需要项目经理安排人员定时到政府机关进行信息化普及培训以及项目管理知识培训。同时在适宜情况下, 提议在该项目验收后开启新项目来完成部分新需求。
　　项目验收对任何一个项目管理者都是一个极大挑战, 即使已经采取本文提到多个手段, 也不能确保我们项目能够顺利验收, 但作为项目承建方, 我们所能做到就是尽可能做好我们所能控制事情, 另外部分极难由我们控制事情则需要借用部分其它力量去完成, 比如请市场部利用部分商业手段来促成项目验收等等。本文中提出这些提议, 是期望能够起到抛砖引玉效果, 期望各位同仁能够提出更多愈加好方法来促进我们项目准期验收。