[干货] 如何 0 经验做企业端项目（整理中）

希望伙伴，从项目开始，注意将所有资料(与项目相关的对话截图、邮件、文件、录音等)都放在一起，直到最后封存。一方面便于查找，另一方面便于自己复盘。

PS：为了能让更多0经验的伙伴学到更多的东西，接下来我将逐步细化。在此期间，给阅读带来不便请谅解。同时，也希望更多的人能分享干货，解决问题，而不是理论。这也是为什么许多书和文章看完了很爽，做还是不会做，因为你们读了太多理论。

0.沙盘推演

 对于0经验的B端项目，最难的可能就是无从下手。而且如果是第一次合作的项目而言，可能只给一次机会。那么，如何利用当下条件做好这件事呢？  于是想到了沙盘推演，这四个字有很多定义，我的理解是战前模拟演练。记得原来在下五子棋比赛的时候，面对陌生的对手经常要在脑中模拟上百遍各种情况，只为了能找到一个赢的战法。

0.1 找棋谱

  拿到的是订机票的合作项目，在与B端接触之前，看了看市面上两个知名的产品：携程和去哪儿。以小白菜的心态分别玩了2遍，然后用 纸和笔 去画了一个订机票业务。当自己不知道怎么做的时候，会向先人学习，就像学习先人留下的棋谱一样。

因为自己不容易集中精神，所以会经常只带纸笔手机找一个干净的地方去整理思路。视野内的事物越少，越容易专心做事。当然，每个人都有自己的办法，这个不拘泥于纸笔。

  我是一个野蛮生长的产品，所以只会笨办法--实践。按照自己画的设计，假装是用户亲自去买机票试试，一路将自己的感受，想知道的信息以及问题都记录了下来，然后在对比已经上线的产品看看，别人是怎么处理的？为什么？  经过几次修复之后，仿真品已经初具模型了。

0.2 流程再造

  因为我要做的是通过语音交互的方式来获取用户信息，并以语音的形式将结果告诉用户。所以，需要根据自己的需求将初始模型进行改造。    第一步：机械式 。我一般是习惯将一个产品从逻辑层到用户层进行纵向拆分，然后在逻辑层上进行进化方向的拆分，第一步，只要求能从头到尾的走下来。    第二步：正常人模式 。在机械式的基础上，会模拟一个正常人在不同场景下进行标准话式交互，以此来不断丰富逻辑。    第三步：调皮捣蛋式 。在第二步的基础上，会模拟一个诚心捣乱的人来玩这个，比如：说着说着突然松手了，语音不全造成必要信息缺失等。   以上三步目的是尽可能的发现这个产品更多的问题，每一步到想不出来即可。

0.3 自我思辨

  此过程主要是模拟两个小人来对话，试图通过多角度分析的方式，以简单好用舒适为核心，对流程再造后的模型进行剪裁和完善。比如：在查询结果，语音输出的情况下，因为受技术和交互方式的影响，所以要尽量言简意赅的同时还要满足用户核心需求。  如此，我就会问自己，没有什么信息你绝对不买这个飞机票？钱，还有什么？... 期间会发现用户在购买东西的时候是有一个很长的决策链，因为人脑是一个单线程CPU，同时只能处理一件事，因素间一定有优先级存在。

如此，经过沙盘推演，一定会有许多问题和自己的猜想存在，接下来就是寻求答案的阶段--收集信息。

1.收集信息

  收集信息阶段，个人建议，不管你有没有经验最好都要从0开始，保持空杯心态。因为环境等因素一直在变，固守原有经验可能蒙蔽你的眼睛而看不到新生的变化。这个阶段，腾讯的伙伴做的比较好，他们有一个比较好的体系，大家可以多与同行交流，多学习。

两点需要注意：

1）自己先行
2）保持和一线业务人员及目标用户充分沟通

  我一般喜欢问别人之前，自己先尽可能的了解清楚，然后有问题有针对性的去请教别人。一方面，锻炼了自己。另一方面，可以节约对方的时间。在询问对方的时候，要记得你的目的是获取信息，而不是去理论和争辩，就把自己当小白，专注自己眼前的目的，别人怎么评价你，是别人的事，你管不了，也没必要浪费时间。当一个能做好事情的小白吧，哈哈～

