口水記
今天參加了團隊內一個新功能的技術評審，雖然自己不參與開發&設計，不過去蹭蹭經驗也是挺好的，關於一些需求/設計提下自己的建議。
從需求評審一直跟到了技術評審。
由於時間比較緊急，屬於倒推項目，雖說後面增加了幾個後端開發，但是懂的都懂。
他們各自負責一部分功能的開發，技術方案出的也是比較急的，且最近的幾個週六都需要加班。
相較於正常的開發這次功能，這次的項目整體時間，壓縮了30%左右吧。
在技術評審的時候就體現了一些出來。
首先說說明顯的不足吧，然後再說說改進
不足：
- 由於時間問題，技術評審明顯缺少了一些設計，想哪寫哪，直接寫的接口，技術評審完全變成了接口評審
- 開發人員分工協調問題，相同功能，兩個人重複過了，在會上才確認人
- 開發對於需求不思考目的，不關心後續的一個發展，該功能上線便萬事大吉
第一點
首先針對第一點的問題，雖然時間很緊，但是必要的一些方案還是不可少的。
簡單的描述，就是下面幾點：
- 功能的UML圖
- 系統整體架構
- 數據庫設計
- 核心功能的流程圖
- 是否使用了團隊之前未使用到的新技術（發現在很多團隊並沒有這點的一個說明，這點其實挺重要的，特別是對於一些倒推項目，很容易導致延期）
上面幾點是基於整個團隊來思考的，文檔中應該要有的。
而且在技術方案中，應該是需要過的。這次的技術評審，只有一個開發，我看到了一個UML圖，至於整體的架構，那是完全沒有，功能的流程圖，也是沒有，數據庫設計，更是沒有說明。
對於這樣的技術方案，其實應該是要打回的。這次的一個技術評審，完全開成了接口評審。
後端和前端過了過接口，然後就完了。。。
第二點
其次第二點，相同功能，多個人同時做了技術方案。
原因我分析一下：應該是這次的功能跨了小組。
很明顯就是前期沒有進行一個後端開發的內部協調，這是技術經理的一個失職。
- 多人合作，分工要明確，提前協調好，確定技術經理/項目經理，需要有一個整體把控的人
第三點
第三點，其實很多開發都有，不思考爲什麼我們要做這個需求，這個功能在團隊/公司層面看來，需要達到一個什麼目的或者說是預期結果，值不值得（這也是爲什麼，很多開發不敢去懟產品，在我看來，很多情況下應該懟產品，懟需求，這說明你去思考了，你不只是站在一個開發的角度去思考需求的實現了）。
後續這個功能要怎麼發展，按照現在的一個技術方案，能不能支撐後續的一個數據量/併發。這些其實在技術方案中都是應該去思考的一件事情。
正常來說，一個新功能的架構和設計，應該要支撐至少2-3年。這個是需要數據來評估的，普通開發可能不在意，但是作爲一個技術經理，是應該去考慮的事情。
需求評審
今天還另外參加了一個需求評審，這次是我需要參加開發了，雖說手上並行着項目開發，但是沒辦法。
不過這個需求中有幾個功能被懟回去了（對於自己懟不回去的，直接反饋到上級說明情況，不要一直和產品經理扯些沒用的，一般來說，扯不過），爲什麼要懟。花費大力氣開發一個無法達到效果的功能，對於團隊來說，就是在浪費資源。
（注意，這裏的懟並不是破口亂罵，而是用正當的理由去說服產品。我和公司的產品，私下關係還是不錯的。但是要分清楚不能因爲私下關係好，就偷偷接需求哈，這是兩碼事）
現在產品正在改那幾個需求功能了。
小結
今天感觸還是挺多的
主要還是技術評審，以及和產品之間的互懟。
今天記了挺多了，總結就兩句話。
技術評審不是接口評審，該有的技術方案都應該在技術評審中體現出來，技術評審要達到的效果是能夠讓沒做過這個需求的人，看完技術方案，可以很快的明白技術架構，功能流程以及數據庫設計；
參加需求評審，多思考需求的目的，預期，解決什麼問題。
不正經語錄
- 懟產品，懟需求，說明你對需求有了自己的思考，而不是對產品經理有意見
- 評價技術方案怎麼樣，就看團隊新人看到這個技術方案，能多快接手這個功能，需不需要開小竈
- 倒推項目，加人是沒問題的，加時間就不要想了
聲明
本文故事純屬遐想，如有雷同，我是原創。
歡迎轉載。
轉載請務必註明以下信息。
原作者：諳憶
原文地址：https://copyfuture.com/blogs-details/20200521194057394736l4log7y6utwj
公衆號
更多精彩內容、活動、程序猿的小故事，歡迎掃碼關注公衆號
