我其实算是和体制内比较熟悉的人了。我父亲是公务员，我从小耳濡目染，或多或少是见过公务员体制内的生活了。

不过，从我自己的体验和志向而言，我并不愿前往体制内。

在大学时，我曾畅想，我可以考编制，在体制内工作，挑选一个每天喝茶看报的岗位。然后在喝茶看报之时，可以自己研究技术，成为一个上班摸鱼，下班写代码的人。

但当我走入社会之后，重新思考这个问题：到底我想要的是什么？

在体制内我所获的不过是一个虚伪的“安全感”，但那个安全感真的是我需要的么？几千块工资，倒是有时间，但每天需要花费 8 个小时在一个自己并不感兴趣的工作当中，去浪费我自己的生命，换来的可能是我一篇、两篇文章的收入。

这真的重要么？我找到了自己的答案。

我读的是 B 站 Up 主手打的《米哈游员工手册》，感受很深。米哈游的员工手册里有对于技术的热爱，有工科男的直率，对于具体的细节也讲解的清晰明确。非常好。

我的自我感受是：我想去米哈游工作！我想去体验一下这样的生活！

以下是我认为写的很好的片段。其中「说到做到」、「有话直说」、「追求极致」是给职场新人很好的帮助。

以下内容来自 B 站 Up 主，感谢他的辛苦手打

作者：Violet-紫色闪电 https://www.bilibili.com/read/cv17027078 出处：bilibili

