所有的活動都可以看做一個項目來管理。在企業中更是這樣。
所以項目管理平台，對於任何一個高科技企業來講都是必不可少的。
OpenProject（以下簡稱OP）就是一個不錯的項目管理平台，軟件開源，文檔齊備。對於大多中小型公司來講，免費版也已經足以滿足工作要求。最新版本的OP還對手機小屏幕的瀏覽進行了優化，完全可以做到使用手機對項目進行管理。
建立賬號
作為企業管理中私密性比較強的一類，OP用戶賬號的建立需要由管理員完成。
其中的賬戶實際只有普通用戶和管理員兩種，后者有權限對OP系統的設置進行維護和調整。前者則是正常的項目管理使用賬戶。
項目管理賬戶在具體項目中可以體現為不同的身份，這個后面我們再講。
首頁和登錄
OP系統頁面都是可以定制的，也可以選擇默認語言。使用出廠設置的情況下，通常首頁語言是你電腦操作系統使用的語言。首頁有項目的瀏覽功能，但是這里可以出現的項目，都是在建立項目時指定為“公開”的項目。
右上角點擊“Sign In”按鈕可以出現登錄框，登錄框出現后，鼠標不要移到其它網頁菜單欄位置，不然登錄框又會消失。
OP設計思想和工作原則
OP定位是一個項目管理全流程的產品，可以管理從立項到完成的完整生命期。
在OP管理下的項目和人，基本都處於“任務驅動”的工作模式下。
因此就類似平常使用Email系統那樣，每天一上班，OP頁面就處於打開狀態。隨時響應、處理、並更新每一項任務。
雖然OP設計可以將所有的時間轉發到Email，但通常的主要項目執行人員，會不斷的被大量任務郵件淹沒，最終還是直接工作在OP頁面上更方便。
建立新項目
首頁上，還有頁面左上角的下拉菜單中，都有新建項目的按鈕。
項目名稱必須以“標識符”開頭，標識符是以小寫字母開頭，只包含小寫字母、數字、下划線和短划線。這跟通常企業的檔案管理要求是吻合的，便於項目的管理和歸檔。之后可以使用中文或者你喜歡的語言，給項目起一個簡潔易懂的名稱。
項目的描述是對項目進一步的解釋。
之后的“標識符”一欄，通常能自動從項目名稱中提取，如果提取的不滿意，可以自己修改一下。
項目的類型默認有兩種，這個可以由管理員，根據團隊的實際情況增減。這個類型並不影響OP對項目的具體處理，主要是提醒項目成員，根據企業的文化、共識、習慣，選擇何種方式對項目進行管理。
默認的兩種類型，Standard project是指標准項目；Scrum team一般是指當前比較流行的敏捷開發團隊管理模式。
最后的“公開”選項，就是指項目是否在首頁、不需要登錄就能供查看。
這部分介紹的比較詳細是因為我們剛剛接觸OP,實際上除了項目名稱，都是可以不填寫或者使用默認值的。
完成項目的創建后，在左上角下拉菜單里面項目的列表里就能查看到項目。對於新項目，一般還有兩件事情需要做：
選擇左下角“項目設置”菜單，屏幕右側，選擇Tab中的第二列“模塊”，在其中勾選在本項目中需要使用的工具。這些工具包含：
- Backlogs: 未完成工作的列表，可以理解為項目級別上的todo list。
- Cost control: 對項目進行成本管理，成本管理主要包括人員成本、設備成本和現金成本。（當然項目管理本身默認包含了時間成本）
- Cost reports: 形成項目成本報告。
- Documents: 允許你上傳項目文檔，並對文檔進行分類管理。
- Meetings: 項目的會議信息，通常是起到會議通知的作用，並可以成為項目的溝通記錄。
- 代碼庫: 支持SNV/GIT兩種版本化的代碼管理工具。
- 工作報告跟蹤：這是整個項目管理的核心
- 新聞：通常是項目組相關的內部消息發布。
- 日歷：相當於形成項目維度的日常工作計划。
- 時間線：形成項目的甘特圖。這個模塊是我比較喜歡的，不過官方已經計划使用工作包中的時間線工具替代掉了，並計划於8.0版本中取消此功能。希望到時候工作包中的時間線也能擁有這樣方便的定制能力吧。
- 時間跟蹤：用於在用戶活動中統計時間的消耗。
- 活動：這是對於管理人員比較有用的一個模塊，用於實施了解到項目的具體工作，跟工作包的管理方式相比更微觀。
- 維基：用於發布項目的最新進展、技術積累或者觀點等內容，是項目的博客，通常的項目都是用於對項目組外的溝通。
- 論壇：通常用於項目組內的溝通、討論及知識積累。
這些功能模塊，根據項目的需求自主添加，理論上越多越好，但對於小項目，過多的模塊會顯著的分散工作人員的注意力，起到反面的作用。
另外一個必要的項目設置是Tab中的第四項：版本。國內軟件開發通常缺乏版本化的管理和規划，但實際上幾乎沒有軟件不需要版本化的管理，所以強烈建議你在新建項目時就在這里建立最初的版本計划。
一個比較特殊的用法是敏捷開發中的Sprint（沖刺）概念，可以在工作類型中添加（后面會介紹）。但更貼切的一個方式是把項目划分的足夠小，然后用Sprint版本的方式來管理。
項目可以添加項目成員，默認的身份是Member，就是普通工作人員，也可以指定為項目管理員，就是中國俗稱的項目經理。
每個項目成員都可以指定成員的Cost，這是指在這個項目中，該成員的成本是多少。換言之，每個不同的項目，同樣的人，可以有不同的成本，這是合理的。因為項目不同、崗位不同、參與度不同，當然都會帶來人員成本的不同。
(貨幣符號當前版本尚不支持修改，請在團隊中自行規定使用方式，比如直接把歐元符號當做人民幣。)
其他的合法用戶，不是項目成員，也不是項目管理員，則自動成為Reader角色，就是可以了解項目，但不能參與和修改項目。
那么更高要求的保密項目怎么辦？這個在OP中並沒有給出特別的處理。通常來說，反正是一個免費的系統，服務器的需求又不高，需要保密的系統單獨部署一套就好了。
項目任務的添加
項目建立后，可以根據具體工作，向項目中添加具體的任務條目。
在OP中，項目條目是分類型進行管理的，這個類型可以在項目設置中增減和修改，但通常直接使用默認的7種類型已經可以滿足大多項目。這其中類型分別是：
- Task: 通常意義上的任務。
- Milestore: 里程碑，指項目的階段成果。
- Phase: 階段。
- Feature: 產品特征。
- Epic: 史詩，其實就是大的用戶故事。
- User story: 用戶故事。
- Bug: 故障、缺陷。
這些類型，要根據自己團隊的習慣來選擇，或者再設置增減。作為一個通用的軟件平台，OP肯定提供了多於一般需求的重復、或者類似的類型，不加區分的在一個項目中使用往往會導致成員的困惑。
這些類型的重要之處是，對於每一個不同的類型，會有不同的工作流程與之相對應。Bug是在各種項目管理流派中歧義最少的概念，我們以Bug為例，可以有如下的工作（或者工作狀態）：
- New: 測試人員提交一個新Bug。
- Confirmed: 開發人員確認這是一個Bug。
- In development: 正常開發解決這個Bug。
- Developed: 開發已經完成
- In Testing: 正在測試Bug是否仍然存在。
- Tested: 測試結束。
- Test failed: 測試失敗（通常指Bug仍未解決。本Bug解決了，又導致了新Bug一般需要溝通，也有可能會新申報一個Bug)
- Closed: 問題解決，Bug流程關閉。
- On hold: 本問題存在，但因技術限制、資源限制、項目版本限制無法解決，暫時存檔，將來會解決。
- Rejected: 駁回，經開發人員確認這不是Bug。
關於對於某一工作類型的工作流設置，需要由系統管理員在系統設置中修改。此外項目管理對於項目類型的增減，實際也是在系統管理員設置的多種工作類型范圍內進行增減。
繼續說項目任務的添加。對於每個任務，指定任務的執行人（指定人）和責任人是很重要的，因為項目管理的核心是對人力資源的調配。執行人跟責任人可以是同一個人，也可以不是。兩者的區別可以參考《完全責任觀》課程或者《當責》暢銷書。
項目管理的另外一個重要維度是時間，所以雖然新建一個項目和新建一個任務，有很多字段都可以空缺，但時間指標還是一定要填寫的。OP支持絕對進度和相對進度兩種時間跟蹤方式，前者指類似“本項目預計32個工時完成”，后者則指好像“本項目計划8月10日開始，到8月20日完成”。兩種方式都可以根據自己團隊特點選用，但一般不需要都用，否則計划調整時候，每個項目都需要通過計算填寫兩次。因為大多的項目計划都需要輸出甘特圖，所以建議使用日期計划的方式。（僅供參考，我也見過很多規范的項目計划是兩者都列出來）。
此外就是剛才說過的版本化管理，每個新建任務，除非是共有性的，否則盡量從屬於某一個版本。而且這樣分配，很多先進的特征，比如路線圖管理，才能幫你自動的生成一些報告。
任務條目可以上傳文檔，用於描述更詳細的內容，比如開發需求文檔。理論上講這個文檔可以使任意格式。但通常的習慣，這個文檔主要供閱讀使用，所以最好是pdf之類，直接可以在網頁打開的文檔。而可以編輯的版本歸類到源代碼進行版本化管理或者文檔共享模塊中管理。
任務條目建立后，在項目列表中就會出現該項內容，點擊列表最后的“！”圖標，可以查看條目的詳細內容及再次編輯和工作狀態更新。在最上面Tab條中的“關系”一欄，可以設置項目的前置項和后置項。對於很多強合作類的項目中，這個設置是很必要的。否則會出現，本來B任務需要等待A任務的結果才能執行，但甘特圖中，A與B並列的情況。
日常執行工作
執行工作通常都圍繞着工作包這個模塊進行，當然實際上很多其它維度的瀏覽界面中也能進行。比如對於任意一個具體的工作人員，每次登陸后的首頁中，就有了大部分涉及到他自己的工作項目。
工作人員只需要根據具體條目的內容，完成自己的工作，隨后在條目的狀態一欄修改項目的進展狀態，就可以讓項目的整體進展更新。
注意強調一下，在一個規划很好的項目中，通常項目和項目內容建立后，是不需要進行大量修改的。日常的工作都是只需要更新項目的狀態和補充上傳項目的文檔、代碼即可。
如果一個項目在執行過程中需要不斷的調整項目的內容、項目設置、修改具體條目的內容和時間計划，只能說項目從立項的規划就存在了大量問題。
項目執行過程中的溝通協調，是通過論壇、WIKI、新聞、會議的形式來完成的。項目成員都應當養成每天定時查看項目信息的習慣，特別是為了避免大量的垃圾郵件而關閉了郵件通知的情況下。
日常管理工作
項目日常的管理工作同執行工作可能類似，但更多的在於使用OP的多個維度的瀏覽或者報表，對項目的內容和執行情況進行把控、分析。從中發現問題，隨后對相關人員進行具體的溝通、協調或者輔導。
也較多會對項目的具體內容和項目計划進行調整的情況。
通常是因為，在國內的開發團隊中，雖然是由項目經理對大家進行任務安排，但隨后是由具體執行人員完成文檔工作和指定執行計划。
如果項目經理認為執行人員的理解有偏差，或者計划制定的有缺陷，項目經理也會直接對已經存在的條目進行編輯修改。但請注意，這種修改，通常要在線下的溝通完成之后。以免發生管理層面的誤會。
這些工作內容，因為通常都是在線下進行，所以在OP平台上往往並不會留下痕跡。但正因如此，管理人員一定要督促自己通過OP平台對項目的細節進行掌控，避免出現具體工作人員已經在平台上對項目狀態進行了更新，或者發布了論壇求助信息，而得不到響應的事情。
本應雙向的信息得不到響應，或者線上線下需要兩次溝通，都會影響項目執行人員的心情和工作狀態。