开发项目管理

经常听到软件委托方(甲方)项目管理人员抱怨:「不了解软件开发,但被长官指派为项目负责人,不得不为但实在不知道过程看不到摸不到的软件开案要如何管理?“项目管理”本身就是一门“软”学科,它有许多相同的管理理念,但还需要更多“管理”软技巧,才能让项目进行得更顺利与成功本文试着以简单的方式依项目发展时程让甲方了解如何进行软件项目管理。

第一招选最适合的厂商

用「男怕入错行,女怕嫁郎」来形容甲方的选乙方也不为过。甲方想要找一个合适的厂商来协助其开发软件项目,而乙方何尝也不是如此,希望找一个优良的客户,彼此可以配合,乙方希望所提供的方案可以协助甲方解决问题,而也可以从中获取合理的利润。

甲方在选商的过程可依自身组织的采购方式进行,但正因软件项目看不到,摸不着,非常依靠厂商的项目能力与人力,故在选商过程最忌讳采用「选最低价的厂商」的方式进行,而应该采「选最适合的厂商」的方式进行。

在遴选的初期需要准备预计委托项目的业务范围,使用人员范围,预计时程,安装地点,限制条件⋯等,让有趣兴的软件厂商对于欲委托的项目有一清楚的认识,以免双方因「误解而结合」,走向项目失败的第一步。在选商的过程中应有选商评分表,并组成评选小组,建立选商评估方式让选商得以较客观的进行,淢少因某人的意见而抹煞众人的意见。进行选商时可请厂商进行简报,展示等。评选小组也可对于厂商进行信誉评估,实际拜访厂商等,让选商的过程可以更全面更透明。

第二招各取所需没赚钱的生意没人要

在甲乙双方的软件委托案中,双方分别代表了自己所属的组织进行本案,在项目金额已固定的限制下,双方基于「各为其主」的心态,希望在合约的进行中获取最大的利益,因此在先天上彼此就有「对抗」的成份在,但软件项目却又是非常依赖双方的人力及能力知识,当双方议定项目范围,时程及委托价金时,即应将此「对抗」心态降到最低,而以「合作」取代。甲方项目管理人员需要了解让所负责的项目顺利的如期如质完成并顺利上线使用,才是项目的最大利益,而不是在项目过程中从乙方争取了多少合约外利益给自己的组织。甲方项目管理人员需要清楚的知道,乙方公司一定是一个将本求利的公司,若是项目不论长短期都没有利润,彼此的关系也不会维持的太久。

第三招专注成本,时间及范围

谈到「项目管理」,就必需要先了解项目有三个限制:成本(包含人力,设备,金钱等),时间及范围而这三个限制构成项目产出物的品质而这三个限制的变动会影响产出物的品质,换言之,若这三个限制有任一个变动又想维持原来的品质,那就需要改变其他两项。

或许有些甲方的项目管理人员会说:「 在我的经​​验中,即使要求了厂商一些合约外的项目,厂商仍然也如期的交付所约定的产出物」其实在要求了合约外的项目(范围的增加),乙方的项目施作团队为了维持产出物的品质,可能采取了投入更多的成本(投入更多的人力)或是投入更多的时间(项目成员加班)。也有可能采取降低品质,以满足原来成本及时间的限制。

因此,甲方对于项目同样会面临有三个限制,只是没有乙方那么明显与直接,这也表示甲方同要需要采取各种项目管理的方法以完成项目。

第四招定期的项目会议是必要的

甲方对于乙方项目经理所提出的项目计划,不要抱有厂商一定会作好的想法而不去理会其「项目计划」,应要仔细核对其工作项目及产出对比于合约的工作范围是否有遗漏?逐一检视乙方所安排的时程计划及所配合项目组织的人力及工作量,审视乙方项目经理在工作项目的人力分派计划是否合理可行。另在工作计划上常会遗漏甲方所需配合工作项目的工期需求,在项目进度计划时也需一并思考。

在项目进度计划中,最细的工作项目时作时程最好不要太长,大约是一到二周,甲方不一定每一最细的工作项目都需要检查乙方是否有达到,可以用抽查的方式,如此较可避免乙方时程有延迟时无法查觉,导致严重延迟无法挽回。

定期的项目会议是必要的。在会议中除可了解项目的进度,也可彼此协调双方应处理的事项,及追㾈双方上次会议待办事项,若项目执行有所偏差及问题时,也可在会议中进行讨寻求解决方案。

