【IPD流程學習 三】模板詳述

上一篇blog可謂IPD最爲核心的部分，也就是IPD的主要流程，在上篇博客中我詳細介紹了IPD的各個核心階段以及每個核心階段的細緻流程、參與人員、每個人的具體職責，那麼相信大家對整體的流程以及流程對IPD理念的實踐和要解決什麼問題都比較清楚了，新的研發流程下和舊的相比就有很多的優勢：

本篇博客介紹IPD的主要模塊，也就是涉及到的一些模板：

其中比較核心的是：項目計劃（管理）、PRD、技術架構和一頁紙四個模板，除了這幾個之外還有一些評審的模板。當然並不要求每一個都按照模板來做，但可以參考其中的理念，更多提供的是方法論。

項目管理

主要編寫人是項目經理，主要包含以下幾個部分：項目組成員、項目關鍵文檔、項目計劃、重要溝通、風險管理、重要變更。

• 項目組成員必須記錄，因爲一個項目組的成員可能來自各個資源池，所以需要有一定的標準，包括定義這個成員的：職位、姓名、投入工作量、工作內容和主管經理
• 項目關鍵文檔需要標識這個文檔的：分類、文檔名稱、描述、創建時間、輸入方/作者、鏈接，這幾個關鍵要素
• 項目計劃也是必須的，並且需要詳細記錄任務的進度和狀態：
  
• 重要溝通表示在項目過程中的一些重大問題的記錄，包含：溝通工作、負責人、參與人、時間、計劃目標、成果這幾個比較重要的方面
• 風險管理在之前是比較缺失或者不透明的，現在需要加緊建設，包括：風險定義、風險類別、風險原因、風險影響範圍、風險級別、處理方式、解決狀態幾個方面
• 需求變更標記需求的一些變化，也是必須要記錄的，包含以下幾個方面：類型、問題 、目的 、提出者、 提出時間、 影響、 優先級、 狀態、 解決方式 、結果 、解決時間 、解決過程這幾個方面。

其中項目組成員、項目計劃和需求變更是比較重要的幾點。當然還有一些週報的模板：

以及項目會議記錄的模板可以參考：

除去以上8八部分之外，再加個封面就是一個完整的九部分的項目計劃書了，項目經理可以據此hold整個項目。除此之外，建議項目經理再做一個項目計劃（kick off）的PPT來增強儀式感。

產品設計PRD

產品設計模塊包括：產品架構設計PRD、產品概要設計PRD、產品詳細設計PRD三部分，三部分從前往後由大到小，負責度由高到低，使用頻率由低到高。

• 產品架構設計PRD使用的比較少且複雜，如果不是特別大的項目簡單做一下即可。一般使用和製作者都是比較高級的產品經理甚至產品專家。
• 產品需求設計PRD是我們最常用的一個模板，是一個相對整體性的設計，包含整個項目中涉及到的全部需求和場景分析，是一個比較整體性的設計。
• 產品模塊設計PRD是某個單story的模板，是在產品需求設計PRD拆分出來的模塊的具體設計，是針對單模塊的比較細緻的設計。

瞭解了整體的三個PRD的關係，接下來詳細瞭解下這是三個常用PRD的結構

產品架構設計PRD

產品架構設計PRD我感覺更多的是形而上的東西，更側重在整體的流程、配合方式、架構方式等，並不是細緻的內容，所以一些簡單stroy或者項目不需要這部分。

步驟	子模塊	子模塊內容
1	文檔控制	包含變更記錄部分內容 ,控制整體產品節奏
2	概述	產品概述及目標、產品roadmap，詳細目標規劃
3	產品架構	產品的整體架構設計
4	使用者需求	使用者角色、主要流程與描述
5	交互體驗框架性需求	主設計基調、整體設計是怎麼樣的，對用戶體驗的目標進行描述
6	功能需求	也就是通俗意義上的功能細節需求
7	業務數據	每個模塊的詳細業務數據
8	系統架構性體系	系統的整體架構設計
9	各部分設計文檔清單	涉及到的各個部分文檔清單彙總
10	測試需求	說明是否需要BETA測試，BETA測試的要求及期望達到的目標等
11	非功能需求	產品營銷需求、規則變更需求、產品服務需求、法務需求、幫助需求、安全性需求
12	上下線需求	上線時限需求、下線需求（活動類需求必須明確下線時間）
13	效益成本分析	效益預測、產品技術中心成本、非產品技術中心的支持成本

非功能需求的一些說明：

• 產品營銷需求（說明使用的推廣方式、目標受衆以及是否有限制或特殊要求？ (網站運營部應提供主要內容）
• 規則變更需求（本產品可能涉及到的規則的變更）
• 產品服務需求（產品上線是否需要客服協助？此產品計劃的服務優先級和重要性如何？當此產品上線後，想要從客服中得到什麼信息？）
• 法務需求（說明與隱私權、知識產權、專利權、商標、服務條款(TOS)、版權、合同責任、客戶溝通等相關之法務議題或需求）
• 幫助需求（提供內部使用者或者客戶在使用此產品時所需要的任何說明文件或幫助，比如線上幫助、CRM知識庫、FAQ等）
• 安全性需求（產品需符合網絡安全部的相關規定）

這幾類需求比較詳細，記錄下說不定以後可以用到。

產品概要設計PRD

產品需求設計PRD是一個項目中整體需求的分析，總模塊的介紹，需要注意裏邊最好設置產品的版本和版本基線。

步驟	子模塊	子模塊內容
1	文檔控制	包含變更記錄部分內容 ,控制整體產品節奏
2	概述	背景、目標、模塊規劃、產品基線、產品風險
3	關聯文檔	描述和產品規劃、MM、需求相關（如MRD）、運營文檔、產品Proposal相關的文檔
4	使用者需求	從使用者的業務場景描述使用者身份，身份描述。需求場景，需求流程圖，以及詳細需求描述
5	功能需求	身份描述、功能總覽、業務數據描述 、功能權限表、功能詳情
6	非功能需求	性能需求、幫助需求、安全性需求、報表需求、數據運營需求
7	上線運維需求	上線的一些運維策略

其中概述部分內容的詳細規劃如下：

• 背景：闡述本次設計的背景和原因，包括問題
• 目標：闡述本次設計的目標，包括客戶價值、特性，解決的問題等，大致場景，或者滿足產品規劃等
• 模塊規劃：闡述可能的階段和階段規劃
• 產品基線：闡述本設計基於的產品版本基線
• 產品風險：闡述產品風險）

其中使用者需求部分內容的詳細規劃如下：

• 用戶與組織範圍：對組織範圍、用戶進行描述
• 業務流程與需求：對業務需求進行描述，可以包括流程圖，流程描述，輸入輸出等
• 業務模型：使用流程圖、Use Case等工具描述業務需求

如果把數據關係等做紮實，那麼以後調整花費的時間就不需要那麼多了。

產品詳細設計PRD

這一份story級別的PRD實際上是上面 一份的PRD的子模塊：

步驟	子模塊	子模塊內容
1	文檔控制	包含變更記錄部分內容 ,控制整體產品節奏
2	業務場景或問題來源	爲什麼要做這個特性？描述客戶業務場景，或需求的問題來源
3	目標	支持哪些場景、哪些功能、實現的效果；以及此特性給客戶帶來的價值
4	產品解決方案	最核心的部分，包含產品的整體解決方案
5	上線準備事項	上線的時候需要準備的一些工作 ，需要平臺協助的內容、以及實施需要對租戶進行相關配置的事項

對於產品解決方案有必要詳細闡述一下，以下幾個過程比較重要，在做產品設計的時候需要通盤考慮一下：

• 業務流程及業務模型，業務流程指用戶日常處理該業務的流程，一般用語言文字或流程圖描述，業務模型指產品使用過程中需要完成的各種任務的流程，一般用泳道圖或流程圖描述
• 原型/交互：關於頁面交互操作的詳細描述，可以是示意圖、或原型
• 數據結構：領域對象（業務視角）、字段的詳細描述
• 產品規則：描述功能的詳細業務處理規則、校驗規則等
• 關聯繫統或者功能影響：與其它產品的交互和對接
• 接口相關設計：對接口的影響，包含讀取、同步、回寫、拉取接口
• 數據相關設計：原有業務數據的修復升級規則等需求
• 非功能需求：性能相關需求，運營、埋點相關需求

以上就是整體的需求設計和分析。比較好的使用方式是在wiki上建立好相關的目錄結構，大家一起來維護一下。

技術架構設計

技術架構設計需要和產品架構設計及業務架構設計結合比較好一些，整體的目錄結構如下，技術設計的時候需要考慮這些點：

步驟	子模塊	子模塊內容
1	引言	包含背景、目標、術語與縮略語、參考資料
2	整體範圍	包含功能需求、需求邊界是明確執行範圍的邊界，階段內應做什麼，不做什麼
3	總體設計	包含架構設計目標、技術及設計約束、領域建模、架構設計、業務流程設計
4	接口設計	包含系統外部接口、系統內部接口
5	數據架構	包含數據模型、數據存儲
6	非功能設計	包含性能、可靠性、安全性、可維護性
7	關鍵技術設計	包含技術選型、技術預研、風險識別與防範
8	部署架構	包含系統部署，網絡拓撲，服務器要求等。
9	其它說明	補充上述未列出事項的描述。比如需要其他系統支持配合等情況說明

技術一頁紙

技術一頁紙需要考慮的很詳細，我個人也非常喜歡寫技術一頁紙，提前可以規避很多坑，整體的目錄結構如下，技術設計的時候需要考慮這些點：

步驟	子模塊	子模塊內容
1	業務流程圖	實現流程、時序以及輸入輸出
2	詳細設計	技術詳細設計，包括領域模塊、類間調用關係
3	影響點評估	對現有業務的影響點評估
4	工作量評估	到人天

另外還有對應的測試一頁紙方案，這裏就不詳細說明了。

總結

本篇blog詳細介紹了四個比較重要的模板，包括：項目規劃、產品設計、技術架構、技術落地一頁紙，其中產品設計又依據複雜度分爲三個模板。當然除此之外還有一些我們平時用不上或者不怎麼需要了解的模板，例如評審的模板（架構與概要設計評審、技術架構評審、詳細設計評審、一頁紙方案的評審）這裏就不一一詳述了。感覺整體的模板還是比較龐大的，初期接入一定會有不舒適感，覺得要填的東西太多了，但是規範化後，雖然繁雜一些，但會變得更清晰，系統的龐大必然需要流程的規範，這樣系統纔會穩定。不再盲目的打補丁！