WFU

2015/12/12

xdite：Deliver Project on Time（Agile Project Management）


作者：陳偉挺醫師


學醫的人，為何需要 Agile？


醫學的訓練與執行，愈來愈需要多方協作。

以我身為感染科醫師為例，在之前的移植病房設計，以及推動多項令人厭煩的感控政策時，除了與同為醫學背景的同儕（醫師、護理、醫技）討論之外，也需要和資訊、工務、事務、清潔等多個單位「交手」，來促成這些「專案」的完成。

但是這個過程往往很痛苦，痛苦的點在於：

  1. 往往不知道真正進度到了哪裡，而溝通的方式往往是一對一的電話、沒效率的 email（又常常忘了 CC），或者是無法 tracking 又很陽春的 Line。
  2. 執行這種吃力不討好的專案，無法量化真正工作量（給老闆看），或者評估需要投入的人力資源，大約有多少。
  3. 好吧對方「配合」你的要求做了，可是做的東西跟當初「通靈想像」的差了十萬八千里，只能陷入砍掉重練的循環中。（感染科嘛，很多事情都是需要假手別人的，真的很彆扭 XD）

基於羅胖說的讀書好方法（要跟對人、要問問題），我想上課也是如此，所以也就義無反顧的來參加 xdite 的 agile 專案管理課程。


Deadline-driven time allocation


xdite 一開場就以她在 facebook hackathon 奪得首獎的例子，精彩的分鏡了「如何進行時間配置」這件事。

和一般以「開始時間」為工作起點的思考不同，反倒以「截止時間」為規劃起點，逆行性的安排好需要完成的事務。

除了把牽扯到不確定因素的事項（例如惡名昭彰的第三方），都儘量往前挪之外，也直接預留一段截止時間前的 buffer 時間帶，來進行專案的實際試運轉，並處理任何在試運轉時發現的意外。

這樣規劃的好處是可以提前偵測地雷，強迫自己面對地雷（不可小看人的拖延功力），並解除或直接引爆地雷，引免在專案進行到中後段時，才發生無法挽回的災難，浪費大家的時間；而這樣的專案能穩定上線，而且完成度也高。


趨吉避凶的 user story


在醫院做專案，常常需要去找 RD 「要新的資訊功能」。

上完課之後，才發現我做的事完全違反課堂 user story 的精髓，把 RD 當成「只是做功能，而不是解決問題」的人。

通常的情景是，我已經「自己很厲害的」先想好了一個框架，說明我要「這個欄位、那個欄位」，然後只是單純要求 RD 執行罷了。

想不到這樣「自以為精準」的作法，居然完全沒有用上 user story 的技巧，一方面讓之後的 end user（其他醫師、護理師等）在實際操作時，直接面對專案爆炸或漏洞百出的風險，另一方面也直接限制了 RD 提供其他 best solution 的可能性。如果一開始就以要解決的問題作開端，那麼一種開放式的、更好的解決方式，就有可能誕生。

User story，即是以「使用者需要完成的目標價值」為出發點，演繹出「什麼是應該做的？」細節清單。

而 user story 的模式，一方面多以 plain text 的方法進行，所以參與門檻極低，不會對於參與者造成威脅感，也可以取代一般「天馬行空發散式」的幻想要求，同時也藉由這樣演繹的過程，找出隱藏的需求和未爆點，將未來上線時的不確定性降到最低。

課堂中 xdite 也舉出例子來說明 user story 的演繹，從一開始短短兩行的 need statement （林佳緯醫師上身）version 1，然後不停的拆解到「真正可以實作」的 version 6（真正實際生活中，可能拆解到 version 15），也是一個非常精彩的示範！


細切目標時，慎防遺失初衷


而實際操作面上，xdite 用 redmine 將目標細切的程度，則是細到令我驚訝的地步（難怪動輒幾百條的細項清單，或者行話說是「幾百張票」XD）。

細切目標的好處是透明公開，目標非常明確，也方便執行。也因為方便執行，所以也容易產生進度，有完成的欣快感，形成一個正向的循環，繼續努力快步向前。

而 xdite 也提到了一些切碎目標之後的可能副作用，包含被切碎的目標，可能因為發派給不同的人執行，到後來，人們就被動的只是接收發派的任務，而且對於手上的任務，也只是覺得「this is just another ToDo list」，而不是有意義的 user story，覺得「那是別人的東西」。

在聽課期間，我也不由得將 user story 以及細切的過程，聯想到 JCI（Joint Commission International，一種國際醫院評鑑）的 tracer methodology 和流程評鑑。

Tracer methodology 是一種追蹤病人實際經歷的流程、治療、或服務的方式，舉例來說，如果有一位發燒病人至急診就醫，爾後痰液檢測懷疑開放性肺結核，則後續 tracer 的重點，就會放在追蹤該病人在急診的檢驗內容、隔離流程與記錄、負壓空間與設備，以及後續轉送住院與傳送防護等事宜。

相較於 user story 是用在開創新服務的專案規劃，細切則是為了方便進行服務內容的分量及順序預估，一旦把這個概念用在醫療評鑑時，反而因為評鑑太著重於「被細切的步驟上」，或者這個步驟是「擅自發想」的，導致於流程中的成員，一方面沒有辦法體認到「屬於自己的 user story」，所以不知為何而做，為何而忙，所以只好因評鑑而做，因評鑑而敷衍，反而加速摧毀這個服務，以及遺失這項服務的核心價值。

也因為缺乏 user story，在沒有共通的情境和價值之下，stakeholder 也就不會有愛，也就容易做出「滿足評鑑需求，於事完全無補」的功能（或 paper work），看起來根本就是一堆沒有效、浪費時間的事。

課堂間 xdite 也提到如何運用麥肯錫問題解決架構方式，來重建情境，喚回當初的 user story，以及提到 scrum 的一些可能缺陷，包含 poker pointing 的偏差可能、master 或 owner 等詞彙，容易造成潛意識上的誤解（把計畫成敗賴給 owner or master）等論述，也非常醒腦。


人生大專案，何處不敏捷


除了專案技巧之外，xdite 也 bonus 大放送，談及如何接案（也就是可以跟怎麼樣的人合作）的心得，所以例如 price shopper、educated buzz word dropper、proposal requester 等類型，應該如何應對，自己也有了想法。（唉呀，醫院中不就是滿滿這樣的人嗎 XD）

今天特別請了一天假來上課，一整個被思考大洗臉，非常開心 XD，雖然非 RD 從業人員，但這些共通的心法，其實遠超過七八成可為己所用，還是超值得！