在項(xiàng)目管理中，只有管理得當(dāng)，團(tuán)隊(duì)和諧得當(dāng)，效率才會提升。下面這篇文章是筆者分享的一種創(chuàng)新的團(tuán)隊(duì)協(xié)作策略，公交模型提升需求管理效率。大家一起來認(rèn)識認(rèn)識吧！

一、 引言

在項(xiàng)目管理中，需求管理是成功的關(guān)鍵，涉及識別、獲取和管理人們對產(chǎn)品或服務(wù)的期望和要求。良好的需求管理可以確保項(xiàng)目滿足所有利益相關(guān)者的期望，避免資源浪費(fèi)和項(xiàng)目范圍蔓延。

然而，許多組織在實(shí)踐中面臨挑戰(zhàn)，傳統(tǒng)需求管理方法往往線性、剛性，與客戶互動有限，導(dǎo)致需求理解不足和響應(yīng)緩慢，可能導(dǎo)致項(xiàng)目失敗。為應(yīng)對這些挑戰(zhàn)，本文提出了一種創(chuàng)新的解決方案——公交模式。

這是一種靈活的需求管理方法，類似于公共交通工具的運(yùn)行方式。在這個(gè)模式下，需求如同乘客在不同站點(diǎn)上車和下車，項(xiàng)目團(tuán)隊(duì)需管理這些“站點(diǎn)”，確保需求能高效進(jìn)入項(xiàng)目開發(fā)流程并得到滿足。

通過模擬公交系統(tǒng)運(yùn)作，我們可以實(shí)現(xiàn)需求管理的高效性和適應(yīng)性，從而在快節(jié)奏的項(xiàng)目環(huán)境中取得成功。

二、公交模型的概念

公交模式把需求管理比作一個(gè)公共交通系統(tǒng)，其中需求就像是需要到達(dá)特定目的地的乘客。

在這個(gè)系統(tǒng)中，需求在其生命周期內(nèi)會經(jīng)過不同的“站點(diǎn)”，每個(gè)站點(diǎn)都代表需求管理過程中的一個(gè)階段，如需求收集、評審、排期、實(shí)施和驗(yàn)收。需求（乘客）在整個(gè)過程中被接收（上車）、處理（行程中）和完成（下車），同時(shí)保證在整個(gè)過程中不斷有需求被接受和已完成的需求被移出系統(tǒng)。

通過允許需求在不同階段靈活“上車”和“下車”，公交模式能夠適應(yīng)項(xiàng)目的變化，以及團(tuán)隊(duì)能力和資源的波動，從而確保需求管理的連續(xù)性和靈活性。公交模式的設(shè)計(jì)快速適應(yīng)不斷變化的市場需求和技術(shù)環(huán)境。

需求可以在任何階段被重新評估和調(diào)整，以確保產(chǎn)品的競爭力和相關(guān)性。每個(gè)需求的狀態(tài)在公交模式中都是可見的，像實(shí)時(shí)追蹤公交車位置一樣。這種透明度不僅有助于團(tuán)隊(duì)成員對需求的理解和響應(yīng)，也讓利益相關(guān)者能夠跟蹤需求的進(jìn)展。

三、公交模型的工作流

1. 需求收集（站點(diǎn)設(shè)置）

• 站點(diǎn)定義：明確需求收集的范圍和類型，設(shè)立固定的“站點(diǎn)”，即收集點(diǎn)，如特定的郵件列表、需求提交平臺等。
• 提交規(guī)則：制定需求提交的格式和規(guī)則，確保收集到的信息準(zhǔn)確、完整。

2. 需求分析（路線規(guī)劃）

• 需求評審：評估每個(gè)需求的可行性、影響范圍、優(yōu)先級和資源需求。
• 需求整合：將相關(guān)需求合并或拆分，以更好地滿足用戶需求和業(yè)務(wù)目標(biāo)。

3. 需求排期（車次安排）

