产品经理为什么喜欢推翻重建产品?

当产品经理接手旧的产品的时候,分析过一遍产品后,第一冲动似乎都是推翻重建,为什么这种状况会频繁的出现呢?

你们在做产品的时候接手旧产品,是改良派还是革命派呢?

回答 75 排序

不能这样说。每个产品人的思维、眼界、嗅觉、执行力都是不一样的,而同样,产品的市场体量、承载的公司战略也不是一成不变的。

刚入行的产品人承受、适应能力比较初级,对不熟悉业务所遇见的不可控因素诸如成本紧缺、档期较紧这种问题处理能力较弱,情急下最常见的办法就是题主所说的推翻重建。把问题调整到可视可控范围内,但往往这样做会引起其他员工的不满和部门资源的不协调,上下层执行不一,观点没有统一战线。最后铁定会拖垮项目进度。

稍微成熟一点的产品人首先在自我要求上会是产品输出导向,而非进度导向的。换言之,会花比较长时间去了解、再认识产品,调查业务瓶颈,查看用户反馈,摸清企业战略和产品的生命周期到了哪一阶段,再针对产品出现的问题,分清哪些是产品本身问题,哪些是技术问题,哪些是业务问题。

对于一款产品来说,业务问题是最先需要解决的,因为产品核心在于商业价值,通过业务体现出来。如果业务逻辑跟不上用户行为,衍生功能解决不了用户需求,平台体验和技术实现再好也无济于事,这部分出现问题确实是需要大刀阔斧甚至重建的。其次产品本身问题介乎到用户需求的满足程度,如果是产品本身出现问题,有强需求未能满足,有潜需求没有挖掘,有弱需求拖沓资源,有伪需求占用成本,这些则要考虑需求实现的优先级,同时结合考虑公司战略层阶段等角度去考虑,这部分花时间去重建则是下下之策。最后便是技术问题,重建的可能性是最小的,但如果涉及到数据源、架构等基层系统问题需要重建的,成本是三者最大的。同样,也要考虑诸多因素。

总结,产品人刚接手一款产品,调整是必然的,重建则需要搞清楚是自身的问题还是产品的问题。反之,都是不负责任的。

匿名
利小刀 捷讯网络技术 产品专员

因为不想靠近别人留下的可能,所以跳进了自己挖的坑。

匿名
蛋总 温商贷 高级产品经理

做产品也有2年多了,有自己0-1主推的项目也有接手前任留下的半成品的经历。因为我是从事后端产品的,我且从后端产品去讨论楼主的这个问题。

首先,接手别人的半成品后第一个想法是推翻,而不是在基础上去迭代的产品经理是有,但是绝对不会是主流,因为考虑到重建成本,一般的产品经理都不会这么干。第二,即时有这个想法,那么一定是前任留下的太坑,而接盘的人感觉填坑的难度不亚于重建的难度。说个例子,做后台产品的,很害怕接手半成品的后台,因为对于后台来说,本身逻辑性就会相对复杂,涉及到的流程和数据交互也会比较多,而且对于后台的设计思路太多太多,有的人会根据工作流去设计,有的人会根据实际功能模块去进行设计,你还需要花很多时间去摸清楚,前任产品经理是怎么想的。然后这个后台的逻辑是否有漏洞,是否你之后的改动会对前面的设计产生很大的影响,这个都是很费时间的。所以有的产品,可能一接手第一想法就是直接推翻。第三,就是产品经理都有自己创造的欲望,这个和产品经理的岗位的特殊性有关,每个产品经理都梦想着自己去主导一个产品的诞生,当然不希望“喜当爹”。

最后,我最近也接手了一个十分之重型的后台系统,功能很全,设计的工作流繁多,但是由于是技术自己搭建的,没有从易用性,操作流程顺畅的角度去考虑,整个后台让人看起来就是一个大杂烩,什么都给你了,就是需要你自己去找。说实话,我刚接到也是要骂娘的,但是产品人的一大high点不就是去变腐朽为神奇么?享受这个过程。

匿名
SSJ是大白。 求职 产品实习生

谢邀

此题无法答得出彩或者得到认同,我已经有这样的预感。

人性本恶,我向来怀着最大的恶意揣测他人。

推倒重建分两种情况概述

一,新产品经理接手旧产品,无论数据原型优劣,若不做任何改良优化或者推倒重建,那么新产品经理出现和存在的意义是什么?怎么体现自己与众不同之处?怎样实现自己的价值?

