騰訊TAPD：系統設計全流程解構

編輯導語：騰訊TAPD，即騰訊敏捷產品研發，是常用的項目管理工具。那么，具體到設計層面，我們可以如何認知這款工具？本篇文章里，作者從系統全局、詳細分析、原型設計三方面對騰訊TAPD的系統設計結構進行分析與拆解，一起來看一下。

騰訊TAPD官方簡介，TAPD 是Tencent Agile Product Development的縮寫，即：騰訊敏捷產品研發。提供貫穿敏捷研發生命周期的一站式服務，覆蓋從產品概念形成、產品規劃、需求分析、項目規劃和跟蹤、質量測試到構建發布、用戶反饋跟蹤的產品研發全生命周期。

此次本著學習的態度解構騰訊TAPD（專業版），我是從TAPD的頁面和功能入手，逆向分析得到關鍵輸出物和原始需求，以此深入學習項目管理系統的業務。

獲得關鍵輸出物后，本文是以正向設計的邏輯進行描述，還原從需求到原型的設計過程。本文按分析粒度大小，分為三部分：

1. 系統全局分析，分析粒度保持在模塊管理，目的是獲得系統的全局認識；
2. 系統詳細分析，分析粒度變小，保持在增刪改查功能的粒度，目的是獲得全部系統用例；
3. 熟悉的系統原型設計，分析粒度變小，保持在頁面和元件交互，目的是獲得可交付的原型和標注。

一、系統全局分析

系統全局分析，分析粒度保持在模塊管理，目的是獲得系統的全局認識。

第一節是從業務的角度獲取需求和用例，第二節是從系統的角度獲取需求和用例，我稱這個粒度為一級用例，第三節和第四節是在前兩節的用例基礎上分析主流程和對象。

1. 業務用例

在軟件項目里，業務范圍和系統范圍是不同的。

業務范圍指這個項目所涉及的所有客戶業務，這些業務有沒有計算機系統參與都是客觀存在的。

系統范圍是指軟件將要實現的那些對應于業務功能的系統功能，從功能性需求來說系統范圍是業務范圍的一個子集，但是一些系統功能則會超出業務范圍，例如操作日志，有沒有操作日志并不影響業務目標的達成，客戶也不一定會提出這個要求，但從系統角度出發，操作日志會使得系統更加健壯。

——來自《大象Thinking in UML》

在引入計算機系統之前，業務也一直跑得很順暢，因此在初始階段，不引入系統的角度，純粹站在業務的角度，分析業務的主流程場景，獲取業務用例。

獲取業務用例需要分析出業務主角和用例，業務主角即參與到業務流程中的角色，例如項目經理、產品經理等。

用例即業務主角需要在業務流程中完成的事情，這里需要注意用例的粒度。我經過思考，系統全局分析階段，建議使用管理一類事物的粒度，例如需求管理，這個粒度僅供參考。

開始獲取業務用例，以下是一段項目實施過程的場景。

某一天，領導分配給項目經理一個新項目，于是，項目經理召集產品組長、設計組長、開發組長、測試組長簡單同步一下項目信息，表示要啟動該項目。

會后項目經理創建一個群聊，把項目成員拉到群聊中，同步項目信息。

開工前，項目經理簡單制定了計劃：產品經理收集需求，產品組長評估需求的優先級，并規劃成多個迭代實施，確定迭代范圍后，產品組長、設計組長、開發組長、測試組長分別進行人員安排。

確定迭代的需求范圍后，接下來就是需求的流轉，產品經理完成需求設計，UI設計師完成UI設計，開發工程師完成編碼，測試工程師完成需求測試，最后產品經理驗證需求并關閉需求。

測試工程師在測試的過程中會提出bug單，交由開發工程師進行修復。項目經理對每個迭代負責，在迭代過程中，每天組織晨會，使用需求看板同步進度。

在進度方面，項目經理會查看需求報表和bug報表跟進進度，并且每周會整理項目報告向上級匯報。最后保證迭代需求全部完成，即可結束本次迭代，然后開啟下一次迭代。

