編輯導(dǎo)語：騰訊TAPD，即騰訊敏捷產(chǎn)品研發(fā)，是常用的項(xiàng)目管理工具。那么，具體到設(shè)計(jì)層面，我們可以如何認(rèn)知這款工具？本篇文章里，作者從系統(tǒng)全局、詳細(xì)分析、原型設(shè)計(jì)三方面對騰訊TAPD的系統(tǒng)設(shè)計(jì)結(jié)構(gòu)進(jìn)行分析與拆解，一起來看一下。

騰訊TAPD官方簡介，TAPD 是Tencent Agile Product Development的縮寫，即：騰訊敏捷產(chǎn)品研發(fā)。提供貫穿敏捷研發(fā)生命周期的一站式服務(wù)，覆蓋從產(chǎn)品概念形成、產(chǎn)品規(guī)劃、需求分析、項(xiàng)目規(guī)劃和跟蹤、質(zhì)量測試到構(gòu)建發(fā)布、用戶反饋跟蹤的產(chǎn)品研發(fā)全生命周期。

此次本著學(xué)習(xí)的態(tài)度解構(gòu)騰訊TAPD（專業(yè)版），我是從TAPD的頁面和功能入手，逆向分析得到關(guān)鍵輸出物和原始需求，以此深入學(xué)習(xí)項(xiàng)目管理系統(tǒng)的業(yè)務(wù)。

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

1. 系統(tǒng)全局分析，分析粒度保持在模塊管理，目的是獲得系統(tǒng)的全局認(rèn)識；
2. 系統(tǒng)詳細(xì)分析，分析粒度變小，保持在增刪改查功能的粒度，目的是獲得全部系統(tǒng)用例；
3. 熟悉的系統(tǒng)原型設(shè)計(jì)，分析粒度變小，保持在頁面和元件交互，目的是獲得可交付的原型和標(biāo)注。

一、系統(tǒng)全局分析

系統(tǒng)全局分析，分析粒度保持在模塊管理，目的是獲得系統(tǒng)的全局認(rèn)識。

第一節(jié)是從業(yè)務(wù)的角度獲取需求和用例，第二節(jié)是從系統(tǒng)的角度獲取需求和用例，我稱這個(gè)粒度為一級用例，第三節(jié)和第四節(jié)是在前兩節(jié)的用例基礎(chǔ)上分析主流程和對象。

1. 業(yè)務(wù)用例

在軟件項(xiàng)目里，業(yè)務(wù)范圍和系統(tǒng)范圍是不同的。

業(yè)務(wù)范圍指這個(gè)項(xiàng)目所涉及的所有客戶業(yè)務(wù)，這些業(yè)務(wù)有沒有計(jì)算機(jī)系統(tǒng)參與都是客觀存在的。

系統(tǒng)范圍是指軟件將要實(shí)現(xiàn)的那些對應(yīng)于業(yè)務(wù)功能的系統(tǒng)功能，從功能性需求來說系統(tǒng)范圍是業(yè)務(wù)范圍的一個(gè)子集，但是一些系統(tǒng)功能則會超出業(yè)務(wù)范圍，例如操作日志，有沒有操作日志并不影響業(yè)務(wù)目標(biāo)的達(dá)成，客戶也不一定會提出這個(gè)要求，但從系統(tǒng)角度出發(fā)，操作日志會使得系統(tǒng)更加健壯。

——來自《大象Thinking in UML》

在引入計(jì)算機(jī)系統(tǒng)之前，業(yè)務(wù)也一直跑得很順暢，因此在初始階段，不引入系統(tǒng)的角度，純粹站在業(yè)務(wù)的角度，分析業(yè)務(wù)的主流程場景，獲取業(yè)務(wù)用例。

獲取業(yè)務(wù)用例需要分析出業(yè)務(wù)主角和用例，業(yè)務(wù)主角即參與到業(yè)務(wù)流程中的角色，例如項(xiàng)目經(jīng)理、產(chǎn)品經(jīng)理等。

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

開始獲取業(yè)務(wù)用例，以下是一段項(xiàng)目實(shí)施過程的場景。

某一天，領(lǐng)導(dǎo)分配給項(xiàng)目經(jīng)理一個(gè)新項(xiàng)目，于是，項(xiàng)目經(jīng)理召集產(chǎn)品組長、設(shè)計(jì)組長、開發(fā)組長、測試組長簡單同步一下項(xiàng)目信息，表示要啟動(dòng)該項(xiàng)目。

會后項(xiàng)目經(jīng)理創(chuàng)建一個(gè)群聊，把項(xiàng)目成員拉到群聊中，同步項(xiàng)目信息。

開工前，項(xiàng)目經(jīng)理簡單制定了計(jì)劃：產(chǎn)品經(jīng)理收集需求，產(chǎn)品組長評估需求的優(yōu)先級，并規(guī)劃成多個(gè)迭代實(shí)施，確定迭代范圍后，產(chǎn)品組長、設(shè)計(jì)組長、開發(fā)組長、測試組長分別進(jìn)行人員安排。

確定迭代的需求范圍后，接下來就是需求的流轉(zhuǎn)，產(chǎn)品經(jīng)理完成需求設(shè)計(jì)，UI設(shè)計(jì)師完成UI設(shè)計(jì)，開發(fā)工程師完成編碼，測試工程師完成需求測試，最后產(chǎn)品經(jīng)理驗(yàn)證需求并關(guān)閉需求。

測試工程師在測試的過程中會提出bug單，交由開發(fā)工程師進(jìn)行修復(fù)。項(xiàng)目經(jīng)理對每個(gè)迭代負(fù)責(zé)，在迭代過程中，每天組織晨會，使用需求看板同步進(jìn)度。

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

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

• 項(xiàng)目經(jīng)理是項(xiàng)目的啟動(dòng)者，由他管理項(xiàng)目；在項(xiàng)目實(shí)施中對每個(gè)迭代負(fù)責(zé)，由他管理迭代；定期在需求看板上同步進(jìn)度，由他管理需求看板；定期查看報(bào)表了解迭代數(shù)據(jù)，他需要查看報(bào)表；定期整理項(xiàng)目報(bào)告進(jìn)行匯報(bào)，他需要管理項(xiàng)目報(bào)告。
• 產(chǎn)品經(jīng)理是需求的提出者，且會進(jìn)行需求設(shè)計(jì)，由他管理需求。
• 設(shè)計(jì)師是需求的設(shè)計(jì)者，參與需求的UI設(shè)計(jì)工作，屬于需求中的一個(gè)步驟。
• 開發(fā)工程師是需求的代碼實(shí)現(xiàn)者，參與需求的代碼編碼工作；當(dāng)系統(tǒng)出現(xiàn)bug的時(shí)候，他需要參與bug的修復(fù)工作。
• 測試工程師是需求的測試者，參與需求的測試工作；當(dāng)測試出bug的時(shí)候，會提出bug單，由他管理bug。注：在TAPD中使用“缺陷”來表示bug，后文也會沿用缺陷這個(gè)詞。

圖1 業(yè)務(wù)用例

2. 系統(tǒng)用例

得到業(yè)務(wù)用例后，雖然能看到業(yè)務(wù)主流程的雛形，但要完成系統(tǒng)的閉環(huán)還需要站在系統(tǒng)的角度去補(bǔ)充用例，例如系統(tǒng)權(quán)限管理的需求，業(yè)務(wù)用例中并沒有體現(xiàn)出來。

系統(tǒng)用例也是需要獲得角色和用例，這個(gè)階段的用例粒度和上一步驟的業(yè)務(wù)用例保持一致，即管理一類事物。

開始獲取系統(tǒng)用例，我站在系統(tǒng)的角度，從三個(gè)方向分析系統(tǒng)需求

1. 系統(tǒng)管理的需求；
2. 系統(tǒng)易用性的需求；
3. 系統(tǒng)擴(kuò)展性的需求。

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

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

根據(jù)上述場景的需求，獲取到系統(tǒng)一級用例，和業(yè)務(wù)用例合并到一起，如圖2。

• 系統(tǒng)管理員，需要?jiǎng)?chuàng)建公司才能使用該系統(tǒng)，由他管理公司；需要維護(hù)組織架構(gòu)，由他管理部門；需要控制公司成員的權(quán)限，由他管理系統(tǒng)用戶組；需要配置系統(tǒng)以實(shí)現(xiàn)差異化的功能，由他管理系統(tǒng)配置。
• 項(xiàng)目經(jīng)理，每個(gè)項(xiàng)目的成員不同，也需要進(jìn)行權(quán)限管理，由他管理項(xiàng)目用戶組。
• 每個(gè)用戶，為了提高系統(tǒng)的可用性和易用性，引入工作臺、儀表盤、文檔管理、消息通知、個(gè)人中心。

圖2 系統(tǒng)用例

3. 主流程分析

主流程就是按某種邏輯把用例組合起來，驗(yàn)證是否可以實(shí)現(xiàn)業(yè)務(wù)目標(biāo)。得到主流程可以對系統(tǒng)有全局的認(rèn)知，也能輔助后續(xù)的對象分析。

經(jīng)過分析，主流程有三個(gè)分支，如圖3。

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

1. 系統(tǒng)管理員在管理公司模塊創(chuàng)建公司并邀請成員；
2. 用戶在個(gè)人中心模塊注冊賬號并接受公司邀請；
3. 系統(tǒng)管理員在管理部門模塊創(chuàng)建部門并關(guān)聯(lián)成員；
4. 系統(tǒng)管理員在管理系統(tǒng)用戶組模塊創(chuàng)建系統(tǒng)用戶組并關(guān)聯(lián)成員；
5. 系統(tǒng)管理員配置一些系統(tǒng)參數(shù)。

項(xiàng)目實(shí)施主流程，主要是創(chuàng)建項(xiàng)目并邀請成員加入項(xiàng)目，然后在項(xiàng)目中創(chuàng)建迭代、需求、缺陷，最終完成需求和修復(fù)缺陷：

1. 項(xiàng)目經(jīng)理在管理項(xiàng)目模塊中創(chuàng)建項(xiàng)目并邀請成員；
2. 項(xiàng)目經(jīng)理在管理項(xiàng)目用戶組模塊中創(chuàng)建項(xiàng)目用戶組并關(guān)聯(lián)成員；
3. 項(xiàng)目經(jīng)理創(chuàng)建迭代和規(guī)劃迭代；
4. 項(xiàng)目成員在需求管理模塊中創(chuàng)建需求和完成需求；
5. 項(xiàng)目成員在缺陷管理模塊中創(chuàng)建缺陷和修復(fù)缺陷；
6. 項(xiàng)目經(jīng)理查看需求看板和報(bào)表跟進(jìn)迭代進(jìn)度；
7. 項(xiàng)目經(jīng)理定期發(fā)布項(xiàng)目報(bào)告。

用戶日常辦公主流程，主要是用戶日常登錄系統(tǒng)后處理自己相關(guān)的工作：

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

圖3 主流程

4. 對象分析

神盾局特工第四季里有一個(gè)概念是虛擬數(shù)字世界：框架（Framework），看過的朋友就很容易理解：軟件系統(tǒng)就是在計(jì)算機(jī)世界模擬現(xiàn)實(shí)世界，現(xiàn)實(shí)世界中的物體會映射成計(jì)算機(jī)世界里的對象。

這里使用面向?qū)ο蠓治龇椒ǎ∣OA），也是《大象Thinking in UML》中的分析步驟之一，意圖是將現(xiàn)實(shí)世界中的物體映射成計(jì)算機(jī)世界中的對象，在系統(tǒng)中使用這些對象去解決需求。比如分析對象需要哪些屬性和功能來解決需求，在后續(xù)的步驟會詳細(xì)分析這些對象。

