本文詳細介紹 Notion 點樣幫一人創業者建立完整嘅工作系統。從項目管理到客戶關係，再到財務追蹤，全部都可以喺一個平台搞掂。無論你係作家、設計師定係網店老闆，都可以透過 Notion 靈活功能打造專屬工作空間，提升效率之餘仲可以慳返唔少開支。本文除咗講 Notion 核心功能，仲有實用嘅入門貼士。

職場

投資理財

學習

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

商業

💼 一人創業

Kevin 創業筆記 📝

客戶

資訊

人工智能

會議記錄

數據

管理

創業

空間

文章

文件

Notion神器：一人創業、Slashies嘅終極工作系統（2025入門教學）

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

音樂藝文

專案管理大小事

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

Seng Wong的沙龍

專案

經理

業務

成員

團隊

開發

分析師

主管

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

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

國際

負責人

非常重

會議

參與

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

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

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

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

軟體

用戶

客製化

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

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

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

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

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

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

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

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

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

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

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

為需求排定優先級對於項目來說異常重要，也是控制項目要實現多少功能的一個手段。如果每一個需求都是同樣重要的話，換句話說就是團隊需要完成所有由用戶提出的需求或功能。那麼在需求管理這一領域來說，我覺得可以說是失敗的。我在這麼多年當項目經理的生涯中，有感這方面管理的困難。當我作為乙方項目經理，要求客戶檢視所有收集回來的需求然後要求他們排定優先級的話，很多時候的結果不會好到那裡去。在他們的眼中，降低優先級某程度就是代表放棄。沒有那個客戶會認為支付了一筆金額後，還要自己降低要求，這是可以接受的。

現在的我是通過工作量透明化的方法來強制打開排定優先級的話題。

- 明確項目目標：乙方項目經理很多時是難以明確知道甲方的項目目標的，因此在執行上往往會出現被甲方拖著鼻子走的情況，只要甲方說這個重要，就需要迫著實現。要打破這個局面，多了解對方項目目標能更利於決定需求的優先程度。以人力資源管理系統（ＨＲ系統）為例，如果對方的目標是改善人員的管理，能更快速地查找個人資料。那麼用戶提出的需求如：修改員工薪金計算公式、員工自助申請假期等；這類合理的需求其優先級能因為跟大目標不太有直接關系而降低；

- 說明總工時：過往的項目，團隊通常會說明項目交付的軟體包含什麼功能。但這樣並不利於項目實現。這是由於需求能於單一功能中無限延伸。再以ＨＲ系統中的「員工管理」此一功能為例，用戶能先提加某某資料欄位的需求，再提欄位和欄位間相互協同相互影響的需求。此類圍繞單一功能無限擴展的情況可謂見怪不怪。因此我們更改做法，於項目的最初，除了跟客戶說明項目將會交付什麼之外，也說明項目包含多少總工時。這能給予項目團隊及客戶一個清晰且可測量的標準。

- 說明實施每項需求所需的時間：每一個人都明白要實施某一個需求，是需要資源的。但是對於不是行內人或是對系統設計了解不深的用戶來說，他們往往會認為所需要的資源幾乎可以忽略不計。換句話說即他們所提出的需求很簡單就能完成，不必為此決定優先級。或者他們會認為每一個需求所需要的資源相差並不大，因此難以作出取捨。為了解決用戶對不確定需要多少資源這一問題，提供明確的參考往往能幫助他們作優先級排序的決定。當客戶得知實施每一個需求大概需要的資源，他們的心中自會盤算是否值得，即實現需求對他工作的幫助是否值得要他支付相對應的金額。

幫助客戶排定優先級的方法

於CMMI的需求開發和管理實踐域中，除了基本如「記錄需求」這種像 “脫褲放屁” 一般的實踐外，有一個實踐我覺得是每一位項目經理都必定聽過，但不一定有做過的實踐。它就是「將需求轉化優先的客戶需求。」言下之意就是在收集客戶各種不同類型的需求後，為需求排定優先順序。排定需求優先順序雖聽起來很理所當然，但是當過項目經理的人就知道，特別是作為乙方的項目經理，很多時收集回來的需求都只有一個優先級，它就是 “最高”。客戶不願意降低需求的優先順序。為何所有需求的優先級都是最高呢？我覺得有幾個不同的原因。- 現在就有：其中一個很重要的原因必定是現在用戶使用中的系統已經有某個功能，即使這個功能使用率有多低，只要現在已經存在的功能，用戶是不希望於新系統中失去任何功能的。- 有所期望：用戶必定希望新系統能比舊系統好，因此所有提出的需求他們都希望能於新系統中實現。而且他們會認為他們提出的需求是必需且不可或缺的，如果缺失的話，感覺會影響更換系統的動機。- 理想主義：新系統應該要能處理各種問題，即使問題的發生機率有多低，只要在需求發掘時有記下，客戶就會認為新系統應能解決該問題，因為客戶會認為此問題必然會於未來再次出現。- 不願失去：於客戶心中，降低需求的優先級於心裡代表的是什麼？必然是失去。最少我認為在他們心中，把優先級降低，即代表新系統將 “有可能” 缺乏解決某一個問題的能力。客戶通常並不會希望失去任何可能的功能，即使他們並未實際擁有它。

難以為需求排定優先級的原因

作為項目經理，不知道大家有沒有一些經驗，在拉上團隊開會問他們覺得這項目有沒有什麼風險的時間，每個人都覺得好像沒有什麼風險。需求清楚、項目時間也有餘裕，感覺不出什麼風險。最多有時候我會聽到，某些成員會講一些比較不重要的事，例如環境在某時間前沒有準備好，某些需求沒能確定等等。總之項目就是給人一種沒有大風險的感覺。

我會覺得這是因為項目經理打開風險的方法失當了。有一組關鍵詞直接代表風險，它就是“不知道”、“不確定”。只要在項目成員口中（包括自己）會說出以上的話，就代表有風險存在。例如某開發說：我不知道能不能做完。表示他有可能在限時內做不完；又如：我不確定這個功能要怎樣做。表示他還不具備做這個東西的知識或技能，有可能做不出項目想要的東西。

以上都是最容易發現項目風險的地方，可惜很多項目經理都是直接無視那些信號聽過就算，並沒有好好記下。有經驗的項目經理應該在和成員討論事情時，好好把握這個信號，並把它記在登記冊上，並在下次的會議上拿出來討論應對措施。