2019年12月31日 星期二

2019 年得到學習報告






2019 年上的許多課,和聽到的許多學科都在腦科學這個領域交會了,不管是年初上more fearless change 作者 Linda Rising 的課 ,到最近火紅的行為經濟學,組織行為學,生命科學..等。由腦科學的角度出發讓我不禁感嘆,我們最大的敵人就是自己這句話是真的,我們自以為是的心智和自由意志(所謂的靈性),每天必須對抗著人類這台精密的機器的玩弄,影響人類行為的根源:第一個是大腦神經元﹔第二個是荷爾蒙﹔最後才是是我們的基因和文化。

2019年12月15日 星期日

[書摘] (技術型)領導者,該想什麼



節錄出幾個我特別有感覺的部分,這本書每個章節後面列出許多問題,都值得領導者或想要變成領導者的人用來問自己,那些我有做到?哪些我沒有做到?我有辦法作的更好嗎?

MOI 領導模型


要讓改變發生,人們身處的環境必須包含三個要素:
  • M(Motivation)動機
  • O(Organization)組織
  • I(Ideas or Innovation) 點子或創新

相對的,領導也有可能意味防止改變發生:
  • M(Kill the motivation) 消除動機
  • O(foster chaos)助長混亂
  • I(suppress the flow of ideas)壓抑點子的流通

>> 要搞爛或搞好組織都要從這三個面向著手....


在一個組織裡面會有很多種領導者,比如說:
  • 動機型領導者 - 超級推銷員,充滿魅力,有任何想法都能推銷出去
  • 組織型領導者 - 工作有效率的企業經理人,辦起事來井然有序

不過這本書則是著重在技術型領導人,技術型領導人通常會注重於三件事:
  • 瞭解問題
  • 控制點子的流通
  • 維持品質

領導者的養成 


尤其是技術型領導者的重點是要先『學會如何學習』,並且要養成面對循環學習的態度,因為在學習的路上會不斷的交替,要學會面對低谷。有許多人就是無法接受面對這種循環面對低谷的感覺,為了了避開而選擇當『上司』管理人,但是反而摔入了峽谷,在人生的旅途上跌了一大跤(因為停止了學習)。



人們很容易認定『最弱的』環節就是『最重要』的環節,也難怪大家都會有個迷思:指定領導者是最重要的環節。於是大家都覺得所有的關鍵就是領導者,領導者要負起所有責任,讓領導者承擔更重的責任,所以也讓大家都更加害怕成為領導者。
(要知道領導者不一定是主管!也不一定是老闆....)


技術領導者 - 創新之路的兩難


而對於技術型領導者,大多是由技術明星變成,他們普遍就會有個恐懼,可能會失去吸收最先進的科技和知識,覺得技術能力會退步。的確不管是作者和我都會覺得,有時候為了增進管理和人際相關的技巧,不得不犧牲一些用來吸收技術性知識的時間。

而技術明星也通常是創新者,但是這又可能會變成有礙於他們學習所需要的領導技巧,因此難以攀上下一個高原期,如果不瞭解自己的創新/學習過程,一旦被賦予領導者的責任,這些技術明星可能會使不上力,覺得自己根本帶不動屬下,不知道該怎麼教他們變的跟自己一樣,又會覺得自己來似乎比較快,這時候反而就破壞了讓下屬創新的機會和環境.....


技術領導者面臨的三大障礙:

  • 當局者迷:看不見自身行為,因為沒有機會改變自我
  • 沒問題症候群:相信自幾知道所有問題的答案
  • 單一解決方案:深信一定有一個最好的辦法

改善之路



組織變革


從個人到團隊最後來到組織,組織是技術領導者的 End Game & End Goal,首先改革需要力量,也必須先取的力量,然後學習成為一個組織者。

然後呢...

讀一本書就像與大師對談,很多時候能聊的多深,取決於自己的經驗與歷練,當沒有累積足夠的經驗和能量,可能會沒有深刻的感覺,越到後面的章節,越有種現在進型式的感覺,需要再累積和驗證過一些東西才能再回來對話,所已有時候一本書必須要讀好幾次。



