一、OMS项目过程
1、项目开展 — 项目规划
1）0-1阶段
① 确定项目最终目标
替换易仓&Saleforce(部分能力)
② 确定项目截止时间
2021年12月份（演变过程：2021.7——＞2021.8——＞2021.9——＞2021.12）
③ 确定项目阶段目标
a.2021年9月份完成独立站迁移
b.2021年12月份完成多渠道迁移
④ 项目开展前期
a.调研清楚业务现状系统现状
b.确定好未来系统规划与需求
c.明确好新的业务职责与流程&拉通业务达成一致
d.明确好新的系统定位与边界&拉通团队达成一致
e.制定项目阶段计划并实施
⑤ 项目开展中期
- 处于快速迭代阶段
- 把控项目整体进度与阶段进度
- 与领导&业务定期同步过程：同步已完成功能+下一步计划（有风险或者变动及时拉通）
OMS 项目计划-OSC
OMS 项目计划-OFS
OMS 项目计划-业务部门配合事项
2）1-N 阶段
PS：0-1过程中伴随着1-N
a.接受并消化所有业务需求
b.梳理并安排所有业务需求的整体优先级
c.与搭档分工（同步需求，输出方案思路，主要把控大方向，适度把控细节）
OMS 1-N 项目迭代计划安排
2、项目开展 — 工作优先级
项目目标大时间短、工作量相对超负荷的情况下，需先确定好工作优先级，按优先级开展工作推动项目。否则工作进展会受阻，项目可能会延期。那如何有序开展工作推动项目呢？大致分为以下四点：
① 查看整体计划
开展每日工作前，先查看项目整体计划。
② 确定当前阶段
根据项目整体计划确定当前所处阶段（双周迭代任务），从而确定当日做什么（今日任务）。
③ 处理自身需求
确定业务方——＞调研拉通——＞确定结论——＞输出方案——＞确认方案
④ 处理搭档需求
作为产品负责人，先调研确定需求大概——＞与搭档进行分工——＞同步需求背景/方案思路/相关改动程序——＞确定需求截止时间
PS：ToB产品在设计过程中更注重每个功能模块之间的衔接，也就是信息流如何形成闭环，在考虑某个模块的改动时，要多考虑是否对其他功能模块或者系统造成影响。所以针对每个需求，需整体闭环思考，将所有相关点都考虑在内，一起改动处理。
⑤ 处理问题
梳理问题（开发中问题、线上问题等）——＞确定问题优先级——＞按优先级逐一处理解决
3、项目开展 — PRD设计
在项目0-1阶段搭好需求文档基线：统一规范、字段、流程、方案，使其团队成员思路清晰认知一致，有助于后期迭代更新，是项目顺利开展以及后续迭代的核心。
OMS PRD-整体＞OSC＞OFS
① 确定系统公共规范
框定好公共规范，便于后续保持统一。
② 明确业务对象
明确业务对象名称及其含义，有助于上下游系统保持统一，方便产研同事与业务同事对系统的统一认知，有助于提供研发建表思路，比如创建地址表、商品表等。
③ 明确业务流程
明确业务流程、状态流转，有助于研发测试同事理解上下游业务、进行系统概要设计系统基础搭建等。
④ 按程序编写PRD
每一页PRD对应每一道程序。例如：当订单进入到系统生成系统单，从而有了相应的订单管理，接着进行商品匹配、分摊计算、库存占用等一系列程序。如下图所示：
OMS PRD-OSC 设计详情
这样的程序PRD设计，有助于产品及其整个团队成员对系统设计、PRD编写有一个清晰的认知，且后续若产生新需求或者发生新问题，定位到需处理的程序后，可以快速直接定位到相应的PRD里编写方案。
4、项目问题 — 系统设计
其实每个项目多少都会遇到一些问题，何况是0-1项目。以下列举一些典型案例。
① OSC的系统定位（替换系统、使用业务方、页面是否显示？）
问题：关于OSC定位，在一开始众说纷纭。它对应的替换系统是易仓还是Saleforce？使用业务方是哪个角色（运营 客服 仓储 物流）？是只需支持下单的服务平台还是外加供业务操作的后管平台？最终衍生出一个问题，是否需要建立后管页面？
解决：经过一系列讨论，OSC定位为提供创单接单能力，提供对客服务人员处理订单的能力。建立了后管页面，供对客服务人员快速筛选查看处理相关单据。
② OSC订单正向状态定义（成功、失败？）、拦截状态定义等
问题：关于OSC订单状态，在几个会议中争执不下，有表示要区分成功与失败的状态等。另外是否需要拦截状态，若需要，拦截状态如何回退等。
解决：最终确定订单状态只记录成功状态或者待执行状态，比如推送失败，那么状态仍处于待推送而不是推送失败，同时记录异常信息：异常类型为推送失败，异常原因为推送失败具体原因。基于订单行的拦截状态无法通过商品行的拦截状态进行汇总折中，则不记录拦截状态，只用订单状态进行流转即可。
③ OFS单据结构设计、系统流程设计、拆单&寻仓库物流的功能设计等
问题：在起初设计阶段，经协商确定设计履约单，与上游OSC的系统单一对一，在其寻完仓库物流后，生成相应的包裹单。其中基于履约单进行拆单——＞寻仓库物流的功能设计，让整个系统流程设计非常冗余。在独立站迁移上线后，问题爆发，业务纷纷反馈履约系统难以使用
解决：在项目第二阶段-多渠道迁移过程中推动解决了问题，针对OFS做了一系列改造，最终只剩包裹单，整个系统流程设计相对顺畅。
④ 各功能分别做在哪个系统（例如：预提报等）
问题：各功能分别做在哪个系统，说到底是系统定位问题、需求分析思路等。例如：预提报功能，一开始确定在做在OFS处理，后续希望整个环节做在TMS，那到底做在哪个系统合适？
解决：最终定位做在OFS，主要是依据整个业务流的配合、业务希望在一个系统看最终包裹信息等一系列的细节决定预提报做在OFS更合适。
⑤ 各问题分别是哪个系统处理（例如：地址截取问题）
问题：同样，各问题分别在哪个系统处理，说到底也是系统定位问题、需求分析角度维度等。例如：对地址进行统一截取（截取策略），是在TMS还是OFS OSC处理？
解决：这时需先思考这是国家维度还是服务商维度的收货信息限制标准，接着确定哪个系统承接合适。最终定位是国家维度的收货信息问题，另OSC需提供统一标准系统单，所以在OSC处理合适。
⑥ 与业务、团队内部、领导拉通过程中的设计分歧等
这一块感受颇深。因为0-1要做成什么样子，每个人都有个蓝图，所以整个项目过程中，不论是与业务团队还是产研团队的沟通中，分歧很多，对此进行了多轮沟通讨论。总体来说，处理方式可以说是上述第四点和第五点的结合。
5、项目问题 — 项目进展
① SM与PO职责不清（例如：迭代内容是SM定还是PO定）
问题：在项目起初迭代阶段，SM与PO的职责划分不清，不清楚整个迭代节奏迭代计划是SM定还是PO定。其中，SM（Scrum Master）偏向于提供更优技术方案、合理估算需求工作量，从而确定需求是否可以在一个迭代内完成。PO（Product Owner）偏向于清楚业务现状、项目规划、需求优先级、需求方案等，从而制定合理需求排期以便满足项目进展需求、业务使用需求。
解决：这类问题在项目过程中不断向上反馈，经多方多次拉通协调达成最终合作模式。基于项目0-1且时间紧迫的特殊性（通过项目目标+项目截止时间倒推迭代节奏迭代计划），基本是由PO决定安排，这时的PO是产品负责人+项目经理的角色。
② 因无上线要求，前期测试质量无法保证
问题：在项目第一阶段，两周为一个迭代，计划完成所有基本功能后，即几个月后，对外开放使用，这便易导致无上线要求使测试质量得不到保证。
解决：后期有了迭代上线要求，测试质量有所保障。
③ 需求评审经常推迟，需求评审时长过长
问题：需求评审原定在当前双周迭代的最后周五完成，以便接下来的双周迭代时间留给研发测试。结果需双休继续加班产出/完善方案，需求评审延至下双周迭代的开始周一，这导致迭代开发测试时间缩短，迭代节奏更为紧张。其中因需求调研需求方案设计过程中无时间与研发沟通拉通，开发测试过程中无时间处理零散问题，所以设计中尽可能将PRD写细，评审上尽可能将各种细节聊到聊透（包括每个字段定义来源作用等、每个功能后续发展等），导致需求评审时长过长。
解决：将项目管理时间产品调研设计等时间再压缩，提高处理能力，赶进度的同时仍保质量。
④ 产品研发过往的工作背景不一、对系统认知不一，沟通成本高，且易发生冲突
问题：新项目、新团队，每个人的工作背景不同、工作经历不同、对系统认知也不同，讨论问题与方案难免会产生一些分歧争执，甚至冲突，普遍需要经过多次沟通来达成一致。
解决：后续在评审开发前期针对接下来计划与方案多做团队内部沟通，以便在后面评审开发中减少冲突摩擦；对于不同看法想法多些耐心倾听与针对性地反馈，不要回避，即便是驳回，也要有理由地针对性地驳回。最终达成一致，相互间更为理解地接受新的观点与方案。
⑤ 业务方各自负责什么，业务流程是什么，在新系统上如何配合闭环
问题：该项目并非完全照搬替换的三方系统，需要在搭建过程中依据公司个性化的业务模式业务需求建立新的业务流，这涉及到新的业务职责划分、新的业务流程拉通、新的系统流程闭环设计等。
解决：项目本身相对不复杂，复杂的是人的不配合，复杂的是部门之间互相踢皮球，复杂的是职责边界模糊不清。以下方式仅供参考：
第一 对齐目标
想各部门所想所急。将项目中的事项与各部门的日常KPI指标对齐，能增加他们业绩指标的事项，他们不会拒绝。
第二 找对人
找到每个部门负责具体事务的小主管。既有执行力，又有大局观，又能调动其他下属配合做具体执行的工作。
第三 专业性
对所有部门应该做的事项要有专业性的同频。这样才能做到大家相互理解。积极推动项目。（宁愿自己累一点、多做一点，只要项目能如期推进就成。）
6、项目成果
① 2021年1月中旬至5月中旬
一个系统调研规划——＞功能设计——＞推翻——＞两个系统调研规划——＞建立数据字典——＞功能设计
② 2021年5月中旬至8月底
两周一个迭代——＞制定计划——＞调整计划——＞写方案——＞改方案——＞01N 狂干三个半月
③ 2021年9月15日
独立站切换完成，正式投入使用：首单成功出库并成功回传平台已发货
④ 2021年12月30日
多渠道切换完成，正式投入使用：灰度阶段已产生线上单走完全流程
PS：同期同步进行【OFS改造、亚马逊平台对接、用户融合项目等】
二、OMS项目总结
1、项目总结
围绕最终目标和截止时间有序开展项目，过程中兵来将挡水来土掩，遇到问题解决问题，减少内耗赶进度做成项目即可。经验细节如上所述，希望对你有所帮助。
网友评论