2020年11月27日 星期五

2020 Domain Driven Design Taiwan - 關於使用者研究的省思

 

今天最意外的收穫就是在 DDD Taiwan 能聽到 Nor 大大的這場演講: 從使用者研究的幕後花絮談起,這個演講題目非常特別,研究的對象不但是運輸業還是線下的領域,對於都在搞線上大數據研究的我們產生了不少省思,此外 服務設計研究場域利益關係人這兩個名詞對我來說還蠻新鮮的。 雖然是不同領域,且比較冷門的 session(Nor 大大還自嘲大家技術聽累了才來他這邊休息),但是從需求訪談的實際場域設計,讓我得到很多啟發和感觸! 

2020年11月20日 星期五

一談就贏實例心得:鬼滅之談判五大呼吸法!?

 

上課前我不斷的問自己,距離上完高階四班過了一年,我究竟成長了多少呢? 不過不管有多少成長,一進到教室看到這個恐怖的 Schedule 依然倒抽一口冷氣,受到進階十班在社團用鬼滅洗版的影響,我腦袋不禁浮現出這些畫面...

 

2020年11月7日 星期六

Team Topologies - 團隊優先思考模式

 

距離上一次聽到作者的演講,並且寫了一篇:微服務架構或單體式架構?先從團隊認知負擔談起,也經過了一年多了,一直都沒時間靜下心來好好讀這本書。

直到最近漸漸開始感受到切身之痛,是時候該好好把這本書讀完(臨時抱佛腳的概念),隨著組織業務增長,團隊也越長越大,團隊之間需要更有效的橫向溝通與協做模式,此外組織為了要在業界佔有一席之地,也必須不斷的加強 domain knowledge 與技術深度,團隊成員都有種要爆的感覺,但是卻又無法具體的描述具體原因出在哪裡?因為人力資源不夠?這是每間公司都會遇到的問題阿,有哪間公司會說自己人太充足的?是因為團隊成員能力不足?其實團隊成員的能力也都是一時之選,那究竟問題出在哪裡呢?很有可能就是在於組織架構和協做溝通的方法。

2020年10月19日 星期一

正念領導力

 

 

這是一本可以用一小時就可以看完,但是卻需要用一輩子的時間來練習的一本書。

本書作者陳德中是台灣正念工坊創辦人,也是 SIY 認證師資 ( 前 Google 工程師陳一鳴正念情商與領導力課程, 另一本書:喜悅,從一個呼吸開始


正念(Mindfulness)是一種善意和好奇的心態,對當下身、心和外在環境所發生的一切保持覺察(客觀、允許、不批判的態度)。

根據調查,大腦運作平均 47% 時間花在分心走神。思緒遊走自動導航模式是大腦自然反應,注意力都放過去或未來、分心缺乏覺知,基於慣性模式與假設做出行動,透過系統化的正念方法,可以將腦袋裡自動導航模式轉變為覺知 Being Aware。 
 

2020年10月11日 星期日

Azure 上各種 Message Queue 的比較

 
資料來源整理自 Azure 官網:

 

傻瓜快速分類:

  • 傳遞的是 Event 類型( 訊息量不大,多為狀態,射後不理),考慮 Event 類型
    • 如果是離散型資料,考慮 Event Grid 
    • 如果是串流行資料,考慮 Event Hubs
  • 傳遞的是 Message 類型 (訊息量較大,帶有資訊,需保證送達),考慮 Message Queue
    • 訊息很多很大不用保證 FIFO,選擇 Storage Queue
    • 訊息不會很大,要保證FIFO

此外 Service Bus 才有支援 AMQP,更多資訊請參考: 同樣都是Message Queue 到底AMQP跟JMS 有什麼差別?

 

Update 找到一個更棒的整理:

 

 

2020年10月10日 星期六

Amazon 14 條成長法則與 14 條領導法則的差異?從貝佐斯寫給股東的信一窺究竟




這本書與一般成功名人傳記不同處在於,除了作者以企業研究的角度切入,長期關注 Amazon 與 Jeff Bezos 的消息外,更以 Amazon 上市這幾年的股東會信件為主軸,來歸納出 Amazon 的14 條成長法則。相信大家應該會有些疑問,寫給股東的信有什麼特別的地方嗎?不就類似新聞稿的東西?
 
在解釋貝佐斯寫給股東的信為什麼值得一讀前,可以先聊聊同樣是寫給股東的信,但是大家更為熟悉的就是巴菲特給股東的信,每年投資界的盛事就是期待他老人家致股東的信,大家除了拜讀外更有許多人收集起來集結成書。
 
 
第一點:溝通股東信是寫給股東看的,而他希望股東都能理解他的理念。
第二點:以身作則,老巴希望他投資的公司都能達到他想要的標準,所以他也以身作則的成為標準。
第三點:因為老巴好為人師,有傳道的渴望。
 
同樣的 ,Jeff Bezos 應該也會希望透過致股東的信,讓投資人和股東瞭解他的想法,以及他打算如何讓 Amazon 如何成為快速成長的公司,同時也希望投資人們有耐心和遠見可以跟他們一同成長。因此就算是以新聞公關稿,或募資的角度來看,也是非常值得參考的內容。
 
 

2020年10月2日 星期五

第五項修練的學習地圖


2020年全世界被按了一個強制暫停的按鈕,我也因為某些原因,趁這個機會多讀點書和整理一下學習歷程。在整理的過程中,依稀感覺到快要可以把整個學習歷程串起來的感覺,就像拳譜一樣,面對組織所面對的各個層級的問題,如果能把這些 workshop 依序舉辦,從第一式打到最後一式就可能變成大絕招?但是就跟武俠小說一樣,要推動這些招式最終還是得靠深厚的內力,否則只是徒具形式。而推動這些招式的前提假設就是 相信眾人的智慧不斷學習反思

2020年9月1日 星期二

從OGSM 談策略

 
OGSM 打造高敏捷團隊 (現在就是一定要寫敏捷~XD)

從 OKR 到 OGSM


其實也不是說 OKR 不好,非得搞個 OGSM ,其實 OGSM 跟 OKR 觀念是很類似,只是之前在使用 OKR 上有點卡關,剛好看了這本書,順著他拆解的脈絡覺得很容易理解與執行,再加上作者為了賣書教育讀者,還是有特別指出 OGSM 可以解決 OKR 的什麼問題:
  • OKR 的思路轉折交代不清楚 (從 O 跳到 KR 跳太快)
  • OKR 缺乏實作案例
  • OKR 無法貫徹執行 (無法有效跟 KPI ) 
  • 不知道如何修改 OKR (不知道怎樣算寫的好)

那在實際運作上我究竟遇到什麼問題呢?

2020年8月22日 星期六

ICA 參與式科技之轉化型行動計畫(Transformation Action Plan)

 

 

最近公司正在為了二轉升空正在如火如荼的制訂規劃新的 Vision & Mission & Strategy ,我也臨危授命的去幫忙帶了幾場 workshop,主要是想透過組合技 ORID 焦點討論法與團隊共創法,幫忙一線主管們回顧過去,找出影響團隊無法達成目標的障礙加以移除,並且展望未來。

 

 

雖然大家討論的很熱烈,也的確讓許多問題都浮出檯面,但是由於我忽略了幾個重要的環節,所以總覺得最終產出還是虛虛的,趁著這次的機會趕緊去報名了 ICA 今年度的 轉化型行動計畫(Transfromation Action Plan) 課程,也可以檢視上次的 workshop 有哪裡做的還不夠?

談到 ICA 的引導,就一定要先複習一下 ICA 參與式科技的引導原則:
  • 包容性
  • 帶著真誠的尊重來參與 (相信眾人的智慧)
  • 探索的歷程
  • 留意脈絡幫助瞭解與許下承諾
  • 引導式的風格


要相信團隊成員的集體智慧,流程只是個工具,用來幫助思考的順暢,但重點還是尊重,並且讓大家能充分表達意見的包容力,所以引導者的觀察力與場控力真的很重要(這也得靠經驗累積)。

 

2020年8月8日 星期六

2020年7月31日 星期五

關於產品調查的問卷設計



前陣子在讀 Lean B2B 時這張圖最讓我有印象,這也是我常拿出來提醒 Team Member 的,到底什麼是 MVP,應該盡量要取三個圈圈的交集處:
  • 我們以為市場可能需要什麼
  • 真實市場確實需要什麼
  • 我們有能力做到什麼
而怎樣的產品對客戶來說怎樣算是一個好的 2B 的 solution 呢?可能有以下的面向,如果都能達到當然是最好的:

    •    Solutions that can help increase revenues (ROI)

    •    Solutions that can help reduce cost (TOC)

    •    Solutions that can help increase customer satisfaction

    •    Solutions that can help decrease risk

    •    Solutions that can help increase market share



趕快到市場上去被打臉尋求回饋固然是最重要的,但是出門前也是可以先從內部收集一些情報,剛好前陣子要跟全公司做個小型產品發表會,介紹這段期間以來 BlendVision 到底在做什麼?以及目前設計產品的理念以及開發進度,想說既然都花費大家時間來聽我們介紹,不如順便收集一些回饋。不過要設計一個好的問卷也是一門學問,在有限的時間下我們就借鏡那三個圈圈,把題目設計如下:

  • 你覺得這個功能是有用的 (用來替換我們有能力作什麼)
  • 你覺得客戶會需要這個功能 (=我們以為市場可能需要什麼)
  • 已經有客戶提出這個功能需求 (真實市場確實需要什麼)

但是光是這樣可能還不夠,就算是匿名問卷,最好還是能區分這是以什麼角度來評估的?
  • 工程師?
  • PM?
  • BD / Sales?
  • Operator (維運/客服)

畢竟可能只有 PM & BD / Sales 有真實接觸市場和客戶的需求。



最後我們回收了 24  份問卷,畢竟不是大家都有空來聽我們介紹產品~~QQ




接下來我們就針對我們的 12 大 Feature 一一介紹功能,並且尋求大家的回饋。





不過畢竟這是倉促之間產生的問卷,所已有效性還值得商榷,而且問題的設計上也造成了(問卷)使用者的困擾,像上面這個打勾的方式就很讓人疑惑,你覺得客戶需要這個功能,也已經有客戶提出這個需求,但是你卻沒有勾你覺得這是有用的??

後來事主自己跑來跟我們聊,原來她覺得只要下面兩個都有勾,其實就代表這個功能是有用,所以就不用她覺得是有用...XDrz...

所以如何設計問卷的問題真是門藝術啊...
有了同仁門的回饋,接下來就繼續到市場上去被人洗臉求成長了~~

不知道大家有設計相關的經驗可以分享嗎?



2020年7月30日 星期四

組織生命週期與溝通模式的變化



最近在跟朋友聊天,聊到這個話題~

人和組織都有生老病死


組織是由人組成的,所以就像人一樣也會有生命週期,在不同階段都有相對應適合的管理模式和工作方法,反過來說就是眾多的管理學工具(方法論)都是為了解決特定的問題,也都有試用的場景,並不是都能一體適用。就像 design pattern 一樣,每個 pattern 都有要解決的問題和適用的場景,用錯時間和地點可能還會產生災難。



老漢愛提當年勇,但識英雄來自四面八方


人是經驗的動物,我們的所有行為都是受到我們信念的影響,而信念則是由過去的成功(失敗)經驗所形塑出來,而盲點往往就是從這邊產生。

情緒 ABC:

A (起源事因) —> B (信念) —> C ( 情緒與行為)
A 是既存事實不會導致 C
真正促成C 的是B

不管是主管和同仁在討論事情時或多或少都會引用過去成功案例和經驗,來佐證自己的觀點的正確性,但確常常忽略產生過去經驗的情境( context ),是在怎樣的組織?處於什麼週期階段?由怎樣的人組成?這些經驗和成熟度才能適用?



而衝突就往往由這些點產生,不過有衝突也不見得是壞事啦,團隊領導的五大障礙這本書也有提到,如果把障礙反過來的正面模型則是:
  1. 團隊成員互相信任  <--先有信任才敢衝突
  2. 團隊成員含不保留地投入有關理念的衝突
  3. 團隊成員承諾達成決策和行動計畫
  4. 團隊成互相要求,為消除計畫中得障礙負起責任
  5. 團隊成員將重點放在達成集體成果

你是對的不代表我是錯的


如何有效利用建設性的衝突,重點應該要放在溝通時要多分享產生這些經驗的 context,大家才能從中找出好的部分可以借鏡,壞的部分可以避免,就像我之前整理的 薩提爾與麥肯錫菁英的思考習慣如何解決負面情緒,裡面提供了解決方法:


如何從“必須型”轉變為“願望型” 五個步驟:

第一步,要肯定你的願望或者目標是有重要價值的﹔
第二步,要去否定絕對的要求,但它不是必須要實現的﹔
第三步,要考慮多種結果的可能性﹔
第四步,現實地評價壞的結果發生的情況﹔
第五步,就是盡最大的努力去實現最好的結果。

不禁又讓我想到組織變革的張力與拉力這個議題,拉扯總是來來回回的,而同樣的議題依舊來來回回的討論...XDrz...


2020年6月9日 星期二

如何透過 PowerBI Desktop 匯入Azure Billing 資料分析



這幾年 Azure 的更新頻率非常快,但是常常是翻天覆地改變的那種,像是如何透過Power BI 分析 Billing 就變了好幾版,所以每次都得重新熟悉。最大的改變我想就是閹割掉 Power BI 網頁版的所有 Input Source ,強制規定一定只能先透過 Power BI Desktop 來設定,這對於 Mac 的使用者真的很不友善....anyway...讓我們來看看新版的介面該怎麼使用。

2020年6月8日 星期一

成功為成功之母,如何從 near miss 中找出致勝關鍵

source: near miss



在 Scrum retrospective meeting 通常會有幾種問題:覺得的好的和不好的,要繼續做的和該停止的這種討論,不過通常對於做的好的,大多會流於感謝和整能量時刻,而很少會好好去討論為什麼的成功,和關鍵指標是什麼,以及這次成功會不會真的就只是運氣好?有聽過專案驗屍會議,但是很少聽過專案成功檢討會議?

我們都知道要敢於面對失敗,因為我們更容易從失敗中學習。但是其實最常被忽略的就是從成功中學習,尤其是那種被運氣影像,『差一點就會失敗』的成功,英文稱為『near miss』。

2020年5月13日 星期三

上游問題 - 如何處理寶寶心裡苦,但寶寶不說的狀況



感謝得到-萬為綱老師搶鮮為我們介紹這本 2020 年一月剛推出,希思兄弟這本的新書,我想中文版大概要一年後才看得到?

看高手寫的書最爽的就是把那種『寶寶心裡苦,但是寶寶不說(or 不知怎麼說)』的狀況總結歸納出來,並且得到一些科學的建議。

然後我就可站在巨人的肩膀上,再透過旁徵博引的萬維鋼老師把本書脈絡整理了出來,最後讓我可以以懶人包和自己的經驗來三次創作😆

在我看來,上游思維用積極的觀點來說就是上醫治未病,但從消極面來看我想到一個問題,「先知除了在本鄉、本族、本家以外,沒有不受尊重的。」

為什麼先知總是辛苦又容易被討厭?原因有三

2020年5月3日 星期日

Go 小教室 - 如何讓mac 上的 goenv 可以選擇 1.12 以上版本


go 其實還一個很年輕的語言,所以每次升級,難免會有一些 breaking change,像最近從 1.13 升級到 1.14 就莫名的讓幾個 unit test 掛了,在還沒有時間去研究到底為什麼升版會造成 unit test 掛掉前,最好還是乖乖定版在 1.13,於是想說就灌個 goenv 來使用,沒想到用 homebrew 安裝的 goenv 卻只能安裝到 1.12beta


2020年4月23日 星期四

Inspired 產品專案管理全書 - 探索客戶計畫:用來提醒 Product Manager 的實用查核表

source: pngwave


工程師背景的我們,從以前最擅長與專注的就是在 Deliver 的優化,以及學習相關的方法論,但是隨著在社會闖蕩碰壁多年,漸漸發現其實 Define and Discovery 的方法論更是至關重要,可以幫助我們減少許多白費工的狀況發生(工程師最怕需求一直改,改出來又沒人用)。

去年聽了 Marty Cagan 的演講 - Product Is Hard ,就開始仔細閱讀『Inspired 產品專案管理全書』,並且思索如何應用在現在的產品,有許多內容和方法真是相見恨晚,在第 39 章整理了 Marty Cagan 在 2013 年寫的一篇文章  The Power of Reference Customers,而這個套路在矽谷的 SaaS company 更是隨處可見,可以在許多產品的業面看到以下訊息:


2020年4月20日 星期一

你知道在 Azure 上有幾種 On Demand 啟動 Spark 的方法嗎?



最近需要開始分析一些 Log ,最直覺的方式就是使用最熟悉的 Spark 來分析,於是開始研究最近有什麼方便在 Azure 啟動 Spark 的方式,在 AWS 和 GCP 上,之前就已經有研究過專門支援的 PaaS 服務:
我知道 Azure 有 HDInsight ,但是之前使用覺得沒有 GCP Dataproc 好用,不知道 2020 年的今天,有沒有什麼新的 Solution 呢?畢竟 Azure 的 "強項" 就是透過大量跟 3rd-party ISV 整合來壯大自己的服務

2020年4月16日 星期四

Go 小教室 - 如何檢驗 Go struct isEmpty




最近踩到一個 buffalo-pop ORM 的一個雷,範例如下:


type Job struct {
 ID             string         `json:"id" db:"id"`
 JobCreateType  JobCreateType  `json:"job_create_type" db:"job_create_type"`
 FileName       string         `json:"file_name" db:"file_name"`
 Status         JobStatus      `json:"status" db:"status"`
 CreatedAt      time.Time      `json:"created_at" db:"created_at"`
 UpdatedAt      time.Time      `json:"updated_at" db:"updated_at"`
 JobSourceInfo  *JobSourceInfo `json:"source_info" has_one:"job_source_infos" fk_id:"job_id"`
}

type JobSourceInfo struct {
 ID               string        `json:"id" db:"id"`
 JobID            string        `json:"job_id" db:"job_id"`
 SourceURL        string        `json:"source_url" db:"source_url"`
 }


一個 Job Struct 裡面有一個 Embedded Struct JobSourceInfo ,在資料庫裡面是 1 - 1 的關係,一開始產生 Job 時,並不預期一定會產生 JobScoureInfo,這時我們都會宣告為指標,理論上只要如下面範例,檢查是不是 nil 就能知道這個物件有沒被產生。

var ji *JobSourceInfo

if ji == nil {
    ji = new(JobSourceInfo)
    // do stuff 
}


但是.... Buffalo 的 ORM 的 Eager func 卻自作主張的幫我產生了一個 Empty Struct ,原本只需要檢查,指標是否為 nil ,但是現在卻得檢查是否為 empty Struct...

那讓我們來看看檢驗 Empty Struct 有幾種方法?

2020年3月29日 星期日

一談就贏:銷售贏家必勝攻略首發班心得 - 學問

業務就是巧言令色的弒血鯊魚嗎?

自從上次 Alex 在『速食遊戲演練班』宣布即將會開設新的銷售公開班,我就非常期待,這一次終於讓我搶到了頭香, 報名到了依舊秒殺的『一談就贏』之『銷售贏家』天字第一班,有很多人問我,你不是工程師嗎,為什麼要來報名銷售課程?

我的回答是:雖然我不是業務,不過跟業務都有很密切的關係,很多候要以 presales 的角色協助 sales or BD (Business Development) ,更多得時候要把他們的需求帶回來轉換成開發的 Spec。此外因為蠻長一段時間都待在新創公司,常常會需要跟老闆和 BD 們一起討論價格與商業模式~

之所以會想要來上這門課主要有幾個學習目標:
  • 瞭解什麼是好的銷售人員 (與 evaluate 的標準)
  • 學習更多關於定價與 BD 相關的知識與武器
  • 學習從 BD 與 業務看市場的角度,來協助產品開發與策略規劃

短短一天的課程可以學到那麼多東西嗎!?

2020年3月7日 星期六

關於 Azure EA 的價錢與 RI 的價錢差異



關於 Reserved Instance 每一家的規則都有一些些許的差異,Azure 的 Reserved 有幾個特點:
  • 現在買 RI 不用全額付款 (upfront ),只需要每月支付
  • 如果買了 RI 後來發現用不了那麼多,可以解約,但是要支付 12% 手續費 (退款原則)


關於 EA 與 RI 的價格差異



在網路上看到一篇文章這樣描述,EA 有折扣,RI 也有折扣,那到底怎麼計算?

後來瞭解才知道,假設一台 VM list price 是 100元,EA 和 RI 的價格方別如下:

EA     (從 list price 折扣 5%~9% off) 所以價格是 95~91 元
RI 1y (從 list price 折扣 ~40% off) 所以價格約略 60 元
RI 3y (從 list price 折扣 ~60% off) 所以價格約月 40 元

EA 與 RI 的折扣不能疊加,只能擇優計算,所以如果就算你是 EA + RI 1y ,那你也只能拿到 60元的價格。


另外根據不同的機型,我做了一個比較表,如果開發機想要省錢,直覺的想法就是只有上班時間開機,下班關機,但是如果 3y RI 買下去,就算一直開機價格也比上班開機下班關機划算~




2020年3月1日 星期日

談判系列叢書懶人包(1) - 雙贏談判



話說在還沒上一談就贏系列課程前,就從 Alex 部落格看到他介紹了許多好的談判書籍,每個月博客來剁手日就會順手買下去,但是也都沒有乖乖看完,大多只是東翻一下西翻一下,因為覺得東西太多,完全不知到要怎麼應用到實際的談判場景?


說實在的那麼多本書,每本書的特色和是用的場景都不太一樣,有些是學案例,有些是學心態,有些是學戰術,如果想要完整的學習當然還是推薦先去上 一談就贏,之後再回來看這些書就會有很大的不同,因為對於談判的框架與輪廓有了更完整的認識和練習,現在再回來看這些書就更能進入狀況,也更有感覺,開始之到該如何利用每本書的小撇步,或是把這些案例當作是戰術上的參考。

溫故而知新,現在回去看之前的作業就覺得自己好傻好天真(代表有在進步!?)

2020年1月30日 星期四

[書摘] 傳奇億萬美元級教練比爾·坎貝爾 Trillon dollar coach





Trillion Dollar Coach - The Leadership playbook of silicon valleys


之所以會對這本書感到興趣一來是好奇這本居然敢自稱『 leadership playbook 』書的內容,而另外一個主因是想瞭解一個『美式足球教練』如何轉型變成商務人士,最後甚至變成矽谷一堆高科技獨角獸公司老闆的教練和朋友( 如 Apple - Steve Jobs, Google - Eric Schmidt ...)。 

這本書基於對八十多人的採訪,並透過許多名人和獨角獸公司的故事整理與解釋了這些管理的原理。目標是為企業領導人和經理提供了一個藍圖,以創建績效更高,速度更快的文化,團隊和公司。前半段主要在描述比爾·坎貝爾的生平,接著就是穿插在許多公司時的案例,透過這本書可以讓我們瞭解這些獨角獸公司還小的時候遇到的挑戰,以及怎麼解決的,有別於市面上一堆管理的書籍講的都是這些獨角獸公司壯大以後的制度。


2020年1月29日 星期三

從Java到Go系列 - Finally and defers

source: funnyZpc



在 Java 世界最習慣的模式就是 try-finally and try-catch-finally ,主要的用途有三種:
  • try-catch 用來處理例外
  • 到了1.7 版 更可以直接用來處理 AutoClosable 的 resource
  • finally 就是用來處理一堆雜七雜八最後處理的東西,包含
    • 經過 try-catch 處理後也出錯的錯誤處理
    • 或者是一些無法 AutoClosable 的 resource
 延伸閱讀:Java Try With Resources

2020年1月27日 星期一

從Java到Go系列 - Jenkins Code coverage


歡迎來到從 Java 到 Go 系列(確定會有系列嗎...),本篇文章想要解決的問題是:

如何讓 Jenkins 顯示 Code coverage?

而會問這個問題的人通常都是來自於 Java 的開發世界,為什麼呢?

根據我的觀察,對於許多原生的 Gopher,他們反而會選擇 Gitlab-CI or Drone 這種輕量級的工具,反而比較不會選擇 Jenkins 老公公,可能原因:
  • Go 的好處就是輕盈,既然要輕盈,就輕到底,也選擇其他輕盈的框架(好啦,這是我的主觀想法,歡迎提供其他看法)
  • 反正code 就放在 Gitlab,那可以直接用整在一起的Gitlab CI 不是更佳省事 
  • Jenkins 的生態系的確比較多 Java 的 plugin(因為他就是由Java 寫的咩...)

2020年1月25日 星期六

從Java到Go系列 - Database migration tool for Go - fizz


從 Java 的世界轉換到 Go 的世界,就會開始尋找對應的服務和專案,在 Java 世界資料庫 migration 最有名的就是 liquibaseflyway ,那在 Go 的世界也有相對應的東西嗎?


2020年1月19日 星期日

獨角獸專案 - Part I 導讀 - 市場與大環境的改變





獨角獸計畫真的看的很痛苦....😂
不是英文不好的痛苦,
而是整個融入情境,想說這種公司怎麼呆的下去的痛苦,怎麼可以用這種方式做事的痛苦,作者很成功的讓我們融入主角 Maxine 的視角,看到各種 IT 行業的慘況....

市場與技術無法脫鉤


故事的背景來到 EC 已經被 Amazon 統治的現代世界,小說中的零件無極限(Parts Unlimited)公司面臨到最大的商業挑戰就是消費者的消費型態已經改變,消費者可能不會再到店面跟零售商買東西,更多的是透過網路和電話購買。但是零件無極限(Parts Unlimited)公司的高層不斷提醒員工,客戶真的需要的還是可以相信的人,並不是透過冷冰冰的網路自行購買零件,所以才有鳳凰計畫,希望幫助零售商可以提升服務進行數位轉型。

但是就像許多企業一樣,上層的命令與計畫傳達到執行端,往往已經扭曲變形.....


2020年1月12日 星期日

獨角獸專案 - Part I 導讀 - 濃濃的臭氣味





Part I 故事背景


Maxine(女)剛渡假回來,就遇到無限公司的薪資系統大當機事件,雖然罪不在於她,但是為了給董事會交代,他的上司 Chris 決定把她調職,調往集團罪惡名昭彰的『鳳凰專案』,希望她過去幾個月負責處理文件的部分,Maxine 感到沮喪憤怒,覺的公司就是要要找人當代罪羔羊,想要逼她走,不過她的老闆 Chris 卻又一直強調,只是調她去那邊避避風頭放個假,之後再把她調回來...

而這個『鳳凰專案』就是上一集故事中的那個專案,話說我已經忘記上一集結局是啥(原本以為已經成功了),沒想到那個專案已經三年過去,仍在虧損沒有成功的死亡行軍中....🙈