软件外包服务管控管理制度

软件外包服务管控管理制度为了规范公司软件外包服务全流程管理，规避外包项目常见的需求混乱、质量不合格、信息安全泄露等风险，保障外包项目质量、进度与成本符合公司预期，同时维护供需双方的合理权益，结合我司多年外包项目合作的实际经验，制定本制度。本制度适用于公司所有对外发包的软件定制开发、软件运维、技术人力外包等各类软件相关外包服务项目，所有涉及软件外包的业务部门、技术部门、财务部门、采购部门都需要严格遵守。以下从各个环节逐一明确管控要求。1总则1.1制定目的我在软件项目管理这行做了快十年，见过太多软件外包项目的遗憾：业务部门提需求模糊不清，供应商做完货不对板，两边吵到扯进纠纷；供应商资质造假，核心团队半路接手项目又跑路，项目烂尾没人接；因为保密没做到位，公司用户数据泄露，赔了一大笔钱还坏了品牌名声。说白了，很多问题不是供应商存心坑人，也不是我们这边故意挑事，就是一开始没有清晰的管控规则，大家对边界的认知不一样，最后矛盾越攒越多。制定这个制度，核心目的就是把全流程的规则说透，把权责划清楚，从源头到结尾把风险控住，既保障公司的项目利益，也让合作的供应商清楚要求，不用摸瞎干活，最终实现双赢，不是为了卡谁，是为了大家都能顺顺利利把项目做成。1.2适用范围本制度适用于公司所有类型的软件外包服务，包括但不限于定制化软件项目开发、现有软件系统的运维升级、专项技术开发服务、驻场技术人力外包等，不管项目金额大小，只要是对外发包的软件相关服务，都得按这个制度走，小项目也不能嫌麻烦跳过流程，好多小项目因为不管控最后出大问题的例子我见得太多了。1.3管控原则我们做外包管控遵循四个基本原则：第一是安全优先，任何时候信息安全、数据安全都要放在第一位，哪怕进度慢一点、成本高一点，也不能在安全上放水；第二是权责清晰，不管是我们这边还是供应商那边，每个环节谁负责什么都写得明明白白，不搞模糊地带；第三是全程管控，不是只选完供应商就不管了，从立项到验收再到售后，每个环节都盯紧，不能当甩手掌柜；第四是互利共赢，我们不会故意压供应商的价格，也不会提不合理的要求，只要供应商按要求交付，我们也按合同准时付款，大家一起赚钱把事情做好。讲完总则的基本要求，接下来我们从外包项目的第一个环节说起，也就是立项和供应商准入，这一步是源头，源头把好关，后面能少出百分之八十的问题。2外包立项与供应商准入管控2.1外包需求立项审批2.1.1需求梳理确认所有软件外包项目，第一步必须由提出需求的业务部门完成完整的需求梳理，不能拍脑袋说“我们要做一个商城小程序”就完事，必须写清楚项目的业务目标、需要实现的所有功能点、对接的现有内部系统、用户量级、性能要求、预期上线时间，哪怕是小功能修改，也要一条一条列出来，不能用“大概”“差不多”这种词。我之前碰到过业务部一个同事，跟供应商口头说要加一个“简单的统计功能”，结果供应商做出来的统计和业务想要的统计完全不是一回事，来回改了一个月，大家都一肚子火，所以需求写细是对所有人都好的事。2.1.2立项评估审批需求梳理完之后，业务部门先提交给技术部门评估，技术部门要评估这个项目能不能由公司内部团队完成，如果内部团队排不开工期、或者缺少对应的专项技术能力，再确认需要外包，然后财务部门根据需求评估项目预算，最后按预算金额走对应审批流程：预算低于一定标准的，由业务和技术负责人共同审批，预算高于标准的，必须提交公司管理层会议审批，审批通过之后才能启动供应商遴选，没有审批的项目不能私自启动外包，谁私自立项谁承担相关责任。2.2供应商准入与遴选2.2.1资质初审所有意向供应商都必须先过资质初审，需要提供营业执照、相关行业的软件服务资质、近年同类型项目案例、核心团队成员的技术背景、无不良信用记录证明，涉及到敏感数据交互的项目，还必须提供对应等级的信息安全服务资质。初审的时候要核实清楚，供应商报的案例是不是真的，我一般都会要求留一个之前客户的对接人联系方式，简单沟通两句合作情况，避免碰到那种拿别人案例吹牛的空壳供应商。2.2.2现场考察与技术测评初审过了之后，必须安排技术和项目负责人去供应商的办公场地现场看看，一来确认对方是不是真的有对应规模，不是那种两三个人打游击的皮包公司，二来要和对方即将参与项目的核心团队面对面沟通，针对我们的项目需求出一个初步的技术方案，现场做技术答辩，看看真实水平。我之前就栽过一次跟头，几年前有个供应商，网上资料做得特别好看，案例堆了一大堆，我们没去现场就定了合作，结果进场才发现，他们宣传的核心技术工程师早就离职了，接我们项目的都是刚毕业不到半年的新人，连基础的架构设计都搞不明白，最后只能解约重新找，耽误了三个月的工期，还亏了不少违约金，从那之后我就要求不管多小的项目，必须现场考察，这个流程省不得。2.2.3入库定级考察测评都合格的供应商，纳入公司合格供应商库，根据资质、技术能力、报价合理性分成A、B两个等级，A级是各方面都优秀、可以长期合作的供应商，以后有项目优先从A级里面选，还可以享受更灵活的付款条件；B级是初步合格、还需要进一步考察的供应商，小项目可以先合作试试水，积累合作记录后再调整等级。源头的立项和供应商选好了，接下来就是项目执行过程的管控，这一步是项目成败的关键，千万不能放手不管当甩手掌柜。3项目执行过程管控3.1合同签订与权责划分3.1.1合同条款细化所有外包项目必须签订正式的书面合同，合同里每一个条款都不能模糊，必须写清楚：项目需求范围、分阶段交付节点、每个节点的交付物要求、验收标准、付款节点、对应价格、变更规则、违约责任、保密条款、知识产权归属，尤其是验收标准和知识产权，这两个是最容易出纠纷的地方。验收标准必须一条一条对应需求列清楚，什么情况算合格，什么情况算不合格，不能只写“验收合格后付尾款”这种模糊的话；知识产权必须明确写清楚，项目完成后所有的源代码、设计文档、相关知识产权全部归我方所有，供应商不得保留、不得二次使用，我之前听说过同行的一件事，外包做完没写知识产权归属，结果供应商拿着源代码做成了产品卖给别的公司，还反过来告我们侵权，最后赔了几百万，这个教训一定要记牢。3.1.2双方权责明确合同签订后，我方必须指定专属的项目经理，全权负责需求对接、进度跟进、问题协调，只有这个项目经理确认的需求才算数，别的人随便提的需求供应商可以不用接，避免多头对接乱改需求，最后把项目改得面目全非。供应商那边也必须指定专属的项目负责人和固定的核心开发团队，核心开发人员中途要更换的，必须提前十五天向我方项目经理申请，经我方同意之后才能换，新人进场必须做好完整的工作交接，我方还要对新人做技术和安全考核，合格了才能上岗，避免随便换人导致项目衔接出问题。3.2需求变更管控我敢说，软件外包项目里九成的矛盾和超支，都来自不规范的需求变更，所以这个环节一定要把规则卡死。3.2.1变更申请要求不管是我方要改需求，还是供应商因为技术原因提出变更，所有变更都必须走正式的书面申请，申请里要写清楚变更的具体内容、变更的原因、变更对项目工期、预算的影响，没有书面申请的口头变更，一律不算数，供应商可以拒绝执行，我方也不会承认变更，不会多付费用，这个规矩一定要一开始就说清楚。3.2.2变更审批流程变更申请提交之后，先由我方项目经理和技术负责人评估变更对项目的影响，如果是小变更，不影响总工期和总预算，由项目经理和技术负责人共同审批就能生效；如果是大变更，影响超过原总工期的百分之十或者原总预算的百分之十，必须提交原立项审批部门重新审批，审批通过之后，双方签订补充变更协议，调整工期和预算，之后才能开始修改，绝对不允许先干活后补流程，很多时候就是大家觉得“都是合作朋友，先改再说”，最后改完了对价格和工期达不成一致，闹得不欢而散。3.3进度与质量管控3.3.1定期进度同步要求供应商必须每周出具正式的项目进度周报，说明本周完成的工作、下周计划、遇到的需要我方协调的问题，并且每周固定开一次线上或者线下的进度同步会，当面沟通清楚情况。如果供应商的实际进度比计划进度滞后超过七天，必须要求供应商出具书面的整改方案，说明滞后原因和赶工计划，滞后超过十五天的，就要按合同约定扣罚款项，严重的可以按合同约定终止合作。3.3.2分阶段质量检查质量管控绝对不能等到最后交付才检查，必须分阶段把关，需求分析完成后，要审核需求规格说明书对不对，有没有理解错我们的需求；架构设计完成后，要审核设计方案符不符合我们的技术要求，能不能满足未来的扩展需求；每个模块开发完成后，供应商先要自己做单元测试，然后提交我方测试团队做功能测试，测试合格了才能进入下一个模块的开发。我之前做过一个十几万的小项目，就是图省事，说等全部做完一起测，结果最后交付的时候发现底层架构根本不对，要改就得全部推翻，最后供应商赔了一半的钱，我们也耽误了工期，双方都受损失，所以分阶段检查真的太有必要了，麻烦这一点，后面省好多事。项目执行完了，接下来就是验收交付和售后运维的管控，这是项目收尾的关键环节，也不能放松。4验收交付与售后运维管控4.1交付验收管控4.1.1交付前置检查供应商申请验收之前，必须先把所有交付物准备齐全，包括完整的源代码、数据库设计文档、部署手册、用户操作手册、完整的测试报告，交付物不全的，我们不受理验收申请，避免验收完了缺东少西，后面维护都找不到资料。4.1.2分层验收流程验收分三步走，第一步由我方项目组做功能验收，对照合同和需求一条一条测，每一条符合要求才算过；第二步交给业务部门做实际试用，一般试用不少于十天，业务部门实际用下来没问题，才算过；第三步由我方技术安全团队做安全验收，扫描有没有安全漏洞，检查代码有没有预留后门，确认数据交互符合我们的安全要求。三步全部都通过了，所有参与验收的负责人签字确认，才算验收合格，只要有一步没过，就打回供应商整改，整改完重新验收。4.2收尾归档验收合格之后，我们才会支付合同约定的尾款，一般我们会留百分之十到十五的尾款作为质保金，验收合格满一年没有出大问题，再付清尾款，这样对我们有保障，也能约束供应商做好售后。所有项目过程中的需求文档、变更记录、会议纪要、交付物，全部都要整理归档到公司的知识库，方便后面维护升级的时候查用，不能做完项目资料就找不到了。4.3售后运维管控4.3.1运维责任明确合同里必须约定至少一年的免费运维质保期，质保期内，非我方原因导致的系统bug、运行故障，供应商必须免费维修，响应时间也必须写清楚，一般问题48小时内响应，严重影响使用的问题24小时内必须解决，超过响应时间不处理的，我们可以委托第三方维修，产生的费用从质保金里扣，不用提前跟供应商商量。4.3.2运维考核管理质保期结束之后，如果我们继续选择供应商做付费运维，每年都会对供应商的运维服务做考核，主要看响应速度、问题解决率、服务态度，考核不合格的，下一年就换服务商，不用碍于情面继续合作，毕竟我们要保障系统正常运行，不能因为人情影响业务。除了上面说的业务流程管控，信息安全和风险管控是现在软件外包里越来越重要的部分，绝对不能忽视。5信息安全与风险管理管控5.1信息安全管控5.1.1保密管理要求所有参与我们项目的供应商工作人员，都必须单独签订保密协议，承诺不泄露我方任何业务数据、用户信息、项目资料，项目过程中，所有数据都必须存放在我方指定的环境里，不能私自拷贝带走，不能把带我方数据的代码上传到公开的代码托管平台，我之前就碰到过供应商的开发人员图方便，把我们带测试数据的代码传到了公开代码平台，结果过了好久才被发现，差点造成用户数据泄露，想想都后怕，所以这个要求一定要卡死，谁违反谁承担全部责任。5.1.2权限管控我们给供应商开通的内部系统权限，严格遵循最小必要原则，就是只给他们完成工作需要的最低权限，项目结束之后，立刻回收所有权限，注销所有账号，绝对不能留权限尾巴，避免出问题。5.2风险管控5.2.1风险提前预判项目启动的时候，我方项目经理就要和供应商一起梳理项目可能存在的风险，比如核心人员离职、技术难点攻克不了、工期滞后，针对每个风险提前制定应对方案，比如预算里预留百分之十的应急预算，提前和备选供应商打好招呼，真出问题能快速接上。5.2.2风险及时处置项目过程中一旦发现风险，比如供应商进度严重滞后、核心人员离职不交接，要立刻启动应对方案，该整改整改，该换人参换人参，真的到了供应商做不下去的地步，要立刻终止合同，启动备选方案，把损失降到最低，不能拖着等着，越拖损失越大。所有项目完成后，我们还要对供应商做综合考核，形成管理闭环，不断优化我们的供应商队伍。6供应商考核与退出管理6.1项目综合考核每个外包项目验收完成后，我们都会从交付质量、工期符合性、配合度、服务质量四个维度给供应商打分，打分结果计入供应商档案，分数高的A级供应商，以后有项目优先合作，付款条件也可以适当放宽，分数不合格的供应商，直接降级，原本是B级的直接清退出库，一年内不再合作。6.2不合格供应商退出如果供应商出现严重违约，比如泄露我们的数据、交付严重不合格、恶意拖欠工期、有欺诈行为，直接清退出合格供应商库，永远不再合作，还要把相关情况记录在供应商档案里，避免后续再踩同样的坑。总而言之，本软件外包服