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

4 评论 11591 浏览 59 收藏 10 分钟

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

通过尽早和不断交付有价值的软件满足客户需要——敏捷宣言。

笔者于2015年第一次接触敏捷开发且第一次碰触Scrum,当时scrum的理念确实为笔者的打开了一扇开发的窗,但结合自身境遇,仔细分析后认定敏捷比较适合于做内部的产品,不适合做ToB解决方案型项目(以下简称Tob项目),原因如下

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

因此ToB解决方案型项目使用敏捷模式可谓如履薄冰,稍有不慎便有需求蔓延、影响交付的风险。

2018年1月,笔者所在的公司承接了某地产龙头的云视频平台建设项目,该集团信息化事业部有着比较丰富的项目建设经验,本项目为总价合同模式,预计建设周期9个月,合同签定之初甲方项目总监就要求项目快速上线,尽早满足该集团业务诉求,优惠条件是项目组可以不用驻场开发(笔者所在公司与项目现场相隔千里)。

笔者权衡再三,与甲方约定项目采用敏捷开发模式,并且达成了具体落地方法,具体如下:

一、架构职责

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

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

二、拆分阶段

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

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

三、沟通模式

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

四、需求范围

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

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

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

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

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

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

以上为我在To B 项目敏捷开发的一点个人心得,希望能对处于相同环境的朋友提供一点参考。

 

作者:王磊,就职于网易杭研项目管理部,担任交付项目管理职位,致力于团队的大客项目交付及流程持续优化。

本文由 @网易杭研项目管理(微信公众号:NetEasePM) 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 日企更坑爹

    回复
  2. 我现在经历的情况是更极端的,在长期项目中甲方和乙方同时经历了项目关键人员甚至直接负责人更迭,这会对双方合作带来非常痛苦的磨合期。这其实对双方其实都很有教育意义,有时候甲方企业会一味求快或是在项目初期寻求便捷省略了一些项目管理过程中的必要流程,相关的文档资料的整理和邮件沟通确认都有欠缺,这个时候经历人员更迭会导致磨合初期会有大量的盲区需要重新确认,这部分耗费的时间成本其实对双方来说都是比较难接受的

    来自浙江 回复
    1. 你这项目 坑呀,不好推进,苦逼

      来自北京 回复