1. 頭腦風暴
此會議有個很響亮的名字，你或許也被人拍著肩膀說：hi，有空沒？一起來風暴一下。
這種在中國人來看不就是乙個茶話會嗎，結果老外們很認真給命了名，而且還發展出一套規範來。
但我們記住了它的名字，卻沒有引入早已成熟的章法，所以這種會常開得亂七八糟，人神共怒，最容易延遲。
所以，開頭腦風暴會議前，作為組織者，要先有乙個譜在心裡，在沒有獲取對於頭腦風暴充分的知識之前，請不要輕易嘗試頭腦風暴！抱怨頭腦風暴無效的，往往是因為自己沒有有效組織，而與會議本身無關。
使用階段：
頭腦風暴定位於無限制的自由聯想和討論，其目的在於產生新觀念或激發創新設想。可以被應用到任何階段：
和其他大部分會議不同，頭腦風暴不是決策會，而是主意大會。
頭腦風暴的原則：遵循這些原則，讓頭腦風暴更加有效。
對主持人的建議：
控制，不要對某個想法過於深入，也不要離題太遠。
兩頂帽子：做主持人，也做參與者。做主持人話不要太多，隱身起來但是時刻要進行控制。
關於控制，舉個例子，比如，在開始頭腦風暴前，你的ppt可能第一頁會放：
然後，在你解釋了你們為什麼這麼做的好處和意義之後，你的乙個ppt可能是這樣的：
2. 線框圖評審會
對於互動設計師來講，線框圖評審會是再熟悉不過了。我不像內部分享一樣展開述說了。有興趣的郵件給我。
正如我之前的《為線框圖多留些時間》一文所言，往往線框圖階段會花費比視覺更多的時間，線框圖的過程正是把不確定轉化為確定，把確定轉化為方案，把方案轉化為規格引數的過程。這就意味著，這個過程一定是有著很多次評估、討論、評審和確認。
在不同的階段，面對不同的人，有：
2.1 線框圖內部評審會
也叫初審，定位是「problem discussing」，先和需求方（很多時候是產品經理），在互動設計前期，一起討論一下待確認的問題。所以定位為「問題討論會」。
說到這裡，不得不提一下專案流程。流程因專案和公司而已，若你所參與的專案流程和我說的不一樣，也沒啥好糾結和爭論的。即時在阿里巴巴，也不見得都是走我說的這種流程。大體上一致，細節上不同。偷偷說一句，我是個流程式控制。我從兩年前就不斷對這個流程進行修訂，一直到現在，我覺得它可以解決大型和中型產品開發專案的很多問題。
在我定義的流程裡，確定了要做什麼東西後，產品經理與互動設計師就同時開工努力去**這個產品要有什麼功能，以及功能詳細的方案和實現。產品經理去撰寫prd(產品需求文件)，而互動開始做線框圖。兩者同時開展工作目前是被證實比較有效同時能夠結合兩者長處的合作方式（要知道，在去年的時候，流程未調整時，總是有互動設計師在抱怨說，每次什麼都確定好了，就讓他出個原型圖，這時他即時對產品需求有質疑或者有建議，被接受也比較難）。
無論是 prd和線框圖都需要不斷迭代著逐漸細化，而prd初審和線框圖內部評審就是迭代過程中的會議。
階段：互動設計前期，prd初審之後（這並不嚴格要求，有些產品若設計本身的重要性大於商業規則，則可以是由互動主導的，prd可以在互動之後寫乙份功能規格清單而已）。
目標：逐漸縮小可能性範圍，明確方向
有人說，既然已經有prd評審，為何還需要線框圖內部評審會呢？
所以，線框圖內部評審最好有的角色是：
這是保證設計質量的重要會議，也是重大的決策會，充滿了是和否的判決，在血雨紛飛中，道路卻越來越清晰了，不再存在太多選擇。
承載物：粗略線框圖、問題列表等。
2.2 線框圖專家評審：
大的方向定了，但是圍繞某個功能點的設計上，解決方案仍然是非常多的，介面如何展現，排版布局以及細節互動等。產品經理有時並不關心這個，在缺乏可用性測試資源時，邀請其他設計師或者行業專家來進行專家評審是成本最低的評估。
與內部評審不同，這裡的結果可能不再是「是」或者「否」，而是「好」，「不好」。
這定位成為「ask for feedback」。強調這個，正是為了建議組織人也就是互動要轉變立場和態度，有時我們開確認會開多了，就會很遮蔽別人的建議，面對挑戰也好，建議也好，總是第一反應不是take，而是push回去，別人一問就解釋，別人一提建議就否決，那就沒有了專家評審的必要了。
你只是徵詢建議，只要存在問題，或許你需要的不是解釋，而是詢問為何會產生這樣的問題，其次才是回答。
產生階段：互動設計中後期，線框圖確認之前。
會議目的：為設計質量把關，徵求建議，接受反饋，優化設計方案
參與人：做這個專案的互動設計師，以及可邀請到的其他互動設計師（人數在5到6個就可以了），產品經理（在場的話，不但能夠幫忙解釋產品的背景，在涉及到萬一有可能修改商業邏輯時也節省了解釋成本），前端和開發代表，在場可以幫忙就每種方案提供技術評估。
承載物：多種解決方案的線框圖，如：
2.3 線框圖技術評審
到此，不但大方向確定了，連分岔的羊腸小道也被關閉了。但是還會有技術評審，人少時，是個規模很小的會議，達成目標就可以了。
目的：向前端和工程師詳細講解設計需求。讓他們當面溝通技術解決方案以及配合模式。
補充一下，在這個會議之後，就真的一切變數都沒有了。不要把技術可行性評估放到這個會議上，給他們看的就是可行性的方案，評審的是怎麼做，怎麼配合而不是能不能做。關於能不能做的問題，在之前的內部評審以及專家評審上就應該解決。
承載物：詳細線框圖和設計說明文件
階段：這個會議可以根據情況放到frd終審之前或者之後。
有時不可避免還會有一些線框圖和frd的細微調整，發個郵件再確認一次就可以了。
這幾個會議，只所以放出來，是因為這是互動設計師主要要組織的會議，當然有些專案需要增加一線框圖確認會，當涉眾很多而且很在意介面和互動細節時，且在prd確認時並未將重點放到這些地方上。
和產品經理的會議如何配合呢？如圖：
整個專案裡，還有kick off，uc評審，tc評審，發布計畫評審……不說了，反正我也說不太清楚。
六.向有效的會議前進
終於到了最後一節了。這一節是分享一些關於如何組織會議的心得。
前面說了，現在很多的會議，因為缺乏有效，導致要麼我們是被別人浪費時間，要麼是自己去浪費別人的時間。
不管別人如何做，我們能不能保證，自己不做罪惡的人，首先，你能保證你組織的每次會議都能夠準時結束嗎？
工作中遇到的幾個的總結
程式設計規範中有一條，條件判斷式使用雙等號 時，應該將常量放在雙等號左側，變數放在右側。遵守該條規範可以避免出現所謂的 差一錯誤 即將雙等號寫成等號。這種情況下，編譯器會報錯。在乙個資料庫connection操作中不能巢狀另乙個資料庫操作。否則會引起資料庫connection鏈結異常。這個問題在低頻...
二 python程式設計中那些重要的事
作用域是學習所有程式語言需要明確的乙個概念。python作用域查詢順序總結為legb。在說明這個原則之前，我們先明確乙個作用域分類 模組作用域，乙個模組中的變數，需要通過模組名稱引用，也稱跨檔案引用。內建作用域，內建模組預先賦值的好名稱，如open.全域性作用域，乙個模組頂層的變數所處位置。外層作用...
設計模式在工作中的應用（二）
這裡我們不介紹如何進行解析生成sql語句，怎麼解析的不重要，只要知道這些都是解析類，轉換為sql語句的不同部分。我是想說說針對上面的需求，我是如何考慮的。需要能夠使用sqlserver的函式？大概想一想，感覺很容易啊，不就是封裝乙個函式類，實現sqlserver資料庫的函式。是的，最根本的實現也就是...