最近跟乙個阿里的朋友聊到關於程式設計師如何把事情做得更好，他提到了很多在阿里的感受，讓我受益匪淺。
所謂「如何把事情做得更好」，就是跳出寫**這件事，如何把我們的工作做好，獲得更多的個人成長，獲得更好的績效考核結果，並能在其他人中脫穎而出。
思維碰撞下，得到了很多有效的資訊，總結為三個方面的「管理」能力：
希望每個人看完都能有所啟發。
所謂目標管理，分為兩個階段：
提出目標
目標管理的前提，是必須先能夠提出乙個足夠有價值的目標，然後再進行達成。 如果目標本身是沒有價值，或者說價值很小的，那即使你花費了很大力氣去做，然後達成了，也沒有什麼意義。跟莫斯科一樣，程式設計師也是不相信眼淚的。苦勞再多，也比不上功勞。
那如何能提出乙個足夠有價值的目標呢？
①**於自上而下的任務拆解
經常看到有人在各種社群吐槽華為的「拉通對齊」。但實際上，拋開某些管理者具體執行層面的問題，「拉通對齊」本身是非常有價值的。公司的管理者在更高的位置，利用更多的資訊進行決策，然後獲得明年公司的發展目標和方向。然後就是將目標拆解到各個部門，各個部門需要相互合作達成目標。作為個人，也會承接到部門內的子任務，這個時候，可以提出自己的一些想法進行討論，在充分溝通的基礎上，應該達成一致，然後堅決執行。那麼這時候你的目標，就是跟部門目標是一致的，跟公司的大目標也是一致的。如果你能很好地達成目標，或者說超出預期，那麼你對部門和公司的價值就是越大的。
②**於自下而上的問題發現與解決
經常可以看到各種社群有人提問，每天 crud 怎麼才能提高？其實這個問題的乙個解決思路是，在工作中發現問題，並給出解決方案。
我舉乙個我們公司的真實案例：乙個後端開發同學，發現自己組內的業務需求經常會有很多離線任務要做。有的人直接使用 spring 的 async 註解，有的人自己新建申請乙個執行緒池塞任務，有的人利用 redis 的 blpull/blpush 來做佇列來進行生產消費。沒有統一的方案，有很多重複勞動，而且容易因為種種原因造成故障（比如沒有資源隔離）。
因此，他提出了乙個目標，做乙個分布式的統一任務排程框架，解決組內的這些問題。目標達成後，還在全公司進行了推廣。後面的結果大家應該能猜到了，公升職加薪走上人生巔峰。
有人說，你這個肯定是小廠啊，大廠各種工具都很成熟了，沒啥要做的。這話說對了一半，大廠的成熟工具和框架確實很多，但也是其他人發現並且實現的，而且我相信沒有任何乙個公司或者部門，在任何事情上都已經做到完美，總會存在問題和不足的地方等待解決的。
管理目標
已經有了乙個很有價值的目標了，我們該怎麼達成呢？這時候，我們就需要對目標進行管理。
我個人認為最好的方式是「倒排時間」的 milestone（里程碑）模式。根據目標 deadline 來往前倒排時間，拆分不同階段的里程碑節點，然後按期檢查當前進度，最終達成目標。
其實也不是什麼新鮮玩意，很多公司都有在做，但是落實到具體部門、小組、個人上，就不太一樣了。尤其我想說的是個人和小組上。在我擔任敏捷小組的 sm（scrum master）期間，發現很多同學對於這種方式的計畫能力都有所欠缺。主要有兩個方面的問題：
①估時問題
如果今天只是乙個寫 sql 的任務，很多同學能準確的估計大概要花費幾分鐘。但是如果是乙個半年或一兩個月的專案，讓你以月或周的粒度進行拆分，很多同學就比較難把握了。
這個其實不是什麼大問題，主要是經驗不足，無法深刻了解到專案中的模組拆解粒度與技術難度。那怎麼做呢？有三個建議：
②進度意識
有了明確的里程碑和時間後，我們還需要在執行過程去及時檢查進度。比如以周、月為單位，來檢查自己或者跟進合作者的完成進度。如果發現有延期風險，那麼就需要提前進行風險暴露，想辦法解決問題，加快進度。正如上文提到的，如果估時有一定 buffer，那麼更加容易轉身，否則，只能通過加班來達成目標了。
以前在做業務開發的時候，產品、前端、後端、測試等角色關聯非常密切，因此在敏捷開發過程中，會需要通過每天的站會來溝通進度，及時暴露風險。現在在做基礎架構相關的工作時候，可能專案的週期會更長，比業務開發的敏捷迭代週期要長很多，因此，往往會通過週為單位的進度分享。只有按時完成每個里程碑節點，我們才有信心按期完成整個目標的交付。 具體的實施，每個公司可能都有自己的目標管理系統，我這裡做個簡單的**，更直觀地反應如何對目標、里程碑進行管理。
如果說目標管理是我們完成任務的基本要求的話，過程管理可能是我們獲得「超出預期」評價的重要部分。
我覺得最好的方式是，在任務 dod（definition of done）的基礎上，你有自己獨有的一套「過程性 dod」。一般我們任務的 dod 是按照一定時間要求，完成什麼功能，上線什麼需求。有的可能會帶上一些效能指標，比如介面響應時間低於多少，線下故障數量低於多少等等。那麼如果只是完成了這些要求，那麼今天你來做這個事情，和另乙個人來做這個事情有什麼區別呢？甚至於如果某個專案，最終由於種種原因沒有上線，或者中途被終止了，那麼是不是你所做的事情都白費了呢？所以，你必須有一套自己的「過程性 dod」。
下面，我介紹一些我的經驗和我見過的大佬們的經驗，大家可以按需取用（業務開發和基礎架構開發還是有很大不同的，尤其在迭代壓力和做事方法上，所以不能一概而論）。
①完整的調研報告
任何乙個任務，都有常規方案和優質方案。就像我上面提到的那個分布式排程系統，普通同學可能就是按照自己的理解，搞個能用的方案就行了。但是優質的方案，肯定是跳出自己的眼界範圍，博採眾長的結果。因此，在確定技術方案前，最好能先去調研一下業界的主流方案，看看別人是不是已經有了比較好的解決方案了。然後把你的調研結果形成文件，這樣不僅能增長你的技術視野，還能體現你的良好技術思考力，這是非常重要的過程性內容。
②完整的技術設計文件
在確認了技術方案後，一般需要做乙個比較詳細的技術設計方案。面向資料庫程式設計？面向 sql 程式設計？物件導向程式設計？面向領域程式設計？這些都是需要在技術方案設計的時候仔細思考的。乙個好的技術方案，能鍛鍊你的技術思考力，能指導你後期快速、高質量地進行開發，也能在你以後進行維護的時候，告訴你當時為啥這麼想。通過不斷地技術設計、開發、反思，才能學以致用，快速提高技術水平。
③問題積累與解決方案
問題一般有兩種：
一種技術問題：包括開發過程中遇到的問題、線上故障解決等，你在解決這些問題後，將排查過程與解決方案進行記錄，形成 bp（best practice，最佳實踐）文件。然後可以跟其他同學進行分享和推廣。這樣你不僅能沉澱自己的經驗，還能慢慢形成一定的技術影響力。
另一種是業務問題：在做基礎架構的同學，往往會覺得自己陷入運維、客服的怪圈。一種好的解決方案，是將日常繁瑣的運維和客服問題進行積累記錄，然後努力通過技術手段去提高效率自動解決類似問題。舉乙個例子：過去我們公司的資料庫公升配都是人肉進行的，業務方提出工單申請，然後審批，然後去找 dba 進行溝通，確認公升級時間。然後到時間後，大家需要再次溝通確認業務是否處於流量低峰，是否可以開始公升級。然後公升級完成後要進行檢查，溝通確認已經完成。後來，有人提出了自動化解決的方案，通過打通工單系統、資料庫管理系統、內部通知系統，將整個流程自動化，提效幾十倍。
④方**產出
一次專案上線後，對很多人意味著結束，但對很多人來說，只是階段性勝利，更重要的是方案論的產出與推廣。如果一次資源的投入和探索只能產出一次結果，那價效比是不高的，但是，如果有完整的可複製的方**產出，那麼這一次投入和探索的過程可以給未來的無數次探索提供指導建議，甚至於能夠快速複製，那就是極高的投入產出比。對有些更優秀的人來說，可能產出方**之後，還能從中找出共性和特性，沉澱為平台化的產品，那就是更加的 niubility 了。
舉乙個例子：之前公司做個乙個分庫分表的專案，專案上線後，專案成員寫了完整的方**指導，在公司進行推廣分享。還將專案過程中使用的資料校驗工具，平台化為技術產品，方便其他業務線能夠快速使用類似的功能。這種就是非常好的範例。
方**的產出，無論對於公司還是對於個人成長，都是絕佳的方式。
過程管理的產物，能很好地體現在結果上。同樣一年完成了幾十個需求，年底 review 的時候，你只完成了需求，而別人沉澱了幾十篇設計文件、最佳實踐、方**，並建立了一定的技術影響力，你可能就是 b，別人就是 a，這樣的差距就是由於過程管理造成的。
而且更重要的是能沉澱你自己的學習與思考，這是個人成長非常重要的部分。即使最終由於各種各樣的原因，在結果導向上沒有乙個好的成績，這些過程管理的結果都是你最重要的財富。乙個五年程式設計師是擁有五年經驗，還是乙個經驗用五年？過程管理往往能告訴你怎麼做。
這部分的內容不多，但是可能比上面的所有內容更加重要，也是大部分程式設計師容易缺失的思維方式。
所謂「向上管理」，不是說拍老闆馬屁。而是一種有效溝通方式，一種科學的上下級合作方式。
有了良好的「目標管理」和「過程管理」後，有的人可能會陷入閉門造車的陷阱，按照計畫或迭代不斷埋頭做事，這是萬萬不可取的。
很多同學容易陷入一種誤區，我專心地完成手上的工作，就可以了。但其實這往往是最危險的。
因為即使你全部做完了，也可能只是達到要求，沒有任何亮點，甚至於由於外部的變化你沒有及時獲取，還做錯了方向。
我們還是需要及時主動跟老闆溝通，溝通自己目前的進度、困難、計畫。讓老闆能及時知道你現在的進展情況。
很多時候，當老闆來找你的時候，往往不是什麼好事。要麼就是你做了什麼錯事，要麼就是他想知道你在做什麼，做到什麼程度了。無論哪種情況，都不好。
程式設計師要知道的事情
程式設計師是乙個神奇的職業 我們工作的時候給公司帶來很高的利益，我們自己也要給自己產生價值。下面一些事情可以提高我們程式設計師，所以我們要認真的看一下。不喜勿噴 1.經常和優秀的人在一起共事 和一些老鳥在一起工作，對你有很大的提公升。比如我經常看老鳥們操作liunx系統，那命令敲的那就乙個快啊 很羨...
程式設計師每天要做的事情
1 程式設計師每天總結自己一天任務的完成情況 最好的方式是寫工作日誌，把自己今天完成了什麼事情，遇見了什麼問題都記錄下來，日後翻看好處多多。2 考慮自己明天應該做的主要工作 把明天要做的事情列出來，並按照優先順序排列，第二天應該把自己效率最高的時間分配給最重要的工作。3 考慮自己一天工作中失誤的地方...
程式設計師每天該做的事情！
前面講了一周該做的事情，那麼每天該做什麼呢？下面的內容，僅供參考！不重視細節，如何談得上成功！1 程式設計師每天總結自己一天任務的完成情況 最好的方式是寫工作日誌，把自己今天完成了什麼事情，遇見了什麼問題都記錄下來，日後翻看好處多多 2 考慮自己明天應該做的主要工作 把明天要做的事情列出來，並按照優...