首页>>科技 > 那些年,我们在产品上趟过的坑

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

2019-11-23 13:13:19

每个产品经理在处理需求和项目的过程中都会遇到无数的困境。在不断挖坑填坑的过程中,我们分散了我们的青春,欢迎我们的成长。作者梳理了曾经参观过的10个产品坑,相信其中一个会击中你。

当一个新项目上线时,它通常涉及多个系统之间的联系,而产品经理通常更关注新项目本身,而忽略对外围系统的影响,从而导致上线后出现许多问题。

先生负责的新wms系统上线了。上线之前,所有内部功能都经过测试和通过。因此,企业资源规划系统库存在上线后被发现出现故障,这影响了财务账户和在线销售。

调查的原因是,wms的库存变化逻辑在上线前根据业务需求进行了调整,而这种变化没有及时通知erp调整情况,导致上下游系统的库存处理机制存在差异。

由于库存问题,原本计划在一个月内顺利切换的项目在六个月内不断得到修复和改进。所有部门都很悲惨。

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

当涉及不同的团队和系统时,产品经理必须尽可能多地了解上游和下游业务系统,在整理方案时应考虑上游和下游系统的相关性。如果涉及到上游和下游系统的变更,产品经理必须提前相互问候,并安排足够的时间进行联合调整。

有许多产品经理认为他们很有经验。他们在收到需求后没有与需求方充分沟通,也没有进行现场调查。他们自然会闭门工作。如果他们再次遇到混乱的业务方面,他们可能无法在新需求上线后使用,这将严重导致现场关闭。

为了节约成本,甲先生为仓库设计了一个新的审核流程,将打印面板和清单的模块推迟到审核环节。这是一个非常好的主意。它可以为仓库节省两到三个人力,同时提高作业效率。

然而,新功能的设计没有考虑到现场操作。因此,打印机上线后的打印速度跟不上现场查看速度。每个审核订单必须等待6到8秒钟才能完成打印,然后才能进行包装,这直接导致审核和仓库爆炸。

运行半天后,该项目不得不延期,造成重大损失。

系统设计必须与业务流程相结合,不得闭门造车。这是一个雷区,许多产品经理,尤其是新来的产品经理,很容易踩在上面,只考虑系统实现,而不考虑现场操作。

系统过程通常是闭环的,但是发现站点不能使用,所有的努力都失败了。因此,在设计系统时,操作角色-操作过程-系统过程应该紧密结合。

同时,在大规模工艺改造上线之前,进行现场测试是非常必要的。

当结合业务流程时,正向流程的顺畅流动意味着项目80%成功,但是复杂性通常在于逆向流程和异常流程的处理。

如果逆向和异常处理不当,该过程将不是一个完整的闭环。一旦出现,它将成为一个死节点,不能再向下流动。

先生新启动了仓库的仓储流程。改进后的流程在可操作性和准确性方面有了很大提高,并得到了仓库的一致好评。

但是,由于在验收过程中没有考虑到拒收收到的货物和错误的修改过程,一些收到的货物不能每天结算,必须从后台处理,从而大大降低了项目的在线效果。

在设计过程时,闭环是一个基本原则。反向和异常处理过程可以设计得非常简单,甚至可以进行人肉处理,但必须仔细考虑,否则,就像定时炸弹一样,一旦情况发生而无法处理,那将是一个巨大的坑。

在互联网行业,计划永远赶不上变化。一些来自传统行业大项目的产品经理很容易陷入“大而全”的项目陷阱,追求完美,认为只有各方面、各种风险都到位的项目才能启动。

殊不知,市场没有等待任何人,当系统被制造出来时,它可能已经过时了。

A jun收到了该公司关于建立新的o2o供应链系统的指示。老板想用这套解决方案来促进业务发展和融资。

结果,一群人设计了一个宏伟的目标并开始实施。由于各种原因,最初的3个月项目持续了8个月。启动这个项目并不容易。然而,错过了最佳融资机会。公司资金短缺,项目团队不得不在当地解散。

在市场不明朗的前提下,以mvp的形式推广项目无疑是成本最低的。首先,最简单的模型旨在帮助企业进行试错。然后,模型明确后,投资将会增加。

当然,mvp并不是放弃系统建设,而是应该充分考虑最基本的底层设计和过程闭环。

项目周期不容易太长,过分追求效率而不考虑未来也是一大禁忌。做供应链项目,要注重系统建设。就像盖楼一样,如果地基不稳定,建筑越高,风险就越大。如果长期如此,只会导致崩溃和灾难。

阿俊奉命建立一个绩效体系。最初计划的核心功能需要3个月的时间来开发和完成,但是老板觉得时间太长,要求将项目缩减到2个月。

两个月后,一个不完善的系统终于上线了。先生计划升级结构,为的是上网的隐患,但新项目一个接一个,没有任何缓冲时间,每个项目都需要尽快上线,没有考虑扩建建设。