1.1 自己先行

  拿到项目以后，我一般会去从各个方向进行调研，当然这也要看你的时间和目的。比如，当你想要在行业战略上布局，那你就要看清这个行业，以及你面前的这个企业是否为龙头，是否能为你打开整个行业做强有力的信任背书。  但是，当你没有这个时间的或者目的没有这方面需求的时候，你可以选择性的去调研信息。如果有可能，我还是挺建议大家做全，像CEO一样思考，甚至比CEO看的更清，虽然你不用去决策，但有时候你看的更远，会把产品生命力做的更长更有活力。而且在小公司，有可能CXO也会和你聊这些，因为你是一线，了解更多内幕。同时，在此过程中你会成长过多，甚至可以请教CXO来学习，丰富自己。不过如果不是CXO主动问你，你最好不要轻易说这些，可以留在心里做验证，因为什么你懂的，具体还要看你的环境哈。

1.1.1全局看

拿到一个项目，一般我会从各个角度去分析，每个角度都会有不同的收获。

举个例子：
玩地图的时候，可能都体验过缩放。以手机版的百度地图为例，当你无限缩小的时候，你会看见这个亚洲，这时候，中国就是一个整体，你会看到蒙古在上，蒙古的上面俄罗斯那么....大，一定是偷了咱们国家的地，哈哈。这时候你在把中国当作一个整体，去分析和它同等级的事物。

   OK，来咱们放大，当你看到省市的时候，你能看到兰州，重庆，昆明...，再放大能看到区县...。到此为止，有没有人想过，为什么在看到区县的时候，看不到省市，看不到俄罗斯？  有人会说，不是一个地域级，百度地图就这样等等，想想你会看上海是否挨着俄罗斯么？但你会看到中国和俄罗斯挨着，上海在中国里面且不是在北边。   其实，这是基于咱们的目的和视野所限。  目的，当我们目的是只分析上海和俄罗斯的位置关系时候。我们只需要地图上显示俄罗斯和上海就可以，其他不希望标注，因为它们会让你眼花缭乱！与你的目的无关。随着我们的目的不同，会看到不同的区域(这个区域是泛化，可以是视野区域，可以是心里区域，可以是大脑区域等等)。   视野，我们的视野有限，而且处理复杂信息的能力也有限。所以我们需要将事物进行分层看待，从不同层次去看，有侧重点的去分析。（同时，从不同层次看有利于建立金字塔思维，因为大脑总是在不停的进行自动归类，当你给的信息过多，分析归类系统就会忙乱，你也会感到不舒服。具体可以看《金字塔原理》这本书。

下面，我们将整个项目作为一个整体进行 全局看

• 将这个项目扔到市场上

分析行业情况及发展趋势（整体分析）
逆趋势的项目未必是好项目；超前趋势的项目有诸多不测需要提前预防；落后趋势的项目虽然会有很多前车之鉴，但同时也可能是快被淘汰的；趋势中的项目前有借鉴后有参考，平行有诸多竞争，压力则稍大些，所以需要分析下全局的情况，这样我们才知道该注意什么，哪里需要着重，哪里需要剪裁。

1）分析发展趋势和与大趋势相符的龙头企业[ 横向分析 ]
分析发展趋势要多看历史变化，分析什么因素导致了历史变迁，少看分析家的个人观点，多看事实依据。分析龙头企业，借鉴经验(了解)，学习(熟悉)，逆袭(改进)。

2）分析行业上下游，看相互作用情况[ 纵向分析 ]
看上下游可以看到业务链是什么样的，相互之间的牵制关系又是什么，以及发展趋势。有可能你所做的东西，正在被上下游慢慢吃掉，比如中关村的柜台电脑零件售卖中间商，此时你还要做柜台么？你愿意也可以。

分析同行情况及发展趋势（局部分析）

1）看竞品公司，发展脉络(发展史等数据)，公司间关系[ 横向分析 ]
2）看竞品，分析竞品优缺点并追其原因(竞品的优缺点可能是公司、产品经理、技术等因素导致，切莫光了解优点缺点就停止，因为有些缺点你可能不会出现，有些优点你也学不来)，竞品间关系[ 纵向分析 ] ，有时候看竞品看多了，会发现一条Copy链，然后你只需要看源头就好了。

• 把项目扔到公司内

向内 ：此项目对于公司内的影响：产品业务、资源(有时候B端业务做好了会带来资源置换)、其他(资金，团队士气[做了一个很有名的单子]等等)

向外 ：此项目对公司在外的影响：声誉、行业资源、竞争力、其他。会不会因为这个项目与B端发生变化，关系上、发展上等

1.1.2 局部看 (整理到此11.26 24:00)

层次分析：看你做的项目是否是B端的一部分，如果是，尽量整理出层次关系，例如订机票：

• 整体上 ：

1）看此项目首尾连接情况
通过订机票的上链接，我就知道这个项目的目标人群是企业人员，同时通过对企业业务了解，发现他们这块业务是刚刚开始做，他们在这块业务是全新的等等情况。（当然，我说的是微信服务号上的，电话客服模式他们早就有了）

2）看此项目的一线人员
谁是订机票的一线人员

3）看整体性限制
比如订机票的业务整体基调就是正式、稳定、效率。

4）看此项目的涉及人员
比如这个项目：谁是决策者？谁是API提供者？谁是12580方的产品？谁是业务员？他们各自的负责范围是什么？决策范围是什么？最佳沟通方式是什么？他们在组织结构中是什么样？他们各自的职位和个人诉求是？等
项目相关人员的组织关系图很重要，可以让你第一时间找到最有效的人，快速处理你的问题。

5）看此项目之前已经存在的问题
这个多数直接找B端一线人员或者使用这个产品的用户处分别获得。

• 局部上：

将项目展开，如果复杂需要你做多层展开。

横向：
看模块间关系，牵制及影响
比如：查询机票和机票结果之间的关系，机票结果是否能回道查询机票，是不是比如有查询机票过程才能到达机票结果，查询机票对机票结果的影响是？比如查询机票环节的时间不对，机票结果中允许用户修改？等等

看模块间传递情况
比如：查询机票给机票结果传哪些信息？这些信息需不需要第三方获取，如果需要，在项目估期时候就要考虑第三方的不稳定因素，如果有连调，还要考虑连调造成的项目延期等等因素。

纵向：
看单模块内部情况
比如：查询机票需要从用户哪里获取到时间、地点、仓位等信息，在对话交流获取信息中，如果用户没给你时间、地点，你要先问那个？内部问答流程是什么？用户会不会有捣乱的情况或者喜欢性缩短说话？例如：5号，这个5号是这个月的？还是下个月的？

看单模块对外连接点
比如：收集完信息，最后一步再进入查询结果前需不需要让用户进行二次验证？等

看单模块影响质量的因素
比如：查询模块最后的信息准确率会受语音识别准确率、语义理解准确率等影响

到这里，是不是有1000个草泥马在心中跑过？为什么要这样？一方面，你只有比B端更了解业务，才能做出好的产品，另一方面，在这里过程中你会有很多疑问和不知，带着这些疑问和不知去问B端人员或者用户会更有收获。反而没有准备直接去问会收获很小，因为有时候你不问，对方也不会说，甚至有些他们都没想到等等。

1.2 找到核心，项目边界

这个阶段，要找到项目的核心是什么？什么是主要的？什么是次要的？项目要做到什么程度？时间给多少？验收人期望的结果是什么？

这个阶段主要是和各个相关人做博弈的时候，切记一定要尽可能的把需求确定下来，做到什么程度，做成什么样，越细越好，拍死了（你能确定多细，全基于你前面的调查和对业务的了解），以后谁要改，就让他们加时间（保护好你的技术、设计哥哥姐姐们的心情）。

1.3 充分交流
经过1.1的磨练，到此你已经有一定基础了，甚至是砖家了。此时，需要从头开始将这个业务流程和一线人员或者相关人对一遍，看看你调查的和他们实际操作的中间是否还有问题。不懂就虚心问，千万不要装明白，后面死的就是你。

2.项目实施

项目实施阶段，不同项目可能复杂度不一样。但只要抓住关键点，还是可以做好的。记住项目的管理核心是时间，任何的问题和变动都围绕时间而发展。不断的时间拖延，只会让团队感觉疲劳。如果想做更好，可以放下一个版本，让大家在心里有一个阶段性的休息。

2.1 版本剪裁

1.项目层分大功能版本。

在一定时间内，先划分出一个不超过60%总时间的基础版本，这个版本只留下核心功能，核心功能是对这个项目而言，没有这个功能则不能使用。比如：对于B端API平台，没有登录注册也能用，商务可以在后台配置，那么登录注册就可以后做等，只不过会让商务忙碌一阵。但是，如果API平台，没有API是不行的，这个就是必做功能。

之后，在划分阶段性版本，版本的划分仅对当下阶段情况而言最重要的优先。

2. 各版本内在进行小版本切分

此版本切分，尽量保持模块间低耦合（相互依赖低），尽量保持单人短时间可完成。这个目的在于快速沟通和测试。

我切的小版本基本上都是一个人1-3天，如此每天早晚会和相关人员及时沟通，看看是否有问题，保持及时沟通可以了解整体情况以及在初期就发现问题。项目管理或者产品经理，都是对项目和产品管理，而不是对人管理，人只是帮你较好的完成这个项目而已。PM在团队中主要是协调，使整体向既定方向发展，那么对于协调岗位而言，沟通是必要的。

此阶段，希望尽量粘死技术负责人：哥，这个能做吗？有其他办法吗？你看这样行不行？这个这么难，大概要花多少时间？...记住，只是调查，不是确定要做，所以不要给技术透露过多肯定的言词。

2.2 内部项目评审

内部项目评审的时候，我们最好按照“金字塔”模式(金字塔原理是本书，有兴趣可以看看)来叙述。先确认项目方向和核心是否正确，再确认顶层框架是否正确，再逐个结构展开，

细化。如此，内部评审人员可以分阶段听，有些人听完方向和核心就会走了。因为方向对了，核心对了，剩下的就是怎么走了，总体上不会偏移。

说到这里，有些人会说了，你前面划分不是白弄了嘛？其实不然，在你划分的时候，其实是你需要考虑所有资源的时候，划分完后，你可以很清晰的知道哪些必做，哪些不可做，哪些费时间，哪些问题可能会大，这样在评审的时候，让你更有自信来表达。否则，对方一问，你都没考虑过，只能打鼓脸冲胖子的自己臆断，为了保持自己不被看扁或者评审会上露怯。知己知彼，方能百战百胜，你需要比评审的所有人都了解全局才行。

内部项目评审是最终敲定要实现什么，以及谁负责配合哪部分，那个决策人对哪块内容负责等。记住你是协调人，不是决定人，所以，你要做博弈。当遇到和自己想法不一样的时候，如果你没有经验或者不是很确定，请记录下对方说的想法，并先尝试做做。如果做出来不错，那有可能是自己问题，如果做出来不对，就立刻分析不对的原因，并找到解决办法。最后，嘿嘿，当初谁说的来着？找TA，有理有据有气势，哈哈 （偶尔逗比一下，毕竟所有有人都希望做好这个项目）

评审会议结束之后，先解决会议遗留问题，然后重新整理，带着整体资料找技术聊。

2.3 可行性分析

继续粘着技术哥哥们，是们。在这里将项目总体概括性的和技术沟通下，看看其中还有没有潜在的技术风险，哪些需要自己去协调和调动资源。这里尽量让每个参与的技术都张嘴表达，让技术负责人尽量少评论和碾压。

这个环节的目的是让大家充分了解项目，以及对后面可能遇到的技术瓶颈，提前做出准备，同时，通过技术表达，对这个项目去区分哪些是突破型拳手，哪些是老司机，哪些是稳定输出，哪些是打酱油的。

这样，有利于你和技术负责人划分人员，如果你公司是民主自由的，你需要在关键点做出不合适的判断。在项目实施过程中，还要有针对性的对打酱油和突破性拳手增加沟通频率，突破型的容易进入挑战疯狂模式，需要及时鼓励，夸赞，引导。打酱油的需要看看进度和质量，鼓励，备份等，所有拳手要提前交代好，任何问题只要1个小时没有想法没有头绪，就立刻和技术负责人、CTO等有经验的人沟通，无解就要立刻和PM及时沟通，不是说明技术不行，而是要保证整个的进度。不要在一个点上浪费太长时间。做一个黑脸时间管。

将技术的所有情况了解以后，下来自己整理，然后与相关技术单聊，没问题以后，开始排期。

2.4 项目排期

1.先排基础版本，后续版本等基础班快完的时候再说。

在项目排期里，我建议评估时间为：1、2、5、8、13、20、30. 如果技术说要10天就记录为13天，因为时间越长，其实准确度越低，而且随着时间变长，中间不可避免的会插入及时问题。

他们说完以后，你自己记录时候，每个时间要乘以1.5(这个是风险系数（包含人员生病，因其他因素拖延等问题。这个系数根据团队自己衡量，我遇到比较好的团队能做到1.2，还有的要2.0)，然后用OmniPlan或者其他工具排期。但是你对上说的总时间要X2。这个是你最大极限，若过程中发现团队超过了1.5，则需要你赶紧查找问题，及时解决。

2.排自己的进度表

项目排期，什么时间需要调度什么资源，什么时间需要检测，什么时间需要开始下一个版本等等。你要比技术至少提前2天开始。 自己的表自己看，同时记录每一天发生的重点事，作为自己的项目经验积累，比如12号，某人生孩子了，记录下，反思自己为什么没考虑到，等等。

如此，开始吧

2.5 保持沟通和效果追踪

每天至少要早晚各一次与相关人员沟通以及追踪效果，便于调整。

初期的沟通重点是项目，确保每个人都清晰，我们在做什么？我们做的目的？对TA有什么好处(鸡血、大饼...)？等等。

中期和中后期，重点在对各个人员情绪变化的追踪，及时关注每个人的健康情况等（你的伙伴在专心努力，你则要做好你能想到的事，如此才能保证整体的前进步伐）。

后期，重点在项目质量、人员心理变化、进度等方面

每个时期的重点都是动态的，根据自己的情况调整，发现问题尽早解决，不要拖..............就好，另一个，如果你是PM，记住你就是打杂的，精通业务、心理、管理、沟通、情绪控制的专业打杂！哈哈，我一般都定位为小白心态，因为这样才不会蒙蔽眼睛，发现更多问题。

再说一遍，如果你是PM，你是做协调的，让整体保持良好运转。

3.测试和验收

测试是最费时间的阶段，同时又是很重要的阶段，因为需要通过测试来检测项目质量，可以透过忙碌之下，看到项目本质的东西。但是，测试往往又是恶心的阶段，同时又是比较难的阶段。

3.1 测试

这里我先简单说下测试方法：

理想条件测试：

1）全程测试

主要目的看能不能从头走到尾，哪怕是机械的，输入固定的。

2）全路径测试

是这将测试部分的流程图画出来，然后把每条路径都测试一遍，看看有没有问题。

3）全量测试

正常值，边界值，超边界值，临界值，意外值

举个例子：六位数字密码

正常值：238753
意外值：你是逗比吗？，999.88，iamcat，空格
边界值：999999，000000
超边界值：1000000，10000(位数)
临界值：999998，000001,99999,00000,空(值和位数)

测试不只是结果，测试时候将遇到的情况所感受的情绪放大，然后顺便做下用户体验优化。

下面来说说测试重点，每个项目的侧重点都不一样，所以要根据自己的目的而有阶段性的测试。
比如我的项目是对企业用户，所以测试是稳定优先级最高，然后是效率，最后是用户体验。
但这个也往往是用户的逆向感知，用户拿到手第一反应是好看吗？用着用着顺手不？卡壳不？速度反应快不？最后是，能不Crash吗？

所以，由于时间有限，我就将稳定设为99%稳定，效率在1秒以内，用户体验整体不需要操心费脑子，美观？呵呵哒，看时间吧。

为什么如此？你再美再操作简单，老Crash，你受得了？尤其是着急买机票的时候。好不容易稳定了，买个机票一个操作给我2分钟后才回应，起急不？

做任何事，想想重点是啥？哪些可以妥协，哪些不可以，不是你说了算，是用户说的算。

现实条件测试：

此时，让朋友或者目标用户替你试用，不要有任何指导和解释，只鼓励和倾听，如果面对面，观察下TA操作的停顿点，表情的变化（困惑？欣喜？），操作顺序是否如你所想等等。

3.1.1 小测试

在项目实施过程中，要按照小版本进行快速测试，目的是尽早发现问题，一方面是技术问题，一方面是项目设计问题，便于快速调整，以及后续版本避免同样错误。

3.1.2 阶段测试

一个小阶段（3-5个小功能）就要测试一下，看看问题，因为前面小测试，已经尽可能的测试好每个功能了，所以这次重点放在功能之间会不会有问题。

