要善於提問題，能夠提出問題，就解決了問題的一大半，問題的高度解決了所處的高度，一個大問題分解成多個小問題，逐步去迭代
不過這些都沒用，問題是如何去提問題？
有哪些具體可執行的操作
如果是參加講座或者閱讀文章等有明確觀點的可以通過下面的結構化方式。
尋找論題與觀點
對方要討論的問題是什麼，觀點是什麼，只有找到了對象想要討論的論題以及立場，大家纔有了初步的共識，一般在閱讀文章、論壇時比較容易找到論題與論點。而在參加分析或者講座時不太容易捕捉，因爲上面演講的人一直在表達，有論據，有觀點，有論據，並且比較隨性，如果邏輯不夠清晰的，很難去get到對方的點，必須要聚精會神，理清對方的思路。
尋找論據
論據分爲兩種，一種是文章或演講或者討論中明確提出的理由，另外一種是沒有明確提出的理由，也就是對方默認的一些觀點，如果是演繹性論證（遵守數學中的充分條件），比較容易尋找這些假設，例如今天老大說要把一個二方庫拆成兩個，咋一看確實也應該拆，兩個包好像不太一樣，但是停下來想想哪種情況會導致一個功能從一個二方庫拆分出來呢，老大給出的理由是“內聚性更好，依賴更乾淨”，那這個論證的論據就是：
1. 這個功能是個獨立的功能，內聚性比較好
2. 內聚性的功能應該獨立出來（沒有明確說出來的）
這個推理過程中確實1.2可以推到出結論，但是2很明顯是有問題，因爲原有的包中有很多比較小的獨立模塊，都是合在一起的。可以通過這樣的方式來挖掘充分條件來尋找明確和不明確的論據。但是生活中往往不是演繹性論證，也就是並不是強的充分條件，例如上面的例子中，我也贊同拆分二方包，但是不能通過具體的幾條理由來強勢的證明，只能說這樣做可能更好，後面也跟老大討論了下，補充了下面兩條理由
1. 這部分功能不太會給外部使用，而目前的其它功能是會的
2. 這部分功能是一種富客戶端的行爲，而不是簡單的常量與接口定義
加上了上面的兩條之後會讓拆分的行爲跟具有說服力（有一個假設是具有較多不同的特性的功能應該獨立出來）。
尋找模糊詞語
在論點與論據中都有可能存在模糊的地方，這也是平時接觸很多的地方。比如在軟件工程中經常聽到的一句話
函數應該儘量短小
那什麼叫短小，多長的函數叫小呢，是1行，還是10行，有些書籍會推薦一個數，比如說20行，這確是比較明確了，但是通常也無法給出令人信服的理由。