今天我打算記一筆流水賬，主要記錄我的一天中乾的事情，並思考效率低下的原因，同時分析一些可用的解決方案。

早上六點四十，被夢想喚醒，然後看一會書，吃早餐，送娃上學。

九點來到公司，開始一天的工作。在工作開始之前，我會花五分鐘先做一個當天的計劃，大概是這樣的。

1. （講道理應該有每日站會，事實上我是xx專案的負責人，但是。。我把站會給省了，把站會取消對專案的危害非常大。後期再討論）
2. 對xx專案的周計劃進行跟進和修訂。
3. 檢查昨天完成的功能，並記錄和指派bug。
4. 整理文件，對昨天完成新功能的特性進行說明。
5. 解決屬於自己名下的bug。
6. 開始兩個下一階段需要交付的新功能，比較簡單的業務介面，程式碼行預計不超過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小時。

顯然我的工作效率是很差的，尤其是晚上效率更差，我最佩服那些自稱晚上效率很高的人，尤其還有一些人特別喜歡深夜擼碼，倒上一杯小酒，藉著凌晨的寂靜，寫著愛寫的程式碼，他們很厲害，因為他們很會自欺欺人。

來統計當天完成工作的工時佔比：

以上流水賬實際上是我們這樣一家普通網際網路公司的日常，當然，對我個人而言，實際上投入到運營對接中的時間相對來說是不算多的，我瞭解我們公司有的開發者每天需要花至少3小時與運營人員進行問題的對接，這顯然會直接影響了開發者的工作效率。

（我相信一流網際網路公司一定不是這樣的）

從上圖可以看出我們的日常工作安排存在以下問題：

• 修復bug這種還技術債的任務，耗時接近47%，佔了將近一半的時間。嗯，能力確實不行，能不能採取措施讓債不欠這麼多，這是人才三角（專業技能、行業知識、軟實力）需要達到的目標。我曾經打算在功能開發中引入TDD來減少返工率，但是最終決定還是先擱置這個想法。
• 我司專案管理的形式是虛擬團隊，產品經理和測試工程師主要在深圳，而研發團隊在長沙，因此，每天投入到團隊溝通中的時間佔比達到20%。事實上虛擬團隊這種開發模式，作為目前比較新興的專案溝通形式，已經被網際網路公司廣泛採用。但是虛擬團隊成員間分處異地、無法面對面溝通，由於文化、工作節奏、技術等原因，容易造成比較大的溝通成本。可以採取以下措施進行優化：
• 1、打造高保真原型圖，進一步拆解任務目標，讓任務目標細分。
• 2、需求討論時間前置，需求的特點是漸進明細的，應儘量將對需求的溝通在研發階段開始前進行落實，減少對於研發階段過程中的額外時間浪費。
• 3、快速衝刺階段儘可能面對面溝通。
• 4、功能交付缺乏Desktop Check，意味著產品經理和測試工程師無法及時瞭解功能的實際開發情況，也意味著團隊間對於成果的交付進度、實現方式，本身是存在疑問的，這將提高溝通成本。
• 如果按每天工作十小時，為3小時為與運營溝通問題的解決來算，佔比達30%。說明對於專案成果的交付上，依然存在不少可以優化和提升的空間。或許可以採取以下措施。
• FAQ文件的進一步細化。
• 知識共享。
• 專案成果移交本身需要有更加規範化的管理措施。

以上是一位CRUD網際網路996開發者的一天，看起來似乎過得很充實， 卻依然需要通過加班來完成當天的任務，而且甚至長期工作時間大於10個小時，與體力勞動者本身沒有太大區別。也許大家都差不多、總是像機器一樣活著，思考都成為一種負擔。總以為靠蠻力可以解決，實際上輸出的或許是一種無用的解決方案。這樣的付出，大概會覺得毫無價值。

然而我們必須停駐腳步，認真思考當下的價值，思考效率和意義的平衡，讓我們的生活更加有意義。

牢記準則：“做正確的事，正確的做事”。<