做了好多專案，這次想聊一下怎麼分析專案，算是自己的拙見，也是自己的一點總結吧。
研發工程師的工作就是不斷的處理業務需求，但PM提的需求應該如何來評判、分析呢？我覺得可以從三個方面來考慮，分別是What、Why、How。
What
主要分析做的是什麼？理解專案，是
一切的前提和基礎
。只有深刻的理解專案，專案才有可能做好。
不知道大家曾經有沒有過這個想法：這些PM從哪裡搞了這麼多專案？
想明白這一點，有可能辨別出PM的能力、公司的管理能力。
產品
很多需求來自
PM自己的觀察和規劃
。這和PM能力強相關。
合作過一些PM，他們對業務瞭如指掌，對業務如何發展成竹在胸。年初便規劃好全年或未來三年的計劃，制定好發展骨架。每個專案都是對骨架進行填充。這會讓研發同學有目標、有成就感，覺得未來可期。
還有一些PM會仔細分析資料、經常體驗自己的產品，透過這種方式發現很多問題，然後對產品進行最佳化。
業務
運營、客服等部門往往處於一線，直接對接使用者。他們能收集大量使用者反饋，這些反饋會輸送給PM。
還有一部分來自於產品上自帶的反饋入口。
收到這些資訊後，PM需要想應對之法。這些反饋往往是使用者的痛點，解決後能大幅提升使用者體驗。
反饋的內容很考驗PM的抽象能力，需要判斷是否真的是痛點，選擇合適的解決方案。萬萬不能聽到啥就做啥，否則很可能導致團隊努力做了一年，都不明白自己到底完成了什麼目標。
老闆
還有一部分需求直接來自於老闆。
雖然我覺得老闆應該把控大方向，不應該直接推動專案，但總有一些老闆選擇主動下場，讓產品推進某個專案。
對於這種操作我不是很認同，倒不是說推進的這個專案有問題，只不過這種操作弊大於利。
一是老闆推某個專案，有時候真的可能是腦子一熱，根本沒有調查，
自己覺得不錯
就讓執行了。
二是很多公司向上管理，即使專案收益低，但因為是老闆的需求，便耗費大量人力去做，沒有把人力放到真正重要的地方。記得以前PM讓做一個專案，內容極其複雜，需多部門配合，所有人都懷疑產出，但因為是老闆推動的，大家只能做。最終效果呢？這個專案需要經多長時間才能覆蓋人力成本，我都不好意思說！
公司的前進方向，老闆和PM是對齊的。如果對齊制度不好，就修改對齊制度，如果PM理解得了、執行的好就留，如果PM理解不了、執行不好就換。
內容
產品提出的需求，應該包含以下元素：BRD、PRD、UE、UI
BRD
：即商業需求文件，是基於商業目標或價值所描述的產品需求內容文件，其核心的用途就是用於產品在投入研發之前，由企業高層作為決策評估的重要依據
PRD
：產品需求文件，是將商業需求文件（BRD）和市場需求文件（MRD）用更加專業的語言進行描述
UE or UX
：User Experience 使用者體驗，PM用UE講解需求，使研發、測試等同學有直觀感受
UI
：User Interface 使用者介面，主要給前端同學開發使用
一般透過這四個元素，研發人員能夠理解這個專案需要做成什麼樣子。防止出現下方展示的情況：
最好
最好提前規劃好的專案與一些最佳化、迭代專案並行，而且前者應該佔的比例更大一些。這樣才能建造出穩固的城堡。這也是為什麼我在對產品經理的一些思考裡認為產品經理重要的原因。
Why
瞭解要做什麼之後，需要思考一些問題。這些問題能夠讓我們發現
專案的核心點，能夠脫離於專案看專案
。
為什麼要做這個專案？
這個專案是為了業務發展、為了解決使用者痛點、為了向上管理？很多研發同學覺得這與自己無關，其實是有關的。
對於一線研發同學來說，想明白為什麼要做這個專案，就能明白專案解決的核心問題是什麼。只有分析出主要矛盾和次要矛盾，真正執行時才能有的放矢。
對於技術經理，需要判斷專案在當前階段做是否合適，是否有更重要的事情要做。
其實產品有一個重要的職責就是宣貫專案的重要性，如同打仗之前需要先申明行為的正義性。
專案屬於哪個模組？
系統一般都會有架構圖，需要判斷專案屬於架構裡的哪一部分。
例如電商一般有交易、訂單、使用者等模組，做的專案屬於哪一部分？還是說這個專案為系統擴展出新的模組。
透過這個問題，我們能夠更好的把握系統架構的現狀。
是否有其它方案？
明白專案核心點後，就要想想，PM的方案是否流暢，是否存在更加合理的方案。這也是為什麼一直在說要了解
專案核心點
，因為這是目標，目標只有一個，方案卻能有很多。條條大路通羅馬。
PM提供的方案，在解決核心問題上是否是最優的嗎？是否有更簡單的方案能夠滿足要求？
這裡提一點，儘量不要總是用小技巧完成需求，一定要把握好度。否則可能產生縫縫補補又三年的效果，衣服雖然能穿，但是會一片一片的。系統終究是一個統一的整體。
專案有什麼收益？
專案能帶來多大收益？可以透過哪些資料進行判斷？
這些問題一定要在PM提出需求的時候進行詢問，可以檢驗PM是否真的考慮過這個問題。對於IT類工作而言，資料是檢驗真理的唯一標準。達成資料也是相關參與同學的最終的目標。
當然，有很多專案，在前期無法給出具體的收益，我們也不能因為缺收益資料就不開發專案。
研發和產品需要有資料驅動的共識。
雖然PM無法給出具體收益，但需要用哪些資料來檢視收益是一定要提供的。
需要做的大而全嗎？
根據專案大小、收益，思考功能是否要做大而全，能否將部分內容砍掉，先上線核心點，其它慢慢迭代。
專案快速發展時期，應該採取小步快跑的方式，先滿足最核心需求，即用20%時間完成80%的核心功能。這樣也能快速調整方向，資料不符合預期迅速改變打法。
專案到達穩定期後，可以用80%的時間提升20%的體驗。
這一切都是在理解了專案、知道專案要解決的核心問題、估計好專案產出之後，才能做出的決定。
專案最終會發展成什麼樣？
這是對未來的思考。當前專案並不是最終版本，那最終形態會是怎樣的？
瞭解這一點，對設計當前系統、今後設計相關係統，能做出更高質量的判斷。
How
經過What和Why的思考後，How對研發同學而言更容易一些。
怎麼做可以分兩部分來討論：
一部分是宏觀上的專案管理，可以看專案流程管理
一個是當前專案需要怎麼設計。磨刀不誤砍柴工，專案做得好，一定要有好的技術方案。
技術方案
完成技術方案，邀請相關同學對技術方案進行詳評，能夠確保大家達成一致，實現了從需求層面到技術層面的統一。一份好的技術方案模板，能夠幫我們縷清很多細節點。
對於技術方案中的內容，每一點都需要確認搞明白，不能想當然。
在設計文件的時候，個人喜歡使用資料驅動的方法，先將db設計好，然後在此基礎上思考每一個介面、每一個狀態如何變更。同時思考併發、異常等情況。
這裡提供一份模板供大家參考：
一、專案背景
二、核心需求點描述
（簡要的兩三句話，描述幾個最核心的需求點；描述清楚滿足了哪些使用者、在哪些場景下的哪些需求）
三、技術方案
架構圖&流程圖
異常流程考慮（選填）
例如：對關鍵環節，超時、下游呼叫返回錯誤等如何處理。使用者提示文案會怎樣、是否有重試和補償等
儲存設計（cache，db，es等） 【必填】
（如果有資料庫等重要儲存新增、變更，需把相關設計進行說明）
相容性評估【必填】
介面安全性評估
效能&容量評估
API定義【必填】
建議QA要測試的點（選填）
四、異常情況下業務影響的評估
評估當此系統穩定性、邏輯、對外返回的資料出現異常時，對B/C端核心功能的影響，並評估在其他系統的監控是否完備
五、對賬&資損點&監控評估
六、上線方案
七、小流量方案&計劃
八、線上觀察&監控內容
九、回滾方案
十、評審結果
技術方案 Review
Code Review
上線方案 Review
十一、專案總結
總結在整個專案過程中值得分享的問題，可以是這麼幾個方面：1。 方案設計和需求方面思考；2。 開發和上線過程中遇到棘手問題；3。思考專案流程存在問題；4。其他任何可以分享的經驗
總結
專案分析不但是技術問題，也是管理問題。希望大家不要只沉浸在做專案中，要跳出專案，從更高處理解專案，會有更多的收穫。
資料
UI、UE和UX三者之間的區別？
最後
大家如果喜歡我的文章，可以關注我的公眾號（程式設計師麻辣燙）
我的個人部落格為：https：//shidawuhen。github。io/
往期文章回顧：
設計模式
招聘
思考
儲存
算法系列
讀書筆記
小工具
架構
網路
Go語言