編輯導(dǎo)語：一個需求從產(chǎn)生到落地的全過程是很復(fù)雜的，本文作者通過分享這篇文章跟大家分享一下：我們在需求落地的過程中，會經(jīng)歷哪些步驟、會遇到哪些困難、有哪些技巧可以保證這個過程的順利，希望看后對你有所幫助。

一、產(chǎn)生需求，辨別真?zhèn)?/h2>

需求的來源有很多，需求挖掘、用戶研究、用戶反饋、數(shù)據(jù)分析、競品分析、公司內(nèi)部（老板、運營人員、銷售、客戶等），需求總是各式各樣的，總是披著假面具的，辨別真?zhèn)危钱a(chǎn)品經(jīng)理的必修課。

除了會辨別，也要懂得拒絕。關(guān)于如何拒絕需求，可以參考我的上一篇文章《真實案例分析——產(chǎn)品經(jīng)理如何拒絕需求》

二、編寫需求文檔

這部分也也不多說，一份優(yōu)秀的需求文檔，應(yīng)該包含什么內(nèi)容，應(yīng)該是什么結(jié)構(gòu)，可以參考我寫的《好的需求文檔是什么樣的結(jié)構(gòu)》，我舉了很多實例，分部分拆解，講的還算詳細。

三、需求評審會

產(chǎn)品經(jīng)理編好了需求文檔，視需求大小，決定是否需要開需求評審會。通常，當需求是全新業(yè)務(wù)、開發(fā)量較大、對原系統(tǒng)改動較大時，是必須開需求評審會的。

很多產(chǎn)品經(jīng)理害怕開評審會，覺得自己寫的需求被開發(fā)測試當著很多人的面指出不足，甚至吐槽，是一件很丟臉的事，面子上過不去。事實上，每個產(chǎn)品經(jīng)理都會經(jīng)歷這個階段，而是否有所成長，最關(guān)鍵也是這個階段。

如果的確是你的方案不足，你的自尊心會促使你快馬加鞭的學(xué)習(xí)，提升自己，會逼迫你在開會之前做好萬全的準備。

如果你的方案沒問題，面對開發(fā)測試老板的質(zhì)疑，你要學(xué)會拆解他們的質(zhì)疑。如何拆解，前提是你已經(jīng)考慮過他們會針對這個方案提出什么質(zhì)疑，以及已經(jīng)思考過你的方案，與他們的方案對比，有哪些優(yōu)勢。

如果你一開始還沒有具備這樣的邏輯能力，那就聽，擺正心態(tài)，耐心的聽別人的質(zhì)疑，但不要馬上否定自己，你需要經(jīng)過深入的思考，來自主判斷。

沒錯，心態(tài)。這個部分我并不想過多強調(diào)產(chǎn)品經(jīng)理的能力，方案寫的多么好，口才有多么好，我想強調(diào)的是，好的心態(tài)，有多重要。我認為優(yōu)秀的產(chǎn)品經(jīng)理，必須有一項品質(zhì)，那就是兼容并包。承認別人的優(yōu)秀，承認自己的不足，但絕不自貶，而是想辦法學(xué)習(xí)優(yōu)秀的人。

相信我，這個品質(zhì)會讓人上癮，不再因為別人質(zhì)疑而覺得抬不起頭，不會因為別人的優(yōu)秀覺得自卑，不害怕別人嘲諷，你會覺得心胸開闊，可以容納更多的事物。我嘗試過一些辦法，不去想，或者心里暗示自己要接受要認可，但都收效甚微。

后來，我終于找到了有效的辦法，那就是開口夸贊。當你遇到了優(yōu)秀的人，當你的評審會上有人提出了的確不錯的方案，你要敢于開口贊許，“我覺得這個想法很好”，“我覺得他的方案比我的更好，我的方案還有xxxx這些不足的，他很?！薄?/p>

一方面，可以在團隊中樹立你客觀、兼容并包、善于贊許他人的好形象；另一方面，你的心胸切切實實可以發(fā)生改變。

通常我們會先讓開發(fā)、測試、設(shè)計都各自熟悉一遍需求文檔，有個基本的了解，以及產(chǎn)生各自的問題，再開評審會。為保證評審會的效率，產(chǎn)品需要挑重要的部分講解，而一些細節(jié)的邏輯細節(jié)問題，則不多贅述。

在評審會過程中，產(chǎn)品經(jīng)理要學(xué)會把控進度，開發(fā)人員在評審會中容易陷入思考如何實現(xiàn)的旋渦，導(dǎo)致他們在會上可能會花時間討論技術(shù)問題，產(chǎn)品要及時喊停，讓會議回到正軌。

需求評審會最重要的意義，就是將絕大多數(shù)的需求上的變數(shù)，扼殺在搖籃里。避免開發(fā)進行途中，由于方案的錯誤，需求變更，導(dǎo)致項目延期，甚至方案要推到重來的情況出現(xiàn)。

四、根據(jù)評審會結(jié)果修改需求文檔

這個部分，產(chǎn)品經(jīng)理除了修改文檔，更重要的工作是反思，是什么原因，導(dǎo)致了方案的缺陷，歸納總結(jié)，分析是哪個步驟出現(xiàn)了問題，是自己的哪種能力不足。

五、確定需求文檔，安排分工

每個公司可能都有自己用來管理員工任務(wù)的工具，我比較推薦teambition，分享下我目前用teambition管理項目的方式：

1. 一條產(chǎn)品線，作為一個項目

以產(chǎn)品線為單位，一條產(chǎn)品線創(chuàng)建一個項目管理。

2. 常用的功能插件

一個項目中，可以根據(jù)項目的需要，選擇功能插件，我比較常用的幾個是任務(wù)、概覽、統(tǒng)計、缺陷、迭代、Wiki、版本管理。

1）任務(wù)

即管理成員工作任務(wù)的地方，以面板的形式存在，面板可以自定義，一個任務(wù)有認領(lǐng)人、參與人、時間等等。

2）概覽

清晰記錄項目的關(guān)鍵信息，支持字段配置，并且可以后期搜索和統(tǒng)計。適合短期的，有階段性的項目。

3）統(tǒng)計

提供項目范圍內(nèi)不同成員任務(wù)、工時的計劃總量和完成情況的可視化統(tǒng)計?？梢钥吹揭粋€項目中，各個成員的工作占比以及各自完成的任務(wù)數(shù)量。

統(tǒng)計項目中各個狀態(tài)任務(wù)的數(shù)量，如已經(jīng)完成了多少、延期的有多少。有助于產(chǎn)品經(jīng)理把控項目的風險，以及團隊的效率。

4）缺陷

這個功能主要由測試人員使用，用于記錄缺陷的生命周期數(shù)據(jù)，可以對缺陷進行全方位記錄與跟蹤。

當測試中 / 項目上線后發(fā)現(xiàn)bug，由測試人員提起，并指派執(zhí)行者，同時編輯缺陷的相關(guān)信息，開發(fā)人員修改后，由測試人員跟蹤，及時更新缺陷的狀態(tài)。

5）迭代

這個功能由產(chǎn)品經(jīng)理使用，即規(guī)劃該產(chǎn)品線的迭代計劃。屬于這個迭代的功能，參與人員創(chuàng)建后任務(wù)后，都關(guān)聯(lián)到這個迭代。即可根據(jù)任務(wù)的完成進度，可見本次迭代的總體進度。

6）Wiki

建立 Teambition 項目與「Thoughts」知識庫的對應(yīng)關(guān)系，通過項目導(dǎo)航查看對應(yīng)「Thoughts」知識庫的 Wiki 文檔，「Thoughts」是一款企業(yè)知識管理工具。通過創(chuàng)作和組織文檔，知識得以沉淀，并在團隊中高效流動，「Thoughts」是以知識庫的形式存在的。

我們通常用「Thoughts」來編寫團隊文檔，例如接口文檔、或任務(wù)中需要特別的說明文檔，「Thoughts」中的文檔，是可以和任務(wù)關(guān)聯(lián)的，即可作為補充材料的形式展示。除此之外，由于它“知識庫”的特性，我們還用它來編輯用戶端的【幫助中心】，可對外發(fā)布訪問。

7）版本管理

每一次發(fā)布版本后，在這里編輯本次版本的版本號、發(fā)布時間、發(fā)布內(nèi)容等，方便溯源。

3. 任務(wù)面板的設(shè)置，以及任務(wù)的流向

這里重點講下第（1）點：任務(wù)。

任務(wù)，實際上是以“流”的形式在項目整個生命周期中運動的。

我們設(shè)置了這幾個面板：需求、采納池、設(shè)計中、開發(fā)中、未完成對接、測試中、代碼評審、待發(fā)布、已上線。

以一個任務(wù)為例：

• 產(chǎn)品經(jīng)理提出需求，在【需求】面板創(chuàng)建了一個任務(wù)；
• 該需求經(jīng)過討論，普遍認可其意義，且已獲得上級的資源支持，則產(chǎn)品經(jīng)理將任務(wù)拉動到【采納池】面板；
• 期間，產(chǎn)品經(jīng)理編寫需求文檔、開需求評審會；
• 期間，設(shè)計師開始參與設(shè)計，由設(shè)計師在【設(shè)計中】面板創(chuàng)建相應(yīng)的設(shè)計任務(wù)（設(shè)計的任務(wù)完成后，由設(shè)計師將任務(wù)拉動到【已上線】面板）；
• 評審會后，安排分工，參與人員；
• 前端、后端、測試分別在產(chǎn)品經(jīng)理創(chuàng)建的任務(wù)下，添加子任務(wù)，并根據(jù)各自的工期，分別設(shè)定開始時間、截止時間；
• 前端、后端開始開發(fā)后，各自將自己的子任務(wù)拉到【開發(fā)中】面板，最先開始開發(fā)的，同時負責將父任務(wù)也拉動到【開發(fā)中】面板；
• 若前后端其中一個優(yōu)先完成開發(fā)，但另一方未完成，即未對接，則已完成的一方將自己的子任務(wù)拉動到【未完成對接】面板中，同時清除開始、截止時間；
• 另一方也完成任務(wù)后，也將自己的任務(wù)拉到【未完成對接】面板，同時負責將父任務(wù)也拉動到【未完成對接】面板；
• 這時，前后端需要在各自的任務(wù)中加上開始時間、截止時間，此時的時間代表的是對接的時間；
• 對接完成后，前后端通知測試人員，同時清除各自子任務(wù)的時間；由測試人員將整個任務(wù)（包括子任務(wù)）拉動到【測試中】面板，并在測試子任務(wù)中指定開始、截止時間（此時時間代表的是測試時間）；
• 測試中出現(xiàn)bug，前后端再次對接，時間算在測試里；
• 測試完成，開始評審代碼，由測試人員，將整個任務(wù)（包括子任務(wù)）拉動到【代碼評審】面板，同時清除測試時間；
• 評審?fù)瓿?，由測試人員，將整個任務(wù)將整個任務(wù)（包括子任務(wù)）拉動到【待發(fā)布】面板；
• 發(fā)布后，由發(fā)布版本的技術(shù)人員，將將整個任務(wù)將整個任務(wù)（包括子任務(wù)）拉動到【已上線】面板。

以上就是一個任務(wù)，最普遍的流向軌跡，省去了很多異常情況（如一個需求若未被采納，由產(chǎn)品經(jīng)理將任務(wù)移到回收站等），產(chǎn)品經(jīng)理可以根據(jù)自己公司的實際情況和習(xí)慣，與團隊共同商議整個流程。

有幾個點需要注意：

1. 工時的評估，需要由技術(shù)主管審核，技術(shù)主管負責指導(dǎo)成員如何正確評估工時（沒有技術(shù)主管可以指定兩個技術(shù)負責人，一個前端一個后端）；
2. 延期的任務(wù)，每一次延期，要在任務(wù)中備注延期的原因，技術(shù)主管、產(chǎn)品經(jīng)理要知道，且分析問題所在；
3. 要求成員在每天下班前，要更新所有任務(wù)的狀態(tài)；
4. 成員要發(fā)日報；
5. 每周要由產(chǎn)品經(jīng)理發(fā)周報，以產(chǎn)品線為單位，概述本周該產(chǎn)品線的進展和計劃，同時公布本期延期的任務(wù)、涉及人員、逾期原因分析?？梢韵蛏霞壣暾堃恍┆剳蜋C制，如一個月任務(wù)未有延期記錄，有獎勵；
6. 產(chǎn)品經(jīng)理要自行劃分階段，定時了解成員的工作，避免在開發(fā)與需求有偏差，在測試前，產(chǎn)品要過一遍功能，確保功能與需求一致，測試后，正式驗收。

六、功能上線，監(jiān)測數(shù)據(jù)，做下步迭代計劃

功能上線后要留意關(guān)鍵指標的變化，做好功能反饋收集，為下一版本的迭代做計劃。

七、復(fù)盤

項目復(fù)盤，必備技能。改天我們再詳細展開。項目復(fù)盤是產(chǎn)品經(jīng)理能力提升的“快車道”，將自己和團隊在整個周期中的過程梳理一遍，提煉精華，暴露缺陷。會復(fù)盤的產(chǎn)品經(jīng)理，與從不復(fù)盤的產(chǎn)品經(jīng)理，注定逐漸拉開距離。

以上，和大家分享了需求從產(chǎn)生到落地的過程中，一些不成文的經(jīng)驗，冰山一角，歡迎補充，集大家之成，查缺補漏。

本文由 @木木 發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

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