新来的设计师对以前的设计风格不满,新来的运营觉得过去的运营策略有问题,不都是这个道理么?

其实就是每个人都与之不同,正如世界上没有两片完全相同的叶子,何必说得那么堂而皇之,大言不惭?

二,原产品经理对自己原产品的改良重建,这是一个必然的过程,随着认知以及经验的提升,自己最容易发现自己以往的的错误,改良也好,重建也罢,都是一款产品迭代更替的必然过程。(我看题主问的主要是第一种情况,这里一笔带过)

其实还分公司团队而论

去了top的公司团队,假如你进了张小龙的团队,哪怕是提了他位置,你敢对微信推倒重建吗?假如进了阿北的团队,(我以前提到过豆瓣产品渐渐趋向老化)你敢对豆瓣推倒重建吗?假如进了度贴吧的团队,你敢对贴吧的产品推倒重建吗?

实际上,敢与不敢是一回事,能与不能又是另外一回事。

去了创业小团队,如几年前的饿了么(有幸在他们的创业孵化器大楼办过公),或者N年前的波奇,这样的推倒重建,大刀阔斧的改革多了去了。

不正是应了那句话,强者愤怒,抽刀向更强者。弱者愤怒,挥刀向更弱者吗?

再次谢邀,回答戾气很重,不过“皇帝就是没穿衣服啊”

欢迎开喷,转载及批注

匿名
车马 银信天下网 前产品总监兼CEO

快闪回答。 

1、上一任产品经理做得确实烂,不然怎么成了上一任了?这么烂的东西,不如推倒重建。

2、上一任产品经理做得还行,但毕竟是另一个人做的,和新任的思路、风格都不同,现在既然新任接手了,就得按新任的思路、风格重来!反正,上一任已经走了,连辩论的机会都没有。这和房子卖了,不管原来的装修如何,新房主基本都会拆了重新装是一样道理。装出来很可能还不如以前,但是“现在我是房主,我就喜欢!”…… 

3、喜欢重建产品的是产品经理?根据我的经验,设计、技术都爱这么干!每次换了设计、技术的头,几乎都会说“原来的设计理念落后!”、“原来的技术架构就有问题……”。然后,重建了几个月,又产生了新的问题……😢

匿名
一颗滚石 某厂 产品线负责人

坚持两个原则:

1、用户第一

2、数据说话

产品经理的出发点,不站在用户角度,很容易判别,常用的语句是:

”我以用户身份做了试验“,问题是实际走访多少用户?

产品经理不使用数据说话,就要大改是不能接受的,给公司带来的成本和损失会很大。

可以要求产品经理使用数据采集系统,获得竞品相关数据,结合自身产品数据(即使数据量小),同时能够站在用户角度、市场行情充分说服:老板、领导、开发。

以上两个基本原则不坚持,其他内容不要谈!

匿名
蒋干三国 北京有装网信息科技有限公司 产品经理

实际上,能够理解前任产品的思考思路,不轻易的进行推翻重建,不仅仅是一种个人修养,更是一种严谨做事的态度

受限于产品的发展阶段和每个人的思考维度,任何可能之前合理的产品因为市场环境的变化或者运营的新需求都会显得过时,甚至产生逻辑错误,新手在接收这类产品的时候,切忌马上着手修改或者全盘否定、推倒重来,而应当从以下的思路解决问题:

1、之前这个功能/逻辑的作用是什么?

了解这个是非常必要的,举个例子:

list的筛选可以将筛选项平铺展开,也可以做成下拉框,如果你觉得平铺的样式比较占版面而贸然的将交互样式改成下拉框,可能会增加一步用户的操作成本,如果下拉框非常多,虽然页面显得非常整洁但实际上是不利于C端用户进行筛选的;

充分了解当时产品做功能/逻辑的思路可以有效避免踩坑;

2、这个功能/逻辑有没有对其他功能产生影响?

推翻重建的时候很难将之前的思路筛选清楚,有些字段会遗漏、展示字段上限等诸多问题可能隐藏在其中,举个例子:

之前在做页面改版的时候需要增加一个字段,在后台字段中我发现一个非常类似的字段,差不多就一字之差吧,询问了当时的产品,他说这个字段目前没有数据;

