Calendar Task

使用過大量的 todo app 後發現日曆對於我來說才是最重要的，對我自己來說工作上有公司的任務管理系統，所以剩下的只有時間管理，日曆本身就是最好的時間管理工具，但總不能把我幾點要做什麼都能通過畫上一段時間來處理，畢竟在公司除了會議以外，很少有明確時間（當然會以大多也無法準時），一項任務也無法保證能在確定的時間完成，這點也是為什麼 Todo app 與日曆僅能部分整合在一起，因此也讓我開始找尋更好的工具輔助；找工具前首先要明確需求，經過當前的狀況列出了幾點：

1. 最簡單的 Todo list (打勾就算完成)
2. 能與日曆整合
3. 有 Tag 或類似功能
4. 有搜索

從以上需求來看 Fantastical 已經能夠很好的滿足，並且我也使用了多年，但有個最痛苦的是用深了以後開始很亂，並且 Fantastical 沒有 Web、Android 版，這點讓一位 Web 愛用者很不舒服，後來開始找到了子彈筆記 Bullet Journal，有紙本、筆就可以完成，同時也有很多變種，Google 一下就可以搜到很多，在此就不介紹。

從子彈筆記開始讓我思考，如果這概念能夠與日曆結合確實能夠達成我要的需求，上述的幾點中除了 1 以外基本都可以完美支持，Tag 可以做為關鍵字搜索滿足，因此我定下了幾個簡單規則來讓日曆上也可以使用子彈筆記：

1. 一個 todo 一個全天事件
2.  >  開頭為未完成任務
3. >< 開頭為已完成任務
4. 使用 ! 表示優先級，P1  !!!   P2   !!  P3  ! 

範例：
* > !! 201902月報  - 未完成 P2 任務
* >< !!! 201901月報 - 已完成 P1 任務

這樣做之後有幾個好處
1. 日曆就像是看板(Kanban) 一眼看過去就知道當週有哪些任務以及會議
2. 定期重複事件天然解決，如果有細節可以直接記錄在日曆事件上
3. 100% 跨平台，Web 版也有很棒的 Google calendar 可用
4. 周邊工具非常多，IFTTT, Google App Script, iOS 有 shortcuts 可以協助你做好各種自動化以及生成報表
5. 能夠解決公司數據安全問題，一般公司都有自己的日曆的服務

但這樣只能解決小、單一的任務，如果有長期的任務還是不好管理，這時候就會有兩種方式，如果是公司的事就直接使用公司的項目管理工具，個人我是使用 Bear 配合 Markdown 可以快速的整理出完整的計畫，當然這就可以看個人習慣。

如果有人對於 IFTTT, Google App Script, shortcuts 的應用細節有興趣歡迎直接聯繫我 :)

以人為中心的管理模式

這陣子打算在團隊中引入敏捷開發，在推進過程中受到了些阻力，確實也是些不同的觀點值得參考，整件事背景源自於某個產品忽然人都被抽調走，由原本的 8 人剩下 2 人，試想原本 8 人的工作變成兩人來承接該怎麼辦？

先來看看原本 8 人的配置方式，每個功能指派給 1 個人負責，把整個系統拆成 8 大功能，好處是任何功能出錯了都可以立即找到對應的人，對於每個人都有長期可延續的事，並且也可以開始學習規劃自己的產品；看似非常棒，並且這模式也跑了 2 年之久，但這種模式在 KPI 的壓力下就會開始變成非常詭異的東西。

產品主從關係沒了，每個功能負責的人都認為自己是主，就像一場電影中每個人都不顧劇情一直搶鏡，其中幾個角色的搶鏡能力不同還是可能出現幾個主線劇情出來，可以想像觀眾的感受是如何，當然這也可能是種特色，但這種特色作為個長期的產品來看簡直無法想像，首先影片好不好看完全取決於角色，如果角色間還存在職級、匯報關係可以演的比起鄉土據還狗血。由人的能力自然競爭出優秀的功能看似很正向，確可能造成因為人的能力不同，某些淺在重要功能就這樣被搞砸而造成走偏。

KPI 角度來看確實在 8 個人各自負責獨立功能的時候很好寫，站在管理角度也很好打分，然而管理者放任這種發展就是對產品的不負責，變為以產品開發者為中心，好聽點叫由下而上的工作模式，實質造成產品發展與人強關連，並且產品功能間不互通，某個人休長假、轉換崗位、離職等因素都會造成產品各種淺在風險。

收回原本的問題，產品維護的人由 8 -> 2 依照原本的邏輯繼續走下去會變為把 8 個人的事拆成兩半，然後還是一樣各幹各的，頂多是出現重要緊急的事才會有合作的時候出來，產品自身仍然出現多條行進路線。我想法是把兩人手上負責的所有內容改由一人統一負責，由一個人來規劃產品，可以讓每個人盡量做相同方向的事，但優先級是以整個產品來思考而非單一功能，以用戶需求唯出發點而不是以功能該如何支持用戶。

每個產品需求新增的同時必須來思考如何刪除，尤其是容易跟業務掛勾上的產品，業務邏輯隨時在變，然而一個不小心可能產生大量歷史業務邏輯在系統中，長期下來就形成了技術債，嚴重的話就會變成系統重寫。

屁話一堆...簡單總結就是
 1. 產品的走向應該統一規劃，而不是依賴每個人負責一小部分，管理者必須把產品功能、開發流程疏理清楚
 2. 傾聽用戶的聲音，明確產品定位，業務邏輯必須抽離主架構中
 3. 上新功能前先想好如何刪除，確保產品核心功能不受影響