記一筆流水賬
今天我打算記一筆流水賬，主要記錄我的一天中干的事情，並思考效率低下的原因，同時分析一些可用的解決方案。
清早·開始做計划
早上六點四十，被夢想喚醒，然后看一會書，吃早餐，送娃上學。
九點來到公司，開始一天的工作。在工作開始之前，我會花五分鍾先做一個當天的計划，大概是這樣的。
（講道理應該有每日站會，事實上我是xx項目的負責人，但是。。我把站會給省了，把站會取消對項目的危害非常大。后期再討論）- 對xx項目的周計划進行跟進和修訂。
- 檢查昨天完成的功能，並記錄和指派bug。
- 整理文檔，對昨天完成新功能的特性進行說明。
- 解決屬於自己名下的bug。
- 開始兩個下一階段需要交付的新功能，比較簡單的業務接口，代碼行預計不超過80行。
這些任務中，除了第五項和第六項相對來說可能會耗時比較長外，其他每個單項任務基本上可以在25分鍾內完成，而且也確實是按任務優先級和重要性順序來安排的，看起來還挺合理的，總體上屬於在8小時內可以完成的工作量，而且其實或許還略微有點不飽和。。。
執行任務（下面是流水賬，可以略過）
於是我喝了一口水，開始完成第一項任務：對xxx項目的周計划進行跟進和修訂。
（如果是周一，以前我還會根據上周完成情況對月計划和總體計划進行適度的總結，但是。。自從來到互聯網公司后，我把這個好習慣也丟掉了，好吧，是因為假裝要敏捷要擁抱變化，所以把總體計划和月計划省掉了）。
但是，當我開始處理這項事務時，計划外的第一件事情發生了。在測試環境下，客戶端反映某接口出現了不該出現的問題，於是我被迫打斷這項任務，花了一分鍾時間，跟他對接口問題進行了檢查，發現是對方參數傳錯了。
嗯。問題解決。繼續開始剛剛的任務。
到哪里了？哦。。還在做計划，接着我迅速調整狀態，花了幾分鍾就把任務完成了。
然后開始第二項任務。
這時，剛剛客戶端又找我了，他說接口還是有問題。
我以為又只要花一分鍾，事實上這次我花了30分鍾，因為確實是原來的代碼邏輯中存在缺陷，需要進行代碼修改、然后發布、再測試代碼。
確認這個問題已經得到解決后，還是處理之前擱置的任務。花了20分鍾處理任務3。
開始處理任務4，這項任務也相對來說比較簡單，所以不到五分鍾解決了。
開始處理任務5。。。在我名下共有20個bug。。。以每個bug5分鍾來衡量，我大概需要花100分鍾才能解決。但是當我開始解決第一個bug時。
又有其他人開始找我了，運營開始找我，說xxx場景下似乎出現了xxx邏輯不對。
線上問題必須優先解決，趕緊的，仔細思考問題發生的條件、對鏈路服務進行跟蹤和分析、查看半年前編寫的代碼邏輯，最終花了15分鍾分析出問題，並花了10分鍾將問題妥善解決。
繼續開始修復bug。在bug修復的過程中，發現是產品邏輯存在缺陷，於是跟產品對任務進行進一步明確、梳理業務、設計更加具體細化的流程。花了1小時。
到中午12點，我上午共完成任務3項，修復了一個bug。
下午不屬於問題的高峰期，但是又發現了產品邏輯之外的一些其他問題，最終解決了15個bug。
積壓了5個bug，留到晚上來解決吧。
當夜幕降臨，我需要花2個小時來解決我剩余的bug和2個未完成的新功能開發任務。
事實上等到晚上八點半時，我完成了剩余bug，新功能完成了一個，但此時效率已經差的不行了，沒辦法，硬着頭皮也得完成今天的任務。
（會不會欠下新債，顯然毋庸置疑）
晚上9點，所有任務已基本上圓滿完成。
總結完成情況
總結今天完成的任務，共完成任務五項，其中修復bug20個，寫了60行新代碼，共耗時10小時。
顯然我的工作效率是很差的，尤其是晚上效率更差，我最佩服那些自稱晚上效率很高的人，尤其還有一些人特別喜歡深夜擼碼，倒上一杯小酒，借着凌晨的寂靜，寫着愛寫的代碼，他們很厲害，因為他們很會自欺欺人。
來統計當天完成工作的工時占比：
| 工作內容 |
時間（分鍾） |
| 梳理日計划 |
5 |
| 修訂周計划 |
10 |
| 接口聯調 |
31 |
| 運營對接 |
25 |
| 修復20個bug |
250 |
| 編寫新功能 |
120 |
| 日常項目溝通 |
120 |
| 其他 |
40 |
| 總計 |
601 |
問題分析
以上流水賬實際上是我們這樣一家普通互聯網公司的日常，當然，對我個人而言，實際上投入到運營對接中的時間相對來說是不算多的，我了解我們公司有的開發者每天需要花至少3小時與運營人員進行問題的對接，這顯然會直接影響了開發者的工作效率。
（我相信一流互聯網公司一定不是這樣的）
從上圖可以看出我們的日常工作安排存在以下問題：
- 修復bug這種還技術債的任務，耗時接近47%，占了將近一半的時間。嗯，能力確實不行，能不能采取措施讓債不欠這么多，這是人才三角（專業技能、行業知識、軟實力）需要達到的目標。我曾經打算在功能開發中引入TDD來減少返工率，但是最終決定還是先擱置這個想法。
- 我司項目管理的形式是虛擬團隊，產品經理和測試工程師主要在深圳，而研發團隊在長沙，因此，每天投入到團隊溝通中的時間占比達到20%。事實上虛擬團隊這種開發模式，作為目前比較新興的項目溝通形式，已經被互聯網公司廣泛采用。但是虛擬團隊成員間分處異地、無法面對面溝通，由於文化、工作節奏、技術等原因，容易造成比較大的溝通成本。可以采取以下措施進行優化：
- 1、打造高保真原型圖，進一步拆解任務目標，讓任務目標細分。
- 2、需求討論時間前置，需求的特點是漸進明細的，應盡量將對需求的溝通在研發階段開始前進行落實，減少對於研發階段過程中的額外時間浪費。
- 3、快速沖刺階段盡可能面對面溝通。
- 4、功能交付缺乏Desktop Check，意味着產品經理和測試工程師無法及時了解功能的實際開發情況，也意味着團隊間對於成果的交付進度、實現方式，本身是存在疑問的，這將提高溝通成本。
- 如果按每天工作十小時，為3小時為與運營溝通問題的解決來算，占比達30%。說明對於項目成果的交付上，依然存在不少可以優化和提升的空間。或許可以采取以下措施。
- FAQ文檔的進一步細化。
- 知識共享。
- 項目成果移交本身需要有更加規范化的管理措施。
結論
以上是一位CRUD互聯網996開發者的一天，看起來似乎過得很充實， 卻依然需要通過加班來完成當天的任務，而且甚至長期工作時間大於10個小時，與體力勞動者本身沒有太大區別。也許大家都差不多、總是像機器一樣活着，思考都成為一種負擔。總以為靠蠻力可以解決，實際上輸出的或許是一種無用的解決方案。這樣的付出，大概會覺得毫無價值。
然而我們必須停駐腳步，認真思考當下的價值，思考效率和意義的平衡，讓我們的生活更加有意義。
牢記准則：“做正確的事，正確的做事”。
