你剛被提升為管理者嗎? 你知道管理者和以前當技術時有那些不同嗎? 我在本文中嘗試探討其中我所經歷過的坑，希望讓各位避免再次經歷這些痛苦的事。

職場

學習

以行動支持創作者！付費即可解鎖

閱讀是為了通過書本認識世界、獲取靈感和改善自己或身邊的人的生活。在此主要分享一些我自己從書中獲得的一些靈感、啟發、見解等內容

Seng Wong的沙龍

管理

團隊

同事

開發

執行

專業

經驗

角色

專案

挑戰

從技術走向領導的失敗體會

你手上的專案，是否也少了那張最重要的「啟航地圖」？當高層未給予明確的專案章程，專案經理該如何從混亂中理出頭緒，確保專案如期、如質、不虧本地完成？這篇文章將分享我從慘痛教訓中學到的變通之道，告訴你如何在沒有「聖旨」的情況下，依然精準掌控專案！

音樂藝文

專案管理大小事

客戶

文件

方案

經理

業務

同仁

資訊

解析「專案章程」的空白：乙方專案經理的經驗與應對策略

本文分享一個更系統化、嚴謹的WBS (工作分解結構) 建立步驟，以開發人力資源管理系統為例，說明如何透過需求分析、功能分解和團隊合作，有效建立WBS，避免專案管理中常見問題。

成員

分析師

主管

你的WBS只是裝飾品？專案經理的覺醒與實戰分享

本文探討 WBS (工作分解結構) 的常見誤解，例如：是否應將專案經理工作、會議行動事項、客戶工作納入 WBS，以及 WBS 是否一經建立便不可修改。文章說明 WBS 的核心目的在於協助管理團隊工作，並強調需區分團隊工作與客戶工作，以及變更管理的重要性。

國際

負責人

非常重

會議

參與

文章

WBS 深度解析：解決專案分解中的常見疑慮

說到專案管理，定義專案範圍是定義專案目標後，下一個關鍵的步驟。缺乏清晰且明確的範圍，會對專案後續管理造成不良的影響。本文會針對軟體開發專案，檢討專案的特性，由於而衍生定義範圍的方法，另外還有不先定義範圍，但照運行專案的方法。

何謂專案範圍及定義的困難

按照美國專案管理協會ＰＭＩ所定義的專案範圍是

軟體

用戶

客製化

軟體開發專案範圍定義方法

今天看到一編不錯的文章，說明了我們的學習和工作方法，還有就是如何使用AI來幫助。簡單理解文章的重點就是不管學習或工作，就是通過input，變成output。過往去使用AI的時候，只要能把結果搞出來，拿到個output, the job is done。我感覺我學到了點什麼、完成了某個任務。

或許這樣的過程並沒有什麼問題，但洽洽跳過了最重要的部分，即思考。

我大腦不希望辛苦的工作而把思考交給了AI，我要說這是一個很危險的陷阱，跳過了思考讓我變得一文不值。

所以使用AI的目標重點不在產出，而是改善輸入。通過使用像一些學術論文、書籍等作為輸入源，讓AI先幫我們看過一遍，這樣就能提高自己資源的質量了。通過Elict + notebookLM就能創造屬於自己的小金庫，來幫助自己思考。在思考過後再使用如ChatGPT等工具把finding整體成output，這樣自己就不需要再花大量的時間來處理人和出的事，只需要專注於思考即可。

文化生活

人生百寶箱

使用AI不要只專注於結果

對於需求開發和管理這一個領域，cmmi給出了一個具重要價值但我覺得被低估重要性的實踐，它就是「需求和產品的雙向追溯。」

在軟件開發這一領域，指的是為了滿足需求而建立的一系列功能或特性的追蹤。建立雙向追溯能夠讓我們在事前確保所有需求已經都建立合適的方案來滿足。在進行途中如有需求變更，能夠快速的找到相對應的功能，並評估變更的影響。在收尾時能功能找回需求，以驗證功能有實際的滿足了需要。因此在項目進行的過程中好好維護這種關係是十分值得的。

建立需求和產品雙向追蹤的重要性

當乙方的項目經理久了，即使我的職責是為了給甲方提供他們想要的軟件系統，但是其項目管理系統也不是共享的。換句話說，甲方（可能）有他自己的項目管理系統來管理著我們的項目，而乙方（我）也有只屬於自己的系統來管理自己的項目。只要這種情況存在，項目經理就必須要在任何需求、功能和特性被修改後，同步給甲方的項目經理，並讓他把這些資訊共享給相關的用戶。

