每天CRUD，程序員如何才能提高？
最近跟一個阿里的朋友聊到關于程序員如何把事情做得更好，他提到了很多在阿里的感受，讓我受益匪淺。
所謂“如何把事情做得更好”，就是跳出寫代碼這件事，如何把我們的工作做好，獲得更多的個人成長，獲得更好的績效考核結果，并能在其他人中脫穎而出。
思維碰撞下，得到了很多有效的信息，總結為三個方面的“管理”能力：
目標管理
過程管理
向上管理
希望每個人看完都能有所啟發(fā)。
1.目標管理
所謂目標管理，分為兩個階段：
- 提出目標
- 管理目標
提出目標
目標管理的前提，是必須先能夠提出一個足夠有價值的目標，然后再進行達成。
如果目標本身是沒有價值，或者說價值很小的，那即使你花費了很大力氣去做，然后達成了，也沒有什么意義。跟莫斯科一樣，程序員也是不相信眼淚的?？鄤谠俣啵脖炔簧瞎?。
那如何能提出一個足夠有價值的目標呢?
①來源于自上而下的任務拆解
經(jīng)?？吹接腥嗽诟鞣N社區(qū)吐槽華為的“拉通對齊”。但實際上，拋開某些管理者具體執(zhí)行層面的問題，“拉通對齊”本身是非常有價值的。
公司的管理者在更高的位置，利用更多的信息進行決策，然后獲得明年公司的發(fā)展目標和方向。
然后就是將目標拆解到各個部門，各個部門需要相互合作達成目標。作為個人，也會承接到部門內(nèi)的子任務，這個時候，可以提出自己的一些想法進行討論，在充分溝通的基礎上，應該達成一致，然后堅決執(zhí)行。
那么這時候你的目標，就是跟部門目標是一致的，跟公司的大目標也是一致的。
如果你能很好地達成目標，或者說超出預期，那么你對部門和公司的價值就是越大的。
②來源于自下而上的問題發(fā)現(xiàn)與解決
經(jīng)?？梢钥吹礁鞣N社區(qū)有人提問，每天 CRUD 怎么才能提高?其實這個問題的一個解決思路是，在工作中發(fā)現(xiàn)問題，并給出解決方案。
我舉一個我們公司的真實案例：一個后端開發(fā)同學，發(fā)現(xiàn)自己組內(nèi)的業(yè)務需求經(jīng)常會有很多離線任務要做。
有的人直接使用 Spring 的 Async 注解，有的人自己新建申請一個線程池塞任務，有的人利用 Redis 的 blpull/blpush 來做隊列來進行生產(chǎn)消費。
沒有統(tǒng)一的方案，有很多重復勞動，而且容易因為種種原因造成故障(比如沒有資源隔離)。
因此，他提出了一個目標，做一個分布式的統(tǒng)一任務調度框架，解決組內(nèi)的這些問題。
目標達成后，還在全公司進行了推廣。后面的結果大家應該能猜到了，升職加薪走上人生巔峰。
有人說，你這個肯定是小廠啊，大廠各種工具都很成熟了，沒啥要做的。
這話說對了一半，大廠的成熟工具和框架確實很多，但也是其他人發(fā)現(xiàn)并且實現(xiàn)的，而且我相信沒有任何一個公司或者部門，在任何事情上都已經(jīng)做到完美，總會存在問題和不足的地方等待解決的。
管理目標
已經(jīng)有了一個很有價值的目標了，我們該怎么達成呢?這時候，我們就需要對目標進行管理。
我個人認為最好的方式是“倒排時間”的 milestone(里程碑)模式。根據(jù)目標 deadline 來往前倒排時間，拆分不同階段的里程碑節(jié)點，然后按期檢查當前進度，最終達成目標。
其實也不是什么新鮮玩意，很多公司都有在做，但是落實到具體部門、小組、個人上，就不太一樣了。
尤其我想說的是個人和小組上。在我擔任敏捷小組的 SM(scrum master)期間，發(fā)現(xiàn)很多同學對于這種方式的計劃能力都有所欠缺。
主要有兩個方面的問題：
①估時問題
如果今天只是一個寫 SQL 的任務，很多同學能準確的估計大概要花費幾分鐘。
但是如果是一個半年或一兩個月的項目，讓你以月或周的粒度進行拆分，很多同學就比較難把握了。
這個其實不是什么大問題，主要是經(jīng)驗不足，無法深刻了解到項目中的模塊拆解粒度與技術難度。
那怎么做呢?有三個建議：
- 如果沒有把握，那就對里程碑做更細粒度的任務拆分。
- 預留 Buffer，給自己有轉身的余地，能夠面對突發(fā)情況。
- 可以請組里更有經(jīng)驗的同事或者 TL 進行 Review。
②進度意識
有了明確的里程碑和時間后，我們還需要在執(zhí)行過程去及時檢查進度。比如以周、月為單位，來檢查自己或者跟進合作者的完成進度。
如果發(fā)現(xiàn)有延期風險，那么就需要提前進行風險暴露，想辦法解決問題，加快進度。
正如上文提到的，如果估時有一定 Buffer，那么更加容易轉身，否則，只能通過加班來達成目標了。
以前在做業(yè)務開發(fā)的時候，產(chǎn)品、前端、后端、測試等角色關聯(lián)非常密切，因此在敏捷開發(fā)過程中，會需要通過每天的站會來溝通進度，及時暴露風險。
現(xiàn)在在做基礎架構相關的工作時候，可能項目的周期會更長，比業(yè)務開發(fā)的敏捷迭代周期要長很多，因此，往往會通過周為單位的進度分享。
只有按時完成每個里程碑節(jié)點，我們才有信心按期完成整個目標的交付。
具體的實施，每個公司可能都有自己的目標管理系統(tǒng)，我這里做個簡單的表格，更直觀地反應如何對目標、里程碑進行管理。
2.過程管理
如果說目標管理是我們完成任務的基本要求的話，過程管理可能是我們獲得“超出預期”評價的重要部分。
我覺得最好的方式是，在任務 DOD(Definition of Done)的基礎上，你有自己獨有的一套“過程性 DOD”。
一般我們?nèi)蝿盏?DOD 是按照一定時間要求，完成什么功能，上線什么需求。有的可能會帶上一些性能指標，比如接口響應時間低于多少，線下故障數(shù)量低于多少等等。
那么如果只是完成了這些要求，那么今天你來做這個事情，和另一個人來做這個事情有什么區(qū)別呢?
甚至于如果某個項目，最終由于種種原因沒有上線，或者中途被終止了，那么是不是你所做的事情都白費了呢?所以，你必須有一套自己的“過程性 DOD”。
下面，我介紹一些我的經(jīng)驗和我見過的大佬們的經(jīng)驗，大家可以按需取用(業(yè)務開發(fā)和基礎架構開發(fā)還是有很大不同的，尤其在迭代壓力和做事方法上，所以不能一概而論)。
①完整的調研報告
任何一個任務，都有常規(guī)方案和優(yōu)質方案。就像我上面提到的那個分布式調度系統(tǒng)，普通同學可能就是按照自己的理解，搞個能用的方案就行了。
但是優(yōu)質的方案，肯定是跳出自己的眼界范圍，博采眾長的結果。因此，在確定技術方案前，最好能先去調研一下業(yè)界的主流方案，看看別人是不是已經(jīng)有了比較好的解決方案了。
然后把你的調研結果形成文檔，這樣不僅能增長你的技術視野，還能體現(xiàn)你的良好技術思考力，這是非常重要的過程性內(nèi)容。
②完整的技術設計文檔
在確認了技術方案后，一般需要做一個比較詳細的技術設計方案。面向數(shù)據(jù)庫編程?面向 SQL 編程?面向對象編程?面向領域編程?這些都是需要在技術方案設計的時候仔細思考的。
一個好的技術方案，能鍛煉你的技術思考力，能指導你后期快速、高質量地進行開發(fā)，也能在你以后進行維護的時候，告訴你當時為啥這么想。
通過不斷地技術設計、開發(fā)、反思，才能學以致用，快速提高技術水平。
③問題積累與解決方案
問題一般有兩種：
一種技術問題：包括開發(fā)過程中遇到的問題、線上故障解決等，你在解決這些問題后，將排查過程與解決方案進行記錄，形成 BP(Best Practice，最佳實踐)文檔。
然后可以跟其他同學進行分享和推廣。這樣你不僅能沉淀自己的經(jīng)驗，還能慢慢形成一定的技術影響力。
另一種是業(yè)務問題：在做基礎架構的同學，往往會覺得自己陷入運維、客服的怪圈。
一種好的解決方案，是將日常繁瑣的運維和客服問題進行積累記錄，然后努力通過技術手段去提高效率自動解決類似問題。
舉一個例子：過去我們公司的數(shù)據(jù)庫升配都是人肉進行的，業(yè)務方提出工單申請，然后審批，然后去找 DBA 進行溝通，確認升級時間。
然后到時間后，大家需要再次溝通確認業(yè)務是否處于流量低峰，是否可以開始升級。然后升級完成后要進行檢查，溝通確認已經(jīng)完成。
后來，有人提出了自動化解決的方案，通過打通工單系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)、內(nèi)部通知系統(tǒng)，將整個流程自動化，提效幾十倍。
④方法論產(chǎn)出
一次項目上線后，對很多人意味著結束，但對很多人來說，只是階段性勝利，更重要的是方案論的產(chǎn)出與推廣。
如果一次資源的投入和探索只能產(chǎn)出一次結果，那性價比是不高的，但是，如果有完整的可復制的方法論產(chǎn)出，那么這一次投入和探索的過程可以給未來的無數(shù)次探索提供指導建議，甚至于能夠快速復制，那就是極高的投入產(chǎn)出比。
對有些更優(yōu)秀的人來說，可能產(chǎn)出方法論之后，還能從中找出共性和特性，沉淀為平臺化的產(chǎn)品，那就是更加的 niubility 了。
舉一個例子：之前公司做個一個分庫分表的項目，項目上線后，項目成員寫了完整的方法論指導，在公司進行推廣分享。
還將項目過程中使用的數(shù)據(jù)校驗工具，平臺化為技術產(chǎn)品，方便其他業(yè)務線能夠快速使用類似的功能。這種就是非常好的范例。
方法論的產(chǎn)出，無論對于公司還是對于個人成長，都是絕佳的方式。
過程管理的產(chǎn)物，能很好地體現(xiàn)在結果上。同樣一年完成了幾十個需求，年底 Review 的時候，你只完成了需求，而別人沉淀了幾十篇設計文檔、最佳實踐、方法論，并建立了一定的技術影響力，你可能就是 B，別人就是 A，這樣的差距就是由于過程管理造成的。
而且更重要的是能沉淀你自己的學習與思考，這是個人成長非常重要的部分。即使最終由于各種各樣的原因，在結果導向上沒有一個好的成績，這些過程管理的結果都是你最重要的財富。
一個五年程序員是擁有五年經(jīng)驗，還是一個經(jīng)驗用五年?過程管理往往能告訴你怎么做。
3.向上管理
這部分的內(nèi)容不多，但是可能比上面的所有內(nèi)容更加重要，也是大部分程序員容易缺失的思維方式。
所謂“向上管理”，不是說拍老板馬屁。而是一種有效溝通方式，一種科學的上下級合作方式。
有了良好的“目標管理”和“過程管理”后，有的人可能會陷入閉門造車的陷阱，按照計劃或迭代不斷埋頭做事，這是萬萬不可取的。
很多同學容易陷入一種誤區(qū)，我專心地完成手上的工作，就可以了。但其實這往往是最危險的。
因為即使你全部做完了，也可能只是達到要求，沒有任何亮點，甚至于由于外部的變化你沒有及時獲取，還做錯了方向。
我們還是需要及時主動跟老板溝通，溝通自己目前的進度、困難、計劃。讓老板能及時知道你現(xiàn)在的進展情況。
很多時候，當老板來找你的時候，往往不是什么好事。要么就是你做了什么錯事，要么就是他想知道你在做什么，做到什么程度了。無論哪種情況，都不好。
阿里的朋友跟我分享了一些比較好的形式：
- 定期整理任務進度，將任務進度、遇到的困難、解決方案等簡明扼要地整理出來，進行匯報。
- 找老板溝通技術規(guī)劃，然后一起討論哪些能做，哪些需要砍掉，然后把能做的東西一起安排一個計劃進行實現(xiàn)。
- 多多關注組內(nèi)同學、老板的周報，如果發(fā)現(xiàn)有什么困難，及時提出幫助，共同解決。
做事的方法真的很重要，尤其是我們程序員，可能過多地與代碼打交道，而容易缺乏技術外的非技術思維。
而好的非技術思維，能幫助我們更好地自我成長，更好地脫穎而出，與大家共勉。
作者：阿丸
編輯：陶家龍
出處：轉載自微信公眾號阿丸筆記(ID：aone_note)
