獨角獸專案-小記

NotesDevOps11 mins

如果你是一位工程師,並且你覺得孤立無援但你又胸懷大志,那麼你適合讀這本書

如果你是一位專案管理人又有一些開發經驗,那麼你要先看鳳凰專案

獨角獸專案是鳳凰專案的後續作品,與鳳凰專案以專案管理人的立場出發不同,這本書是以 RD 及 QA 的角度出發,並且深刻描述平時工作時會經歷的問題,如: 不知所云的工作文件、層層審核的工作流程及工單系統、莫名其妙的戰犯轉移和背鍋、奇怪的高層組織決策、相互制衡的組織關係、沒有效率的會議討論及工作流程...等等。

其實你並不孤單,因為這個世界上時時刻刻都在上演同樣的戲碼,甚至今天有一本書能讓你讀起來相當寫實,本書的主角正和你一樣經歷了一連串的低潮及崩潰,但還是找到了一群志同道合的夥伴及曙光,並且正默默的為組織未來的進步及發展,掀起一系列革命。

隨著章節的推進,與鳳凰專案的風格相同,除了可以經歷人物心情高低起伏變化之外,在獨角獸專案是以工程師的角度與立場來描述要從瀑布流開發(Water fall)、隕石開發(Meteor Fall)到敏捷開發 (Agile) 時的一些契機與念想。

這是一個關於反骨開發人員和商業領導者共同努力,在充滿不確定和分秒必爭的時刻,不斷進行創新,生存和發展的故事。

如果對故事有興趣或對當前工作環境感到困惑及絕望,不妨翻翻這兩本書,我想你會獲得一些啟示及方向

那麼,鳳凰專案強調的 "三步工作法則" 及 "四個工作分類" 是什麼?

獨角獸專案說的 "五大理念" 又是什麼?

關於三步工作法則

一、第一步: 暢流原則

連續建置、整合及部署,需要隨著建立環境,嚴控在製品及建構能安全進行變更的系統及組織。讓由左至右的流量最大化。

二、第二步: 回饋原則

藉由持續流動的快速回饋,放大效益,並且避免問題再次發生,更快速的發現及修復問題。

  • 每天持續改善日常工作
  • 建立自動化測試,並確保程式碼處於隨時可部署的狀態
  • 在開發與 IT 運維之間建立共同的目標及同甘共苦的文化
  • 建立普遍性的產品觀測機制,讓每個人都能看到程式碼環境是否按照設計進行,以及是否達到客戶的目標(Kibana)

三、第三步: 持續學習與實驗原則

創造公司及團隊文化,鼓勵團隊建立創新、勇於冒險( 相對於畏懼或盲目服從命令)及高度信任的文化(相對於低信任度的指揮控制文化),透過實驗及承擔風險,持續不斷改善日常工作流程系統。不斷的反覆及操演,能提供足夠的技能和經驗,讓我們能回到安全區域及正常運作

關於四個工作分類

  • 業務專案
  • IT內部專案
  • 變更
  • 計劃外工作或救火工作

關於五個理念

一、區域性和簡潔性 (Locality and Simplicity)

區域性和簡潔性讓系統維持低耦合,幫助團隊成員能有信心的獨立進行開發、測試及交付項目,快速創價值!

區域性的要求是讓團隊中的人員在開發時不會受到其他團隊或部門的制衡,每個人都能快速、自信且安全的對系統進行更改,讓我們透過領域關注,將時間花在真正需要關注的地方,如果只需更改一個文件,一個模塊,一個組件,一個 API 調用,一個容器,一個應用程序或其他任何內容,就可以創造價值! 豈不快哉!?

反之,當開發人員因為技術債(technical debt)或太過耦合的系統架構,一個簡單的變更需求隨時都可能變成災難,你需要經過前端部門、後端部門、資料處理部門及上級的核准及協助才能進行,當你開完成了變更,你又需要各部門協助驗證及確認,再花一次時間在等待上,反覆操作直到成果正確。當我們把所有時間花在跨部門的交涉、程序申請及驗證,不可避免的結果是簡單的任務變複雜,而且需要更多的時間,也因此不管團隊成員再怎麼努力,最後團隊效率都顯得不佳,甚至系統因為技術債的關係太過耦合,導致時間都花在償還技術債,而不是創新功能上。

簡單性可以實現區域性,如透過函式編程 (Functional Programming)、微服務 (Microservices),可以讓我們專注在一個點上的需求,讓系統之間保持耦合,我們可以快速的交付功能及創造價值。團隊可以快速且獨立的專注在幫助客戶成功上,並透過測試和持續整合(CI)與交付(CD, 如: Blue/Green),增加我們對於項目的信心。讓每個團隊都能為自己的項目做決策,而無需獲得遠在天邊近在眼前的主管批准,導致問題或者結果在很晚才被發現。

二、專注, 流暢和快樂 Focus, Flow and Joy

維持工作的快樂與成就是金錢無法取代的,正能量會讓你自己及團隊成就非凡

第二個理念,想探討的的是每天的工作感受,你是否每天都一成不變,日復一日的工作?甚至不知道完成的項目對客戶有什麼幫助?再提交項目的時候,甚至看不到你的成果及回饋,只有在問題發生,接受處罰時才有你的份?每天就像是機器人一樣重複性的工作,也不在意產出,除了金錢報酬之外,工作一點成就感也沒有?如果是這樣,你正在失去挑戰、學習及發現的快樂,工作帶給你的只是無止盡的痛苦跟義務,不能讓你獲得心理上的滿足,遲早你會隨著時間失去熱情及自我。

