po是什么职位的简称，po是什么职位的简称英文？

一、团队管理

目标首先要和上级或公司的目标不能偏倚，执行时需要去确认，避免费力不讨好。

执行任务时，任务要细化成一个个可验证的里程碑，能看到成果和价值。

如何让工程师高高兴兴的来上班，自发努力的去工作，这是技术领导者要研究的一个重要课题，在这方面，国外就做得比较靠前。国内公司则更多见于KPI的管控。举个例子，如果一个系统由于员工操作不当出现了问题，有些公司可能会主张给员工记过、罚款。我非常不赞同这样的做法，为什么呢？因为这种做法是针对人，而不是针对事。正确的做法应该要对事不对人，因为我们的目的是要解决产品技术的不足，优化流程、优化管控系统等。做接近目标的事情远远比处分一个员工重要的多。

管理基本上是三个事，管人、管事和自我管理。

管人的意思就是管团队。

管事的意思是要找准方向。

自我管理的意思是说管理者自身的素质和自我的成长，管理者就是这个团队的天花板，如果管理者自己不成长，那么团队就会受限，所以，管理者要修炼自己硬技能和软技能等各方面的能力，包括个人魅力、沟通能力等，从而提高自己的影响力。所谓影响力并不在于职位高低，而是当别人有困难的时候，是否会想到向你寻求建议或支持。一个leader的关键素养就是要能服众，能获得团队和客户的信任，之后，自然会赢得老板的信任。

先来说第一个素质，自我定位。

要明白作为管理者，是来帮助团队，而不是阻碍他们前进、阻碍他们创新的。因此，如果你懂，你就一起来干，如果你不懂，那就相信团队，放手让团队去做，千万别外行领导内行，这是非常不好的做法。管理者肯定是孤独的，哭得自己哭、压力得自己扛，但取得的成绩、获得的好处一定得交给整个团队。最糟糕的做法就是成绩是自己的，问题是团队的，这样一定会导致众叛亲离。

再来说第二个素质，能激励团队，也就是能驱动团队成员有主人翁精神、有ownership。

技术研发是知识密集型项目，不能沿用传统的“命令与控制”Command & Control的管理方法。这种管理模式之下，大家多会觉得所做的事情与我无关，是你老板的事情。

激发主人翁精神的一个关键就是让团队成员有参与感，而要让他们获得参与感就需要赋予他们建议权甚至是决定权。同时，领导者需要往后退一步，把命令变成协作和引导。管理者这时要做的不是一个奴隶主，而是一个教练或是一个老师，传道授业解惑。

给员工放权的多少是一个团队是否强大的表现。最差的管理是家长式的保姆式的管理。

在管理的象限图中，第一象限是团队，第二象限是质量，第三象限是流程，第四象限是成本。

不同的管理风格会偏重不同的象限，而且一个管理者最多只能偏重其中的两项，而且还不能是处在对角线上的。因为对角线都是有冲突的，比如太注重流程，团队就会没有活力，或者关注质量，成本就难免会变高等。另外，相邻的两个象限是互补的，比如好的质量必须要好的团队和高效的流程来保证。

每个人的管理风格都是不一样的，而我的风格更偏重团队和质量这两点。大家也可以做一些测试来测自己的管理风格，比如当系统出现故障的时候，你会怎么办？是先惩罚人，还是先弥补流程，还是先总结错误。其中并没有哪个答案是标准答案，就看你选择什么，而你的选择会展示你的偏好。

因为我之前在湾区的经历，我会希望我的风格能更接近湾区的管理方式。作为管理者本身，我觉得非常重要的一点是，自己要做好榜样。在很多事情上，我对团队有怎样的要求，那我自己也要达到这样的要求，甚至做到更好，起到榜样作用。古语有言，知之非难，行之不易，你怎么做要比你怎么说重要得多。

而在具体的管理上，我不提倡micromanagement，也就是微观管理，把管理做得特别细。我会在把公司目标和当前要做的事情跟团队传达清楚的情况下，授权给团队，给团队更多的自由度，让他们能自主的去思考、去执行。

另外，毕竟我管理的是技术团队，所以我相信代码可以解决很多问题。我们应该尽可能的去用代码治理，而不是靠人治。

