软件公司流程化管理实施方案

上传人:卷*** 文档编号:138304494 上传时间:2022-08-20 格式:DOC 页数:17 大小:128.50KB
收藏 版权申诉 举报 下载
软件公司流程化管理实施方案_第1页
第1页 / 共17页
软件公司流程化管理实施方案_第2页
第2页 / 共17页
软件公司流程化管理实施方案_第3页
第3页 / 共17页
资源描述:

《软件公司流程化管理实施方案》由会员分享,可在线阅读,更多相关《软件公司流程化管理实施方案(17页珍藏版)》请在装配图网上搜索。

1、软件公司流程化管理实施方案版本/状态作者参与者起止日期备注V0.22014.1.262014.1.28首次创建目 录第 1 章 整体流程11.1 整体流程概述11.2 关键环节及主要主体1第 2 章 关键主体组成及职责32.1 市场销售32.2 设计团队32.3 评审委员会32.4 开发团队32.5 业务需求方3第 3 章 关键环节43.1 组建项目设计团队43.2 制定整体推进计划43.3 需求调研及成果确认53.4 需求分析及功能设计63.5 需求设计评审73.6 组建项目开发团队83.7 制定详细开发计划83.8 系统功能开发实现93.9 系统测试及功能完善103.10 用户培训103.

2、11 系统实施113.12 运维支撑113.13 系统验收11第 4 章 其他事宜124.1 风险控制124.2 退出机制124.3 保障条件134.3.1 资源保障134.3.2 制度保障134.3.3 技术保障134.3.4 后勤保障13第 1 章 整体流程1.1 整体流程概述为改进公司流程控制方式,提高项目管控效率,适应环境变化,特草拟新的流程控制方案,仅供参考。流程可整体归结为如下三步:1、 市场销售部门同客户签订合同;2、 设计团队进行需求调研及开发设计;3、 开发团队对设计进行实现,同时配合测试,并完成系统实施、验收等相关工作。各关键环节及主要主体干系如1.2所述。1.2 关键环节

3、及主要主体各环节及主体干系如下图所示环节主体干系图第 2 章 关键主体组成及职责2.1 市场销售主要负责市场拓展,主要工作包括投标应标、合同签订、客户关系维护等。2.2 设计团队人员组成主要由项目经理及固定人员组成主要职责是将用户的业务需求转换为抽象的系统功能设计,并将工作成果转交由开发团队执行,起到承前启后的关键作用。2.3 评审委员会项目设计结束后,需由评审委员会对设计成果进行内部评审,评审委员会的人员组成为:l 销售负责人l 设计团队负责人及全部设计执行人l 项目经理l 甲方项目负责人(外部评审时参与)评审通过后,即可将设计成果转交开发团队开展项目开发工作。2.4 开发团队开发团队是系统

4、功能实现的主体,项目技术水平层次搭配合理的开发团队对项目开发效率的提高起到极大作用,也对产品的质量的保障。2.5 业务需求方业务需求方授权负责人员,主要对项目的推进计划、需求调研、用户测试、培训组织、实施协调等方面进行协助确认。第 3 章 关键环节3.1 组建项目设计团队项目合同签订后,即可着手启动项目设计团队的组建工作,此项工作由项目销售负责人向公司领导申请发起。项目设计团队的工作非常重要,担负着将用户业务需求转化为系统抽象实现的重任,承担着整个项目工作承前启后的角色,因此,在组建设计团队时应充分考虑各种因素,仔细甄选人员组成。根据公司实际情况,设计团队应是一个动态构成的组织,随着项目性质的

5、不同,设计团队的组成人员也不尽相同(主要是项目经理的变化)。因此项目合同签订后首要的就是确定项目经理,项目经理加上设计团队的其他固定人员即组成对应项目的实际设计团队。1、 项目设计团队组织构成建议如下负责人员:张敏成员组成:固定人员有王宏远、王乃青、冯德福,变动人员为相关项目的项目经理。2、 主要职责项目合同签订后(也可视实际情况,经公司领导同意后提前执行),即转入项目实施的前期准备工作,主要包括:l 制定项目整体推进计划l 业务需求调研及确认l 需求分析及功能设计l 参与业务需求调研成果的外部评审l 参与项目开发设计的内部评审3.2 制定整体推进计划项目经理制定整体推进计划,并与业务需求方沟

6、通确认。整体推进计划应至少包括如下内容:l 业务需求调研安排及双方人员组成l 调研成果(用户需求说明书?)的最终确定截止日(需有用户参与评审)l 需求分析进度安排(需有用户参与评审)l 功能设计进度安排(一般包括概要设计、详细设计,可视项目具体情况而定)l 功能编码实现起止日起l 内部联调测试日期安排l 用户测试日期安排l 测试问题功能完善起止日期l 回归测试日期安排(视具体情况,与用户沟通是否参加)l 系统培训、实施、试运行日期安排l 系统运维支撑安排l 项目验收时间安排另外,为了掌握项目推进工作的主动性,提高工作执行效率,保证项目质量,在条件允许的情况下,相关计划项应分别制定对内(公司内部

7、)、对外(面向客户)两套计划方案。“对内计划”较“对外计划”应至少有20%30%的提前量(具体量值可视实际情况而定)。3.3 需求调研及成果确认正式调研前,项目经理应先与业务需求方沟通确认如下问题:1、 确定双方授权联系人及调研参与人我方人员建议由项目经理和设计团队主要设计人员参加;需求方建议由信息部门负责人员牵头、业务干系人协助。2、 确定调研方式需求调研的一般方式如下:方式1、会议讨论确定需求;方式2、现场观摩学习,发现、聆听、引导需求;方式3、方式1+方式2。同需求方沟通,确认调研的方式,做好可能的应对准备。3、 约定调研范围,确定提纲及计划首先约定调研范围,然后确定调研提纲,根据调研的

8、范围及提纲,预估工作量,拟定双方认可的计划安排,调研时严格按照计划执行。4、 确定需要提交的成果文档5、 约定定期沟通机制如定期会议、邮件等方式,及时确认已调研内容的正确性等,尽量减少信息失真、避免理解偏差。6、 约定需求变更的限度控制及确认方式调研期间的可控需求变更记录即可,可不必签字确认;但调研成果确认后再发生的需求变更,无论是否可控都应由需求方确认(书面签字?邮件确认?);对于非可控的重大变更,应有销售负责人参与沟通(可能会牵涉到合同需求及金额条款的修订等)。除以上须确认问题之外,调研之前还应着重提高项目团队(与项目相关的所有人员)的业务知识和专业素养。可先通过阅读招标、投标、合同等文档

9、,对标的业务有个大概的了解,然后再有的放矢的主动学习,为后期的调研(至少客户不认为我们傻)、开发(至少知道自己在做什么而不像机器人那样机械)做好业务知识的储备工作。以上问题解决之后,即可按照约定的计划开展项目调研工作。开展调研时应工作细心(一个不经意的细节,有可能是隐含着巨大的需求变量,也可能是重要的设计参照)、态度诚恳、条例清晰、把握主动(只有主动控制局面,才不至于需求调研主线的偏离)。除此之外,调研时还应注意以适当的方式引导、培养用户习惯。用户习惯(即使是坏习惯)一旦形成就会有很强的惯性,而且很难再次被改变(哪怕是好习惯)。因此,调研时应从项目预期功能出发对用户习惯加以引导或培养,营造利于

10、后期工作开展的心理环境(也有利于后期的测试及验收的顺利进行)。3.4 需求分析及功能设计调研结果确认后,即可对项目进行需求分析及功能设,并最终形成系统开发设计说明书(概要设计、详细设计等),开展此项工作时应遵循如下原则:1、 功能易用性与技术可控性相平衡的原则开展此项工作时,在满足用户需求的前提下,应遵循功能易用与技术可控相平衡原则。即在功能设计时应充分考虑具体实现的技术复杂度问题,不应盲目追求技术的先进性,而应重点考虑系统的可维护性、可扩展性2、 系统功能模块化分解的原则用户需求转换为具体的实现抽象时,应先对整体功能进行梳理、分析、归类,形成相对独立的若干逻辑单元,然后分别设计,并确定相互之

