fbpx

站長成長週報 039 – 如何做出好的決策 004

這是 Soft & Share 對訂閱會員所推出的服務,站長 MaoYang 透過站長週報分享一週來的學習心得 ( 每週日晚上發表 ),先前發表的站長成長週報請參考這裡

本週時事感想

上週我在 slack 分享了一篇文章 – 「聽完說書,不用翻書」的說書人商業模式可行嗎?(高雄律師談網紅創業),按照這篇文章的說法,我寫站長成長週報跟大家分享的閱讀畫線筆記其實也有觸犯的著作權的問題

所以我自我檢討,未來我跟大家分享我的閱讀心得,我會以我在看這本書時我想到一些過去的經驗與想法和主題閱讀關聯 ( 例如這本書的想法也有出現在另外一本書 ,另外一本書的切入角度不一樣,但是概念是一樣) 為主。書中的細節大家有興趣再自行買書來看。

這週我們繼續閱讀一本書 – 零偏見決斷法,如果你沒有閱讀過這本書也可以跟著我的腳步一起來閱讀這本書

目前我的閱讀進度是第四章 – 找到曾解決類似問題的人

筆記

以下的筆記來自這個章節後面的重點摘要

1需要更多選項卻卡住時,想辦法找到曾解決類似問題的人

2向外尋找:競爭分析、標竿尋找、最佳實務

「山姆・沃爾頓到各處參訪賣場,發現聰明的顧客結帳方法。」

3內部尋找:找到亮點。

「凱瑟的領導者在集團內的醫院裡找到解決敗血症問題的先驅團隊,並且把解決方案推展到所有醫院」

「你可以從自己的亮點裡學到什麼(例如上個月是哪四天去健身房的)?」

4特別注意:爭取主動,把最棒的做法製作成「清單」

「檢核表可以讓人避免犯錯,清單則可以激發新的想法。
廣告人休斯與強生運用清單迅速發想出很多創新構想。
刪減預算的清單有可能讓趨吉與避凶兩種心態快速切換──能否這邊多砍一點,用來多投資在其他地方?」

5尋找點子的另一個地方:從遙遠處尋找,透過類比的方法拾級而上。

「凱文・敦博:類比是科研工作解決問題的一大支柱。科學家經常透過類似的實驗與類似的微生物,讓研究工作往前推進。
拾級而上:登上低處的梯階可以看到小範圍的類比(風險低,新奇的程度小);爬上高處的梯階,得以看見範圍更廣的解決方式(風險高,新奇的程度大)。
費歐娜・費爾赫思特爬上樓梯,分析所有可以快速移動的東西,包括鯊魚和魚雷,因而設計出能游得更快的泳衣。」

6當你可以隨意取得這世上像自助餐那麼多的選項時,何必勞神苦思?

心得與感想

✍ 關於摘要第一點與第二點的感想

我在幾年前才真正理解 Mentor ( 導師 ) 這個角色的重要性,無論你的工作是工程師,業務,甚至你準備要創業或是正在創業,有一位可以諮詢的 Mentor 是很重要的,Mentor 不只要找一位,因為你遇到的問題,不見得每位 Mentor 都遇的到,Mentor 給出了建議,接下來就是你自己的判斷力跟執行力了

必須要注意一點的是,培養出自己解決問題的「洞察力」也很重要,最好的是你發現了問題,有了自己的想法,然後可以找一位可以討論的 Mentor 來檢視這個想法好不好?而不是在「腦袋一片空白」的狀態下去找 Mentor 詢問,這種方式只能解決一時的問題,無法解決長期的問題

我有一次在一本商業模式的書籍看到一個問句很不錯( 這個案例在很多書上都看得到 ) ,如果你在做電子商務網站,你可以問一下自己,如果這個網站換 Amazon 的 CEO 貝佐夫來經營,他會做哪些事情來讓這個網站變得更好?如果你在做產品開發,或是產品經理,你可以問一下自己,如果這件事情由 Steve Jobs 來主導,他會覺得這個產品有哪些方面做的不夠好?

使用名人的角度來找問題的選項前提是你平常要多看這些名人傳記,從傳記中找到他們的思維模式,長期下來,你就可以有「無形的 Mentor」,在遇到問題時,切換到他們的視角,也可以找到很多選項。

我在創業過程有沒有找過 Mentor ?有,他也給我了不少的建議,但最大的問題反而是出在我自己的執行力,所以我搞砸了 🙁

✍ 關於第三點的感想

我在一家公司曾經做過跨部門的協調 ,當時這家公司的掃瞄器測試演算法每個部門的標準不太一樣,造成生產線出問題時就出現很大的爭議,當時我遇到跨部門溝通時遇到最大的問題應該就是「穀倉效應」,每個部門有自己的方法,也不太願意跟另一個部門分享,所以當你要在內部「取經」時要特別注意這個現象。最後的問題你會發現「人的阻力」往往比問題本身的「阻力」還要大,這時候你就要使用華頓商學院談判課程講的許多技巧來說服他人

✍ 關於第四點的感想

這邊的會員大部分都有軟體開發背景,軟體開發有所謂的「最佳實踐」,這些實踐是許多軟體開發團隊所累積出來的,但是要套用「最佳實踐」要懂得「裁切」還有持續改進。並不是所有的「最佳實踐」在每個團隊中都適用。

最有名的軟體開發最佳實踐清單當屬 – 約耳測試:邁向高品質的12個步驟

  1. 你有使用原始碼控制系統嗎?
  2. 你能用一個步驟建出所有結果嗎?
  3. 你有沒有每天都重新編譯建立(daily builds)嗎?
  4. 你有沒有問題追蹤資料庫(bug database)?
  5. 你會先把問題都修好之後才寫新的程式嗎?
  6. 你有一份最新的時程表嗎?
  7. 你有規格嗎?
  8. 程式人員有沒有安靜的工作環境?
  9. 你有沒有用市面上最好的工具?
  10. 你有沒有測試人員?
  11. 有沒有在面試時要求面試對象寫程式?
  12. 有沒有做走廊使用性(hallway usability)測試?

約耳之前在微軟擔任軟體專案經理,後來自己開了幾家公司,最有名的就是 Trello 跟 Stack Overflow 這兩個線上服務,他平常有在寫 blog ,也將這些文章集結了兩本書,裡面許多觀念到目前為止都還適用軟體開發團隊

我們上次讀的華頓商學院最受歡迎的談判課程七章 – 整理 : 一套好用的談判工具清單,也是最佳實踐清單的範例。

對於個人發展也有所謂的「最佳實踐清單」,如果你自己還沒有建立屬於自己一份邁向成功的「實踐清單」,可以先參考別人的,然後再逐漸去修改成屬於自己的「清單」( 這本書也有提到找到自己的「亮點」)。

與成功有約:高效能人士的七個習慣(全新修訂版」,這就是最有名的一份自我實踐清單。

✍ 關於第五點的感想

關於類比,我們在 站長成長週報 010 – 成為發現問題與定義問題的人才 中有提到三種後設思考法,第一項就是 – 抽象化、類推。類推的「類」也就是這本書講的類比方法。

「類比」的方法最好的方式就是要有多元的興趣,然後讓自己的大腦切換到「發散模式」( 例如運動,散步,深度睡眠 ) ,則可以很容易將不相關的事物給連結再一起,這時候要記得記錄下來,這些筆記累積久了就是你自己發揮創意的絕佳來源。

如果你要創業,多收集一些商業模式是有幫助的,你也可以從別人已經發展成熟的商業模式「類推」到另一個產業。

第五點中提到的「拾級而上」也就是在講「抽象化」的能力,「抽象化」能力要做得好,必須將範圍擴大,這跟我們在做物件導向設計抽象化類別的能力很像。

「站在樓梯低處的梯階,可以看見跟我們非常相似的情境,由於情況類似,可以找到顯而易見的解決方案,成功的機會當然是比較大的。當爬上樓梯的高處,有機會看到從其他領域引發的更多選項。然而,這些選項需要跳躍式的想像力,或許會帶來無法預期的突破,但也蘊藏高度失敗的風險。」

附帶一提,我在看「拾級而上」這個小節,讓我想到「被討厭的勇氣」這本書的第四夜中的「傾聽更大的共同體之聲」,如果你也看過被討厭的勇氣這本書 ,可以將這兩個部分一起複習一下,看看其相似之處在哪裡?

這個網站採用 Akismet 服務減少垃圾留言。進一步了解 Akismet 如何處理網站訪客的留言資料

Powered by WordPress.com.

Up ↑

%d 位部落客按了讚: