|
| 1 | +# Part 4:進度管理篇 |
| 2 | + |
| 3 | +## 同步進度 -- 使用專案管理 |
| 4 | + |
| 5 | +我們前面提到,要有效的提高遠距團隊效率,第一件事就是要引入一個專案管理系統。 |
| 6 | + |
| 7 | +這件事的目的其實是為了要解決遠距團隊協作的最大痛點 --- 資訊與進度上的同步。 |
| 8 | + |
| 9 | +以前在辦公室,多半公司都是以小組為單位。進度存在小組的默契裡面。但是失去了辦公室之後,項目的進度就四散了。 |
| 10 | + |
| 11 | +這時候我們就需要一套專案管理系統,來記錄與同步中專案的大小事。 |
| 12 | + |
| 13 | +有一些非技術領域的朋友,可能不知道專案管理系統是什麼,簡單來說,專案管理系統比較像 TODO LIST,只不過比較像是「團隊版」的 TODO LIST。 |
| 14 | + |
| 15 | +每個團隊根據規模與型態,適合不同的專案管理系統。 |
| 16 | + |
| 17 | +這邊根據我的工作經驗,推薦大家幾種不同的選擇。 |
| 18 | + |
| 19 | +### 小型專案:Trello (看板式) |
| 20 | + |
| 21 | +一般小型協作專案的開發,我通常會推薦Trello。 (30個以內待辦事項需要管理) |
| 22 | + |
| 23 | +Trello是看板式管理,適合待辦事項狀態簡單型的專案(如進度可以區分:尚未實做、實做中、已結束等)。 |
| 24 | + |
| 25 | +### 中小型專案:Tower (列表式) |
| 26 | + |
| 27 | +執行中小型專案的推薦,我推薦可以試試看Tower。 (100個以內以內待辦事項需要管理) |
| 28 | + |
| 29 | +Tower 適合待辦專案多類別型的專案,比如我寫書就會用Tower(第一章需要完成什麼,第二章需要完成什麼)。 |
| 30 | + |
| 31 | +### 複雜型專案:Redmine |
| 32 | + |
| 33 | +Redmine是一套開源軟體,非常適合用來管理複雜的專案。 |
| 34 | +比如說像我們軟體團隊,需要管理複雜的子專案以及里程碑。就會非常倚重這一類的重武器。 |
| 35 | + |
| 36 | +### 特殊行業的專案管理軟體:BrightPod(廣告類) |
| 37 | + |
| 38 | +比如說我印象中很深刻的,就是一套BrightPod專案管理軟體。 |
| 39 | + |
| 40 | +這套軟體最大的不同,是用來解決「重複型事件」的。因為廣告專案(如 SEO, Landing Page 投放),基本上都是重複型事件) |
| 41 | + |
| 42 | +### 你該使用哪一種的專案管理系統? |
| 43 | + |
| 44 | +很多公司的管理者,在導入專案管理系統時,常會有手足無措的情況發生,不知道該用哪一套比較好。 |
| 45 | + |
| 46 | +希望我推薦一套給他們。其實真沒有一套專案管理系統是適合所有團隊的。 |
| 47 | + |
| 48 | +因為每一套專案管理系統,後面隱藏的可能就是一套對應的專案管理哲學。 |
| 49 | + |
| 50 | +若真要推薦的話。我會推薦非技術團隊,先用 Trello 或 Tower。 |
| 51 | + |
| 52 | +這些團隊,目前最大的問題,就是沒有把該做的事,都團體記錄起來數位同步,以致於漏東漏西。 |
| 53 | + |
| 54 | +所以他們比較需要一目了然,直觀型的紀錄版。 |
| 55 | + |
| 56 | +至於一般軟體工司,與程式高度相關的,就比較適合 Redmine 這種重型的專案管理系統。 |
| 57 | + |
| 58 | +因為這種重型的專案管理系統,背後就可以透過一些特殊的機制,去做到更細微的里程碑式管理。 |
| 59 | + |
| 60 | +總之,如果你沒有用過任何專案管理軟體,不妨在Google搜尋時,輸入這樣的關鍵字,也就是 「”領域" + "Project Management"」,如:「Marketing Project Management」, |
| 61 | +相信可以找到很多專案管理的工作法、軟體選擇。 |
| 62 | + |
| 63 | + |
| 64 | +## 同步狀態 -- 使用專用工作即時軟體 Slack |
| 65 | + |
| 66 | +你在工作上都用什麼即時通訊軟體跟同事進行遠距工通呢? |
| 67 | + |
| 68 | +關於這個問題,我最常得到的答案是 FB Messenger, LINE, Wechat。 |
| 69 | + |
| 70 | +但是當我再問一句,你喜歡用 FB Messenger, LINE, Wechat 溝通公事嗎? |
| 71 | + |
| 72 | +每個人都面帶難色搖搖頭。 |
| 73 | + |
| 74 | +雖然,大家都有 FB Messenger, LINE, Wechat。但是這類軟體都有很大的幾個缺點。 |
| 75 | + |
| 76 | +1. 使用這類軟體等於變相加班。工作群組上有什麼訊息出現,你就得隨時回應。 |
| 77 | +2. 難以將私人生活與工作分開。有些人甚至有兩隻手機兩組帳號,就是不希望自己的社交帳號跟工作混在一起。 |
| 78 | +3. 難以追蹤討論串。有時候,為了方便,我們總會拉一個群組討論許多工作上的細節,文件傳的滿天飛。雖然聊得很開心,但是卻很難回去找討論串與對話。 |
| 79 | + |
| 80 | +所以,雖然大家都會用社交聊天軟體溝通工作,但是大家卻痛恨用社交軟體溝通工作。 |
| 81 | + |
| 82 | +再來,私人聊天軟體,還有一個隱藏的隱憂是資安問題。很多市面上的資安事件,其實都是因為許多工作者沒有基礎的資安意識,直接在私人聊天軟體上大談工作內容,甚至用來轉發工作密件。 |
| 83 | + |
| 84 | +首先,很多人的私人社交密碼非常薄弱。甚至是與許多常見服務帳號的密碼相同,所以一個社交網站被破,幾乎所有社交網站就會連環被破。 |
| 85 | + |
| 86 | +所以工作者的社交帳號被盜了,甚至公司內部的項目機密、文件也被盜了。 |
| 87 | + |
| 88 | +### 使用專用軟體切分工作與生活 |
| 89 | + |
| 90 | +在歐美遠距團隊裡面,最常使用的通訊軟體叫 Slack。 |
| 91 | + |
| 92 | +Slack 的專門用途,就是來解決以上的困擾的。 |
| 93 | + |
| 94 | +首先 Slack 的專門用途就是被設定在公事用途上的討論。 |
| 95 | + |
| 96 | +這樣第一步就確保了,我們是在公司的專用場域工具討論保密性強的公事。 |
| 97 | + |
| 98 | +### 切分工作主題、整合資訊來源 |
| 99 | + |
| 100 | +技術團隊十分喜愛使用Slack的原因有幾點:首先是可分主題群組。 |
| 101 | + |
| 102 | +可以針對不同的工作主題訊息、切分開不同的討論頻道。 |
| 103 | + |
| 104 | +再來是,Slack 不止是聊天室而已,而是「可編程」的聊天室。 |
| 105 | + |
| 106 | +許多網站都能夠整合 Slack 的 API。 |
| 107 | + |
| 108 | +比如說,我之前經營網站,網站系統上有安裝「Bug 收集系統」,我們就可以透過 Slack 整合機制,當網站出現 Bug 時,自動將錯誤訊息傳到 Slack 上。 |
| 109 | + |
| 110 | +而剛剛我們提到專案管理系統,我們也會整合 Slack ,將專案管理系統上,TODO LIST 的更新狀態,傳送到 Slack 上。 |
| 111 | + |
| 112 | +甚至是將我們網站的「客服系統訊息」,也整合進 Slack。 |
| 113 | + |
| 114 | +這樣,我們只要安裝一個軟體 Slack,就可以掌握「工作對話」「網站最新動態」「工作最新動態」「客戶最新抱怨」。 |
| 115 | + |
| 116 | +上班時間,不用一直開著 Email、各個工作系統的介面,使用這套流程,基本上公司任何一個員工,都可以透過手機(Slack有手機版),迅速了解到公司一整天發生了什麼,同事正在做什麼。重現實體辦公室中的「空氣流動」。 |
| 117 | + |
| 118 | + |
| 119 | +## 管理輕重緩急、以狀態去溝通項目進展 |
| 120 | + |
| 121 | +在我們團隊,我們團隊工程上使用的是 Redmine。小項目的 checklist 檢查部分,才是使用 Tower 或 Trello。 |
| 122 | + |
| 123 | +因為工程上,我們可能要開到幾百個 Ticcket,實在沒辦法一張一張票去確認實做狀態。 |
| 124 | + |
| 125 | +Redmine 可以訂製 Ticket 狀態,讓我們可以更精確的去敘述協作上的狀態溝通問題。 |
| 126 | + |
| 127 | +## 進階:使用專案管理系統拆票,加速項目快速執行 |
| 128 | + |
| 129 | +初步的專案管理,只需要做到將團隊「想到」「覺得」需要做的事情,丟上專案管理系統,這樣就能大大加速專案的進展了。 |
| 130 | + |
| 131 | +然而,這其實只做到追蹤(進度上有沒有做完),還算不上加速。這裡我還可以教大家一個利用專案管理系統加速項目進行的技巧。 |
| 132 | + |
| 133 | +讓我問問你,小專案,大家自己寫寫 TODO LIST 上去,幾個人湊合還能完成。 |
| 134 | + |
| 135 | +那麼如果是一個需要 10-20 人合作,且需要耗時三個月的項目,那要怎麼管理? |
| 136 | + |
| 137 | +此時追蹤技巧,就不夠用。真的還需要專案拆分技巧了。 |
| 138 | + |
| 139 | +在我們公司,通常有一個叫 User Story 拆分的新人訓練,這個訓練是讓新人有能力將大專案拆成小專案、小項目去依次執行。 |
| 140 | + |
| 141 | +User Story 的專書,網路上很多,這邊我就不展開說。主要是我們利用 User Story 的技巧,能將模糊的大專案,拆成逐項小項目,實做。 |
| 142 | + |
| 143 | +以下是實做一個商店的 User Story 變化: |
| 144 | + |
| 145 | +### Version 1: |
| 146 | + |
| 147 | +* 作為一個商家,我要能夠很方便地賣出我的貨品 |
| 148 | +* 作為一個消費者,我要能夠很方便地在這個網路商店上買到我要的東西 |
| 149 | + |
| 150 | +### Version 2: |
| 151 | + |
| 152 | +* 做為一個商家,我要能夠在後台上架我的東西,並設定能夠販賣 |
| 153 | +* 作為一個消費者,我要在前台能夠找到商品並結賬 |
| 154 | + |
| 155 | +### Version 3: |
| 156 | + |
| 157 | +* 身為商家的管理者,我要能夠在後台上架我的東西,並設定能夠販賣 |
| 158 | +* 身為商家的管理者,我要能夠在後台設定權限,權限分成管理者以及消費者 |
| 159 | +* 作為一個消費者,我要在前台能夠找到商品並結賬 |
| 160 | + |
| 161 | + |
| 162 | +### Version 4: |
| 163 | + |
| 164 | +* 身為商家的管理者,我要能夠在後台上架我的東西,並設定能夠販賣 |
| 165 | + * 身為管理者,我可以上傳一個商品的物品敘述及圖片 |
| 166 | + * 身為管理者,我可以上傳一個商品的規格、價格及庫存 |
| 167 | +* 身為管理者,我可以設定一個商品是否能夠上架販售 |
| 168 | +身為商家的管理者,我要能夠在後台設定權限,權限分成管理者以及消費者 |
| 169 | + * 為一個消費者,我要在前台能夠找到商品並結賬 |
| 170 | +* 身為消費者,我要在前台能夠找到商品並加到購物車 |
| 171 | +* 身為消費者,我要在前台能夠將多樣商品加到購物車,並生成一張訂單 |
| 172 | + |
| 173 | +### Version 5: |
| 174 | + |
| 175 | +* 身為商家的管理者,我要能夠在後台上架我的東西,並設定能夠販賣 |
| 176 | + * 身為管理者,我可以上傳一個商品的物品敘述及圖片 |
| 177 | + * 身為管理者,我可以上傳一個商品的規格、價格及庫存 |
| 178 | + * 身為管理者,我可以設定一個商品是否能夠上架販售 |
| 179 | +* 身為商家的管理者,我要能夠在後台設定權限,權限分成管理者以及消費者 |
| 180 | +* 身為商家,我應該可以收到消費者下訂的訂單,並設定為已結帳 |
| 181 | +* 身為商家,當消費者確定購物結帳後,該商品的庫存必須按照數量減少 |
| 182 | +* 作為一個消費者,我要在前台能夠找到商品並結賬 |
| 183 | + * 身為消費者,我要在前台能夠找到商品並加到購物車 |
| 184 | + * 身為消費者,我要在前台能夠將多樣商品加到購物車,並生成一張訂單 |
| 185 | + * 身為消費者,當系統生成一張訂單後,我可以填寫寄送資訊,並且用信用卡結帳 |
| 186 | + * 身為消費者,當我用信用卡結帳後,我的信箱要能收到一張訂單確認信 |
0 commit comments