1. 需求流程的常見問題

問題1：反饋需求的渠道太多，難以集中管理

如果團隊沒有使用協(xié)作平臺，一般會采用多人在線編輯的文檔，在IM聊天工具中進行協(xié)同編輯。這種方法在短期的協(xié)作中是非常高效的，但是隨著業(yè)務(wù)的發(fā)展，客戶的增多，這種協(xié)同文檔也會越來越多，給提需求的人和承接需求的人都帶來了困擾，他們不清楚應(yīng)該在哪一個文檔中管理需求，并且由于創(chuàng)建文檔非常的方便，團隊成員很容易創(chuàng)建新的文檔來管理需求，這樣會讓整體的管理越來越糟糕，舊的文檔中的需求便沒有人再關(guān)注了。

即使團隊使用了協(xié)作工具平臺，如果缺少流程規(guī)范，也很容易出現(xiàn)類似的問題，產(chǎn)品經(jīng)理會發(fā)現(xiàn)平臺中有很多的需求池，收集需求和集中管理需求也非常的困難。

問題2：責(zé)權(quán)不明，需求長時間無人處理

需求的交付時間過長，是困擾很多團隊的問題，而在這個過程當(dāng)中我們發(fā)現(xiàn)并不一定是開發(fā)的時間長，而是需求長時間無人處理，一直處于停滯狀態(tài)。

出現(xiàn)這種問題的原因，一般是團隊之間的責(zé)權(quán)定義不明確，比如業(yè)務(wù)團隊認為需求已經(jīng)提交，等待研發(fā)團隊開發(fā)，研發(fā)團隊認為需求還沒有說清楚，還要補充很多的信息，最后當(dāng)團隊發(fā)現(xiàn)問題的時候，可能時間已經(jīng)過去了很久。這種停滯是毫無意義的，很容易讓團隊之間產(chǎn)生信任危機。

問題3：需求質(zhì)量差，經(jīng)常返工造成延期

需求質(zhì)量差也是需求流程當(dāng)中一個經(jīng)常被提到的問題，質(zhì)量問題一般包括以下幾個方面：

• 需求表述不清

• 需求遺漏

• 邏輯存在漏洞或者沖突

在需求進入開發(fā)階段以后，一旦發(fā)現(xiàn)需求的質(zhì)量問題，就會造成開發(fā)和測試工作的返工，讓需求交付時間延長，出現(xiàn)不必要的資源浪費。如果不幸在需求上線后才發(fā)現(xiàn)問題，那么損失就更大了。很多團隊都在想辦法解決需求質(zhì)量的問題，需求評審設(shè)一個有效的手段，能夠規(guī)避大部分的風(fēng)險。

問題4：各個團隊流程存在差異，跨團隊協(xié)作比較困難

隨著業(yè)務(wù)不斷發(fā)展，業(yè)務(wù)線和產(chǎn)品線都有可能進行拆分，不同團隊的需求流程也會逐漸形成差異化，如果一個需求需要兩個以上的產(chǎn)品團隊合作，就有可能會出現(xiàn)協(xié)作的問題。

如果產(chǎn)品形態(tài)確實存在較大差異，那么需求流程存在不同也是合理的。但是在一個產(chǎn)品線內(nèi)部，產(chǎn)品形態(tài)基本是接近的，比較理想的情況是，各個產(chǎn)品團隊盡量采用相同的需求流程來進行管理。這就好像醫(yī)院的就診流程，不同的科室都會采用相同的就診流程，這樣對于病人來說更加容易理解，不同科室之間，如果需要聯(lián)合會診也會更加的高效。

2. 為團隊制定科學(xué)有效的需求流程

需求流程的規(guī)范化從制定規(guī)范到實施規(guī)范，是一個復(fù)雜的系統(tǒng)工程。在這個過程中，既要考驗團隊的組織協(xié)作能力，也要依靠工具平臺的配置管理能力。接下來我們介紹一下需求流程的整個過程。

團隊角色分析

完成一個需求，往往需要很多的角色一起協(xié)作，因此制定需求流程，首先需要對流程中所有相關(guān)的角色進行分析，我們可以用一張簡單的表格列出各個角色的職能和責(zé)任，這里的關(guān)鍵是澄清角色在需求流程中所需要完成的工作，這也是我們后面設(shè)置需求詳細流程的依據(jù)。將各個角色的關(guān)系繪制成完整的團隊結(jié)構(gòu)圖，也有助于在需求流程推廣過程中讓每一位成員都清楚的了解完整的協(xié)作關(guān)系。

