在日常工作中，每週的工作都充實而有所沉澱嗎？是否覺得自己在假忙碌？如何有序推進工作進展，有序記錄自己的工作？本文作者結合自身實踐，講述了在方法論上對自己工作推進記錄的一張表，迭代了四個版本，希望對你的工作與成長能有所幫助。
我是技術出身，Java後端，不過從一接觸代碼我就熱衷於去創造一些自己不經意間想到的一些小工具或者小框架，希望做一個可以給同行使用或者有幫助的小產品，或許算不上產品，畢竟當時並不覺得產品能有技術好上多少。
不過現在回過頭來看，自己當初做的開源項目InChat，從0.1發佈，寫技術説明文檔，建立QQ羣，收集好友需求建議，再持續迭代下去，其實和做產品一樣，甚至當時的0.1也是基於MVP的概念，把最核心的工作優先實現並推出市場。
轉產品至今有一年了，這期間也慢慢讓我看到了自己作為產品的一些優缺點。
溝通、推進、開發協調等等，在自己轉產品後從零到壹孵化出一個To B的小產品，在這期間最讓我得心應手的就是執行性的工作與技術開發的推進，我擅長根據具體的反饋，參考競品設計適合的功能原型，對接技術團隊交流產品的業務邏輯等等，這讓我在每天的工作中都推進很充實。
但是在1.0給到用户後，我開始面臨產品迭代上的難題，用户需求與洞察力。
和大多數產品一樣，我的產品也是基於領導的想法與資源，才順利的落地了v1.0，不過後續的產品迭代演進，還是要基於市場、用户需求來確定。
這讓我有一段時間的工作過得很混亂，乃至無從下手。
不知道大家是否也會經歷這樣的階段，又是因什麼而處於這個階段。
在產品迭代的過程中，有段時間我多次進行競品分析，並將市面上的競品功能一一羅列，在下一版的迭代中也借鑑了部分競品的功能點，並自己進行了產品設計。
不過在進行產品演示的時候，卻換來了一系列的追問：“這樣的功能用户一定會用嗎？”、“產品目前定位是什麼？”、“你的商業模式與這些功能之間有關係嗎？”
你自己想的、或者照搬來的東西，不一定是這個產品所需要的。
大約是兩週的工作，我覺得好像一無所獲，甚至毫無推進，產品的迭代是為了更好的服務用户，讓用户購買這個產品，而產品的目標用户是什麼樣的需求，我並沒有系統的去調研，且產品的服務本身是否會因為區域、地域、人文等問題而存在一些特殊的無法複製的功能點呢？
我做的產品的醫療診後的隨訪產品，而正是因為如此，在此之後我開始有計劃的進行用户調研，比起外出，作為程序員我確實更喜歡一個人靜靜的坐在電腦前埋頭做自己的工作，慶幸的是，我對於交流溝通並不牴觸，如果附帶目的性，那麼我會更加聊得開。
我特意的到醫院進行用户調研，如下表，也是最近的一次調研反饋。
正如上面説到的，面對毫無進展的工作，且加上每週的工作總結，我突然發現自己不應該繼續工作下去，應該有序的記錄並推進自己的工作進展。
由此本文的核心重點“那張表”因此出現，總共用了4周左右，我迭代了大約4個版本，目前覺得較為完善且也適用於各種職業的人羣使用。
如下為0.1版本，當時想得很簡單，需要記錄我每週的工作推進情況，所以有點像甘特圖，每個工作都可能持續或者當天完成，這樣的表格剛好滿足我的需求。
在第二週的時候，我發現我還需要參加一些會議，同時在這周因為涉及產品的v1.1迭代開發，發現自己在溝通交流上耗費了很長的時間，且這些時間其實是沒必要的，同時關於產品相關的信息/問題，在日常溝通中要保持記錄。
因此，在0.2表上，我新增了會議還有當日的一些工作總結。
在下一週的工作中，我發現自己對於用户需求的調研不夠積極，甚至有些排斥，因此基於自己的職業性質，給自己新增了一行“用户調研”，用來提醒自己。
同一周，在自己重新閲讀自己本週工作的時候，發現自己的工作內容其實還可以再細分，讓領導可以明白本週的主要工作重點是哪幾個方面，然後根據他自己的想法有選擇的看就好，因此對自己的工作內容進行了整理分類。
如下就是最後的這張表了。
當然，不一定每天都有時間整理，具體時間還是要根據自身的工作量來定，而且不是每一天都有得反思，有時候一次討論對我來説説其實就是一種業務上的沉澱。
這張表，對我本人而言，從我開始設計並參照着記錄之後，我發現我每週的工作量增加了10%左右，通過對工作內容進度的把控，可以有秩序的安排一些小的工作進去，且自己的一些划水時間也自然的減少，自己對於未來一到兩天的工作內容有大致的規劃與把控，這也是我本次想要分享的。
順便給一張程序員可以參照的表，具體內容因人而異，核心是讓你有效的把控工作內容的進度，特別是多任務並行的情況下。
到點了，去加貓糧了。
作者：貓叔記，現架構設計（碼農）兼創業技術顧問，不羈平庸，熱愛開源，雜談程序人生與不定期乾貨。公眾號：貓叔記
本文由 @貓叔記 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議