让我们心平气和地聊聊代码与产品

本节目由津津乐道制作播出。

嗯，

没有，

我没有各位听友大家好，

这里是津津乐道与生网联合制作的博客栏目编码人生，

这是我们的第一期节目。

那么相信大家已经在预告片里面听到了啊，

我们的这档节目会聊什么？

哎，

那第一期节目呢我们就来个拉仇恨的话题吧。

小白好啊，

今天天呢让我们一起来聊一聊程序员和产品经理之间的这些故事。

哎，

今天的主播和嘉宾呢除了我和小白以外呢，

还有两位来自声网的嘉宾啊，

呃请他们分别介绍一下自己吧。

那你们俩谁谁先开始。

hello，大家好，

我是毛玉洁。

啊，

目前在主要负责这个相关的呃技术架构的工作啊，

那个在深网也已经有啊五的五年的工作经验啊，

目前在从事一些呃浏览器相关技术的一些开发工作。

那你是什么出身技术出身就是上学学的就是技术。

对，

嗯，

然后现在做的也是技术。

对，ok 那云一介绍一下自己吧。

好，

大家好，

我叫胡云烨。

那来自深网，

现在是 iot 行业的产品负责人。

那我呢是曾经是一个差点成为航天工程师的初我的 psd。

那加入互联互联网行业呢已经快六年多的时间了，

一直在从事嗯和 ai 啊人际交互啊，

实施互动相关的这个领域。

然后去做一些我自认为可能是一些有温度的技术产品吧。

嗯嗯，

哎今天这个话题大家听到了哈，

有点拉仇恨了，

呃，

分别请来了一位程序员和一位产品经理，

跟大家聊一聊哈。

呃呃，

其实我们所有的开发者其实在日常生活当中或者工作当中，

其实都会遇到一个怎么讲呢？

一个梗吧，

是吧？

小白就是这个产品经理与程序员之间的矛盾。

是的，

天天都听着说，

哎，

程序员跟产品经理又打起来了。

对吧我们快去拉架，

产品经理又改需求了。

陈轩要打人了，

各种各样的梗。

对，

各种各种这种也不能叫是个梗吧。

就是大家总觉得呢开发和指挥我开发这两件事情永远是一个矛盾和对立。

是的，

我们觉得说呢大家这两种工种其实是应该是一个合作的状态状态不是说我指挥你，

你去做什么，

或者是啊我就一定要去听你指挥。

其实大家更多是一个合作，

我们是共同去达成一个目标的人。

程序员和产品经理分别说说自己不爽的地儿吧。

程序员先开始吧，

对吧？

嗯，ok 好，

我可以说一些啊说几点那个因为之前其实那个无论是在做开发，

无论是在做架构设计的时候，

其实跟产品都有非常亮度的一些合作。

啊啊，

我大概说说几点，

那个是一些工作里面的一些体会啊。

那么第一点的话，

其实啊我可以称之为叫需求变更啊。

那这个变更的话不是说经常变化啊，

他们有的时候会根据自己的一些对于业务的判断啊，

有的时候会临时插入一些需求。

啊，

那么在客户没有真正的理解客户的需求的时候，

他也会去对于这个需求会发生一些变化，

理解会发生一些变化。

然后除了对于需求之外，

他们还非常关注。

于是说我们必须要在一个星期啊把这个需求给做出来。

嗯，okok 啊，

除了对于交付时间啊，

程序员其实很多时候呃会认为是说我们写完代码就 ok 了啊。

但是你呃最后我们会从产品那边得到结论是说，

哎，

哎，

为什么你呃你你你只是做完了，

就就也就是你没有文档啊，

你没有交付一个结果，

就这个结果不是我想要的啊，

所以对于最终的交付结果啊，

也没有一个比较清晰的一个判断啊，

这是我我认为的是第一点，

就是一个需求变更啊。

那么第二点啊是我一个呃就是还比较切切身的一个一个例子啊，

就是呃我之前其实也做了很多的需求，

嗯，

啊，

那么这个需求做完之后就也是做完了，

我完全没有任何的就是体现出来价值啊。

因为就是你觉得你做的东西其实没有被真正的有效的利用起来。

对，

嗯，

就是这个时候挫败感特别强，

是不是挫败感没有特别强对。

所以这个时候我们一般就会说，

你看你是产品经理怎么规划的，

这个对产品对吧？

你看我我你你又催我一个礼拜做完，

然后做完你就不用了，

什么情况？

对，

说好的优先级很高呢？

对啊，

你急什么？

对，

就是说这一点就是我们自己因为做做出来的东西是特别希望有能产生人的价值。

对，

嗯，

那这是第二点。

那第三点的话，

其实就是还是一个比较典型的一个问题啊，

就是可能是产品经理跟程序员之间的这个思考的角度啊，

对不起嗯，

啊那个一个是更多的从业互联网名词又来了对齐啊。

对，

就产品经理更多的会考虑从业务啊怎么帮公司赚更多钱啊，

他这个产品怎么掌握的更好？

那程序员可能更多的就是哎我今天要用呃 c 加加做，

还是用加号做对？

可能我们更多的会去从一些啊技术的实现的这个原就是呃角度上去思考这个问题。

啊，

所以说那个在这个换位思考啊，

以及最终的这个交互这个这个标准上面，

我们可能是需要去有更多的沟通和理解的。

啊，

这是我觉得是说那个我们程序员跟这个产品经理之间会有一些对吧？

天然的可能就会有一些这样的一些对立的对对对立的对啊，

云逸说说吧，

他吐完你的草来来再使劲啊，

我终于知道为什么要毛毛，

先说了，

我就一直在对号入座，

你知道吗？

然后我就庆幸，

我不是对毛毛造成伤害的那个人，

但是我也对其他人造成过伤害。

然后其实刚才毛毛在说时候，

我也在回述啊，

就我三段经历其实有一个共性的点。

首先他都是土地一段的生意，

嗯，

或者 tob 单的产品。

那其次呢，

我都经历了从零到一的过程。

那所以因为这两个因素啊，

就是所以毛毛刚才提到的在在插入需求和一直得不到价值反馈。

这两件事情上其实我是非常有感受。

但是这里我要吐槽一下，

就是说其实大家平常经常说段子，

可能经常说唉那个呃程序员经常说唉那个这个需求做不了。

但其实真实生活当中我们不会这么不理性啊，

就是我们会感受到的是那个就是程序员对我们的质疑，

说这个需求不合理，

或者说你为什么要插入这个需求？

那其实这个时候我们也很委屈。

那我们我们会觉得说，

哎，

我们可能是梳理了来自客户的十几个需求，

我们已经做了很多，

并且经过我们的判断，

对于价值判断的优先级，

然后唉觉得这个实现的程度已经已经进进行过的梳理了。

那这是这是这是这是一类。

那另外一个就是对于价值反馈这一点了。

那这件事情其实在创新的过程当中啊，

拓拓展新市场的过程当中，

其实是一个非常正常的现象。

那可能就是我就是我们最终可能就成为那个背锅的那个伤害者了。

那还有一点呢，

就是可能我要反向吐槽了。

那那个刚才毛毛也提到也很多很多程序员非常有自己的一些技术追求。

那我也遇到过就是非常自嗨的那个那个程序员。

那因为我过去就是还比较长的时间从事 ai 相关的产品的孵化，

哎，

这些算法工程师非常容易自嗨，

非常容易自嗨呢，

他们哎呀深有体会。

对，

他们他们经常会说，

哎，

你看我是用的纯的深度学习算法，

我没有用任何的 ruber 啊。

是，

但是哎你的效果就是没有办法比，

就是经过了我们哎人工一些先验经验，

或者经过 rubbs 所所性所所结合所产出的这个结果。

那你对于客户最终是如何用的，

能对他带来什么样的商业价值？

你是没有认知的那这个时候就要跟他进行非常多的 battle，那这是一种自嗨。

那还有一种自嗨呢，

可能也是因为在创新业务相关。

那很多研研发其实也会对于自己的这个技术的这个实践的预判其实是有误差的。

所以我也经常被我的研发放鸽子。

对，

所以这两年可能是我在这个过程当中会想要去吐槽的。

两个比较重要的点是呃声网。

有一点意思就是二位嘉宾其实从事的都是一个 tob 的业务。

呃，

但是我特别想听听小白，

你曾经在大厂做过这个，

也不能完全算是 toc 吧。

这是。

但是我知道你在的大厂可能是一个有 toc 基因的大厂。

对那在他们这个整个的过程当中，

你觉得有什么词儿要吐？

呃，

其实整个 toc 这块我一直最想吐槽的就是我之前在大厂里面做一项目的时候，

嗯，

然后那项目呢是一个对内的项目，

对吧？

那对内项目它可能就只是对内部员工，

那我们肯定就是 toc 的嘛。

然后 toc 的时候呃，

公司在给资源的时候，

没有给到一个专业的产品经理。

所以就拉到了一个我们的秘书小姐姐来给我们做小姐姐和来小产品经理。

然后那一次合作其实还是挺崩溃的。

因为他没有产品经理的相关的一些经验，

然后上来就开始给我们去加需求，

而且会加一些可能奇奇怪怪的。

就是我我会会去直接去质疑。

他说 ok 那我们这个活动可能就三天就结束了。

然后你这个需求做完需要两天。

那我们在这种场景下，

我们是去做这个好，

还是去做一个另外一个事情，

可能会更有价值。

那这个东西对于他来说，

你要给人上课，

这是就是到这个时候，

他他问题就在于说，

他可能因为没有相关经验，

他不会去思考说啊到底哪个东西是我该做的。

他可能就直接觉得那这个东西我就要，

然后这个时候我们就很容易产生冲突。

嗯嗯，

就是因为你对这个产品的实现的代价是有一个预估的，

你觉得不划算，

但是他觉得无所谓，

你干呗，

反正你是马蓉对他可能就会觉得说，

哎，

那我现在就是要对吧，

你就是来给我干活的，

你实现不实现吧。

对，

那那你有没有想到是你想太多了，

也有这种可能。

嗯，

因为当时我们最后这个事儿呢还是干了，

只是说这个事儿不是我干，

可能用了一种可能更低成本的，

但是可能也是我的习惯的问题。

因为我是后端出身，

那我会觉得说这个事情我们如果上的不到位，

可能最后会有很高的风险。

嗯，

其实在国内互联网公司我聊过一些朋友哈。

我总觉得在国内互联网公司很多的情况下，

产品经理和项目经理这个角色是混淆的。

你有没有发现确实包括刚刚毛毛去吐槽的时候，

就比如说啊产品经理在插需求。

但其实我们如果是真正的一个项目的话，

有专门的项目经理会有项目经你来去评估这个事情到底要不要差，

而不是由产品经理来决定。

对，

因为如果产品经理来决定，

那一定的结论就是我这个需求很重要，

明天我就要上线，

对吧？

但项目经理他可能会从整个项目的结构，

包括我们整个项目的情况来去评估这个事情的优先级到底有多高。

他其实会成局外人，

他会以局外的人的视角来去看。

但是产品经理可能说 ok 那这个需求是我提的，

我觉得确实对用户很重要，

这个时候就会有误判是没错。

因为我总觉得在互联网公司里面，

项目经理的要不就没有，

要不要就话语权特别热。

但是项目经理这个角色往往又是非常重要的，

因为他会在产品需求和这个开发资源上，

他是那个天平，

他应该去平衡这件事情。

但是往往很多公司做的在这块上做的，

其实并不是说特别好，

可能他都被敏捷给打残了。

哎，

对我我是觉得这几年就是我们突出敏捷，

当然敏捷有它的一定的好处哈。

但是往往呢有的时候必要的这种摩擦成本其实是很重要的。

是的，

其实还是需要有一个站在外面的人去看这个问题。

因为无论我是产品经理也好，

我还是程序也好，

我其实都是身在其中，

身在其中，

难免会把这个事给放大。

但是你可能有一个更高视角的人，

他去看的时候，

他就会明确说说你这个可能其实没有那么重要。

是咱说回这个矛盾来讲，

刚才大家也分别吐了一下，

吐了吐槽是吧？

嗯，

你们觉得嗯我觉得毛毛先说吧，

你们觉得就是程序员的跟产品经理的这种我们打引号的矛盾哈。

其实我们都知道，

这其实也不是什么大是大非的问题，

往往大家都是为了实现这个需求嘛。

但是你觉得这个问题的根源会出在哪儿啊？

不敢说了，

没事儿，

我不打。

你。

对我觉得这咱应该来一期视频，

看看这二位的表情。

嗯，

根源啊那个呃我觉得根源可能还是那个有很多原因吧。

刚刚其实有提到提到几点啊，

那个我也我也觉得比较认可啊，

