程序員如何變得靠譜

寫在前面

以前有位老闆和我說過，你們智商是正態分佈曲線的，能力上都是大差不差，同時你們都在規範化的公司裏面坐着規範化的事情，能力也都差很少，那麼爲何有人作的好，爲何有的人更被老闆承認呢？其實無外乎就是作事靠譜，人在職場身不禁己，究竟哪些東西可讓咱們作起事來靠譜呢？無外乎是一些心態吧。

本文結合美團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度全方位客觀評價，學習他人優勢，積極吸收他人建議，並就一些問題勇於討論。

空杯心態有助於咱們提高新技能，並將其轉換爲咱們能力庫的一部分。