做此事困難嗎？說實話不困難，但在執行時通常也有以下的問題

1. 修改後沒有共享: 乙方的項目經理只著眼於內部的執行，沒有做好需求的管理。需求在執行的過程中可能需要澄清，或更改而需要修改現有的需求。修改後只存在於項目管理系統上，沒有更新到相關的文件，更加不會共享給對方。因此甲方在一段時間後即忘記有關的修改。以致於在甲方做驗收測試的時候手上拿的可能是舊的版本而可能引致一些問題。在每次需求有所更動的時候，在流程中加入資訊分享的步驟是很重要的。或者甲乙雙方能建立一個資訊共享的文件夾，並讓甲方承諾且共同維護它。

2. 難以確認生效的版本：很多時候在修改需求時，會因為對細節的打磨而作多次修改，在修改完成後可能客戶又忘記確認。如果在相隔不遠的時間有多次不同的修改的話，這樣的情況就變得複雜了。最於乙方在執行項目時所依據的版本到底是那一份呢？在來來回回的過程中雙方所閱覽的版本就會有所差異，這可能會造成雙方衝突的原頭。因此要避免此類問題的發生，一份打算“生效”版本號的索引文件就事關重大了。雙方在尋找項目文件前先查閱現在各文件版本的現況，能有效為雙方提供統一的視角。要注意的是索引文件應該只有一份而且必須及時更新，並以更新日期為對雙方的對齊點。

為項目中的甲乙雙方提供資訊統一的方法

在讀過不少關於時間管理和生產力書籍後，發現很多不同的作者不約而同地提出了一個十分反人類思維的建議，即「做得愈少，得到愈多。」換句話說就是要我們把時間花在最重要的事情上。這種話我聽過真的太多了，但實際上好像沒幾個人做到，為什麼呢？

在回想上一季我的經歷後，我明白問題的核心是我以前從來沒有想過到底什麼對自己最重要，總是在追逐世界為我準備的各種東西。反正每天上班必定是會面對無盡的事情，幾乎不會給我機會停下來思考，只要能把工作完成就可以了。思考什麼對自己重要根本沒有什麼意義，更像是帶著一種浪漫主義的想法。

而當開始思考自己看重什麼後，才能有機會改變。這種改變的機會就像複利效應一樣，是一個十分漫長的過程，而已途中還會有各種各樣的引誘使自己離開原有的想法。因此只有集中自己的精力，一直在一條航道上，才能找到那「一塊」寶藏。

自我成長

在讀時間管理書籍後的反思

就需求開發和管理這一領域，業務分析師努力向客戶收集需求後，下一步當然就是把需求記錄在案了。就記錄在案這一個步驟，CMMI也提出了一個我覺得很多初階管理者不重視的實踐，但是這個實踐極為重要，它就是「與需求提供者就需求的含意達成一致」。簡而言之就是我們在收集需求的時候，理解和寫出來的東西，是否就是對方講的內容呢？會不會在溝通的過程中，理解錯誤呢？我覺得要做好這一個部份，需求的編寫實際上起關鍵的作出，即易於理解及用詞一致。我個人比較不推薦以用戶故事的方式來編寫需求，即需求編寫的格式是「我是誰，想怎樣，然後我能得到什麼價值。」除非對方對上述需求編寫方式已經十分了解，不然的話這種格式未必能很普通地引起對方的共鳴。而且於需求收集的過程中，也未必能準確地識別所謂的價值是什麼。隨便地寫下一個自己猜想的價值可能並不洽當。因此以直接的行文來表達對方希望想要什麼比起以指定格式來編寫更加重要。另一方面就是用詞方面，我最近受到很深刻的教訓，就是用詞前後不一致而引起的混亂。例如我有時會寫使用者姓名，也有時會寫使用者名稱。如果我在不同的句字中混合使用上面的詞，則可能會造成混亂。例如：操作記錄中要顯示操作的使用者姓名；登入時要輸入使用者名稱。讀者會疑惑這兩個資料，顯示的會是同一個資料嗎？還是指兩個不同的資料？因此在編寫需求時保存一致的用詞能避免和減低誤會的發生。畢竟需求編寫完成後，看的是別人而不是自己。文字能表達的內容及意義有其限制，如果項目的需求比較複雜的話，則十分建議以會議的方式來對每項寫下的需求進行講解。也能幫助編寫需求的人更容易找出理解錯誤的地方，並且及時更正。

沒達成一致意義的需求就是沒有需求

閱讀啟發中心

有效的軟體開發專案管理