就是刚刚说有说到资源这个事儿，

那个呃比如说我现在其实有在带呃开发团队啊，

那么我其实知道我我我的人能做多少事情啊，

但是你其实你你的这个产品一直进需求，

然后你也一直没办法量化自己的这个需求的优先级到底是谁最高啊，

那是有有哪些需求可以往后稍微推一推。

因为其实基本上上产品那边过来的需求，

很多时候都是第优先级。

就是今天我这个需求是为这个唉只有第一没有第二对为这个大客户来做的那这个第二个需求又是为另外一个大客户户做的。

其实在呃现有的人力以及时间的情况下，

我们确实没办法能满足那么多啊需求。

所以我我觉得是说这个啊资源这块啊会是一个那个比较大的一个点啊。

还有一个其实就是刚刚说的就是那个你真正交付的这个需求的一个结果啊，

到底是个什么东西啊？

是是只是把代码写完了，

还是说我们还有很多相关的要帮助这个客户上线，

要帮助这个客户交付文档啊，

这些东西其实都是呃是不是在我们这个研发的这个周期里面啊，

这一点其实在交付标准这块也是需要确定好的啊。

因为我们后续的话呃，

很多人认为写程序员，

很多人认为说写完代码之后，

哎，ok 我的日志我的工作就完成了。

但是我后续免不了是说产品是希望哎你研发是能跟客户对接的啊，

你要帮助客户说能够在他的这个生产环境里面，

或者在在他的那个那边，

可以把这个能够跑通跑通。

对，

所以这个东西都是有一些 gap 的。

嗯，

对我大概说这两点，

对我我觉得就是我印象最深的。

其实很多程序员的吐槽在于说程序员的工作，

其实他是没有办法被打断的对。

因为我们很多时候我们需要去思考一个路径，

沉浸在你的这个实现路径里面。

对，

如果我这个路径被打断，

我就必须从头再来。

对，

但是呢产品经理不曾强来小白把你的屏幕打开，

来戳一戳，

对你你要给我改。

然后这种情况下呢，

就是导致了甚至现在很多时候我们说的这个程序员的这种加班问题也源自于此。

就是曾经有一个大厂的程序员跟我吐槽，

我说你们为什么九九六你这没必要嘛，

就是一天你有效的工作时间，

谁都知道，

你不可能九九六的写代码，

那写疯了是吧？

但是他跟我讲，

那就是我不是九九六的在写代码，

是我绝大多数的白天时间都在被产品经理抓走。

开会对我只有晚上有晚上，

产品经理走了，

我才有时间写点代码都是这样。

是的，

毕竟我的本质还是写代码，

但是白天要被拉去开会，

我只能选择在一个晚上。

夜深人静，

没人打扰的时候，

我好好把我的这些代码给好好写一下。

对对，

所以你也不能怪九九六这件事情真的在项目和产品管理里，

很多公司其实在这一块我觉得还是有短板的。

其实在这里关于这个需求的问题，

就是刚才我说的抓程序员拉程序员改需求这个事儿，

我想请请这个云逸去讲一讲。

为什么从产产品层面总是有这么多的需求要改？

嗯，

这个确确实是，

就是刚刚也提到一个关键词是敏捷。

我觉得敏捷这件事情现在已经越来越没有下线了，

就是确实是商业变化的这个节奏很快。

唉，

可能有来自外部市场大环境的那也有来自竞争对手的那也会有来自于我们自身的这个优先级的这个这个这个讨。

所以其实很多时候真真正这个需求，

在我们哎向程序员去阐述之前，

其实可能能已经经历过很多内部的 battle，或或者说我们自己的内心的这个 battle 了。

那所以这是这我觉得是一个必然的过程。

但是我觉得这个矛盾的根源，

其实可能还是就刚才大家也说黑话叫对齐嘛。

那我觉得能就是大家没有达成共识。

那其实很多时候我们的这个需求变更啊，

其实也是为了能够交付更好的产品，

就能够去帮助客户啊去解决问题。

那特别是 tob 端的产品，

其实我认为它是以交付到客户手上，

真正用起来才算结束的。

而不是说我们研发开发完了就开发完了。

所以这个过程当中确实是会出现一些哎需求的变更。

然后需要在特别新产品哎，

需要研发，

可能早期跟着客户一起去打磨上线。

然后把整个我们交付的过程，

甚至包括客户后期使使用的一个前期的过程一起打磨顺利。

这才是我们一个整整体的一个从哎产品功能到运营的一个完整的一个交付过程。

所以这个过程当中，

那确实是呃会有这样的呃一些快速的变化。

那有一点我也觉得确实可能是包括我自己以及我身边的很多产品经理啊，

我们自己其实就是挺挺擅长，

或者说是也挺挺善于去做一些多任务啊，

然后多线程的一些工作的。

确实可能思维方式，

包括工作方式跟程序员有天然的这个差别，

会导致这样的原因。

呃，

我觉得这一块其实最关键的是需求改我是可以接受的，

但是不要一改就马上实现。

因为对这就是一个进度管理的问题。

对，

因为很多时候我们手上可能就还是我们刚说说那问题。

嗯，

我有项目管有项目管理的情况下，

我可能确实有一些高优先的事情去做。

但问题是我们可能碰到需求变更的时候，

可能这个事儿已经拉到非常紧急的。

我就不得不一次又一次去打断我的工作流来去做这件事情。

所以这个事情我觉得或者我们可以再去改需求的时候，

可以有一个预期。

比如说可能他现在还正在忙，

对吧？

我可能说我不要求你当现在给我做出来的，

但是你可能给我一个合适的预估时间，

我好去跟客户去沟通。

我说我大概什么时候可以上，

对吧？

可能这样会好一点就害怕。

比如说产品经理在对，

在群里跟客户说没问题，

明天上线。

结果这边产品这个研发一堆需求做不完，

这个时候就尴尬了。

你们发现没有？

他用了一个非常高情商的说法来说这件事情。

但是有的时候我遇到的程序员往往是一些嗯表达上啊啊各方面，

他可能考虑的并不是特别多多的这些程序员。

嗯，

云逸有没有遇到过这种程序员，

经常以一种低情商的方式来回应你。

呃，

遇遇到过就是来讲讲他们的故事，

就是他可能不会这么直白，

但是他潜台词就是你不懂这个很复杂，

然后这个没有那么快能够实现，

或者他会觉得说就是哎这个需求怎么可以这么对吧？

点点点，

然后然后会。

会有这种抱怨声会比较多。

刚才我们在节目之前聊聊天，

我觉得萌萌还是那种高情商的程序。

不客气吧。

那个呃对关于这一点就是包括就是互相的沟通嘛，

有一些体会。

那个呃程序员嘛那个是一个这种我们这种大脑是疯狂运转的。

比如在小程序的时候特别担心，

特别怕自己被打打扰。

然后我们其实每天更多的其实会面临的更多的是程序的问题啊，

程序的 bug 程序如果 bug 如果修不掉，

那我们会很焦虑。

然后又有很多业务的问题啊，

那个有很多客户的问题，

我们可能需要修啊，

那么我们还有卡一些 deadline 啊这些问题，

那个业务，

然后还有这个时间啊，

这三方的压力会导致可能很多程序会变得非常的暴躁啊。

其实他们不是啊不想好好说话，

他们其实如果真的能有就是比较在比较放纵的情况下，

他们还是挺愿意沟通的。

但是由于是这种长时间，

而且是常年在跟一个没有情感的东西打交道的时候，

会就就是说慢慢慢慢让你变成一个看起来不不太会沟通的这样一个一个人。

对我觉得这点呢就有之前一个梗嘛，

就是产品经理怎么去跟程序员报 bug。

你可别跟程序员说，

哥们儿你有 bug 了，

你得说，

哎，

哥们儿这玩意儿怎么怎么不是这样啊，

对吧？

你说有 bug 了，

程序员第一反应你才有试试，

对吧？

但是你要说哎哥们儿这个怎么不行，

他内心里边想我擦我是不是写出 bug 来了？

对，

咱聊会聊会这个话题啊，

我觉得刚才我讨论了很多矛盾的根源。

那其实我们今天更想讨论的并不是说大家互相吐槽这件事情。

其实我们更想讨论的是，

我们需要什么样的产品和技术的团队，

以及我们怎么补齐在沟通当中的这个短板。

因为我我我会觉得说其实不同类新的公司或者不同的产品，

其实对于产品经理的这个素质要求是不一样的。

但是会有这几个共性，

或者说是基本的条件吧。

就是首先我是觉得产品经理可以不懂，