Context Not Control

 Context, not Control的理念来源于Netflix。

     先解释一下字面意思：

     什么是Context?一切做决策需要的背景信息，都叫Context。比如：我们项目目标用户是啥，我们的历史数据如何，一测用户平成是咋样的反馈，做一个Feature的人力成本如何，技术风险的高低，甚至某个同学熬夜加班效率特别高23.等等这些都是Context

  那什么是Control呢? 一切流程化的执行手段，比如: OA审批流程，指令拆分分解，委员会投票表决等。

    那对我的工作而言，这两者是啥区别？

    “Control”的工作方式意味着，严格遵守你的上司给你下达的指令，不必去多想他为什么这么决策，只管执行好就行，也不用考虑这个指令之外的事情，只对下达的这个命令范畴内的事情来负责。如果需要其他人来配合那就拆分，然后分配任务出去，然后同样严格控制他们来执行。这种工作方式，在很多大型企业和组织，都是十分常见的。

    “Context”的工作方式则不一样。当进行一个任务的时候，我们首先需要全面的了解上下文的信息，基于自己对眼前工作的专业的认识，结与相关人员充分沟通同步认知，然后做出好的解决方案并执行完成。

    举一个具体的例子，当我们要实现一个怪物的自动索敌跟踪功能的时候。

    “Control”的故事会是这样：客户端主程和策划讨论完成后，基于他的知识与经验，告诉具体做Feature的程序A，用Unity的NavMeshAgent来创建Navmesh，然后实现一个寻路算法，来满足需求上的功能。

    Context的故事则是这样的:客户端组长拉具体的负责实现的程序A同学和策划进行深入讨论，告诉他要做一个这样的Feature，并建议可以用到NavMeshAgent这样的功能。

    看起来故事的开头并没有太大的差别，甚至很多时候这两个故事的结果也会差不多，程序A顺利使用NavMeshAgent实现了Feature，并通过了验收与测试。但是当我们的项目越来越大，越来越复杂的时候，这两条故事线的发展会天差地别。

    Control线的，程序A看完了文档，看完了策划的需求文档，开始动手实现，一天后他实现了功能，在一个测试场景里跑了一下，发现没有太大问题，他喊策划来验收了一下，从而提出了修改意见，然后自己跑了跑也发现问题不大。这时候程序A认为再过一天修完Bug ，close掉这个feature毫无风险，第二天，修完bug后他把这个功能放到游戏大世界中去。这是一个面积一万倍于测试场景的世界，而且地形的复杂程度也比测试场景要高很多，不过地形复杂这件事早在程序的意料之中，他准备再花一整天时间来好好处理各种意料之外的情况。想到这里。他按下了NavMesh的Build按钮，起身准备去接一杯水，1分钟后程序A回到自己的工位，他发现这个还没有build，他敏捷的意识到出问题了，这个世界太tmd大了，光离线构建一个NavMesh就要好久，这可能会是个坑。程序啜了一口水，想了想，马上就要周版本打包了，这个任务还是得close。主程说了让我用这个方法，他应该心里有数吧，反正我毫无bug的把这个功能实现完了。策划也验收得差不多了，就这样先提交一版吧，程序A不知思考了几分钟，正等他回过神来的时候，NavMesh已经构建完了。在PC上这还是挺快的嘛，程序A继续开始做其他的功能与测试，并准时在打包前提交了全部代码。

    几个小时后，当晚的周版本打包完成了，大家开始下载，不知为何今晚的下载速度有些慢大家又开始抱怨这个WiFi AP太卡了，都集中在同一时间下载。终于，十几分钟后，有人下载好了，开始回归Feature。“卧槽，怎么闪退了？”一个用iPhone 7的人喊到、“是啊，我这里好像也闪退了。”越来越多的人发现自己的设备无法正常进行游戏。简单统计后，大家发现，除了最高端设备，好像其他的都很容易闪退。经过了1个小时的排查后，大家发现，这周周版本的包比上一周整整大了500mb，而这其中95%都是内存爆炸，都是因为太多NavMesh的载入而导致的。当目光投向程序A的时候，他很坦然地承认了问题，确实看来不能这么做。然后他用比别人更专业，更精准的语言来描述了问题，以及在当前Solution下无解的程度。现在皮球回到了客户端主程的身上，在忙碌的周版本的午夜，他的疲惫显而易见的浮在脸上。因为屁股后面还排了好几个人在反馈问题。PM还在问他要不要重新打包好验收其他功能，给他用来思考这个问题的时间只有不到一分钟。那肯定是没办法离线缓存所有的NavMesh啊。这个世界太大了，是的，程序A附和道，然后他继续在等待新的指示。主程叹了一口气。在叹气的这蓄须臾之间他想了很多，今晚的下班时间应该又是3点以后了吧；这个寻路的功能这么做下去恐怕要重新设计了；恐怕没法三言两语就把后续的走路时间给讲清楚，他自己还需要去思考更多；还有，他还想到了这项目再这么做下去，简直就是个无底深渊……

    在另一条世界线上，Context线的故事，则完全不同，程序A还在会议室里跟策划讨论，这次的会议有点长，客户端组长已经忙别的去了。“这个功能，要用在哪？地下城？”“嗯，不止地下城，大世界也会有。”策划答道。嗯，地下城还好说，除了地形之外，其他跟崩三差不多，“那大世界是啥需求？怪可以随处跑吗？”“可以。”策划随口答道，这在他看来是跟其他毫无差别的需求，十分平常。而此时，程序A脸色沉了下来，见程序A没有爽快的接锅，策划同学眉头一皱，发现事情并不简单。“有什么问题吗？”他试探性低问道。“有，你确定世界这么大，怪的活动范围是不受限制的对吧？”程序A又确认了一遍。“是的，至少是可以被拉到很远的地方的。”策划回答道。“我先去了解一下NavMeshAgent的功能吧，现在还没法确定这个功能怎么做。”好吧，虽然PM要求的需求评审时间快到了，但此时好像也只能这样了。“那么有什么问题随时找我吧，如果有问题，我们也可以想想其他的解决方案”，策划说到。两人起身走到门口，策划突然停住了脚步，因为在他看来这个需求十分平常，不是所有游戏都是这样的吗？他觉得这个问题必须问清楚。于是他问道：“我们跟其他游戏在实现上有什么不同吗？”正在翻阅手机的程序A抬起头：“有很大的不同啊”，他放下手机，上面显示着NavMeshAgent的文档。他开始跟策划解释为什么有巨大的不同，平时少言寡语的程序A，像是打开了封印千年的话匣子，为什么要离线缓存多大的Mesh，如果Runtime计算会不会卡，异步Load我们可能要自己实践…，等程序A再次闭上嘴的时候，他自己觉得自己的脑中貌似已经有了一个大概的Solution了。策划一直听完了程序A的陈述，偶尔插一两个问题，虽然有些细节他不清楚，但大概意思是get到了。好歹我本科也是读CS的呢，策划自己心里盘算着。这场会议，终于在近两个小时的讨论后结束了。

    后来程序A了解完了NavMeshAgent的功能向程序组长表示，直接来用并不靠谱，但在长期的沟通中，他们都清楚这个Feature还是必须要做完，再后来他们又去找了工具组，引擎组，大家一起讨论了一个改造NavMeshAgent的方案，基于各方面的支持，先实现了一版功能。然后，又是几周的迭代和反馈测试，才最终把这个功能稳定下来。

    Context线的故事讲完了，如果你问我为什么中间没有写，策划SB吗？程序是不是老油条这样的桥段。我会告诉你，并不是他们多么的，而是他们在长期的沟通中，已经完全同步了。互相理解是因为，在同样的背景信息（Context）下，基于逻辑，得出了同样的结论。

