写在前面
之前有位老板和我说过，大家智商是正态分布曲线的，能力上都是大差不差，同时大家都在规范化的公司里面坐着规范化的事情，能力也都差不多，那么为什么有人做的好，为什么有的人更被老板认可呢？其实无外乎就是做事靠谱，人在职场身不由己，究竟哪些东西可以让我们做起事来靠谱呢？无外乎是一些心态吧。
本文结合美团Blog的一篇文章进行加工。
遵循这些原则让你和你的团队变得更强大。
Owner意识
两个层面：认真负责，积极主动。
认真负责是工作底线，对交付结果负责，细到每一个设计文档，每一行代码认真完成，对质量负责，如果文档混乱，代码难以维护，测试过程中一堆bug，不仅影响交付质量也让RD，QA，PM对你产生不信任感。大到对系统负责，系统架构演进，文档细节整理，日志完整，数据库扩容，缓存空间资源是否够用，作为系统Owner需要认真履行。
积极主动是在Owner之上的又一层次要求，每个人每天都会面对大量的事情，很多事情可能不在计划之内，这时需要一种主动精神，不能因为太忙没有时间去处理。积极主动的心态应该是遇到计划之外的事情仍然可以积极主动进行推进并解决问题。如果实在无法排开时间解决，可以将问题交付给能解决的同学。
积极主动可以体现在多个方面上，比如计划之外梳理系统性能瓶颈，发现接口性能问题，并推进解决。比如项目存在跨端情况是，可以积极主动承担跨端主R的角色，积极发现问题，暴露问题并推进解决问题，推动团队合作进度，保证项目推进。
当然这个是性格使然，有些人偏外向一些，有些人偏内向所以有的时候表现出来的就类似于积极一些或者主动一些，人需要慢慢长大的，可以强迫自己下，变得外向些。
时间观念
所有的RD，QA，PM本质上都是需要为项目的交付负责，所以按时交付项目是最基本的要求，对于项目关键节点需要有时间观念，防止项目delay，对交付结果负责。
试想一下如果同样工作量的项目，在你负责期间时常delay，老板会怎么想？可能会认为你在能力上存在问题。
为了按时保质保量完成项目交付，重要的是：做事有计划，工作分主次。
工作上需要有做事安排，比如RD在设计评审之后需要能够精确预估出开发时间，进行合理的安排开发，联调，测试时间节点。如果是项目负责人需要做多端协调，比如设计到FE，QA，PM甚至多端其他工种同学的配合。
所以为了保证复杂项目可落地可执行，需要事无巨细的对项目节点的每一项进行细化拆分。事实证明拆分粒度越细，计划执行也就越精准，实际开发时间和预期时间也就越接近。
很多dealy的项目主要的延期原因主要是一些关键节点上多方存在分歧，比如对于时间是上班时间还是下班时间提测可能存在理解上的二意性，或者在知识需求理解上存在不一致，一个复杂的项目再多的沟通和交流都是有必要的。
工作分主次，因为每天我们会面对各种计划之外的事情，所以区分事情的重要性和主次很有必要，根据“艾森豪威尔-四象限法则”，工作按照重要，紧急分成四个象限。
优先做重要且紧急的事情，重要不紧急的事情放缓，但需要持续跟进。紧急不重要但事情酌情委托其他人（合适的人）去做。不重要不紧急的事情可以考虑不做。
很多事情delay未能正常交付的原因也常因为项目负责人分不清事情的主次，造成工作拖后腿，实际工作中应该避免一些本末倒置的工作方式，区分干扰工作项，保证重要紧急事情可以按时交付。
以始为终
以始为终是《高效能人士的七个习惯》中的一个习惯，目的是：先清楚目标，然后努力实现。
RD很多时候只是埋头苦干，季度总结时列出很多项目，付出很多努力，但是取得了哪些收益，对业务进行了什么提升，却很难说清楚。
所以工作中应该遵循以始为终法则，很多人做需要不关心收益，上线之后也没有持续跟进效果。
比如我们进行一个接口的性能优化，但是优化之后具体的收益是什么呢？或者目的是什么呢？很多时候可以多问一下，我们的目标是什么，是为了节日大促进行优化？还是系统可能存在宕机风险，最终是需要根据问题设定目标，实现目标。
以始为终对于技术同学来说是我们技术提升的核心，很多人看文章收获很小往往没有带着目标去学习，在学习一门新知识之前，我们需要明确带着问题去学习，这样有了问题之后有了目标，再向这个目标持续前进，最后才可以持续进步。
闭环原则
有的时候不管是技术方案讨论，还是产品需要讨论，在需求评审，技术方案讨论过程中大家兴致勃勃热火朝天，但是最后很多问题并没有得到改进，造成这种原因主要是做事不闭环。
闭环的意思是，凡是有交代，件件有着落，事事有回音。也是做事被认为靠谱最重要的一个原则。
闭环强调的是即时反馈的闭环，老板将向上管理中很重要的一点也是闭环，主要是老板交给你一件事情，你需要主动的去将进度和风险告知老板，如果有需要可以带着解决方案，如果需要老板资源配合，可以和老板申请，而不要让老板主动每次的去问你进度，这样老板可能感觉你做事情不太靠谱。
其实形成闭环主要是做事习惯的养成，这个很好培养，比如在多方合作会议上，就沟通讨论内容在各方达成一致后将会议记录周知到大家，同时在群里跟踪会议记录内容的进度状态节点，如果在执行过程中存在问题，需要进一步跟踪并解决问题，比如是否存在需求理解不一致情况，是否由于不同PM对于系统理解程度不同造成需求点遗漏？需要多方多次明确事项，并对事项进展进行check。
整个过程就是：沟通要求有结论，通知需要有反馈，todo需要做验收。一定要养成这种做事习惯。
有的时候老板因为不会深入到具体项目的细节当中，很多事情他并没有你熟悉，他不熟悉项目细节就倾向于对于项目进度有风险意识，如果你不主动汇报项目进度及细节他心里会更没底。
这也属于信息不对称的一种情况，所以及时汇报，哪怕简短的一句话，他会更有信息也形成了闭环，有助于事情的推进。
保持敬畏
敬畏之心主要可以帮助我们少犯错误，特别是高流量系统，一不小心的一个bug可能就会影响众多的人，很大的单量，做事有敬畏之心，多check可以防止case的发生，多走一个流程也多在一个角度覆盖下功能点是否有风险。
保持敬畏可以通过建立规范和SOP开始，比如代码规范，文档规范，设计规范，合作规范，上线流程，高峰期做事更加小心等。
制度和规范在一定程度上可以制约人性中的侥幸心理，如果约定了规范一定要严格执行，如果因为没有按照规范执行而造成的case直接打C。
进入新团队先忘掉之前的习惯（以后慢慢在捡起来也可以），尽快熟悉团队的做事规范，让自己节奏和团队保持一致。这样可以减少沟通成本。
当然保持敬畏不代表是因循守旧，需要在充分了解和熟悉流程规范之后，建立一套适合新团队的标准和流程，就形式上存在的问题进行讨论。
事不过二
错误的事情不要犯第二次，如果是因为流程造成的问题，要及时通过复盘进行流程上的优化，如果是方案上的问题，及时就系统技术方案进行梳理，防止同样的事情再次发生，同时进行问题整理，防止团队其他小伙伴出现类似问题，不管是code review机制还是测试流程需要进行核心功能点覆盖。
简明原则
不管是PM的需求文档，还是RD的设计方案，在或者的QA的冒烟用例，如果过分复杂会让合作方一头雾水，也就难以执行，我们需要遵循简明原则，只有简单了大家才会喜欢，也更容易执行和落地，最后也就更能取得好的效果。
一个过分复杂和庞杂的文案摆在面前，很容易引起需求的二意性，最后造成南辕北辙得不偿失。
文档需要尽量合理，流程轻视，抽象简化，案例先行，讲清依赖，落地清晰，落地可行。
产出和产能平衡
系统通过不断叠加新功能而进行产出，系统的产能代表了系统架构的可扩展性和稳定性。为了达到产出产能平衡需要在业务需求迭代过程中，持续对技术进行优化，如果一味的堆积业务需求，经过一定时间系统可能变得糟烂不堪，难以维护，最终也就影响了系统稳定性，造成产出低效了。
善于提问
不管工作过程中也好，还是需求对接过程中也好，多提问也总是有好处的，首先可以表面一种积极而非懒惰的思想。同时很多事情经过提问可以在侧面强化一个需求的稳定性，和容错性。
评审的意义在于审视，如果得不到多角度的讨论，评审也就失去了意义。所以需要鼓励大家讨论，勇敢的将质疑表达出来。
提出好问题和知识储备，专业技能，经验背景，业务理解是分不开的，多积累就有多角度的批判性。
空杯心态
一个人可以长期成长在于空杯心态，过度自信的人往往会把工作中的建议当作批评，不接受反对意见，学习上就缺乏动力。
空杯心态要求我们进行自我检讨和反省，需要借助其他人眼光进行360度全方位客观评价，学习他人优点，积极吸取他人建议，并就一些问题敢于讨论。
空杯心态有助于我们提升新技能，并将其转换为我们能力库的一部分。
