Blog

使用 Notion 建構 ZTD 簡潔風格的時間暨工作管理 (提供模板下載) – 1/2

ZTD in Notion Feature Image

前言

原來一直是使用 Microsoft To Do (併購自 Wunderlist) 記錄我的工作項目,它挺不錯用,符合簡潔 (simplicity) 原則。不過我打算把所有關於生產力 (productivity) 機制都集中到 Notion 統一管理,盡量降低多種工具的使用,所以花了一些時間研究並製作成 ZTD 簡潔風格的時間暨工作管理系統,這裏就分享下這套系統所使用的方法與想法,文後也提供了完整的 Notion 模板供下載,可以自行複製 (duplicate) 並擴展/客製化,打造自己的工作管理 (task management)。

我採用的方法論主要有兩種:ZTD (Zen to Done) 與「吃了那隻青蛙」每天只專注三件最重要的事情。相對於目前主流的 SCRUM、子彈筆記工作管理 這些太過緊湊的方式,並不適合我,我還是比較喜好簡潔風格,不要給自己每天太大壓力,只專注作最重要的事項就好。

ZTD 是一種簡化 GTD (Getting Thing Done) 的時間管理方法論 (methodology),頭字那個 Z 就有「禪 (Zen)」的意味,簡約與樸實,流水不爭先。這裏有篇文章:「時間管理:GTD與ZTD」,解釋兩者的異同之處。

引用該文所述:「ZTD 是一套系統,但不是一系列習慣的改變,而是一次聚焦一個習慣;除了計劃,它更聚焦於行動以及如何用簡單、無壓力的行為完成任務,幫助我們建立有條理的高效能習慣。」

ZTD 簡化後的四種習慣:「搜集、處理、計劃、行動」。

而「每天只專注在做三件最重要的事情」,則是源自於「吃了那隻青蛙」一書,作者 Brian Tracy 是非常知名的成功學大師,他這本著作,強烈推薦必讀,簡單扼要。最精扼的心法就是:每天早晨起床,依據從週與前一日的規劃,來決定今天最大隻的青蛙先把它吃掉,如此這天就再也沒有可以難倒你的事!

閱讀全文 »

聊聊關於 UML 輔導個案的二三事

** 本文同步發表於 FB社群-軟體設計鮮思維 **

UML System Sequence Diagram

前兩個星期有位上過前一期「軟體架構師」課程的學員,他在某大金融單位擔任技術職PM,特地利用週末時間到我家附近,請教我關於他利用 UML 所繪製的設計圖問題。相當認真,所以我很願意陪他一同討論軟體相關議題,順道一同在肯德基吃午餐。總共花了約兩個來小時吧,該學員還要去參加他的讀書會,真是有夠認真啊,不過起碼有討論出一個比較具代表性的使用案例其實現的主要程序描述。

畫出來是否正確或合理與否是一回事,至少他肯利用 UML 表現出他的設計思維就很值得肯定,這才有機會可以指指點點與討論的。

他只畫了使用案例圖與某一結構設計的類別圖,因爲有公司機密問題,這裏就不方便貼出他的原稿。我只就他的設計給予一些建議與修正,並利用他在 Mac 所使用的 UML 工具繪製出來。

黑曜石 (Obsidian) 解開我如何記錄與整理筆記的枷鎖

Obsidian Screenshot

長久以來我一直對於該如何有效記錄與整理數位筆記相當苦惱,尤其是對筆記的資料夾如何分類,以及筆記如何有效查找與索引,一直不得其要領。

我自己有訂閱了 EvernoteNotion 專業用戶,前者用來擷取 (web clip) 網頁內容非常好用,應該是目前地表最強的網頁擷取的工具了;而後者則是這兩年超夯的雲端筆記軟體了,衆多 Youtuber 極力推薦並發表好多使用心得,看這篇:「為什麼許多人都改用 Notion 做為主力筆記軟體?看完這個你就明白了 👍

