全部的活動均可以看作一個項目來管理。在企業中更是這樣。
因此項目管理平臺，對於任何一個高科技企業來說都是必不可少的。
OpenProject（如下簡稱OP）就是一個不錯的項目管理平臺，軟件開源，文檔齊備。對於大多中小型公司來說，免費版也已經足以知足工做要求。最新版本的OP還對手機小屏幕的瀏覽進行了優化，徹底能夠作到使用手機對項目進行管理。服務器
創建帳號
做爲企業管理中私密性比較強的一類，OP用戶帳號的創建須要由管理員完成。
其中的帳戶實際只有普通用戶和管理員兩種，後者有權限對OP系統的設置進行維護和調整。前者則是正常的項目管理使用帳戶。
項目管理帳戶在具體項目中能夠體現爲不一樣的身份，這個後面咱們再講。工具
首頁和登陸
OP系統頁面都是能夠定製的，也能夠選擇默認語言。使用出廠設置的狀況下，一般首頁語言是你電腦操做系統使用的語言。首頁有項目的瀏覽功能，可是這裏能夠出現的項目，都是在創建項目時指定爲「公開」的項目。
右上角點擊「Sign In」按鈕能夠出現登陸框，登陸框出現後，鼠標不要移到其它網頁菜單欄位置，否則登陸框又會消失。測試
OP設計思想和工做原則
OP定位是一個項目管理全流程的產品，能夠管理從立項到完成的完整生命期。
在OP管理下的項目和人，基本都處於「任務驅動」的工做模式下。
所以就相似日常使用Email系統那樣，天天一上班，OP頁面就處於打開狀態。隨時響應、處理、並更新每一項任務。
雖然OP設計能夠將全部的時間轉發到Email，但一般的主要項目執行人員，會不斷的被大量任務郵件淹沒，最終仍是直接工做在OP頁面上更方便。優化
創建新項目
首頁上，還有頁面左上角的下拉菜單中，都有新建項目的按鈕。
項目名稱必須以「標識符」開頭，標識符是以小寫字母開頭，只包含小寫字母、數字、下劃線和短劃線。這跟一般企業的檔案管理要求是吻合的，便於項目的管理和歸檔。以後可使用中文或者你喜歡的語言，給項目起一個簡潔易懂的名稱。
項目的描述是對項目進一步的解釋。
以後的「標識符」一欄，一般能自動從項目名稱中提取，若是提取的不滿意，能夠本身修改一下。
項目的類型默認有兩種，這個能夠由管理員，根據團隊的實際狀況增減。這個類型並不影響OP對項目的具體處理，主要是提醒項目成員，根據企業的文化、共識、習慣，選擇何種方式對項目進行管理。
默認的兩種類型，Standard project是指標準項目；Scrum team通常是指當前比較流行的敏捷開發團隊管理模式。
最後的「公開」選項，就是指項目是否在首頁、不須要登陸就能供查看。
這部分介紹的比較詳細是由於咱們剛剛接觸OP,實際上除了項目名稱，都是能夠不填寫或者使用默認值的。
完成項目的建立後，在左上角下拉菜單裏面項目的列表裏就能查看到項目。對於新項目，通常還有兩件事情須要作：
選擇左下角「項目設置」菜單，屏幕右側，選擇Tab中的第二列「模塊」，在其中勾選在本項目中須要使用的工具。這些工具包含：spa
- 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平臺對項目的細節進行掌控，避免出現具體工做人員已經在平臺上對項目狀態進行了更新，或者發佈了論壇求助信息，而得不到響應的事情。
本應雙向的信息得不到響應，或者線上線下須要兩次溝通，都會影響項目執行人員的心情和工做狀態。