为什么是 Context ？

相比Control，强调Context的管理模式有什么好处？

    第一、分布式运算，让更多人参与决策，利用集体的智慧。对于组长，因为精力有限，做审批决策只花30分钟，但团队成员他们在一线决策有更丰富的外部信息，它可以花三个小时，做更多的调研之后才判断。

    第二、可以更快速的执行，不需要层层汇总，不需要汇总到一处，不需要所有决策在CEO或制作人这里排队列，能够更及时的响应。

    第三、充分的外部信息输入。在Control的模式中，任何信息都要到CEO这个节点，靠CEO再分发出去，CEO很大程度变成了公司和外部之间的接口，相比单靠CEO接触外界情况，了解市场行业或者外部环境，让更多的同事，更多节点直接面向行业，信息确实会更充分，角度也不一样。

    第四、参与感激发创造力。做同样的事情，如果团队成员知其然，也知其所以然，会比只知道指令，做起来更有意思。这个对于发挥团队成员创造力是有帮助的。

    第五、可规模化。Context的建设，表现形式可能是内部的系统，可能是知识共享文档，这些都是可以复用的，是可规模化的。而CEO和Leader们的时间、精力是有瓶颈，靠拼体力，脑力，耐力来解决，是有瓶颈的，是没有规模效应的。

 当然，有时候也需要Control：

        一、 紧急情况和重点项目。比如重大的玩家口碑危机需要快速响应。重点项目也是如此，如果竞争对手已经逼近，这个时候进行分布式的讨论，自下而上的涌现，来不及解决问题，时间窗口很快就过去了。所以紧急情况和处理重点项目需要Control。

        二、 创新业务和新团队早期。如果一个新团队设立，或者一个新Leader刚加入，这个时候需要Control，新业务早期，需要更多支持配备资源的时候，也需要CEO统一协调，主导进展。

        三、 不匹配的职位安排。某个岗位的人跟公司理念差距很大，那么他的Leader也是需要Control来干预的，比如一个资深运营同学，之前一直是做强商业化产品，游戏运营以拉收入为主。那么他的Leader在早期也是需要Control的。

说到做到

什么是”说到做到”？

“说到做到”的意思是，在miHoYo内，以任何形式作出的承诺，都应该在承诺的时间内，保证质量的完成。承诺的形式可能是一封邮件、一个TAPD上的任务、一段微信上的聊天，也可能是在走廊里跟别人说了一句话：”诶，这个东西我今天晚上给你做好。”那么就要在你所承诺的时间节点保证质量地把它完成，这就是说到做到的意思。

为什么要”说到做到”？

说到做到是项目能够正常推进的最基本的执行力保证。

如果每个人的承诺不能够按时兑现的话。那我们就无法基于这个承诺去做一个更大的团队的计划，我们的产品计划就全都是空谈。

当然，作为一个数字娱乐产品，在软件工程中会碰到各种各样的风险，所以更需要我们可以科学的预估，科学的做出计划。

说到做到，就是这样一个十分基础的要求。

怎么做到”说到做到”？

1.先搞清楚任务需求，才能给出靠谱的承诺

在一项任务的讨论阶段。如果你对其中的目的、要求存在疑问时，务必当面提出来。千万别抱有”应该是这么个意思吧”之类的想法，很可能你的理解和现实会有极大的偏差。

有哪些基本信息是你需要明确的？

1）交付结果是什么？ （是一个工作计划的邮件？完成一个功能的代码？还是下班的时候把空调关掉？）

2）交付的衡量标准，完成这项工作结果的程度。你们对好坏的衡量标准的认识是不是一致的？（能用？易用？友好？……什么程度呢？）

3）交付的截止时间，也就是我们常说的Deadline。

我们希望就算你的Leader或者合作伙伴没有很清楚地定义这些问题时，你也要和他非常明确地沟通清楚，因为这会直接影响到你是否能说到做到。

除了这些直接要求以外，任务和任务之间的上下游关系，是否存在配合这项任务的人等这些辅助信息，也都能帮助你更好的理解这项任务。在充分了解任务的背景信息后，尽可能把这项任务拆解成细分行动，并评估清楚每一个小行动所需的时间和资源，你才能给出一个真正意义上务实的、可达成的承诺。

2.对于没有把握的事，一定不要给出承诺

主要体现在三点：

1）当工作任务具有不确定性时，正确且安全的做法是：不要草率做出承诺。你应该把你看到的不确定性因素抛出来，并且主动去了解这些不确定的情况。

2）对于无法评估的不确定性问题，先进行尝试，摸一摸路，估计一个预研时间。等预研时间到了，或者有了阶段性结论，再进行下一步的评估。

3）绝对不要因为：碍于面子、Push自己不要拖延或迫于组长压力等愚蠢的理由做出你预期无法完成的承诺

特别对于新人，或者对于项目情况不了解的时候。请务必记住，不作出承诺才是最负责的做法。否则耽误的会是整个项目的进度预期，而不仅仅是眼前的这一个任务。

3.充分细分&累加时间，是一个靠谱的预估方法

为了能够评估出一个合理的任务完成时间，我推荐一个方法：

在充分了解需求的情况下把每一个需求和目标进行细分，细分到不能再细分为止，然后把这每一细分项的时间算出来，再把它们累加起来，应该会有一个相对靠谱一些的结果。一般来讲， 一个细分任务的时间不应该超过2天时间。否则，我会认为这个任务一定有可以继续细分的空间与必要。

有话直说

什么是”有话直说”？

有话直说的意思是：在我们公司内，当你发现一个问题，或者感觉哪里做的不对的时候，唯一正确的做法是：找到这个问题的当事人，当面向他客观陈述这个问题，这个就是有话直说。

这个问题，可能是产品上的问题，比如说你觉得这个地方策划设计的不对，也可能是团队上的问题，比如说你觉得某个地方我们运转不对，或者说你认为某个人好像没有尽到应尽的职责。不论什么问题，我们都应该在看到这些问题后的第一时间当面有话直说。

为什么要做到”有话直说”？

有两个重要的原因：

1有话直说是通往卓越产品的重要保障；

2.鸵鸟姿态面对小问题，必将酿成大炸弹。

我分别来解释一下。

先说第一条：有话直说是通往卓越产品的重要保障。

在miHoYo刚刚成立的时候，我们几个创始入共同立下了一个规则：无论遇到什么问题，我们都要有话直说。有话直说并不容易，但是作为一家创意企业，有话直说是通往卓越的唯一途径。我们希望自己和miHoYo都能不断进化，而为了实现这一点，我们需要对彼此极度坦诚，有话直说。

