這個題目很難寫的。 每一個人的思考問題的方式都不同,即便同一我的對待不一樣問題或者同一個問題不一樣場景也會有不一樣的策略。 可是有沒有通用的解決方案?框架
問題原本是抽象的, 通常的, 其答案也是通常的,不會對待特定問題直接給出答案,可是對於問題有指導做用, 廢話一大篇。學習
Polya 在書中給出了一個解題框架。測試
1. 理解題目優化
理解什麼是未知量,什麼是已知量,什麼是條件。未知量表明什麼? 能用符號或者圖表示出來嗎?ui
是否能夠用本身的描述清楚? 從而理解問題是什麼,對問題有一個整體的認識。 google
2. 制定計劃
spa
對於如何解這道題目,給出一個思路或者規劃,這是最有挑戰的一部分。 設計
對於題目,能夠找出已知與未知之間的聯繫? 如何找,這是一個技術活。 Polya在書中給出了本身的一些間接,簡單直觀有用。 從本身已有熟悉的題目入手,熟悉的定量入手,或者曾經作過的某些相似的方面入手。項目管理
若是還找不到聯繫,嘗試從另外的角度複述這個題目? 試着從定義入手?這道題目的更廣泛化的題目是什麼? 更特殊的題目是什麼? 能轉換一道熟悉的題目? 題目已知條件能夠 改改嗎? 未知條件能夠改改嗎? 須要引入其餘輔助的元素? 你用到全部的條件嗎? 用到全部的數據嗎? 開發
3. 執行計劃。
執行方案,保證每一步都正確。你能證實每一步是正確的嗎?若是不同,能夠是計劃出錯仍是執行問題?
4. 檢查和反思。
檢查題目的正確性。 題目的每一步解答是否正確? 結果是否容易驗證? 特殊狀況(特殊值)是否也成立? 通常狀況是什麼樣子?
反思就是經驗教訓總結。題目是否是還有別的思路,別的解法,嘗試看看。比較之間異同? 哪個更好一些?更直觀簡單不出錯?
這個題目有什麼結論,能夠爲之後利用上? 這個題目的解答,分析,思路,有什麼能夠借鑑的? 這個題目的解答是否還能夠優化? 是否能夠替換掉冗餘或者複雜的部分? (這就是觸類旁通, 若是讀書的時候能夠作到這一點,或許就接近學霸啦:) )
感受Polya這個方案很容易推廣到通常問題的解決框架。
1. 理解問題。
什麼是問題? 問題就是實際和指望之間的差距。
瞭解什麼是指望, 目標,需求?能具體嗎? 什麼是現實狀況? 中間的差距是什麼? 有多大?
Beyond what you see。 瞭解問題的深層次緣由。
問題不是憑空開的出來的。 問題是從哪裏來的?爲何會有這個問題? 問題對應的場景是什麼? 它的上下文是怎樣? 定性是什麼?定量又有什麼?
利益分析, 問題從誰哪裏來的? 問題沒有解決誰會受益? 或者受害? 若是沒有解決,誰會受害或者受益?
若是沒有理解問題,就直接執行或者關注細節,如同沒有看病沒有診斷,直接開藥。可是這一步每每會被不經意的忽略掉。
2. 制定計劃。
尋找思路,制定規劃。這個都是最關鍵的一部分,一個挑戰。不一樣問題,其解不同,很難有一個統一的思路。固然對於豐富多彩的世界,千奇百怪的問題,不可能有一個one-to-all 的銀彈。對於這個時間點的本身,很難系統的給出一個方法了,或許是孜孜不倦的追求了。
總結本身經常使用的方法:
好比: 窮舉與啓發。 計算機中經常使用到的。窮舉問題域全部可能確定能夠,可是耗時耗力成本高。啓發能夠快速解決,可是難度大。 好比家裏東西不見,能夠大掃除,必定容易找到;也能夠根據判斷再那裏丟的,何時丟的?期間本身呆過那些地方? 通常很大機率能夠找到。
好比: 對比。 對於修理東西,無論軟件硬件這個方法均可以嘗試。 一個好的,一個壞的。 兩者之間一個一個比對,局部替換,總歸能夠能夠找到問題。 好比修機器,好比配置文件出錯了。
好比: 類比。 對於相似的問題,相似的問題本身是如何解決的? 某些屬性是類似的,其餘方面是否是也能夠借鑑呢?
好比: 自治。 對於大問題,打碎。各個擊破。 好比搭建一個環境。分塊,分層解決。
好比: 抽象和特化。 對於問題的通常描述是什麼?這個問題通常有什麼思路? 對於這個問題的特殊狀況,有什麼借鑑的思路?
嘗試,反證法,沒有任何頭緒,能夠反問是什麼阻滯,妨礙了問題的解決。
嘗試,迭代。 每次作一部分,增量完成。
其餘模式:
模式1: 散彈聚焦。迭代
模式2: 黑盒白盒灰盒子(對比,類比)
模式3: GIAF(Google is a Friend)
模式4: RTFM (Read the f*nk manual)
模式5: 諮詢他人。 身邊有經驗的或這方面專家,或者社區尋找幫助。
對於通常那的技術問題,google is your friend 或者 read the f*uk manual,get info from community。 能夠解決大多數的問題,或者獲得思路。
3. 解決問題。
按照計劃去執行。每每會有同計劃不同的地方? 實際狀況和指望的不同? 那麼就應對這些變化? 或者有風險,應對風險。 (怎麼和PMP同樣呢?)
讀萬卷書,行萬里路。 沒有實踐壓根不知道計劃的好壞? 就是在牛逼的理論沒有檢驗,只是停留在口頭。遺憾白搭。
4. 檢查,經驗教訓總結。
對於問題自己是否解決了? 麼有解決,重新迭代一次。
解決了,經驗總結,那些作的好? 能夠保留借鑑。 那些作的很差的? 值得提升。
對於問題自己解決了,有哪些能夠值得發揚廣大,乘勝追擊,擴大戰果? 那些能夠優化? 那些能夠更好? 二度定律(見到的規律都是另一個定律的一種特殊狀況)
對於解決問題的思路, 有什麼能夠借鑑的? 有什麼能夠學習的? 有什麼和之前的不同?
其實如同生活裏面的走路。 去哪裏? 怎麼走? 走過去? 若是走歪了走偏了,如何發現和糾正? 走完後,給下一次走路經驗教訓總結。
解決問題依賴的因素。
1. 態度和動力。
問題不能迴避,否者一樣的問題會出現。 根據本身的生活經驗,這個我堅信。
2. 知識儲備
巧婦不能無米之炊。好比沒有計算機知識,去fix 一個bug? 沒有醫學知識,去看病?
3. 心智
邏輯推理,如何提問,獨立思考。
4. 個性
自信與堅韌。
對應無其不有的世界,這個方法對於不一樣的領域有着不一樣的變種,可是感受有着某種相似:
好比1: 如何fix bug?
1. 重現問題。
2. 定位問題。
3. Fix bug。
4. 迴歸測試。
前兩點就是理解問題,第三點就是制定計劃,解決問題。 第四點就是經驗教訓總結。
好比2:如何PMP中的通常項目管理。
項目啓動章程,計劃(計劃說明說3個基準),執行,監控(計劃與實際比較,採起措施糾正),結束(經驗教訓總結)。
一切皆項目,這個也能夠看作解決問題的一個通常框架。
項目章程對於理解問題; 項目的計劃對應於解決問題的計劃,這個一樣也是難點; 執行與監控,這個與問題執行也同樣的,PMP更將強調變化。 結束與反思,經驗教訓總結。
按照對於問題的定義,項目也是一個大問題。可是和問題解決思路是同樣的。
好比3: IT中敏捷,scrum
Planing meeting1 ---需求的定義--->對應於理解問題----》對應於項目管理的章程
Planing meeting2---任務分解,估算時間,分配給具體的人-----》對於項目管理的計劃階段-----》解決問題
daily Meeting-------執行任務報告狀態和風險管理---->項目管理的執行和監控
review meeting----- 對於執行的結果,是否知足須要----》項目產品的經驗教訓
retrospective meeting----對於執行的過程當中的反思---》經驗教訓
迭代iterate -------對應於增量開發。
好比4:戴明環。
計劃,執行,測量,處理
也就是定義問題、制定計劃、執行、反饋處理==》再次迭代
好比5:胡適的「 大膽假設,當心求證」 ==》 對應計劃和執行,迭代。
好比6: 本身最近本身解決的一個問題安裝R環境:
好比7:最近公司軟件質量問題。 開會說是bug比較多,可是麼有 任何對於此問題的深入理解,就直接給處方。忽略掉第一步。
應該怎麼作?
軟件質量有問題? 具體是什麼樣的狀況啊?
是用戶不會使用? 仍是可用性比較差? 仍是實施沒有實施好? 仍是用戶業務有變化? 是bug數量太多,support的速度跟不上?仍是新feature,support 的知識沒更新?
是測試覆蓋率跟不上? 仍是測試時間不夠?仍是測試技能不夠? 仍是測試對於用戶如何使用軟件不清楚?仍是測試對於領域知識不夠? 仍是build'不穩定?
是開發的質量很差?歷史緣由,代碼維護不太好? team 之間溝通不夠? 仍是技能不夠?仍是第三方依賴或者外部依賴不對? 仍是開發節奏太快,開發趕時間? 仍是開發流程太複雜?仍是設計太難?
仍是解決方案太差,沒有抓住用戶問題?
仍是發佈速度太快,其餘方面沒有跟的上而致使的?
仍是你們的態度問題?是由於協做,溝通問題?仍是對於產品不看好?激勵不到位?
這些bug分類嗎,2/8原則找到最主要的?
對於問題沒有理解,指望找出好的辦法,有針對性的辦法? 若是生病不去診斷,蒙着眼睛抓藥。這樣企圖康復的機率有多大?
對於人生,也同樣,若是沒有目標? 那一切也無從談起.