基于以上場景，獲取業務主角和提煉一級用例，如圖1。

• 項目經理是項目的啟動者，由他管理項目；在項目實施中對每個迭代負責，由他管理迭代；定期在需求看板上同步進度，由他管理需求看板；定期查看報表了解迭代數據，他需要查看報表；定期整理項目報告進行匯報，他需要管理項目報告。
• 產品經理是需求的提出者，且會進行需求設計，由他管理需求。
• 設計師是需求的設計者，參與需求的UI設計工作，屬于需求中的一個步驟。
• 開發工程師是需求的代碼實現者，參與需求的代碼編碼工作；當系統出現bug的時候，他需要參與bug的修復工作。
• 測試工程師是需求的測試者，參與需求的測試工作；當測試出bug的時候，會提出bug單，由他管理bug。注：在TAPD中使用“缺陷”來表示bug，后文也會沿用缺陷這個詞。

圖1 業務用例

2. 系統用例

得到業務用例后，雖然能看到業務主流程的雛形，但要完成系統的閉環還需要站在系統的角度去補充用例，例如系統權限管理的需求，業務用例中并沒有體現出來。

系統用例也是需要獲得角色和用例，這個階段的用例粒度和上一步驟的業務用例保持一致，即管理一類事物。

開始獲取系統用例，我站在系統的角度，從三個方向分析系統需求

1. 系統管理的需求；
2. 系統易用性的需求；
3. 系統擴展性的需求。

于是我列出了以下場景的需求：

• TAPD是一款SaaS產品，會服務多家公司的客戶，所以需要創建一家公司才可使用系統；
• 每個系統都需要考慮權限管理，所以管理員需要維護組織架構和系統用戶組權限，才能夠管理公司成員的權限；項目經理需要維護項目用戶組權限，才能夠管理項目成員的權限；
• 每個用戶需要注冊、登錄、修改密碼等個人中心的功能；
• 在工作中，需要處理的事情散落在各頁面，用戶可以有一個工作臺，集中展示個人相關的待辦項；
• 用戶可能關注很多項內容，最好能在一個頁面展示用戶感興趣的內容概覽，減少切換，提供可自定義的儀表盤；
• 每個需求會關聯需求文檔，以及項目過程中需要文檔的共享協作，提供集中展示文檔的功能；
• 用戶想及時得到迭代、需求、缺陷的更新消息，方便跟進，提供消息通知功能；
• TAPD服務多家公司，那么各家公司的需求會存在差異性，需要做到很強的可配置化來支持差異化需求。

根據上述場景的需求，獲取到系統一級用例，和業務用例合并到一起，如圖2。

• 系統管理員，需要創建公司才能使用該系統，由他管理公司；需要維護組織架構，由他管理部門；需要控制公司成員的權限，由他管理系統用戶組；需要配置系統以實現差異化的功能，由他管理系統配置。
• 項目經理，每個項目的成員不同，也需要進行權限管理，由他管理項目用戶組。
• 每個用戶，為了提高系統的可用性和易用性，引入工作臺、儀表盤、文檔管理、消息通知、個人中心。

圖2 系統用例

3. 主流程分析

主流程就是按某種邏輯把用例組合起來，驗證是否可以實現業務目標。得到主流程可以對系統有全局的認知，也能輔助后續的對象分析。

經過分析，主流程有三個分支，如圖3。

管理公司主流程，主要是創建公司并邀請成員加入公司：

1. 系統管理員在管理公司模塊創建公司并邀請成員；
2. 用戶在個人中心模塊注冊賬號并接受公司邀請；
3. 系統管理員在管理部門模塊創建部門并關聯成員；
4. 系統管理員在管理系統用戶組模塊創建系統用戶組并關聯成員；
5. 系統管理員配置一些系統參數。

項目實施主流程，主要是創建項目并邀請成員加入項目，然后在項目中創建迭代、需求、缺陷，最終完成需求和修復缺陷：

1. 項目經理在管理項目模塊中創建項目并邀請成員；
2. 項目經理在管理項目用戶組模塊中創建項目用戶組并關聯成員；
3. 項目經理創建迭代和規劃迭代；
4. 項目成員在需求管理模塊中創建需求和完成需求；
5. 項目成員在缺陷管理模塊中創建缺陷和修復缺陷；
6. 項目經理查看需求看板和報表跟進迭代進度；
7. 項目經理定期發布項目報告。

用戶日常辦公主流程，主要是用戶日常登錄系統后處理自己相關的工作：

1. 用戶在個人中心模塊進行登錄進入系統；
2. 在工作臺查看待辦項并進行處理；
3. 在儀表板查看概況；
4. 在文檔管理中創建文檔；
5. 在消息通知中查看需求、缺陷更新等消息。

圖3 主流程

4. 對象分析

神盾局特工第四季里有一個概念是虛擬數字世界：框架（Framework），看過的朋友就很容易理解：軟件系統就是在計算機世界模擬現實世界，現實世界中的物體會映射成計算機世界里的對象。

這里使用面向對象分析方法（OOA），也是《大象Thinking in UML》中的分析步驟之一，意圖是將現實世界中的物體映射成計算機世界中的對象，在系統中使用這些對象去解決需求。比如分析對象需要哪些屬性和功能來解決需求，在后續的步驟會詳細分析這些對象。

獲取到主要的對象，還可以幫助我們對系統有整體的認知。從以上的用例和主流程中進行抽象，獲得以下對象：

• 管理公司主流程：公司、部門、系統用戶組；
• 項目實施主流程：項目、項目用戶組、迭代、需求白板、報表、項目報告、需求、缺陷；
• 用戶辦公主流程：用戶、工作臺、儀表盤、文檔、消息。

將以上對象，按照相關性進行分類，并簡單梳理對象之間的關系，即一對一、一對多、多對多。

此處的對象關系圖主要用于了解系統全局，所以對象之間關系和圖例沒有很標準，如圖4。

圖4 對象圖

二、系統詳細分析

系統詳細分析，分析粒度變小，保持在增刪改查功能的粒度，目的是獲得全部系統用例。

• 第一節，把系統全局分析里的用例進行細化，即用例流程分析，可以發現基本的二級用例；
• 第二節，搜集所有的二級用例，即在流程中體現的功能以外，再補充必要的其他二級用例；
• 第三節，為了滿足高可配置化，還需要引入配置對象，例如項目模板；
• 第四節，我稱為三級用例，主要是找到配置對象的用例，例如創建項目模板，以滿足配置需求。

1. 用例流程分析

用例流程就是用例的實現方式，是常用的需求細化方法，即細化上述一級用例的粒度。流程分析的目的是可以從中發現下級用例，現在開始分析流程。

1）管理公司流程，如圖5左一

• 系統管理員：①創建公司，②創建部門，③創建系統用戶組，④系統配置，⑤邀請成員加入公司；
• 用戶：⑥注冊賬號，⑦接受邀請加入公司。

2）管理項目流程，如圖5左二

• 項目經理：①創建項目，②創建項目用戶組，③邀請成員加入項目；
• 用戶：④已是公司成員的用戶可自動加入項目，⑤未加入公司的用戶需要注冊后接受邀請加入公司和項目。

3）管理迭代流程，如圖5左三

項目經理：①創建迭代，②規劃迭代，③跟進迭代進度，④完成迭代。

圖5 管理公司、項目、迭代流程

4）管理需求流程，如圖6

• 產品經理：①創建需求，②設計需求，⑧需求驗收通過可關閉需求，否則回退給開發工程師；
• UI設計師：③UI設計，⑦設計驗收通過流傳給產品經理驗收，否則回退給開發工程師；
• 開發工程師：④代碼開發；
• 測試工程師：⑤測試，⑥測試通過流轉給UI設計師驗收，否則回退給開發工程師。

圖6 管理需求流程

5）管理缺陷流程，如圖7左一

• 測試工程師：①創建缺陷，③缺陷驗收通過可關閉缺陷，否則回退給開發工程師；
• 開發工程師：②修復缺陷。

6）報表流程，如圖7左二

項目經理：①查詢項目、迭代中的需求和缺陷報表，②保存報表，③導出報表。

7）需求看板流程，如圖7左三

項目經理：①查詢迭代的需求白板，②移動需求狀態。

8）項目報告流程，如圖7左四

項目經理：①創建項目報告，②保存草稿，③發送項目報告。

圖7 缺陷、報表、需求看板、項目報告流程

9）工作臺流程，如圖8左一

用戶：①查看待辦項，②查看已辦項。

10）儀表盤流程如圖8左二

用戶：①編輯儀表盤內容，②編輯儀表盤布局。

11）文檔流程，如圖8左三

用戶：①創建文檔，②保存文檔，③邀請協作者。

12）消息流程，如圖8左四

• 系統：①觸發發送消息；
• 用戶：②查看消息。

圖8 工作臺、儀表盤、文檔、消息流程

2. 二級用例

完成流程分析后，已經獲得一部分細化的二級用例，但對于整個系統的閉環還是不夠的，這節就補充完善二級用例。

現在獲取的用例粒度，保持在主要對象的增刪改查即可。

獲取二級用例從兩個角度分析。

一是從上述的流程中進行提取用例；二是專注分析的對象，然后圍繞該對象設想一些場景以獲得需求，例如刪除、導出、打印、批量處理等在流程中找不到的需求。

開始獲取二級用例。

1）管理公司二級用例，如圖9

• 公司，補全增查改、注銷公司，和關聯成員的用例：邀請成員、查看成員、移除成員；
• 部門，補全增查改刪，和關聯成員的用例：成員加入部門、查看成員、成員移出部門；
• 系統用戶組，補全增查改刪、配置權限，和關聯成員的用例：成員加入用戶組、查看成員、成員移出用戶組。

圖9 管理公司二級用例

2）管理項目二級用例，如圖10

• 項目，補全增查改、結束項目，和關聯成員的用例：邀請成員、查看成員、移除成員；
• 項目用戶組，補全增查改刪、配置權限，和關聯成員的用例：成員加入用戶組、查看成員、成員移出用戶組；
• 迭代，補全增查改、關閉迭代、規劃迭代，和導出需求：導出迭代；
• 需求，補全增查改刪，還需考慮需求的日常操作：移動需求、復制需求、關聯父/子需求、關聯迭代、流轉需求、導出需求、導入需求、打印需求、分享需求、關注需求，以及批量操作需求：批量編輯需求、批量狀態流轉、批量移動、批量復制、批量刪除、批量修改父需求、批量分享；
• 缺陷，補全增查改刪，還需考慮缺陷的日常操作：移動缺陷、復制缺陷、關聯迭代、關聯需求、流轉缺陷、導出缺陷、導入缺陷、打印缺陷、分享缺陷、關注缺陷，以及批量操作需求：批量編輯缺陷、批量狀態流轉、批量移動、批量復制、批量刪除、批量分享；
• 需求白板，支持兩種查看方式：查看迭代需求狀態、查看人員的迭代需求狀態；
• 報表，支持查看需求報表、查看缺陷報表、保存報表、導出報表；
• 項目報告，補全增查改刪、保存草稿、復制項目報告。

圖10 管理項目二級用例

3）用戶辦公二級用例，如圖11

• 用戶，支持用戶的常規操作：注冊、登錄、退出登錄、修改密碼、找回密碼、查看個人詳情、編輯資料、注銷賬戶，以及和公司的關聯關系：接受公司邀請、退出公司、切換公司；
• 工作臺，支持查詢我的待辦、查詢我的已辦、查詢我創建的、查詢我關注的、查詢最近瀏覽的、全局查詢；
• 儀表盤，可查看工作卡片、查看迭代概覽卡片、查看需求卡片、查看缺陷卡片、查看報表卡片，以及配置卡片：添加卡片、編輯卡片布局、刪除卡片、卡片內容設置
• 文檔，補全增查改刪，以及考慮文檔的日常操作：發布到項目、邀請協作者、移動、復制、上傳、下載、關注、分享，還有批量操作需求：批量刪除、批量移動文件夾；
• 消息，支持自動觸發并發送消息、消息提醒、查看消息、刪除消息。

圖11 用戶辦公二級用例

3. 補充對象

以上的二級用例，基本已經解決業務的需求，業務可以閉環流轉了。但還需要考慮一些非功能性需求，例如系統的配置需求、安全需求等。

TAPD提供的是SaaS服務，使用一套系統服務所有客戶，就需要提供強大的配置化功能，以滿足不同客戶的個性化需求。

從之前獲取到的對象進行分析，聚焦每個對象的場景，得到以下對象有強烈的可配置化需求，并提取補充對象，如圖12。

• 項目，①每個項目都有大量的配置內容，為了簡化創建項目的設置工作，引入項目模板；②查詢項目列表時，根據需要進行自定義可展示的字段，引入列表顯示字段；
• 迭代，①創建迭代時，不同迭代類型的字段項可能不同，引入創建頁模板；②在創建頁模板中添加的字段需要維護，引入自定義字段；③查詢迭代列表時，可以按條件快速過濾數據和自定義展示字段，引入列表視圖；
• 需求，①創建需求時，不同需求類型的字段項可能不同，引入創建頁模板；②在創建頁模板中添加的字段需要維護，引入自定義字段；③不同需求類型的工作流可能不同，引入工作流；④工作流中的狀態需要維護，引入狀態；⑤創建需求時，將創建頁模板和工作流組合在一起，引入需求類別；⑥查詢需求列表時，可以按條件快速過濾數據和自定義展示字段，引入列表視圖；
• 缺陷，①創建缺陷時，不同缺陷類型的字段項可能不同，引入創建頁模板；②在創建頁模板中添加的字段需要維護，引入自定義字段；③不同缺陷類型的工作流可能不同，引入工作流；④工作流中的狀態需要維護，引入狀態；⑤查詢缺陷列表時，可以按條件快速過濾數據和自定義展示字段，引入列表視圖；
• 項目報告，①創建項目報告時，需要展示的內容是有規律的，只是時間范圍不同，為簡化發布項目報告，引入項目報告模板；
• 儀表盤，①用戶想自定義個性化的儀表盤，引入卡片；
• 消息，①配置消息的觸發條件，引入消息事件。

圖12 補充對象

4. 三級用例

得到補充對象后，就繼續分析以上對象的用例，這樣就完成該粒度層次的分析。

三級用例粒度是補充對象的增查改刪，例如創建項目模板，是創建補充對象供上級對象調用，達到配置的目標。

該粒度的用例比較有規律，大概有創建、查詢、編輯、 刪除、復制、排序、啟用、默認等功能。

如圖13，列出了補充對象的用例。

圖13 補充對象的三級用例

三、系統原型設計

系統原型設計，分析粒度變小，保持在頁面和元件交互，目的是獲得可交付的原型和標注。

在原型設計前，需要梳理功能清單，一來可以展示系統的全貌，二來可以了解工作量和分配各模塊的執行人。

1. 功能清單

功能清單就是把系統內容和用例按某種展現邏輯組織起來，而這種展示邏輯就是導航設計，所以在列功能清單前先進行導航設計，然后把用例放置到相應的的導航菜單中，即可完成功能清單。

在完成功能清單后，即完成產品規劃的部分，就可以按模塊分配給多名產品經理，設計各個模塊。

1）導航設計

參考三個主流程，管理公司、項目實施、用戶日常辦公。

可以發現，用戶日常辦公的功能使用頻率最高，因此工作臺、文檔、消息、個人中心，放在一級導航的位置，儀表盤和工作臺的性質比較相似，儀表盤合并到工作臺菜單下，并且儀表盤是概覽卡片的聚合頁，可以充當登錄系統后的首頁。

在項目實施主流程中，迭代、需求、缺陷等都歸屬于某個項目下，所以項目是一級導航，流程中的其他模塊，迭代、需求、缺陷、需求白板、報表、文檔、設置就放在項目下的二級導航，還有一個項目報告，就合并到報表中。

公司管理也放置在一級導航中。如圖14。

圖14 導航菜單

2）功能清單

在導航菜單的框架下，按模塊填充二級用例和三級用例。例如需求管理的常規功能（二級用例）放在需求模塊中，而需求的配置功能（三級用例）放在項目設置的需求設置中，如圖15。

完整功能清單寫在騰訊文檔，請訪問https://docs.qq.com/sheet/DQXR1dndQY3B1c2Z4。

2. 原型設計

不知道各位是否有這樣的困擾，在原型設計時會有這樣的卡頓，例如查詢列表頁要展示什么字段、創建頁要展示什么字段，就有被打斷的感覺。

因此建議在開始原型設計之前，先根據對象的場景，分析對象的屬性。我個人習慣是先分析對象屬性再畫詳細的原型，這樣是比較順暢的。

1）對象屬性

分析對象屬性，并不是輕松的過程，每個屬性都有針對的場景。這里用“需求”這個對象舉例。

① 基礎信息

• ID，需求的唯一標識；
• 標題，需求的標題，用于概括需求內容，方便查找；
• 描述，需求的詳細描述，例如描述需求背景、解決方案等；
• 業務價值，指實現需求后的價值有多大，在規劃迭代時優先實現業務價值高的；
• 優先級，指需求的優先級，在規劃迭代時優先實現優先級高的需求；
• 規模，指需求的工作量，預測需要多少工時可以完成；
• 項目，需求所屬哪個項目；
• 迭代，需求所屬哪個迭代；
• 版本，需求所屬哪個版本；
• 模塊，需求所屬哪個模塊；
• 需求分類，用戶可自定義需求分類，用于區分不同類型的需求，例如用戶需求、代碼優化需求；
• 需求類別，不同的需求類別的配置項不同，即需求創建頁和工作流程不同，需求可以選擇使用哪個需求類別的配置；
• 父需求，需求的父需求是哪個；
• 子需求，需求的子需求是哪些；
• 缺陷，需求下關聯哪些缺陷；
• 狀態，需求流轉的狀態，例如需求設計、開發、測試等狀態；
• 評論，處理人可以在需求下進行評論留言；
• 附件，用于上傳需求規格說明書。

② 人員相關屬性

創建人、處理人、開發人員、抄送人。

③ 時間相關屬性

創建時間、預計開始時間、預計結束時間、最后修改時間、完成時間。

可以看出，屬性很多，靠自己想是行不通的，這也是分析行業系統的價值，把行業系統常用的對象和屬性學來，也就入門這項業務了。

其他主要對象的屬性寫在騰訊文檔，請訪問https://docs.qq.com/sheet/DQUlqa2JnR2puWUZm。

2）原型設計

最后進行原型設計，并進行文字標注，補充業務規則和交互規則等。

做PC web網頁設計時，這里推薦Element UI組件，記住常用的組件，會提高寫標注的效率。

為了體會TAPD的規則和交互，我也簡單還原了TAPD的標注，原型放在藍湖，請訪問https://lanhuapp.com/url/iXUNq。

【尾巴】

各位看官，由于是在現成的系統上進行分解推導，因此會存在一些上帝視角，有些用例和對象出現的邏輯沒有那么順暢，請大家見諒。另外，這些邏輯不順暢的點，可能就是此類系統的行業知識，當你見過之后，也就認識和學習了這個行業的業務知識。

感謝閱讀。

 

本文由 @王世翔 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議