然后我就没有创建新字段,而是使用原来的那个字段添加内容,上线后傻眼了,一个入口很深的页面将我添加的字段显示了出来,不得不返回上一个版本


退一步来说,前人在做功能的时候也不是拍脑袋在做,新人接替工作的时候务必还是要严谨谦虚,保持一颗平常心,体现自我的良好修养

匿名
猫男 钱宝 产品经理

题主的问题要从几个方面着手。公司的战略经营方向,产品经理自身的专业能力,对产品的理解和对行业的了解等都是很关键的点。

首先,为什么推翻?

1.时间成本:当接手一个产品需求后,如果这个公司的人员流动较大,很多时候还会面临(产品的设计文档、流程、prd等都不完善的情况)那么很多时候,产品经理们需要花费大量时间和经理去学习了解这个产品原来的逻辑规则与设计思路。很多时候,学习的时间成本不是问题,主要是心累!

2.大坑小坑:很多产品经理在做一个产品的时候,会因为时间紧迫、人员不够、领导、当下环境等主观客观原因而留下各种大坑小坑,让后人吐槽不以。

3.成就感:很多人喜欢从自己理解的角度,去建立一套逻辑体系,希望自己的思考和设计能全面呈现在用户的面前,接受吐槽和膜拜。简而言之,就是站在别人的肩膀上实现自己的价值,进行自我提升与学习,获得成就感。

4.下次面试加分:这个很重要。很多面试官都会问:你有主导过什么产品从0到有吗?很多人都希望自己能自信满满的回答:有!然后balabala……

其次,为什么改良?

1.时间成本:还是时间,很多时候一个产品已经是一个庞大的体系,除非公司的整体经营方向发生大的变化,否则不可能进行重建。只会发生整合,整合是超级让人心累。但是没有办法,只能整合,只能改良。

2.人力成本:很多功能都是牵一发而动全身,一个小功能的改动,如果重建需要动到各个方面的业务功能与配合。那么人员的配合上就是拉大了战线,所以很多时候为了节省人力都是尽可能少的进行改良。

3.各种坑:有时候,大家都知道坑在那里。但是为什么不动呢,因为时机还没有到。所以,改良吧。

4.人际关系:比如这个产品是你领导做的。他丢给你了,说了句:怎么做,随你!然后,你怎么做。。。

匿名
醉月心涯 通行 产品经理

“”当产品经理接手旧的产品的时候,分析过一遍产品后,第一冲动似乎都是推翻重建“这种说法的一般都是没有做过仔细评估或者认真思考的人。

结合自己的亲身经历说一下这个问题:

当初接触接手某个产品的时候,产品已经拥有PC端,APP端和H5端;

产品现状

PC端:拥有符合目前业务的所有功能,交互性良好,界面风格及美观性与当前行业靠前的产品一致,只有小部分功能存在优化空间;

APP端:拥有绝大部分的业务功能,且包含一些app特有属性功能,一些复杂的操作及数据显示和分析功能暂无,整体体验一般,能够基本满足经常使用的一些操作和需要;

H5端:拥有产品的最主要的功能,能够满足最高频率使用的场景,体验较差,交互性很差。

目标

新版app要求体验非常好,界面风格需要符合当前最主流的方式,能够满足当前业务的所有功能,需要增加在移动端更好推广的功能;

新版H5端要求满足体验较好,用户能够在不借助其他端产品(PC或app)的情况下能够完成产品的基本操作;

持续优化PC端体验;

微信端内嵌H5,同时基于微信端做一些特殊功能,诸如免登陆,信息推送等;

结果

优先开发新版的H5版本,分为两个大版本实现,为期一个半月;

新版app,主要实现界面风格及交互性,后台开发功能较少,为期一个月;

微信端开发,为期一个月;

持续优化PC端的功能及体验;

结论:是否真的需要推倒重来,始终还是要结合实际情况,外部及内部情况以及产品本身目前所处的状态,能够投入的资源综合考虑!

匿名
飞翔的小鱼儿 某大数据公司 产品

每一个产品人都应该有一种觉悟:懂得站在前人的肩膀上。虽说产品很多时候讲究颠覆,但颠覆也是一点点的积累、调整致更优解,等到市场发展度、用户认可度、产品成熟度三者协调一致才能取得颠覆的效果。

所以对于这个问题,我们先定义重做的概念,我把他分为两种:1、界面布局、交互、或者个别页面逻辑重做,2、产品核心功能定位,包括:用户需求、使用场景等定位不清的重做。

其次,我们可以把两种选择定位到两种改进方向:1、改良派——优化,2、革命派——颠覆

1)使用场景

两种方向需要不同的场景下使用

a、优化:产品方向没根本问题,用户需求把握较准确,使用场景定位较准确,以上这些产品的核心定位只要不存在偏差就不需要第二种重做;其次业务流程、界面、交互等存在不明确的情况,需要重做

b、颠覆:经分析、沟通,产品定位不明、用户需求偏移,必须要求第二种的重做,重新规划顶层设计;另一种是界面、业务流程等交互效果不好,可以考虑改版,但首先考虑是否可以只需要调整局部就能修复。

2)产品经理心里诉求

导致产品经理重做产品有几个方面
a、产品更优化。前产品经理确实没能完成很好的完成产品设计,这个时候包括以上的两种情况:产品定位和产品交互。

b、理念不合,且成本不高,这个时候经常发生在产品设计中途换人的情况,产品只走到市场调研或者策划阶段,改动成本小,可以承受。

综上来说,对我来说产品拿到手并不会存在强迫症的重做。而是拿到手先实际分析产品状态,并结合公司整体规划和个人理念,确定定位的准确性;其次在交互层面都是可以调整优化,如果整体界面、交互效果很差,再考虑重做。

匿名
不羁老师 腾讯控股公司 商业产品经理

为什么喜欢推翻重建产品?

这个问题问得带有情绪色彩,产品经理并不喜欢重构啊,往往是因为现实的一些问题。

举一个切身的例子:以前负责过一款ERP系统,刚开始做的时候,我针对的用户群是公司内部的四五十名推广员工,做些简单的小功能,已经满足他们的需求了。

后来公司拿到融资,上市了。

公司业务发展快,推广部的人数也越来越多,后续慢慢地加了很多功能,为满足用户需求。

后来当推广人员到两百多人的时候,当前的系统无法满足需求。

  • 由于开始的系统架构就是供四五十人使用的,到了使用人数一多,请求过多导致响应缓慢,系统加载性能效率很低
  • 系统并发量增多,导致系统有问题
  • 底层数据结构,建表的时候一张表,增加字段都是一张表,涉及到联表查询,数据量过多的时候,就有问题。
  • 等等

这时候,我发现,系统已经无法满足推广员的需求了。


那么有没有必要重构?

重构的成本与重构的收益如何权衡。

成本:一个产品跟两个开发,从梳理需求、提供解决方案到最后的测试上线,需要花两个月时间。

收益:重构后,优化业务流程,系统的操作效率加快,提升推广部的工作效率

经过评估,最后重构了。


其实,没有无缘无故地重构,只有当系统无法满足当前的业务需求时,才会想着重构。

如果没事干就重构,那就是产品经理脑残的问题了~

匿名
姜半刀 亲亲小保 运营总监

此事不是简单的改革还是改良就能搞定的。还需想到与人情有关,旧的产品不可能是一个产品经理独立完成的,肯定是这个团队共同做出来的。产品经理离开了,团队对于这个事情的看法主要是两种感觉,要么觉得惋惜遗憾,要么觉得庆幸小开心。无论怎样这个团队都还存在的。作为一个新的产品经理,如何不尴尬迅速融入这个团队,是一个比产品变革更重要的事情。

建议两件事情都是需要操作的,不应该只选其一。首先了解旧产品,尽可能分析发掘所有存在的问题,包括UI、逻辑、产品内容等各个方面。增补版本,做改良和微调。同时着手新版本的迭代准备,两件事情交错的进行,一方面保证产品的正常运营,另一方面给大家一个更高的期待,等待新版本的出现。

这样才是个有情商有智商的产品经理。

上来就改革的,过于激进,很容易让团队不积极配合,导致产品出现问题。

如果什么都不在,只是修修补补,老板会觉得自己选错了人。

想清楚了,就好解决了。

匿名
Somnus懿 养伤中 一个经常瞎操心产品变现的PM

能优化肯定第一会去优化,因为重做的成本比较高

但是,一些老功能或者说经历了N个pm的产品总会有这样那样的不足,有的考虑场景较多,数据表建立的比较完善;有的考虑不足,只为满足功能而做,随着时间推移真的是走不动了。


我是后台产品,对于是否考虑推翻的时候,第一要考虑的就是要业务理解程度,通过加之所在公司也是业务驱动,所以只有很好的了解业务,才知道索要做的功能的商业价值。所以我接到新系统的时候第一做的就是优化,因为不了解,所以不敢动;

当在优化和实际体验中,发现现有功能有很大缺失,同时部分调整仅简单的优化无法完成,只能拉上业务开会,阐述观点,若业务同意才会进行推翻重建,而且在重建完成后,历史版本和重做版本并行,给业务熟悉世界,经过熟悉周期并收集业务反馈,若没有问题则进行系统切换

其次就是数据统计需求,很多时候是一朝天子一朝臣,每个人对数据的理解和埋点定位不同,如果有数据需求没有挖掘或者记录,现有表单中许多冗杂废弃字段,然后根据优先级,同时结合考虑公司战略层阶段等角度去考虑,进行底层重建。

当然,也不排除有新官上任三把火的情况,希望通过重建来证明自己,有时候也不能说是为了证明自己,每个人的工作方式和方法都是不同,行为习惯也是有差异,希望推翻可能更多的是希望按照自己喜欢和熟悉的方式来进行。

个人经历:

后台CRM刚接手的时候一脸懵逼,熟悉业务以后开始慢慢优化,部分走不动或者底层不支持的模块,在足够了解业务场景和底层数据时,进行重建,然后两个版本并行并让业务同时使用检验。业务反馈OK,那么邮件通知切换时间,然后到时间直接切掉原有模块改用新的。好处就是业务有适应过程,检验不足,缺点就是周期略长

匿名
残品经理Hardy 今日头条 资深产品

推翻重建,还用得着你么?

我反对一上来就推翻重建,老的版本不管你觉得多不合理,都有他存在的理由。新来的产品经理要对每一个老产品抱有敬畏之心。就像中医理论它再荒谬,中药里还是有研究和检验的价值,我们可以废医验药。

基于现有版本进行小幅优化,不断的观测数据,是最有可能找到症结所在的。重新搭建反而重置了所有的变量,打破了平衡,你无从知道做的更对了还是更错了。当你了解了大部分的问题原因之后,把所有的改善方案摆在领导面前,那就无所谓推翻还是继续改良,那只是手段,并不重要。重要的是让产品更好。

另外,能化腐朽为神奇,也算是产品经理的本事之一,如果你永远觉得重建才能够实现乌托邦,那么你只能永远在重建之中循环。

但我觉得产品经理一定要敢于突破现状,不要被现状框住,不怕推翻和革命,敢于面对质疑和挑战。一切为了产品价值提升,不计手段,不畏强权,这是我所提倡的。

匿名
JenniferWang 互金行业 高级产品经理

从顶层思考,首先了解,目前的产品在公司的战略地位,如果目前产品仅仅处于一块鸡肋处境,那么分析ROI是否还值得去这样做,每个决策都应该都数据作为支撑,才可以做到有理有据,能说服别人,也能说服自己,如果仅仅是因为刚到一个公司,要出业绩而推翻重来,无异于浪费资源。

再来讲,如果产品处在公司战略的重要地位,那么分析公司目前在什么处境,每个阶段公司都有自己重中之重的任务要完成,资源就那么多,集中力量打好攻坚战,才是最重要的,再回归到成本的角度,就知道应该如何来决策;产品坑多,涉及范围之广,影响之大,都是推翻重来需要考量的因素,就像医院,除非不得已,性命攸关才会考虑截肢处理,但凡能做个手术可以恢复的,何必大动干戈;

匿名
Mrr 北京高歌讯风科技有限公司 产品运营

说说我所在公司遇到的事情吧。

由于原型图并没有准确描述具体细节(这个问题也沟通过很多次,多写细节,设计和产品不写),说时间太短,先开发,不行再改。好,接着开始按照A思路开始做,做完后提交测试,然后测试和设计沟通,对,你没看错,是测试去沟通,沟通完了说这样不行,出了个设计B,然后技术改,改了2天,细节的东西改好,上线,大家相安无事。奇葩的来了,设计人员离职,新招了一个设计,这个设计刚来的主要任务是优化现有设计,这下可好了。设计说,这个设计不行,我们得按照A的模式去改,WTF。你在逗我吗?最后是不得不花更多的时间再改回去...

