寫檔案也是技術活
01:實踐
對於多數開發同學來說,很多時候即討厭沒有研發檔案,但是自己又不願意常寫檔案,痛且倔強著;
程式設計師該不該寫檔案,與爭論哪種程式語言最好一樣,想撕的嘴不留情,該寫的筆不停耕;
當自我的意識上去糾結一件事情要不要去做的時候,不妨停下來看一看,大的職場環境是如何選擇的,糾結自然就沒必要了;
對於寫檔案這件事情,並不需要去思考能帶來哪些好處或者會佔用多少時間,用心去寫自然明白當中利弊;
最近兩年聽到不少搬磚的朋友說,公司已經把檔案管理提升到資產層面,在重大版本推進過程中,預留檔案輸出的時間,這可不是一般的大聰明;
從工作的這幾年實踐經驗來看,寫檔案原則上本著複雜的事項細寫,簡單的事項簡寫或者不寫,卷可以但又不閒的慌;
02:目錄
網際網路的產品,多少存在一定的虛擬屬性,很多事情和想法也都具有明顯的抽象感,如果缺乏檔案的結構化描述,時間拉扯下很容易煙消雲散;
這裡羅列一份在研發管理和職場中,或多或少都會接觸到的檔案內容,雖然結構複雜,但隨著時間的沉澱,其帶來的價值遠大於維護成本;
工作中涉及到的檔案種類比較繁多,但就管理和沉澱的動作來說屬於那種重要但不緊急的事情,這樣說並不是指研發流程中動作的時序可以混亂;
順著工作流程把該輸出的檔案做好,是比較正常的節奏,在特殊情況下也可以先解決事情,再後補檔案;
從開發的角度來說,如果是常規狀態下的版本推進,那麼在版本結束時各種相關檔案就可以上傳指定目錄了;
但是工作中不乏很多生產環境突發的棘手狀況,此時團隊自然優先解決,如果問題影響過大,在事後必然還要輸出總結檔案,即是經驗更是教訓;
03:模板
如果是個人的檔案,簡明扼要即可;但是工作檔案需要有規範和風格上的約束,通常情況下基於統一的模板庫即可;
在研發流程中,通常會圍繞專案的進度管理檔案,在該檔案中會統籌流程中的核心內容,涉及各個階段的進度維護;
基於專案進度管理的檔案模板,在流程推進的過程中,不斷補齊相關的核心內容,清晰準確的記錄版本進度;
採用特定的模板寫工作檔案,本身就會起到規範的效果,在部門的日常管理中,需要階段性的沉澱和維護各類檔案的模板結構,而模板的內容可以根據具體需求來定,在使用的過程中也需要時常優化;
如果檔案模板足夠豐富,在一定程度上可以解決不想寫檔案的問題,在寫檔案這件事上之所以會勸退很多人,很大原因是缺少可用的檔案模板;
當模板庫中存在:專案進度、研發設計、測試用例、階段總結、階段規劃等各種樣例時,下載之後直接使用,編寫核心內容即可,這樣排斥寫檔案的情緒自然減少;
04:內容
檔案的內容是價值所在,對於團隊的共同作業來說內容簡明扼要即可,讓閱讀檔案的人可以快速準確的理解事情的資訊;
通常需要輸出檔案的事項都比較複雜,所以在內容上需要適當的排版,複雜的邏輯儘量使用圖解來描述,這樣內容條理和思路都會很清晰;
對於其他細節方面的把控,比如段落縮排、專業名詞、空格等,通常本著:對內的檔案儘量做好,對外的檔案必須做好的原則;
檔案內容是思考邏輯的呈現,在編寫過程中也容易發現邏輯上的問題,再通過評審討論和完善內容,這樣事情圍繞檔案在後續的過程中不會過度偏離主線;
對於開發這個角色來說,寫檔案是避不開的事,在一個專案上待的時間久了,再看初期的程式碼,都覺得不是自己寫的,更別說是複雜的業務邏輯了;
在研發檔案中,最常用的圖解就是邏輯時序,再適當的豐富相關的內容,在一份圖中可以包括流程、邏輯、互動、資料管理等各個核心節點;
開發的設計檔案基本是幾張圖就可以描述清楚的,通常涉及:業務流程圖,邏輯時序圖,資料結構圖;
當複雜的業務呈現在檔案和設計圖上時,其實就是給事情預設好了航線,當然有時候中途被迫返航或變道也不少見;
05:工具
工欲善其事,必先利其器,想快速做好一份檔案,必須得有趁手好用的工具才行,在多年寫檔案的經驗中,以下工具多少都試用過;
圖中標紅的工具,是個人在實踐中覺得不錯的工具,當下使用最多的是DrawIO和語雀檔案,在免費的邊界內足夠日常使用;
由於工作中需要對接的事項比較多,很難統一共同作業的各方使用的檔案工具,自然接觸到的工具型別就很複雜,對於團隊內部來說,通常使用辦公軟體整合的工具,以便於統一管理;
寫檔案的習慣已經持續了很多年,工具的變遷也經歷了三次,從辦公檔案遷向Markdown,從線下遷移到線上,更換過一次檔案工具;
時間在變,檔案類產品也在不斷的更新換代,如何尋找自己順手的工具,本著一個基本的原則:免費的範疇內,支援線上管理,功能適當豐富即可;
最後分享一條寫檔案的理由:因為工作多而複雜,所以要寫到檔案中,這樣便能安心的忘了它。
END