前段時間看到一個童鞋在後臺留言，一個idea要怎麼樣才能變成線上的產品？學姐回想了下，在自己初入行的那會兒，確實會面臨“idea多，結果少”的情況。相信很多來做產品經理的童鞋都是懷揣著滿腔的想法，結果進公司後發現，扯皮、推鍋的事兒很多，推進大專案並不是這麼簡單。
為啥專案推進總是不順利？
撇開專案本身價值有問題的情況不討論，無非是這兩個原因：
1. 流程問題
做大專案的流程，平時做普通需求的流程顯然不一樣，很多童鞋對這部分並不熟悉，或者說熟悉但不精通。
這就讓學姐想到了前幾天看到的一個影片，還挺有意思的，講的是重慶有倆大型商場要趕在聖誕節前開業，一個外國大叔實地探訪開業前的36小時。只見商場裡幾乎空無一物，建材堆的到處都是，看上去就像一個工地，甚至要帶安全帽。聖誕節當天，這倆商場就奇蹟般地正常營業了，客流量還挺大，沒有任何一個環節掉鏈子，影片的結尾大叔開始感慨“中國速度” ↓
學姐看完影片後覺得，這不就是咱上線一個產品的真實過程嗎？上線前還有長長的buglist，視覺還原問題至少十幾個，老闆們還在那兒各種提意見～一陣手忙腳亂後，專案竟然準時上線了，甚至沒有任何bug和客戶投訴。要做到這種“中國網際網路速度”，還是要歸功於學姐這麼多年梳理出來的流程，就像這個影片裡外國大叔說得一樣，雖然整個工地看上去雜亂無章，但其實每個人都各司其職，他稱其為“orginized chaos”，在推進專案的時候，到底要怎麼做到這種“有組織地混亂”呢？學姐會在後文詳細介紹，先讓童鞋們感受一下整個流程，一共分為五大階段，階段裡還有不少環節↓
學姐會著重介紹每個流程的
目的、方式、參與人員和產出
。
2. “人設”問題，同事們對你的信任度不高
不知道童鞋們有沒有遇到過這種情況，身邊有些同事做專案總是順風順水的，然鵝一到你的專案，總有人來“找茬”，這其實就是同事們對你信任度還不夠高的表現。
學姐本人曾經被一個老闆形容為“非常搞得定研發”，每次轉崗，都會有研發表達惋惜；即使是我現在辭職在家休息了，還經常有研發問我要不要回流。
舉個例子，曾經有一個研發leader（很棒的小姐姐）在我轉崗的時候拉著我說“我們這個業務自從你來了之後，就搞得風生水起嘛”，弄得我都有點不好意思了，這之後過了兩年，她也轉崗了，我負責的新業務正好要給她提需求，那推進可就太絲滑了～其實，這個業務的業績真有這麼好嗎（畢竟我都要轉崗了）？之前負責這個業務的產品難道就不給力了嗎？為什麼研發小姐姐就這麼願意做我的需求呢？
這就是建立人設、提升信任度的功勞了。雖然大家平時做專案的流程看上去都差不多，但在這個過程中，還是有很多細節可以幫助你“打造人設”，成為大家心中靠譜的產品經理。
所以，學姐今天這篇文章會“軟硬結合”，在幫助童鞋們最佳化做專案的流程，也會告訴大家該怎麼打造人設，讓同事們愛上（？）做你的需求。
01 需求調研階段
目的
需求的來源是多種多樣的，可以來自於資料分析、使用者調研、客戶調研、競品分析等等，可能是某個老闆或者同事提出的，也可能是你哪天洗澡的時候就靈光乍現了（之前某大佬和我說TA在洗澡的時候會琢磨業務）。但從idea到專案真的啟動，還需要
進一步調研
。有些童鞋可能把“找需求”和“做需求”的調研混為一談，但其實兩者是不一樣的，前者主要是為了發現問題，後者主要是去調研怎麼解決這個問題，對於一個比較大型的專案來說，後者肯定是不能省略的。
方式
調研的形式不限，和“找需求”類似，可以是問卷、訪談，也可以是資料分析、競品調研，只是會更針對你想解決的問題。
至少要調研哪種使用者（who）、在什麼場景下（where）、為什麼原因（why）產生這個需求，越細越好，比如who就要具體到這類使用者的畫像等等（性別、年齡、收入、愛好、恩格爾……）。有點類似於大家喜歡玩的“沉浸式劇本殺”，有人物的背景，也有佈景搭建，甚至可以找到這個人物做每一件事兒的動機。只有這樣，在需求設計階段（第三階段），我們才能找到“代入感”，在兩個方案中糾結的時候作出更好的判斷，也方便我們對每個功能排優先順序。
參與人員
學姐覺得吧，如果是比較大的專案，
邀請對業務感興趣或者比較有想法的運營、設計、研發甚至銷售，一定程度參與前期的調研
，會大幅提升他們後續參與專案的積極性，也方便後續和他們在這個需求上的想法和你一致。如果他們比較忙的話，你也可以只是把問卷或者資料分析的結果分享給他們。
將心比心，如果有一個人天天動動嘴就讓你幫他幹活，你是不是會有點不樂意？所以，我們最好不要直接拿著已經敲定的需求去通知大家幹活，能儘量
提升大家的參與感
是最好的，既方便以後拉他們一起“上船”做專案，也可以打造靠譜的產品人設。
產出
下階段Kick off的ppt或者文件，演講形式的ppt最佳，必須包含需求的背景和價值、指標提升、功能的優先順序、專案上線的大致時間點，最好可以附上調研過程。
02 專案啟動階段
調研完，是不是可以開始寫需求文件了？當然不是啦，咱是做大專案的，要有個正式啟動的階段。
環節1：組內 Kick off
專案啟動肯定要先讓內部的同事（特別是老闆）和你想法一致吧，別到時候開kick off會的時候被老闆懟，這就很難看了，也會讓其他部門的人對你的信任度大打折扣。這部分學姐就不贅述了，大家根據自己平時的習慣的方式來就好。
環節1：組內 Kick off
自己老闆這過關了之後，就可以開Kick off會了，Kick off就是足球比賽中開球的意思（學姐剛百度的），現在引申為專案啟動的意思。做大專案可不能偷偷摸摸的，要有儀式感，這就得有一個正大光明的啟動會～
環節2：Kick off會
這個會的目的說白了也很簡單，就是把大家都“拉上（你的賊）船”。首先是要保證相干人員都認可你這個專案的價值願意為這個專案出力，其次是要保證大家在溝通專案的時候都在一個頻道上，能更快達成共識。
環節2：Kick off會
怎麼樣保證以上兩點？
目的
學姐在上一部分也說到了，調研後產出的ppt一定要包含需求的背景和價值，如果同事們對這些東西都無感的話，就把對預計能對指標的提升寫出來。
如果這些實際的東西都還不能打動同事，那咱就只能用態度去感化他們了～拿出第一階段辛辛苦苦做的使用者調研或者資料分析給他們講解一遍，讓他們感受到你是在很認真地做專案，並不是動動嘴皮子就想指揮他們幹活，這也能打造是靠譜人設。
方式
1. 闡述背景、價值、指標
我們需要把自己對這個專案中不同功能的優先順序列出來，並把對
2.
和原因寫清楚，保證大家對這個時間點都有印象，給大家一些些緊迫感～別讓別人覺得你這個專案完全不急。
明確專案時間點
最後，我們還要給大家充分的時間討論，認真的記錄下他們的提問和建議，這樣的好處是可以讓你考慮地更全面，也可以避免專案做到一半某個同事突然跳出來發表修改意見。如果會上討論不清楚，也可以會後給同事們一倆周時間提建議（言下之意，過期不侯～）。
專案上線時間點的大致預期
學姐建議把能想到的所有可能相干的同事都邀請進來，不同部門（業務、平臺、中臺等）、不同工種（運營、研發、設計、法務、財務、客服……）一定要保證都邀請到，並且儘量保證每個部門和工種都至少要派一個代表過來。
3．設定討論環節
輸出的形式是會議紀要，必須包含時間、參與人員、大家提出的問題和你的next step（包括時間點），附件裡要有Kick off的PPT↓
03 專案設計階段
調研、啟動階段之後，我們可以啟動設計了，如果時間比較趕的話，在啟動階段的同時就進行設計也可以，但是這樣設計容易返工，因為啟動會上可能還是會有不少同事提出建議的。
這個階段的有4個環節，1是提設計需求，2是設計評審，3是細化需求文件，當中會穿插技術調研。
參與人員
相信在經過第一階段和第二階段後，設計師或者設計師的leader已經對這個專案有了不少了解（被你拉上賊船了），這時候再提需求就比較穩了，做起來肯定會比他們接的那些個臨時提的需求要更有積極性嘛～
輸出
讓設計充分了解需求
環節1：提設計需求
設計需求我們一般用文件的形式去提，並附上之前的Kick off的ppt。文件會比Kick off的ppt更落實一些，首先要有一個表格寫上這個需求的基本情況，比如平臺、使用者群、使用場景、功能列表、優先順序、是否需要視覺等，其次是功能的框架圖、流程圖和線框圖（如果你有的話），最後是一些相關競品的頁面截圖↓
環節1：提設計需求
一般是先把設計需求提給互動，等互動定稿了再由互動把需求提給視覺。不過如果有一些視覺設計比較重的專案，舉個例子，可能會用到新元件或者新的視覺規範的專案，也可以在提互動需求的時候就把視覺拉上一起參與討論，避免後期視覺讓互動返工。
目的
如果是較大的專案，至少準備2套不同方向的互動稿/視覺稿。
方式
參與人員
讓老闆和其他相干同事認可設計方案。
輸出
設計評審也會分成兩種情況：一些互動比較重的需求，可以先拉上大家一起過互動稿，互動確定了之後再進行視覺設計；如果是輕互動重視覺的專案，可以在群裡發下互動稿，如果大家問題不大那麼可以等到有視覺稿了再開會評審。如果你覺得拿不準，可以和設計討論之後再決定在哪一步拉會過稿子。
環節2：設計評審
原則是先和內部的人過，先叫上自己的老闆、設計師老闆、同部門的產品、運營，再去找外部的人過，比如客服、法務、其他部門的產品等（當然這個環節暫時不會叫到研發）。同理，這也是避免在外人面前窩裡反，造成人設崩塌。當然，在你們根據外部同事的建議修改了稿子之後，
環節2：設計評審
。
目的
設計稿確定之後，需求文件就可以寫得比較詳細了。
方式
參與人員
很多童鞋可能前3個環節都做得挺好了，甚至哼哧哼哧寫了幾十頁需求文件，但是到了下個階段——也就是需求評審之後，發現研發提了一些可行性的問題，導致設計稿全部推翻重來，一夜回到解放前。所以，這個環節的目的主要是確保可行性沒有大的問題。
也別忘了及時知會到內部人員
環節3: 細化需求文件
。但設計評審的時候又不方便叫上研發，畢竟那時候設計還沒定稿，如果讓研發參與，他們可能會對設計稿提出一些很“研發”的要求（也就是偷懶）。解決方法也很簡單，找到研發的負責人看一下稿子的可行性，如果他沒空，就讓他給這個專案指定一個前端、一個後端，有稿子了之後私他們一下康康～
環節3: 細化需求文件
能得到研發小哥哥/小姐姐的一個微笑肯定就行了（這樣咱就當是能做的）。
04 專案開發階段
終於終於，專案可以正式開搞了～
環節0：技術調研
環節0：技術調研
需求評審會大家應該都很熟了，做任何需求都要經歷這一步，拿著文件、叫上研發、設計師、測試一起。同理，也是先找內部的研發（自己部門的）看，再問他們需要拉上哪些外部的研發再開一次評審會。
目的
首先，是研發對需求的修改建議和你對這些建議的next step，比如
方式
進一步調研、最佳化方案等，形式不限，可以在寫在文件裡，也可以用會議紀要的形式。寫完並不是就這麼算了，一定要及時給研發們反饋，這樣才能讓別人感受到你對這個專案是很上心的，也是進一步打造靠譜的人設～
其次，要明確大概在什麼
技術調研一定要穿插在設計階段進行
，畢竟那時候才能知道專案的工作量和排期，還有我們最關心的上線時間點。
輸出
本環節一般不需要產品參與，大家瞭解一下即可。主要是技術討論這個方案怎麼實現，需要多久，會上會討論出一些對需求的修改建議和工作量的評估，然後進行排期。
環節1&環節2：內部需求評審會&外部需求評審會
本環節一般不需要產品參與，大家瞭解一下即可。主要是測試人員根據技術實現方案輸出測試用例、工作量，並進行排期，一般會後測試會把用例共享給產品看一下，確認是否覆蓋全。
環節1&環節2：內部需求評審會&外部需求評審會
調整方案是避免不了的，一定會穿插在整個需求開發階段，大家就不要夢想著一次定稿了。調整方案之後一定要
方式&參與人員
，如果是比較小的調整可以在群裡溝通，大調整最好再發上一封郵件。另外，學姐在介紹需求文件的時候也提到過，需求的變更最好要在文件上留下詳細的記錄。
05 需求上線階段
產出
本環節主要是測試人員進行的，包括後續的壓力測試/滲透測試等等，學姐就不一一介紹了。另外，專案如果涉及到需要運營配置的，也要提前通知運營，切忌臨時抱佛腳。
何時
時間點會進行技術評審和測試評審
確保產品沒有bug，最佳化體驗
環節3:技術評審
一般在測試讓研發把P0、P1的bug修完之後，產品就可以參與一起測試和視覺還原了。
環節3:技術評審
有些童鞋可能會覺得“公司不給測試發工資的嗎，為啥還要產品再測一遍？”其實最瞭解這個專案的還是產品本人，畢竟需求是你寫的，測試人員在理解需求的時候不一定能完全get你的想法，也可能會有一些在文件上並沒有提到的細節。所以任何專案，產品一定要測一遍主流程，這也是打造靠譜人設的一個環節。
環節4:測試評審
視覺還原也很重要，一定要叫上相關的設計童鞋一起驗收，學姐多年的經驗，再優秀的研發，眼神也可能會飄，做出來的東西他們自己覺得和稿子一摸一樣，可在學姐眼裡那就是毫不相關了～設計師最討厭的就是上線的產品和自己的稿子不一樣了，這會很敗他們對你的印象的。
環節4:測試評審
打點也是比較容易遺漏的地方，測試和研發一般都會更顧及整個產品的流程是否能走通，對資料採集不會這麼敏感，所以產品要驗證一下打點是否正確。畢竟一個專案上線之後資料有遺漏或者資料有錯，那最終倒黴的還是產品。
環節0：方案最佳化
Bug list或者視覺修復list，最好包含截圖和優先順序，方便研發和測試進行追蹤。
環節0：方案最佳化
知會相干人員
這部分的官方目的和環節2類似，但真實目的其實還是讓這些同事們高抬貴手，不要等專案上線了再來給你提意見，那時候就真來不及了。
環節1：測試/配置
IM、郵件通知大家自行驗收或者開會集中驗收，在基本沒有bug和視覺還原問題的時候再進行，避免同事們覺得你這個專案的體驗太垃圾。
環節1：測試/配置
這部分一定要帶上所有專案相關方，也就是kick off的那些人。
環節2：產品&設計驗收
Bug list或者視覺修復list，最好包含截圖和優先順序，方便研發和測試進行追蹤。
環節2：產品&設計驗收
激動人心的時候到了，咱的專案終於可以上線了。
目的
我們可以根據專案的影響面來評估是否要先灰度上線，學姐之前在大廠的時候，涉及到核心頁面的調整會切一小部分流量灰度釋出（比如3%、5%），確認沒有使用者投訴和技術指標的異常之後再切全量，避免造成太大的損失，小心使得萬年船嘛。
方式
產品、測試、研發、運維等
1. 產品測試
上線郵件。一般會再簡單介紹一下需求背景，附上設計方案、感謝名單，感謝下對專案有貢獻的人，這部分也是可以拉到一些些好感度的，畢竟誰不希望自己的工作被認可嘛～
06 上線後階段
2. 視覺還原
3. 打點驗收
在專案上線之後2-3天，一定要看一下資料。一是確保專案沒有明顯的技術問題（如果有的話，資料會出現很大的波動），二是如果你對自己的專案資料漠不關心的話，其他同事就會覺得你不夠負責。
輸出
產品，BI等
環節3：其他同事驗收
在專案上線兩週～一個月（只要能累積到足夠多的資料），大家就可以輸出資料分析報告啦。
環節2：專案覆盤
有了資料分析之後，我們要開一個專案的覆盤會，咱可不能讓別的同事覺得，利用完他們就拋棄他們了吖～一定要有始有終。如果資料好的話，也可以考慮寫郵件發一封喜報，感謝一下大家，這樣下次他們再接你的需求，才能更有勁兒。所以學姐之前在大廠的時候，也會定期把一些需求（不管是大專案還是小最佳化）的結果，透過分享會的形式告知大家，讓大家在嗑瓜子、喝奶茶之餘，可以對專案再提提建議，那專案的2期不就順理成章了嗎。
當然，專案覆盤展開寫又是一篇文章，哪天有空學姐再起一篇咯。
總之，做專案還是挺考驗產品經理的硬實力和軟實力的，硬實力就是你對專案流程的把控，軟實力就是打造靠譜的人設。前者跟著流程來就行，後者要求你在整個流程的中儘量體現自己的積極性和嚴謹度，另外就是將心比心，更公開透明地去和同事們溝通，學姐相信這樣做專案，冰山都會被感動滴（談戀愛同理）～
環節3：其他同事驗收
所有人問「貼吧之父」俞軍
產品經理的思考利器——UML新晉管理者容易犯的3種管理錯誤
目的