比如，当我们遇到问题，或内部需要做一些事情的时候，我的第一反应就是，这件事是否能够用工具或机器等手段自动化的去解决，之后又是否能够自动化的发现类似问题并解决。现在，这也已经成为我们团队很多leader的第一反应。

我接触过很多技术团队的管理者，在我看来，他们对具体事情的关心远远不够。什么意思呢，就是他们只关注大方向。在我看来，商业竞争和游泳、篮球等等体育竞赛实际上是一样的，体育竞赛最后只有一个奥运冠军，每个行业最终也只有一个第一。运动员要怎么培养呢？如果教练来了之后，只是给运动员定个PKI，比如“今年要进入三强”或者“三分球进球率要达到80%”，这样的教练有什么用呢？你去看看那些知名的教练，他们可是每天盯得很紧的，一个动作做得不对都会马上来纠正，我们的技术管理者跟教练比起来差得太远了。

在我看来，大部分技术管理者可以提升的空间是很大的。我觉得比尔·盖茨就是一个非常典型的优秀的技术领导者，他在上世纪70年代就预见到将来家家户户都会拥有个人电脑，所以他去做了操作系统，这就是“做对的事情”。但是具体做事情的时候，他也非常关心细节。大家知道乔布斯也非常关心细节。所以能够把技术产品做到最好的人，都是对产品、技术、体验、质量这些事情非常在乎的，真的像一个教练一样，调教出了一批优秀的人，这些人现在也成了各大公司的领导者。

而技术人在转向管理的时候，面临的最大的问题就是思维上的转变。举个例子，某个问题自己几分钟就能搞定，但交给下属可能需要好几天才行，这时作为技术leader就一定要克制自己，不要亲自去解决问题，否则虽然对解决问题有帮助，但对团队管理却并无好处。

这就是挑战所在，其实就是看你能不能放弃自己的技术优势，给团队机会，让年轻的团队按照你的方向和思路往前走，给他们带去成长，这样你自己才能有更好的成长。

激发团队创造力

第一，要有责任感。作为CTO，你首先需要有责任感。中国女排奥运会夺冠，在接受记者采访时，郎平说，比赛的成绩是跟队员的未来密切相关的，所以，你能不能打出好成绩，不仅关于你自己，更关于整个团队别人的前途。

这句话给我留下的印象很深，这就是责任感。说回到带团队，公司把这么重要的事情交给你；团队那么多兄弟相信你愿意跟着你；客户信任你愿意用你的产品，你就需要对他们负责。

第二点，要有效沟通。沟通其实就是讲故事。团队人少的时候，你可以一个一个跟对方沟通，一遍不行说两遍三遍，总能说清楚。但当团队大了，人数超过150人之后，就很难用亲情、友情、人与人之间的关系等情感的方式去沟通。

你需要的是讲故事，用故事去沟通效果最好。当你在说业务发展、愿景的时候，其实就是在讲故事，而把这个故事讲好，自然能把你想要团队做的事、希望他们达成的目标传达给他们，带着他们一起向上走。

第三，要树立合适的愿景。跟团队讲故事的时候必然会聊到愿景，可以说愿景是故事的核心。但我们树立的愿景要切合公司发展步伐，不能走得太远太前。

比如我们之前踩过一个坑，2004年左右，普元就提出了类似云计算的愿景，但那个愿景太超前了，行业还没有发展到那一个阶段，导致无论是跟公司内部还是公司外部提我们愿景的时候，大家都不理解，觉得不靠谱。最终，这个愿景对公司发展起到的拉动作用是极其细微的。

因此，我们预见5年之后的行业情形是最合适的，预见10年就太远了，对公司当前的发展并没有太大的好处。

第四，要有匠人精神。这个词现在被说的有点多了，但一家企业必须找到自己最擅长的领域，然后专注的打磨，将其做到极致，变成自身的核心竞争力。现在很多领域都有赚钱的机会，但如果不是跟自己核心相关的话，就要懂得取舍。

我们的创新可能都是时间熬出来的，我们掉过无数的坑，经历过无数次的错误，但是我们想办法从坑里爬出来，一步一个脚印把事情做好。一个产品做了废，废了再做，可能要磨四遍、五遍才有突破。而在这个过程中，我们也能不断去思考怎么把技术跟业务做更好的结合。

要鼓励自我驱动。 以前，通常是公司高层或领导者直接驱动，下面的程序员戏称自己是码农，领导让做什么就做什么。但现在，我们要鼓励他们的自我驱动，让工程师自己身体内部的马达转动起来，让他们自己考虑下一步该往哪里走，怎么才能做到最好？作为管理者，你要做的是设定一个目标，然后想办法让他们自我驱动的往前走，这是一个比较大的转变。

要大胆放权。既然要鼓励自我驱动，就不能把程序员锁得死死的，所以大胆放权。坦白讲，不少管理者都非常在乎自己手中的权利，不舍得放权。

但其实大可放宽心，因为你放出去的权利还是你的，你能放出去就还能收回来，所以大胆放权，这个并不会对你造成什么伤害，管理者要有这个心胸。

要避免纯管理者模式。 我见很多纯管理者，他们制定了公司的管理制度，他们会觉得之所以管不好，就是因为制度做的还不够好。我也认同，管理制度是有用的，但作为技术管理者，一定要想明白，如果你的公司都是能人、每个人都能非常高效的工作，那么你就不需要管理制度。

你之所以需要管理制度，是因为里面有一些庸人，这些庸人总是犯错或偷懒，所以需要制度来避免他们犯错。但你制定越多的管理制度，减少庸人犯错机会的同时，你也是在惩罚那些能人，给他们树立了太多的条条框框，让他们动弹不得。所以，作为一个管理者，你在制定这些管理制度的时候，一定需要克制自己内心的冲动，不要去做扼杀创新的事情。

举例来说，我们之前推出了分布式数据库RadonDB和分布式块存储NeonSAN，这两个产品就是比较典型的例子，都是我完全放权给了它们的负责人，由负责人自我驱动，最后打造出了非常优秀的产品。

这里有两个关键因素，一个是幸运因素，这点无需避讳，能找到这样两个人是我的幸运。对我而言，他们比千军万马都要有用，这也是我常说的，有创造力的人要远比那些普通工程师有价值得多。

另一个因素是，管理者有没有给他们创造一个能自我发挥的空间。其实，相关的事情他们之前在别的公司也做过，那为什么之前没有做成，在青云就做成了呢？总的来说，就是我们给予了他们合适的阳光、雨露、土壤，给了他们能发芽、成长、结果的环境，激发了他们的潜能，把他们从看上去很普通的技术人，变成了青云的Super Star，这是我作为公司的管理者需要去做到的。

我一直很反对管理者驱动太多，因为在那种情况下，你实际上是在为你个人去管理，是在维系你的权利，并没有为公司的核心竞争力增长这个目标去管理，这两者之间有很大的区别。

，说是放权，其实中间有很多实操的环节，实际上是付出了更大的精力的。我并不会像别的公司那样，把研发跟外界隔绝，生怕别人来挖。我反而会努力把他们培养成Super Star，同时努力把他们推出去，支持他们多去参加大会、去做宣讲，建立自己的影响力。做管理者还是要有胸怀。

话说回来，那些纯粹为了钱的人也到不了Super Star这个level，之前就会离开了。所以我也不会在这些人身上花费气力，走就走，没关系，留下来的、沉淀下来的才是公司最重要的一批人，是公司整个文化传播的种子。

达到“无为而治”这样极高的管理境界，可能看着管理者什么都没做，但其实整个公司都在他的Control之下，按照统一的价值观做事

很多管理人员会进入一个误区，他会去享受权利带来的快感，却不知道怎么培养团队成员。在我看来，一名合格的领导者，不在于自己的能力有多大，而在于能够培养出多少更优秀的人才；也不在于自己能够做多少事，而在于能带领团队做多少事。一个人一天不眠不休也只能工作24小时，但如果能将方法传承给团队，培养出10个和你一样优秀的人，那工作效率就能够翻10倍。

要做好技术团队管理，我觉得以下这几点比较关键：

第一，要有一个比较大的梦想，这是非常重要的；

第二，要让技术人员感知到，他们做的事情在直接对客户产生价值，让他们有成就感；

第三，要坚持技术导向，让技术人员觉得他们能在这里学到东西，比如如何处理大规模的海量并发任务等，这些是技术人员比较感兴趣的。

二、职场软技能

在合作中，往往是先有信任，才有尊重。如果你觉得CEO信任你，那你就不会觉得他说的话是对你的不尊重，否则CEO说话直接点，CTO就会受不了。相反也是这样的。所以，最关键的还是彼此间的信任与尊重。

其实CEO与CTO之间的沟通障碍是客观存在的，也是正常的，我们要清醒意识它的存在，更关键的是在这种时候，CTO要主动向前走一步，跨越这个鸿沟。

懂业务，我经常开玩笑说，懂业务的技术，就像流氓会武术。

深度/广度并重。

人的技术高端技术人的日常工作大概是40%跟人相关，30%跟业务相关，剩下30%才跟技术相关。我认为掌握人的技术，有两点非常重要：一是懂表达，二是懂尊重。

懂表达就是如何能将自己的理解用大家容易接受和理解的方式表达出来，这个对于建立和扩大自己的影响力非常关键。

懂尊重，就是要帮助他人成长，好的技术人都容易有英雄情结，视比自己水平低的人如草芥，沟通基本以鄙视为主，所以必须从内心深处尊重其他人，才能建立和发展好一个技术团队。

任何技术最后都要跟业务相结合，在我看来，当今世界上是没有纯技术的概念的。哪怕你研究的是导弹技术，也需要跟导弹的设计成本、最终目标相关联，这其实也是业务的范畴了。所以，CEO一定要对业务有绝对的把控能力。

来做CTO的时候，我只用关注技术本身就好，想的更多的是如何用技术手段去解决商业中的一个个问题。但创业成为CEO之后，需要更多的去关注技术和商业之间的关系。另外需要考虑的事情也变得更多、范围更广了，有时候不能简单的只想着把事情做好，而是要考虑平衡各方面的因素，对平衡感的要求会更高一些。

产品思维从本质上讲，就是业务思维，就是要去思考产品的用户价值，甚至更进一步需要考虑商业的层面，思考怎么才能卖出更高的价格或者卖更多的产品，从而产生更大的营收和利润。

技术管理者首先是一个管理者，为一个团队的前途负责，其次才是一个技术人员。我认为管理者最核心的能力不是团队管理能力，而是以下这两点：

1）判断力：如何避开错误的和没必要做的事情，集中精力到最必要和最正确的事情上，从而让团队尽量少做无用功；

2）协调能力：如何和其他团队进行高效协同，从而为团队构建最好的工作环境。

我要花更多的时间去“务虚”，去做思考、做沟通、做规划等相关事情，同时，你走得越高，你“务虚”的时间就要越多。

我们CEO对于CTO的要求就两点，

第一是要有对未来的预见与洞察；

第二是要能激发团队的创造力。在他看来，如果能做好这两点，那至少能打80分以上。

架构的本质是折中，作为架构师，你拥有的是有限的资源，如人力资源、机器资源等，但你面对的是没有上限的需求，如工期的需求、稳定性的需求等，所以需要在不同的层面做出折中的选择。

你不可能做出一个完美的解决方案，必然要牺牲一些东西来达成另一些需求。所以，从宏观的整体架构设计和安排，到最终每个功能点的实现，都是折中的。

我父亲小时候给我讲了一个故事，至今印象深刻。20世纪初期，美国福特公司的一台电机出现故障，很多人花了两三个月都修不好。在束手无策的情况下请来了专家斯坦门茨，斯坦门茨在电机旁边仔细观察，又计算了两天后，就用粉笔在电机的外壳上画了一条线，说：“打开电机，在这条线往里的线圈减少16圈。”结果证明，问题果真出在这里。

这个故事给我的感触很深，作为架构师，你一定要成为那个划线的人。一个架构会涉及方方面面，不可能全都很好的顾及，所以，你需要找到那条线，找到问题的关键，并将其解决，这才是最能体现架构师价值的地方。

一个很真实的体会是，要跟老板多汇报，多总结、多思考，再跟团队多交流。很多技术人可能在向上沟通上存在一些疑惑。对此，我的建议是，客观、真实地反映现状。

说真的，做管理还是挺难的，如果允许我自夸一下的话，我觉得所谓的创新工作或治理工作，这方面的直觉会相当重要，至少对我来讲是这样。任何优秀的管理方法，管理者都要对流程非常清楚，但这里面也有一个诀窍，就是你要精准地知道，哪些是你要做的事情，哪些事情一定不做。

大部分时候，要平衡商业、技术和管理这三者的关系，确实会遇到一些困难，对我自己而言，这时候最重要的就是要接受别人的帮助。我经常会讲，一个人有长处其实是很危险的一件事，因为他的短处是需要别人帮忙填补的，但很多人看不到这一点。

我觉得我最大的长处，并不是我自己有多优秀，而是我可以心安理得地接受别人的帮助，比如2050，就是我接受别人的帮助，而不是我帮助别人。如果你管理上比较弱，在这方面就要多接受别人的帮助，如果不能接受，那就会是个灾难，不要试图去做你明知道做不好的事情。适时接受他人援手，也是一个人成长最后的挑战。

1. 个人核心技能的打造。

个人核心技能是指你在某一个领域是否足够精专，是否具备足够的核心竞争力。最直接体现在你在这个工作岗位上的不可替代性程度，你的不可替代性越强，就说明你越有核心竞争力，反之亦然。间接则体现在你在公司或是这个领域中的话语权及权威性。

具体打造的话，我们可以从聚焦和开阔眼界两个方面着手。

2. 打造自己的独特性。

除了技术功底扎实外，如果想打造个人品牌，就一定要找到自己的个人特色，打造自己的独特性。

而独特性，一般由核心技能之外的多样化技能构成，比如你程序员里最会演讲的、最会写文章的、最会做PPT的等等，这些都是很好的标签。这样，如果公司有一个去知名技术大会分享的机会，你就可能是领导第一个想到的人。

3. 找平台+建立圈子、

很多技术人给人的第一印象就是有点内向，不爱交流，我一直很建议技术人们多出来分享。分享的好处有很多，首先，很多东西你以为已经弄明白了，其实不然，出来分享，有助于你把自己正在做的事情真正理清楚、讲清楚，这是非常重要的。其次，你分享之后，别人才能给你反馈，有正向有反向，你才可能意识到自己之前走入的一些误区，也能认识到自己和行业真正顶尖水平之间的差距。最后，通过分享，别人才有可能认识你，这是一个锻炼的机会，也是一个树立自己形象的机会。

因此，要想让自己的个人品牌足够大，就一定要出来分享，而且要选择一些优秀的平台，比如极客邦举办的InfoQ、ArchSummit等大会就是不错的选择。

如何打造高效的研发团队

第一，团队项目管理的透明性

我从2009年全职做敏捷教练以来，每次辅导团队，做的第一件事就是公开团队的所有工作事项，保证项目管理的透明性。

我总结我的辅导经验后发现，效果最好的做法就是通过一块高1.5米，宽2米的大白板，将团队中所有事务全部罗列出来，包括需求列表、迭代表、问题风险列表等，把所有的信息透明化。

因此，在这块白板上，我们能够看到团队中所有人的任务和进度。当然这对于个人来说，将自己完完全全暴露在团队成员面前，是一个很难过的心理关，因此，团队如果想要达到之前提到的完全透明的理想状态，就需要团队慢慢磨合。透明的团队项目管理，能够使团队内部互相信任，这点非常重要，因为，缺乏信任的单兵式作战，不能称为团队，只有建立互相信任的基础，团队才能高效作战。

第二，制定团队自己的规则

我曾经报名学习了IAF国际引导者协会关于引导的课程，从中深深感知到了团队规则的重要性。

我们常说流程，但流程其实跟规则有区别。一般来讲，流程针对的是上规模的团队或组织，只有当一个几十上百人的团体在做一件复杂的事情的时候，我们才需要流程。目的是为了在某一个节点、某一个方面提醒人们少犯错误。其中节点是时间纬度，方面是空间纬度。

这是我对流程的定义，但其实很多人对流程的定义出现了偏差，所以对于团队，我更喜欢用规则rule。

另外，流程一般都是由公司层面制订的，团队不会参与流程的制定过程，只能按照固定流程行事。而在我看来，团队应该根据团队情况制定适合自己的规则，比如开会的规则、代码提交的规则、代码评审的规则，以及相应的奖惩制度等等。

只有团队自己参与了规则制定的过程，并不断检验它，才是让团队达成共识，高效协作的行之有效的办法。

第三，权利与职责清晰

团队内部公开透明，也制定了行之有效的规则，接下来就是明确权利与职责（义务）。权力与职责是对等的，你有多大的权力，就应该承担相应的职责，不能只享受权力，不承担义务，或只有义务，没有权力。

据我观察，互联网行业有一个很普遍的问题是，产品经理既管产品，又管项目，把两个权力都抓在手里，就很容易出现问题。比如产品经理进行项目估算后，由别人执行、落地，而一旦他的估算出现偏差，别人在具体执行过程中，就很难按照估算将项目落地，这就是问题所在。

我比较喜欢Scrum中的角色设置，他们分别是PO（产品负责人）、Scrum Master和Team（开发团队），我想应该再加入一个重要角色，即People Manager，这四个角色相互制约、相互促进。

我们先把People Manager抛外，在团队运作中，PO负责产品方向，包括产品对外的承诺、收集所有需求等，Scrum Master是Team和PO之间的“润滑剂”、协调者，负责提升团队协作效率，确保团队持续、高效地输出结果。而另一个角色Team的职责范围更广，事实上整个项目管理工作都是在Team内部完成，当然，这也离不开团队内部的自主性。

因此，每个角色的权利与职责不同，各自发挥其作用，保证团队的高效输出。

第四，个人的激励

对于团队leader，我总结了三点激励团队成员的途径：

1.动机，给予每个团队成员Motivation。2.个人成长，了解团队成员的职业生涯或成长通道，按照这个方向帮助他提升个人能力。3.尊重与认可，关注团队中的个人，给他尊重与认可。当然，这方面也需要团队的透明制度作为支撑。

在激励个人方面，Scrum Master会起到关键作用，他需要具备良好的引导技巧，（这也是我为什么去学引导技巧的原因），运用引导技巧，能够让团队中的每个人互相尊重，良好协作，高效沟通。

需要注意的是，Scrum Master虽然担负如此重要的职责，需要解决团队中所有的问题，消除达成目的的障碍，但是，Scrum Master本身没有权力，也不需要权力。因为有权力的团队无法自驱动与自组织，Scrum Master应该依靠的是他的能力和影响力。

第五、透明的考评机制

考评机制是一个敏感话题，但对团队非常重要。在阿尔卡特朗讯内部曾经有一套“七二一”法则，其中，“七”代表对公司业绩的贡献，很好理解。

“二”是指团队产出的占比，是团队与团队之间的考评。比如在互联网公司，产品团队、开发团队之间互相考评，如果考评机制透明，他们互相打的分数就应该相对公平、公正。

当然，这是一个考核标准，考核的是产出量，另外，我们还可以考核产品上线后产生的缺陷量，这个数据很好统计，但往往会被忽略。因为有些人认为这样做很伤人，但其实，要想做到不伤人也很简单，就是将考核机制透明化、数据透明化，如果你认为不该是你背锅，你就可以申诉。

最后是“七二一”法则中的“一”，这10%是对个人能力成长的考核，我们不谈个人在过去一年对团队的贡献，而是关注他的成长，由团队来考评成长分数。

Go语言，七牛是全球第一个用 Go 写的云存储。早期在产品都还没正式上线的时候就写了《Go语言编程》这本书，看起来特别的不务正业，但事实上我们有自己非常明确的目的。

一方面，写书是最好的说明自己是某方面专家的方式。

另一方面，在那个时间点选择Go语言也非常能够说明我们团队的独到眼光和品味。结合一些规模较小的高端架构类技术交流会议上的密集分享，我们就快速成功打造出了七牛云这个技术品牌

三、跳槽与创业

创业的时候要专注在这个过程上，而不是技术领域。在不同的阶段使用合适的技术解决相关场景的业务需求，创业者需要的不是炫技，而是提供能够为业务服务的技术。一件商品最重要的是质量，但是提高产品质量最关键的是精准的把握用户需求的本质。否则，无论产品质量多好，功能多么丰富，如果不是用户需要的，那么这个产品就是不成功的，是某种程度的自嗨

爆款产品是因为真的“爆”了，才被叫做爆款，很少有人开始的时候就说要打造爆款，因为说了也没什么用。大部分产品都是一点一点长起来了，微信也不例外，只不过由于腾讯的用户体量，微信的起点更高罢了。事实上很多爆款都是黑天鹅事件，而黑天鹅事件是可遇不可求的。

成功产品的增长曲线。发布，获得初始用户，拉起一条增长曲线，然后失去新鲜感，数据下降，保持在一个低水平线上，反复迭代，挣扎，试错，找到真正的用户需求点，很多产品在这个阶段就死掉了，活下来的继续前行，直到找到那个数据上扬的拐点……

有人会觉得如果总是变那干脆不要计划了，这也是不可取的。邱岳老师在他的产品专栏里说过，没有任何作战计划在与敌人遭遇之后依然有效，但做计划的过程依然是必要的。缺乏计划会让产品失掉节奏感，员工失去方向，并且很难专注。计划制定的过程，本身是一个制定战略，统一思想，上下齐心的过程。也就是说，大家要登船渡海，扬帆起航了，得弄个罗盘，定好灯塔，然后再出发，这样在行进的过程中，无论怎么折腾，总的方向不会有大的偏差。

记住墨菲定律，当你认为要出问题的时候，就一定会出问题，决不能有侥幸心理。

如何获取资源呢？资源是相互吸引的，你想要资源，首先自己也得有资源，否则你有什么资格免费获得别人的帮助呢？

技术人学习一些产品知识，对自己有百利无一害。工程师如果对产品很有感觉，和产品经理沟通起来会更加顺畅，而不是你说什么我就做什么。在很多互联网公司工程师都具备很强的产品思维，甚至一些技术产品本身就是工程师主导研发的。腾讯的马化腾就非常推崇技术出身的产品经理，他说：

”产品和服务是需要大量技术背景的，我们希望的产品经理是非常资深的，做过前端、后端开发的技术研发人员晋升而来。好的产品最好交到一个有技术能力、有经验的人员手上，这样会让大家更加放心。很多产品经理对核心能力的关注不够，不是说完全没有关注，而是没有关注到位。核心能力不仅仅是功能，也包括性能。对于技术出身的产品经理，特别是做后台出来的，如果自己有能力、有信心做到对核心能力的关注，肯定会渴望将速度、后台做到极限。”

企业级服务的创业公司早期的种子客户，我觉得要符合几个条件：特别痛，不怕死，不怕麻烦。

我觉得千万不要去找那些所谓大公司，好像付钱能力很高，但是他没有那么痛，又怕死又怕麻烦。我经常说，你早期客户一定要去找产品价值高的客户，而不是商业价值高的客户。他虽然可能只付你二三十万，但是他特别痛，他比你还着急想尽快上线，这个是最好的客户。锻炼了产品，锻炼了业务。

创业公司很容易掉进“贪大求快”的坑。贪大就是特别想做大客户，大客户有几个问题，第一它流程特别长，把小企业给拖死了。第二，大客户需求多，很容易变成一个定制化项目。第三呢，大客户往往反应不敏捷，你跟他搞半天，其实最后是没有口碑的。

求快指的是什么？很多公司容易做着做着就做项目去了，比如有一个客户给我提了100项需求，我现在的产品只能满足30项，但是我一看，这个项目两百万，我就干了，70个需求反正先定制化帮他解决了，这一搞就把自己拖死了。反过来，给我四五十个需求的客户只能付我30万，但这个才是真正磨产品和产品化。我觉得最优秀的公司都是产品化的公司，你什么时候听过Oracle给你做定制？没有的。一点一点的通过时间去做产品化积累，才能通过产品化做到最牛的公司。