因为我们知道任何一个人在团队里面，不管是制作人也好，是策划负责人也好，是美术负责人也好，都是有他的局限性的。简单来说。作为一个人，他一定有其擅长的地方，和不擅长的地方；有他特别容易关注的地方，和容易忽视的细节。所谓人无完人，人就是这样一种生物。但我们对于产品的要求是无限接近于完美的，那怎么办呢？必须通过一个团队来取长补短，互相弥补彼此的缺陷，发挥长处。那如何做呢？就是要在团队里面，可以听到来自不同角度的声音和意见，所以我们需要有话直说。对于任何一个人，当我们觉得他负责的东西有问题的时候，应该立刻告诉他，这样才能让他获得一个更全面的认识，避免个人视野的局限，帮他建立一个全面的认知。只有看到的问题全面了，再以严密的逻辑进行判断，才有可能做出比较好的决定。

这里有一个很有趣的现象。大家都知道，我们公司没有主美，主程这样的Title，而只讲美术组长，程序负责人。为什么呢？因为主x。往往会给人一种，他说了算，对错都由他来一言定之的印象。这样以难免个人影响太重，难免在获得部分正确判断的同时也放大了个人缺陷。而XX负责人，或XX组长则意味着：这个岗位的同学，负责组织整个团队一起来取长补短，发挥每个人擅长的事情， 最终把一个问题解决好。他是组织者，也是负责人，但不等于其他人要言听计从。每一个人都拥有对自己负责事情的决策权，也必须遵循有话直说，开放地接收各种意见。

再说第二条：鸵鸟姿态面对小问题，必将酿成大炸弹。

在miHoYo短暂的发展史上。我们也曾经犯过类似的错误。冰冻三尺非一日之寒，大问题也都是因各种小问题没有被及时解决从而变得愈发严重。通常当问题还在初期阶段时，解决起来不仅成本小，方式也多。但如果问题没有得以及时暴露，经过不断积累，它会像病毒一样扩散，破坏面越来越大。这时再去解决它就可能会牵一发而动全身，付出的代价无法估量，甚至导致团队决裂、产品最终失败。

所以有话直说，可以保证在问题还比较小的时候就暴露出来，并把它及时解决。我们坚信，我们应当把问题和分歧摆到桌面上，从而及早地暴露问题，及时的解决问题。

“有话直说”该怎么做？

1.当面直接说，及时说，绝不在背后说

当看到任何项目上的问题、产品的缺陷、项目成员的不足的时候，当遇到跟团队其他人意见不合或者对某些事情做法不满的时候，唯一正确的做法就是找到当事人，当面跟他反馈、吐槽甚至吵架。直面所有的问题，有话直说，创造环境做直接的沟通，这是正确的做法。对任何公司同事，当面不会说的事情也绝不在背后议论。一个公司里直在讨论问题的场合没有声音而背地里有嗡嗡嗡的声音，就是不正常的表现。这种嗡嗡嗡的声音大都是以匿名、小圈子的形式存在的；小团体甚至是办公室政治的形成大多都是从两个人同时吐槽同一个对象开始的。背地吐槽对任务、团队、尤其是对你自己，没有任何正面作用。非但不会解决问题反而会增加问题的复杂度。

2.客观陈述，对事不对人

有话直说的文化有时候会让人不适，尤其在存在分歧的时候，我们有话直说的唯一目的就是让问题或者分歧暴露出来并朝着好的方向去发展。因此只有客观陈述事实，只针对”事” 本身才能推动问题的解决，针对”人”解决不了任何问题。

表达时怎么算是对”事”，怎么算是对”人”：

对”事”：对事情本身下判断（正确与否的结论）、给支撑结论的论据（问题定位）或提供处理方式的建议（解决问题的方法）。如”这打出来的伤害太低了（判断、结论） ，你的圣痕搭配得有问题（问题定位），换个”薛定谔上”输出会更高（解决问题的方法）” 。

对”人”：对人（人格、个性）产生攻击行为。如：”某某就是不行”，”某某完全不懂”。

3.直面冲突，求取共识

很多人以为，掩盖分歧是维持和睦最容易的方法，这种观点大错特错。回避冲突也就回避了解决冲突的机会；躲过了小的矛盾，之后往往会有大的矛盾，甚至会导致人与人的疏离。只有直面且积极解决小的矛盾，才会更好地维持长久的信任关系。认真处理分歧，有话直说，当事方之间开放、坚定地进行高质量的反复讨论，细心梳理所有问题的过程，这些方法都非常有用。因为它们有助于双方了解此前不清楚的情况，这是有话直说的另一层含义。