2019年12月10日 星期二

關於Marty Cagan - Product Is Hard 的筆記整理




原本想說沒機會去參加 Product Tank 的這場活動,還好事後有影片釋出,可以讓我補課,影片的內容的確有很多解決我的疑惑,也讓我很有感處,以下節錄出一些重點:

有那麼多好的工程師和設計師,為什麼一個好的產品那麼少?
  • 因為好的產品經理實在太少了!
  • 太少討論,和教學關於如何做好 Product (這邊指的應該是SaaS Product)
這也是現在Agile 遇到的問題,許多人以為考到 CSPO 就是一個好的產品經理,但是產品經理應該只有 5% 在專案管理,更多的時間應該花在產品探索和設計。

2019年12月9日 星期一

讓孩子了解什麼是民主,社會階級,獨裁



孩子的教育不能等,自從小貝哥回鄉下玩,回來以後就一直喊 xxx 凍算,叫覺得時候該好好教育一下,讓他瞭解什麼是民主,什麼是選舉,這些人都再做什麼,剛好前幾天在臉書上看到朋友在分享這套叢書,就趁著博客來剁手日買下去了 - 什麼是民主,社會階級,獨裁

 ★二○一六年波隆那童書大獎★★委內瑞拉圖書銀行文學獎★


2019年12月7日 星期六

一談就贏 - 高階四班心得

 我與談判大師的距離


說真的比起許多學長姐,我真的很幸運,才能用短短一年的時間,一路從思維班(12班)進階班(8班),上到高階班(4班),2019 年真的過的異常的 辛苦 充實阿!!

為了對的起已經付出的時間與金錢,也對的起一路提點我們的老師和學長姐們,真的奉勸各位學弟妹,如果想學到真正的談判,一定要一路撐到最後全部上完,才真的有機會把完整的框架學會,老師會這樣設計不是沒有道理的。

學談判心境的轉變


如果用比較平淡的講法來描述我這一年來的心境,思維班讓我『硬起來』,準備隨時可以與人談判的勇氣,學到不要害怕衝突,談判並不只是比口才和爾驢我詐,到了進階班學到了價值三角讓我就像撿到槍一樣,想說終於有個看起來蠻好操作的框架,應該可以上場多練習了,但是到了高階班才讓讓我再度冷靜下來,發現不要因為拿了一個錘子,看到的東西都是釘子想要錘下去,慎選場景,先釐清目的,這個場景真的需要用談判解決嗎?還是應該摸摸鼻子,找其他方式來解決?

這不禁讓我想到老師上課前提到的『...我看到你們之中一些人,本身的缺點居然比原先擴展的還大,所以我很懷疑你們究竟知不知道學習的目的....』,看到這老師的提醒,我冷汗直流,心想這不就是在說我嗎.....


如果要用誇張一點的講法就是,學談判前就像一個小孩望著滿天繁星想說只要長大一點手伸長一點就能抓到星星,到了思維班就像一個小孩學到星星其實在外太空唷,要飛到外太空才能碰到,到了進階班才有了更精準的知識,知道其實那些發亮的星星叫做恆星,只要開太空船飛出太陽係就可以遇到,但是到了高階班才驚覺,原來出了太陽系那些星星距離我們幾百光年之外,就算以光速進行,也要一百年之久.....那這樣不是有生之年都沒望了!?別擔心這時候 Alex 會教你怎麼靠曲速和蟲洞到達目的地.....(並不會,這時候可能要回來修正目標,你真的是想要抓到星星嗎?)

向大師學習



對於 Alex 的強大的體認就跟對課程心得一樣,隨著自己功力的提升有著不同的體認,正所謂內行看門道,外行看熱鬧,對我們這種談判小白來說,一開始只是在看大師演練功夫招式,並且對於老師過往談判經歷和表演感到讚嘆,但是會覺得跟旁邊其他功夫師父比起來,好像覺得沒太大的差別(現在想起來真是汗顏),直到進階班跳下來跟著他一起演練招式,這才發現看起來簡單基礎的動作卻是滯礙難行,很努力都不一定能跟上動作,直到了高階班以為差不多可以跟上動作了,直到上場跟老師演練一下推手拆解招式,不出幾回合就被老師的內力震飛出去....(噴出一口鮮血,還非常感激的謝謝賜教)

此時腦浮現人生跑馬燈,盡是老師的課前作業問題『你們認為什麼是談判?你們學盤判是為了什麼?你覺得你可以做的更好嗎?如果重來那個當下你應該怎麼做?』...

老師不斷的在觀察我們每個人,這些人想要上的是怎樣的課?他們究竟想聽到什麼?他們分別的長處是什麼?有什麼短處(有沒有改善?)而這次高階班跟其他幾般最大的差別就是可以一整天跟隨在老師身邊觀察, 越是相處越能具體的理解到 Alex 的強大和我們之間的差距,跟我們離他還有多遠的距離,就連吃飯跟我們聊天都是有所準備和規劃絲毫不鬆懈的。


對於震撼的部分就先提到這裡,這篇真的不是來歌功頌德和拍馬屁的~XD  不過如果沒有這樣的鋪陳是無法體會我的收穫,也無法體會老師為了讓我們學習所下的功夫,而且上面描述學習的心境和Alex 的強大的部分,其實是我第一天上課完拖著疲憊的身體就先寫下來了。



學習的框架


充滿風險卻逐步完善,逐步清晰的課程架構


老師在課堂上提到實務談判的三大核心難題:
  • 多對多
  • 動態
  • 不理解對手(沒有重視細節,沒有重視人) 
五大操作困境:
  • 不知道如何出手
  • 不清楚如何因應
  • 不掌握時間
  • 不能創造機會
  • 內部無法達成共識

基於上面的困境就知道一個談判的課程所需要解決的問題實在太多,涵蓋範圍實在太廣,如果以正規的學校教育,可能要花一整個學期來學期,我更能理解為什麼老師的課程必須設計成這樣(當然也是冒著風險,冒著同學沒辦法跟到最後看到全貌),就像敏捷開發一樣由具體而模糊,每次都 delivery 一些可以用的東西,但是都還不是全貌,畢竟才三次總共五半的課,要跑完人家一年的課程,就沒辦法用一般的方法慢慢來,必須透過演練和活動讓同學體認出真正談判會遇到的困難,才有辦法糾正觀念,重新學習...




而老師要怎麼降低課程設計的風險?老師一直用行動在告訴我們:
  • 創造連結
  • 建立關係
  • 培養共識
  • 打造信任

透過課前作業,透過每一篇文章,透過每個學長姐的心得來傳達訊息,我們因為連結,建立的關係,培養了對課程與學習的共識,也信任老師會提供最好的課程來讓我們學習,並且深信是有用的。

警語:學弟妹在看學長姐心得時也必須注意,最危險的的就是看到學長姐的『關鍵字』和老師上課的金句來臆測課程內容,這就是老師所提醒的不要用已知去瞭解未知,所以我也盡量不去描述這些『重點』,留給各位在課堂上體會。

關於課程上的競爭


思維班的競爭其實是其實在混亂中就結束了,可能很多人都還沒意識到自己該爭什麼?為什麼要贏?真的有必要繼續往下上嗎?甚至有很多人只是來看看的(打卡集點的概念)。

到了進階班真正的競爭才開始,更有組織,更有意識的在小組競爭,除了好勝心和證明學習成果,更是為了爭取高階班的資格。

但是到了高階班整個競爭心態變了,不是不想贏,而是更想要贏得自己的人生,每個人都拿出自己生命中血淋淋的談判經歷來當案例,每個人都是為了自己的人生在競爭,想要贏過去的自己,想要解決生活中真正的問題,這跟過去看著老師拿出來與自己無關的案例,和同學『演』練談判的競爭心態差很多。所以小組與小組之間的競爭變少了,更多了一起協力學習一起幫忙解決問題的共患難心態。



此外看別人的案子和看自己的案子也有很大的差距,一旦牽涉到自己,就會有過多的感情和過去經驗的糾結,會讓自己不能做出最佳的判斷,這不也是我們思維班課前作業老師一直要我們思考的,我們到底為了什麼在學談判?我們認為談判是什麼?學完之後要怎麼用談判?要怎麼改善自己的缺點?(至少不能讓他再惡化)

價值連結的取捨


在進階班讓我感到收穫最大的就是價值三角,其中大家朗朗上口的雙贏,把餅作大,就是透過價值連結的活動產生,但是自己在練習和操作的時候一直覺得太理想化,很難被實作,直到了高階班透過談判架構的細部拆,解終於瞭解當初價值三角做的如此零零落落,原來一直沒有搞清楚利害關係人(有哪些種類?對於我方和對方的影響?),更不用說各自的利益都分不清楚,要怎麼作價值連結?更不用說極大化雙方的利益。

此外價值連結不是只有取得,還得有捨棄,為了得達到雙方的目標,我自己願意拿什麼來換?(你沒辦法要求和臆測別人會拿什麼來換),取捨?談何容易,為了達到目的,你願意犧牲掉什麼?沒想到居然還真的可以排得出來...(雖然我們可能還是會排錯)






談判框架 - 工程師的領域


以前都認為談判是適合業務哪種很會說話,反應很快人的天下,隨著課程雖然慢慢修正了這些錯誤的觀念,直到高階班讓我遇到了談判架構檢核表,不禁讓我驚呼~阿~這對工程師友善多了,讓我們思考更有所依循。



談判架構檢核表的推演,根本跟寫程式的『測試驅動開發』 ( TDD - Test Driven Development )方法一樣,一開始先立一個目的,隨著功能的實作中,不斷的查核檢驗錯誤,如果卡住了再回上一層修改和重構,有時甚至會回到最源頭發現根本是目標設立錯誤,不習慣 TDD 的人剛開始一定會覺得麻煩和速度慢,但是上手後整個手順和速度有著明顯的加速,更容易拆解和實作複雜的談判架構和演算法,就像老師說的很多時候那些 3*3 的沙盤推演不是靠天才橫空出世,而是靠一步一步推演出來的。
這個框架非常具有操作性,在第一天我們發現案例可能走不下去的時,我們馬上決定換另一個案例,坐在沙發上,我們光是按照檢核表透過口頭走過一遍,就把上課前七嘴八舌討論老半天都還搞不清楚的案例拆解開來,看清楚這是一個怎樣的『局』,當然至於要怎麼作的好對我們來說又是得花時間磨練的功夫了....


上完這門課真的是充滿了懊悔與落差,但是也真的很開心有了新的武器可以面對人生的挑戰(M屬性來著..),但是生活就是沒有時間讓我們停下來懊惱,壓力和挑戰還是持續的排山倒海而來,出了教室馬上就開始應用,面對人生的大魔王~~


最後要感謝我的同伴們(佳儀、育成、安婷、雅樂),因為這陣子實在太累太操了,沒有大家的支持沒辦法走道最後~~



延伸閱讀:


2019年11月11日 星期一

Apache Spark 3.0 Release Preview






一轉眼 Apache Spark 3.0-preview 已經推出了,眼看又快要跟時代脫節了...🙈
這次 3.0 的更新多到爆炸,所以再研究有什麼令人興奮的更新前,我們先來複習一下之前在 Spark+AI Summit 2019 Keynote 的預告有什麼需要我們注意的。

  • 更多向量矩陣運算和GPU支援
  • 跟 K8s 更緊密的整合
  • Koalas - panda dataframe

2019年11月7日 星期四

使用 Go Get 在Docker 使用 multi-stage builds 搬檔案遇到的問題

source: mundodocker


前情提要


Docker 從 17.05 版本以後就有這個貼心的設計, multi-stage build(多階段建構),這對於長期因為 build docker image 太大而困擾的我們真的是很方便,所以現在 multi-stage build 幾乎已經成為 build docker image 標準配備。

在不支持多階段建構的年代,通常會有兩種作法:

2019年10月27日 星期日

一談就贏 - 速食遊戲演練班




第一次參加『一談就贏』系列的其他課程,而且還是空前絕後的『速食遊戲演練班』, 如果硬要把心得濃縮成摘要,大概就是:

這次的演練基本上就是結合『談判』、『銷售』、『MTa』三大綜合戰技,而其中我覺得最重要的是『MTa』的團隊合作(等等你根本沒上過啊...),縱使有再好的談判技巧和銷售定價策略,只要不能有效達成團隊合作,一切都是回到單兵作戰,吃的是本質學能,考驗個人戰技。






2019年10月25日 星期五

組織變革的張力與拉力




昨天聽完 #周師父 的演講,拿這張投影片搭配今天聽到 #梁寧 在講組織與關係就特別有感覺。

關於抗拒的張力與抗力的圖片在『最小阻力之路』和『第五項修練』中都有出現,但是用來解釋 Component team 與 Feature team 倒是第一次聽到,覺得很新鮮也很有道理。如果有再推行敏捷都會知道 Feature Team 的好處,而 Feature Team 也主要是以傳遞上商業價值為導向,但是系統開發的本質,卻是以 Domain Architecture Design 和 Reuse Shared Modules 的 Competent team 在思考與運作。沒有誰對誰錯,只有當下適合不適合,與分配的比例。


2019年10月22日 星期二

Lean B2B - 架構與順序

source: Lean B2B


在講解作者提出的 B2B Startup Pyramid 前,我們再來看一次本書的目錄架構:


1. Why This Book Matters


Chapter 1. Introduction
Chapter 2. Where I’m Coming From
Chapter 3. The Nature of the B2B World

2. People

Chapter 4. Were it starts
Chapter 5. Choosing a market
Chapter 6. Finding Early Adopters
Chapter 7. Leveraging Domain Credibility & Visibility
Chapter 8. Contacting Early Adopter

3. Problem

Chapter 9.   Finding Problem
Chapter 10. Conducting Problem Interviews
Chapter 11.  Analyzing the Results

4. Solutions

Chapter 12. Finding a Solution
Chapter 13. Creating a Minimum Viable Product
Chapter 14. Preparing Your Pitch
Chapter 15. Conducting Solution Interviews
Chapter 16. Product Market Fit

5. Speed
  
Chapter 17. Common Challenges
Chapter 18. Speeding up Product Market Validation
Chapter 19. Conclusion


不過其實最吸引我目光的反而是『加速』章節的第十七章,B2B Startup 常見的問題,其實應該說許多公司都常見的問題,後面看到有什麼心得再來分享~

  • Being everything
  • Pet Problem
  • The curse of “interesting”
  • Postponed usage
  • Long sales cycles
  • Insufficient credibility
  • Gatekeepers and Saboteurs
  • Soft value propositions
  • Committed budgets
  • Insuffcient coaching influence
  • Death by process

2019年10月2日 星期三

Lean B2B - 同樣是 Lean Startup B2B 與 B2C 有什麼差異?



從年初在準備『 Agile meetup - 為什麼我的敏捷總是卡卡的? 』這個活動時,就開始大量研究 B2B 與 B2C 之間本質的差異,以及對於導入敏捷會不會有什麼影響,一直覺得這個議題應該蠻適合研究的。而延續上一篇文章『加速 (Accelerate) - Lead time 我搞不懂你啊』,其實敏捷的本質就是圍繞在商業價值,所以關於 B2B 與 B2C 的議題應該延伸到整個價值流來檢視(包含 Lean StartupDesign Thinking、Agile)。

剛好最近新的工作是要負責開發新產品,同事也提議要來舉辦讀書會,我就找到了這本有趣的書,還真的有人再探討,同樣是精實創業( Lean Startup)同樣是開發新產品, B2B 與 B2C 有什麼差異?

2019年9月17日 星期二

加速 (Accelerate) - Lead time 我搞不懂你啊



在 Accelerate 第二章看到這個表(把Dev & Ops 兩個階段分開來看),就讓我想到之前看到上面 Gartner 那張圖,Design Thinking,Lean Startup,Agile 應該要整合在一起,這張圖告訴我們,只專注在Agile 上的優化可能還是無法解決商業成功的問題,這也是我一直以來在問自己的問題,縱使在產品 Delivery 上怎麼優化(當然不可能完美,但是還算有到一定程度),感覺對於商業成功的影響還是有種施不上力的感覺。




2019年9月14日 星期六

一談就贏 - 進階八班心得『專注在你能控制的部分』



這是一門談判課,『想贏』這個目標,究竟是想學好談判,能贏!還是想拿到進階班冠軍,有資格繼續挺進高階班?這個問題在這段期間一直在我腦袋裡翻轉,也一直被人反覆詢問.....


忘記從何時開始,每年都固定提撥一筆預算去進修(進場維修),而一談就贏這一系列的課程真的是從開始上課以來最操也最辛苦的一門課(沒有之一),Alex 打造出來的這個平台和這個局真的很恐怖厲害,打從作業一就開始就讓我們不斷體會什麼叫做談判,甚至可以一直回推到思維班的作業一....

2019年8月18日 星期日

指數型組織 - 大型組織的變革策略

Source: Exponential Organizations, Salim Ismail


雪球速讀法這本書有提到,看書先看框架,如果對於框架有興趣,在去裡面看脈絡和內容,指數型組織這本書總結出一個共同的特性『宏大變革目標』(MTP),其中又可以細分為構成的外部五大屬性以及內部五大屬性:

外部五大屬性( SCALE ):

  • Staff on Demand(隨需求聘僱員工)
  • Community & Crowd(社群經營與眾籌)
  • Algorithm(演算法)
  • Leveraged Assets(槓桿化資產) 
  • Engagement(參與)

內部五大屬性(IDEAS):
  • Interface(介面)
  • Dashboard(儀表版)
  • Experimentation(實驗力)
  • Autonomy(自治力)
  • Social(社交)

不過我覺得許多特性真的都是比較適合2C 類型的公司?

2019年7月29日 星期一

2019年7月23日 星期二

得到萬維鋼的書單



一直以來我在得到最愛的專欄就是萬維鋼的精英日課,除了他都會講許多美國最新出版的有趣書籍外,重點會把自身的理解和經驗融合在裡面,甚至會把各本書之間的關連性串在一起,因此很多時候真的去看了那本書反而會覺得沒他講的精彩....XD


2019年5月27日 星期一

我們面對的是棘手問題還是單純問題?




人生三部曲:

單純問題

小時候面對的都是那種問題被定義清楚的挑戰(如考試)

兩難問題 (成年人只能選擇,沒有都簡單對錯)

出了社會越來越多人感到迷茫,因為要面對更多的是兩難的問題,沒有正確解與唯一解,更慘的是從小沒有培養面對這種兩難問題能力。

棘手問題 (wicked problem )

當出了社會一陣子後,又會面對人生的另一個關卡,也使許多人的天花板,就是要面對棘手問題,棘手問題(wicked problem)是1973 Berkley 兩位教授(Rittel and Webber) 提出的定義:

是指一個困難或不可能解決的問題,因為這個問題不完整、矛盾、不斷變化且往往難以識別或定義。 英語中使用「wicked」是指一種抵抗的決心,而不是指邪惡 ,故通常不翻譯為「邪惡問題」。另一種對棘手問題的定義是「問題因其複雜的社會意涵,而沒有任何能夠確定的停止點 。」且因為復雜的相互依賴性,試圖解決棘手問題的行動或方法可能會造成其他問題的產生。


2019年4月25日 星期四

Spark+AI Summit 2019 Keynote 重點搶鮮看



熱騰騰的 Spark+AI Summit 2019 的影片陸續出爐了,讓我們先來看看 Keynote 的重點內容  - Reynold Xin (Databricks), Brooke Wenig (Databricks)


第一個重點就是針對Unify Data 處理和AI Databricks 做了什麼努力,去年他們提出 Hydrogen 為了讓Spark 能更方便跟各種 ML lib 串接。


而今年的 Spark 3.0 放了更多重點在於讓 jvm base 的底層可以支援更多向量矩陣運算和GPU支援。








再來就是因應Kubernetes 的崛起,Spark 勢必得更加密切的與Kubernetes整合。