3.1.3 全局测试

将版本整体测试下，重点在整体的稳定性和反应速度上。

3.1.4 全民参与

一方面是发现BUG，另一方面是极速提升和收集用户体验反馈。

以上将的东西要灵活运用，不要机械化。比如：小测试时候，我就可以全量测试+现实测试，因为需要快速反应问题。如此，可能没有走过全路径，但是对于你当初的一些设计意图，可以得到快速的反馈。

做PM一定不要死，分析问题，找到合适的方法来解决就好，不要拘泥于条框，固定思维。

3.2 验收

验收是给别人看的，其实项目如何自己最清楚，但要记住底线是对的起自己。当然，混也能过去，但最终是浪费自己时间，在做一件没有意义的事。

3.3 复盘

好啦，交差了，爽吗？先别急休息，立刻复盘整个项目：
复盘对于下围棋的人可能不陌生，下围棋的人有时候下完了会在脑子里过一遍，没走一步都会问自己，如果不这么走会如何？尽管下了一盘，但复盘给他增长了100盘的经验。

在团队里复盘，通过不断问对方，引导对方让其发现问题所在。不对人进行评论，聚焦在项目上。角色分工为：主持人，讲述人，提问人。主持人负责维持复盘的稳定。提问人在倾听讲述人讲述项目的过程中，记录学习点、问题点，讲述完以后，提问他。讲述人是讲述项目的人。团队里每个人都要讲，所以讲述和设问的人是相对动态变化角色的。
（建议控制在5人左右一个小组，分组进行。）

讲述内容：

[1]项目目的
项目目的是什么？重点是？

这主要反应项目或者产品有没有讲项目与相关人员沟通到位，传递到位。

[2]结果对比
结果如何？自己预期结果是什么样？最后结果如何？满意吗？为什么？

这个主要看团队人员对于这个项目是否满意，对自己的结果有和感想

[3]叙述过程
讲述一下，自己从接到这个人物到完成的过程 （此过程不要打断讲述人，认真倾听，有问题请记录下来）

[4]自我剖析
在这个过程中，自己有哪些问题？（看看你记录的问题，他自己是否认识到了）

[5]众人设问
大家根据讲述人说的东西，进行设问。设问有两个目的，一方面是学习，一方面是引导。

比如他说自己在做A功能时候迷惑，
你可以问：“哪些事情感到迷惑？”
回答：“没有方向，不知道该怎么做，该做B呢，还是做成C就行了？”
问：“做B会怎样？”
回答：“做B的话，我不知道能能否让反应速度达到2s以内”
问：“哦，有哪些因素影响速度？”
...一步步的分解下去，直到找到原因，注意语气要平和，要慢，配合对方思考的节奏。如果你说的太快，会有种步步紧逼的感觉。也千万不要说“我觉得应该这么做，这么做”，如此你帮了他一次，下次还能帮么？永远？得让他自己明白，自己学会分解问题，发现问题本质，整理自己的思路等

[6]总结规律
主持人做一下简评，很客观的评价讲述人做的值得赞扬的部分。针对他不好的地方或者不足的地方，找个对应的主题希望他能抽空做下分享。比如他登录没做好，“XXX，表扬。。。。。，对了，看你能不能抽空就登录部分给大家分享下，相互学习下....”,为了讲好这个，他要做准备，并且通过分享与其他人交流，进一步弥补了自己的问题。

一般，优秀的伙伴，都有自知之明，知道自己问题会自己弥补。如果你发现某人一直都是油油滑滑的，做事也不好，还总包装自己，这样的人就要早点处理为好。人做事不好可以改进，人不行，那就是严重问题了。

总结以后，换下一个人继续讲述。

（团队版本）复盘的主旨：
对事不对人的进行剖析：

1）提问不带主称位
比如你怎么没做？，最好是这块怎么做好呀？

2）提问不能用反问，
比如：怎么不这样做？

3）人有优缺点
在交流中，体会伙伴的感受，设问事为了帮助他进一步深思。

复盘也可用于自己。《复盘》也专门有这本书可以看看。
在此送给想要提升自己的一句墨子的话：行有不得，反求诸己。

木溪：AI产品，4年创业经验，历经前端架构、合伙人、产品。人工智能的产品群（QQ群：116211197）

关键字：产品经理

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！