網際網路公司管理研發流程，常常使用TAPD一類的敏捷工具。一個需求從提出到上線要經歷至少七個流程：
初級工程師往往做不好需求評審工作。要麼被產品經理牽著鼻子走，讓幹什麼就幹什麼；要麼預估不到隱藏的工作量，在開發排期階段給出不合理的排期，導致開發時間緊張，最後加班應付測試。
以下探討的需求評審和技術方案設計等內容，都用電商的需求《優惠券管理平臺》來舉例說明。
需求標題：優惠券管理平臺
需求背景：當前使用者下單結算不支援任何優惠折扣活動，行銷人員無法採用多樣化的手段留存和獲客。
需求內容：規劃優惠券管理平臺，運營人員申請行銷預算，批次生成優惠券，贈送優惠券給不同畫像的使用者。購物車支援使用者下單時使用優惠券。後臺管理增加兩大模組：1.行銷預算管理；2.優惠券管理（設定優惠券模版、生成優惠券、贈送優惠券）。
詳細設計：篇幅過長，略。
我們常常說研發人員也要有產品思維，並不是產品思維多麼寶貴，而是沒有產品思維，就不知道怎麼拒絕產品經理的需求。面對任意一個需求，都要發起對產品經理的三連追問：
十個產品九個抄，很多產品經理的需求缺乏後續規劃。他們沒有完成產品的閉環思考，先抄襲別人的創意試試水。產品需求檔案裡面可能會出現前後邏輯矛盾，研發人員要抓住這些矛盾，給予重重的嘲諷，幫助他們改善工作。
如果一個需求的目的，無法用簡短的話說清楚，就是不內聚的，要拆分需求後再分析。研發人員可以將需求拆分為3類：
產品需要技術實現產品，研發需要產品展示價值，兩者的利益是一致的。研發人員在質疑需求合理性時，措辭上要處在「為了產品更好」的基調上。如果需求被駁回，部分產品經理會擡出上一級領導壓人，比如「這是李總要做的，你能怎麼著」。如果需求確實荒謬，要上升到管理層去決定，否則產品經理會玩成慣性。
拿到一個需求，尤其是週期長、功能多的需求，要考慮多個方面來設計技術方案，做到低成本、高效能、可維護。
沒有一勞永逸的方案，適應一定階段的變化即可。要與產品經理溝通，基本確定未來幾個月的變與不變。在《優惠券管理平臺》裡面，優惠券的產生、使用、核銷三個狀態的流轉是確定的，而使用規則可能會變化，一開始可能隨便用，後來演變成按商品分類、品牌劃分。針對變的部分要考慮可延伸性，比如資料庫欄位型別採用JSON，或者設計規則擴充套件表。
以業務領域為界限，規劃每個微服務工程的職責。在《優惠券管理平臺》裡面，優惠券是新業務，至少需要一個新微服務。行銷預算與優惠券不是強關聯的，未來可能贈送禮品卡或者實物紀念品，行銷預算的程式碼不能寫在優惠券的微服務裡面。
根據介面存取次數或者前端埋點統計，預估業務產生的資料量，估值越具體越好。例如: 雙十一活動中，預估發放優惠券100萬個，購物車結算頁面查詢優惠券介面達到1000QPS。根據這些結論，才能更好的規劃資料庫表的分片設計、查詢介面的效能設計。
避免洩漏使用者資料，將敏感資訊如手機號、銀行卡明文顯示在頁面中；暴露的連結是否包含敏感引數，比如行銷簡訊內容的推廣連結包含使用者ID。
給前端使用的介面是否防刷；存取外部介面要設定存取超時時間。
編寫技術方案檔案有兩個作用，一是用於技術評審，二是方便接盤俠參考。檔案至少包括6個要點：