某移动办公平台项目的敏捷实践反思

摘要：敏捷开发社区邀请到了小笠老师，和我们分享其参与的移动办公平台项目中 “大瀑布下的小敏捷” 实践经验。希望这些实操内容能给大家带来启发，助力敏捷开发更好落地。

一、项目背景

移动办公在多年以前已经成为企业数字化转型的重要组成，企业移动办公平台是通过技术手段打破传统办公的时空限制，通过连接人、数据、业务重构企业的运作模式，帮助企业在效率、成本、灵活性等方面形成竞争优势。
之前曾在一家集团企业实施过移动办公平台项目，这家企业此前的移动办公模式是选择通过微信公众号搭建的，大部分管理应用通过链接形式嵌入在微信公众号菜单。然而，随着企业的发展、业务的增多以及管理方式的完善，这种模式已经不能满足移动办公的需要，例如一些硬件接入、离线办公、系统集成方面存在明显局限。
在这样的背景下我司带着“产品+定制开发”的模式承接了该移动办公平台的实施交付。

二、项目目标

集团公司的移动办公平台是面向内部员工的统一服务入口。其短期目标是在三个月开发移动办公平台，搭建移动应用开放生态，整合考勤、审批、沟通、营销、人力等业务应用，这一目标得到了甲乙双方的共同认可。而公司实际的是想通过该移动平台，为集团公司建设一些大型移动应用，将其打造为公司的标杆客户。

三、实施过程

图1 大瀑布下的小敏捷

项目采用“大瀑布下的小敏捷”模式推进，融合“敏捷开发”与“瀑布开发”的优势。在整体规划设计结束之后进入各个版本的敏捷迭代。但是当项目上线之后，各种迭代计划就被打乱了：移动应用存在边用边发现新问题的情况，客户希望持续看到一些新的内容和新变化，各个业务部门看到移动应用的便利之后也开始疯狂提需求。公司考虑到以后长期的合作，默默接受了部分需求，导致产品迭代清单和版本更新计划屡次被打乱。

各种需求的无限增加，用户的实际需求反而未能得满足，项目的成本持续攀升，各个干系人怨声载道，项目和双方关系都陷入了岌岌可危的境地。

四、过程探索

在经过多次思考和各种撕逼、会议碰撞、借鉴其他公司的优秀经验之后，甲乙双方都正视了自己存在的问题，为实现后续规范合作作，双方开始制定相关的规范和流程。

4.1规范需求流程

图2 需求管理简化流程

敏捷开发强调“拥抱变化”，核心目的是通过短迭代、快反馈，响应那些能提升项目核心价值的合理变化，而非无差别接受所有需求。对于移动办公平台这类toB产品，必须基于用户痛点，理解用户真正的需求，坚决杜绝一些“临时想起”、“攀比式”、“无边界”的需求。

明确需求边界：组织甲乙双方产品经理、业务部门、数字化部门、共同梳理移动办公平台的核心功能范围，明确哪些属于核心需求，哪些属于拓展需求，哪些属于平台需求，哪些属于业务需求。对于非核心功能和非平台需求，将其列为后续可能的拓展方向，暂不纳入当前开发计划。
建立需求评估机制：成立由甲乙双方产品经理、开发负责人、项目经理组成的需求评估小组。对于新提出的需求，从与项目目标的契合度、开发成本、用户价值等方面进行评估打分，根据分数确定需求的优先级，仅允许高优先级需求进入需求资源池。

4.2规范迭代周期

表1 版本迭代计划

根据需求的紧急程度和排期要求，提前两周制定迭代内容，并将版本更新内容和计划同步给相关干系人。

每个迭代周期开始前，根据开发团队的人员配置和工作能力，确定该迭代能够承载的开发工作量。若有新的开发计划加入，必须从当前迭代计划中移除同等工作量的低优先级需求，以确保迭代周期和开发质量不受影响。