再來就是 Spark 3.x 想要解決 Data scientist 的痛,因為 Data scientist 通常用 python + panda 在他們的個人電腦上建模型和測試,但是一旦要scale 就得重寫code porting 到 spark,此外雖然看起來都是dataframe 但是實際上理念卻是差很多,所以stackoverflow 上常常都是這些型態轉換的問題。




於是Databricks推出 Koalas: Panda DataFrame API on Spark,最神奇的就是只要把panda的任function 換個名稱koalas 就無痛轉移了....XD




相信Data scientist 和 Data engineer 一定很期待,也可以少很多工~










2019年4月11日 星期四

從孫子兵法看今年Google Cloud 的策略

兵法到底要怎麼用在人生和企業經營?


節錄一段 #華山講孫子兵法 的一段就有很好的解釋:


今天大家都想學《#孫子兵法》並且把《孫子兵法》運用在企業經營裡面,但是你也要知道軍事兵法和企業經營的區別。

企業的競爭戰略確實是脫胎於軍事戰略,包括我們的企業管理也是從軍隊管理思想裡面發展出來的,因為人類社會是先有軍隊,后有企業。但軍事對抗和企業競爭有一個最大的本質區別——軍事是 零和游戲 ,而企業競爭不是。 零和游戲就是沒有雙贏,不是你贏,就是我贏,企業競爭是 重複博弈



但是企業競爭不一樣。 市場是無限的,是發展的,是變化的,甚至可以說市場是多空間的,隨時可以有新的市場被創造出來。

做企業的人研究知己知彼,最重要的就是不要被競爭對手帶走,而是自己要聚焦於研究顧客,研究自己,專心搞研發,少研究對手。

所以商業中知己知彼的“彼”不是競爭對手,而是顧客 ﹔你想要做好經營,你就得了解顧客,你知道對手有什麼用呢?

有一句話:

“競爭思維就是沒有競爭力的原因”。

你總去考慮競爭對手,你的思維就會被競爭對手帶走而不去關注顧客。 你不知道自己是誰,也不知道顧客要什麼,僅僅知道對手有什麼用....

雲端大廠的競爭


就像三大 Cloud provider 之間的競爭,如果只是關注領頭羊的 AWS 有什麼,那我也要有,那對於廠商和消費者都是雙輸的局面,不過還好 GCP & Azure 也不是省油的燈,都另外有好好發展各自的強項,重點還是理解客戶要什麼,可以幫客戶解決什麼問題,這樣一來市場的動態變化還很難說...

因為別人有什麼什麼,所以我們也該有什麼,不然沒辦法賣,這充其量也只是Me too ,更不要從 Me too 的角度去競爭,應該反過來思考我們能提供什麼是別人無法提供,或是我們能做好什麼是別人不想碰的?

這次Google 更是推出 Hybrid Cloud 的殺手鐧 GKE On-Prem 以及 Anthos

目標有兩個:

1. 針對其它 Cloud Provide (AWS, Azure) 的客戶降低轉移門檻
2. 針對使用 Private Cloud 的客戶提高使用雲端的意願,並且幫助管理與轉型



顧客聲音,這幾個字幾乎成了今年Next大會的官方慣用語


而 Ithome 這篇文(【舊金山Next直擊】Google雲端新CEO大喊「聆聽顧客聲音」原則,更要開始搶攻多雲混合雲戰場 ) 更印證了我的想法,聆聽顧客聲音,專注在自己的強項。

而Google Cloud CEO Thomas Kurian 提出的戰略方針有四個特點:

特色1:GCP轉而聚焦數位轉型企業,而非所有企業
特色2:聆聽顧客聲音,走下雲端進軍多雲混合雲
特色3:大秀各產業指標型企業採用情況,更強調GCP新企業顧客
特色4:不是與開源爭利,而要和開源產業聯手服務企業





2019年4月10日 星期三

Stack overflow Developer Survey Results 2019


熱騰騰的  Stack overflow Developer Survey Results2019  就在出爐了,在這份針對stackoverflow 全球 90,000 developers 的問卷,看到了許多有趣的統計資訊,首先大概主要是因為語言的關係,亞洲區的參與率普遍都低,台灣佔了 0.21%,不過以人口比例來說應該也算不錯啦...XD



而這份Survey 有幾個重點:

  • Python 再度擠掉Java 蟬聯成長最快速的語言,此外也是Rust 外排名第二最受歡迎的程式語言
  • 許多人第一次寫程式都是在他們16歲的時候
  • DevOps specialists and site reliability engineers 是屬於待遇最好,最有經驗的工程師,且都滿意他們的工作,換工作的意願最低...XD
  • 開發者中中國的開發者是最樂觀的,相信他們的小孩會有更好的未來,反觀西方世界的法國和德國則是最不樂觀的
  • 對於什麼會妨礙生產力這件事,不同性別有著不同的困擾,男人認為跟非技術人員工作很困擾的是,而女人認為在一個有毒的職場工作環境(toxic work environments) 讓他們很困擾。 
  • Stackoverflow 的重要性,可以節省開發者一週 30 to 90 分鐘~XDDD

2019年4月3日 星期三

欸假邪教的故事




這幾天頭都暈暈的,昨天開會時突然就睡,還著做了一個夢,接著腦袋裡突然浮現出一個聲音,跟我講了一個我不懂的故事~

很久很久以前,傳說中有個欸假邪教,邪教信徒靠著兩大神功縱橫江湖 死逛 & 砍半,所到之處人人為之色變。不過其實這兩大神功其實就像辟邪劍法一點威力也沒有,但是為什麼大家都還是對他們又愛又恨?

2019年4月2日 星期二

工程師鍛鍊接軌世界的能力從stackoverflow 開始



說來慚愧,過去一直以來就是把 Stackoverflow 當作是google 問題解答的終點站,反正找到解答參考完答案就離開了,沒有login 也沒有給予解答的人感謝(投票),更不用說加入這群討論甚至回饋社群。

最近看到一個問題,你對這個世界(社群)帶來多少impact? 能影響了多少人?雖然我有寫blog 有經營粉絲團,但畢竟是小眾。因為家庭因素也比較少在社群走跳甚至演講和分享,所以為了回答自己這個問題,我定下給自己定下了一個新的練習的目標,就是要在stackoverflow 上面好好的問問題和回答問題累積積分,不玩則已深入研究以後才驚覺這真得是一個設計良好的成就系統,可以鍛鍊許多能力:
  1. 英文書面溝通能力 (因為在這邊你全部都得用英文溝通,不管是問問題還是回答問題)
  2. 解決問題的專業能力 (因為你要提出有效且讓人看的懂得解決方案)
  3. 看懂問題的能力 (就算是你熟悉的專業領域,也會看到千奇百怪的問題~)
  4. 審查問題的能力
  5. 審查答案的能力 
  6. 解決客戶問題的能力 (前提是你的產品要夠有名到客戶到上面問...XDD)

2019年3月2日 星期六

一個專業的雲端架構師需要具備協助建立團隊文化的能力

Google SRE implement DevOps



在Coursera 上 Google Cloud Professional Cloud Architect 的課程,原本以為是一個以技術為主的課程,上了之後才發現遠遠不只這些,而且有需多部分發人省思,一個專業的雲端架構師除了技術上要協助客戶釐清需求外,更重要的是幫助客戶完成商業需求,甚至要協助建立團隊的開發維運文化!

2019年2月20日 星期三

Google Cloud Load Balancing 將要針對 user-define request header 收費



今天早上收到這封信,腦中浮現出了幾個字養套殺使用者付費...XD
原本是一個Google 佛心來著的免費加值服務,現在卻變成要收費了,所以現在得好好算一下是不是要繼續使用這個服務。


你如何衡量你的人生 - 為你的孩子製造機會解決困難



最近看到朋友再讀『你要如何衡量你的人生』,看到他節錄的幾個章節很有感覺,所以又拿起來重新翻了一次,之前看這本書時小朋友還很小,但是現在小朋友大了,自己也面對許多人生的新問題,重新看再看這本書就更有感受了。