然而我從 Evernote 轉至 Notion,使用體驗上都還是覺得總有那種說不出的不順手。前者提供太多功能但卻覺擁腫;後者我發現到它大多被應用於如何提昇「生產力 (productivity)」上,例如工作/專案管理、習慣追蹤、整理個人文件數據庫 …等。這兩者對於「純」筆記的記錄與整理,總覺得沒那麼「簡單、直覺」,尤其後者最大的硬傷在於無法本機儲存數位資訊,而且竟然沒有支援完整 HTML 排版,雖提供多樣化的頁面組織元素,甚強調說有支援 Markdown 語法,但其實都只是一小部分而已。

就上個星期隨意瀏覽 Youtube 視頻,再次瀏覽到這篇 (其實以前就有看到該篇視頻,但當時正在研究 Notion 的應用就忽視了,而也正因爲有使用 Notion 後的體驗才能更有感吧。) :「天哪我給大腦開外掛了!它完全顛覆了大家對筆記軟體的認知|Obsidian 教學-YouTube (這一篇視頻對入門者強烈推薦)」,這才發掘到這樣的筆記軟體不正就是符合我所想要的嗎?! - 簡單!!

閱讀全文 »

關於 Udemy 線上課程平台課程大綱規劃與模板 (提供下載)

最近在整理原來實體課程的教材內容,準備移轉到線上教學平台上 (我的第一個線上課程應確定爲「活用 UML 體現軟體設計思維」),首先考量的應該是國外最大的教學平台 - Udemy

實體教學與線上教學肯定是截然不同的方式,前者重於與學員的「互動」,甚而需「因材施教」,動態改變課程內容;但後者並沒有可與之互動的觀衆,所以事前錄製的內容與呈現方式,以及每一個單元的主題與目標,就要相當明確了。

最主要的呈現方式當然就是視頻錄製,並可以使用如 Powerpoint 的簡報作課程大綱與內容說明,另外涉及到開發工具的操作等,就需要螢幕錄製操作步驟。每一個視頻單元,據我大量查看 Udemy 衆多課程講師,大都爲 5~10 分鐘左右,單元主題要能切中該視頻內容,可以是很通俗的命名。

與我實體課程規劃大綱的方式最大的不同是,Udemy 課程大綱主要只有兩層:Section 與 Lecture

Section 比較像是章、節的概念,而 Lecture 與傳統書籍大綱內的小節觀念可能不大相同,它要呈現的是一個講課、講座、講稿這樣的概念。

Section 比較容易界定,一個「章/節」的目標 (objective) 明確就沒有問題。而 Lecture 我是很不習慣,主要就在於要配合視頻 5~10 分鐘內的長度,所以以前的小節觀念,需要分割或合併,但要給予一個清晰的 Lecture 講座名稱,有時沒想像得簡單。

閱讀全文 »

關於 DDD (Domain Driven Development) 微服務的結構設計議題

** 本文同步發表於 FB社群-軟體設計鮮思維 **

最近在線上輔導了一位 技術職PM 結構設計的實現 (Realization)議題,他傳給我 DDD 的架構圖,覺得在「Domain Service」與「Domain Model」的責任界定上,觀念不是很清楚。

嗯,其實這所謂的 DDD (Domain Driven Development) 架構圖根本就是典型 3-tier (Presentation-Application Logic-Data Source) 分層結構呈現爲圓形的剝洋蔥層次而已,越是內層 (Domain Model) 越代表爲系統的核心。
DDD Onion Architecture Diagram

工程師從這張圖往往會認爲「Domain Model」是最重要的核心觀念。是這樣沒錯,但對以「需求爲導向」的專案開發性質,它卻反而沒那麼重要!況且結構設計的基礎功夫要很紮實,封裝-介面-多型 諸多「虛」的設計觀念確實能充分了解並能整合活用,沒有花上 5-10 年以上功夫,是不容易應用在現實的系統開發上的。相對於此,「Domain Service」對現實的專案開發可是更切實際,且結構設計上的觀念也會比較容易入手。

閱讀全文 »

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal