編輯導語：項目制中的需求人員如何能更好地體現(xiàn)自身價值以便更多地為團隊賦能呢？不可否認的是需要通過日常的積累、總結，讓自己能夠通過專業(yè)性快速得到客戶以及團隊的認可。本文從七個方面做出了解答，一起來看看。

前陣子有個朋友跟我吐槽說：

在項目制的團隊里，需求做的好與不好，對結果的影響大與不大，是很難用客觀數(shù)據(jù)或感受來衡量的。

需求做得好，項目不一定能做好；需求做的不好，項目不一定不能做好。那你說需求算什么？

對此我也能感同身受。所以今天想聊一聊項目制中的需求人員如何能更好的體現(xiàn)自身價值？如何更多的為團隊賦能？

如果有平行時空，同一個項目不同的需求人員可橫向對比，能直觀體現(xiàn)出優(yōu)秀者的效率與價值。

但是在項目制的管理中，節(jié)點就在那里，功能多少及質量高低都可能浮動。項目最終都會上線，功能的完整性及嚴謹性從各方角度看，也不容易被明顯察覺。即便項目延期了，大家也不會覺得需求要承擔主要責任。

但是作為項目的源頭，我們通過自身的專業(yè)性能夠為團隊帶來很多需求內外的幫助，從一個個細節(jié)入手進行提升，最終可能匯聚出不一樣的結果。

一、需求邊界你不一定能做主（盡量控制、快速接納）

拋開前期對現(xiàn)狀的熟悉、了解過程，需求人員在開始執(zhí)行需求分析時，首要任務是確認需求的邊界在哪。但是需求的邊界總會不可控的產(chǎn)生蔓延。

關于需求蔓延，即便此人非常有經(jīng)驗、有話語權，也會經(jīng)常遇到無法拒絕的新功能，最終導致邊界不可控，團隊工作量超標。自己難免會失落，或受到團隊質疑。但是這個問題要從兩方面來考慮。

首先，蔓延是相對的。如果換個經(jīng)驗相對少些的人，蔓延的可能會更多。因為我相信每位需求人員都會盡己所能控制邊界，我的價值也許就體現(xiàn)在回絕了幾個別人無法回絕的蔓延需求（關于如何控制需求蔓延的一些方法和應變技巧，最近我也在總結，后面會單獨展開探討）。

其次，有一些蔓延是我們沒有辦法控制的。比如政治任務，比如客戶的強烈要求，即便我們攔住了，需求提出方也會找到我們的領導來協(xié)調這件事。我們能做的，是在有限的范圍內減少蔓延，同時更快的形成方案，形成最小化可執(zhí)行方案。

同樣的需求別人的方案需要100人月，我的方案需要99人月，這一個人月就是我的價值。

二、需求細節(jié)你一定能做主（結構化思考、合理化執(zhí)行）

需求邊界確認之后，才是詳細需求的分析，以及最優(yōu)解決方案的形成。也是最常規(guī)體現(xiàn)一位需求人員水平的階段。

同樣完成一個功能，你的頁面設計更合理，對功能之間的連接、交互更清晰，所需開發(fā)的任務更少，這都是需求人員能夠結合自身經(jīng)驗體現(xiàn)出來的價值。

而且我們在分析需求時，能夠更快速洞察真實訴求（關于需求洞察可看底部的往期文章），能夠結合結構化思維設計出更合理的解決方案，能夠結合團隊實際能力，做出最小化可行性方案，這都是需求人員的價值所在。

三、做好需求講解（由淺至深、代入場景）

同樣的需求，你給人講明白需要一天，換個人講明白只需要半天，差距自然就出來了。

而且好的需求講解能夠讓客戶、團隊成員對你形成很好的初始印象，后續(xù)的很多工作都能更容易開展。

關于如何做好需求講解，有很多方法和細節(jié)，要根據(jù)受眾的不同、知識背景的不同、功能范圍的不同、關注重點不同等，制定不同的講解思路，同時還要有場景代入感讓聽眾更能理解等等。最近一年我也在團隊中和大家一起實踐如何更好的講需求。今天就不展開闡述了，計劃下一篇再單獨總結。

四、如何為開發(fā)崗賦能（業(yè)務邏輯是“大頭兒”）

我們大部分業(yè)務型產(chǎn)品/項目，開發(fā)人員更多的是在編寫“業(yè)務代碼”，業(yè)務處理邏輯是否準確，直接影響到開發(fā)質量。

所以需求人員除了給開發(fā)講明白需求，還要針對關鍵的業(yè)務邏輯進行講解。比如做A功能需要從B功能拿到b數(shù)據(jù)，傳給C功能的c模塊進行D規(guī)則的處理，最后返回到A頁面進行展示。這樣一波流程圖畫下來，開發(fā)的設計思路就完成了一大半，設計階段、開發(fā)階段的效率自然會得到很大提升。

同時有機會的話可以多聽一聽內部的設計評審，看看開發(fā)畫的流程圖對不對、對功能的理解對不對，把問題提前暴露出來必定是極好的。

五、如何為測試崗賦能（需求測試不分家）

針對測試人員在需求講解、細節(jié)確認等方面和上述的方法類似，不再贅述。測試崗更重要的是參與測試用例的評審，配合測試在寫用例過程中所發(fā)現(xiàn)的細節(jié)性問題盡快給出合理的解決方案。

針對測試發(fā)現(xiàn)的某些需求未考慮的極端場景或小概率場景，現(xiàn)有需求不滿足時，是否要“傷筋動骨”進行改造，這種權衡性問題對需求人員的決策力也是一個很大的考驗。我們要基于改造的工作量、時間周期、場景頻率、業(yè)務影響范圍、客戶輿情等多方面進行綜合考量。

在測試階段進度緊張時，需求人員也可以協(xié)助測試進行功能測試，或配合測試進行組內驗收測試，或與甲方/第三方測試團隊溝通細節(jié)，解釋問題等。

六、如何為項目經(jīng)理賦能（能多做就多做）

需求人員可以幫助項目經(jīng)理完成“需求跟蹤矩陣”的編寫，將需求文檔中的功能轉化為可執(zhí)行任務，再由項目經(jīng)理進行分配。

可協(xié)助項目經(jīng)理進行質量跟蹤、進度跟蹤、資源協(xié)調、客戶溝通、其他項目文檔編寫等，也可以通過本身的溝通優(yōu)勢，幫助項目經(jīng)理“穩(wěn)定軍心”，做團隊內部的“潤滑劑”。

七、如何為運營崗賦能（讓業(yè)務更有溫度）

如果團隊中有運營崗位，可以協(xié)助運營更好的完成推廣方案、調研方案、操作手冊、常見問題答疑等相關物料（當然有些團隊中這些物料產(chǎn)出本就屬于需求崗的職責范圍）。

如果涉及到運營活動、數(shù)據(jù)分析等事項，需求人員也可以站在自身對用戶、功能的理解，給予相應建議。

八、總結

一句話概括：通過自身專業(yè)能力節(jié)省各個環(huán)節(jié)的時間。

而且這些事項能讓我們更快速、更全面的成長、積累、突破瓶頸，從而得到共贏的成果。

需要注意的是，需求的工作沒有非常統(tǒng)一的標準，即使是同一個公司內部、同一個團隊面對不同境遇，在標準和執(zhí)行層面都會有差異。在此只是根據(jù)常規(guī)情況總結了一些常見的內容。我們真正在執(zhí)行階段，還是要根據(jù)項目情況和人員情況靈活處理。只要符合自身境遇需要即可。

當我們真正得到很好的工作成果時，能力提升了，成就感收獲了，外在的表彰與認可還會那么在意嗎？

寫在最后

需求人員到了新的團隊，或者面對新的客戶時，第一印象、前期印象非常重要。我們要通過日常的修煉、積累、總結，讓自己能夠通過專業(yè)性快速得到客戶的認可、團隊的認可。

被認可后，后面的工作就順滑多了。因為你說的，別人會聽，而不是不管你對不對都會先被質疑一波，那樣后面再扭轉局面就更難了。

所以，想給大家一個靠譜的印象，就要付出比他人更多的努力。“歲寒，然后知松柏之后凋也”。只要我們堅持，總會被覺察，被認可。

即便你已不在這個團隊，他們還是會時不時懷念你。而不是看著你曾經(jīng)的文檔“問候你的家人”…

公眾號：不想延期了

本文由 @不想延期了 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載。

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