Re: [討論] 週報的用途?

※ 引述《NewSpec (新規格)》之銘言：
: 最近聽到某些公司有要求要寫週報
: 不過做的事情PM一般來說都會知道，專案也應該早就和老闆告知過了
: 為什麼還要人寫週報呢? 感覺很多此一舉
: 請問一下週報真正的用途是什麼? 真的有必要嗎?
[公司規模]
小型公司 :
可能所有 IT 都在同一個辦公室, 站起來問一下, 馬上可以 Sync 所有狀況,
或是只有幾十個人, 發個 Mail 就可以討論進度, 這種情況, 週報的意義確實不大

中大型公司 :
像是集團規模, 底下有好幾間子公司, IT 人員分散在不同樓層, 不同縣市, 不同國家,
這時候週報就有意義了

底層員工 > 小主管 > 中主管 > 經理 > 總經理

1. 週報可能是匯報到中主管的階段, 中主管需要在彙整每個人的週報, 往上呈報
2. 週報的過程, 可以聽到其他系統負責人的計畫排程, 或是系統問題修正, 有相關聯
的系統單位, 可以即時判定是否跟自己有相關

ex: 人事系統提出, 因應歐洲法規修改個資法, 個資需要做調整, 請假系統聽到之後, 可能就會提出, 他們系統也許需要配合修改

3. 週報也是 KPI 審核一種依據

[週報內容]
這個依照每間公司規定, 有不同內容, 前後待過的兩家不同公司, 我的習慣都是從
自己的工作日誌彙整為週報, 目前為止, 大約寫了 8 年的工作日誌

用自己看得懂的文字記錄, 可以快速查詢, 大概會記錄

1.工作預定排程 : 幾月幾號要進行系統分析設計 / 文件撰寫 / 開發 / 測試 / 上線
2.哪一天遇到突發 Case, 花了多久時間處理, 造成原定工作延期
3.難解的 Bug, 花了特別多時間處理, 紀錄解決方法和流程
4.某個系統功能, 採用了我覺得不合理的方法, 我會特別紀錄是哪一天, 哪個人,
在哪一場會議做出這個決定, 之後出問題, 避免把錯誤怪在我身上
5.工作進度

現在遇到難解的 Bug, 會憑印象在過去的工作日誌查詢, 有時候真的會發現是相同狀況,可以省去尋找解法的時間

--

單純只以 RD 角度, 當然覺得看 Code 就好, 如果公司有需要通過 ISO 認證, RD 可能寫文件的時間, 會超過實際寫 Code 的時間