現象
這個月我的工作任務中，有一項是重構oea框架中的autoui部分。這個任務在月初時計畫在乙個月內完成，包括問題分析、設計新的結構、編寫設計文件、開展設計評審、**實現。原計畫半天到一天的評審會議，最後花費了大概一天半的時間。接下來，我就評審會議**現的問題進行一下總結。
本次autoui設計是我到公司以來，覺得最有挑戰的一次工作。
會議之前，我和組內的人員進行了多次溝通，了解他們的需求：我們的autoui框架當前有些什麼問題？當介面需求被提出後，我們對它的完成情況怎麼樣？開發人員對autoui有什麼期望？測試、需求人員對autoui有什麼期望？布局有什麼問題？期望的gix4介面是什麼？
接下來的幾天時間就是不停的對系統進行設計，好幾個問題都是在睡覺的時候想明白的。：）
然後，我們召開了設計評審會議。
參加會議的人不多，但是其間出了許多問題，最顯著的有以下幾個：
1.沒有把要解決的問題講清楚。
*開始設計審查後，發現原來還有人不明白之前的問題。所以又倒退回去解釋要解決的問題。
*有人得出對審核的問題不清晰，並提出每個問題都直接進入技術主題，脫離業務，無法直觀地聯想到gix4相應的業務細節。
*有人得出一次審核的問題不要太多。
2.有人得出應該給在之前就對評審成功後接下來任務進行計畫、估時等。
3.我沒有把我自己設定的假設標記出來。
4.大概只有15%的時間是花在設計的審查上。
5.給大家講清楚設計的過程較為困難。
反思
1. 聽眾對問題的理解程度不一。
評審之前，我的想法是，由於之前已經做過幾次現有問題的溝通，大家對問題已經比較理解了，評審的主要目的是評審我的設計。內容應該是：檢查它是否能達到大家的期望，檢查是否有遺漏、不足、錯誤，討論一下是否有更好的設計方案。另外，我非常想在這個月內完成這次重構，而要完成從分析到實現、測試的整個過程，乙個月的時間是非常短的。所以我在設計完成之後，立刻召開了評審會議。我並沒有對評審會議進行計畫，ppt也沒有寫，沒有分析與會人員的期望，冒冒失失地就召開了評審會議。
主觀上我認為「之前這些問題已經討論過了，沒必要再重複」，所以我很快地把問題都過了，盡快開始設計的審查。但是由於之前討論問題的人員和現在參加評審的人，並不是完全相同，所以導致過程中不斷地被提問：「這個問題是為什麼出現的？」、「它的業務場景是什麼？」、「問題不要太多，最好乙個乙個討論。」……
出現這種情況的本質原因就是我把解釋問題的環節過得太快了！之前我應該想到，評審開始時，最重要的評審人員是哪些，他們對這些問題是否和我已經達成了共誤，如果沒有，我應該如何給他們解釋。換句話說，由於沒有分析與會的人員，所以就武斷地忽略了解釋問題的必要性。
2. 問題確實可以分解。
本次重構中其實還包含別乙個較小關係的模組重構（mvvm模式）。把它加進來一起討論的原因也簡單：該模組比較小，沒必要專門開一次設計評審；我想在autoui重構時把這個問題也解決了，畢竟，mvvm模式解決了，autoui做起來也會更流暢一些。
3. 沒有解釋清楚自己的設計。
這也是乙個很嚴重的問題。我之前粗淺地認為，到時只要對著設計稿先講一下總體的結構，然後乙個子模組乙個子模組地講解，就可以解釋清楚了。但是還是沒有達到預期的效果。主要原因是：還是因為內容分解得太快，這次再加上乙個更抽象的結構圖，效果可能會更好。（限於篇幅，具體方案我會另起一篇文章來分析如何講解自己的軟體設計稿。）
4. 對評審會議的認識問題。
我對問題已經達成共識的假設、對評審會議內容的理解錯誤，都造成了溝通不便。引用周哥的話說，「評審也是溝通的過程」、「你清楚的別人不一定清楚」、「設計過程也需要給我們說清楚」。只有結果是不夠的。
5. 沒有做評審通過後的任務計畫。
這個其實也算是對評審會議的理解有誤。評審會議不只是評審！應該還包括其後具體的任務計畫。而不應該認為，「如果評審不通過，這步就浪費了。」其實這一步需要的時間不多，完全可以抽出時間來完成它。這個步驟應該放在評審之前就完成，以方便大家對未來要做的任務有乙個清晰的認識，也反過來更好地理解整個設計。
6. 沒有對評審做準備工作。
就算按照我之前的想法，大家進行進入設計評審環節。我同樣沒有在評審之前就想清楚：如何給大家解釋清楚我的設計方案。
這一點單獨提出來再說一遍，是想對自己強調一件事：時間再緊，也必須要抽出時間來為會議進行準備工作；ppt可以不要，但是對整個會議的計畫還是需要的，形式用公司的五環策劃表就很不錯。
改進
. 如果是第一次做某件事，最好向有經驗的人先請教，了解整個流程。
. 在時間允許的前提下，一次只做一件事。
. 按照易理解的分解程度來分解你的內容。
. 謹記：急於求成可能會浪費更多的時間。
. 對重要的會議始終要進行策劃。
. 分析你的參會人員。
. 設計評審會議不只是評審設計結果，還需要評審：問題、設計過程、之後的任務計畫。
. 溝通的時候，要指明哪些是假設。
2023年12月份的反思
最近在單位根本沒看書了。相比以前每個禮拜還會有一定的進展，現在根本停滯不前了。原因分析如下 書房被破壞了。對策 先暫時搞無需長時間使用書桌的專案，比如程式設計，看電子書 老是在基礎的學科漫遊，沒有切實感受到自己程式設計能力的提公升，優點洩氣。對策 把100題完成，反覆思考揣摩學到的內容。不知道現在自...
12月14日考試題反思
本大周學習了遞迴和高精。又進行了考試，結果爆零了，總結後是自己沒掌握。還是看題吧！第一題大意 給兩個字串，找出重疊字元輸出對數並排列。題看了很久才明白意思，前面幾問的思路是有的，可排列函式sort的用法卻忘了，想了許久，還是先敲 為上。最初 如下 include using namespace st...
JZOJ8月6日提高組反思
又是愉快的沒落的一天 被2020 2018暴打day2 一堆人ak 看到這個 m 只有100 就堅定了我打暴力的信心 離散化加暴力匹配 原本就想 30 結果70 o 一開始想的貪心被自己證偽了 所以就去打暴力了 20半點問題都木有 想到說要先把每個數各自的最優點求出來 然後這兩個最優點相連 但是不會...