艾偉也談項目管理，個人管理：從昨天的一個設計評審來談如何與人交流你的設計思路

　　評審并不是審判，你直接說出結果之後，然後等着判官下筆，評審一定是基于特定主題進行的，所讨論的東西都圍繞這個主題，那麼如何讓人先清晰你的這個主題是需要考慮的。對于不同人來說，每個人關注視角不一樣，是以還需要針對這個主題，對于不同場合、不同參與者，你需要使用什麼方式來講哪些内容才能夠讓參與者都清晰。

技術是為業務服務的，再考慮技術時一定需要想想為實際業務做了什麼

你清楚的别人不一定清楚

一般自己做的設計會覺得很簡單，可維護很好，但是沒有做過的人了解起來很可能是相反的

你覺得簡單的别人不一定覺得簡單

就拿自己來說，我以前看些書覺得非常難，過了兩三年後，再看之後發現這些書就像入門書一樣。自己不同時期對難易了解不一樣，更何況對于不同人來說呢

你對問題的了解不一定是對的

每個人對問題的深度挖掘能力是不一樣的，有的人隻看到表象，而有的人喜歡探索真正的問題，對問題的了解不一樣會導緻後續交流評審的内容完全不一樣

你的比選方案選考慮因素不一定全面的

即使問題了解都一緻，由于每個人的經驗是不一樣的，你的比選方案不一定是全面的

你的具體方案并不一定是最好的

即使你決定了具體方案，但也不一定是最好的，可能還可以在這個方案基礎上再優化一些内容

評審也是溝通的過程

如何結構化的、從上往下或者從下往上、分塊的闡述你的問題和設計？不要再還未了結需要讨論的内容以及必要性之前就直接進入細節，否則大家此時的溝通頻道并不是在一個台

問題是否正确？

由于是重構，是以我希望一開始看到的是羅列出來的現存的一些問題。

對這些問題，我們可以通過一句話的簡單描述就都清楚，要是太長了估計就是多個問題。

把多個問題放在一起同時講會導緻溝通不暢。

對問題的正确性進行讨論

問題的深層原因？

問題描述清晰之後，我就會問為什麼會出現這個問題？

是純技術問題還是業務問題？如果是業務問題，必須拿出現有的實際例子來描述這個問題；如果是技術問題，就需要從品質屬性去描述。

如果是有論據的一定拿出論據，如果是假想的一定說出是有待驗證的

對深層次原因進行讨論

針對各個問題，逐個從上往下進行分析讨論？

總體講完之後，我不喜歡跳躍式的逐層闡述每個問題，我更希望依次讨論完每個具體問題

針對具體問題你是如何思考的？

對問題的解決方案有哪些？

你是否有考慮過多個方案？

每種方案有何優缺點？

為何選擇目前這種方案

開發人員如何使用你的架構？

對于做平台和架構的人來說，這個問題是必須問題。

如果是基于模型驅動開發的，還需要考慮你的架構是否可以支援模型驅動開發？

下一步的粗略計劃？

優先級也是需要考慮的，特别是項目組中馬上就開開發的情況下

可能你的方案需要幾周或者更長時間，接下來三天你會做什麼？接下來一周你會做什麼？