踩雷無數的狐狸先生

在還是學生時代, 常常為了返回遙遠的家鄉, 會跟陌生的同學一起, 共同乘坐一輛車, 大家多少補貼一些油錢或是買杯飲料給開車的人, 這樣的目的是為了節省車資, 路上有人相伴的感覺是額外的樂趣 這些資訊在學校的各個平台間流竄, 盡可能地想要湊滿人數, 讓自己可以分最少的錢 世界各國的窮學生都有一樣的想法,  大家想盡辦法提供媒合,  甚至就發展出專業且可以營利的服務 2012 年美國出現了 Lyft,  這是一個在城市內提供駕駛和乘客的配對服務, 他們不是在配對之間抽取佣金, 他們的駕駛是不收取費用的,  但是Lyft 會提供一個建議的捐獻金額給乘客, 再讓乘客自己評估要捐獻多少, 沒有強制乘客要付多少錢... 駕駛可以利用通勤的時間提供車上的空位,可能會有一筆額外的收入 乘客可以省去搭計程車昂貴的車資 聽起來多麽的美好!!  但是當規模大到一定程度, 開始有投資人進入公司的時候, 這種美好的分享情懷還很存在嗎？ 公司如果想要賺更多的錢, 就是要能搓合更多的駕駛和乘客 最簡單的方法就是讓駕駛在一趟的服務中賺更多的錢, 這樣他們才更願意接受那些原本不會接的乘客, 或是可以繞一點點路完成配對 最後發展成多數的駕駛不再只是因為順路而提供座位,  他們開車就是想透過這個服務賺到更多的錢.... 而這還是共享經濟原本的初衷嗎？

想像一下, 假如你可以建造一座共享的城市, 在那裡人人都是創業家,  那種已經沒落的在地與私人行小商店再度的繁榮, 想像一個促進社會的蓬勃城市, 那裡沒有閒置的空間, 所有的資源都可以被有效的利用, 一切都能於他人共享. 一個生產力更強, 卻沒有更多浪費的城市 這是Airbnb 最原始的願景 分享經濟是年輕且迅速不斷改變的潮流, 初衷是向他人分享自己閒置的資源,時間,資產促進群體或社會可以享有跟充足, 低價,便利的服務, 拉近彼此的距離 但分享經濟真的這麼美好嗎？  在紐約市 13% 的Airbnb 屋主, 有著超過40%以上的房源, 對Airbnb 來說整層住家的出租才是主要的收益來源, 整層住家的收益在某些國際大城市佔了超過90%... 對這些屋主來說轉型做Airbnb, 一個月只要10天的訂房就能超過長租合約的收益, 更不用說如果是在熱門的位置或是熱門的季節, 帶來的收入都遠遠高於傳統的租約... 越來越多的房東不提供長租的合約給在地需要房子的居民, 轉而經營起Airbnb 類似的分享經濟服務 巴黎已經出現嚴重的公寓短缺狀況, 尤其是代表生活群體的雙人房或是小型的家庭房狀況更為嚴重, 隨著投資客盡可能的大量買進房產, 他變成一種生意, 能比傳統出租給居民帶來更多的收益, 但對當地居民來說, 市場能找到的房屋越來越少, 價格也越來越高.... 當我們使用便利便宜的服務的同時, 也許也應該思考一下他帶來了哪些衝擊和改變.....

 你可曾想過在大火中的生存之道是再放一場火？ 你可曾想過要保命的方法是丟棄平常賴以維生的工具？ 想像一下,你剛寫完了考券 , 對其中的幾題感到不確定,你還有一些時間去思考, 你會選擇堅守第一時間的答案？或是重新思考後做出更動呢？ 心理學家做過超過1500份的考券統計, 只有 25%的改動是從對的改成錯的, 有超過50%的改動是錯的改成對的 (剩下的人可能是從錯的改成錯的....) 1949年有15個受訓精良的消防隊員奉命去撲滅森林大火, 但是火勢蔓延過快, 最後只有3名消防員安全存活了下來..... 1個先放一場火先清出了空間讓火勢不會入侵... 2 個放下每天受訓賴以維生的工具,  拼命的往高處奔跑... 在重大的壓力下, 人們通常會回到自動且熟知的思考,  這是演化的適應, 我們緊握不放的工具是日常的假設, 直覺, 跟習慣....幾乎不會在第一時間抱持著開放思維, 擁抱變化 進步少不了改變,  那些改變不了自己心態的人,什麼也無法改變

 當注意力成為稀有貨幣, 預留深度工作的時間 變成想要變成高效率人士必學的技能 臉書的小紅點, Line 的小綠點, 以超高的成癮性在破壞人們的專注力 如何在一堆瑣事中找出相對重要的事,  就變得非常有價值 深度工作 在免於分心專注的狀態下進行的職業活動,  這種狀態可以把你的認知能力推向極限, 這種努力是可以幫助創造有價值或是改進技術能力, 並且是他人難以模仿的 淺薄工作 非高認知需求偏向後勤的工作, 往往在注意力分散的狀態中執行, 無法創造出新價值而且很容易被模仿 深度工作越來越稀有, 正好顯示於它的價值上面, 只要好好地培養這種能力並且善用它, 就可以成為各行業中的佼佼者 成為新經濟中的贏家有兩個很重要的核心能力 快速精通轉業技術的學習能力 在品質和速度達到高水準的生產力 深度工作力幫助快速學習困難技術 你的注意力必須專注在某個你嘗試改善的技術或嘗試精通的思想 你需要獲得回饋以糾正你的方法, 讓你把注意力放在最有生產力的地方 深度工作力協助你達成高水準的生產力 高品質工作  = 花費的時間  X 專注程度 把工作時間的專注程度最大化, 就能將每單位工作時間的產能最大化 注意力殘留 一但達到夠高的職位就必須同時處理多項專案, 會議一場接著一場, 思緒在不同專案接跳來跳去 問題是當你從任務A換到任務B的時候, 注意力很難立刻跟著轉換, 你的注意力能然會殘留在原本的任務上面, 進而影響到下一個任務的表現 分心帶來成本, 深度可以提升價值 破壞深度工作所造成的影響不輕易測量 - 度量黑洞 由於缺乏特種行為對企業影響的反饋, 我們傾向採用當時最容易的方法 - 最小阻力原則 在沒有明確指標可以證明工作是否有生產力的時候, 會選擇做很多事 - 以忙碌代替生產力 專注力是有限的資源, 你可以決定花在優先事項中或者是非必要的事件上面 如何將深度工作列為優先事項？ 確立你的工作哲學 修道院模式 -  為深度工作安排時間與世隔絕不要受到外界的干擾 雙模式 - 分配明確的時段給深度工作, 其餘的開放艮別的事情 節奏式 - 把工作變成簡單規律的習慣, 去創造節奏(可藉由月曆上的記號輔助) 記者式 - 任何時間都能安排時間適應深度工作 (須經過良好的訓練) 建立深度工作的儀式 深度工作的儀式沒有明確的定義,完全取決於個人和工作類型,  但任何有效的儀式都必須解決一些常見的問題： 你在何處