直到有一天有了另一个大项目,经过先生的评估,他发现现有的系统架构不再能被支持,并建议重建它。然而,老板并不欣赏这一点,认为这是A先生能力的问题。先生别无选择,只能辞职。

该公司的高级管理人员立即聘用了B先生,新来的官员三次担任这一职务。根据过去的经验,先生认为这个项目不太难,所以他在老板面前下了一个书面的军事命令,以确保任务的完成。

在整理需求的过程中,我们意识到系统的核心性能模块漏洞百出,根本无法添加新的功能。因此,我们对没有这样做感到遗憾,并不得不在项目开始前让公司承担开小差的责任。

在系统构建开始时,产品经理必须与架构师一起识别和评估核心架构。即使项目周期很紧,基础设施也不能偷懒,否则会有无穷无尽的麻烦。

如果无法逆转对业务预期的管理,最好使用28条规则优先考虑核心底层的构建,并对非必要功能进行适当的权衡。

在项目过程中,经常会遇到产品经理与业务和技术不能在同一个维度上交谈的情况。他们之间半天的交流就像对牛弹琴,没有结论。

此外,每个人都认为他们已经达成共识,但实际上他们的理解是非常不同的,这导致项目的效果没有达到预期,身心俱疲。

由阿先生领导的中央库存系统终于上线了。然而,由于业务的复杂性,许多场景没有被很好地考虑,导致不准确的库存计算。由于系统问题,许多订单缺货,无法用于库存生产。

甲先生找到了负责任的技术副乙进行调查。一次操作后,所有订单正常转移到仓库,中央库存没有错误报告信息。

我们还没来得及高兴,仓库就爆发了超卖的问题,因为仓库在接到许多订单后,如果没有实物库存,仓库就无法定位生产。

甲先生再次找乙先生,乙先生平静地解释说,中央库存增加了自动库存增加机制。一旦没有找到库存,它将自动添加100个,以确保订单可以顺利下单并交付到仓库。这也导致一些订单超卖。

阿俊很生气,但是小b觉得很委屈,因为他的举动有效地解决了网上卡片清单的问题,没有感觉到他错在哪里,也没有意识到超卖的严重性…..

在这种情况下,产品经理需要找出每个人不在同一纬度说话的原因。如果每个人都有不同的概念和需求,产品经理最好改变他的语气和沟通方式。

如果一些技校学生想偷懒,别有用心,假装与理解混淆,他们就会产生工作态度的问题。

如果每个人都同意已经达成共识,建议使用复述承诺方法。技术学生将复述计划并一起改正,直到各方不再有分歧。

大多数时候,业务部只有一个想法。起初,想法不是特别清楚,所以提交了一个模糊的要求,产品经理开始根据他自己的理解来设计系统。

在项目的过程中,业务需求变得越来越清晰,但发现产品计划与预期相差甚远。因此,需求的变化是不可避免的。

如果产品经理不能有效地管理需求中过于频繁的变化,将直接影响系统设计和项目进度。

考虑到财务压力,采购部需要代表经销商进行发货,即从自我管理采购到与经销商合作,经销商将代表经销商发货。

在项目开始时,业务部门要求一些商品作为试点。根据采购部的要求,骏a设计了一个交货系统。采购部已经确认该计划是正确的。

但是,在系统开发过程中,公司高层多次提出新的想法,要求扩大委托的种类和范围,导致项目范围一次又一次的扩大,底层的系统结构也随之调整,因此无法按时交付,影响了业务的发展。

需求的变化是不可避免的,但是如果变化太频繁,不仅会影响系统设计,还会严重动摇项目团队的士气。

作为一名产品经理,一个人必须学会拒绝,一个人必须学会说不;遇到困难时。第二,应优先评估这些变化的影响。如果确认影响重大,可向上级报告,由上级讨论是否推迟项目或推迟变更的实施。

不要只报道好消息,不要报道坏消息。当项目出了问题时,再报告也为时已晚。

许多公司只有一个最大的产品经理,外加一组需求转换器。这个产品经理是老板。普通的产品经理只能充当将老板的想法转化为产品文档的角色。

老板做产品经理并不可怕。可怕的是,老板想得太多,而且不断变化。一天天变化并不可怕。最可怕的是,老板仍然立刻说话,不接受挑战和建议。

阿俊的老板最近突然冲动,经常在晚上11点后测试自己的产品,随时向高管发送一些大大小小的想法。

因为老板一直很强势,没有人敢反驳,一群高管跟随老板的想法进行讨论,最终想出了一个各方都满意的解决方案,并根据各自的职责接受了改进任务。

老板服务得很好,但他受到了先生和他的技能的很大影响,因为如果他仔细思考,如果他想实现他的想法,他必须在底层做出改变,这涉及到广泛的问题,改进的效果是未知的。

在困难时期,部门主管下达了另一项命令,老板又改变了主意。这个计划不需要实施。同时,先生很高兴他对未来充满无助和困惑。..

拒绝一个只有一个声音的老板是不可能的。如果你想向魏徵学习,向他进谏,就要小心谨慎,除非你有魏徵那样的才能和不可替代的能力,而且你的上司也有唐太宗那样的头脑。毕竟,你需要为你的老板解决问题,而不是在你拿到薪水的时候拒绝你的老板。

最好的方法是找到更多与老板沟通的机会,并给予适当的指导。有计划后不要着急开工,先向老板汇报,收到确认指令后再开工。

也许在你汇报的过程中,老板的想法又变了?

当做大规模项目时,不止一个产品经理经常参与其中。在这样的项目中,每个产品经理都必须有明确的分工,并明确界定首要和次要的优先级。主要产品负责控制总体计划并将子系统计划连接在一起。其他产品负责整理每个子系统模块的细节,并跟踪主产品经理的部署。

如果他们分开战斗,他们会像散沙一样。失败的风险极高。

阿俊收到了一个大项目,涉及三个系统的连接。所以老板派了B Jun和C Jun来支持这个项目,并安排每个人负责一个系统。

乙和丙都依赖资历比甲老。他们不听甲的安排。他们分别提出了自己的技术审查和发展计划。只有当技术计划对接时,他们才发现三个系统的计划有很大不同,需要进行新的需求审查。

这时,乙和丙仍然不同意。他们私下完成了计划,没有通知先生..阿俊别无选择,只能找老板来协调,这保证了项目需求计划的统一,但却和乙丙形成了更深层次的争吵

对于新来的人来说,很难见到那些依靠老来推销老来的、没有团队合作意识的同事。建议理清思路,先从自己身上找出原因,同时用做好事的态度沟通。应该注意交流的语气。

如果沟通不畅,及时报告风险并寻求领导的支持。如果连领导都不支持你,那么你必须考虑是你自己的问题还是系统的问题。

如果制度氛围是这样的话,也许你不适合在这里玩。我们应该考虑改变环境吗?

如果我们看看结果,许多公司完成的大多数项目都会以失败告终。这种失败不是指项目本身,而是指业务水平不能满足预期。

为了尽可能避免这种现象,产品经理在收到需求时最好从业务的角度进行分析,多问原因,多用数据说话,促使业务方对反方向的输出负责,坚决杜绝业务随意张嘴和产品技术断腿的混乱局面。

年底,当甲先生恢复交易时,他发现他在过去两年里为仓库做了200多份声明,但实际使用的不到30份。他们中的许多人在提高需求时非常焦虑,上网后一次也不需要他们。

我试着沟通,但效果不理想。因此,先生和这项技术为每个菜单增加了嵌入功能。如果报告使用时间超过3个月,将离线处理。同时,它将把统计结果通知业务方,并要求业务方书面解释原因。

经过六个月的整合,报告数量最终控制在50份以下,对后续报告的需求也减少了90%。

需求应该双向考虑。业务部门应考虑技术部门需求产出的质量。技术部门也应该考虑需求的使用和业务部门的业务期望的相反方向。

简单的投入和从不要求产出会导致每个人陷入僵局。商业方面会发现很容易提出要求,而且不必承担后果。技术部门只关心实施,从不要求结果。肤浅的友谊带来了大量的资源浪费。

因此,从现在开始,让各方对成本负责,并有更多的roi意识!

生活很难避免失望,眼泪和笑声形成对比。

成长的过程充满了未知的痛苦。我们在大大小小的坑里一个接一个地向前爬行。荆棘长在我们面前,伤了我们的脚。结果,我们遭受焦虑、犹豫和不安。有些人呆在同一个地方,如果他们不能坚持住,就围着它转。从那以后,我们陷入了泥潭。有些人拔掉身上的刺,勇敢地前进,克服许多障碍,最终填满坑,播下希望的种子。然后他们继续探索前进,一次又一次地在心中寻找阿尔卑斯山。

回头看,被参观过的坑被绿树和青山覆盖着,曾经流过血的伤口也长出了鹰的翅膀,让我们变得更强壮。

我之前有一段时间在工作中感到沮丧和失落。我去和老领导谈了谈。之后,老领导给小q发了一段文字,读完之后,我恍然大悟:“人生遇到瓶颈和低谷是正常的自然规律。正是在这个时候,你才真正总结和认识到。人生赢得战斗的渴望必须是一个长期积累的过程,而不是一场小规模的局部战斗。珍惜你的时间与你的处境无关,在做你现在正在做的事情时要放松。上天会给我们更好的安排。”

昨天更多,明天更少,今天依然存在,没有增减,这就是生活。珍惜你的时间,从今天开始,知道世界上最容易和最难的事情是开始做你应该做的事情。

作者:木笔是一种常见产品,在供应链领域有着深厚的文化底蕴。微信公众号:供应链产品说明

这篇文章最初是由“木笔”发表的。每个人都是产品经理。未经允许禁止复制。

主题地图来自unsplash,基于cc0协议。

极速飞艇购买 河北11选5投注 北京快3 台湾宾果app