一本正經需求洽談老黃曆
本篇文章是寫給跟我一樣的普通工程師小哥看的，大佬請繞道，主要聊聊，怎麼搞定我們工作中所遇到的來自很多人的形形色色的需求，我把絕大多數的需求都放在這四個階段去想，每個階段都有它固有的一些方法，每個階段都有它固有的手段。
一個需求從構思到上線到維護，不可避免經歷上邊這麼幾個階段。決定要去想，這個需求是不是要做，這是需求的初始端也是需求的來源，需求的來源總是源自某些人的某些思考或者拍腦袋，畢竟拍腦袋也是思考的一種。決定要去設計，這個階段需求大方向其實已經定了，需要去思考怎麼設計你的架構來滿足這塊事情。決定怎麼落地，這個階段其實架構都已經定了，需要思考的是跟誰一起合作怎麼去把這個需求做成。決定怎麼上線，這個階段會有各種各樣的限制，以及各種各樣的資料遷移過程。
決定要去想
需求可能來自產品經理的一句話，嗯，某某某平臺裡有一個功能，我們也要上。第一想法是什麼？"傻的，別人有我們就要做咩。"其實大可不必，我們先上他們平臺去看看，取其精華去其糟粕，好的我們就借鑑，然後再跟產品經理聊這個事情的可行性。
需求可能來自產品經理的一句話，嗯，這個業務大佬說要做這個A需求，我們得在這週五完成上線。第一想法是什麼？"傻的，要不五分鐘後上線好了"。這個時候我們要做的事情呢，是去了解從產品經理口中出來的所謂的業務大佬的這個需求的真正意義，最好是跟業務大佬直接對話，好好思考業務真正的需求以及這麼著急上線背後的思考。
這個階段其實很多時候都是一些人的一些天馬行空的東西，不要著急去落地，也不要著急去設計，優先找到最核心的人，諮詢清楚這件事情背後的意義，再旁敲側擊諮詢更多的人，蒐集更多的資訊，再做出你自己的判斷。
宜：
一份文件，二次確認，三次交談。
忌：
一口答應，二話不說。
決定要去設計
好了，需求確定需要，嗯這個玩意我們是要做了，也知道要做成怎麼樣的東西了，完美我們要自己設計一個從頭到尾的方案。停。別什麼事情都想著自己徹徹底底完成，對於小專案來說還行，對於大專案來說這絕對不可能的，蒐集可用的靠譜服務，借力打力。
這個階段要不要一次性設計好所有的東西呢？其實未必需要，這個階段肯定是來來回回的，我們設計好一個比較基礎的版本後，及時溝通，保證這個設計是符合使用者的需求的。設計得七七八八，要學會自己進行沙盤演練，考慮更多的情況，在紙上甚至腦裡進行沙盤推演，保證方案的可行性以及方案的契合程度。
設計的階段，需要多多考慮能否借力打力，以及隨時驗證。
宜：
借力打力，隨時驗證，沙盤推演。
忌：
設計一個來自老鐵的666火箭。
決定怎麼落地
好了，大體架構已經基本確定了，該思考怎麼落地了，這個階段一般要進行詳細設計了，一般來說這個階段在細化的時候都會跟原先的需求可能會有一些出入，所以在設計完技術方案之後，要跟兄弟團隊的同學一對一溝通好大家的邊界以及分工合作的方法。所有的方方面面都溝通完之後，組織大家進行一次技術評審，並且在這個時候確定最終的排期以及各方的對接人。這個階段一般都要產出自己系統相關的技術方案，甚至各個介面各個欄位，系統間互動，最終產出的驗收標準。
宜：
一對一溝通，技術方案確定後再聊排期，方案要落地成文件。
忌：
拉一大波人開一些無關的會。
決定怎麼上線
這個階段會出現在開發得七七八八的時候，要做一些系統上線的處理。系統部署依賴關係以及部署計劃要梳理一下，灰度計劃要設計一下，資料庫怎麼上線要梳理一下，資料庫歷史資料遷移要考慮一下，系統監控要提前設定一下免得不知道上線效果。整理成一個checklist，一個一個檢查，確保萬無一失。
宜：
依賴梳理，監控梳理，細心確認。
忌：
一波部署，聽天由命。
以上