汽車大王亨利福特的名言：如果我當年問顧客他們想要什麼，他們肯定告訴我要一匹更快的馬。 什麼是「破壞式創新」？（Disruptive Innovation） 與主流客戶特別看重的指標特質大不相同, 而且在特別某幾個看重的指標,新的技術通常遜色很多破壞式技術獲得採用獲肯定, 一開始往往只出現新市場或新應用上, 這些技術的改進和成長速度超快, 逐漸的入侵既有的市場 如何判斷是破壞式創新或者延續性技術？ 從檢視內部開發人員對於現在新產品或技術出現的意見分歧,以往績效傑出的技術人員, 往往堅持主張技術的新市場將會出現, 就算面對關鍵顧客及市場行銷高層的反對也一樣,  這通常是一種訊號 延續性技術 (sustaining technology) 往往可以保持某個改進速率, 這通常時顧客看中的特質, 一般來說, 客戶或公司高層會偏愛可預期效能增長的技術, 很可以掌握透入多少資源可以在未來的某一個時候得到與預期差不多的增長 面對破壞式技術時,很少有公司可以克服規模或是成功的障礙, 往往因為公司的文化或是選擇打安全牌, 這一點不意外, 但是可以做到的一點是偵測並培養破壞式技術的技術 決策者必須有能力偵測可能屬於破壞式創新類型的技術, 若要開發新技術並且商業化, 高層必須要能保護這些技術, 不受服務既有客戶的干擾, 而唯一的保護方法是設立獨立的組織在主流事業外

 什麼是使用者案例(User story)？ 怎麼區分好與壞？ 軟體開發的三個基礎 知道問題 針對問題提出寫法 (程式開發) 確定問題有確實被解決 但是工程師經常的省略了某些步驟, 甚至專注在程式開發上, 不管其他兩項了... 怎麼知道我們的產品或系統正面臨什麼問題,  這其實是非常的重要,  要先有明確的問題才知道如何去解決... 這邊經常被省略或是有些常見的錯誤 Remote control Programming 使用者案例(User story) 一般不會告訴程式人員該如何解決問題或是提供解決方案, 好的使用者案例更應該在描述問題或是需求的本身, 至於該如何解決接給專業的工程師來就好 這種案例很常發生在有技術背景的PM or Planner 身上, 他會依照他過去的經驗提供一些解法 這個table 多開個什麼欄位,  這邊多傳個什麼值就可以解決問題了 導致PM or Planner  開出來需求就是加個欄位加個回傳值.... 但這真的是最好的解法嗎？ 說不定技術框架已經跟以前不一樣了？或是有其他更好的解法？  開發團隊沒有真正的是了解為什麼要做這個改變,  同時也限制了解決問題的創意 Story as a contract 開出來的功能需求跟被要求遵守的規範是一樣的,  需求應該是可以引領工程團隊作進一步的對話跟討論 在討論對話的過程中常常會出現更有創造力更有效率的解決方案 使用書寫的方式去記錄規範, 很容易產生誤解 下雨天留客天留我不留 不同的斷句地方就會有不同的意思 如果有一個交互式對談就可以明確的澄清問題以及用戶的需求 好的開發團隊在收到案例初期應該會有大量的交談對話去建立問題的細節 Monster stories 使用者案例應該以小步快跑不段遞增的方式去描述需求,  盡可能小到讓使用者案例可以在一個開發週期裡面被完成 怎麼分解到足夠小的部分,並且可以讓工程師快速的完成每一部分去向客戶提供價值 這是最大的挑戰 使用者案例的價值在於它能夠解決客戶的問題或是提供客戶想要的價值 一堆寶藏很有價值, 但是一塊錢也是有價值的 開發團隊經常會誤解為做完客戶想要的 所有事 才有價值... 我們應該把案例拆分到更小的單位, 更快且不斷交付提供價值給用戶 這樣做是會更有效率,  且單位更小的好處是當犯錯時更容易回朔,  這樣客戶和開發團隊所承擔的風險或更小 Depend