我们需要做三件事：

1）把我们的真实想法摆在桌面上；

2）存在经过深思熟虑的分歧，但人们愿意在相互了解的过程中更改观点；

3）如果分歧依然存在，拥有一种大家一致同意的决策方式 （如投票或者拥有清晰的权威）。以便我们能够不带怨气地把分歧留在身后。

我们相信任何组织或任何人际关系想要保持的好，这些都是必需的。我们极力鼓励大家有话直说。直面冲突，求取共识。

4.保持开放心态，着眼大局

我们充分鼓励大家有话直说，但这并不意味着你提出的建议或吐槽就一定要被采纳和解决。影响一件事对错与否的判断因素有很多（可能是时机、获取背景信息的丰富程度、看待问题视角等等），但我们最终会把决策权交给具体负责这项任务的同学（他所掌握的信息不但是最全面的，同时承担的责任也是最大的）。当观点争执不下，然而事情还要继续推进的时候，就需要由这位决策同学出来确定路径并执行落地。如果决策已出，就必须要放下个人的异议（事后会进行决策复盘），全力以赴去达成目标。

针对有话直说我们总结一下，在miHoYo最让人痛恨的有这5种人：

1.马后炮的，事后会说”你看，当时我就觉得这地方不对……”；

2.当面不说，喜欢在背后议论人的，拉帮结派搞小团体的；

3.分不清楚什么是对事，什么是对人的；

4.好好先生，明明看到了问题就让问题烂着，而无动于衷的；

5.唯我独尊，个人意志高于集体意志的。

最后，必须说明，有话直说≠一人一票。

这是关于有话直说必须跟大家强调的一件事情：有话直说的目的是暴露问题。任何人提出来的意见，可能是对的，也可能不对。可能只是提问者自己的另一种局限视角。所以，有话直说绝对不意味着说了必须改，也不应该被滥用做少数服从多数。

我们一直以来的理念都是，谁在一线做这件事情，谁最了解一线的情况，谁来做决定，并为结果负责。有话直说，是为了帮这个决策者，更多的看到全局的信息与意见，然后让他可以在一个更丰富的信息下，做出更好的决定。

追求极致

怎么做才算“追求极致”？

有两句话请大家记住：

1.别人能做到的事情，我们一定能做到；

2.没有什么事情是做不到的。

这是有严密逻辑的两句话，而不是鸡汤，我们逐一解释一下。

先说第一句，别人能做到的事情，我们一定能做到。其实我们历史上一直是这么做的。比如说我们做崩2时，之前从来没有用过Unity，但是我们看到其他团队可以用Unity+ Maya来做出流畅细腻的纸片人骨骼动面，那我们就坚定地用同样的技术路线在iPhone4的机型上做出了一样能够流畅运行的效果。再比如说我们在做崩3卡通渲染的时候，我们之前也从来没做过3D游戏，但是.看到Guilty Gear卡通渲染效果做出来了，虽然它是在Play Station上，但我们觉得同样的方法在mobile平台上面做，基于iPhone6的硬件性能，其实问题也不大，所以说最终我们也确实在效果上实现了十分接近的卡通渲染表现。

那么逻辑上我怎么解释这个问题呢？上文中提到过，我们所处的是一个数字创意产业，我们所用的生产工具与这个地球上所有顶级的公司相比，没有本质差别。最好用的商业引擎，源代码我们都有，第三方中间件都可以买到，Open Source项目大家都能看到。然后生产所需的知识，我们能够接触到的也和全球其他顶级公司无异，开源的代码，最新研究的Paper与分享，这些都是可以公开透明看到的。那么在我们的生产工具和知识都跟别人基本一样的情况下，为什么别人做出来的东西我们做不到？我能想到的理由只有一个，我们比他们“笨”！但是miHoYo一直崇尚的是跟优秀的人在一起做优秀的事情，没有人承认自己笨。所以说我们没有理由说在这个世界上别人能做到的事情我们是做不到的。做不到的人，不应该在miHoYo。

