年末了，也是該好好地回顧整過去一整年。這次靈光一閃把平常兩週一次的回顧會議主題設定為『歲末年終感謝祭』，目標是讓大家重溫這一年，並且最後依據這一年的狀態找出下一年可以改善的方向。由於討論的內容與時間跨度一定與平常不同，自然需要準備的東西不同，這裡就來分享一下最後這個會議做了什麼：

會議準備

此回顧會議與平常最大的差別在於時間跨度是平常回顧會議的 26 倍（我們兩週一個 sprint），一般人連昨天午餐吃什麼都不一定有辦法馬上想得出來，因此第一要務是需要先整理過去一年發生的重點事項，好讓大家有個回顧的基礎。

為了幫助團隊回想並且找出好的改善行動，重點事項的角度可以是產品面、技術面、甚至一些大環境、個人生活面的。此時可以善用團隊的紀錄文件尤其是 planning / refinement / review / retro 紀錄，來幫助自己整理出重點。包含 planning 規劃的功能、refinement 常被提出的需求、每次回顧的可執行事項等。

為了讓討論可以更順利進行，最好是在會議前就先把這些重點拋出，讓大家有時間好好回憶這段時間發生了什麼。試想如果直接在會議上突然拋出這些，大家沒有時間消化，最後的想法可能都還是會以近期印象比較深刻的事項為主，那就失去我們想要做『年度』回顧的初衷。

會議的進行

會議本身仍然可以依照團隊習慣的回顧方式進行，最大差異在這次大家要產生的是『現在就可以開始、明年有可能持續進行的改善事項』。以下是我們自己的玩法：

1. 分享三件 2020 最有成就感的事情，其中一件是大家可能不知道的事情
2. 2020 想感謝的三個人事物，其中有一件是大家可能不知道的事情
3. 2021 你最期待的三件事？

1 與 2 自然是讓大家分享與互相肯定彼此的成就，這次也試著加入一點變化，讓大家分享一些『不為人知的秘辛』，透過自我揭露希望讓大家能更了解彼此。另外也可以從不同角度來理解成員們各自在意的地方，同時也可以觀察團隊的透明度狀況。

重頭戲自然是第三點的『新年新希望』，從大家期待的事項，來反推現在還有哪裡需要加強的，然後挖坑給大家跳（誤）。儘管我們 OKR 也是會歸納成員們想做的事，但畢竟 OKR 是比較目標導向，容易忽略一些不在目標上的事項。這同時也是可以檢視團隊認知是否一致，如果大家對產品的認知出入沒有太大，就會出現類似的期待。舉個反例：如果有人認為產品才在 poc 階段、有人認為已經可以開始推廣，就會同時出現對於產品功能加強以及業績增強的期待。由於這裡會討論的幾乎是 OKR 目標等級的議題，但也是個取得大家共識的好機會，同時找出大家可以開始動作的起點。

可執行事項

這些動作的起點自然就變成最後產生出來的『可執行事項』了，這次的可執行事項有可能背後揹負著的是一整年的期望，因此寫『可執行事項』需要寫明確點，不要寫『做出 XXX 大功能』，而是在討論時就需要討論可以怎麼開始，比如『與相關 stakeholder 協調 XXX 進行方式』、『規劃 XXX 功能』。（SMART 原則還記得吧）

這些可執行事項的目的是負責點火（開始），並且確保接火花有人接手，可以持續的燃燒。如果我們想要有個明確的結果，那麼有個明確的開始也許是個不錯的方式。

我們新年新希望

說最大的希望當然是持續透過產品來讓求職及招募變得更方便、讓雙方能夠找到更合適的彼此，為了達到這個目標嘛…團隊仍在招募中，希望加入可以自由發揮技術同時對產品開發有興趣的，歡迎與我們聊聊

摘要

• 整理過去一年的重要事項
• 如果產不出來，表示需要開始記錄開發的狀況（恭喜你，新的『可執行事項』get!）
• 回顧會議的熱身階段也變得相對比較重要，因為我們平常不會以年為單位來討論，需要花些時間來進入狀況
• 由於跨度較大，建議時間拉長為兩倍。也因為時間拉長為兩倍，就需要設定中途休息時間、會議室的重新確認等，此外順便訂個下午茶大家吃吃喝喝放鬆點吧
• 重點！！！ 產生出『可執行事項』，並確保有後續的動作
• 明年記得回來看看這些『可執行事項』