分析團隊角色不能只關(guān)注技術(shù)團隊，還要格外注意需求的來源團隊（業(yè)務(wù)團隊），如果需求的來源很多，涉及多個業(yè)務(wù)團隊，那么一定要把每個團隊的業(yè)務(wù)特點、需求類型、客戶類型都考慮到，這些信息在需求流程中可能會產(chǎn)生不同的影響。

團隊結(jié)構(gòu)圖

定義需求類型和結(jié)構(gòu)關(guān)系

需求類型的定義可以說是整個需求流程當(dāng)中的關(guān)鍵環(huán)節(jié)，常見的需求類型包括產(chǎn)品需求、用戶需求、系統(tǒng)需求、技術(shù)需求，還有一些英文概念，例如user story、Feature等等。面對這么多需求類型，很多團隊會感到困惑，不知道該選擇哪個類。這里切不可完全照搬網(wǎng)絡(luò)上的一些推薦方案，而是要選擇適合團隊的需求類型，盡量選擇團隊成員比較熟悉的比較常用的概念。 需求的類型其實跟團隊角色有著非常大的關(guān)系。一般每個需求類型都會由一個角色主要負責(zé)。我們用遞進的方式向大家介紹一下需求類型和結(jié)構(gòu)關(guān)系，從簡單到復(fù)雜逐漸轉(zhuǎn)變，大家也可以看一下自己的團隊更適合在哪個模式更合適。

我們先說一下最簡單的模式，只采用一個需求類型：產(chǎn)品類需求（有的團隊更習(xí)慣稱產(chǎn)品為“系統(tǒng)”，因此習(xí)慣使用系統(tǒng)需求這個類型）。產(chǎn)品需求的負責(zé)角色就是產(chǎn)品經(jīng)理，產(chǎn)品經(jīng)理創(chuàng)建需求并完成設(shè)計，再指派給開發(fā)由開發(fā)團隊完成需求的交付。當(dāng)技術(shù)團隊的分工更加明確，一個需求可能會有多個技術(shù)人員合作完成，這時我們會在需求下拆分任務(wù)，任務(wù)的負責(zé)角色就是技術(shù)團隊，這些任務(wù)會分配給不同的技術(shù)人員各自完成，這樣就形成了從產(chǎn)品需求到任務(wù)的兩層結(jié)構(gòu)。

由于產(chǎn)品需求是由產(chǎn)品經(jīng)理創(chuàng)建的，因此產(chǎn)品需求的顆粒度會基本保持一致。如果需求的來源不僅僅來自于產(chǎn)品經(jīng)理，很多業(yè)務(wù)角色也會創(chuàng)建需求，這時我們將會面臨需求的分層，引入業(yè)務(wù)需求的類型，業(yè)務(wù)需求的負責(zé)角色就是業(yè)務(wù)團隊。由于業(yè)務(wù)需求是來自于一線的客戶或者用戶，需求的顆粒度可能存在較大的差異，有的需求很小兩周就可以實現(xiàn)，有的需求可能需要幾個月。業(yè)務(wù)需求是無法直接交給技術(shù)團隊進行開發(fā)的，必須要經(jīng)過產(chǎn)品經(jīng)理的分析、拆分和整合。

這里我們并不是說有多少的角色就需要創(chuàng)建多少需求類型，還是要根據(jù)協(xié)作關(guān)系的復(fù)雜度來判斷，如果整個需求流程中的關(guān)系比較簡單，人數(shù)也相對較少，那么一個需求類型就可以解決，如果團隊之間存在多對多的協(xié)作關(guān)系，這時我們還會考慮引入需求和任務(wù)的分層。

需求類型和結(jié)構(gòu)關(guān)系

定義需求管理空間

確定了需求類型之后，接下來就要對需求管理空間進行定義，首先需要定義空間的類型。空間類型一般包括：需求研發(fā)交付空間、原始需求收集空間、產(chǎn)品規(guī)劃空間、項目管理空間等等。空間類型的選擇也同樣需要參考團隊的具體協(xié)作場景，根據(jù)需求的類型和團隊角色關(guān)系進行設(shè)置。每個需求空間會有多個角色進行協(xié)作，也可以支持多種需求類型的管理，同樣每個空間也會有一個主要負責(zé)的角色。

需求研發(fā)交付空間一般是必備的，這個空間的負責(zé)角色是研發(fā)團隊，同時管理產(chǎn)品需求和任務(wù)兩種事項類型。產(chǎn)品經(jīng)理會在這個空間里創(chuàng)建需求，在完成方案設(shè)計和評審之后指派給研發(fā)團隊。

如果需求的來源也來自于業(yè)務(wù)團隊，那么是否應(yīng)該創(chuàng)建獨立的空間來管理需求呢？這里我們要根據(jù)具體情況來定，如果業(yè)務(wù)團隊和技術(shù)團隊協(xié)作關(guān)系非常簡單，已經(jīng)形成了固定的搭配，是一對一的模式，這種情況不必另外單獨創(chuàng)建空間，所有的角色都可以在一個空間內(nèi)完成工作。因此需求空間的實質(zhì)就是承載了一個長期固定協(xié)作的團隊工作。

但是當(dāng)業(yè)務(wù)團隊和技術(shù)團隊形成了多對多的協(xié)作關(guān)系時，我們就要考慮創(chuàng)建第二種空間類型，也就是業(yè)務(wù)需求的收集空間(需求池) 。這是因為業(yè)務(wù)團隊錄入的需求，經(jīng)常會需要多個技術(shù)團隊來承接，業(yè)務(wù)團隊直接在研發(fā)交付空間中提需求，效率是比較低的，而且業(yè)務(wù)團隊提出的需求，往往無法直接給研發(fā)團隊進行開發(fā)，還需要經(jīng)過產(chǎn)品團隊的分析和轉(zhuǎn)化。這時就需要一個統(tǒng)一的需求收集空間。

大部分情況下，這兩種類型的空間就可以滿足需求管理的要求了，產(chǎn)品經(jīng)理在需求池中承接需求，并轉(zhuǎn)化為產(chǎn)品需求，而產(chǎn)品需求將會直接進入研發(fā)空間，由研發(fā)團隊進行交付。如果產(chǎn)品團隊不斷發(fā)展壯大，有了獨立的組織架構(gòu)，覆蓋多條產(chǎn)品線，并且對產(chǎn)品的規(guī)劃有比較明確的訴求，這是我們會考慮引入第三類需求空間：產(chǎn)品規(guī)劃空間，這類空間的負責(zé)角色就是產(chǎn)品團隊，管理比較大的產(chǎn)品主題（topic），產(chǎn)品主題也一樣可以拆分產(chǎn)品需求，指派到研發(fā)交付空間，在研發(fā)團隊的視角，產(chǎn)品需求可能會有多個來源，有的來自于業(yè)務(wù)團隊收集的業(yè)務(wù)需求，有的來自于產(chǎn)品團隊自身的規(guī)劃。

確定了空間類型之后，我們一般會按照組織架構(gòu)來創(chuàng)建具體的空間，研發(fā)交付空間一般以研發(fā)經(jīng)理的維度來區(qū)分，因為研發(fā)經(jīng)理需要制定團隊的工作計劃，在同一個空間中效率最高。需求收集空間的創(chuàng)建一般以業(yè)務(wù)現(xiàn)進行劃分，每個空間也有一位業(yè)務(wù)一號位（負責(zé)人），這樣利于需求優(yōu)先級的排定。

需求管理空間

制定需求流程規(guī)范

在確定了需求類型和空間類型之后，接下來我們要制定需求流程規(guī)范。每個需求類型都需要設(shè)置流程。需求流程和團隊角色有著很大的關(guān)系，需求流程規(guī)范主要包括以下三個方面：

• 流程有哪些狀態(tài)？

• 每個狀態(tài)的責(zé)任角色是誰？

• 每個狀態(tài)達成的必要條件有哪些？

產(chǎn)品需求的流程一般分為設(shè)計、開發(fā)、測試、發(fā)布等幾個階段。業(yè)務(wù)需求的流程一般分為確認、排期、實現(xiàn)、驗收、評價等幾個階段。任務(wù)同樣也有流程的概念，不過由于任務(wù)基本是由一個人獨立完成，因此流程相對比較簡單。

每個階段一般都會包括to do、doing、done三種狀態(tài)，例如業(yè)務(wù)需求創(chuàng)建完需要進入確認階段，包含待確認、確認中、已確認三個狀態(tài)。在選擇狀態(tài)的時候，不必每個階段都要保留這三個狀態(tài)，那樣會顯得有些繁瑣，可以根據(jù)實際情況選擇需要的狀態(tài)。比如業(yè)務(wù)需求的確認是通過需求評審會，當(dāng)場會形成結(jié)論，這時就不必選擇“確認中”這個狀態(tài)，只保留“待確認”和“已確認”。在需求指派給另一個角色的時候，就需要選擇“to do”的狀態(tài)，例如產(chǎn)品經(jīng)理在完成需求設(shè)計之后，指派給開發(fā)時會將需求設(shè)置成“待開發(fā)”，開發(fā)在完成開發(fā)之后提交給測試團隊，會將需求設(shè)置為“待測試”。

具體的狀態(tài)還要根據(jù)團隊的實際情況，設(shè)置對應(yīng)的狀態(tài)，狀態(tài)的命名可以參考前文的規(guī)則。如果團隊中已經(jīng)形成了比較成熟的需求流程，那么建議盡量沿用團隊已有的規(guī)范流程。

通過繪制需求流程圖，可以同時將需求類型、空間類型、流程狀態(tài)、團隊角色同時展示在一張圖上，便于在團隊中推廣需求規(guī)范時，讓團隊成員更清楚的了解規(guī)范內(nèi)容。

需求流程圖

確定需求評審/排期的時間節(jié)奏

需求評審和需求排期是需求流程中兩個非常重要的事件，為了讓團隊協(xié)作保持一個固定的節(jié)奏，也是為了提高協(xié)作的效率，我們建議團隊約定一個固定的時間，統(tǒng)一安排需求評審和需求排期。

一般我們建議每周安排一次需求評審，每兩周安排一次需求排期。因為研發(fā)團隊安排迭代的節(jié)奏一般是兩周，而新需求是每周都會有。不過根據(jù)團隊的實際情況，這個節(jié)奏可以再進行相應(yīng)的調(diào)整。

需求流程規(guī)范發(fā)布

如果完成了以上的工作，那么恭喜你，團隊的需求流程規(guī)范已經(jīng)基本草擬完成，接下來你需要與各個角色的負責(zé)人和團隊成員一起評審這個規(guī)范，取得大家的共識。在評審討論過程中，還可以繼續(xù)對這個規(guī)范進行修改和完善，這一步非常的重要，一個成功的流程規(guī)范，可能需要比較長的時間的打磨，才能夠穩(wěn)定下來。取得團隊管理者的支持也是必要的，流程規(guī)范的落地實施本質(zhì)上還是一個管理行為。

3. 通過云效進行專業(yè)的需求規(guī)范化設(shè)置

前面我們介紹了需求流程規(guī)范的制定方法，接下來我們結(jié)合云效產(chǎn)品實際功能的來演示一下，如何在工具中落實這些需求流程規(guī)范。

配置協(xié)作角色

管理員首先在云效Projex的「全局設(shè)置」中，根據(jù)規(guī)范創(chuàng)建對應(yīng)的項目角色，并且為每個角色配置初始化的權(quán)限點，將來項目模板的角色可以從中進行選擇，并且可以根據(jù)項目的要求修改各個角色的權(quán)限點。

配置需求類型和需求關(guān)系

接下來我們在云效中創(chuàng)建需求類型，類型的名稱按照需求流程規(guī)范的要求來命名，每個類型可以選擇不同的圖標(biāo)，方便用戶進行區(qū)分。

需求的字段也需要先定義好，需求字段分為“全局字段”和“項目內(nèi)字段”兩種，全局字段的待選值是全企業(yè)統(tǒng)一的，在不同的項目空間和不同的需求類型中，都是相同的選項；而項目內(nèi)字段，可以在各個項目空間各自設(shè)置待選值。這里需要把一些各個團隊共享的字段創(chuàng)建為「全局字段」。

接下來要進行非常重要的需求關(guān)系設(shè)置，在全局設(shè)置中的可以找到「類型間關(guān)系」設(shè)置，根據(jù)需求規(guī)范創(chuàng)建類型關(guān)系，比如系統(tǒng)需求下面可以拆解研發(fā)任務(wù)，我們就可以在這里創(chuàng)建一種類型關(guān)系：父項是系統(tǒng)需求，子項是研發(fā)任務(wù)。這樣需求的結(jié)構(gòu)關(guān)系就規(guī)范起來了，用戶只能按照設(shè)置的關(guān)系來拆解需求。

配置工作流

創(chuàng)建好需求類型之后，我們開始設(shè)置工作流程。云效預(yù)置了常用的工作項狀態(tài)，管理員還可以根據(jù)需求規(guī)范繼續(xù)創(chuàng)建其他的狀態(tài)。

每個需求類型都可以設(shè)置不同的流程，我們將工作項狀態(tài)添加到需求流程中，然后通過勾選checkbox來決定流程的走向。一般在同一個階段內(nèi)，狀態(tài)的流轉(zhuǎn)可以不加限制，而在從一個階段向另一個階段跨越的時候，則需要進行嚴(yán)格的限制。

配置流程狀態(tài)的角色和卡點

我們需要決定對每一個狀態(tài)的變化設(shè)置卡點，卡點包含「必填字段」和「角色控制」兩個方面，比如說進入開發(fā)狀態(tài)，只能由開發(fā)團隊來操作，并且計劃完成時間也必須填寫，那么就可以按照圖片所示進行設(shè)置。

配置項目空間模板

下一步我們就可以設(shè)置項目空間的模板了。云效預(yù)置了研發(fā)交付類、業(yè)務(wù)需求收集類等多個模板，我們可以根據(jù)規(guī)范創(chuàng)建對應(yīng)的項目模板，每個模板中包含了協(xié)作角色和需求類型，管理員可以從之前維護好的角色和需求類型中，將需要的數(shù)據(jù)加入項目模板。

配置好項目模板后，我們可以創(chuàng)建實際的項目空間。比如按照產(chǎn)品研發(fā)團隊創(chuàng)建研發(fā)交付空間，按照業(yè)務(wù)線創(chuàng)建業(yè)務(wù)需求的收集空間。

將項目模板的配置同步到各個項目空間

如果要保證不同的團隊的項目空間，遵循一個相同的需求流程，我們需要設(shè)置模板的「同步」功能，實現(xiàn)一個統(tǒng)一地規(guī)范性管理。一旦開啟了模板的同步，所有由這個模板創(chuàng)建的項目，都會使用模板的規(guī)則，項目管理員將無法修改需求流程，如果企業(yè)管理員修改了模板的需求流程，項目會自動使用模板的最新流程。

同步的設(shè)置也可以按照不同的需求類型進行分別配置，有的需求類型可以既同步需求字段，也同步需求流程，而有的需求可以只同步其中一個，甚至不同步，這樣可以滿足各種管理場景的訴求。

通過自動化規(guī)則實現(xiàn)需求狀態(tài)的聯(lián)動

當(dāng)需求和任務(wù)出現(xiàn)分層管理的時候，讓每一層需求的狀態(tài)保持最新的進展，會讓跨團隊的協(xié)作更高效，云效的自動化規(guī)則支持有關(guān)聯(lián)的需求和任務(wù)進行自動的狀態(tài)同步，比如當(dāng)系統(tǒng)需求下的研發(fā)任務(wù)變?yōu)椤高M行中」的時候，系統(tǒng)需求的狀態(tài)也會自動變?yōu)椤搁_發(fā)中」。

我們可以直接在項目模板中設(shè)置這些自動更新狀態(tài)的規(guī)則，這樣所有項目都會共享這些自動規(guī)則。配置規(guī)則一般主要是兩個場景：

• 當(dāng)任何子項變?yōu)閐oing的時候，父項自動變成doing

• 當(dāng)所有子項變?yōu)閐one的時候，父項自動變成done

配置需求評審流程

為了保證需求的質(zhì)量，并且在研發(fā)團隊中達成共識，我們建議使用云效的需求評審功能。我們可以基于不同的項目，選擇是否開啟需求評審。在項目設(shè)置的「評審設(shè)置」中，我們首先選擇哪些需求類型需要進行評審，再設(shè)置進入評審的「狀態(tài)節(jié)點」，一般是“設(shè)計完成”后，可以啟動評審。最后可以預(yù)置評審的評委，一般是項目經(jīng)理、開發(fā)經(jīng)理、測試經(jīng)理等等。完成了配置后，當(dāng)需求到達指定狀態(tài)時，用戶就可以發(fā)起評審了。

一般會由需求的負責(zé)人來發(fā)起評審，這時可以根據(jù)需求調(diào)整評委的范圍，填寫評審的注意事項。評審發(fā)起后，各個評委都會收到通知，也可以在項目的「評審」菜單中集中查找與自己相關(guān)的所有評審，然后在需求的詳情頁面中填寫評審的結(jié)論和意見。

如果所有的評委都選擇通過，或者超時未發(fā)表意見，均視為評審?fù)ㄟ^。只要有一位評委選擇不通過，則視為評審不通過。評審?fù)ㄟ^后，自動化規(guī)則會將需求自動設(shè)置為下一個階段的todo（如：待開發(fā)），通過對流程卡點的設(shè)置，可以實現(xiàn)需求從設(shè)計階段進入開發(fā)階段，只能依賴評審，而不同通過手工設(shè)置（管理員除外），這樣可以讓需求評審對需求流程的控制更加有效。

總結(jié)

需求流程的治理是一個長期的過程，需要整個團隊的執(zhí)行力和流程管理人員的推動能力，更需要研發(fā)流程中各個角色的互相理解與支持。

云效產(chǎn)品所提供的產(chǎn)品特性，能夠幫助各個團隊將需求規(guī)范落實下去，并且盡量減少協(xié)作過程中的工作量和不必要的誤會，讓整個需求流程變得有序且透明。