項目資源管理-日曆圖

做爲一名前端開發經理，公司有多條業務線，協調資源支持各業務線平常需求成了個人平常。這篇文章主要記錄這個過程的思考和如何生成一個直觀的日曆圖。

現狀

• 多個業務線需求，技術方案選型須要統一落地，因此最好能統一收集需求，合理安排；
• 跨部門（跨省）合做，目前項目流程並不規範，開發人員需求評估存在必定問題，存在延期狀況；
• 經過開發同窗工做日誌瞭解工做狀況，沒法直觀地持續跟蹤；
• 部分產品線臨時需求較多，開發同窗的計劃常常改變，加大跟蹤難度；
• 靠文本輸出進度、計劃、問題給項目經理，不直觀；

目標

因此，我但願經過項目管理工具來進行項目排期、資源協調，並輸出直觀的報告給上級、產品經理、開發經理，將前端工做安排、資源狀況透明化，從而逐漸完善項目流程和合做方式。

奈何目前好的、完善的項目管理協同工具都須要收費，因此只能從新細化下需求，考慮在現有了解的資源基礎上去儘量達到目標：

• 方便的項目管理，可持續跟蹤進展
• 支持里程碑，關鍵時間點，在關鍵時間點覆盤，逐漸優化工做方式
• 將信息直觀地同步給相關方，增長互相間的瞭解
  • 需求排期狀況、節奏點
  • 資源投入狀況
• 經過持續跟蹤，覆盤，逐漸減小臨時變動，提早計劃
• 資源飽和下，提供給各產品線需求PK，將重點放在優先級更高的任務上
• 輸出到工做報告中

因此核心仍是項目管理和報告輸出，綜合考慮

• 項目管理：最終仍是決定使用OmniPlan，將項目需求按業務線分組管理起來，可是隨着任務的增長，甘特圖信息內容太多，不夠直觀，另外也不容易透明共享。
• 報告輸出：更傾向於使用日曆圖，像日曆日程那樣，能夠方便查看最近的任務、詳情。

因此將重點放在，在OminiPlan項目管理基礎上，如何進行合理的管理，將輸出的甘特圖信息轉換成日曆圖，並造成了最後的解決方案。

最終效果

• 默認顯示當月的項目安排
• 將任務按顏色區分，關聯里程碑
• 任務展現：業務線、開發人員、需求名稱，底下顯示完成進度條
• 點擊任務右側展現詳情，若是名稱填寫需求文檔ID，可連接到需求文檔
• 能夠篩選業務線、開發人員，減小無關項

OmniPlan

爲了最終的日曆圖展現，首先要確保甘特圖數據符合必定的要求，因此先看下輸出的CSV：

紅框中是咱們須要的信息，接下來會介紹OmniPlan使用中的一些點，保證最終輸出的數據要求：

• 任務編號：任務編號按層級編號，以達到相似樹形結構的效果
• 任務分組：
  • 根任務按業務線或者大項目分組劃分，以此來展現業務線信息
  • 關聯項目能夠自由建立分組，最終任務按照樹葉子節點來統計
• 里程碑：任務劃分幾個階段開發，聯調，測試，發佈，其中後三項爲里程碑，必須按此命名，並跟任務創建關聯關係
• 使用關聯線來鏈接任務：里程碑是經過任務關聯和任務聯繫上的
• 資源安排：任務安排了資源纔算計劃內的任務，能夠查看人員狀況，檢查未分配的任務
• 任務拆分：一個長時間的需求，可能會由於緊急或優先級更高的需求，須要進行拆分，但他們同屬於一個任務，只要展現一個信息便可；這時候能夠經過任務拆分，安排出合適的時間給其餘需求
• 設置基線，持續跟蹤：每週計劃排好後，設置基線，用來按期覆盤，對比計劃和實際狀況，發現問題

因此最終咱們整理的甘特圖以下：

日曆圖

項目管理起來後，只須要持續根據，更新完成狀況，並進行數據同步便可。 接下來咱們須要須要將CSV轉換成日曆圖，這裏簡單講下思路：

1. 明確日曆圖要展現的信息，造成數據結構

{
  productLine: '',  // 產品線
  title: '',        // 任務名稱
  url: '',          // 需求文檔地址，從名稱中獲取
  assigned: '',     // 分配
  // 開發
  develop: {
    startTime: 0,     // 開始時間
    endTime: '',      // 結束時間
    effort: '',       // 工時
    done: '',         // 完成度
  },
  // 聯調
  jointDebug: {
    startTime: 0,     // 開始時間
    endTime: '',      // 結束時間
    effort: '',       // 工時
    done: '',         // 完成度
  },
  // 測試
  test: {
    startTime: 0,     // 開始時間
    endTime: '',      // 結束時間
    effort: '',       // 工時
    done: '',         // 完成度
  },
  // 發佈
  publish: {
    startTime: 0,     // 開始時間
    endTime: '',      // 結束時間
    effort: '',       // 工時
    done: '',         // 完成度
  }
}
複製代碼

將各階段數據聚合到一條，是爲了不前臺再去查找關聯關係，展現詳情也更方便。數據經過csv進行解析 2. 日曆圖由兩部分組成：日曆+日程

• 先根據年份月份生成日曆圖
• 而後根據日曆圖開始、結束時間，篩選出範圍內的任務
• 按周將任務拆分紅數組，這樣能夠將任務展現成跨天連續的樣子 最終造成：

{
	dates: [
		[1, 2, 3, 4, 5, 6, 7]
		...
	],   // 日曆
	tasks: [
		[
			{
				任務1,
				style: {
					根據開始時間，計算水平偏移
					根據覆蓋狀況，計算垂直偏移
					顏色區分
				}
			}
		],
		...
	]
}
複製代碼

顏色區分思路：

雖然是隨機顏色，可是顏色要能很好區分，另外還要展現進度條，因此須要符合必定的規則。這裏基於HSL，只生成色相（H），而後經過飽和度（S）、明度（L）來設置顏色深淺來區分進度條；

因此按照色相環上6大主色：360°/0°紅、60°黃、120°綠、180°青、240°藍、300°洋紅不斷進行拆分，讓臨近的兩個任務儘量處於兩個主色上

爲何不設置OmniPlan報告模板？

• 首先模板語法能力有限，難於完成複雜的邏輯，數據處理，日曆繪製
• 可交互性
• 報告主要是要透明，讓相關方知道，同時能夠隨時跟蹤

總結

這樣的項目管理主要是爲了瞭解項目安排和資源狀況，方便開發經理跟進組員的狀況，並統計反饋給相關方。只解決了特定需求，像一些大的項目，應該由PM來去維護項目計劃細節來跟進。後續會繼續跟進狀況，學習項目管理，尋求更合適的方式。