To B 解决方案型项目异地敏捷建设心得

本文是关于作者在 To B 项目敏捷开发的一点个人心得,希望能对处于相同环境的朋友提供一点参考,一起来文中看看 ~

通过尽早和不断交付有价值的软件满足客户需要—— 敏捷宣言。
笔者于 2015 年第一次接触敏捷开发且第一次碰触 Scrum,当时 scrum 的理念确实为笔者的打开了一扇开发的窗,但结合自身境遇,仔细分析后认定敏捷比较适合于做内部的产品,不适合做 ToB 解决方案型项目(以下简称 Tob 项目), 原因如下 :

  • 立场: Tob 项目甲乙双方关系为被服务与服务的关系,甲方希望最少成本做最多的事,节约成本,乙方希望项目可以利润最大化,提高收益。
  • 背景: ToB 项目甲方期初需要经历项目可行性研究、项目立项、项目评审等过程,前后需准备大量的描述材料,如果实施结果与预期目标偏差过大,会被审计组审计。同时,也会对项目申请人的能力产生质疑,因此客户的建设理念往往倾向于传统瀑布模式,注重交付成果的一致性。
  • 合同: ToB 项目以固定总价合同模式居多,固定总价合同前期就有明确的范围、进度、成本、交付成果等要求。
  • 观点: ToB 项目团队往往会由甲乙双方共同组成,双方背后都有不同的利益组织,因此观点比较复杂,针对共同目标双方患难与共,但同时又因各为其主,会在一些细节上产生分歧,尤其是在变更的时候,因为会涉及到成本、进度等要素,弄得每一次变更都像打架一样。
  • 倾注: ToB 项目建设往往由甲方业务方申请,IT 部门承建,受益人与负责人不为同一人,由于利益、职责不同,甲方负责人的投入热忱也不尽相同。

因此 ToB 解决方案型项目使用敏捷模式可谓如履薄冰,稍有不慎便有需求蔓延、影响交付的风险。
2018 年 1 月,笔者所在的公司承接了某地产龙头的云视频平台建设项目,该集团信息化事业部有着比较丰富的项目建设经验,本项目为总价合同模式,预计建设周期 9 个月,合同签定之初甲方项目总监就要求项目快速上线,尽早满足该集团业务诉求,优惠条件是项目组可以不用驻场开发(笔者所在公司与项目现场相隔千里)。
笔者权衡再三,与甲方约定项目采用敏捷开发模式,并且达成了 具体落地方法 ,具体如下:

一、架构职责

架构职责:由甲方项目总监、产品经理、乙方项目经理、产品经理、开发经理、测试经理组成项目核心团队。

  • 甲方项目总监: 负责甲方整体项目把控工作;
  • 甲方项目经理: 负责需求筛选,优先级排序,协调甲方技术、业务人员配合本项目建设等工作;
  • 乙方项目经理: 负责编写 WBS、编制项目计划、信息同步、风险跟踪等工作;
  • 乙方产品经理: 负责需求收集、梳理、分析、原型制作、需求确认、改进方案等工作;
  • 乙方技术经理: 负责构建系统架构、指导开发、外部接口对接、重点问题攻坚工作等工作;
  • 乙方测试经理: 负责组织测试规划、方案、用例、BUG 管理、培训等工作。

二、拆分阶段

拆分阶段:将原 9 个月的建设周期拆分成三个阶段,即每三个月一个大阶段,每阶段里再拆分成 3 个小迭代,每个小迭代均提供有价值的交付物。

  • 每个大阶段提前三周做需求收集、需求分析、需求排序等工作,规划好本阶段的工作内容,以及完成第一个小迭代的交互稿细化;
  • 每个小迭代前两周做需求收集、需求分析、需求排序、交互稿细化等工作;
  • 每个小迭代内如无特殊情况,不做项目变更;
  • 第一个阶段不做小迭代拆分(建设初期初始化的事情太多:如确定需求基线、整体架构设计、硬件资源、网络资源、域名、安全检查、各种评审以及新团队成员组建磨合等);

三、沟通模式

  • 沟通模式:现场会议、电话会议、IM、邮件等。
  • 项目周报:邮件形式面向项目组全体成员,每周一次。
  • 会议纪要:邮件形式面向项目组与会人员及双方领导,每次会议。
  • 阶段成果确认:邮件形式面向对应负责人及双方领导,每阶段。
  • 乙方内部敏捷沟通模式:站会、周会、回顾会。
  • 各大阶段前两周,甲乙双方当面交流,一般交流周期为一周(很重要!)。

四、需求范围

需求范围:以需求规格说明书为需求基线,并辅以需求变更单.

  • 以需求规格说明书为需求基线;
  • 需求收集、需求分析、需求排序阶段甲乙双方共同参与,并达成共识;
  • 统一思想,拥抱变更,重点强调本项目会有较多变更,大家心里上一定要认同这一点,当出现变更时,双方一同分析变更影响(含工作量、工期、建设节奏等),达成共识后,迅速对变更需求给予确认;

在双方达成共识的基础上,该项目基本按即定计划执行,项目整体提前 1 个月,即用时 8 个月建设完成,在完成的同时也整理一下 个人的心得。

  • 互信: 互信非常重要,本项目由于分小迭代上线,在对最终用户需求做出及时反馈的同时,项目组也面对着大量的变更,是否符合变更,变更工作量多少均达成共识,虽然大家是为一个项目服务,但背后利益群体不同,达成互信非常不易;
  • 互助: 本项目在建设的过程中除遇到变更外,因甲方客观情况需要,曾尝试过双周迭代,项目组很好的满足了甲方高层级的业务需求,双方的友谊更进了一步;
  • 互补: 甲方项目经理出身产品设计,本项目中兼了甲方产品经理和甲方项目经理两个职务,由于项目管理经验和技术能力相对薄弱,项目组会对该项目经理给予一定的帮助,一同面对项目中的问题,帮助其快速成长,该项目经理成长后,在很大程度上对项目起了推动作用;
  • 迅速确认: 由于本项目有大量的变更,为防止这些变更遗漏、事后无法追述等情况,在确定变更后,双方迅速确认;同时,阶段性成果也要迅速确认;
  • 节奏: 本项目直接参与建设人员平均人数为 30 人,峰值时达到 45 人左右,如何保障大团队能一直高效的工作,节奏很重要,项目组通过提前规划需求、提前出交互稿的形式,使大团队每轮迭代后均后新任务执行;
  • 不足: ToB 项目,尤其是首次合作的 ToB 项目,项目的约束条件会很多,干系人沟通渠道的很大,需要用大量的时间来识别及应对,而此时实现短期项目上线,进度风险特别大,本项目第一阶段就因沟通不够充分,导致延期上线一周。

最后,此次项目虽然通过敏捷的方式取得了成功,但个人总结 ToB 项目在总价合同的模式下,想要实现敏捷必须要具备以下几点要素:

  • 甲方 IT 建设的成熟度要高;
  • 双方理解并认同敏捷的模式;
  • 甲方会对本项目做出大量的建设投入;
  • 乙方项目经理要有很好的控场能力,并且对项目的走向有一定的前瞻能力。

以上为我在 To B 项目敏捷开发的一点个人心得,希望能对处于相同环境的朋友提供一点参考。
 
作者:王磊,就职于网易杭研项目管理部,担任交付项目管理职位,致力于团队的大客项目交付及流程持续优化。
@网易杭研项目管理(微信公众号:NetEasePM) 。