再说第二句话，没有什么事情是做不到的。你可能会想这个实在是太鸡汤了，这个世界上怎么可能会没有什么事情是不可能做到的。

其实在我们看来，一件事能否做到，这是个态度问题。比如有人提出一个需求，然后程序说这个东西我做不了，这在miHoYo就是一个很严重的态度问题，因为这不是一个追求极致的做事方式和态度。一个东西不能实现，一定是有原因的。假设我极端的反问，给你200年时间，这个东西还做不出来吗？我觉得200年以我们目前的科技发展速度来看，很多现在幻想的东西都有实现的可能。那还有什么理由说做不出来呢？所以说，能做或者不能做，是一个在各种条件下才能判断的复杂问题，不是一句话不能做就可以草率下结论的。我们的目的是解决问题，而不是甩锅。

正确的沟通方式是，当我们遇到困难的时候，去讲清楚为什么在你看来它做不出来，这一定是有原因的。 可能是因为，我们代码上有历史遗留问题，要实现这个需求，先要两周的时间来重构代码，然后再花三天时间来把这个feature做出来。那把这个情况讲清楚，就是正确沟通方式的。再比如，我们所做的一个设计，实现成本很高，会让运维成本翻5倍，执行的同学一看尿了，说这哪行，肯定不能接受，然后就说不能做。但可能这个成本正是我们乐意去承受的，因为它能够给用户带来的变化远比这个付出还要大，或者这个功能做出来就是产品的核心竞争力，我们就是要做不计性价比的投入。所以说，能做不能做，还是必须结合各方面信息来判断，而不能单方面草率下定论。只有把这样的问题抛出来，我们才能够分析出是否存在一个更好解决方案，可能存在work around的方法，绕过困难，又满足需求，也可能这就是一个要不计成本硬刚下去的核心功能。

我们现在正在做的项目，少则几十人，多则几百人，在一个这么大的一个团队规模下，任何人都无法看到整个项目的每一个细节。所以要做到产品结果上的追求极致，就要求每一个人必须把自己所做的事情做到极致。只有每个人都以追求极致去要求自己，把我们产品的每一个基本模块做好，最终合在一起，那才能最终成为一个极致的产品。

今天在听播客的时候，听到了一个很有意思的观点：“定位理论不是在所有的领域都有用的，主要是广告营销业，以及一些偏快消品的行业“。

当时主播举的例子是：今麦郎通过推出一款“凉白开”的产品，在市场上异军突起，占领了自己的一席之地。

作为故事，必然有一定的夸大的成分，但我觉得这个逻辑很合理：

• 优秀的人往往不需要定位就可以很优秀。
• 中庸的人需要定位来让自己和别人看起来不一样，看起来很优秀。

我和朋友聊起来时举的例子是 王垠，看我博客的人可能不少人就知道。对于王垠而言，他没有定位就足以让他被很多人所知道。而只有中人之姿的我，只有通过定位才能在众多工程师当中，变得与众不同，为人所知。

如果你也是一个“标品”，不妨找找自己的定位，让自己与众不同。

合理。

如果说，如何拥有一个稳定的个人评价体系 谈的是「选择和目标」，那么今天要聊的就是达成目标的路线。

每个人都需要有一个属于自己的战略，来逐渐的达成自己的目标。目标搭配着战略，剩下的便只有努力达成战略过程中的每一个 Milestone，最终达成自己的目标了。

战略的重要性不言而喻。

接下来的重点是：什么是战略？

战略或策略，是指为实现某种目标（如政治、军事、经济、商业或国家利益等方面的目标）而制定的高层次、全方位的长期行动计划。

维基百科

从维基百科的描述当中，我们可以抽出几个关键的定义

