外部协作项目的极限拉扯到底怎么样?

“上周肝考试,这周肝项目”——2023.9

一周肝了 3 个外部协同项目,A项目 涉及到 3 方三角拉扯,B、C 项目分别涉及一个外部相关方拉扯。先说结果:A项目顺利进入测试、B 项目达到上线准备、C 项目捞底明确了问题清单进入外部协作方处理阶段。

A 项目涉及 3 方最为复杂,任意2 方都有协同对接任务,作为业务方 除了主导自己成员和外部 1 、外部 2 的对接,关键还得全程操心外部 1、外部 2 他们之间的协调沟通。明确核心逻辑,甄别关键任务,这当然是作为“串串”角色必须具备和秉持的。焦躁的表象下无非是各个相关方的不确定。这个过程惊奇的发现,基本的关键信息串联、看前后文,原来也是稀缺的基本功🤫更别提目标驱动了。舍我其谁?每每遇到这种情况,就有“让我来”的冲动行为。

B 项目、C 项目作为单一外部协作方,自然简单不过,简单的做法就是完全确保给他们正确的指令执行就好,心情好一些的时候科普一下场景,时间闲的无聊也可以给他们指导建议。

回顾学生时代、职场的一些经历,经历外部协作绝不算少,或许是这些经历、或许是不愿牵强,遇到极限拉扯总想拨茧抽丝一探究竟,找到真相、穿越迷雾。

清楚记得当年初入职场第一个工作任务,嗯…对,就是“任务”,boss让我和一个办公室老师一起接待工程勘察队员(工程人估计要会心一笑),个个肚子跟怀孕似的,带着他们大夏天白天一起钻玉米地,晚上一起去洗浴中心 happy。作为业主方角色,后续经典的工程5方关系拉扯不断上演。

后端有一段短暂的经历是当年酒店线上大战时,携程、艺龙、去哪儿、美团,都在搞酒店,去哪儿势头资本市场势头正猛,城市BD的角色就是要独立完成客户拓展/拜访/签约/拍摄/产品包装上线/销售跟进/产品优化,那会儿已经是996,今天啥时候来、晚上啥时候走就欧啦。这当中最拉扯的当然是酒店旅馆小老板儿,房价要拉扯、房型要拉扯、能不能多给签几种销售方式也要拉扯,最高兴的是第一次陌拜就签了一家满贯合作的酒店。

第二段时间较长职场经历中,用一张脑图协调过全公司近100人参与筹备举办产品发布会(参会规模在近千人);一个人3个月跑4个城市驱动集团5家分子公司对标ERP实施规范;为了做细颗粒数据支撑管理和业务升维,联合筹备外部研发系统,内部和财务销售产品各部门拉扯,外部和乙方公司的产品研发测试甚至boss拉扯;这都还不算当时负责范围的各种外部厂商拉扯的(硬件的、软件的、服务的)…

大学也协调过全班几十个人,从学校骑车一路狂飙几十里到黄河边野外烧烤,炭——校门口烧烤摊让人老板帮订的、锅——一东北大姐火锅店借的、碗筷——都自己家伙事儿、肉/菜/馍/饮/油/料/刷——拉几个同伙逛附近菜超买的、串串——分给男女生宿舍晚上自己洗菜切菜穿芊的、自行车——自己的/借的/一拖一的/租的、灶台——黄河边石头摆的。狂奔几十公里,导航也没有,逢人就问路,可就是开心啊!四月春风草长、红花绿柳,一群傻二青年欢快的摆灶、生火、烤制、碰杯、爬树,比拼烤技、互相换吃,悬河边跑着打闹…

很多时候,我们经历了到了更远的地方,便也不会再纠结脚下的路。

对于极限拉扯无非几个关键点:

1、搞清楚自己的目标、大家的目标是什么,是不是一致的

2、搞清楚每个参与方的驱动来自于什么

3、识别关键路径、把握核心信息链路、用好关键人

4、进程中甄别关键任务、挖掘关键信息

5、带领/影响成员,穿越风险迷雾区,实现目标

聊聊产品迭代范围的管理

范围即标的,是一个迭代冲刺的目标。围绕冲刺目标,通常会有匹配的:时间窗口、前后端开发资源、测试资源、运维资源、业务资源,同时会有匹配的协同系统协同处理方案、应急处理方案。当然,背后依赖的还有整个产品roadmap,再往底层其实是商业和战略规划。

 

范围的控制不论从风险、时间、团队信心哪个角度来说都是很有必要的事情(这里不谈绝对,比如突发的bug,不修复就要挂了,那没的说绝对是重要且紧急且马上就得做)。

1、风险控制:一个想要插队的需求,如果要做,不仅是开发、测试资源日历的问题。同时需要评估和既有范围的耦合度,其本身的相关方系统、业务有哪些,明确出来需求的地图边界在哪里。前面是进行风险的识别、评估,同时必须准备风险的应对措施,如果因为插队需求问题导致的诸如需要紧急

修复、回滚等,对原迭代范围的应急方案是什么?最坏的结果,如果发生了之后,还需要去做的就是持续的关注监控,避免次生的业务和系统问题发生,比如:系统和业务不一致导致的无效数据。关于风险,因为团队内分工的不同,会存在不同岗位角色的信息差,这里最好要有开发、测试、产品、项目、业务协同进行上述风险的预判过程;


2、时间:世上不如意之事十之八九,项目管理、产品迭代又何尝不是如此。人员请假、线上问题、bug暴露、老板需求都会挤压既定的时间规划。尽管我们在做迭代评审后,项目成员都会自己评估绝对的工作量,标记自己的deadline。尽管每个人都或多或少预留了一些buff,但是通常结果是,开发的交付、测试交付基本都会达到整个范围的deadline。不能说是团队成员效率问题,或许是deadline的标的成为了大家心理的一种暗示。所以范围蔓延通常意味着时间的不可控概率大幅度上涨。


3、团队信心:一次冲刺对于每个成员来说都是整装待发重新出发的一段旅程。大家有清晰的里程碑、有清晰的目标,过程中不断的持续交付并按照节点推进,最终达成一次交付。这感觉一定程度是可以刺激人的慢性多巴胺的,让成员充满信心、并拥有成就感和责任感;无控制的范围蔓延,会打乱成员的节奏,引起团队信心的打击,团队信心就像nba2k里球员的自信值,对于投篮命中率具有牛皮的加成效果。

每个产品经理成长过程中一定遇到过,加法的过程,我们想把一些小不点搭顺风车。不乏遇到由于评估偏差导致连累正常的范围。搭顺风车其实是件小事,但是需要背后评估分析的却是一套严谨的方法体系。

iSpiik快记131:数字驱动下,不可或缺的内心驱动

数字化的进程提供了各式各样的产品,2b 2c 2g… 为组织数字化提供了有力支撑,这也促进了组织内部SMART原则下的目标拆解落地:具体的、可衡量、可实现、现实的、有时限。很少再见到:工作态度良好5分、优秀10分这种了,一个人一个岗位被抽象为一串串可以代表的数字

“你再怎么可观地设计绩效体系,这个体系都无法真正地与你追求的目标画上等号,在这种情况下绩效体系越量化,越容易将团队成员带入追求绩效的数字游戏上,而忽视了真正的目标”

字节据说采用的OKR,所有人都可以看到leader的下个月下个季度的重点是什么,然后每个人都可以为此对标行为是不是可以帮助实现团队目标,你甚至可以看到张一鸣接下来的主要任务,大家想办法去靠近。另外,飞书在内部作用可见一斑。

这样看来,每个组织都是有一个叫做“团队/公司”的产品,做出来产品,给社会输出价值,也获取交换的价值。

iSpiik快记130:组织知识管理

接着之前的会议OKris_3zzz再挖挖,很多人都痛恨传统的、低效的、不靠谱的会议,我叫它为“断点会议”,事前事中事后不连贯。

一个靠谱的会议,事前应有所准备:物料、方案、人员、时间、地点、初步check等;事中有内容的输出和协作沉淀;事后有任务和知识转化;

从数字化角度看(参考图片)以#钉钉#  之类协同OA为例,依托组织在线可以把会议的事前触达(即时通讯及日程)、事中内容协作/沉淀(智能文档)、事后知识转化(云课堂)、任务协同(群任务看板或三方协同看板)全部在线完成;

同时转化的知识可以形成组织智慧,沉淀到#云课堂#  ,流转进入到培训模块,参与到学习路径地图中。【再结合之前关于学习路径的分享OKris_3zzz快哉】

iSpiik快记129:路标的过程管理

接着这条路标及分解说OKris_3zzz

产品路标规划,跟咱里程碑说的本质差不多。

这个应用有很多变种,比如在薪酬体系中:路标设置有年度目标、季度目标、月度目标,年度目标是一个核算周期,这个周期内拆解为季度、月度目标,为了结果达成设置过程把控节点,过程的节点落地到基层KPI,过程锚点设置激励机制,过程中可能有起有落,但是核算周期没有结束之前都保持有搬回全局的可能性,这样就让team可以保持冲刺的姿态尽可能触达周期标的,不至于中途放弃,同时提供了中途回顾及修正的检查点。

产品实现/运营过程,其实一样可以参考上面思路,按照路径把握合适的划分粒度之后,形成延续的脉冲式前进。#ispiik小站#

iSpiik快记124:做一个feature前的思考

纯银V微博分享过关于做一个feature前的思考:
“比如说,我们做一个 feature 之前,先搞清楚三件事:
1、目的到底是什么?抠细一点,再细一点
2、有那些统计数据可以证明这个目的?
3、发版之后,你的数据预期是什么?
把这三点搞明白之后,这个 feature 的优先级,值得投入的研发成本,经常自然而然就浮出水面了。如果预判过于乐观,最后达不到数据预期怎么办?你需要公开复盘,总结经验,修正下一次的数据预期。”

此3条可以是对我们在哪儿、我们去哪儿的清晰的定位,然后feature就是我们怎么去?当然涵盖了想清楚、做不做、做多少、怎么做。

标的建立精准坐标、为什么要去那里、如何衡量完成度,原则其实就是具体的、可实现、相关、可衡量、有时间周期的SMART原则,至少得是个逻辑自洽的闭环。

iSpiik快记123:图片这套做产品怎么样?

(外部因素+内部因素)*使命愿景,确定出来标的(产品概念图);

接着是产品路径规划(产品路径地图),组队,目标分解,过程把控(这里可能是N个小螺旋);

创造用户价值(群众是产品的用户、员工是组织的用户)、产品价值、商业价值。 ​​​​

部分个人作品文件概览

名称《**生活电商业务逻辑图》
链接https://www.processon.com/view/link/5e731d78e4b027d999bb11a6
描述生活电商项目产品业务逻辑图(仓储、物流、配送、运营、客服、售后)
名称《**云系统与实际业务流 融合逻辑图》
链接https://www.processon.com/view/link/5bc6d014e4b0bd4db96778ae
描述**系统功能逻辑、客户按职能泳道的业务逻辑图,融合展示。
名称《**公司业务流程图》
链接https://www.processon.com/view/link/5c4d74b5e4b08a7683b67711
描述公司维度的业务流程拆解。
名称《旅游生态业务流程概览》
链接https://www.processon.com/view/link/5c2d7f75e4b048f108bf9e7d
描述旅业上下游业务概览(资源方/目的地公司/客源地公司/分销端/游客)
名称KOBE,See You Again!
链接https://org.modao.cc/app/151f9256f88f8c656314f3e0eb38a7a07d1dc276?simulator_type=device&sticky
描述See You Again.

iSpiik快记105:解构/建构vs需求/设计评审

产品实现中有2个节点很有意思,“需求评审”是你完成了现实的解构,要摆出来拿着放大镜🔍给别人看,你找到了真实的世界的真相,想到了到达那里的路径,进行了建构描绘。

“设计评审”更像是数字建构,用数字去勾勒将要组成的虚拟世界。