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

每位产品经理在处理需求和项目的路上，都会遇到无数的坑。在周而复始的挖坑和填坑的过程中，我们散落了青春，也迎来了成长。笔者梳理了一下曾经趟过的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协议

作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。


Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: