初做产品时，请不要想当然认为可以一蹴而就 - 推酷
初做产品时，请不要想当然认为可以一蹴而就
那些年我走过的弯路之——一蹴而就
很多产品经理平时工作都非常努力，但产出效率却并不高，导致产品经理工作事倍功半，产出效率低的原因有很多，其中之一是完美主义，这一点在之前的文章《
》中已经做过详细的分析，今天再给大家分享另外一个影响产品经理工作效率的大敌：一蹴而就。
火山算不上一位聪明的产品经理，但的确是一名非常勤奋的产品经理。在创业公司那几年，在公司里算是典型的劳模。记得当时我们CEO经常挂在嘴边的一句话，要论敬业程度，在公司里如果说火山排名第二，没人敢说第一。每当老板这么说起时，我内心都会泛起一丝隐隐地自豪感。现在想想，自己当初做过的很多项目，其实都是处于事倍功半的状态，投入了很多的时间和精力，但实际的产出效率并不高。接下来给大家分享一个真实的项目案例——一个我初做产品时曾经犯过的低级错误。
我们公司做的是一款基于商旅出行预定的企业商旅管理产品，差不多2年前，火山接到了这样一个需求：
需求描述：为我们机票产品增加一个审批的功能，保证企业员工的每一次差旅出行都在经过领导审批之后再进行，让公司的差旅支出更加可控。
审批，这是一个企业级的管理软件中非常常见的一个功能，我们不妨先暂停一下，假设你是接到这个需求的产品经理，你将怎样完成这个项目？
思考1分钟，计时开始……
想必现在你已经有一个大概的思路，那么，火山是怎样做这个项目的呢？这个需求其实在我刚开始接手产品的时候就一直在提，但是由于种种原因就一直没做。在正式启动项目之前，我跟我当时的领导简单描述了一下我的想法：
审批有两种做法，即：行前审批和出票审批，前者是出行前先生成一张审批单，审批通过之后再订票；后者是在订票的时候生成一张审批单，领导审批通过之后再出票……
如此云云之后，我给领导的建议是以“事前审批单”的方式来做这个审批项目。我的领导当时刚空降到我们公司，大约40来岁，是一个智商奇高同时也比较自负的人，有比较强的技术背景，但没做过产品，之前从事的并不是这个行业，在大致在听了我的思路之后，表示这个需求并不复杂，很简单的，你按照你的想法去做就好了。
由于客户、销售、运营、老板各种场合提了很多次，大致的需求我也都了解，所以我也就没再做需求调研，我直接按照事前审批单的方式上手开始做这个项目。先是花了2天的时间梳理业务流程，然后是花了差不多3个星期的时间画网站原型，在这中间跟我们开发经理简单沟通过一些技术方案。在包含了无数交互动画的网站原型画完之后，我还是觉得不够出彩，为了在我的新领导面前表现一下，我又花了1个星期把详细的PRD写了出来，试图一蹴而就，把交付给领导检验的项目成果做得更漂亮一点。
终于，一个月之后，到了给领导交付成果的时候了。我叫上了我的领导，召集业务需求方、开发经理一起，开始了第一轮需求评审。首先评审的内容是流程，我打开我的visio，开始讲解我的流程：“当用户选择好一个航班，点击“预定”的时候，系统按照用户所选的行程，生成一张审批单……”
“审批怎么会是从预定是开始 “我话还没说完，领导直接打断我的话，说道：“审批应该该是从下单时开始才对呀！”
“没有，我的做法不太一样，您先听我把话说完……” 我解释道。
“你不用往下说了，你这种做法肯定是错的！”我领导从座位上站起来，也不正眼看我，拍打着投在墙壁上的投影说。”审批怎么可能是从预定开始的呢，没有这种做法……”
“我的做法跟您的想法不一样！”做了一个月的项目，新领导连讲完的机会都不给我，还在那么多人面前一通骂，让我也有一点情绪激动。“您能不能先听我把话说完，不要一上来就劈头盖脸一通骂……”
“火山，你先别着急，我知道你的意思，你的意思是先做一个审批单，审批通过之后再走后续的预定的流程对吧？那种审批做起来可能比较麻烦一点，但是我们这次只需要做出票审批就可以了。”参会的业务见气氛不太对，一边安抚我的情绪，一边解释道。
“在我印象中，审批应该也是从下单开始的。”半天没有发言的CTO也发言了。
之后，也不知道是因为赌气还是因为被大家说服，我慢慢放弃了争辩，开始闭嘴听大家的想法……不仅没有得到新领导的认可，我也没有得到老领导CTO甚至业务方的认可，对于这样的结果，虽然从感情的角度来说，我的确很难接受，但是从理智的角度来说，我已经逐渐意识到：无论我的方案是否具备可行性，但毫无疑问的是，从一开始我的方向就已经错了，我把自己狠狠地坑了一把，因为这个方向性的错误，导致我辛辛苦苦花了一个月时间做的整个项目方案都得推翻重做！
什么叫事倍功半？这就是活生生、血淋淋的例子！
为什么会有这样的结果?火山在这个项目中犯了那些错？我们不妨再稍作暂停，回想一下，在你的工作过程中是否也有过类似的经历？我的这段可以作为反面教材的经历对你是否有一些启发？
思考1分钟，计时开始……
这个项目做下来，其实火山犯了很多错，例如没有充分地沟通，缺少需求调研等，但如果做项目的方法得当，这些错误实际上都是可以在做项目的过程中得以修正的，但是我并没有修正掉，因为我还犯了另外 一个致命的错误——妄图一蹴而就！
一开始，领导可能并没有给出明确的方向，而我没有跟领导寻求明确的指示，这可以说我在沟通上犯了明显的错误。但是如果我没有妄图一蹴而就，在绘制完流程图之后把流程图给领导看一看，请示一下，领导可能在项目一开始就已经给我把问题点指出，那么，我后面花了一个月时间完成的产品方案，也就不必推翻重做了。即便流程没有能够第一时间确认，但是如果我在画完原型图时不妄图一蹴而就，先跟领导请示一下，那么我就不用浪费那么多时间为一个错误的产品方案撰写那么详细的PRD文档了。如果一开始就纠正了方向，由于做法更简单，或许我的项目早都可以结项了。
现在再回过头去看我刚开始做产品那段经历，这样的低级错误我似乎犯过不止一次。有时是因为希望希望能给人眼前一亮的感觉，也有时是因为想要偷懒而省去需求评审，还有时因为自认为简单就不需要沟通，我时常都抱着这样一种一蹴而就的做事方式，说到底无外乎是为了省一些中间环节的沟通时间，殊不知看似相仿的产品功能，产品设计的方式方法可能变化万千，很多优秀产品都不是生来就在一个正确的轨道上的，而是在设计的过程中根据多方讯息和实际情况逐步修正而成的，也没有哪个项目是产品经理可以一气呵成而不需要任何调整的。正所谓与“欲速则不达”，为了省一点沟通的时间而采取一蹴而就的做事方式，往往适得其反，不但时间不会花得更少，反而可能会花2倍、3倍甚至更多的时间。
做得慢，我们还可以通过勤加练习提高工作效率，但是如果方向做错了，做得越多也就意味着错的越多，相应的返工的成本也就越高。没有什么比推翻重来更影响产品经理工作效率的了。小项目可能影响不大，但是对于比较大的项目，因为如果一开始选择的方向就错了，那影响就难以估量了。所以，现在你明白为什么说一蹴而就是影响产品经理工作效率的大敌了吧。
那么，我们产品经理在做项目的过程当中，该如何避免出现类似的错误，把这种风险降到最低呢？作为一名在这方面给自己挖坑过大坑的过来人，我的建议是： 遵循产品设计的必要流程。 对于比较大的项目，除了前期充分的需求调研之外，在做项目的过程当中，在一些关键性地节点上，还需要与关键的需求负责人保持密切的沟通，要尽可能及早的发现并修正方向性的问题，具体的操作细节总结起来就是：
需求调研阶段——深入调研并确定项目范围
项目启动阶段——与业务需求方、技术负责人、关键领导人一起确认主体业务流程
产品设计阶段——与业务方展开2-3轮需求评审，确定网站原型
提交开发阶段——与开发、测试进行PRD评审，确认功能细节
创业公司大多主张快速响应，简化流程乃至于没有流程的。但是时间长了，团队规模扩大了，做的项目多了，慢慢地我开始体会到流程的重要性了。
关于产品设计有哪些流程，特别是创业公司需要哪些必要的产品设计流程，我也是颇有心得的，关于这一点，我会在后续的推文中做专门的分享。感兴趣的小伙伴可以关注我的微信公众号”PM火山”的后续推文，敬请期待。
本文由 @火山&原创发布于人人都是产品经理。未经许可，禁止转载。
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致不知道的肯定以为是影视学院的学生在拍戏呢。
新郎的衣服已经被撕开，双脚也被透明胶带捆住了。
声明：本文由入驻搜狐公众平台的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
　　数十万互联网从业者的共同关注！
　　作者：火山。 作者授权早读课发表，转载请联系作者。
　　微信公众号：PM火山
　　编辑：Juvae
　　欢迎到早读课投稿，投稿邮箱：
　　那些年我走过的弯路之――完美主义
　　完美主义，这是初级产品经理，特别是有追求的初级产品经理必走的弯路，而且这条弯路背后还潜藏着硕大的一个天坑！火山刚开始做产品的时候就走过不少这样的弯路，也顺道挖了好多坑，今天来跟大家分享一个我之前做过的真实的产品案例。
　　火山所在的公司是一家专门为票务代理人提供自动化业务系统的创业公司，打造的是一款基于SaaS的toB类产品。差不多3年前，也就是在我刚开始做产品的时候，我接到了这样一个需求：
　　需求名称：订单拦截
　　需求来源：上海xx客票代理服务公司
　　提出人：我公司x销售同事
　　需求描述：
　　虽然我们系统可以实现没有人工干预的自动出票（票源来自我们系统自动推荐的供应商），但是利润空间有限，而我们的客户大多本身有自己稳定的出票渠道，而且他们某些产品利润空间比我们提供的更大，为保证利润最大化，在用户前台下单后，系统需要将订单进行拦截（即不走自动出票的流程），经线下与固有渠道比对好利润之后，人工确定是否通过我们系统出我们推荐的供应商的票。
这就是大致的需求背景，看到这里，请各位看官先别着急往下看，设想一下假设你是接收到这个需求的产品经理，你将会如何设计产品以实现这个用户需求？
思考一分钟，计时开始……
　　犹记得当时我刚做产品不到1年的时间，为了提升自己在产品方面的专业素养，我看了很多书有关产品的书籍，对产品的用户体验无比在意，有着强烈的完美主义倾向，做任何的产品功能，功能体验都会抠得很细，提高用户体验是我做产品的无上法则，什么边边角角都尽可能地考虑周全，这个项目自然也不例外。
　　闲话休烦，我们言归正传，回来继续说这个项目。接到这个需求之后，我首先做的事情就是穷尽我有限的脑洞，对需求可能的用户场景进行了无限详尽的分析，除了最基本也是最重要的下单流程相关变更之外，在订单拦截设置上，我设想还存在以下几种用户场景：
场景1：首先，订单拦截需要可控，客户可以决定是否要做拦截，因此，需要一个订单拦截的开关，可以打开和关闭订单拦截功能；
场景2：订单拦截开启时，需要考虑一天之中的时间，客户白天有人守着的时候，订单拦截开启，下了班，或者中午吃饭的时候，没有客服在电脑跟前时，有可能会忘记关闭订单拦截，这个时候订单拦截需要自动关闭，走自动出票的流程；
场景3：不同的客户上下班时间不一样，因此，需要支持不同的客户按照不同的时间来设定拦截；
场景4： 周一~周五上下班时间固定，周末值班，时间可能会跟平时不一样，因此，需要支持按照工作日和周末拦截时段的区别设置；
场景5：如果遇到平日是法定节假日，客服的上下班时间可能会不一样，因此需要支持按照个性化的时间段进行订单拦截；
场景6：有些热门机票库存有时候会非常紧张，订单拦截之后由于有时间延迟，最后想再去从我们平台自动出票的时候，可能票已经没有了，因此为了优先保证出票，需要设定一个阈值，当余票数量低于5张时，订单拦截不生效；
场景7：不同的客户对这个阈值可能会有不同的设定，不一定每家都设定5张，因此需要支持不同的公司设定不同的阈值；
场景8：订单拦截后，如果超过半个小时订单没有做任何处理，有可能是客服来不及处理或者没有注意到，为保证客户出行，如果检测到超过半小时没有出票时，系统需要触发自动出票流程；
场景9：不同的客户可能对自动处理的时间会有不同的要求，因此需要支持时间上的自定义；
场景10：春节等个别特殊时段，没有客服值班，所有的订单需要走自动出票流程，订单拦截不生效；　　基于以上这些应用场景，关于订单拦截设置模块的功能，经过差不多1个多星期的产品设计调整和反复优化，（请忽略新手的效率问题）我做出了一个产品Demo，效果如下图所示：
　　这个产品设计几乎“完美”地解决了上述所有的应用场景需求，也成功亮瞎了销售同事的钛合金g眼。而后，提交开发时，开发小伙伴却颇有微词，表示这里面的逻辑太多，实现起来难度比较大，但在我耐心的解释和坚持之下，最终还是顺利地推进了开发。现在回想起来，我依稀记得当时我被自己缜密的思维，周全地考虑感动得不行不行的样子。
　　终于，经过开发小伙伴差不多一个多月的开发，产品基本成型，在内部测试的阶段，客户来我们公司拜访，我就得意洋洋地给客户做了详细的产品展示和培训。一番讲解之后，客户似乎并不买账，同时还提出了不少疑问：
需要拦截的指定时段与周期ab同时勾选时可能存在时间上的重叠，重叠之后以哪个为准；
拦截时段与不拦截时段如果出现重叠，是拦还是不拦？
既然本身就有拦截开关，那为何在拦截设置里面又要设置例外条件？订单拦截开启时，又遇到了不做拦截订单，到底是拦还是不拦？
　　我花了10几分钟的时间，给客户解答这个订单拦截的逻辑，最后发现不仅没帮客户把问题解释清楚，反而连自己都被绕进去了。在这个时候，我已经意识到：无论我最后能否帮客户培训清楚这个功能，这都已经注定将是一个失败的产品设计，而最直接的表现就是――学习成本太高，没有几个用户有那么好的耐性愿意花那么长时间去研究你的功能怎么使用的。如果进一步上升到理论高度来说，就是我的产品设计已经违背了“Don’t make me think”的产品设计黄金法则。
　　之后，经过与客户的深入交流，了解到客户其实只是需要一个简单的订单拦截功能，需要拦截的时候手动打开，不需要拦截的时候就手动关闭就可以了。换句话说，我费劲心思所做的那些产品设计在真正的用户手里已经被判了死刑！
　　自己所作出的投入虽然白费，虽然没有得到用户的认可，但毕竟是自己掰石头砸了自己的脚，终究是谁也怨不了；可是对于本身前期就颇有微词，而现在又不得不毁掉自己亲手码出来的开发GG那边……你能想象我当时心里的忐忑吗？
　　正所谓“自己挖的坑，含着泪也得填完”。为了降低开发gg的不满，我 生生“编造”了好一通凿凿之辞：由于这个功能现阶段还不稳定，加之用户需要时间适应，因此，这个项目中的所有设置里面的相关功能均作为高级设置，在后期迭代的版本中根据用户的需求我们再逐步放开……费了九牛二虎之力，好说歹说，开发GG终于答应了把分时段、分周期、特殊情况不拦截等等功能逻辑先全部注释掉。最终，我们交付了如下一个订单拦截的功能：
　　实际的应用场景就是，用户需要拦截的时候打开，不需要的订单拦截就时候关闭可以了。真正完美地解决了用户的实际需求，也不需要用户去思考。
　　后来，两年多的时间过去了，随着时间的推移，我们的客户增长了10几倍，订单业务量上涨了几十倍。所有新老客户都一直用着两年前我所设计的订单拦截功能打理着他们的实际业务，而当初我所设想的哪些用户场景几乎从来就没有客户再提起过，而我“天才般”设计的那些所谓 “完美”的高级功能沉睡在开发GG的代码行里，从来也没有再醒来过……
　　做一个项目，我不仅把自己给坑了，成功地坑了开发，坑了测试，进而也坑了公司（资源浪费）。所以，现在你明白为什么我说完美主义对于产品经理而言是一条弯路了吧。
　　如今三年过去了，重新审视三年前自己做过的这个项目，感触良多，今天我想尝试对这个项目做一次复盘，反思一下自己当年都犯了哪些错误。看到这里，想必各位看官对这个案例也会有自己的一些看法。我们不妨再暂停一下，思考一下发生在火山身上的这个案例是否有带给你某些启发？
思考一分钟，计时开始……
　　火山复盘：
　　在这个项目中，火山至少犯了两个严重的错误：脱离用户、完美主义。前者是产品经理圈子里常见的一种错误，而这种错误对于产品经理而言往往又是非常严重乃至于是致命的，但由于与本文的主题不相匹配，因此在本文中我就不再展开分析，我会在后期专门撰文分析，今天我着重分析一下后者，即――完美主义。
　　完美主义最大的表现就是抓小丢大，死抠细节，不放过任何一个应（bian）用（bian）场（jiao）景（jiao）。我在这个项目中就是这样一种表现，总希望自己做出来的产品可以适应各种各样的场景，满足用户方方面面的需求。其实这样做产品很累，而且效率也会很低，但即便如此，依然总有无数的产品经理在这条道路上前赴后继……
　　我不由得想到了一句歌词：是我想得太多，犹如飞蛾扑火那么冲动……
　　产品经理追求完美本无可厚非，而且我们周围用过的很多神一样存在的产品，例如微信、苹果等等背后都有这么一个理念，也正因为他们追求完美的理念，才让我们得以用到那么棒的产品。但凡事过犹不及，把握好度很重要，如果在资源并不充足的情况下，就过份主张完美主义的产品理念，做任何的项目都那么在意这些边边角角的细节的话，这将非常影响产品的节奏。如果一个产品团队都是秉持着这样一种理念，它对于唯快不破的互联网公司，特别是资源本就非常匮乏的创业公司来说负面影响是非常非常大的，不信，我们来算一笔账就很清楚了。
　　在这个项目中，我作为产品经理，为了实现这个客户需求，花了3周左右的做需求，其中1个多星期就是在做上述的那些边边角角的需求，开发GG花了5周左右的时间开发，测试花了2周左右的时间测试，也就是说这个项目总共花费工时：
　　产品+开发+测试=3+5+2=10周≈2.3月
　　这其中还没有计算需求评审占据的业务、开发和测试的时间，测试研读PRD，写测试用例的时间以及最终产品跟踪、业务内部培训、外部解答的时间。最终，实践证明我所有那些追求完美的设想在很长一段时间内都是多余的，也就是说所有基于案例中所提到的应用场景做出的设计和开发都是不必要的，至少在很长一段时间内是不必要的，而如果去除这部分需求，粗略估计整个项目的工期可以缩短一个月，即节约1人月的工时。如果一个公司有10个人的产品团队，每人每月做1个这样的项目，那么1年下来浪费的人力是多少呢？
　　1人x1个项目x1个月浪费工时x10人x12个月=120人月
　　按照人均人力成本12k计算，全年共浪费人力成本：
　　120x万/年
　　换句话说，1年下来，一个10人左右的完美主义产品团队无形之中就给一个公司造成了144万的成本浪费。是不是有一种不算不知道，一算吓一跳的感觉？
　　而完美主义带来的负面影响远不止这种资金成本上的损失，因为这些是可估量得出的；这背后更大更恶劣的影响还在于时间上的损耗，因为120人月（10人年）的另外一种含义是，一年下来团队里面少了10个人的产出，而这个数字还是建立在10个人的基数上测算的，假设你公司的产品团队有30人，50人乃至于更多，可以想象一下，在这个天下武功唯快不破的年代，少了30、50个人的团队对一家互联网公司的影响会有多大，完美主义的产品理念背后潜藏着多大的一个天坑……
　　回到开头的话题，为什么说完美主义是初级产品经理必走的弯路？选择做产品经理的人大多都是比较有想法的，都希望自己生的“孩子”长得更好看一点，技能更多一点。而刚开始做产品的时候，但凡有追求的产品经理，肯定各种产品经理相关的书籍资料恶补，而在产品经理所能涉猎到的诸如张小龙、马化腾、周鸿t、雷布斯等产品大咖总结的产品方法论当中，用户体验是相对而言最容意感知得到也最好被理解的，因此，无数初级产品经理就将打造完美用户体验作为了产品道路上的一个信条也就不奇怪了。所以，现在你知道为什么我说有追求的产品经理最容易走上完美主义这条弯路了吧？
　　那么，有没有办法可以控制或者避免自己的完美主义倾向呢？答案是：有！那就是――抓大放小，基于主应用场景设计产品。
　　写到这里，文章已经很长了，而单就最后这条方法论，展开来讲也可以写好几篇文章，所以今天先点到为止，如果感兴趣的小伙伴多的话，火山可以在后续的文章中再给大家分享。
　　后记：
　　不久前，我作为初创团队的一员，怀着感伤离开了待了3年的创业公司。要问我在一家创业公司做三年产品经理有多少收获，我只能说实在太多太多，这些收获不仅仅局限于技术流的产品硬技能强化，如流程图、原型图、PRD等，更多的是对于意识流的产品软技能提升，这其中就包含了沟通协调、产品规划、产品方法论等等。而无论硬技能还是软技能，最深刻的感悟永远都是从自己挖过的坑或者走过的弯路中收获的。我将会在接下来的一段时间里，我会由浅入深地把我的这些收获和感悟进行总结并与大家进行分享，希望可以给在产品经理道路上打拼的同仁们一点点启发。
欢迎举报抄袭、转载、暴力色情及含有欺诈和虚假信息的不良文章。
请先登录再操作
请先登录再操作
微信扫一扫分享至朋友圈
搜狐公众平台官方账号
生活时尚&搭配博主 /生活时尚自媒体 /时尚类书籍作者
搜狐网教育频道官方账号
全球最大华文占星网站-专业研究星座命理及测算服务机构
专注互联网产品、用研、交互、设计、运营领域精选内容。信息爆...
主演：黄晓明/陈乔恩/乔任梁/谢君豪/吕佳容/戚迹
主演：陈晓/陈妍希/张馨予/杨明娜/毛晓彤/孙耀琦
主演：陈键锋/李依晓/张迪/郑亦桐/张明明/何彦霓
主演：尚格?云顿/乔?弗拉尼甘/Bianca Bree
主演：艾斯?库珀/ 查宁?塔图姆/ 乔纳?希尔
baby14岁写真曝光
李冰冰向成龙撒娇争宠
李湘遭闺蜜曝光旧爱
美女模特教老板走秀
曝搬砖男神奇葩择偶观
柳岩被迫成赚钱工具
大屁小P虐心恋
匆匆那年大结局
乔杉遭粉丝骚扰
男闺蜜的尴尬初夜
客服热线：86-10-
客服邮箱：初做产品时，我犯过低级错误 -学网-中国IT综合门户网站-提供健康,养生,留学,移民,创业,汽车等信息
初做产品时，我犯过低级错误
来源：互联网 更新时间： 21:57:00 责任编辑：鲁晓倩字体：
对于比较大的项目，除了前期充分的需求调研之外，在做项目的过程当中，在一些关键性地节点上，还需要与关键的需求负责人保持密切的沟通，要尽可能及早的发现并修正方向性的问题，具体的操作细节总结起来就是：经验之谈需求调研阶段――深入调研并确定项...
那些年我走过的弯路之――一蹴而就
很多产品经理平时工作都非常努力，但产出效率却并不高，导致产品经理工作事倍功半，产出效率低的原因有很多，其中之一是完美主义。
这一点在之前的文章《为什么说完美主义的产品理念背后潜藏着一个天坑》中已经做过详细的分析，今天再给大家分享另外一个影响产品经理工作效率的大敌：一蹴而就。
火山算不上一位聪明的产品经理，但的确是一名非常勤奋的产品经理。
在创业公司那几年，在公司里算是典型的劳模。记得当时我们CEO经常挂在嘴边的一句话，要论敬业程度，在公司里如果说火山排名第二，没人敢说第一。
每当老板这么说起时，我内心都会泛起一丝隐隐地自豪感。
现在想想，自己当初做过的很多项目，其实都是处于事倍功半的状态，投入了很多的时间和精力，但实际的产出效率并不高。
接下来给大家分享一个真实的项目案例――一个我曾经犯过的一个低级错误。
我们公司做的是一款基于商旅出行预定的企业商旅管理产品，差不多2年前，火山接到了这样一个需求：
相关文章：
上一篇文章：下一篇文章：
最新添加资讯
24小时热门资讯
Copyright © 2004- All Rights Reserved. 学网 版权所有
京ICP备号-1 京公网安备02号您的赞赏，是对我创作的最大鼓励。|赞赏4人打赏
收藏已收藏 | 34赞 | 29
分享到微信扫码分享到微信
微信公众号：PM火山
7篇作品22.4k阅读总量
热门问题12345678910(远航之帆)
(起点学院)
(turtlefish)
(起点学院)
(起点学院)
第三方登录：