• 战略的设定应该是达成某个目标：先有目标再有战略，而不是先有战略再想目标。
• 战略应该是长期行动计划：战略意味着你要做一个偏长期的规划，这个规划可能是一年、三年、五年，甚至是十年。但肯定不是一星期，两星期的，那个叫计划或 Todo。
• 战略应该是高层次、全方位的计划：高层次意味着战略关注的是一个在长周期下有效的事情， 而非短期有价值的。追求的更多的是长期价值；而全方位则提醒我们，战略不止我们能一眼看到的东西，还包括我们需要仔细思考才能意识到的问题。

但上面的这些似乎还是有点模糊，不具备可执行性，那是否有一些更具有可执行性的建议？

1. 战略的核心是聚焦

战略的重点不在于你要做什么，因为那个已经被目标定义。反而，战略要定义你不要做什么。我们选择做一件事的理由可能不重要，但我们选择不做一件事的理由非常的重要，因为他代表着背后的思考。

同样的，战略因为是一个更长期的过程，我们必须确定哪些事情是重要的，而重要的事情，往往只有很少的几件。如果你的战略有 30 条，那大概率不是战略，而是战术。

2. 战略要找到关键点

战略是要解决一个更加长期的问题和方案，在这个过程中，你需要做的是尽可能的找到其中的关键点位，通过撬动一个关键点位，来降低自己后续的实现成本。如果战略虽然制定，但却没有找到关键点位，可能会让你的目标离你越来越远。

不过，如果你的能力和判断力不足以让你找到战略的核心关键点也不影响，可以先设定一个指标，先快速尝试一下， 并推演当前的指标和手段是否可以持续产生效果和价值，再决定战略的关键点。

一些核心的判断点包括：

• 不要边污染边治理：边污染边治理意味着你永生无法达到目标，你可以无限逼近目标，但永远无法达成目标。
• 权责对等：在设计战略体系的时候，往往会遇到需要和他人协作共同达成。在涉及到和他人共同协作的时候，一定要注意权责对等。以及，要尝试为他人的部分设定 Plan B ，不要出现一着不慎，满盘皆输的局面。

我并不是一个学 CS (Computer Science)出身的工程师，我是一个学 EE（Electrical Engineering）的工程师。我的大学本科专业是 —— 电子信息科学与技术（Electronic Information Science and Technology）。

虽然本科不是 CS ，没办法如其他从业者一般，系统性的学习数据结构、计算机原理等一系列基础课程，给我的计算机从业带来了一定遗憾。但好在这些经典内容我可以通过 Mooc、自己阅读相关的图书来获得，虽然不能说学的就比人家科班的好，但好在是够用。

此外，软件行业的从业比较依赖你的实战能力，我因为喜欢 CS，所以其实从初中就开始 Coding ，当我毕业的时候，已经 Coding 了近 10 年，越过最基础的那些痛苦的日子，倒是也不影响我就业。

反倒是 EE 的背景，赋予了我无限的可能。我可以从事前端、后端的工作，但同时也可以成为一个嵌入式工程师（毕竟大学整这玩意的），也可以自己亲自上手设计板子、焊板子，给我了不一样的可能性和未来。

反倒是出身于 CS 的同学，因为所学内容和所工作内容的高度一致性，很难表现出背后的交叉价值，比较难有更多的选择。

我不后悔我学的是 EE。

不过，我还是会拿自己学 EE 来打趣：「当年报志愿的时候不懂，打电话给招办，问这个是不是 IT 行业，人家说是，我就报了。没想到这个是偏电子的 IT…」

我的博客的一个特色是，我很少删除旧文章。

一个核心的原因是在我看来，这些旧文章虽然拙劣、天真、单纯，但从某种视角上，那是我的过去。我没必要修改我的旧文章，来掩盖自己的过去。我不太需要所有人都认为我是完美的。

当然，另外一个重要的原因可能是我懒得去修改自己之前的文章了。毕竟目前已经一千多篇文章了，实在是懒得更新了。

倘若我要写一篇文章，且和之前的文章相关，我可能会选择在文章当中引用旧文章，从而方便读者了解到之前我的思考轨迹。

而不删除旧文章获得的一个好处便是，我的思考轨迹，我如何变成如今的我都有迹可循。