软件开发项目管控实施方案

软件开发项目管控实施方案我做软件开发项目管理快六年了，前前后后经手过十几个大小项目，见过太多本来前景不错的项目，因为管控松散，最后落得延期交付、预算超支、团队怨声载道的下场。我自己也在这上面栽过不小的跟头，所以结合这么多年踩坑踩出来的经验，整理了这套可落地的软件开发项目管控实施方案，目的就是让项目从启动到交付全流程都可控，既降低项目风险，也减少团队不必要的内耗。接下来我从方案背景、实施细则、保障措施几个方面具体说明。1方案实施背景与总体目标1.1实施背景我们公司之前接软件开发项目，大多走“接需求-拍脑袋排期-闷头开发-延期救火”的老路子，我几年前带的那个企业内部管理系统项目，就是典型的反面例子。当初我们急着签单，跟客户只口头约定了大概需求就开工，开发过程中客户今天加一个自定义报表功能，明天改一个多级审批流程，我们当时没明确的管控规则，抹不开面子拒绝，客户说改就改，最后原定三个半月交付的项目，硬生生做了五个半月才上线，预算超了40%不说，团队连续加班一个多月，好几个人私下跟我提说扛不住想调整，客户最后还因为我们延期不满意，真的是两边不讨好。项目复盘的时候，所有人都一致认为，问题根源就是没有一套清晰明确的项目管控规则，全靠项目经理个人盯着，难免有顾不到的地方，所以我们才出台了这套统一的管控实施方案，适用于我们公司所有大小软件开发项目，不管是几万块的小工具还是上百万的定制系统，都按这套规则走。1.2总体目标我们推行这套管控方案，核心目标有四个，说起来也很实在：第一是把项目工期偏差控制在10%以内，避免大面积延期，打乱公司整体的项目排期；第二是把项目成本控制在预算浮动范围内，杜绝无意义的成本浪费，保证项目的合理利润；第三是保障交付质量，让上线后的严重级别bug率降到千分之五以下，不给后续运维和客户留下烂摊子；第四是减少团队无意义的内耗和加班，让项目推进更顺畅，维护好团队的工作状态。说句掏心窝子的话，管控不是为了卡着大家，是为了把规则说在前面，让大家不用糊里糊涂背锅，这也是我做这个方案最核心的初衷。2项目全生命周期管控实施细则讲完背景和目标，接下来就是方案最核心的部分，也就是项目从启动到交付全流程的管控实施细则，我们按项目推进顺序拆解，每个环节都有明确的管控要求，一步一步推进不会乱。2.1项目启动阶段管控启动阶段是整个项目的基础，基础打不好，后面怎么管都白搭，我现在哪怕项目再急，启动阶段的流程也不会省。2.1.1需求边界管控启动阶段第一件事就是锁死需求边界，具体操作就是，先由产品经理对接客户，整理出完整的需求文档，把每个功能的逻辑、交互、验收标准都写的明明白白，不能有“大概做一个类似某某的功能”这种模糊描述。然后拉上客户方负责人、产品、开发组长、测试组长、项目经理一起开需求评审会，一条一条过需求，同时给需求分优先级：P0是必须在本次交付完成的核心需求，P1是可以放在后续迭代优化的非核心需求，P2是可以远期规划的需求。所有参会人员都要签字确认需求文档和优先级划分，凡是没有写进本次P0需求池的内容，一律不允许在开发阶段随便加进来，后续要加必须走变更流程。我之前就是不好意思在前期跟客户掰扯清楚需求边界，结果后面给自己挖了大坑，现在我哪怕多花一两天在需求评审上，也绝对不会把模糊的需求带进开发阶段。2.1.2资源配置管控需求定完之后，就要根据项目的规模和难度配置对应资源，人力上，核心业务模块一定要分配给有同类型项目经验的资深开发，非核心的边缘功能可以安排新人锻炼，既保证了核心进度质量，也给了新人成长空间，不会出现大材小用浪费人力，或者小材大用扛不住任务的问题；预算上，我们会按需求核算出基础成本之后，额外预留10%到15%的浮动预算，专门应对后续可能出现的需求变更和突发问题，不会把预算卡的太死；工具上，提前统一好所有人要用的协作工具、代码版本管理工具、测试管理工具，所有人都按统一规范来，避免出现各人用各人的工具，最后对接的时候格式不兼容、找不到文件的问题。2.2项目开发执行阶段管控启动阶段把基础工作都做扎实，接下来进入开发执行阶段，这一阶段是管控的核心，要盯紧细节，随时纠偏，不能放鸭子。2.2.1进度拆解管控我们现在不用那种一口气排好几个月的大计划，那样太粗了，很容易失控，我们都是按两周一个迭代做拆分，每个迭代要完成的需求，再拆解成一个个独立的小任务，每个任务都明确负责人和交付时间，最小的任务不会超过三天，这样进度不会模糊，谁拖了后腿一眼就能看出来。每天早上开十分钟的站会，每个人只说三件事：昨天完成了什么，今天要做什么，遇到了什么解决不了的问题。我作为项目经理会把所有问题记下来，当天协调资源解决，绝对不会把问题攒着。我之前吃过亏，就是一个开发遇到第三方接口对接的问题，不好意思说，自己闷头卡了一周，等到我查进度的时候才发现，一下子把整个项目的进度都拖慢了，所以现在这种每日同步真的不是形式主义，能把很多小问题消灭在萌芽状态。2.2.2需求变更管控这应该是所有软件开发项目最头疼的问题，我们现在定死了规则：不管是客户提的变更，还是我们内部提的变更，都必须先填正式的变更申请单，写清楚变更的内容、为什么要变、会对现有进度和成本造成什么影响，然后提交给客户方负责人和我方项目经理共同审批，审批通过之后，才能调整项目计划，如果变更影响比较大，增加了很多工作量，就要和客户重新协商调整工期和预算，绝对不会允许随便插需求。很多人说这样会不会太生硬，得罪客户？我不这么看，我前期把规则说清楚，客户也会理解，毕竟你改需求就要加钱加时间，天经地义，总比最后项目做砸了，大家都不满意要好。2.2.3开发质量管控我们一直信奉质量是做出来的，不是测出来的，所以每一步都卡质量，开发写完一个模块，首先要自己按验收标准自测，自测通过才能提交测试，不然打回去重新改；核心模块开发完，必须组织资深开发做代码评审，检查代码的规范性、可维护性，有没有潜在的bug，避免留下技术债务，到后期改都改不了；测试环节，每天同步bug清单，严重级别影响核心流程的bug，必须在三个工作日内改完，不允许拖着，每周我都会拉着开发和测试过一次bug闭环情况，确保bug不堆积。我之前遇到过一个项目，核心模块没做代码评审，开发离职之后，上线出了问题，接手的人翻代码完全摸不着头脑，整整改了两周，差点把项目搞黄，从那之后代码评审这一步我从来都不松。2.2.4内外沟通管控对内我们除了每日站会，每周五下午开一次周会，同步整体进度，梳理本周遇到的问题，调整下周计划；对外我们每两周给客户发一份书面的进度简报，告诉客户我们做到哪了，遇到了什么问题，接下来计划做什么，如果有延期风险提前跟客户说，取得客户的理解。我之前就是怕客户担心，进度出了问题瞒着，等到快交付了才说，结果客户更加生气，觉得我们不诚信，现在提前沟通，反而大部分客户都能理解，配合我们调整计划。2.3项目上线收尾阶段管控开发阶段完成之后，到了上线收尾阶段，这最后一步也不能掉以轻心，不然前面做得再好，最后一步出问题也会前功尽弃。2.3.1预验收管控正式上线前一周，我们会组织客户做预验收，按照之前签字确认的需求清单，一条一条核对功能，有不符合要求的地方当场记录，要求开发在上线前修改完成，预验收通过之后，才能走正式上线流程，避免带着问题上线，给客户造成不好的体验，也减少后续返工的麻烦。2.3.2上线后过渡管控正式上线后的前两周是问题高发期，我们会安排开发和测试轮流值守，客户遇到问题保证两小时内响应，八小时内给出解决方案，同时我们会把整理好的项目文档、操作手册、部署说明、常见问题清单一并交接给运维和客户方的对接人员，所有内容都写的清清楚楚，不会留下糊涂账，接手的人一看就能明白。2.3.3项目复盘总结项目正式交付之后，我们一定会抽半天时间开复盘会，不管项目做的好还是不好，都要总结，哪些地方管控到位了，起到了好效果，哪些地方还有漏洞，下次怎么改，复盘出来的经验教训都会整理到我们的项目管控知识库里面，后面的新项目都可以参考。我一直觉得，踩坑不可怕，可怕的是同一个坑踩好几次，复盘就是帮我们避免重复踩坑的最好方法。3方案落地保障措施全流程的管控规则定好了，还要有对应的保障措施，才能让方案落得下去，不然就是一纸空文，没人当真。3.1权责与激励保障我们首先会明确项目每个角色的责任：项目经理对项目整体的进度、成本、交付结果负责，产品经理对需求的正确性、完整性负责，开发对代码质量和任务交付进度负责，测试对交付的质量负责，责任明确到个人，不会出了问题互相推诿。同时配套对应的激励机制，项目按时按质交付完成，会发专项的项目奖金，按每个人的贡献大小分配，做得多做得好的拿得多，做得不好的也会有对应的复盘总结和改进要求，充分调动大家的积极性，让大家愿意按规则做事，而不是觉得管控是麻烦事。3.2风险预警保障我们每个周都会梳理项目的潜在风险，比如核心开发可能要请假、第三方合作方的交付可能延期、客户那边对接人换了之类的，都会提前列出来，做好应对预案，比如提前安排后备开发熟悉核心模块，提前一周跟第三方对接催促进度，不会等风险变成实际问题了才手忙脚乱的救火。我常跟团队的小伙伴说，提前发现的风险都不是大风险，藏着掖着的风险才会变成大事故。3.3工具统一保障我们公司统一采购了协作工具、代码管理工具和测试管理工具，所有项目都必须用统一的工具，所有任务、进度、文档都存在统一的平台上，任何人都可以随时查看，既方便了管控，也避免了因为人员变动导致文档丢失的问题。之前我们试过大家各用各的工具，找个需求文档要找好几个人要，浪费好多时间，现在统一之后，效率提升了很多，也减少了很多不必要的沟通成本。方案总结总的来说，这套软件开发项目管控实施方案，不是我坐在办公室凭空想出来的，是我带着团队做了一个又一个项目，踩了一个又一个坑，一点点总结调整出来的。它的核心不是为了约束谁，也不是搞形式主义，而是把规则提