4.3规范工时流程

表2 工时评估

根据需求评估结果和迭代周期的安排，对每次版本更新涉及到的工时进行评估。在工时评估初期，由于开发人员技术能力存在差异、对需求复杂度的认同程度不同，导致工时评估工作一直拉扯。经过一段时间的磨合，甲乙双方对工时评估已经达成了一定的共识，例如H5应用开发，先对开发难度进行评估，再根据难度等级对开发人天进行评估，对于项目经理和产品经理这种持续投入的人员，按人月这种形式进行评估。

按月汇总工时，经甲乙双方项目经理确认后，同步至项目管理委员会，作为框架协议等文件附件，甲方会定期据此进行结算。

4.4加强沟通与反馈

强调“自组织团队”：甲乙双方共同组成项目团队，对于版本迭代过程中的产品问题和技术问题可以随时沟通，但对于需求的变动、计划方案变动，必须有专门的对接人，避免随意承诺甲方要求。

减少“不必要会议”：首先就是减少每日站会，考虑到两周一个迭代版本的时间较为紧张，项目经理在分配任务的时候一定要充分的规划及准备，明确原型产出、UI设计、封版等关键节点的时间。团队成员按照任务分配开展工作，仅在遇到问题或者进度滞后的情况，才会召开团队进行会议沟通。

其次就是减少日报、周报的撰写，任务分解到位后，项目经理对团队成员的工作内容已清晰掌握，无需让团队成员花费时间撰写重复、已知的工作内容。相反，项目经理需要定期和团队成员沟通，投入时间去思考并撰写日报和周报，向团队成员和甲乙双方公司领导报告项目情况。

增加“必要会议”：对于需求评审、设计方案确认、版本内容确认、工时评估等会议，必须严格执行，且重要干系人务必到位。为提高会议效率，相关材料一定要提前准备好，并且提前和相关干系人通气，确保会上能够做出决策，会后及时通过邮件确认。

轻量化文档：与传统开发中“文档先行”（如动辄数百页的需求规格说明书）不同，敏捷更强调“可运行的软件胜过完备的文档”。文档仅保留核心内容，避免过度文档消耗精力，撰写文档力求“简洁”，阅读文档力求“能懂”。

项目过程中的文档越简单越好，但是项目经理要做好文档的归档工作，对每个版本中的所有文档都要分类整理好，同时了解甲乙双方PMO的管理要求，避免项目整体验收时再补文档的情况。

强调确认过程：对于需求确认、版本内容确认、工时确认，逆序进行邮件确认；若版本内容较大，需进行会审签字。

项目过程公开：联合甲方在禅道上创建项目，项目的所有需求、计划、版本内容、功能分工均在禅道上进行公开，根据人员职能进行权限划分。干系人对于公开内容有异议时，可以随时找项目经理沟通。

持续反馈：每个迭代结束后，项目经理跟踪用户反馈、测试数据、业务覆盖情况，进行复盘总结，为下一轮迭代提供依据，这种“开发-反馈-优化”的闭环，能确保项目始终向“解决实际问题”的方向演进。

五、项目成果

该项目的实践揭示了敏捷开发在大型客户、复杂项目中的挑战与机遇。本项目不仅验证了混合开发模式的可行性，更通过规范化流程与精细化运营，为行业提供了“敏捷落地”的范本，项目的合作模式得到了甲乙双方的认可，甲方也把这种合作模式推广到与更多的供应商合作中。

经过一年多的跌宕起伏，甲乙双方精诚合作，互利互赢，我司在甲方的年度供应商大会中获得了金牌供应商的荣誉。公司将该项目树立为标杆产品，一方面将项目中的优质需求反哺公司产品中，另一边也以该客户为标杆向更多客户推广。

疫情之后，移动办公已经作为企业数字化转型的基础配置和刚需载体，同时也催生了更多的移动创新应用，我们与集团企业的合作也得以进一步深化。