專案元件化設計，究竟是畫蛇添足還是畫龍點睛？
從零開始學運營，10年經驗運營總監親授，2天線下集訓+1年線上學習，做個有競爭力的運營人。 ofollow,noindex">瞭解詳情
釋放雙眼，帶上耳機，聽聽看~！
00:00
00:00
在之前的文章裡，我介紹了任務相關功能的設計思路。無論是Worktile6.0，還是Teambition，Trello，基本上都是由任務組成了專案。然而，Worktile7.0引入了【元件】這個概念，作為任務的承載方式，二者共同組成的專案。我們這樣設計的初衷，是為了增加展示的多樣性，同時增加專案功能的可拓展性。究竟如何實現，讓我帶您瞭解一下！
專案元件與任務的關係
元件決定了任務的展示形式、展示維度。元件之下，還有【檢視】——通過檢視，進一步對元件中的任務進行篩選和區分。
（圖1：專案／元件／檢視 三者的關係）
以敏捷開發專案為例，所包含的元件有：
- 需求： 專案需求池，該專案的需求任務都彙總在這裡。
- 任務： 根據需求，衍生出的研發任務彙總在這裡。
- 缺陷： 該專案的缺陷任務彙總在這裡。
- 迭代： 管理該專案內的每次迭代。
- 報表： 對專案內資料進行統計分析展示。
同時，在需求元件下面，我們可以通過【檢視】對需求進行篩選——【進行中的需求】、【我負責的需求】等。
其關係如圖所示：
（圖2：通過【檢視】可以對需求進行篩選）
產品實現如圖所示：
（圖3：敏捷開發專案元件圖）
八種類型的元件
在Worktile7.0中，我們提供了八種元件，其中報表元件肩負著統計分析的功能，後續我們會單獨介紹。下面，就來一起看看其他幾種元件。
1. 看板/列表/表格元件
看板，是最基礎也是常用的任務展示方式，Worktile的老使用者都不會陌生。通過看板的形式，對任務進行展示。但是與過去的看板所不同的，在Worktile7.0中引入了【檢視】的概念，即通過設定不同的檢視，對任務進行篩選。
（圖4：【看板元件】產品介面）
在過去，同一個看板的list是固定的，這也就限制了我們對任務的篩選。通過檢視功能，我們可以按人員分組、按屬性分組、按狀態分組……極大的增加了檢視／篩選任務的便捷性。
Worktile 7.0通過【檢視設計器】進行檢視的設定，設定流程包括三步：
- A 選擇分組方式——按照怎樣的維度來進行分組，設定list；
- B 選擇排序方式——一個分組內的任務，以何種形式進行排序；
- C 設定查詢條件——在前兩步的基礎上，如果需要進行查詢，可以在這裡進行設定。
（圖5：檢視設計器的產品介面）
除此之外，移動端辦公越來越普及，在手機端檢視工作變得越來越頻繁。但是，手機端的互動和PC端的互動天生不同，本著之前提到的【個性化】的設計思路，我們把【想要看到什麼】的選擇權交給使用者。使用者可以通過【配置中心】針對性地修改看板元件在PC端和移動端展示任務的方式。
（圖6：配置中心可以修改展示任務的方式）
【列表】和【表格】與看板的設定和功能類似，只是任務的展現形式和互動略有不同，在此就不展開介紹了。
2. 時間元件
甘特圖通過條狀圖來顯示專案，進度，和其他時間相關的系統進展的內在關係隨著時間進展的情況，是專案管理過程中瞭解專案進度的重要方式。Worktile7.0提供【時間】元件來檢視專案的甘特圖。
（圖7：【時間元件】產品介面）
【定義起始／截止時間屬性】：一個任務型別中，可能存在多個與“時間”相關的屬性；而甘特圖只能展示一種維度上的起始和截止時間。例如：一個測試用例任務可能包括任務的開始／截止時間、測試日期，這樣就有了3個時間屬性。然而甘特圖只能展示一組時間維度，究竟是選擇“任務的開始／截止時間”還是“測試日期”呢？我們就可以通過【定義起始／截止時間屬性】來實現。
在Worktile7.0中，預設起始／截止時間屬性為“任務的開始／截止時間”屬性，我們也可以將其設定成其他的。如圖8所示，測試用例在甘特圖中的起始時間為“測試日期”屬性。
（圖8：測試用例在甘特圖中的起始時間為“測試日期”屬性）
3. 日曆元件
通過日曆的形式展示專案內任務的進展情況。
（圖9：【日曆元件】產品介面）
與甘特圖中的【定義起始／截止時間屬性】類似，日曆元件也只能以一組起始／截止時間為展示維度。這就需要在元件設定中定義任務型別的起始／截止時間屬性
4. 工時元件
工時元件可以對專案內任務工時情況進行彙總、展示和篩選。同時，工時元件提供了多種檢視和篩選維度。
注意：
- A 若需要統計工時，本專案內的任務型別必須包含【工時】屬性。
- B 任務填寫工時資訊之後，才能在工時元件內展示。
（圖10：【工時元件】產品介面）
5. 迭代元件
迭代元件是專為敏捷開發設計的元件。在敏捷開發的過程中，規劃和實施迭代（sprint）是非常重要的一步。我們從需求池（product backlog）中選取一定規模的使用者故事／需求／缺陷，規劃成一次迭代並執行。而在迭代的執行過程中，敏捷團隊需要掌握所有任務的資訊、瞭解使用者故事之間的關係並對迭代的進度進行統計及分析。
（圖11：敏捷開發流程圖）
為了滿足敏捷開發的需求，Worktile對迭代元件進行了特異化的設計，設定瞭如下檢視以滿足迭代需求：
- 概覽： 對迭代資訊／時間／進度／燃盡圖等迭代進度資訊進行展示。
- 任務： 本次迭代內所有任務資訊的彙總展示。
- 故事板： 通過看板檢視展示本次迭代中任務／缺陷／需求之間的關係。
- 規劃： 通過簡單的拖拽動作規劃迭代。
在專案模板中新增迭代元件，即可實現對迭代的規劃、跟進和管理。
注意：
- A 敏捷開發中的任務型別要有【所屬迭代】的屬性。
- B 在敏捷開發的過程中，我們有時會定義多種任務型別作為敏捷開發的需求。這就要求我們必須把自定義的任務型別“對映”為需求／任務／缺陷中的一種（如圖12所示），才能夠被迭代元件作為需求／任務／缺陷中的某一種來處理。
- C 一個任務型別只能被對映為需求／任務／缺陷中的一種，而一個迭代中的需求／任務／缺陷都可以對應多種任務型別。
（圖12：迭代元件的對映設定）
總結
任務型別和元件，組成了一個專案模板的基本結構。任務型別的自定義和專案元件的自主選擇和配置，是Worktile7.0模組化設計的體現。結合安全模式的設定，就可以組合出無數種可能，滿足針對不同工作場景的個性化匹配。
#專欄作家#
袁林，人人都是產品經理專欄作家。分享SaaS運營和企業管理／協作／辦公的相關知識
本文原創釋出於人人都是產品經理。未經許可，禁止轉載。
題圖來自 Pexels ，基於 CC0 協議
