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

　　昨天專案組進行了一個設計評審，主要是對OpenExpressApp的AutoUI部分進行重構，我相當於評審人。大家也可以把這個評審過程當做與人交流你的設計思路的一個過程，以下從我評審的一些要素來談談與人交流設計思路時需要考慮的內容，也許對大家在實際工作中的架構、設計和溝通都有所幫助。

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

影響我評審關注的一些觀點

• 技術是為業務服務的，在考慮技術時一定需要想想為實際業務做了什麼
• 你清楚的別人不一定清楚
  一般自己做的設計會覺得很簡單，可維護很好，但是沒有做過的人理解起來很可能是相反的
• 你覺得簡單的別人不一定覺得簡單
  就拿自己來說，我以前看些書覺得非常難，過了兩三年後，再看之後發現這些書就像入門書一樣。自己不同時期對難易理解不一樣，更何況對於不同人來說呢
• 你對問題的理解不一定是對的
  每個人對問題的深度挖掘能力是不一樣的，有的人只看到表象，而有的人喜歡探索真正的問題，對問題的理解不一樣會導致後續交流評審的內容完全不一樣
• 你的比選方案選考慮因素不一定全面的
  即使問題理解都一致，由於每個人的經驗是不一樣的，你的比選方案不一定是全面的
• 你的具體方案並不一定是最好的
  即使你決定了具體方案，但也不一定是最好的，可能還可以在這個方案基礎上再優化一些內容
• 評審也是溝通的過程
  如何結構化的、從上往下或者從下往上、分塊的闡述你的問題和設計？不要在還未了解需要討論的內容以及必要性之前就直接進入細節，否則大家此時的溝通可能不在一個頻道

我的一些提問

• 問題是否正確？
  • 由於是重構，所以我希望一開始看到的是羅列出來的現存的一些問題。
  • 對這些問題，我們可以通過一句話的簡單描述就都清楚，要是太長了估計就是多個問題。
  • 把多個問題放在一起同時講會導致溝通不暢。
  • 對問題的正確性進行討論
• 問題的深層原因？
  • 問題描述清晰之後，我就會問為什麼會出現這個問題？
  • 是純技術問題還是業務問題？如果是業務問題，必須拿出現有的實際例子來描述這個問題；如果是技術問題，就需要從質量屬性去描述。
  • 如果是有論據的一定拿出論據，如果是假想的一定說出是有待驗證的
  • 對深層次原因進行討論
• 針對各個問題，逐個從上往下進行分析討論？
  • 總體講完之後，開始依次討論完每個具體問題，不要跳躍式的這裡講一點，然後那裡講一點，弄得聽的人都暈了
  • 針對具體問題你是如何思考的？
• 對問題的解決方案有哪些？
  • 你是否有考慮過多個方案？
  • 每種方案有何優缺點？
  • 為何選擇當前這種方案
• 開發人員如何使用你的框架？
  • 對於做平臺和框架的人來說，這個問題是必須先問問自己的。
  • 如果是基於模型驅動開發的，還需要考慮你的框架是否可以支援模型驅動開發？
• 下一步的粗略計劃？
  • 優先順序也是需要考慮的，特別是馬上就要實施你的解決方案了
  • 可能你的方案需要幾周甚至幾個月的時間，你清楚接下來三天自己會做什麼？接下來一週你會做什麼？

 

推薦：你可能需要的線上電子書

 

歡迎轉載，轉載請註明：轉載自周金根 [ http://zhoujg.cnblogs.com/ ]