反之,如果你可以獲得快速而持續的反饋,可以讓你更加專注、專心、挑戰、學習、發現和精通自己的專業領域,藉由幫助他人改善生活及實踐,使你獲得心理上的滿足,每天的工作都讓你覺得意義非凡,那麼快樂自然而來。

試著想想剛從學校畢業,踏入社會接受挑戰,一切都很新鮮時,每天的期待。如果你深陷泥淖,那麼你得停下腳步,思考如何重拾自己的快樂,這個環境是否真的適合你?你有更好的選擇嗎?

三、持續改善日常工作 Improvement of Daily Work

如果你在發現了既有規則及流程缺陷,那麼你應該提出問題,並且修正它

你的一小步及經驗分享,可以為整個團隊帶來巨大的效益

第三個理念,想探討的是藉由持續回饋來解決尚未發現或即將發生的問題,以廣為人知的 Toyota Andon Cord 為例,我們可以試者思考在日復一日的工作中,如何提高工作水平?Andon Cord 在 Toyota 的用途是當工廠問題發生時,只要拉下這個繩索,整個產線會因為這個安全機制而停擺,大家一起專注在解決這個問題上,同時公司會感謝他們這樣做,而不是追究責任,因為這提供了一個日常改善的機會,讓問題在還沒擴大之前就能被發現,並且透過其他人的幫助,而被解決。這些知識隨後也將被廣泛的傳遞及分享,讓所有工廠的人都可以從中學習受益,避免問題再次發生。

這個持續改善的流程,就好比開發人員透過持續修改 pipeline、script 讓流程最佳化,儘管一開始的版本可能漏洞百出,但隨著團隊不斷的貢獻及回饋,最終會產出一個最佳解,讓團隊的工作流程更有效率。

四、心理上的安全感 Psychological Safety

面對及討論問題本身,而非針對犯錯者咎責

關於第四個理念,想探討團隊領導中的五大障礙,分別為:

  • 缺乏信任:不願在團隊中顯示弱點
  • 害怕衝突:尋求表面的和諧,重於建設性的激情辯論
  • 缺乏擔當:假意認同團隊的決策,在整個組織中形成模稜兩可的文化
  • 規避問責:對同儕的失職行為,不表態、不咎責,致使團隊的工作標準降低
  • 漠視結果:只聚焦於個人的成就、地位和自我價值,超過團隊的成敗

上面的五點是人的本性,基於自我保護的意識,當有危機來臨時,人類並不會隨意暴露自己的弱點,承擔風險?逃命都來不及了,怎麼可能讓自己成為代罪羔羊。

然而在這樣的氛圍下,再也沒有人敢冒險,團隊也就失去了創新跟實驗的機會

下列兩種情境,哪個團隊會發展得更好?

A 團隊,每個人都勇敢的冒險制定決策並且承擔風險,每天解決問題,並且向其他人分享碰到的問題及所學到的知識。

B 團隊,由主管來決策並且承擔風險,團隊成員僅需要依照主管所規劃的解決方案來執行,碰到問題時向主管匯報並且尋求解答。

為了讓團隊更快速的成長,管理者要為團隊成員建立安全感,當問題發生時,探究的是問題發生的原因,而非是誰產生了問題,並且要讓任何人都能勇敢的提出意見,不會因為各持己見而感到尷尬或受罰,在歸納出原因後將訊息盡可能的傳遞,讓團隊成員盡可能有同樣的思維,這點和前幾個理念是相輔相成,唯有足夠的安全感,才能讓團隊成員暢所欲言,勇於改善,創造價值。

五、以顧客為中心 Customer Focus

什麼服務和產品對於客戶是有價值的?是否真正解決了客戶問題?
  1. 藉由數據將客戶依照不同習性和行為做分類,提供適合的服務或產品給對應的客戶
  2. 實際前往第一線,你會發現你以為的最佳流程,對於使用者來說一點也不
  3. 放下那些不夠好的東西,留下並且精進那些有價值的東西

書中提到的第五個理念,在產業快速發展的今天,我們可以從各大公司發現類似的現象,以蘋果為例,在每年發表會中都會提出許多產品,但是今年全新的產品,在下個年度可能不會在販售,亦或者是有更新的規格。以音樂隨身聽 iPod 來說,在沒有 iPhone 之前,可說是人手一機,賣得嚇嚇叫,有 nano, shuffle, classic 等等不同大小的款式,這項產品可說是當年蘋果除了電腦之外,最熱賣的商品之一。

但在 iPhone 橫空出世之後,你如果可以在 iPhone 上有相同的音樂體驗,那麼你就不會想要每天多放一個 iPod 在口袋,只為了聽音樂這件事情,隨著 iPhone 的功能越來越多及成熟, iPod 最終就消失在市場上,然而使用者卻不會覺得少了什麼,因為他們已經有相同功能且更便利的工具。

想在市場中獲勝,唯有以快勝慢。而堅持創新、持續突破的大公司,幾乎每次都能旗開得勝
破壞式創新,造就成功。i.e. Facebook, Apple, Amazon, Netflix, Google, Tesla

MVP

傑出工程師 (Distinguished engineer, DE)

個人貢獻者 (Individual Contributor, IC)

© 2024, All rights reserved.