6

车路协同&智能网联项目落地“十心法”

 1 year ago
source link: https://www.woshipm.com/zhichang/5765778.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

在做项目过程中,我们常常会遇到各种各样的问题,不仅仅需要管事情,还需要管理好人的问题。作者结合自己做的车路协同&智能网联的项目经验,与你谈谈在项目落地过程中需要注意的一些事情。

QHHeBl5SICHnQyP3PyiS.jpg

从南到北,从沈阳到广西,从东到西,从山东到甘肃,车路协同&智能网联的项目也做了几个,写点这过程中的心得体会,聊以自慰,全当记录~

01 预期管理

项目开始时,我们要先解决“人”的问题。

如何让众多的利益相关方,不同的团队,部门上级、项目负责人,乃至大老板,在项目推进中能够“可控”,能够目标一致,甚至欢天喜地的配合你完成项目上线。

做好“预期管理”。

最开始时作为产品经理只关心自己负责的业务部分如何更快的上线,至多关心自己的上级及团队,不太会想到项目里的其他团队。

但角色上调之后,开始逐渐关心整个项目的落地如何更丝滑,如何让所有人“满意”,要对不同的角色,实行不同的预期管理。

针对产品部门领导,要如实告知产品的能力范围和边界,90%对上解决方案和售前,必须承认他们的嘴太厉害了,我们要给他们收一收,你给他们收80%,他们能给客户吹成100%,所以要给自己和团队留个buffer。

过程中给自己团队80%的交付满意度,产品质量定120%的目标。

02 降低人效的预期

兵马未动,粮草先行。开始之前总得先盘一盘这摊子活需要多少人力投入。

预估人力资源,会决定投入多少人力成本,项目是否能保证不延期,这里有个问题,把人从办公室拉到现场,人效是正常办公的多少?

我的感觉是 75%。

搞过车路协同项目落地的都知道,这个过程链路太长。大面上来说,车、路、云是不同的团队负责,拿路侧来说,路侧设备的电路、灯杆、挂臂、顶管、相机、雷达等设备需要普通工人顶管架线,需要协调城市管理部门安装灯杆、挂臂,需要运维团队对设备激活,维护、需要技术团队标定相机雷达、需要研发团队跑算法,分析性能等等。

此外现场还会有你意想不到的各种问题,外部依赖项比如:顶管设备坏了,频繁下雨,市领导检查不让施工了,沟通上的效率也会低很多。

远不如办公室来一嗓子。我在天南他在地北,再加上信号不好,说半天都是 啥,啥,啥。

为了避免对人力效率的错误评估,导致项目的延期,建议默认每个人的效率是75%。

03 任务包拆解到人

这也是自己吃过的很大的一个亏,项目开始时就一个人在现场上蹿下跳,脚不离地,心里还有种指点他人的怪癖爽感,但下来冷静往回看,其实很多事情都没跟到位,很多临时决策也并不是最优解。

因此核心事项、关键任务包一定要有具体负责人,项目尤其是现场要盯紧的环节太多了,每个环节都应有负责人。

这样每个节点都有关键人来负责,更多跟关键节点的人汇总消息,降低沟通成本,更能降低出错的成本。

另外全链路需要1-2个人来熟悉整个项目概况,能给自己找个替身。

相信我,这个动作一定要做,你不是每天都要盯现场,不是每个决策都需要你下,要给自己抽身出来的机会。

04 尽早确定版本边界

在项目交付中,要给交付方明确的版本概念,交付的版本号是一方面,另外还代表着这个项目交付的软硬件系统能力边界,尽可能前置明确、对齐好系统能力范围。

不要到现场了或邻近交付了再来过多的增调需求,不可否认车路协同项目确实很难做到不改需求,但作为产品经理应负责在过程中逐渐与大家对齐产品最终效果,并敢于控制迭代节奏,敢于说不,那些不重要的需求要敢于后置,要控制版本的边界和迭代节奏。

05 注意现场“好奇宝宝”

虽然不会总用恶意来揣度别人,但多一些防备总是好的。项目进场后你会发现真的有很多双眼睛在盯着你,看你的进展,学习你的流程和实施情况。

对一家公司的产品方案,行业人一打眼,问两个关键问题也就大概知道了七七八八。另外这个市场现在都在互相学习,一家的项目落地肯定是有多个同行在学习探底。

一家公司的交付标准及能力,是需要保密的,但竞争对手的窥私欲是没办法制止的,

现场一般会做3个动作:工牌表明身份,留意闲散人员,建立信息保密机制。

就举个简单的例子,你在现场跟技术讨论项目卡点及解决方案,结果转身在抖音看到了这段视频,还有很多免费小心心,嗯,你说多崩溃。

另外我们希望别人看到的,是我们希望他们看到的那些。这里涉及的信息分发,舆情的控制,不应被不受管理的发出去,不然就需要太大的解释成本了。

06 有效问题反馈机制

在现场需要充分“放权”或是能有效收集民意,这些声音都将是收获。

搞过项目落地的,一定懂“墨菲定律”的痛,觉得不会出问题的,一定会出问题。

很需要提前把这些问题暴露出来,尽可能压低风险造成的影响。

鼓励大家多对项目发表意见,要能有效收集汇总,并给到问题提出者反馈!

见微,知晓项目一线风险、需要哪些资源,觉得不OK的事情,哪些是阻碍项、哪些需要协调

能够根据这些问题提前评估依赖项,要么多要资源,要么提前爆出风险,且应对现场发现的问题找到的解决技巧或tips,留存记录。

鼓励大家写SOP,并沉淀成项目经验。

07 解决问题要结果

给判断。应明确问题出现反馈时,要附上自己的判断依据。

2小时原则。2小时不能自行解决,则需要暴露出来,让问题升级或协调资源。

鼓励补位。每个人多做一点,每个部门多承担一点,产品可以测试,运维也可以配合现场抓日志。

专项团队。支持组建现场小组,快速专项攻破难点问题,并表扬出来。有时候现场的人真的只是缺这句鼓励。

08 消息同步机制

在项目一线,每个人都在忙自己的任务事项,这时候一定要关注消息同步的及时性和到达率,能不能通知到每一位人,什么样的消息该同步给谁。

什么样的消息同步:需求变更,时间调整,任务优先级变更。

要怎么同步:建议建立三个群:负责人群,项目组大群及核心事项群

这里涉及到2点,不同的内容在不同的群里同步。每个人对于信息的消化不一样,需要经过翻译处理后再给到自己下游,举个🌰,我们要临时对交付内容做一个修改,这种修改是向善的且有价值的,但可能具体执行层的人只看到了要改,不清楚这样改的好处。

就很容易让团队里的人挑战或质疑,潜在影响产出。

09 对于工作节奏的把控

前松后紧,还是前紧后松,还是一个节奏走完全程?

真正搞过落地的,心里应该只有一个答案:不管前边紧不紧,越到交付越紧。

越往后各种意想不到的问题越会出现,前边埋的雷也该被趟出来了,结合实际来看,我们能做的一件事是:让项目能尽早正向的滚动起来,到后期最影响节奏的是定位-跟进-解决问题,尽可能降低问题复现的成本,很多现场的问题就是偶现,等统一反馈了,环境变了也很难复现,反而是给现场埋了雷,提升问题解决效率,现场的人一般都是一人多岗,很容易由于其他任务导致这个问题就卡在这里。

10 决策权要逐步收口

前期鼓励每个人来发言发现问题,越往后时间、交付越紧张,信息越来越透明,更需要人来拍版;越临近项目,整个项目的进度和风险更加透明化和保证已知。

因为我们要开始准备向外输出的工作了,准备跟解决方案,售前的同事合作来应对第三方和监理的验收,这时候要保证大家知道系统的能力边界在哪里,别砸了。

越往后,每个决定就需要承担越来越多的风险和责任,敢拍板的人也会越来越少。

那谁来拍版那,原则上是谁负责,谁拍版。

过程中的几点感受~

要相信团队。没有人可以面面俱到,没有人。要相信团队里的每个人,团队是可以互相支撑的。

要学会求助。不一定要所有事情自己扛,学会跟老板跟同事求助,磨合磨合才会更好。

凡事尽可能简单。要拥有超凡化简的能力,先盯紧目标,先想全局实现路径。

要有自己的坚持和节奏。要有自己的坚持和节奏,要有自己的坚持和节奏。

本文由 @张广岐^_^ 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

给作者打赏,鼓励TA抓紧创作!

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK