編輯導語：要把想法變成切實的產品總是很難的，這篇文章討論了項目推進總是不順利的兩個原因，將項目分為五大階段和各個小環節，幫助大家優化做項目的流程，不妨來看看。

前段時間看到一個童鞋在后臺留言，一個idea要怎么樣才能變成線上的產品？學姐回想了下，在自己初入行的那會兒，確實會面臨“idea多，結果少”的情況。相信很多來做產品經理的童鞋都是懷揣著滿腔的想法，結果進公司后發現，扯皮、推鍋的事兒很多，推進大項目并不是這么簡單。

一、為啥項目推進總是不順利？

撇開項目本身價值有問題的情況不討論，無非是這兩個原因：

1. 流程問題

做大項目的流程，平時做普通需求的流程顯然不一樣，很多童鞋對這部分并不熟悉，或者說熟悉但不精通。

這就讓學姐想到了前幾天看到的一個視頻，還挺有意思的，講的是重慶有倆大型商場要趕在圣誕節前開業，一個外國大叔實地探訪開業前的36小時。只見商場里幾乎空無一物，建材堆的到處都是，看上去就像一個工地，甚至要帶安全帽。圣誕節當天，這倆商場就奇跡般地正常營業了，客流量還挺大，沒有任何一個環節掉鏈子，視頻的結尾大叔開始感慨“中國速度” ↓

學姐看完視頻后覺得，這不就是咱上線一個產品的真實過程嗎？上線前還有長長的bug list，視覺還原問題至少十幾個，老板們還在那兒各種提意見～

一陣手忙腳亂后，項目竟然準時上線了，甚至沒有任何bug和客戶投訴。要做到這種“中國互聯網速度”，還是要歸功于學姐這么多年梳理出來的流程。就像這個視頻里外國大叔說得一樣，雖然整個工地看上去雜亂無章，但其實每個人都各司其職，他稱其為“organized chaos”。

在推進項目的時候，到底要怎么做到這種“有組織地混亂”呢？學姐會在后文詳細介紹，先讓童鞋們感受一下整個流程，一共分為五大階段，階段里還有不少環節↓

學姐會著重介紹每個流程的目的、方式、參與人員和產出。

2. 沒有“人設”，同事們對你的信任度不高

不知道童鞋們有沒有遇到過這種情況，身邊有些同事做項目總是順風順水的，然鵝一到你的項目，總有人來“找茬”，這其實就是同事們對你信任度還不夠高的表現。

學姐本人曾經被一個老板形容為“非常搞得定研發”，每次轉崗，都會有研發表達惋惜。即使是我現在辭職在家休息了，還經常有研發問我要不要回流。

舉個例子，曾經有一個研發leader（很棒的小姐姐）在我轉崗的時候拉著我說“我們這個業務自從你來了之后，就搞得風生水起嘛”，弄得我都有點不好意思了。這之后過了兩年，她也轉崗了，我負責的新業務正好要給她提需求，那推進可就太絲滑了～

其實，這個業務的業績真有這么好嗎（畢竟我都要轉崗了）？之前負責這個業務的產品難道就不給力了嗎？為什么研發小姐姐就這么愿意做我的需求呢？

這就是建立人設、提升信任度的功勞了。雖然大家平時做項目的流程看上去都差不多，但在這個過程中，還是有很多細節可以幫助你“打造人設”，成為大家心中靠譜的產品經理。

所以，學姐今天這篇文章會“軟硬結合”，在幫助童鞋們優化做項目的流程，也會告訴大家該怎么打造人設，讓同事們愛上（？）做你的需求。

二、需求調研階段

1. 目的

需求的來源是多種多樣的，可以來自于數據分析、用戶調研、客戶調研、競品分析等等，可能是某個老板或者同事提出的，也可能是你哪天洗澡的時候就靈光乍現了（之前某大佬和我說TA在洗澡的時候會琢磨業務）。

但從idea到項目真的啟動，還需要進一步調研。有些童鞋可能把“找需求”和“做需求”的調研混為一談，但其實兩者是不一樣的，前者主要是為了發現問題，后者主要是去調研怎么解決這個問題，對于一個比較大型的項目來說，后者肯定是不能省略的。

2. 方式

調研的形式不限，和“找需求”類似，可以是問卷、訪談，也可以是數據分析、競品調研，只是會更針對你想解決的問題。

至少要調研哪種用戶（who）、在什么場景下（where）、為什么原因（why）產生這個需求，越細越好。比如who就要具體到這類用戶的畫像等等（性別、年齡、收入、愛好、恩格爾……）。有點類似于大家喜歡玩的“沉浸式劇本殺”，有人物的背景，也有布景搭建，甚至可以找到這個人物做每一件事兒的動機。

只有這樣，在需求設計階段（第三階段），我們才能找到“代入感”，在兩個方案中糾結的時候作出更好的判斷，也方便我們對每個功能排優先級。

3. 參與人員

學姐覺得吧，如果是比較大的項目，邀請對業務感興趣或者比較有想法的運營、設計、研發甚至銷售，一定程度參與前期的調研，會大幅提升他們后續參與項目的積極性，也方便后續和他們在這個需求上的想法和你一致。如果他們比較忙的話，你也可以只是把問卷或者數據分析的結果分享給他們。

將心比心，如果有一個人天天動動嘴就讓你幫他干活，你是不是會有點不樂意？所以，我們最好不要直接拿著已經敲定的需求去通知大家干活，能盡量提升大家的參與感是最好的，既方便以后拉他們一起“上船”做項目，也可以打造靠譜的產品人設。

4. 產出

下階段Kick off的ppt或者文檔，演講形式的ppt最佳，必須包含需求的背景和價值、指標提升、功能的優先級、項目上線的大致時間點，最好可以附上調研過程。

三、項目啟動階段

調研完，是不是可以開始寫需求文檔了？當然不是啦，咱是做大項目的，要有個正式啟動的階段。

環節1：組內 Kick off

項目啟動肯定要先讓內部的同事（特別是老板）和你想法一致吧，別到時候開kick off會的時候被老板懟，這就很難看了，也會讓其他部門的人對你的信任度大打折扣。這部分學姐就不贅述了，大家根據自己平時的習慣的方式來就好。

環節2：Kick off會

自己老板這過關了之后，就可以開Kick off會了，Kick off就是足球比賽中開球的意思（學姐剛百度的），現在引申為項目啟動的意思。做大項目可不能偷偷摸摸的，要有儀式感，這就得有一個正大光明的啟動會～

（1）目的

這個會的目的說白了也很簡單，就是把大家都“拉上（你的賊）船”。首先是要保證相干人員都認可你這個項目的價值，愿意為這個項目出力，其次是要保證大家在溝通項目的時候都在一個頻道上，能更快達成共識。

（2）方式

怎么樣保證以上兩點？

① 闡述背景、價值、指標

學姐在上一部分也說到了，調研后產出的ppt一定要包含需求的背景和價值，如果同事們對這些東西都無感的話，就把對預計能對指標的提升寫出來（關于價值和指標可以去看學姐的數據分析寶典）。

如果這些實際的東西都還不能打動同事，那咱就只能用態度去感化他們了～拿出第一階段辛辛苦苦做的用戶調研或者數據分析給他們講解一遍，讓他們感受到你是在很認真地做項目，并不是動動嘴皮子就想指揮他們干活，這也能打造靠譜人設。

② 明確項目時間點

我們需要把自己對這個項目中不同功能的優先級列出來，并把對項目上線時間點的大致預期和原因寫清楚，保證大家對這個時間點都有印象，給大家一些些緊迫感～別讓別人覺得你這個項目完全不急。

③ 設置討論環節

最后，我們還要給大家充分的時間討論，認真地記錄下他們的提問和建議，這樣的好處是可以讓你考慮地更全面，也可以避免項目做到一半，某個同事突然跳出來發表修改意見。如果會上討論不清楚，也可以會后給同事們一倆周時間提建議（言下之意，過期不侯～）。

（3）參與人員

學姐建議把能想到的所有可能相干的同事都邀請進來，不同部門（業務、平臺、中臺等）、不同工種（運營、研發、設計、法務、財務、客服……）一定要保證都邀請到，并且盡量保證每個部門和工種都至少要派一個代表過來。

（4）輸出

輸出的形式是會議紀要，必須包含時間、參與人員、大家提出的問題和你的next step（包括時間點），附件里要有Kick off的PPT↓

四、項目設計階段

調研、啟動階段之后，我們可以啟動設計了。如果時間比較趕的話，在啟動階段的同時就進行設計也可以，但是這樣設計容易返工，因為啟動會上可能還是會有不少同事提出建議的。

這個階段的有4個環節，1是提設計需求，2是設計評審，3是細化需求文檔，當中會穿插技術調研。

環節1：提設計需求

相信在經過第一階段和第二階段后，設計師或者設計師的leader已經對這個項目有了不少了解（被你拉上賊船了），這時候再提需求就比較穩了，做起來肯定會比他們接的那些個臨時提的需求要更有積極性嘛～

（1）目的

讓設計充分了解需求。

（2）方式

設計需求我們一般用文檔的形式去提，并附上之前的Kick off的ppt。文檔會比Kick off的ppt更落實一些，首先要有一個表格寫上這個需求的基本情況，比如平臺、用戶群、使用場景、功能列表、優先級、是否需要視覺等，其次是功能的框架圖、流程圖和線框圖（如果你有的話），最后是一些相關競品的頁面截圖↓

（3）參與人員

一般是先把設計需求提給交互，等交互定稿了再由交互把需求提給視覺。不過如果有一些視覺設計比較重的項目，舉個例子，可能會用到新組件或者新的視覺規范的項目，也可以在提交互需求的時候就把視覺拉上一起參與討論，避免后期視覺讓交互返工。

（4）輸出

如果是較大的項目，至少準備2套不同方向的交互稿/視覺稿。

環節2：設計評審

（1）目的

讓老板和其他相干同事認可設計方案。

（2）方式

設計評審也會分成兩種情況：一些交互比較重的需求，可以先拉上大家一起過交互稿，交互確定了之后再進行視覺設計；如果是輕交互重視覺的項目，可以在群里發下交互稿，如果大家問題不大那么可以等到有視覺稿了再開會評審。如果你覺得拿不準，可以和設計討論之后再決定在哪一步拉會過稿子。

（3）參與人員

原則是先和內部的人過，先叫上自己的老板、設計師老板、同部門的產品、運營，再去找外部的人過，比如客服、法務、其他部門的產品等（當然這個環節暫時不會叫到研發）。同理，這也是避免在外人面前窩里反，造成人設崩塌。當然，在你們根據外部同事的建議修改了稿子之后，也別忘了及時知會到內部人員。

環節3：細化需求文檔

設計稿確定之后，需求文檔就可以寫得比較詳細了，這部分學姐之前有專門的文章介紹，不贅述了。

環節0：技術調研

（1）目的

很多童鞋可能前3個環節都做得挺好了，甚至哼哧哼哧寫了幾十頁需求文檔，但是到了下個階段——也就是需求評審之后，發現研發提了一些可行性的問題，導致設計稿全部推翻重來，一夜回到解放前。所以，這個環節的目的主要是確?？尚行詻]有大的問題。

（2）方式

技術調研一定要穿插在設計階段進行。但設計評審的時候又不方便叫上研發，畢竟那時候設計還沒定稿，如果讓研發參與，他們可能會對設計稿提出一些很“研發”的要求（也就是偷懶）。解決方法也很簡單，找到研發的負責人看一下稿子的可行性，如果他沒空，就讓他給這個項目指定一個前端、一個后端，有稿子了之后私他們一下康康～

（3）輸出

能得到研發小哥哥/小姐姐的一個微笑肯定就行了（這樣咱就當是能做的）。

四、項目開發階段

終于終于，項目可以正式開搞了～

環節1&環節2：內部需求評審會&外部需求評審會

（1）方式&參與人員

需求評審會大家應該都很熟了，做任何需求都要經歷這一步，拿著文檔、叫上研發、設計師、測試一起。同理，也是先找內部的研發（自己部門的）看，再問他們需要拉上哪些外部的研發再開一次評審會。

（2）產出

首先，是研發對需求的修改建議和你對這些建議的next step，比如何時進一步調研、優化方案等，形式不限，可以在寫在文檔里，也可以用會議紀要的形式。寫完并不是就這么算了，一定要及時給研發們反饋，這樣才能讓別人感受到你對這個項目是很上心的，也是進一步打造靠譜的人設～

其次，要明確大概在什么時間點會進行技術評審和測試評審，畢竟那時候才能知道項目的工作量和排期，還有我們最關心的上線時間點。

環節3：技術評審

本環節一般不需要產品參與，大家了解一下即可。主要是技術討論這個方案怎么實現，需要多久，會上會討論出一些對需求的修改建議和工作量的評估，然后進行排期。

環節4：測試評審

本環節一般不需要產品參與，大家了解一下即可。主要是測試人員根據技術實現方案輸出測試用例、工作量，并進行排期，一般會后測試會把用例共享給產品看一下，確認是否覆蓋全。

環節0：方案優化

調整方案是避免不了的，一定會穿插在整個需求開發階段，大家就不要夢想著一次定稿了。調整方案之后一定要知會相干人員，如果是比較小的調整可以在群里溝通，大調整最好再發上一封郵件。另外，學姐在介紹需求文檔的時候也提到過，需求的變更最好要在文檔上留下詳細的記錄。

五、需求上線階段

環節1：測試/配置

本環節主要是測試人員進行的，包括后續的壓力測試/滲透測試等等，學姐就不一一介紹了。另外，項目如果涉及到需要運營配置的，也要提前通知運營，切忌臨時抱佛腳。

環節2：產品&設計驗收

（1）目的

確保產品沒有bug，優化體驗

（2）方式

一般在測試讓研發把P0、P1的bug修完之后，產品就可以參與一起測試和視覺還原了。

①產品測試

有些童鞋可能會覺得“公司不給測試發工資的嗎，為啥還要產品再測一遍？”其實最了解這個項目的還是產品本人，畢竟需求是你寫的，測試人員在理解需求的時候不一定能完全get你的想法，也可能會有一些在文檔上并沒有提到的細節。所以任何項目，產品一定要測一遍主流程，這也是打造靠譜人設的一個環節。

②視覺還原

視覺還原也很重要，一定要叫上相關的設計童鞋一起驗收，學姐多年的經驗，再優秀的研發，眼神也可能會飄，做出來的東西他們自己覺得和稿子一摸一樣，可在學姐眼里那就是毫不相關了～設計師最討厭的就是上線的產品和自己的稿子不一樣了，這會很敗他們對你的印象的。

③打點驗收

打點也是比較容易遺漏的地方，測試和研發一般都會更顧及整個產品的流程是否能走通，對數據采集不會這么敏感，所以產品要驗證一下打點是否正確。畢竟一個項目上線之后數據有遺漏或者數據有錯，那最終倒霉的還是產品。

（3）輸出

Bug list或者視覺修復list，最好包含截圖和優先級，方便研發和測試進行追蹤。

環節3：其他同事驗收

（1）目的

這部分的官方目的和環節2類似，但真實目的其實還是讓這些同事們高抬貴手，不要等項目上線了再來給你提意見，那時候就真來不及了。

（2）方式

IM、郵件通知大家自行驗收或者開會集中驗收，在基本沒有bug和視覺還原問題的時候再進行，避免同事們覺得你這個項目的體驗太垃圾。

（3）參與人員

這部分一定要帶上所有項目相關方，也就是kick off的那些人。

（4）輸出

Bug list或者視覺修復list，最好包含截圖和優先級，方便研發和測試進行追蹤。

環節4：上線

激動人心的時候到了，咱的項目終于可以上線了。

（1）方式

我們可以根據項目的影響面來評估是否要先灰度上線，學姐之前在大廠的時候，涉及到核心頁面的調整會切一小部分流量灰度發布（比如3%、5%），確認沒有用戶投訴和技術指標的異常之后再切全量，避免造成太大的損失，小心使得萬年船嘛。

（2）參與人員

產品、測試、研發、運維等。

（3）輸出

上線郵件。一般會再簡單介紹一下需求背景，附上設計方案、感謝名單，感謝下對項目有貢獻的人，這部分也是可以拉到一些些好感度的，畢竟誰不希望自己的工作被認可嘛～

六、上線后階段

環節1：數據監控

（1）目的

在項目上線之后2-3天，一定要看一下數據。一是確保項目沒有明顯的技術問題（如果有的話，數據會出現很大的波動），二是如果你對自己的項目數據漠不關心的話，其他同事就會覺得你不夠負責。

（2）參與人員

產品，BI等。

（3）輸出

在項目上線兩周～一個月（只要能累積到足夠多的數據），大家就可以輸出數據分析報告啦，如果對數據分析不熟悉的可以看學姐的這篇文章哦。

環節2：項目復盤

有了數據分析之后，我們要開一個項目的復盤會，咱可不能讓別的同事覺得，利用完他們就拋棄他們了吖～一定要有始有終。

如果數據好的話，也可以考慮寫郵件發一封喜報，感謝一下大家，這樣下次他們再接你的需求，才能更有勁兒。所以學姐之前在大廠的時候，也會定期把一些需求（不管是大項目還是小優化）的結果，通過分享會的形式告知大家，讓大家在嗑瓜子、喝奶茶之余，可以對項目再提提建議，那項目的2期不就順理成章了嗎？

當然，項目復盤展開寫又是一篇文章，哪天有空學姐再起一篇咯。

總之，做項目還是挺考驗產品經理的硬實力和軟實力的，硬實力就是你對項目流程的把控，軟實力就是打造靠譜的人設。前者跟著流程來就行，后者要求你在整個流程的中盡量體現自己的積極性和嚴謹度，另外就是將心比心，更公開透明地去和同事們溝通，學姐相信這樣做項目，冰山都會被感動滴（談戀愛同理）～

#專欄作家#

海貝學姐，公眾號：海貝學姐，人人都是產品經理專欄作家。十年大廠產品經驗，精通產品方法論和產品知識。

本文原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基于 CC0 協議