但如果我们把视野收拢在国内，类似这样的机会已经不多了，特别是在垂直行业。我们在垂直行业创业，想用技术、用互联网思维推动行业改变的话，很多时候需要摒弃一些技术人的固有想法，更多的是需要深入去了解所处的行业，了解他们真正需要什么。

最开始的时候，我们也想把产品做得轻一些，能够打造一个轻资产型的公司。毕竟我的两个合伙人都是来自谷歌，而谷歌就是非常标杆的轻资产型的公司。但在垂直行业，这么做越来越困难的，以流利说为例，最终，我们还是选择投入大量资源打造属于自己的原创教材和课程。技术人创业一定要跨过这个思维的坎，这是我们创业过程中最深的一个感悟。

技术人创业时，找到合适的合伙人是非常关键的一点，第一，是知根知底 第二，是互补性。

技术创业可以分为四个阶段。

第一个阶段，做自己想做的事情；

第二个阶段，去做那些不想做，但又必须得做得事情；

第三个阶段：找到一群合适的人，去帮你做那些你不想做，也不擅长的事情；

最后一个阶段，有机会去做那些自己内心真正想做的事情。

任何技术都是为商业服务的，所以我们要围绕我们的商业目的、商业手段去选择所需的技术。

四、技术趋势解读

Jdk11从强大的ZGC、更好的G1到基本的字符串改进，再到各种基础类库、协议，各方面都有非常大的提高，不是修修补补，而是本身能力的巨大提升。

Java面临的最大的挑战计算模式和场景的变化.

过去十几年里，Java平台主要的投入都致力于让它可以在那种大吞吐量的、长期运行的服务器端跑的好。

但云计算兴起后，微服务、Serverless等新的计算模式对编程语言的技术要求变成支持快速启动、高数据密度、短时间运行的工作负载等。另外像大数据、人工智能、深度学习这些领域，会更看中语言对数据的运算能力等。

Java最大的核心竞争力来源于全球超过1200万的 Java 程序员，庞大的Java生态，海量的类库、工具、产品构建的无所不能的竞争力

我觉得大众对人工智能的认知偏差普遍比较大，出现这种偏差有多方面的原因：艺术作品的先入为主、对大众的人工智能知识科普的不足、媒体的过度渲染、部分从业人员的炒作等等。这种偏差的影响也是多方面的。第一个影响是大众的恐慌。比如人工智能取代人类，人工智能导致失业率升高等等，这有可能会导致社会上对人工智能的一些恐慌，一些人可能并不太了解人工智能在做什么，而是盲目的反对和否定，这当然会影响行业的发展。其实，虽然人工智能技术确实会导致某些职业岗位的需求量大幅下降，但是同时也会创造一些新的职业类型，人力资源会向新兴的岗位流动。第二个影响是大众的失望。过分的渲染和炒作会过度拉高大众对人工智能的期望值，当项目或者产品投放市场以后，如果产品的实际表现和宣传相差过大，大众就会大失所望而可能抛弃产品并且对人工智能产生质疑，这对人工智能技术和产品的改进和推广都会带来一定的负面影响。

如何学习人工智能，首先是要打好基础，数学基础、计算机基础、编程基础都要扎实；然后就是选择一个方向，人工智能领域里面课题众多，要结合自身条件、个人兴趣和行业发展选择适合自己的方向；再就是要紧跟技术的发展，人工智能领域技术更新迭代速度很快，稍不留神就会被落在后面。

在线教育跟其他互联网领域不太一样，它的先行者优势没有那么强，简单来说，这件事情你是不是第一个做，是不是第一个吃螃蟹的人没有那么关键。因为教育是一个非常重内容、重品质、重服务、重口碑的行业，快不是关键，走的方向对不对、走得稳不稳才是关键。

我得泼盆冷水，一个人是否懂技术对于把握商业趋势并没有明显关联性。尽可能了解行业发展趋势的唯一办法就是深入而透彻的研究这个行业。因此对于这个问题我唯一的建议是：别把自己的技术能力当回事。就算之前是技术大佬，也应该把自己当小白，怀着敬畏之心好好学习商业知识，认真倾听用户的声音，洞察需求的演进方向。不要死抱着自己的技术荣誉不放。