• 版本規(guī)劃：根據(jù)需求的優(yōu)先級和開發(fā)資源，規(guī)劃需求在產(chǎn)品的哪個(gè)版本中實(shí)施。
• 迭代計(jì)劃：在敏捷開發(fā)環(huán)境中，需求被分配到特定的迭代或沖刺中。
• 臨時(shí)加班車：針對緊急或特別需求，可能需要安排臨時(shí)的加班車（加急開發(fā)和部署流程）。
• 緊急班次: 設(shè)立一個(gè)“緊急班次”，僅用于處理那些必須立即發(fā)布的緊急需求。定義一個(gè)嚴(yán)格的緊急需求審批流程，確保只有真正緊急和關(guān)鍵的問題才能使用緊急軌道。緊急需求一且發(fā)布，要迅速組織回顧會議，分析其緊急性的原因，并學(xué)習(xí)如何在常規(guī)過程中避免類似情況發(fā)生。

4. 需求開發(fā)（乘客上車）

• 開發(fā)分配：根據(jù)需求特點(diǎn)，分配給相應(yīng)的開發(fā)人員或團(tuán)隊(duì)。
• 開發(fā)跟蹤：監(jiān)督需求開發(fā)的進(jìn)度，確保按計(jì)劃進(jìn)行。

5. 驗(yàn)收與部署（到站通知）

• 驗(yàn)收測試：完成開發(fā)后進(jìn)行詳細(xì)的測試，確保滿足需求規(guī)范。
• 用戶驗(yàn)收：由需求提出者或最終用戶進(jìn)行驗(yàn)收。
• 上線部署：驗(yàn)收通過后，需求被部署到生產(chǎn)環(huán)境，并通知所有相關(guān)方。

6. 反饋循環(huán)（乘客下車與評價(jià)）

• 用戶反饋：收集用戶對新功能的反饋。
• 持續(xù)改進(jìn)：根據(jù)反饋優(yōu)化現(xiàn)有功能，調(diào)整未來的需求收集和開發(fā)流程。

7. 流程優(yōu)化（循環(huán)與調(diào)整）

• 效率分析：定期評估流程效率，識別瓶頸和改進(jìn)點(diǎn)。
• 流程調(diào)整：基于分析結(jié)果和團(tuán)隊(duì)反饋調(diào)整流程，以提高效率和響應(yīng)速度。

8. 核心要素

• 定時(shí)收集：需求不是隨時(shí)被接受和處理，而是在預(yù)定的時(shí)間點(diǎn)集中收集。
• 固定路線：需求處理按照既定的流程進(jìn)行，類似公交車固定的行駛路線。
• 預(yù)定時(shí)間表：確定需求處理的時(shí)間表，比如每周或每兩周進(jìn)行一次需求評審和排期。
• 批量處理：單個(gè)需求不立即實(shí)施，而是和其他需求一起批量處理，提高效率。
• 規(guī)則明確：公交模型要求對需求收集、處理和發(fā)布的規(guī)則必須明確，所有人都能清晰理解。
• 優(yōu)先級排序：根據(jù)需求的重要性和緊急性對它們進(jìn)行優(yōu)先級排序，以合理分配資源。
• 靈活調(diào)整：雖然是定時(shí)收集和處理，但公交模型也應(yīng)允許在必要時(shí)對時(shí)間表和處理流程進(jìn)行靈活調(diào)整。
• 溝通機(jī)制：要有有效的溝通機(jī)制確保所有利益相關(guān)者了解需求處理的進(jìn)度和變更。
• 反饋循環(huán)：在需求完成后，收集反饋并用于改進(jìn)未來的需求收集和處理過程。
• 持續(xù)改進(jìn)：定期回顧和評估模型的效率和效果。

四、公交模式的具體應(yīng)用

1. 背景

一個(gè)中型電子商務(wù)公司面臨需求管理上的混亂，需求從各個(gè)部門和客戶不斷涌入，導(dǎo)致產(chǎn)品團(tuán)隊(duì)難以跟上節(jié)奏，緊急需求經(jīng)常打亂計(jì)劃。公司決定實(shí)施公交模型來優(yōu)化需求管理流程。

2. 目標(biāo)

• 確保需求被系統(tǒng)地收集、分析、排期和實(shí)施
• 提高團(tuán)隊(duì)對緊急和變更需求的響應(yīng)速度
• 增強(qiáng)跨部門之間的透明度和溝通
• 提升需求實(shí)施的效率和質(zhì)量

3. 流程制定

1）需求收集（站點(diǎn)設(shè)置）

公司設(shè)立一個(gè)內(nèi)部平臺作為需求提交站點(diǎn)，每月第一個(gè)周一，任何員工和客戶都可以在這里提出新的服務(wù)需求或改進(jìn)建議。

• 需求來源：描述需求的起源或來源。例如：客戶反饋、產(chǎn)品需求、運(yùn)營需求、客戶需求、技術(shù)需求、高層需求。
• 功能模塊：指定需求涉及的產(chǎn)品或系統(tǒng)的具體模塊或部分。若為新功能，明確提及“新模塊”。
• 背景問題：簡潔明了地描述產(chǎn)生此需求的背景和當(dāng)前所遇到的問題。盡可能提供數(shù)據(jù)或事例支持。
• 業(yè)務(wù)價(jià)值：描述實(shí)施此需求后可以為業(yè)務(wù)帶來的預(yù)期價(jià)值或好處。例如提高效率、增加用戶、提升滿意度等。
• 需求描述：詳細(xì)、清晰、具體地描述內(nèi)容。
• 提出日期：記錄需求提出的確切日期。格式統(tǒng)一為“YYYY-MM-DD”。
• 提出人：記錄提出需求的人員姓名或團(tuán)隊(duì)。若有多個(gè)提出人，列舉主要聯(lián)系人。
• 相關(guān)資料：提供需求相關(guān)的支持文件、鏈接或參考資料。

2）需求分析（路線規(guī)劃）

• 內(nèi)部評估周期：每周周一，產(chǎn)品團(tuán)隊(duì)對收集的需求進(jìn)行評估，分析其影響和緊迫性，并對其進(jìn)行反饋。
• 外部反饋周期：每周周一，產(chǎn)品團(tuán)隊(duì)與相關(guān)方召開需求反饋會議，對每個(gè)需求進(jìn)行反饋和問題解答。
• 初步評估結(jié)果：此處填寫需求的初步評估狀態(tài)，“待評估”、“已評估”、“需進(jìn)一步討論”等。
• 反饋日期：產(chǎn)品團(tuán)隊(duì)對需求進(jìn)行評估后的反饋日期。
• 反饋內(nèi)容：產(chǎn)品團(tuán)隊(duì)對需求的具體反饋內(nèi)容，可以是“接受”、“拒絕”、“暫不考慮”等，同時(shí)可加入具體的理由或建議。
• 注意：需求反饋環(huán)節(jié)不回復(fù)開發(fā)周期和排期

3）需求排期（車次安排）

• 內(nèi)部規(guī)劃周期：雙周周一，產(chǎn)品團(tuán)隊(duì)對收集的需求進(jìn)行評估，規(guī)劃下一個(gè)需求管理周期的初步版本范圍。
• 外部同步周期：雙周周一，產(chǎn)品團(tuán)隊(duì)與相關(guān)方召開版本評審會議，明確最終版本范圍。
• 版本內(nèi)容：50%新功能；20%優(yōu)化需求；30%其他需求
• 版本內(nèi)容變更流程：如需變更需求，根據(jù)緊急度，可增加1-2個(gè)緊急需求。如非緊急需求，可從中挑選顆粒度相當(dāng)?shù)男枨筮M(jìn)行更換。

4）需求開發(fā)（乘客上車）

開發(fā)分配：項(xiàng)目經(jīng)理進(jìn)行需求拆解和任務(wù)下發(fā)，分配給相應(yīng)的開發(fā)人員。

5）驗(yàn)收與部署（到站通知）

驗(yàn)收準(zhǔn)入標(biāo)準(zhǔn)：

① 要求對需求文檔上提及的所有功能進(jìn)行全面測試，且提交驗(yàn)收測試時(shí)，開發(fā)方發(fā)現(xiàn)的所有缺陷都已解決。
② 驗(yàn)收環(huán)境準(zhǔn)備就緒，提供測試賬號，驗(yàn)收測試環(huán)境準(zhǔn)備完成，與線上真實(shí)環(huán)境一致。
③ 清除測試數(shù)據(jù)，保證無臟數(shù)據(jù)導(dǎo)致異常。

產(chǎn)品驗(yàn)收合格標(biāo)準(zhǔn)：

① 系統(tǒng)滿足驗(yàn)收測試要求，產(chǎn)品需求均已實(shí)現(xiàn)。
② 驗(yàn)收測試用例執(zhí)行覆蓋率達(dá)到100%。
③ 測試通過率達(dá)到100%，非功能性測試用例達(dá)到95%以上。
④ 在測試中發(fā)現(xiàn)的Bug已經(jīng)得到閉環(huán)，Bug趨勢得到收斂。
⑤ 沒有P0，P1級必現(xiàn)BUG存在，P2級非必現(xiàn)BUG數(shù)目不能超過2個(gè)（注：非必現(xiàn)bug的復(fù)現(xiàn)概率不能高于5%），剩余BUG數(shù)不超過5個(gè)，所有BUG數(shù)目不能超過8個(gè)業(yè)務(wù)驗(yàn)收合格標(biāo)準(zhǔn)：沒有P0，P1級必現(xiàn)BUG存在，P2級非必現(xiàn)BUG數(shù)目不能超過2個(gè)（注：非必現(xiàn)bug的復(fù)現(xiàn)概率不能高于5%），剩余BUG數(shù)不超過5個(gè)，所有BUG數(shù)目不能超過8個(gè)。

6）反饋循環(huán)（乘客下車與評價(jià)）

• 1.bug處理流程：用戶反饋 -》運(yùn)營接收問題 -》做一輪初篩 -》反饋給 測試人員 -》測試人員復(fù)現(xiàn)，提交Bug，登記線上問題表 -》反饋給開發(fā)同學(xué)，開發(fā)修復(fù) -》測試同學(xué)驗(yàn)證 -》上線 -》告知運(yùn)營
• 2.需求處理流程：用戶反饋 -》運(yùn)營接收問題 -》做一輪初篩 -》反饋給 測試人員 -》判定為新需求 -》反饋給產(chǎn)品同學(xué)入池
• 3.線上問題記錄表：所屬系統(tǒng)/頁面/模塊/問題描述/圖示/提出者/提出日/版本號/問題類型/缺陷性質(zhì)/優(yōu)先級/問題狀態(tài)/產(chǎn)品責(zé)任人/當(dāng)前處理人/問題定位/解決方案/解決日期

注意：為了應(yīng)對緊急情況，臨時(shí)解決的方案必須記錄，bug標(biāo)識出臨時(shí)解決，需要真正修復(fù)驗(yàn)證后進(jìn)行關(guān)閉。

7）流程優(yōu)化（循環(huán)與調(diào)整）

對整體流程持續(xù)優(yōu)化和調(diào)整，直至流程全部運(yùn)營順暢。

正如公交車穩(wěn)定而有序地穿梭于城市，我們的需求管理機(jī)制確保每個(gè)功能安全、準(zhǔn)時(shí)地到達(dá)用戶手中。

這一機(jī)制不僅提升了工作效率，也強(qiáng)化了團(tuán)隊(duì)之間的合作與溝通。正如公交系統(tǒng)連接城市的每一個(gè)角落，我們的需求管理流程連接了用戶的需求與開發(fā)團(tuán)隊(duì)的能力，確保每個(gè)功能都能準(zhǔn)時(shí)抵達(dá)用戶手中。

每個(gè)參與者，無論是需求提出者、開發(fā)者還是測試人員，都在這個(gè)過程中找到了自己的位置，共同推動著項(xiàng)目向前發(fā)展。