那些年,我们在产品上趟过的坑

3 评论 5236 浏览 36 收藏 21 分钟

每位产品经理在处理需求和项目的路上,都会遇到无数的坑。在周而复始的挖坑和填坑的过程中,我们散落了青春,也迎来了成长。笔者梳理了一下曾经趟过的10个产品坑,相信总有一个命中你。

坑1:缺乏全局视角:上下游系统联动考虑不周

一个新的项目上线,往往会涉及到多个系统之间的联动,而产品经理经常会更加聚焦于新项目本身,而忽略了对外围系统的影响,导致上线后问题多多。

例子

A君负责的新WMS系统上线,在上线之前,内部所有功能均测试通过,结果上线以后发现ERP库存错乱了,因为库存的错乱,影响了财务账和线上销售。

排查原因才发现是临上线前,根据业务需求,调整了WMS的库存变更逻辑,而此变更并未及时通知ERP调整,导致上下游系统的库存处理机制产生了差异。

原计划1个月顺利切换的项目,因为此库存问题,后续不断修复改进,持续了半年之久,各部门痛苦不堪。

经验说

内部问题是最容易解决的,与外部系统的交互才是项目的关键。

涉及到不同的团队、不同的系统,产品经理一定要尽可能多的了解上下游业务系统,梳理方案时要多考虑上下游系统的关联性,要是涉及到上下游系统的改动,一定要提前与对方打招呼,安排好充裕的时间进行联调。

坑2:不贴合业务现场,闭门造车

有很多自认为很有经验的产品经理,接到需求后不与需求方充分沟通,更不实地考察,想当然的闭门造车,如果再碰到一个稀里糊涂的业务方,就有可能出现新需求上线后无法使用,严重的会导致现场停摆的情况发生。

例子

为节约成本,A君给库房设计了一套新的复核流程,将打印面单和清单的模块后置到复核环节。这本是一个很好的想法,可以为库房节省两到三个人力,同时提升了作业效率。

但新功能设计时并未考虑到现场的操作情况,导致上线后,打印机的打印速度跟不上现场复核的速度,每复核一单要等待6到8秒才能打印完成,然后才能进行打包,直接导致复核爆仓。

项目运行半天后,不得不回滚,损失惨重。

经验说

系统设计一定要与业务流程相结合,切忌闭门造车。只考虑系统实现,不关注实地操作,是很多产品经理特别是产品新人很容易踩的一个雷区。

往往系统流程是闭环了,但发现现场无法使用,所有的努力功亏一篑,所以在设计系统时,操作角色-操作流程-系统流程要紧密结合。

同时,大的流程改造,在上线前进行实地测试是非常必要的。

坑3:流程不闭环,忽视逆向和异常流程

在梳理业务流程时,正向流程的通畅,意味着项目成功了80%,但复杂点往往在于逆向流程和异常流程的处理。

如果逆向和异常没有处理好,流程就不是一个完整的闭环,一旦出现了,就会变成死节点,再也无法向下流转。

例子

A君为库房新上线了入库流程,改进后的流程从操作性和准确性方面均提升不少,得到了库房的一致好评。

但由于没有考虑到收货拒收,以及验收环节出现错误的修改流程,导致有一批收货无法进行日结,只得找技术从后台进行处理,项目上线效果大打折扣。

经验说

设计流程时,闭环是个基本原则,逆向和异常的处理流程可以设计的很简单,甚至人肉处理都行,但一定要考虑周全,否则如同定时炸弹一样,一旦情况出现了而无法处理,就是巨坑。

坑4:项目周期太长,计划赶不上变化

在互联网行业,计划永远赶不上变化。一些从传统行业做大项目过来的产品经理容易落入”大而全”的项目圈套中,追求极致,认为只有面面俱到,所有风险都考虑到位的项目才能上线。

殊不知,市场不等人,当系统做出来的那一刻,也许就已经过时了。

例子

A君接到公司指令,要求打造一套生鲜的O2O供应链系统,老板想借此整套解决方案进行业务推广和融资。

于是一行人浩浩荡荡设计了一个宏伟目标开始实施,种种原因,原计划3个月的工程持续了8个月的时间,好不容易项目上线,最佳融资机会却已经错过了,公司资金吃紧,项目组只能就地解散。

经验说

在市场尚不明朗的前提下,项目以MVP的形式推进无疑是成本最低的,先设计出最简单的模型来辅助业务进行试错,小步快跑、快速迭代,待模式清晰以后再加大投入。

当然,MVP不是要放弃系统建设,最基本的底层设计和流程闭环还是要充分考虑的

坑5:追求效率,缺乏体系化建设

项目周期不易过长,太过追求效率而不考虑未来也是大忌。做供应链类项目,要注重体系化建设,就像盖楼一样,如果根基不稳,盖得越高,风险就越大,如果长期如此,只会造成崩塌,酿成大患。

例子

A君受命搭建履约系统,原本规划的核心功能要3个月才能开发完成,但老板觉得时间太长,要求项目砍到2个月。

2个月以后,一个不完善的系统终于上线,A君本计划针对上线的隐患问题做一次架构升级,但新项目一个接一个,根本不给缓冲的时间,而且每一个项目都是要求尽快上线而不考虑扩展性建设。

直到有一天又来了一个大项目,A君评估后发现现有系统架构已无法再继续支撑,提出要重构,而老板不领情,认为是A君能力问题,A君无奈选择离职。

公司高层火速招了B君上岗,新官上任三把火,B君按以往经验评估此项目难度并不算大,于是在老板面前立下军令状,保证完成任务。

在梳理需求的过程中,方知系统最核心的履约模块都是千疮百孔,根本无法再往上添加新功能,于是悔不当初,只得在项目启动之前负罪离职,当了逃兵。

经验说

产品经理在系统搭建之初,一定要和架构师一起针对最核心的架构进行辨识和评估,就算项目周期再紧,基础建设也不能偷懒,否则后患无穷;

如果不能反向管理业务预期,最好使用二八法则,优先保证核心底层建设工作,针对非必要功能进行适当取舍。

坑6:目标不一致,项目多方不在同一高度对话

项目过程中,经常会遇到产品经理和业务、技术不在同一个维度对话,相互之间沟通半天如同对牛弹琴,了无结论。

更有甚者,大家以为达成了共识,实则各自理解相差甚远,导致项目效果达不到预期,身心俱疲。

例子

A君主导的中央库存系统终于上线,但上线以后由于业务的复杂性,很多场景考虑不周,导致库存计算不准,很多订单由于系统问题产生缺货无法下发库存生产。

A君找到负责的技术小B排查,一通操作以后,所有订单均正常流转到了库房,中央库存再无报错信息。

还没来得及高兴时,库房又爆出超卖问题,原因是很多订单下发库房以后,WMS没有实物库存无法定位生产。

A君再找小B,小B很淡定的解释道,中央库存增加了一个自动加库存机制,一旦发现无库存,就自动加100,保证订单能顺利下单并下发库房,如此也导致了某些订单的超卖。

A君大怒,但小B委屈的认为自己此举有效的解决线上卡单的问题,并不觉得自己错在哪里,也没有意识到超卖的严重性…..

经验说

遇到此类坑,产品经理需要搞清楚大家不在同一纬度对话的缘由,如果是大家概念不统一、需求理解不一致,产品经理最好能转变语气和沟通方式;

如果是某些技术同学心怀鬼胎想偷懒,揣着明白装糊涂,那就要上升到工作态度问题了;

如果大家一致认为已经达成了共识, 推荐使用复述承诺法,由技术同学对方案进行复述,大家一起指正,直到各方均不再有分歧为止。

坑7:需求管理不善,频繁的需求变更

很多时候,业务部门只有一个想法,刚开始这个想法并没有想的特别明白,于是提交过来一个模棱两可的需求,产品经理就基于自己的理解开始设计系统;

在项目过程中,业务诉求越来越清晰,却发现产品方案和自己的预期相去甚远,于是,需求变更在所难免。

如果产品经理不对过于频繁的需求变更进行有效管理,就会直接影响到系统设计和项目进展了。

例子

采购部基于资金压力考虑,需要做代发货业务,即由自营采购变为和经销商合作,由经销商代为发货。

项目开始之初,业务方要求以某些商品作为试点。A君以采购部的需求,设计了一套代发货系统,采购部确认方案无误。

但在系统开发过程中,公司高层又好几次冒出新的想法,要求扩大品类、扩大代发货范围,导致项目范围一再扩大,系统底层架构也跟着调整,无法按时交付,影响了业务的开展。

经验说

需求变更在所难免,但过于频繁的话,不仅影响系统设计,还会严重动摇项目组军心。

作为产品经理,一要学会拒绝,有困难时一定要学会say no;二要会分轻重缓急,评估变更带来的影响,如果确认影响重大,可以向上汇报,由高层之间商议决定项目延期,还是暂缓实施变更。

千万不要只报喜不报忧,等到项目出问题了再汇报,就为时晚矣。

坑8: 老板想法太多,一言堂

很多公司只有一个最大的产品产品经理,加上一群需求转化师,这名产品经理就是老板其人,普通产品经理们只能充当将老板的想法转换为产品文档的角色。

老板做产品经理不可怕,可怕的是老板想法太多,还朝令夕改,经常变。朝令夕改也不可怕,最可怕的是老板还一言堂,不接受挑战和建议。

例子

A君的老板最近心血来潮,经常晚上11点以后对自家产品进行试用,随时把一些或大或小的想法发到高管群里。

因为老板向来强势,没人敢反驳,一众高管顺着老板的想法进行讨论,终于得出一个各方都满意的解决方案,并各司其职领取改进任务。

老板是伺候好了,却苦了A君和技术,因为细想下来,老板的想法若要实施,就要进行底层改动,牵涉面甚广,而且改进效果未知。

正在为难之际,部门老大又传达命令下来,老板想法又变了,此方案不用实施了。A君庆幸的同时,充满了无奈和对对未来的迷茫…..

经验说

遇到一言堂的老板,拒绝是不可能的,如果想学魏征一样死谏,除非你有魏征一样的才能和不可替代性,你的老板也具备唐太宗一般的胸襟,否则还是要慎重, 毕竟你领取工资,是要为老板解决问题的,而不是对老板说不的。

最好的方式是找机会多和老板沟通,适当的加以引导。有方案以后也不要着急动工,先跟老板汇报,得到确认指令后再动工。

说不定在你汇报的过程中,老板的想法就又变了呢?

坑9: 多方产品各自为战,没有主次

在做大型项目时,往往不止一个产品经理参与,这种项目上,各位产品经理的分工一定要明确,主次分清,主产品负责整体方案的把控,以及把各子系统方案串到一起;其他产品负责各个子系统模块的细节梳理,听从主产品经理的调配。

如果各自为战,就如同一盘散沙,失败风险极高。

例子

A君接到一个大项目,需要涉及到3个系统的联动,于是老大又派了B君、C君对项目支援,安排每人负责一个系统。

B、C二人仗着资历比A君老,不听A君安排,各自出完方案找到自己的技术评审开发,到进行技术方案对接的时候才发现三个系统的方案有严重出入,要求重新进行需求评审。

此时B、C仍不以为然,两人私下对完方案,并不告知A君。A君无奈,找到老大出面协调,才保证了项目的需求方案的统一,却与B、C结下了更深的梁子。

经验说

新人初来乍到,遇到倚老卖老,没有团队意识的同事,是非常棘手的事情,建议摆正心态,先从自身找原因,同时抱着把事情做好的态度进行沟通,要注意沟通的语气。

如果沟通不畅,及时上报风险,寻求领导的支援。如果连领导也不支持你,那就要考虑一下是自身问题,还是体制问题了。

如果体制风气便是如此,或许这里并不适合你发挥,是不是要考虑换个环境?

坑10: 只顾投入,不问产出

如果从结果上看,很多公司做的大部分项目都会以失败而告终,这种失败不是指项目本身,而是业务层面达不到预期。

为了尽量避免这种现象,产品经理在接需求时,最好能站在业务角度进行分析,多问为什么,多用数据说话,反向驱动业务方为产出负责,坚决杜绝业务随便动动嘴,产品技术跑断腿的乱象。

例子

A君在年底做复盘时,发现近两年为库房做了200多个报表需求,而实际用到的不到30个,很多都是提需求的时候特别着急,上线以后一次都不用。

曾经尝试过沟通,效果并不理想。于是A君和技术合计,为每个菜单增加了埋点功能,如果某报表超过3个月不用,就做下线处理,同时,会将统计结果告知业务方,要求业务方书面说明原因。

经过半年的整顿,终于将报表控制到50个以内,后续报表类需求也减少了90%。

经验说

需求应该双向考量,业务部门考量技术部门的需求产出质量,技术部门也应该反向考量业务部门对需求的使用情况和业务预期。

一味投入、从不问产出,会让所有人陷入一个僵局中,业务方觉得提需求很轻松,也不用承担后果,技术部门只顾着实施,从不问结果,表面的和气带来的是诸多的资源浪费。

所以,从现在起,让各方均为成本负责,多一些ROI意识吧!

总结

人生难免不如意,泪与欢笑成对比。

成长的过程中充满了未知的苦难,我们在一个个大大小小的坑中匍匐前行,前方荆棘密布,刺痛双脚,于是我们痛苦、焦虑、彷徨、不安,有人坚持不下去就停留在原地打转,从此迷失在泥潭中;有人拔掉身上的倒刺奋勇前行,跨过重重阻碍,终将坑填平并种下希望的种子,接着继续探索前行,周而复始的找寻自己心中的阿尔卑斯山。

回过头来看,那些曾经趟过的坑已经绿树成荫、满目青山,曾经滴血的伤口也长出了苍鹰之翅,让我们更加强大。

前一阵小Q工作中受挫,特别迷茫,去找老领导聊天,事后老领导给小Q发来一段文字,看完以后如遇良药,豁然开朗:“人生遇见瓶颈和低谷是正常的自然规律,正是在这个时候才是你真正总结和开悟的阶段。人生想打赢胜仗一定是长期积累的过程,不是靠局部小战役。珍惜自己的时间和境遇无关,安心做好现在的事情,上天自会给我们更好的安排。”

昨日渐多,明日愈少,今日还在,不增不减,这就是人生。珍惜自己的时间,就从今天开始吧,要知道这个世界上最容易和最难的事,都是开始去做你该做的事。

 

作者:木笔,产品一俗生,深耕于供应链领域;微信公众号:供应链产品笔记

本文由 @木笔 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 这篇文章看完了感觉都是心酸和泪水,眼泪都快流了下来

    来自北京 回复
    1. 看来是同道中人

      来自北京 回复
    2. 不说了,要不我提一杯吧

      来自北京 回复