資源是有限的，需求是無窮的。想要把事情完成，就要挑重要且可以完成的先做。這也是 OKR 這本書所強調的第一個重點：透過限制目標數量 3–5 個來聚焦。讓團隊專注在重要的目標上，齊力解決同一個問題。

Ｑ：集中火力時是否容易重工？Ａ：的確比較容易，但分散火力時也會有方向不確定沒有把資源有效使用在正確方向上的問題。且大家如果都在做同件事情且彼此間的溝通良好（後面會再細講溝通）的話，反而會比較容易發現重工的部分，比起來分散目標容易造成各自為政，浪費資源的情況會比聚焦時的重工來得嚴重。

目標的釐清

要所有人聚焦，把目標搞清楚是很重要的。OKR 把目標管理這件複雜的事情濃縮成了 『目標』以及『關鍵結果』之下的簡單文字。舉一個實際的例子，我們身為一個求職平台，一開始可能會有這樣子的 OKR：

目標：協助求職者找到工作
關鍵結果：1. 投遞量 + 400% 2. 每月活躍用戶 MAU + 200% 3. 給他一隻貓

乍看也許簡單清楚，但實際上當成員們開始討論時，就會冒出許多『為什麼』：

• 為什麼目標是協助求職者而不是招募者？協助求職者可以讓我們發大財嗎？
• 為什麼是用投遞量與每月活躍用戶來衡量？為什麼不用 XXX 指標？
• 找到工作就好了嗎？那我們與 YYY 有什麼差別？這樣是不是違背了組織願景？
• 為什麼要給他一隻貓

以及，更多的『要做什麼』：

• 所謂的『協助』要做什麼事情？
• 我們有辦法計算 MAU 嗎？
• 怎樣算是『找到工作』？
• 我有個大膽的想法可以幫助求職者找到工作，但他會大幅降低我們的活躍用戶，試問單兵該如何處置？
• 我覺得可以做 A 功能來提升投遞量，但另一個團隊成員覺得 B 功能比較好，dochi?
• 所以我們該做什麼來提升投遞量？提升 MAU？
• 預計要做的功能 C 看起來對任何一個 OKR 沒有幫助，還要做嗎？
• 要一隻貓有難度，可以給空氣鳳梨就好嗎？

相較於第一天的演說形式，第二天主題是各式工作坊。身為一個工程師當然是直接選擇技術軌，由 3D 四少 REFK — River, Eason, Fong, Kim 帶來的『DDD 深度歷險：從戰略到戰術』。四位大大加上助教群百年功力（？）加持下，工作坊可謂收穫滿滿。

工作坊分為三個部分： 事件風暴 Event Storming、戰術建模 Tactic Modeling、以及 Example Mapping，最後一部分由於有事提早離開沒有參與到，這裡就來分享一下第一次玩事件風暴以及戰術建模的一些想法。

事件風暴 Event Storming

事件風暴這類大型協作討論，首選還是使用超大的白板，不過現場工作坊分成八組，沒有地方放八個超大白板， 因此使用的是電子白板軟體 miro。先給大家看我們的成果，主題是假想的機票搜尋訂購網站的系統流程： https://miro.com/app/board/o9J_leUokrk=/

首先，無論事件風暴、User Story Mapping 或是 Wireframe ，背後都有個重點：對齊大家的認知，避免產生各種錯覺。同時透過群體討論破除各自的知識詛咒、認知固化所產生之盲點，並建立群體的共識。而事件風暴則是透過團隊與領域專家共同討論，讓團隊能夠把領域知識轉化為系統架構與流程的一個過程。

200/11/27–28 是台灣第一屆的領域驅動設計 (下以 DDD 簡稱) 年會，光是聽到 DDD 很多人會以為是工程師的名詞，但這真的誤會大了，讓我先用一句話來介紹 DDD：

領域驅動設計 Domain Driven Design ，是透過專注理解領域問題並以此建構相對應軟體的一套方法

整個方法包含兩大部分：理解領域問題、以及建構相對應軟體。『理解領域問題』有很多可以討論的：誰該理解？理解什麼？怎麼理解？為什麼要理解？『建構相對應軟體』聽起來就是工程師的主場，但工程師光是看書上所寫很難有實際的感受，也一定不知道如何下手。

DDD 涵蓋的範圍非常的廣，初探 DDD 的人如我難免有上述一堆問題，這也很切合此次年會『讓更多人知道何謂領域驅動設計 (DDD)』的主軸。先說結論：參與後的收穫非常切合此主 …

公司讀書會來跟風近年很夯的 『OKR： 做最重要的事』。此系列文將紀錄我們的 OKR 學習討論歷程。本文為簡單的 kickoff 及基本介紹，之後預計依序探討以下幾個 OKR 的核心觀念：

• 專注的力量：透過共同的目標讓團隊一起做好一件事情
• 團隊合作：透明化的目標設定讓團隊可以彼此協調、統整
• 掌握進度：建立明確的指標，以確實掌握進度，並依據狀況適時調整
• 自我挑戰：Aim High，突破自我
• 回饋與改進：面對未知的世界，瞎子摸象的我們需要邊探索邊調整方向與戰術
• 組織文化：打造組織適當的準則與環境，讓上述各點得以順利實現

這是讀書會的摘要，因此除了書本內容之外，也包含了成員間的討論與相關的工作坊／作業。這是我們的成長紀錄，也是一種參考案例，希望能夠與對 OKR 同樣有興趣的讀者們一同交流。

什麼是 OKR？

OKR 全名 Obj …

當專案變大、變複雜，若是不好好處理，維護成本或是開發成本都會逐漸提升，最後到一種無法動彈的地步。系統演變至此，（看起來）最低成本的方式就是砍掉重練了。

實際建構過幾個專案後一定會碰到這問題，於是我們會想要讓程式碼更好維護，這時就需要 SOLID 原則的幫忙。系列文預計依序介紹 SOLID 的五個原則，來看看這五個原則將如何應用在 React 專案內，本文將從第一個原則開始：

單一責任原則 SRP Single Responsibility Principle

A class should have one, and only one, reason to change.

在跳進 React 範例之前，還是先來回顧一下單一責任原則。這是一個相對容易理解的原則，套用到 React 專案就是，一個功能拆成一個元件（檔案） …

原文網址 https://www.techtello.com/how-to-deal-with-difficult-people/

人類這種生物有著天生的社交需求，社交的目的之一是透過交流來獲得他人的認可。當他人與我們有相同的信念時，我們會感覺良好，覺得被肯定，反之則會失落。很自然的，我們喜歡與我們相近的人共事，所謂的『同溫層』。

因此，當有人貶低我們的意見、否定我們的想法、忽略我們要說的，表現得像個萬事通、以批評為樂、創造負面的能量，就會讓我們覺得很不開心。這些『難相處的人』的行為總是會踩到我們的地雷，他們應該為製造的麻煩負責，畢竟，他們才是有問題的那群。

人們的困擾不是來自事情的本身，而是來自他們對事情的看法。

— 斯多噶派哲學家愛比克泰德 (Epictetus)

也許我們對難相處的人的看法 …

至此，我們討論了命名、函式、註解、物件、測試等，是時候該把抽象層級往上一層，進入到『類別』了。類別是變數與函式的組合，也是在一般 OOP 下最常被使用到的元素之一，不過也由於在抽象層級上多了一層，其複雜度也相對更高。

結構

一般類別會有變數、函式，加上兩種面向：存取權限（公開／私有／有的還有保護級 protected ）、靜態 static／實例 instance，總共可以產生八種組合。八種說多不多說少不少，我們應該以固定的順序來安排，以提升可讀性。多數程式語言的變數是需要先宣告的，因此變數會放在函式之前，其他的話可以依照由高階任務往低階實作細節的順序，如此的好處是可以讓人閱讀起來能夠先看到全貌，再往下看到細節。至於靜態／非靜態可以分開處理，畢竟使用情境其實完全不同，而靜態變數／函式通常是比較泛用 …