技术真可以不懂，

但是必须要有的是边界感。

嗯，

就是就是我以我自己来举个例子好了。

其实我刚才说到我其实是从一个其实也是一个完全外行人进入互联网的角色。

那我也不会 coding，我唯一会用的就是 matleft。

那在程序员眼里这不算 coding。

对，

但是我是一开始如太狠心了，

直接说话。

那我加入互联网公司的时候的第一个第一个工作职责其实是 ceo 助理。

那我是怎么从 ceo 助也逐渐的去深入到这个哎产品的管理定义这个角色当中的。

其实我就是因为我过去是一些自动化的那所以我就是很清晰的。

当时我们在设计对话机器人，

那我就是很清晰的知道哎，

我每一个模块，

每一个算法，

它的边界是什么，

它的极限是什么？

我通可以通过什么样的产品设计交互的体验，

以及数据运营的方式，

把技术边界在有限的范围之内，

把这个产品的商业化的价值发挥到最大的极限。

那我觉得这个是一个从算是呃技术手段上，

或者说是一个呃战术上，

我觉得是一个必要的一个一点。

那第二个呢就是可能就是同理心了。

我觉得这个同理心既包括就是说对呃客户，

或者说是对需求的这种理解。

当然也包括对于就是每天面对着机器的这个程序员的这个理解，

就是要会沟通。

那第三个的话，

我觉得是领导力了。

就是其实大家刚才一在摔怎么提需求，

怎么接需求，

你看提更需这两个词，

就把这个关系变成了一条流水线上的一些分工，

或者说是更有更说的更简单粗暴一点。

就是甲乙方。

那所以我觉得就是如何让就是这个看起来是一个产品经理的个人决策，

变成一个呃集体愿意对向同一个方向去努力给大家制定一个共同目标。

我觉得这个特别重要。

对，

然后这是集体决策让然后然后所以我觉得这三年可能是我觉得从这个就是比较宏观视角去看比较重要的那那剩下的就是一些就是一些技巧性和学习能力的问题了。

在能力上，

那就包括你对于整个就是市场分析的能力呀，

洞察的能力，

然后时刻保持好奇心啊，

能够去对整个技术趋势能够有一点点的感知啊，

那然后就是嗯包最重要的是沟通能力了。

因为其实很多时候呃，

程序员在表达你的需求不清晰的时候，

其实是你的价值传递没有表述清楚。

对，

就是你没有真正的告诉程序员，

我的目的是什么，

而是告诉你你把这个需求给我实现了。

对，

或者我我在解决什么问题？

嗯，

是我可以说一些我的个人的一些体会啊。

其实我之前那个也是会感觉自己啊不会沟通，

嗯，

然后情商低，

然后每天也只会写代码。

其实这段这个状态其实有持续了好几年。

其实从毕业之后呃，

大概有前五年时间，

基本上都是每天在做啊比较重复的一些事儿啊，

因为为什么会这么想呢？

因为一方面其实很多程序员的性格都偏内向，

他其实本来就不太希望去沟通。

你给我一个电脑，

你给我一台手机，

我可以半个月不出门啊。

那个这都是程序员，

其实比较想达到的一个状态，

一个境界。

对，

是对那个。

但是后面的话我我会发现，

但是我我不是说这样不好，

其实我们也有认识很多人，

那他真的是有非常非常深的技术追求。

他甚至每天可以在研，

比如说开源代码可以通宵的去研究，

对于技术非常痴迷。

他认为是说我能够创造出来一个呃，

比如举个例子，

操作系统啊可能能够给自己带带来的愉悦感，

超过跟别人去沟通啊，

或者是说交付一些就具有很具有商业价值的东西。

那我觉得这种人他其实在技术这块，

他即使沟通不好，

他也能对于这个社会，

也能对于这个或者是自己吧可能带来更大的一个价值。

啊，

这一点我觉得我是认的。

所以我们会强调是说，

在第五年的时候，

我有思考过呃，

就自身的一个呃技术的一个发展的一个路径啊。

因为现在比较典型的其实就是选吧。

那个有很多人能成为一个技术专家啊，

他就是说他其实可以沟通，

不算特别好啊。

那他只要能把技术给做的非常深入，

做到行业的第一啊，

那也可以。

那么第二条路其实就很多人他会到达一个瓶颈啊，