因為自己屬於 notion 重度使用者,每日大小紀錄甚至工作上都會用到它,一天 notion 裡面泡個幾個小時那種。也因此,操作的效率變成資訊處理的瓶頸,工欲善其事必先利其器,這裡就來分享一下可以省下我大量時間的兩個工具:快捷鍵 & notion-enhancer

Image for post
Image for post

快捷鍵

官方快捷鍵文章寫得非常詳盡,推薦閱讀 https://www.notion.so/Learn-the-shortcuts-66e28cec810548c3a4061513126766b0。也整理一下那些比較常用的指令。分兩種類型:一般操作&基本文字編輯

一般操作

  • ⌘ + P 搜尋所有檔案
  • ⌘ + [ / ⌘ + ] 前一頁/後一頁
  • ⌘ + \\ 開關側欄
  • / 帶出功能選單
  • ⌘ + ⌥ + 0~9 把內文轉變為各種不同樣式
  • ⌘ + + / ⌘ + - / ⌘ …


Image for post
Image for post
很快的我們即將從 2020 畢業

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

會議準備

此回顧會議與平常最大的差別在於時間跨度是平常回顧會議的 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 個來聚焦。讓團隊專注在重要的目標上,齊力解決同一個問題。

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

目標的釐清

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

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

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

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

以及,更多的『要做什麼』:

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


Image for post
Image for post

相較於第一天的演說形式,第二天主題是各式工作坊。身為一個工程師當然是直接選擇技術軌,由 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)』的主軸。先說結論:參與後的收穫非常切合此主 …


Image for post
Image for post

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

  • 專注的力量:透過共同的目標讓團隊一起做好一件事情
  • 團隊合作:透明化的目標設定讓團隊可以彼此協調、統整
  • 掌握進度:建立明確的指標,以確實掌握進度,並依據狀況適時調整
  • 自我挑戰:Aim High,突破自我
  • 回饋與改進:面對未知的世界,瞎子摸象的我們需要邊探索邊調整方向與戰術
  • 組織文化:打造組織適當的準則與環境,讓上述各點得以順利實現
這是讀書會的摘要,因此除了書本內容之外,也包含了成員間的討論與相關的工作坊/作業。這是我們的成長紀錄,也是一種參考案例,希望能夠與對 OKR 同樣有興趣的讀者們一同交流。

什麼是 OKR?

OKR 全名 Obj …


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

年輕人終究是年輕人 https://memes.tw/gif-maker

實際建構過幾個專案後一定會碰到這問題,於是我們會想要讓程式碼更好維護,這時就需要 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/

Image for post
Image for post
image from: https://www.techtello.com/how-to-deal-with-difficult-people/

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

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

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

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

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


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

Image for post
Image for post
此 class 非彼 class

結構

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


此為番外回顧篇,若對結對有興趣可以參考系列文:結對程設指南

Image for post
Image for post

若要說開始結對的原因,最主要的就是因為系統與人員開始日趨複雜,因此需要增加技術與系統知識的交流,於是就選了結對的方式來嘗試增加團隊的技能深度與廣度。在此之前,團隊雖然也常互相討論,但通常就是在團隊程式碼審查的時間或是遇到問題時請教比較了解的人,一般情況下不會結對。

團隊於六月中開始認真結對,每個 sprint 都會安排成員至少一到兩小時的結對時間。結對時間與主題是由成員自行決定,通常都是挑那個 sprint 比較有挑戰性、有討論性的任務來進行。

兩個月後,我們也想知道結對對我們產生了什麼影響,於是有了第一次的結對回顧會議。就讓我們來看看一個初次認真進行結對的團隊,會有什麼樣子的反饋及想法吧~

結對後大家的回顧重點

這次回顧會議以四個面向依序蒐集大家對結對的看法,分別為 1. 喜歡的地方 2. 可以改善的地方 3. 有疑問的地方 4. 之後想試試看,整理如下:

👍 讚 / 喜歡的地方

  • 為了溝通交流順暢,需要先整理思考自己的想法
  • 一起解決遇到的問題,可以學到自己都沒想過的解決方式,比如資訊的搜集、或是不會的寫法
  • 夥伴可以在討論想法時幫助突破盲點、自己一個人會卡的地方突然就跨過去了
  • 即時且互相的程式碼審查,並討論 coding guideline
  • 多理解了些自己沒碰過的功能
  • 交流開發習慣

👎 噓 / 可以改善的地方

  • 技術落差太大時會跟不上、靈魂飄走
  • 兩個人都沒見過不會解的問題時,一起卡關
  • 無法長期集中注意力
  • 太多東西看不懂(?)
  • 遇到障礙導致開發不順暢,擔心夥伴覺得卡(夥伴表示:沒有啊我沒感覺…)
  • 對於重複解釋沒有耐心

❓有疑問的地方

  • 目標和主題的選擇是否應該更適合結對的兩人?
  • 非程式面的東西,比如架構或是商業邏輯的釐清是否算在結對範疇內?
  • 思考結對該用什麼主題與素材也很耗費時間
  • 任務提早做完沒東西結對

💡 之後想試試看

  • 覺得沒有效果時就果斷暫停結對,並討論後續處理,無論是休息、延期或直接放棄
  • 自行依照任務需求決定結對長度
  • 輪流敲鍵盤
  • 先約時間、設定主題,雙方才有時間先想好要做什麼

一番討論後的幾個想法

沒耐心的部分,需要調整各自的期望

在一個自主性高的團隊內,沒耐心的狀況都是對彼此的期望太高,希望對方可以做得更好。這一方面可以透過多次輪替互相觀摩彼此結對的方式來加強,另一方面也是磨練自己溝通與引導能力的好機會。

結對不只是一起寫程式

架構的發想、溝通,商業邏輯的探究,這些有助於最終產出品質的事項都可以是結對的一部分

不一定要挑自己拿手的主題

結對中你可能擔任引導者、或被引導者、更常見的是兩種身份都有,因此不一定要挑選自己熟悉的主題,甚至也不一定要有人熟悉,只要兩人認為有辦法共同在這主題上創造出足夠的價值就已足夠。

任務提早做完時

可以參照 91 的建議進行向上結對,甚至如結對程設指南(4):結對?不結對?中所說,就算剩下的是無聊的任務仍然是可以結對的。

改善

為了讓結對能產生更多的價值,我們列出了兩個主要的可執行行動:

Sprint Planning 時先敲定結對的人、主題與時間

事前敲定時間與主題可讓雙方有機會在事前準備相關資訊;熟悉的人可以整理自己所知,而不熟悉的也可以先行做功課,希望有助於結對的順利進行。

同時,由結對的兩人先行決定主題,也可以避免知識落差太大的狀況,進而減少跟不上的狀況。

結對過程中,如果覺得沒有效果時就果斷暫停結對,並討論後續處理,無論是休息、延期或直接放棄

結對不是一定就要作伙到底。結對過程一定會遇到許多不同狀況,如果是累了就休息一下或擇期再戰;如果卡關且兩人都不知如何是好,那也可以分頭進行或是直接拆夥讓主事者先處理,等回到軌道再行結合。

另外有時候注意力不足有可能是對於主題的認知與參與度不夠,這種狀況不是主題會需要調整,不然就是參與雙方需要就參與度不夠的點多下點功伕(主動了解/引導方試著準備更合宜的資訊/兩者都要)

結論

雖然才短短兩個月,但結對確實增加了團隊的資訊流動,大家也都認為這是個有幫助的活動。回頭看結對程設指南 (3):可能遇到的挑戰會發現,其實裡面所提到的挑戰多多少少都有遇到。不過由於團隊的心態與溝通能力本來就不是個大問題,因此比較卡的地方主要落在知識落差以及合適的中斷機制,透過此次回顧我們也有了初步的改善方案。

有幸處在自主性以及溝通能力都很好的團隊,其實會形成一個互相學習勉勵的氛圍,因此只要適時的透過回顧來呈現問題並且找出共識以及可執行行動,再來就是讓子彈再飛一會兒,然後再次的回顧以及再次的成長了~

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store