獲取到主要的對象，還可以幫助我們對系統(tǒng)有整體的認(rèn)知。從以上的用例和主流程中進(jìn)行抽象，獲得以下對象：

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

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

此處的對象關(guān)系圖主要用于了解系統(tǒng)全局，所以對象之間關(guān)系和圖例沒有很標(biāo)準(zhǔn)，如圖4。

圖4 對象圖

二、系統(tǒng)詳細(xì)分析

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

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

1. 用例流程分析

用例流程就是用例的實(shí)現(xiàn)方式，是常用的需求細(xì)化方法，即細(xì)化上述一級用例的粒度。流程分析的目的是可以從中發(fā)現(xiàn)下級用例，現(xiàn)在開始分析流程。

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

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

2）管理項(xiàng)目流程，如圖5左二

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

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

項(xiàng)目經(jīng)理：①創(chuàng)建迭代，②規(guī)劃迭代，③跟進(jìn)迭代進(jìn)度，④完成迭代。

圖5 管理公司、項(xiàng)目、迭代流程

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

• 產(chǎn)品經(jīng)理：①創(chuàng)建需求，②設(shè)計(jì)需求，⑧需求驗(yàn)收通過可關(guān)閉需求，否則回退給開發(fā)工程師；
• UI設(shè)計(jì)師：③UI設(shè)計(jì)，⑦設(shè)計(jì)驗(yàn)收通過流傳給產(chǎn)品經(jīng)理驗(yàn)收，否則回退給開發(fā)工程師；
• 開發(fā)工程師：④代碼開發(fā)；
• 測試工程師：⑤測試，⑥測試通過流轉(zhuǎn)給UI設(shè)計(jì)師驗(yàn)收，否則回退給開發(fā)工程師。

圖6 管理需求流程

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

• 測試工程師：①創(chuàng)建缺陷，③缺陷驗(yàn)收通過可關(guān)閉缺陷，否則回退給開發(fā)工程師；
• 開發(fā)工程師：②修復(fù)缺陷。

6）報(bào)表流程，如圖7左二

項(xiàng)目經(jīng)理：①查詢項(xiàng)目、迭代中的需求和缺陷報(bào)表，②保存報(bào)表，③導(dǎo)出報(bào)表。

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

項(xiàng)目經(jīng)理：①查詢迭代的需求白板，②移動(dòng)需求狀態(tài)。

8）項(xiàng)目報(bào)告流程，如圖7左四

項(xiàng)目經(jīng)理：①創(chuàng)建項(xiàng)目報(bào)告，②保存草稿，③發(fā)送項(xiàng)目報(bào)告。

圖7 缺陷、報(bào)表、需求看板、項(xiàng)目報(bào)告流程

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

用戶：①查看待辦項(xiàng)，②查看已辦項(xiàng)。

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

用戶：①編輯儀表盤內(nèi)容，②編輯儀表盤布局。

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

用戶：①創(chuàng)建文檔，②保存文檔，③邀請協(xié)作者。

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

• 系統(tǒng)：①觸發(fā)發(fā)送消息；
• 用戶：②查看消息。

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

2. 二級用例

完成流程分析后，已經(jīng)獲得一部分細(xì)化的二級用例，但對于整個(gè)系統(tǒng)的閉環(huán)還是不夠的，這節(jié)就補(bǔ)充完善二級用例。

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

獲取二級用例從兩個(gè)角度分析。

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

開始獲取二級用例。

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

• 公司，補(bǔ)全增查改、注銷公司，和關(guān)聯(lián)成員的用例：邀請成員、查看成員、移除成員；
• 部門，補(bǔ)全增查改刪，和關(guān)聯(lián)成員的用例：成員加入部門、查看成員、成員移出部門；
• 系統(tǒng)用戶組，補(bǔ)全增查改刪、配置權(quán)限，和關(guān)聯(lián)成員的用例：成員加入用戶組、查看成員、成員移出用戶組。

圖9 管理公司二級用例

2）管理項(xiàng)目二級用例，如圖10

• 項(xiàng)目，補(bǔ)全增查改、結(jié)束項(xiàng)目，和關(guān)聯(lián)成員的用例：邀請成員、查看成員、移除成員；
• 項(xiàng)目用戶組，補(bǔ)全增查改刪、配置權(quán)限，和關(guān)聯(lián)成員的用例：成員加入用戶組、查看成員、成員移出用戶組；
• 迭代，補(bǔ)全增查改、關(guān)閉迭代、規(guī)劃迭代，和導(dǎo)出需求：導(dǎo)出迭代；
• 需求，補(bǔ)全增查改刪，還需考慮需求的日常操作：移動(dòng)需求、復(fù)制需求、關(guān)聯(lián)父/子需求、關(guān)聯(lián)迭代、流轉(zhuǎn)需求、導(dǎo)出需求、導(dǎo)入需求、打印需求、分享需求、關(guān)注需求，以及批量操作需求：批量編輯需求、批量狀態(tài)流轉(zhuǎn)、批量移動(dòng)、批量復(fù)制、批量刪除、批量修改父需求、批量分享；
• 缺陷，補(bǔ)全增查改刪，還需考慮缺陷的日常操作：移動(dòng)缺陷、復(fù)制缺陷、關(guān)聯(lián)迭代、關(guān)聯(lián)需求、流轉(zhuǎn)缺陷、導(dǎo)出缺陷、導(dǎo)入缺陷、打印缺陷、分享缺陷、關(guān)注缺陷，以及批量操作需求：批量編輯缺陷、批量狀態(tài)流轉(zhuǎn)、批量移動(dòng)、批量復(fù)制、批量刪除、批量分享；
• 需求白板，支持兩種查看方式：查看迭代需求狀態(tài)、查看人員的迭代需求狀態(tài)；
• 報(bào)表，支持查看需求報(bào)表、查看缺陷報(bào)表、保存報(bào)表、導(dǎo)出報(bào)表；
• 項(xiàng)目報(bào)告，補(bǔ)全增查改刪、保存草稿、復(fù)制項(xiàng)目報(bào)告。

圖10 管理項(xiàng)目二級用例

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

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

圖11 用戶辦公二級用例

3. 補(bǔ)充對象

以上的二級用例，基本已經(jīng)解決業(yè)務(wù)的需求，業(yè)務(wù)可以閉環(huán)流轉(zhuǎn)了。但還需要考慮一些非功能性需求，例如系統(tǒng)的配置需求、安全需求等。

TAPD提供的是SaaS服務(wù)，使用一套系統(tǒng)服務(wù)所有客戶，就需要提供強(qiáng)大的配置化功能，以滿足不同客戶的個(gè)性化需求。

從之前獲取到的對象進(jìn)行分析，聚焦每個(gè)對象的場景，得到以下對象有強(qiáng)烈的可配置化需求，并提取補(bǔ)充對象，如圖12。

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

圖12 補(bǔ)充對象

4. 三級用例

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

三級用例粒度是補(bǔ)充對象的增查改刪，例如創(chuàng)建項(xiàng)目模板，是創(chuàng)建補(bǔ)充對象供上級對象調(diào)用，達(dá)到配置的目標(biāo)。

該粒度的用例比較有規(guī)律，大概有創(chuàng)建、查詢、編輯、 刪除、復(fù)制、排序、啟用、默認(rèn)等功能。

如圖13，列出了補(bǔ)充對象的用例。

圖13 補(bǔ)充對象的三級用例

三、系統(tǒng)原型設(shè)計(jì)

系統(tǒng)原型設(shè)計(jì)，分析粒度變小，保持在頁面和元件交互，目的是獲得可交付的原型和標(biāo)注。

在原型設(shè)計(jì)前，需要梳理功能清單，一來可以展示系統(tǒng)的全貌，二來可以了解工作量和分配各模塊的執(zhí)行人。

1. 功能清單

功能清單就是把系統(tǒng)內(nèi)容和用例按某種展現(xiàn)邏輯組織起來，而這種展示邏輯就是導(dǎo)航設(shè)計(jì)，所以在列功能清單前先進(jìn)行導(dǎo)航設(shè)計(jì)，然后把用例放置到相應(yīng)的的導(dǎo)航菜單中，即可完成功能清單。

在完成功能清單后，即完成產(chǎn)品規(guī)劃的部分，就可以按模塊分配給多名產(chǎn)品經(jīng)理，設(shè)計(jì)各個(gè)模塊。

1）導(dǎo)航設(shè)計(jì)

參考三個(gè)主流程，管理公司、項(xiàng)目實(shí)施、用戶日常辦公。

可以發(fā)現(xiàn)，用戶日常辦公的功能使用頻率最高，因此工作臺、文檔、消息、個(gè)人中心，放在一級導(dǎo)航的位置，儀表盤和工作臺的性質(zhì)比較相似，儀表盤合并到工作臺菜單下，并且儀表盤是概覽卡片的聚合頁，可以充當(dāng)?shù)卿浵到y(tǒng)后的首頁。

在項(xiàng)目實(shí)施主流程中，迭代、需求、缺陷等都?xì)w屬于某個(gè)項(xiàng)目下，所以項(xiàng)目是一級導(dǎo)航，流程中的其他模塊，迭代、需求、缺陷、需求白板、報(bào)表、文檔、設(shè)置就放在項(xiàng)目下的二級導(dǎo)航，還有一個(gè)項(xiàng)目報(bào)告，就合并到報(bào)表中。

公司管理也放置在一級導(dǎo)航中。如圖14。

圖14 導(dǎo)航菜單

2）功能清單

在導(dǎo)航菜單的框架下，按模塊填充二級用例和三級用例。例如需求管理的常規(guī)功能（二級用例）放在需求模塊中，而需求的配置功能（三級用例）放在項(xiàng)目設(shè)置的需求設(shè)置中，如圖15。

完整功能清單寫在騰訊文檔，請?jiān)L問https://docs.qq.com/sheet/DQXR1dndQY3B1c2Z4。

2. 原型設(shè)計(jì)

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

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

1）對象屬性

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

① 基礎(chǔ)信息

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

② 人員相關(guān)屬性

創(chuàng)建人、處理人、開發(fā)人員、抄送人。

③ 時(shí)間相關(guān)屬性

創(chuàng)建時(shí)間、預(yù)計(jì)開始時(shí)間、預(yù)計(jì)結(jié)束時(shí)間、最后修改時(shí)間、完成時(shí)間。

可以看出，屬性很多，靠自己想是行不通的，這也是分析行業(yè)系統(tǒng)的價(jià)值，把行業(yè)系統(tǒng)常用的對象和屬性學(xué)來，也就入門這項(xiàng)業(yè)務(wù)了。

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

2）原型設(shè)計(jì)

最后進(jìn)行原型設(shè)計(jì)，并進(jìn)行文字標(biāo)注，補(bǔ)充業(yè)務(wù)規(guī)則和交互規(guī)則等。

做PC web網(wǎng)頁設(shè)計(jì)時(shí)，這里推薦Element UI組件，記住常用的組件，會提高寫標(biāo)注的效率。

為了體會TAPD的規(guī)則和交互，我也簡單還原了TAPD的標(biāo)注，原型放在藍(lán)湖，請?jiān)L問https://lanhuapp.com/url/iXUNq。

【尾巴】

各位看官，由于是在現(xiàn)成的系統(tǒng)上進(jìn)行分解推導(dǎo)，因此會存在一些上帝視角，有些用例和對象出現(xiàn)的邏輯沒有那么順暢，請大家見諒。另外，這些邏輯不順暢的點(diǎn)，可能就是此類系統(tǒng)的行業(yè)知識，當(dāng)你見過之后，也就認(rèn)識和學(xué)習(xí)了這個(gè)行業(yè)的業(yè)務(wù)知識。

感謝閱讀。

本文由 @王世翔?原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議