韶光回到8年前，我人生中的第一份演习事情，是在某互联网公司的无线搜索部做一个C++工程师。当时的我可谓斗志昂扬，想要大干一场，结果第一次上线就写了人生中第一个Casestudy。由于对支配环境的不理解，把SVN库里的配置文件缺点地发到线上，并且上完线就去吃晚饭了，等用饭回来创造师傅在焦头烂额地回滚配置。那次故障造成了一个核心做事20分钟不可用，影响了几百万的用户。
这仅仅是一个开始，在后来半年的韶光里，我险些把所有职场新人可能犯的缺点都犯了个遍。架构师让我调研一个抓取性能提升方案，我闷头搞了两周，也没有得出任何结论；本来安排好的开拓操持，由于我临时要回去写论文，搞得经理措手不及；参加项目漫谈会，全程“打酱油”……那段韶光，自己也很苦恼，险些每天晚上11点多才走，很累很辛劳，但依然拿不到想要的结果。
8年过去了，自己从一个职场小白逐步发展为一名技能Leader。我创造团队中的很多同学在一直地重复犯着自己当年类似的缺点。他们并不是不努力，到底是哪里出了问题？
经由一段韶光的不雅观察与思考后，我想我找到了答案。那便是：我们大多数同学在事情中缺少原则的辅导。
原则，犹如指引行动的“灯塔”，它连接着我们的代价不雅观与行动。
不久前，桥水基金创始人雷·达里奥在《原则》一书中所传达的理念，引爆了朋友圈。每个人都该当有自己的原则，当我们须要作出选择时，一定要坚持以原则为中央。但是在现实生活中，我们每每短缺对原则的总结，对付很多人来说这是一门“只可融会不可言传”的玄学，是属于老司机的秘密，实在不然。
“追求卓越”是美团的代价不雅观。作为一名技能职员，我们该当如何践行呢？
本文总结了十条精进原则，希望能够给大家带来一些启示，更好地辅导我们的行动。
原则一：Owner意识
“Owner意识”紧张表示在两个层面：一是负责卖力的态度，二是积极主动的精神。
（1）负责卖力是事情的底线
首先，要对我们交付的结果卖力。项目中每一个设计文档、每一行代码都须要负责完成，要对它的质量卖力。如果设计文档逻辑混乱，代码没有注释，测试时创造一堆Bug，影响的不仅仅是RD的工程交付质量，还会对协同事情的RD、QA、PM等产生不好的影响。久而久之，团队的整体交付质量、事情效率也会逐步低落，乃至会导致团队成员之间产生不信赖感。
其次，我们要对开拓的系统卖力。系统的架构是否须要改进，接口文档是否完善，日志是否完全，数据库是否须要扩容，缓存空间够不足等等，这些都是须要落地的事情。作为系统Owner，请一定要负责履行。
（2）积极主动是“Owner意识”更高一级的哀求
RD每天要面对大量的事情，而且很多并不在操持内，这就须要具备一种积极主动的精神。例如我们每天可能会面对大量的技能咨询，如果客户提出的问题很永劫光得不到回应的话，就会带来不好的客户体验。
很多同学说忙于自己的事情没有韶光处理，有同学以为这件事不是很主要，也有很多同学是看到了，但是不知道怎么回答，更有甚者，看到了干脆装没瞥见，这些都是缺少Owner意识的表示。精确的做法是积极主动地推动问题的办理，如果韶光无法排开或者不知道如何办理，可以直接将问题反馈给能办理的同学。
积极主动还可以表现在更多方面。比如：很多同学会自发地梳理卖力做事的现状，根据接口在性能方面暴露的问题提出改进见地并持续推动办理；也有同学在跨团队沟通中主动承担起主R的角色，积极创造问题、暴露问题，推动互助团队的进度，担保项目顺利推进。
这些同学无一不是团队的中坚力量，以是，我们在做好自己份内事情的同时，也该当积极主动地投入到“份外”的事情中去。一分耕耘一分收成，不要给自己设限，努力成为一个更加精良的人。
原则二：韶光不雅观念
相信大家都有韶光不雅观念，但是真正能实行到位的可能并没有那么多。互联网是一个快速发展的行业，RD的研发效率是一个公司硬实力的主要表示。项目的定期交付是一项很主要的实行能力，在很大程度上决定着领导和同事对自己靠谱程度的评价。
大家可能会问：难度险些相同的项目，为什么有的同学常常Delay，而有的同学每次都能按时上线？
一个很主要的缘故原由，便是这些按时交付的同学每每具备如下两个特质：干事有操持，事情分主次。
（1）事情安排要有操持性
常日，RD在设计评审之后就能预估出精确的开拓韶光，进而再合理地安排开拓、联调、测试操持。如果是项目卖力人，那么就会涉及折衷FE、QA、PM等多个工种的同学共同完成事情。凡事预则立，不预则废。在操持制订过程中，要尽可能把每一项拆细一点（至少到pd粒度）。事实证明，粒度越细，操持就越精准，实际开拓韶光与操持之间的偏差就会越小。
此外，务必要规定明确的可检讨的产出，并在操持中设置一些关键的韶光点进行核对。无数血淋淋的事实见告我们，很多项目延期都是由于在一些关键交付点上双方存在不合造成的。例如：后台RD的接口文档操持在周五供应，FE认为是周五上午，而RD认为是周五放工条件交，无形中会给排期带来了1pd的偏差。以是，我们要做到操持粒度足够细，关键韶光点要可检讨。
（2）事情安排要分清楚主次
我们每天要面对很多的事情，要学会分辨这些事情的主次。可以考试测验利用“艾森豪威尔法则”（四象限法则），把事情按照主要、紧急程度分成四象限。
优先做主要紧急的事情；主要不紧急的事情可以暂缓做，但是要持续推进；紧急不主要的事情可以酌情委托给最得当的人做；不主要不紧急的事情可以考虑不做。
很多项目无法定期交付的缘故原由，都是由于实行人分不清主次。比如：在开拓中须要利用到ES，一些不熟习ES的同学可能想系统性地学习一下这方面的知识，就会一头扎进ES的汪洋中。末了才创造，原来一天就能完成的事情被严重拖后。
实际事情中，我们应该避免这种“本末倒置”的事情办法。在本例中，“系统性地学习ES”是一件主要但不紧急的事情。要学会分辨出这些滋扰的事情项，担保主要紧急的事情能够按时交付。
原则三：以终为始
“以终为始”（Begin With The End In Mind），是史蒂芬·柯维在《高效能人士的七个习气》中提到的一个习气，它因此所有事物都经由两次创造的原则（第一次为心智上的创造，第二次为实际的创造）为根本的。直不雅观的表达便是：先想清楚目标，然后努力实现。
在事情中，很多RD每每只是专一走路，很少举头看天。每次季度总结的时候，罗列了很多项目，付出很多努力。但是详细这些项目取得了哪些收益，对业务有哪些提升，却很难说出来。这就解释在事情中并没有遵守“以终为始”这一原则。
此外，很多同学在做需求的过程中，对付目标与收益关注不足，系统上线之后，也没有持续地跟进利用效果。这一点在技能优化项目中表示的尤为明显。
例如：在一个接口性能优化的项目中，经由RD的努力优化，系统TP99缩短了60%，支持QPS提升了2倍。但是系统到底须要优化到什么程度呢？是不是缩短60%，提升2倍就能知足需求呢？
在优化之前，很多同学常常忘却设置一个预设的目标（TP99小于多少，支持QPS大于多少）。我们必须清楚，优化一定是有缘故原由的，比如预期某节假日流量会暴增或者某接口超时比例过高，如果不进行优化，系统可能会存在宕机风险。办理特定的问题才是技能优化的终极目的，以是要根据问题设定目标，再进行优化。
“以终为始”，这一原则还可以浸染于我们的学习中。很多同学看过很多技能文章，但是总是觉得自己依然一无所知。很主要的一个缘故原由，便是没有带着目标去学习。
在这个信息爆炸的时期，如果只是碎片化地吸收各个公众号推送的文章，效果险些可以忽略不计。在学习之前，我们一定要问自己，这次学习的目标是什么？
是想把Redis的持久化事理搞清楚，还是把Redis的主从同步机制弄明白，亦或是想学习全体Redis Cluster的架构体系。如果我们能够带着问题与目标，再进行干系的资料搜集与学习，就会事半功倍。这种学习模式的效果会比碎片化阅读好很多。
原则四：闭环思维
你是否碰着过这样的场景：参加了一个设 计（或需求）评审，大家兴致勃勃地提了很多合理的见地，等到再次评审的时候，却创造第一次提的很多问题都没有得到改进，很多谈论过的问题须要从头再开始谈论。这种情形便是一种范例的事情不闭环。
之前看过一句话：
一个人是否靠谱，就看他能否做到凡事有交代，件件有着落，事事有覆信。
这便是闭环思维的主要性，它强调的是一种即时反馈闭环，如果别人给我们分配了一个任务，不管完成的结果如何，一定要在规定的韶光内给出明确的反馈。
例如：在跨部门的沟通会议中，虽然各方达成了同等，会议发起者已经将终极的记录周知大家。但是，到这一步实在并没有完成真正的闭环，在落地实行过程中很可能还存在一些潜在的问题。
例如：会议纪假如否经各方仔细核对并确认过？会议中明确的To Do进展是什么？完成结果有没有Check的机制？
如果这些没有做到的话，就会陷入“沟通-创造问题-再沟通-再创造问题”的恶性循环中。
真正的闭环，哀求我们对事情中的事情都能够养成良好的思维习气，沟通要有结论，关照要有反馈，To Do要有验收。
“闭环思维”还哀求能够定期主动进行阶段性的反馈。刚参加事情时，我接了一个工期为两个月的项目。全体项目须要独自完成，自己每天按照操持，井井有条地进行开拓。大概过了两周之后，Leader讯问项目进度，虽然我已经跟他说没问题。然而，Leader见告我，由于我每天对着电脑也不说话，让贰心里很没底。
这时，我才意识到一个很主要的问题，我跟Leader之间存在信息不对称。从那往后，我就时时时得跟他申报请示一下进度，哪怕就只有简短的一句话，也可以明显觉得，他对我的信心增加了很多。特殊是我做Leader之后，对这种闭环反馈的理解，就更加深刻了。从Leader的角度看，实在只是想知道项目是否在正常推进，是否碰着问题须要他帮忙办理。
原则五：保持敬畏
“君子之心，常怀敬畏”，保持敬畏之心能够让我们少犯缺点。在事情中存在各种各样的规范，例如代码规范、设计规范、上线规范等等。我们必须明白，这些规范的制订一定是基于某些客不雅观缘故原由的，它们都是历史上无数Case积累而来的履历。团队里的每一个成员都该当学习并严格遵守，这一点对付新人尤其主要。
当我们进入到一个新的团队，请先暂时忘掉之前的习气，要尽快学习团队既有的规范，并且让自己与团队保持同等。以编码风格为例，很多同学每每习气于自己之前的代码写作风格，在做新公司第一个项目时，也按照自己的习气进行变量、包的命名等等。结果在代码Review过程中，被提了很多修正见地，不得不返工重写，得不偿失落。
如果能够保持敬畏之心，提前理解编码规范，这种问题完备可以避免。
类似的问题，还包括对上线流程的不理解，对回滚操作不熟习，对SRE线上变更过程不理解等等。除了这些显而易见的规范，还有一些约定俗成的规则。个人建议是：如果有事情拿不准，不妨多问问其他同事，不要凭自己的觉得干工作。
保持敬畏之心并不虞味着要“因循守旧”。在我们充分理解这些规范和约定之后，如果以为存在欠妥之处，可以跟全组同学谈论，是否采纳新的建议，然后及时去更新迭代。实在，让规范与约定与时俱进，也是另一种形式的敬畏。
原则六：事不过二
“事不过二”，是我们团队一向坚持的原则，它可以解读为两层含义。
一层含义是“所有的评审与问题谈论，不要超过两次”。之以是有这样的哀求，是由于我们创造，很多RD都把韶光花费在一些无休止的评审与问题谈论中，真正投入到实际开拓中的韶光反而很少。在实际事情场景中，我们常常会碰着一些不是很成熟的需求评审。这些需求文档，要么是背景与目标暗昧不清，要么是产品方案描述不足细化，或者存在歧义。RD与PM被迫反复进行谈论，我曾经碰着过一个需求评审，进行了三次还被打回。
同样的问题，在设计评审中也习认为常。方案固然须要经由反复的谈论，但是如果迟迟不能达成同等，就会耗费很多RD与PM的宝贵韶光，这就与提升研发效率的理念背道而驰，因此我们团队规定：所有的评审最多两次。
通过这种办法，倒逼利益干系方尽可能地做好需求与方案设计。评审会议组织前，考试测验与所有干系职员达成同等，讯问对方的见地，并进行有针对性的谈论，这样能够大大提升评审会议的效率和质量。如果在第一次评审中不通过，那么就只有一次机会进行复审。一旦两次不通过，就须要进行Casestudy。
“事不过二”原则的另一层含义，是“同样的缺点不能犯第二次”。每次故障之后，Casestudy都必须进行深刻的总结复盘，对故障缘故原由进行5Why剖析，给出明确可实行的To Do List。每次季度总结会，大家自我反省问题所在，不才个季度必须有所改进，不能再犯类似的缺点。孔子云：“不迁怒，不贰过”，在缺点中反思与发展，才能让我们成为更精良的人。
原则七：设计优先
“设计优先”这条原则，相对来说更加详细一些。之以是单列一项，是由于架构设计太主要了。
Uncle Bob曾说过：
“软件架构的目标，是为了让构建与掩护系统的所需人力资源最小化。”
架构设计，并不仅仅关系到系统的质量，还关乎团队的效能问题。很多团队也有明文规定，开拓周期在3pd以上的项目必须有设计文档，开拓周期在5pd以上的项目必须有设计评审。在详细的实行过程中，由于各种缘故原由，设计每每并不能达到预期的效果。
究其缘故原由，有的是由于项目周期紧，来不及设计的足够详细。有的是由于RD主不雅观上认为项目比较大略，设计草草了事。
无数事实证明，忽略了前期设计，每每会导致后续开拓周期被大幅拉长，给项目带来了很大的Delay风险。而且最恐怖的是，不当的设计会给项目带来巨大的后期掩护本钱，我们不得不腾出韶光，专门进行项目的优化与重构。
因此，无论什么时候都要记住“设计优先”这一原则。磨刀不误砍柴工，前期良好的设计，会给项目开拓以及后期掩护带来极大的收益。
“设计优先”这一原则，哀求写别人看得懂的设计，我们理解一个别系最直接的路子便是结合设计文档与代码。在实际事情中，很多同学的设计文档让大家看得一头雾水，通篇下来，看不出系统整体的设计思路。
实在，设计的过程是一种智力上的创造，我们更希望它能成为个人与集体聪慧的结晶。
如何才能让我们的设计变得普通易懂？
我个人认为，设计该当只管即便利用比较合理的逻辑，进而把设计中的一些点组织起来。比如：可以利用从抽象到详细，由总到分的构造来组织材料。在设计过程中，要以需求为出发点，通过合理的抽象把问题简化，讲清楚各个模块之间的关系，再详细分述模块的实现细节。
做完设计之后，可以发给比较资深的RD或者PM审阅一下，根据他们的反馈再进行完善。好的设计，一定是逻辑清晰易懂、细节落地可实行的。
原则八：P/PC平衡
“P/PC平衡”原则，即产出与产能平衡原则。伊索寓言中讲述了一个《生金蛋的鹅》的故事，产出好比“金蛋”，产能好比“会下金蛋的鹅”。“重蛋轻鹅”的人，终极可能连产蛋的资产都保不住；“重鹅轻蛋”的人，终极可能会被饿去世。产出与产能必须平衡，才能达到真正的高效能。
为了让大家更清晰的理解这一原则，本文举两个例子：
从系统的角度看，每一个别系都是通过持续不断地叠加功能，来实现其产出，而系统的产能是通过系统架构的可扩展性、稳定性等一系列特性来表征。为了达到产出与产能的平衡，须要在不断支持业务需求的过程中，持续进行技能架构层面的优化。
如果一味地做业务需求，经由一定的韶光，系统会越来越慢，终极影响业务的稳定性。反之，一个没有任何业务产出的系统，终极会消亡。
再从RD的角度来看这个问题，RD通过做需求来给公司创造代价，实现自己的产出。而RD的产能是指技能能力、软本色、身体康健状况，有这些成本后，我们才能进行持续的产出。在日常事情中，我创造很多RD每每只重视产出。他们也在很努力地做项目，但是每一个项目所利用的方法，还是沿用自己先前一向的思路。终极，不仅项目做得一样平常，还会抱怨自己得不到任何发展。
这便是P/PC不平衡的表示，如果能在做项目的过程中，通过学习总结持续提升自己的技能能力和软本色，并将其运用于项目履行交付中，相信一定会取得双赢的结果。
“P/PC平衡”原则还适用于很多其他的领域，例如：团队、家庭等，我本人也非常推崇这一原则。希望大家也能将其作为自身的一项基本原则，努力探求到产出与产能的平衡点。
原则九：长于提问
“长于提问”，首先要勤于提问。求知欲源于好奇心，是人类的一种本能。在事情中要养成勤于提问的好习气，不懂就问，不要由于自己一时
在设计评审、代码评审这类表示集体聪慧的活动中，碰着有问题的地方一定要提出来。我常常看到，很多同学评审全程一声不响，这便是摧残浪费蹂躏大家的韶光。设计评审的目的，是让大家针对方案提出改进见地并达成同等，如果全程“打酱油”，那就失落去了评审的意义。我们鼓励大家多提问，把自己内心的迷惑表达出来，然后通过互换的办法得到答案。
“长于提问”，还要懂得如何提问。为什么同样是参加设计评审，有的同学就能提出很好的问题，而有的同学却提不出任何问题？
除了知识储备、专业技能、履历等方面的差异外，还有一点很主要：这便是批驳性思维。
批驳性思维主见通过批驳性思考达到理性思维，即对事物实质的认知和节制。关于如何进行批驳性思维，大家可以参考一些经典的图书如《批驳性思维》、《学会提问》等。在事情中面临一项决策时，会有各种各样的见地摆在你面前，以是我们必须要学会利用批驳性思维来进行剖析，每个人的论据是否可靠，论证是否合理，是否有隐含的态度。
同样，在阅读一篇技能博客的时候，也要利用批驳性的思维，多问几个为什么，作者得出的结论是否合理？论据是否充分？
只有这样，才能不断地获取真正的知识。
原则十：空杯心态
“满招损，谦受益”，“空杯心态”是末了一项原则，我以为这也是一个人能够持续发展的条件。做技能的人，骨子里常日有股傲气，并且会随着资历、成绩的提升而不断增加。初入职场的小白，可能会非常谦逊，但是事情几年之后，专业技能逐步提升，可能还取得了一些小造诣，人就会越来越自傲。
这时候，如果不能始终保持“空杯心态”，这种自傲就会逐步演化为自满。自满的人，每每表现为事情中把别人的建议当成是批评，不接管任何反对见地，学习上也缺少求知的动力，总是拿自己的长处去跟别人的短处做比较。实在每个人多少都会有一些自满，恐怖的是不知道乃至不愿承认自满。
保持“空杯心态”这一原则哀求我们时候进行自我检视与反省。在事情中，多去跟不同级别的同学聊一聊，或者做一个360度评估，这有助于我们更加客不雅观地评价自己。在横向比拟中，多向那些精良的同学看齐，学习他人的优点。
很多同学在设计评审或者代码Review过程中，针对别人提出的问题与建议，每每都采取一种对立的态度。缺点地认为别人是在挑刺，是在针对自己。
诚然，在某些方面，我们可能确实比其他人想得深入，但是这不代表在所有方面都能考虑全面。对付别人的建议，建议利用“长于提问”原则里提到的批驳性思维仔细剖析一下，客气肠吸取那些好的建议。
事情学习就像“练级打怪”，技能储备的越多，就越随意马虎走到末了。保持空杯心态，可以让我们创造很多以前把稳不到的新能力，我们要做的便是努力学习它，将它们转化为自己能力库的一部分。
总结
以上，是我总结的事情与学习的十条基本原则。个中有的侧重于个人干工作的方法，如“Owner意识”、“韶光不雅观念”、“以终为始”、”闭环思维”；有的侧重于团队事情标准规范，如“保持敬畏”、“事不过二”、“设计优先”；有的侧重于团队或个人效能提升，如“P/PC平衡”、“长于提问”、“空杯心态”。
这些原则是我多年在事情与学习中，不断总结得来的履历。希望在大家面临选择时，这些原则能够起到一定的帮助和辅导浸染。
以原则为中央地事情与生活，让自己与团队变得更加强大。
作者：云鹏，2014年加入美团，先后参与了美团酒店供应链体系、分布式调度系统的培植，现在卖力美团旅行客户关系管理系统、根本信息做事的培植事情。