11、间的依赖关系,为模块化的开发打好基础。3、 关键功能及核心流程尽量细化设计的原则系统功能具体设计前,应首先甄别关键功能点及其之间的逻辑关系,并重点对此细化设计。为保证后期开发工作的质量,对于核心流程,应采用图示、描述(尽量细化到伪代码级别)相结合的方式详细阐述。4、 设计成果选择性确认的原则考虑到对设计成果的保护,只需将需求分析与客户确认即可(合同有特殊约定除外)。5、 应有开发团队主要负责人参与为了与项目开发工作无缝对接,应有项目主要技术负责人参与需求分析及功能设计工作。3.5 需求设计评审需求分析及功能设计完成后,应及时评审工作。先进行公司内部评审,评审内容包括需求分析、概要设计、详细设计

12、等;然后再进行有客户参与的外部评审,平射内容主要是需求分析或概要设计部分。评审的目的是为了保证对业务需求理解的正确及合理性,减少理解差异性。通过评审促使各方对业务需求理解保持一致,为后期工作大好基础。此项工作应尽量安排测试负责人参与,是测试者提前对需求有个大概的认识,为后期测试工作的开展大好基础。3.6 组建项目开发团队开发团队人员结构和规模层次主要取决于项目需求规模情况及公司现状,比较适合我公司的团队组建模式可有主程序员制和层次结构制。主程序员制,即由经验丰富、技术精通的高级工程师作为项目负责人直接带领开发人员执行开发工作。这种模式人员关系简单,一般适用于比较小的项目。层次结构制,即开发团队

13、由若干职能小组组成,各小组由项目经理统一管理,项目经理对项目负总责。这种模式层次清晰,各组职责分明,一般适用于较大型的项目。不管采用哪种模式,开发团队的结构都大致由如几部分组成:l 项目经理l 合理搭配的初、中、高级工程师(条件允许的情况下按此搭配)l 项目测试、实施、支撑等工作的预期人员l 后勤保障人员以上人员组成分工明确,各有侧重,可视实际情况动态适当调整。具体工作安排可采用双人互备模式(即每项功能都双人安排,单人负责,互为备份),降低人员流动风险。团队内部各人员之间应建立良好的互动关系,开发实施过程中遇到问题应及时沟通、充分协作;不但分内工作要及时保质完成,对别人的遇到的困难也应积极帮助

14、。项目经理对团队工作负总责,及时协调各方资源解决遇到的问题,保证以保证开发工作的顺利完成。开发团队组建后,应首先对其进行相关的业务及技术培训,使之对将要执行的工作有个感性认识后再具体开发,做到有的放矢。3.7 制定详细开发计划综合考虑项目性质、总体进度要求、公司资源现状等因素,制订切合实际、易于执行、便于追溯、方便考核的项目详细开发计划。1、 开发周期开发周期以项目整体推进计划(对内计划)为依据,结束时间不迟于推进计划所规定的交付时间,开始时间可以早于推进计划所拟定的编码启动时间。2、 功能模块首先,应涵盖需求设计文档中列举的所有功能;其次,应包含相关隐含功能,如核心流程公用方法可作为单独的功

15、能列出。3、 优先顺序应充分考虑个功能模块之间的逻辑依赖关系,使功能开发的顺序安排更加科学合理。总体顺序可以是“基础数据整理-公用方法-核心流程-查询及报表-辅助功能”,具体安排可视项目具体情况而定。4、 时间粒度时间进度控制采取长期、短期相结合的方式,即计划中应包含各时间周期的任务安排:总体进度(开发时间截止点)、各阶段性进度(可以里程碑事件为标准划分)、月或周进度等应有所体现。5、 自由灵活在保证里程碑事件完成的基础上,开发人员可自己安排详细计划。对于工作日计划,除有特别要求外,一般可由开发人员自主安排(即以分配的每周总任务为依据,根据自身情况进行安排)3.8 系统功能开发实现1、 编码前

16、的准备工作实施编码之前,应事先定义相关编码规范及要求、目录结构层次、变量定义规则、方法及类的命名规则、程序备注说明要求等。应以业界标准为参照,结合项目特点制订通俗易懂、易于维护的规则。2、 关键功能重点关注项目的关键功能、核心流程及公用方法应分配给经验丰富的资深工程师开发,以保证程序的稳定性。3、 基础数据及开发环境项目相关的基础数据可提前先行梳理及配置,同时系统开发环境(开发框架、个人开发环境等)也应提前准备,以便开发工作的顺利开展。;4、 做好单元测试工作根据公司实际情况,专门组织的测试工作要有阶段性成果时才能组织,而开发过程中的单元测试则属开发人员开发工作的一部分,在编码的同时做好单元测

17、试工作,发现问题及时完善,开发、测试交叉进行,保证开发质量。5、 做好开发进度管控开发人员应严格按照开发计划执行,项目经理做好进度管控,可通过如下方式进行:主动巡查收集信息,定期工作报告,常规进度检查,重大问题会议商讨等。3.9 系统测试及功能完善1、 单元测试单元测试由开发人员开发时自主完成。2、 内部联调测试联调测试的目的是验证各模块功能正确性、模块间数据及控制流是否按照预先设计方法实现、系统整体功能正确性等。测试之前应先编写测试方案,规定测试要求。在适当把握测试粒度的基础上,测试要求尽量细致,测试结束后应生成测试报告,作为功能完善的依据。3、 用户业务测试条件许可时,参与测试的业务人员应

18、包含使用系统的各个角色人员。测试过程中相关开发人员应和业务人员加强沟通、注意引导、培养用户习惯。4、 测试问题修正测试中测试到的问题,应先梳理分类,小问题及时修改,大问题修改时应考虑系统整体型,不能各自为政。5、 回归测试测试问题修正后,及时进行回归测试,验证问题修改的正确情况。3.10 用户培训1、 制定培训计划2、 确定培训预期(希望达到的效果)3、 确定培训方式4、 师资培训5、 操作普训6、 技术培训3.11 系统实施系统实施前,须先制定应急预案和实施方案。1、 应急预案应制定应急预案,主要包含一旦实施失败的应急行动。2、 实施方案制定详细的实施步骤,内容应包含实施执行步骤、执行人员、

19、监察人员等,如条件允许,正式实施前应先进行模拟实施。3.12 运维支撑略3.13 系统验收略第 4 章 其他事宜4.1 风险控制在整个项目执行环节中,越靠前的风险危害越大,越应及时控制、解决。1、 风险因素控制l 需求分析阶段主要风险因素有目标不清,范围不明,用户参与或沟通程度不充分,对业务或需求了解不够,未做可行性分析等。l 功能设计阶段主要风险因素有需求分析结果自身缺陷,设计队伍经验少,需求变更无法控制,功能遗漏等。l 编码实现阶段主要风险有开发环境不完善,设计错误,自身能力不足,功能范围或进度计划改变,人员变动,内部沟通不充分,无有效的备份方案和测试计划及测试人员经验不足等。l 收尾阶段

20、风险收尾风险有设备到货延误或质量不达标,升级复杂或扩展性差,超支或资金无法回收等。2、 预警制度建立项目实施过程中应建立相关的风险预警机制,一旦发现有不可控的风险因素,应及时给分管领导进行风险预警。4.2 退出机制为充分利用人力资源,在项目实施过程中,团队成员的组成及推出是一个动态过程,并无具体时间节点,项目进行到某个环节,都有可能有退出的人员,如主要功能开发完毕后,可退出一部分开发人员;项目实施后,可退出大部分开发人员及测试人员;验收后只需保留1-2个日常运维人员即可(可由初级工程师担当)。4.3 保障条件4.3.1 资源保障l 人力资源保障项目实施过程中应有人力资源的保证,事先确定的项目组不应随意调换或调离,以保证项目组的稳定。l 财物资源保障包含开发活动费用及相关设备资源等。4.3.2 制度保障应建立是相关激励措施,制定绩效评定标准严格执行鼓励互帮互助,特定项目薪酬计划。4.3.3 技术保障略4.3.4 后勤保障略

展开阅读全文
温馨提示:
1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
2: 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
3.本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们

copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!