产品其实也是这样。每个人有不同的风格,侧重点不同。你可以说通过后台数据和用户反馈来调整,but,在我司看来就是痴人做梦!!!对于不做用户调研的产品其实也很无奈。毕竟产品上面,还有老板,老板说了算...

只是吐槽,说是我遇到的事情。

匿名
耿彪 实战电商学院 执行秘书长

其实推倒重建并不是产品经理才会的技能,在各行各业中都有这样的现象。而产品经理是直接接触产品的岗位,对于产品的认知度和敏感度要高很多,所以我们才会单纯的认为只有产品经理才会这样做。

举个例子:产品经理在产品初期进行了产品的规划,然而等到产品做出来,投入到初期的市场中会经历长短不一的时间,而一款产品甚至要经理多个测试阶段,少则三五个月,多则一年两年,在这个过程中产品需要和用户需求时常会发生变化,这样一来原有的产品已经无法满足市场,所以产品经理会在这样的情况下推翻重建,这是普遍的现象。

第二类的就是对于自己的产品有着类似于严苛的要求,所以修改的版本就会更加频繁。一般的产品经理会几个项目之后出现改动,而有的甚至会一个项目一个改动,甚至于天天都在改动。这还只是改动,推翻重建的勇气就会更大。

众多周知万达电商前期一直建不起来,除了与企业本身的流程审核制度有关,还与不同领导思维不同有关,这样就会使得产品多次推倒重建。

当然,这样对待弊病就是产品在搭建过程中耗费太多的时间、经历和财务,甚至使得企业产品一度处于停滞的状态。

所以,最好的就是确定大方向保持一段较长的时间不改动,其他内在需求可以存在,最后每个一个时常推翻原产品,推出新产品,这也是产品经理的职责所在。

匿名
RexQ 百拓商旅 产品经理

无论是改革还是革命,都要看代价。

首先,产生改革和革命的冲动,都很正常。有三种可能:1.自身对于产品的业务流程不是非常了解,产生了对于产品的误解;2.因为市场变化,产品与使用场景不是非常贴合;3.个人喜好影响。

第一种,需要深入了解产品,关注用户使用产品时,你认为不合理的地方是为什么;

第二种,市场变化导致的需求变更,需要在最小代价成本的情况下,看看如何优化;

第三种,去适应产品;

我感觉,正常接手一个旧产品,应该是上面三个原因多多少少都存在,纠合在一起产生的。

具体是否需要革命,可以和BOSS讨论一下,成本以及未来产品发展,最低的成本获得最合理,最合适的产品。

匿名
蚕豆豆 某IT行业上市公司 上网打杂
  • 看数据,先改良。(牛刀小试)
  • 熟悉业务后看改良后的数据,对比改良前后数据变化。(对比)
  • 了解业务后再对比是直接推翻重建好还是接着优化改良好。(考虑重改利弊大小)

作为新手,老老实实坐修补匠,先缝缝补补,做作对比最重要。

业务熟悉之后可以牛刀小试改版一些不那么重要的点,对比改版前后数据变化。

业务熟练之后摸清旧框架优缺点,先画原图设计你要的“房子”框架。最后再重建产品。

这个题目一开始就感觉没有提到点处,没有哪个产品经理牛逼到一进入公司就能够把公司旧的产品剔除掉,然后重建一个新的产品。即使上头同意了,手底下那批辛苦搭建老产品的人也不答应啊。

匿名
鬼谷 腾讯 腾讯商业产品经理

首先一刀切就是个不懂的问题,什么叫产品经理喜欢推翻重建;问题怎么能这么提?如果问题是:题主为什么喜欢同性?这不就直接给你先把帽子给扣上了?先问是不是再说为什么!

首先重构的肯定是原来的架构不支持现在的业务才需要重构,而不是为了重构而重构,为了重构而重构老板工程师非搞死你;而且重构的工作量比修修补补的工作量要大很多;而且做出来不一定比现在的好;所以重构的前提一定是现在的架构无法支撑业务才需要,我们自己有时候也会重构部分业务和代码;而优化叠加才是常态,谁没事干一天重头设计整个系统架构;

匿名
查看更多

发表评论,请先 登录 · 注册

合作伙伴

诸葛IO
薪人薪事
拉勾
 阿尔法公社
测试兄弟
Growing IO
BOSS直聘
环信
外包大师
CSDN