第五招需求确认与管理是最重要的

执行一个软件项目,无非是要解决甲方某一特定或是某些现在已存在或是未来会遇到的问题,而这些问题即是需求的根源,问题/需求应由该业务之负责单明白叙述,甲方应有固定的人选能叙述所想解决的问题及需求,若是有跨单位的业务流程问题,甲方更应有可整合的人选来统合不同单位之间的差异与矛盾切记不要。把不确定/不明确的需求丢给乙方项目,千万不要认为:「乙方是专业的,他们可以解决的」乙方是资讯的专业,但解决不了甲方部门间的需求矛盾或是需求的不确定性。

乙方资讯公司在软件开发时,都会要求需求确认,系统分析确认⋯等确认的工作项目,「确认」的工作是有必要的,用以沟通甲乙双方就需求的了解是否有偏差。甲方的管理人员应正面看待此要求,文件看不懂,可请乙方人员说明,在确认中一定要检查文件是否满足原来的需求。需求确认的确认需与需求提出为相同的人员。

甲方所面对外在的环境会改变或是人员的想法会改变,相对应要电脑化的资讯系统也会需要跟着改变,会改变是正常的,但不因会改变而认为:「反正会变,为何要确认?」。经确实确认的需求,设计等项目是处在彼此了解,结构稳固的状态,对于未来的发展是可期待的。而在「确认」后的改变就必需进行管理,每一改变都需评估对项目在成本,范围,时程,技术等的影响等,并取得到双方的同意,让原预计要发展的结构内容维持在一稳固的状态。

第六招测试脚本,测试小组也要量身订做

一般而言较负责的厂商会提供给甲方测试报告,甲方项目管理人员在开始进行测试前,可就两个面向先行检视,检视所设计开发的系统是否满足原先彼此所确认的规格,是否有所遗漏及不符处?检视乙方所提出的测试报告是否含盖了所要开发的功能?测试的顺序是否展现了甲方的业务流程顺序。

甲方在进行测试时,应组成测试小组,小组人员最好由原提出需求及确认需求的人员所组成,在测试之前应先准备测试脚本,若是厂商有提供脚本,可拿来参考,但切勿只用厂商所提供的脚本作为测试的脚本,以免测试的案例不足及偏颇。

在测试过程应详细记录通过与不通的功能,特别是不通过的功能应留下错误的佐证资料,以便厂商就错误问题进行修改。测试与错误修正一般而言不会重叠进行,而是以不重叠的方式交替进行,主要是为版本管理,让测试时是在一个稳定且明确的版本上进行。

若是乙方所提供的软件系统经多次测试与修改,在问题收敛到某一数量,双方觉得留下的问题已不严重,可以上线使用时,为确认原已测试过关的功能不因修改其他的问题有所影响,需要重新再测试一次。若是所开发系统会有比较多人同时上线使用,或是有系统反应速度的严格限制时,就有必需作压力测试,这类的压力测试,需要使用工具,工具及测试一般而言都由厂商提供,而测试的范围可选择作业比较频繁或是较重要的作业来进行,若是预算,时程允许也可以业务流程为范围,在流程会用到的功能均予以测试。除有特别原因,一般软件系统在正式上线使用前会进行平行作业,让新系统与现有系统或是人工系统平行作业一段时间并同时进行比对,以确保新系统上线时的正确性及稳定性。

一般而言软件系统很难作到找不到问题(错误),因此大概无法作到「没有问题,才验收的条件」,一般验收的最低门槛大概是:「需求规格范围内属业务流程内之作业都可正常运作无误」,当然一般衡量标是:?「该软件系统可上线使用了吗」另验收条件也要以合约规范来进行,若是合约规范不清,也可参考甲方组织内类似案件来进行。

第七招善用同业经验或是资讯单位协助

甲方项目管理人员在进行项目管理时,除可请教同事外,若是组织内有资讯单位,亦可请其协助提供支援,特别是在技术上。若是经费许可,项目有其必要性,也可寻求其他的资讯相关之管理顾问从第三者的角度协助进行项目管理。

结语

资讯软件本质上在未见到成果前较难以文字及图型说明,在执行过程中也较难清楚看到全貌,而工作与工作之间先后顺序的强制性又不如其他工程类项目强烈,施作过程全靠工程师人工所生产,因先天上的不同,软件项目管理也相对的复杂且难管理。要让资讯软件项目成功,甲乙双方的项目管理人员,不能只有「各为其主」更要互助合作才有可能成功。