筆者過去接過的案子涵蓋網頁設計、APP 製作、網路爬蟲、專欄文章、線上課程、企業內訓…

不管是好的、壞的，還是奇怪的甲方全都遇過，所以在上設計管理的課程時很有「共鳴感」。

如果你有接案的打算，那這篇文章一定要讀到最後，別人踩過的坑，我們沒必要親自體會。

PS. 這篇文章沒有要批評任何一方的意思，其實無論甲方還是乙方都需要後天學習，沒有人天生就會。

文章大綱

ㄧ、與客戶初步接洽
二、初步認識＆討論
三、深入釐清需求
四、提供報價單
五、提供時程
六、提供合約＆簽約
七、結語

文章大綱所列出的，是接案常見的流程，可能會根據實際狀況增減。

ㄧ、與客戶初步接洽

建議先跟客戶確認以下 3 點，避免浪費彼此的時間：

• 時程: 了解客戶對專案時程的期待，確認彼此的時程能對上；當遇到急件時，你一定要考慮自己是否能夠如期完成。
• 類型: 判斷自己是否做過類似的專案，以及是否擅長這類型的專案。
• 預算: 你要初步提供自己可以接受的報價區間，避免談到後面才發現客戶無法負擔。

很多人會因為害怕或缺乏經驗，不敢在一開始跟客戶確認以上事宜，導致專案在一個很模糊的狀態下進行；但殊不知，這些模糊地帶往往會導致合作到後期彼此撕破臉。

另外你不要想著每次接洽都會成功，因為客戶可能一次聯繫很多人，避免出狀況時沒有備案。

這次沒有選你，未必是你不好，只是他們心目中的第一名接下了這個專案。

二、初步認識＆討論

客戶選擇你，不代表他了解你。

所以在跟客戶第一次見面時，建議你要先介紹自己過去的作品、做事的流程，讓客戶判斷自己是否能配合。

同時你也要了解客戶對這個專案的期待，像是專案的目標與背景資訊。

這邊也建議你了解一下客戶過往的做事流程，在資訊透明的狀態下才有可能合作愉快。

三、深入釐清需求

在初步確定合作意向後，建議約一個較大型的會議。

在這階段要讓專案相關利害人一同加入討論，以確認對方的需求。

四、提供報價單

如果沒有白紙黑字，那報價就只是憑感覺；以下是撰寫報價單要注意的事項：

• 不要有模糊空間: 規格要講清楚，能修改幾次要列出來，要明訂具體的流程。
• 附上但書: 具體寫上你不做的部分；並寫上如果真的要做，你會如何報價。

而這份報價單可以：

• 讓客戶思考預算: 有時客戶天馬行空，我們需要透過報價單把他拉回現實；如果有預算考量，可以在這個階段幫客戶收斂專案範圍，讓他對內容進行取捨。
• 幫我們初步篩選客戶: 在報價後，有些客戶會開始殺價或是提出不合理的需求；如果覺得對方的行為讓你覺得不舒服，那建議不要繼續合作下去，因為通常會越來越痛苦。

Tips: 與其消耗能量克服痛苦，不如一開始就選擇合適的客戶？

五、提供時程

有些專案的時程會長達幾個月，甚至以年為單位。

為了確保雙方的認知相同，我們要與客戶討論：

• 重要檢核點（里程碑）: 除了規畫專案時程外，還要列出每個階段可以驗收的項目；並在進行驗收前，確保相關利害關係人皆可參與這些重大會議（不然可能在後續被有決策權的人推翻重來）。
• 專案交付時間: 定下時間後，後續合約就會按照這個時間走。

六、提供合約

前面細節都確認完後，就可以準備簽約了，但簽約有很多細節需要注意，筆者有空時會再寫另一篇文章分享。

不過這邊也要提醒大家，簽約不代表有保障，就算對象是大公司也一樣。

因為法律流程跑起來曠日費時，我就聽說過有的公司的樓梯間堆滿法院傳票。

七、結語

你沒看錯，這篇文章談的只是「接案前要注意的事項」。

還有很多細節沒有寫進文章，比如: 如何報價、如何提高報價、如何接到好專案、如何判斷是否為好客戶…

接案其實很累，因為前期的溝通也是專案的成本。

如果在這個階段發現客戶不合適，建議及時停損，勉強的結果通常不好。

同時提醒大家，如果你在有正職的狀態下接案，請謹慎評估自己的身心狀況；因為接案而搞砸本業，那就真的本末倒置了。

以上是「職涯必修設計管理學」的 Part 2心得筆記 ，如果覺得我的分享對你有幫助，歡迎 Follow 我吸收更多知識。

今天就讓我們來聊聊「專案執行」時，如何讓合作的過程更加順利。

以筆者過去的經驗來說，團隊合作免不了要「溝通」，但每個人的溝通能力落差極大，有些人總覺得對方是自己肚子裡的蛔蟲，因此詢問問題、交付任務都沒說明細節，時常需要你來我往的多次確認。

為了減少彼此的衝突，我們可以針對常見的合作情境設計「格式」與「規範」。

工作記錄（Work Log）

如果團隊有使用專案管理系統，為了日後方便追溯與釐清狀況，建議填寫的內容如下：

• 如果實作的方向是討論出來的，請紀錄「與會人員」與「決議結果」。
• 如果使用到特別的演算法、技術、套件，請特別附註。
• 如果該 Ticket 完成後要由其他人接手處理（ex：後端完成 API 後交付給前端），請說明要執行哪些指令（ex：DB Migration、Seeder…），並提供相關文件。
• 如果發現 Ticket 完成的時間與估計的不同，請與 PM 討論並調整。

工程師之間的合作

律定格式，讓溝通有一定的品質。

• 明定 Ticket 執行順序：一個 Sprint 中，每個工程師手上有很多的 Ticket，但有些 Ticket 會有所謂的「前置條件」，為了減少等待的空窗期，工程師要在「 Sprint Planning 時溝通好」。
• 回報 API Bug：請說明是在「哪個系統」、「哪隻 API」、「什麼參數下」會發生。
• 回報 Web Bug：請說明是在「哪個系統」、「哪個畫面（截圖）」、「如何操作」會發生。
• 遇到自己無法解決的問題：請說明是在「哪個系統」、「哪個 Ticket」、「你做過哪些嘗試」、「你認為可能的解決方案」。

工程師與 PM 的合作

工程師與 PM 合作時，千萬不要惜字如金，大家都要把話講清楚；工程師要求 PM 做到的事，自己也要做到。

• 如果 PM 請工程師完成 Sprint 以外的需求：請說明「任務優先度」、「為什麼會有這個需求」、「可以將哪個 Ticket 排後面一點」。
• 如果工程師在開發過程中收到其他團隊的需求：請將對話窗口轉移到「PM」，由他來統一處理。
• 如果工程師請 PM 開 Ticket：需描述「哪個系統」、「為什麼會有這個需求」、「需求描述」、「估計時數」。
• 若 Loading 太重無法負荷：請說明「原因」，如：掛的 Ticket 數量太多、任務分配不均、某個 Ticket 實作遇到困難。
• 若多個專案同時發起高優先度的任務：有些工程師身上會掛多個專案，若不幸有兩個以上的專案同時發起高優先度的任務，就需要請「PM」協助排出優先順序。

為什麼都要由 PM 來開 Ticket？

有些工程師覺得自己開 Ticket 比較快，資訊多轉一手給 PM 根本是浪費時間，但這個制度是有原因的，如果不這樣做就可能導致：

• PM 對專案的掌握度下降：如果大家都自己開 Ticket，PM 會無法掌握每個人實際在做的任務，即使有 Tag 到 PM，PM 也未必有辦法看到每一則訊息。
• 專案進度偏離原定計畫：很多時候，工程師心中的任務優先順序跟 PM 是不一樣的，這導致最後在核對完成的任務時，會因為彼此的認知落差而產生爭執。
• 勞逸不均：有些工程師發現問題就想解，導致身上背了一堆 Ticket 天天加班，而其他工程師閒閒沒事做。
• 做了徒勞無功的任務：有些功能從專案的角度來看，可能不重要，甚至是不需要的。

為了避免上述的狀況發生，如果有任何想做的需求，請先與 PM 討論，讓 PM 從整體的角度來判斷（ex：如果你的 Loading 太重，PM 就可能將你提出的 Ticket 分配給其他人做）。

結語

筆者透過 3 個主題（專案啟動、初始任務、專案執行），與讀者分享制定工作流程的重要性。

制定工作流程是為了讓團隊運作更為順利，所以其中的規範、格式都要與成員充分討論；在彼此有共識的狀態下，工作流程才有存在的價值，否則會變成一種負擔。

最後再次提醒大家，文章的流程未必適用於每個團隊，但可以做為參考方向。

今天讓我們來了解，在正式開發前有哪些「初始任務」要做，以及每個步驟由誰負責。

STEP 1：規劃每個階段的時程

由「PM」將專案的需求拆分成不同的 Phase，這樣工程師比較能集中注意力在特定事物上，每個 Phase 都需要把如下的任務納入考量：

1. 要完成的功能（ex：前端、後端）。
2. 撰寫測試程式的時程（ex：單元測試、壓力測試）。
3. QA 團隊測試的時程。
4. 測試、正式環境部署的時程。

規劃時要保留「緩衝時間」，因為測試一次就過基本上是不可能發生的事情，往往需要預留 10~15% 的時間來修 Bug。

STEP 2：撰寫 Ticket 需求規格

由「PM」在專案管理系統上為每項任務建立 Ticket，建議需求規格的內容要包含：

1. Prototype 截圖：讓工程師了解功能具體的位置在哪。
2. 需求描述：說明這個功能是用來做什麼的，它跟哪些功能有相依性。
3. 相關計算規則：如果需求是「計算商品總價」，那就要列出「產品搭配、折價卷、信用卡優惠…」等多種排列組合的計算規則。
4. 使用的邏輯：搜尋欄位可以查詢的欄位有哪些？搜尋的邏輯是 And 還是 Or？
5. 關聯需求：像是後端做完 API 後交付給前端，就需要將兩個 Ticket 關聯。
6. 驗收標準：判斷這個 Ticket 是否可以 Close 的依據。

STEP 3：評估每個 Ticket 的時數

不同 Ticket 的難易度不同，這邊會由「Tech Lead」與「工程師團隊」一同評估，確認該 Ticket 由誰負責，並評估需要的時數。

筆者在這裡提醒大家，千萬不要勉強自己估出一個很難完成的時數，不然卡關時，會影響到後續一系列的時程規劃（但也不要估出不合理的時數）。

如果某個 Ticket 預估的時程超過 6 小時，建議要再做拆分，否則很難衡量每天實作的進度。

STEP 4：確認能否在截止日前完成

只要是專案就一定有截止日期，「PM、Tech Lead」需要在這個階段將 Ticket 的時數轉化為甘特圖來審視，若發現已經超過截止日期，那勢必要再做一些調整，比如：

1. 簡化部分功能（ex：原本要用 Auto-Complete，現在改用一般的搜尋）。
2. 規劃 MVP 讓客戶使用（ex：原本要經過一系列複雜流程才能建立的資料，先用 Seeder 代替，以此大幅減少工程師的開發時間）。

這邊不建議堅持原計劃完成所有功能，因為快速開發所累積的技術債，於未來要花更多的時間處理。

STEP 5：分配 Ticket

由「PM」規劃這個 Sprint 要完成哪些 Tickets，然後在 Sprint Planning 時進行細節分工；假設一個 Sprint 為 2 週，建議每個人身上掛的 Tickets 總時數不要超過 65 小時，因為：

1. 時常會有臨時的會議、需求、Bug…等意外事件，需要保留緩衝時間。
2. 在專案初始階段，我們無法保證是否有遺漏的規劃、邏輯的錯誤，若把時間塞滿就很難有轉圜的餘地。
3. 有時舊專案會有緊急狀況需要優先處理，這個也會吃掉不少時間。

小結

專案的「初始任務」非常重要，若忽略其中一個步驟，都等於埋下一顆未爆彈。

相信經過「專案啟動、初始任務」這兩個主題，大家都能體會專案前期規劃、評估的重要性；但如果開發時 PM 與 RD、RD 與 RD 間的溝通不良，專案在執行時也會困難重重。

因此在下一篇文章中，筆者會針對常見的合作情境，分享實用的「溝通格式」，讓專案執行時更為順利！

PM 雖然被稱之為專案「經理」，但在大多數的公司並沒有管理實權；如果想讓 RD 跟你配合，至少要對技術要有一定程度的了解，並能聽懂對方想表達的內容。

本篇文章會分享一些實用技巧，讓 PM 獲得更精確的資訊來判斷 RD 的估時是否合理，並告訴你遇到不配合的 RD 該如何應對進退；話不多說，讓我們看下去！

了解對方的專業真的很重要嗎？

筆者很負責任的跟你說：「超級重要！」

當然這不是要你成為該領域的專家，但至少要具備「溝通、評估」的能力。

以 Web 開發舉例，如果你不具備前端、後端、資料庫的概念，你怎麼評估及分配任務？難道只靠感覺來判斷工程師的估時是否合理？

就拿筆者過去的經驗來說，儘管我有全端開發經驗，但在擔任公司 PM 時，因為缺乏與設計師合作的經驗，導致合作初期無法判斷設計師的估時是否合理。

了解專業是為了評估出「合理時間」，並在遇到不合理的狀況時，能適時提出自己有疑問的觀點。

在此特別強調「不要亂估時」！一但被發現會破壞彼此的信任，也是不尊重自己專業的表現。

如果 RD 的估時超出 PM 心中的時程

原則上，PM 都是秉持相信 RD 的態度請他估時的；但有時 RD 估出來的時數，會讓人懷疑自己是不是被糊弄了。

如果專案有時程壓力，PM 會需要更精確的資訊來協助判斷，比如：

1. 向 RD 詢問該 Task 的細節：就像標題所述，PM 需要了解這些時間花在哪裡，是否需要拆成多個 Subtask？因為有時一行字的需求，背後可能涉及到資料庫的遷移、後端 API 改寫、前端畫面調整。
2. 是否有擅長這個領域的人：有時會有這麼長的估時，是因為指派對象不擅長這部分的技術，或是缺乏相關經驗；如果時程寬鬆，那是一個很好的學習機會，但如果有時程壓力，還是看誰擅長就由誰負責（如果 PM 不清楚每位成員擅長的領域，在 Planning 階段可以請資深工程師 or Tech Lead 從旁建議）。
3. 如果是全新領域：RD 在面對陌生的技術時，也只能憑感覺亂估；因此建議開一個「研究新技術」的 Task，讓 RD 先對技術有基礎的認知，在這之後估出來的時間才有參考價值。
4. 是否有最小可行性方案：如果不是技術達不到，而是時程根本不夠，那就要考慮縮減非必要功能，或是採用替代方案。比如說有個需求是「使用者列表」，在 API 設計上，工程師會覺得除了「查詢」外，應該還要有「新增、修改、刪除」的功能，但如果客戶沒有這些需求，那或許先階段用 Seeder 把使用者寫入資料庫就可以了。

RD 估時較長，還有一個常見原因，那就是面對「需求變更」時的緩衝時間；理想上需求變更應該要延長專案時程，但實務上專案的截止日期很難調整，因此在估時上多少會預留一點空間來保護自己。

這個部分涉及到組織文化、公司面對客戶的話語權、主管態度等多個方面，如果讀者對這個話題感興趣，筆者會在獨立一篇與大家分享。

適當的借勢

如果 PM 初來乍到，而 RD 年資很深，那有可能遇到 PM 叫不動 RD、RD 明顯亂估時的狀況。

在職場上我們盡量與人為善，但假使對方就是很皮，你以禮相待他還是使勁搞破壞；那適時的請主管協調也是有必要的，不過這個方法偶爾為之還行，如果常常使用不但會被 RD 討厭，還會讓主管懷疑你的工作能力。

每間公司的文化不同，但拿人手短、吃人嘴短幾乎是共通的；有時請 RD 喝個下午茶，你會發現大家突然變得很好溝通（每個人的社交方式不同，也歡迎讀者分享自身經驗）。

結語

有些 RD 被詢問估時的細節時，會覺得 PM 不尊重專業；但 PM 真的是只是想了解細節，並尋求更好的方案。

筆者認為 PM 與 RD 是平等互助的關係，只是彼此的立場與看事情的角度有些許差異；如果總是刁難對方，其實是在損害自己的 Credit，並讓主管難做人。

「RD 與 PM 的攻防戰」這個議題就先講到這邊，希望有讓大家看到不同角度的思維模式，如果喜歡類似的內容也歡迎留言告訴我～

RD 與 PM 如果有默契，那會是一個很好的組合；但如果彼此水火不容，專案絕對會各種出包。

為什麼會出現標題的對話？

有些公司請 PM 更像是在找秘書，基本上不太管專業背景、從業經驗，只是找一個會紀錄需求，安排時程的人。

在這樣前提下找到的 PM，說實話 RD 真的心很累，大家都是出來打工的，憑什麼要我成為你增加經驗的工具人。

因為沒有專業背景，所以 PM 問的問題通常沒有什麼 Sense，甚至類似的問題還會重複問；而這個狀況除非 PM 有自知之明去學習相關知識，否則未必會隨時間改善。

大部分 RD 會服從有專業能力的人，然後看不起那些什麼都不懂，只會一直塞工作給他們的人。

有些比較情緒化的 RD 在不爽的時候，就算看到專案規劃有問題，也不會出言提醒（不過這樣做也會害到自己，筆者建議要保持工程師的專業素養）。

面對專業的 PM

當然業界也有很多專業的 PM，實務經驗豐富的他們對時程尤其敏感。

通常 PM 在收到需求後，會先請 RD 評估需要的工時；如果 RD 評估的工時超過 PM 心中的時程，那 PM 接下來就會詢問為什麼要花這麼多時間？

這裡我們先分析 RD 估時較長的幾種原因：

1. 之前沒有使用過這項技術，在未知的狀態下，會先拋出一個較長的時程。
2. 即使遇到需求變更，專案的截止日期也不會改變，所以先給自己預留一份緩衝時間。
3. 前段時間工作 Loading 太重，想在淡季為自己爭取一點喘息空間。

關於第 1、2 點，我們放到下一個 PM 篇再來討論；今天這篇文章先來聊聊 RD 如何用好的理由實現第 3 點。

RD 如何用好的理由為自己爭取喘息空間

有經驗的 PM 會適時地讓 RD 有喘息空間，但 RD 也要給 PM 一些好的理由，讓他可以跟老闆交代，這就是筆者說的「默契」，比如說：

• 重構程式：快速開發容易累積技術債，可以趁淡季的時候進行重構，以維護專案程式碼的品質；而多少程式需要重構，每個功能重構所需的時間都是很有彈性的。
• 研究新技術：評估未來專案可能會用到的技術、套件，並提前研究，避免日後專案執行時卡關。
• 整理技術文件：在有時程壓力的狀況下，常常 API 文件、部署文件、使用說明文件的內容不齊全，可以趁這個時機點更新到最新版。

筆者只是舉出 3 個常見例子，歡迎讀者留言補充自己是如何爭取「喘息空間」的。

結語

「專業」為自己贏得尊重，彼此的「默契」讓合作更加順利。

撰寫需求規格時，PM 很難把每個面向都考慮得很完整，因此開發時，需要 RD 適時地與 PM 溝通，或是用自己的經驗補齊不足之處；但具體做到哪個程度，也要參考到專案的時程。

下篇文章，就讓我們改由 PM 的角度來討論這個話題吧。

文章提及之專案、人物、事件純屬虛構，如有雷同，實屬巧合，請勿對號入座。

在前兩篇文章中（連結 1、連結 2），我們討論了團隊的聲音為何越來越少，以及主管權衡事情的角度。

而在這篇文章想跟大家分享，這些累積的問題是如何爆發的。

▋不患寡，而患不均

在一個團隊中，如果主管對每個人的標準都差不多，那至少可以維持基礎的平衡。

但如果出現了嚴重的偏差，比如：

1. 同樣是犯錯，有些人輕描淡寫帶過，而某些人則是被嚴懲。
2. 同樣是功勞，有些人藉此升官發財，而某些人卻被賦予更重的任務。

只要有人的地方，就一定會有「親疏遠近」，主管跟其中幾個人特別要好也是人之常情；但如果差別待遇的太明顯，那團隊內部肯定會出現問題。

就像這名工程師在爆炸前有提出最後一個問題：「如果有做不好的地方，我會持續改進。就算在會議上被點名檢討，只要是自己的問題，我就會虛心接受，並在下次做得更好；但為什麼我提出的問題，專案經理都沒有改進？」

結果沒想到主管回他：「不要總是在檢討別人，你要加強溝通技巧啊！」

在聽完主管的話後，工程師理智斷線，怒吼道：「好！我閉嘴！反正我說的話都沒人在聽！」並且在當天遞出辭呈。

如果主管對下屬過度雙重標準，那團隊的流動率會相當高。

▋專案經理的後續發展

也許讀者覺得專案經理這麼混，一但離開公司肯定四處碰壁，但實際上在不久後他也遞出了辭呈，並成功跳槽到另一間薪水更高的公司。

其實這位專案經理並不是沒有專業能力，而是因為受到主管的庇護而不需要認真發揮實力；如果一個人發現自己就算很混也能立足，那大多數的人就是能混就混。

▋主管最後怎麼樣了？

因為專案經理離職，所以他需要暫時代理這個職位；為了避免更多的工程師離職，他重新規範需求規格該有的元素；並且開始面試新的專案經理、工程師。

有沒有覺得這些事情很熟悉？

對！其實就是上一篇提到，主管想解決問題時所需要做的事。有時我們把時間拉長會發現，該做的事還是得做，如果當下不做，只會讓問題在引爆後更難收拾。

▋筆者的想法

發現問題 ➝ 承認問題 ➝ 解決問題

團隊中不乏能發現問題的成員，而解決問題的方法也很多，比如：「將大問題切割成小問題、定期回顧問題處理狀況、獎懲機制明確……」隨便 Google 都有一堆解答。

既然能發現問題，解答又不難找，為什麼團隊還是有這麼多問題？

從筆者的角度來看，應該是卡在「承認問題」的環節；換而言之，「人」才是造成問題無法解決的根本原因。就像在這個案例中，如果主管能適時地做出決策，也許故事的發展就不同了……

文章提及之專案、人物、事件純屬虛構，如有雷同，實屬巧合，請勿對號入座。

在上篇文章中，我們提到團隊改善的聲音越來越少，最後淪為一個形式的問題。

今天讓我們來了解，為何有些主管在收集到成員對團隊的建議後，選擇忽視成員心聲，甚至把問題放著不管。

對錯重要，還是穩定重要？

假使今天有工程師提出問題：「專案經理寫的需求規格太過模糊，裡面沒有交代前因後果，甚至連一些判斷的邏輯都沒有寫，這樣每次在實作前都要先跟他討論一次，我覺得非常浪費時間。」

上面問題的責任歸屬很清楚，根本的原因就是「專案經理缺乏撰寫需求規格的專業能力」，理論上我們只要請專案經理跟工程師溝通，協調出怎麼樣的需求規格是可以接受的，那問題就解決了。

但如果我們把上述的情境加上如下前提：

1. 專案經理已經在公司做了 5 年，過去的專案也都順利結案。
2. 工程師才進來 6 個月，有些東西還在摸索。

我想整個問題就會變複雜了，以這個案例來說，主管也在會議上要求專案經理寫出更詳細的規格；但一個月後，規格依舊模糊，完全沒有改善的徵兆。

這類問題常發生在老鳥身上，他們認為：「自己過去這樣做都很順利，今天來了一個小毛頭就要我配合他進行調整，憑什麼？」

不是沒有解決方案，只是很難推動，以及想不想推動

主管不傻，他當然也知道解決方案；但就像是上面的例子，如果你硬是要專案經理改，如果他不爽不幹了，許多他手上正在進行的專案都會受到影響。

離職預告期是給善良的人來遵守的，筆者曾遇過提離職後，直接請連續假到離職日的人。

很多人會想如果再找一個專案經理，慢慢取代他手上的工作不就好了；但實際上部門編列的預算，未必能夠再多聘請一個人。

上面講了這麼多，只是想透過實際案例讓讀者們了解；站在主管的角度，他要做的是權衡出一個對部門(自己)最有利的方案，而不僅僅只是從事情的對錯來決策。

如果主管只是想悠閒混日子，那他可以繼續放任專案經理；但假使想徹底把問題解決，他就需要做多手準備，比如：

1. 深入了解每個專案，萬一專案經理離職，他可以暫時代理這個位置。
2. 律定需求規格該有的元素，讓工程師可以順利作業。
3. 開始面試新的專案經理，確認專業能力符合需求。

假使你是主管，面對這個問題你會選擇哪一條路？

就像上篇文章提到的，很多問題都是綜合因素所造成；今天所舉出的這個例子，應該也在很多公司不斷上演。

站在旁觀者的角度，我們知道怎麼做才是「正確」的；但站在當事人的角度，因為問題還沒有大到讓團隊無法運作，在動力不足的狀態下很多人會放棄決策（因為做出決策後，自己接下來幾個月都會很累）。

人，容易因為需要太多努力，而拒絕改變。

在下一篇文章中，筆者會跟大家分析工程師真正的引爆點，以及主管後續的故事。

文章提及之專案、人物、事件純屬虛構，如有雷同，實屬巧合，請勿對號入座。

這個情緒話的標題，真的是筆者在現實職場中聽到的。

我打算以這個標題做一個系列文（目前預計有 3 篇），讓你了解是什麼樣的問題，才導致工程師情緒失控用這種方式表達自己的不滿。

主管在徵詢團隊成員意見時，是真的想改善？還是做個形式而已？

在部門會議時（ex：週會、月會），有些主管會詢問大家：「團隊還有哪些地方可以改善？」

相信大部分主管是想透過這個問題與成員討論，進而讓團隊的運作更加順暢；但通常只有一開始的 3~5 次會有人提出哪些地方需要改善，隨著時間推進，會越來越沒有人提出問題。

一但發生上述情境，這個問題就會淪為一個形式，象徵會議的結束。

沒有人提出要改善的地方，是真的沒有地方可以改善了嗎？

我相信一定有團隊在經過多次磨合後，已經摸索出最適合當下的運作模式，即使遇到新問題也可以快速應對。

但這種團隊真的是「極少數」，實際上大部分團隊的狀況是：「過去的問題尚未解決，新的問題不斷誕生。」

明明問題一直存在，甚至越來越多，為什麼反而沒有人提出來呢？

是什麼原因，導致後來沒有人提出問題？

以筆者過去的經驗來說，在發生以下的狀況後，即使對工作再有熱情，也會逐漸被澆熄：

1. 問題在被提出來後，並沒有明確地商討出彼此能接受的解決方案。
2. 往往只有階級高、資歷深的人提出的建議才會受到重視；而基層、資歷淺的人所提出的建議容易被當耳邊風。
3. 技術人員所提出的建議，有時會被以「你不懂專案管理、這不是你應該插手的事」為由否決。
4. 即使討論出解決方案，也不是每位團隊成員都會遵守執行。

冰凍三尺，非一日之寒。很多問題都是綜合因素所造成的。

大家可以想一想

我相信這個問題不只筆者碰到過，應該絕大多數的團隊都曾遇到，或正在面臨類似的狀況。

說一句實在話，團隊問題並不是光靠基層努力就能解決的，畢竟現實生活不是連續劇；如果管理層不覺醒，問題會一直存在，甚至變得更糟糕。

下一篇文章中，筆者會分析為什麼有些主管選擇忽視成員心聲，甚至把問題放著不管。

這些明眼人都知道會對團隊帶來負面影響的問題，為什麼他們還是做了？真的是因為昏庸無能嗎？

其實大部分的工程師都是可以理性溝通的，但我們無法接受一直做「白工」和「重工」，今天筆者想透過一個案例來跟大家分享「客戶、PM、工程師」之間思維的差異，並提出可以改善的方案。

本文提及之專案、人物、事件純屬虛構，如有雷同，實屬巧合，請勿對號入座。

大綱
一、工程師說 Loading 太重，可以請你幫忙分擔嗎？
二、需求不斷變更，緩衝時間再多也不夠用！
三、可是客戶態度很強硬啊！東西真的不符合他們需求
四、整理不完的例外，變更不斷的需求
五、從源頭解決問題，不是每個問題都要靠程式解決
六、客戶未必具備工程背景，要協助他們表達需求
七、我們要如何調整，讓未來的合作更加順利

一、工程師說 Loading 太重，可以請你幫忙分擔嗎？

PM 反饋這個問題後，我打開專案管理系統，看那位抱怨 Loading 太重的工程師手上有哪些 Ticket，是否需要做適當的調整。

結果仔細一看才發現，儘管那位工程師在這個 Sprint 中只剩下 2 張 Ticket 尚未完成，但有一張「匯出 Excel 報表」的 Ticket 預估時程遠遠超過之前在 Sprint Planning 的預估（4➝15）。

因為剩下的 2 個 Ticket 都是這次 Sprint 的核心功能，且距離結束只剩不到 2 個工作天，因此 PM 希望我可以接手那個估時已經到達 15 小時的 Ticket，讓工程師專注處理剩下的 Ticket。

跟 PM 談到這裡的時候我覺得有點奇怪，之所以將匯出 Excel 報表的 Ticket 分配給那位工程師，就是因為他之前有實作的經驗，沒道理在這個地方卡這麼久。

二、需求不斷變更，緩衝時間再多也不夠用！

為了釐清這個問題，我跟 PM、工程師開了一個臨時會議，去了解是什麼原因導致一個不困難的 Ticket 花了這麼多時間。

此時我才從工程師那邊了解到另一個事實，其實對他而言，匯出 Excel 報表的功能並不複雜，Loading 太重的原因是客戶不斷變更需求，導致這個 Ticket 的估時不斷增加，但預計交付的日期並沒有延長，因此時間壓力會全部壓到工程師身上。

我在詢問這個需求變更的頻率有多高時，工程師表示把新版交付出去後，可能再過 3、4 個小時就會收到新的需求變更；儘管每次修改都不會花太多時間，但架不住這麼頻繁的更動啊！

當需求變更導致一直做白工、重工，就可能讓工程師工作效率下降，甚至可能在完成功能後故意拖一段時間再交付；畢竟提早交付沒好事，只是讓自己的工作量變更多而已。

三、可是客戶態度很強硬啊！東西真的不符合他們需求

客戶花錢請我們做系統，當然是希望做出符合他們實際業務需求的產品；站在客戶的立場上，他們當然會用最嚴格的標準在看待每一個功能。

但站在我們的立場上，在人力資源固定的狀態下，每多一次需求變更，我們就需要花更多的時間與精力去完成，甚至導致部分同仁需要加班。

為了解決這個問題，我請 PM 跟客戶約一個時間，一起了解需求不停變更的原因是什麼，不然這樣一直改下去其實是在浪費彼此的時間。

四、整理不完的例外，變更不斷的需求

客戶是一個專門提供材料出貨的公司，在深入訪談後，才了解需求之所以會一直變更，是因為這個 Excel 報表始終沒有決定一個固定的版本，會這樣是因為過去客戶在填寫出貨單時沒有律定格式，同一個材料可能有 10 幾種表達方式。

過去沒有遇到這個問題，是因為之前的出貨單都是 Case by Case，所以他們材料名稱儘管不統一，但依舊能夠看得懂；可是如果把好幾張出貨單放在一起看，就會因為資料很難整合而產生許多問題，這也是客戶找我們做系統化的原因。

下面用手機來舉個例子，我們手機有前鏡頭，假使在出貨單上顯示：「前鏡頭、前置相機、front camera、Front Camera、frontCamera」我相信大家都看得懂這是指同一個東西；但如果管理階層想要知道公司這個月到底賣了多少個「前鏡頭」，下屬就需要畫很多時間做比對跟整合。

除了相機的案例外，這邊再舉一個螢幕的例子，每個手機螢幕的尺寸大小不同，因此出貨單上有各自的命名；當管理階層想了解這個月總共賣了多少個「螢幕」，下屬會因為出貨單的材料沒有階層的概念而整理到崩潰。

在了解客戶的痛點後，我們就知道這是因為過去「命名不統一、材料缺乏階層概念」導致的問題。

PM 一開始也是從這個方向去處理問題的，他先請客戶將期望的命名、材料的階層整理出來，然後請工程師依照規格去統整；儘管這個方案看似沒有問題，但因為客戶當時在填寫出貨單時，命名太過狂野，因此有非常多的例外需要處理，而每發現一個例外就要請工程師調整程式。

五、從源頭解決問題，不是每個問題都要靠程式解決

了解來龍去脈後，我想也許我們都把問題搞複雜了，既然我們都知道問題是在出貨單上，為什麼不要從源頭來解決這個問題呢？

如果出貨單的格式沒有律定，在未來同樣的問題還是會發生；因為出貨單上每天都可能會誕生新的名詞，而新的名詞會無法自動歸類，可以料想到就算現在符合客戶的需求，在未來還是會有許多衍生問題。

當然過去的歷史業障很難要求客戶調整，「統一名詞、確定階層」還是一個必要的工作；但也許我們可以先用過去的出貨單模擬客戶期望的 Excel，而不是不斷請工程師修改程式。

若發現有缺少、錯誤的材料先記錄下來，累積到一定的量後再請工程師修正，不然他會改到瘋。

同時為了讓錯誤的歷史在這個階段就停下，我們需要請客戶與填寫出貨單的部門溝通，律定「出貨單」填寫的格式。

如果涉及到客戶公司內部，盡可能讓他們「自行協調」，我們做好「引導的角色」就夠了，如果由我們向客戶的其他部門提出需求，那破局的機率非常高。

六、客戶未必具備工程背景，我們要協助他們表達需求

其實就算是公司內部的溝通也是不容易的，起初填寫出貨單的部門對律定格式這件事反彈極大，因為他們原本都做得好好的，現在變得要依規範行事。

在了解到客戶推行的困難點後，我們製作了一張高達數百個欄位的 Excel，並請客戶向填寫出貨單的部門展示，讓他們體會到混亂的格式造成什麼後果。

在這之後他們才理解為什麼格式需要律定了，也了解公司導入這個系統就是希望把流程標準化，減少報表製作的時間，不是想要刁難他們。

七、我們要如何調整，讓未來的合作更加順利

儘管這個問題最後在多方的協作下圓滿解決，但其實中間有許多摩擦是可以在初期避免的。

Tech Lead

若發現某個 Ticket 的估時逐漸增加，要主動向工程師詢問實際狀況，因為有些細節在 Scrum Meeting 並不會提及。

若發現工程師在做重工、白工，要先釐清問題來源；不是每個問題都要靠程式解決，我們可以先嘗試跟客戶溝通。

PM

如果客戶提出的需求變更太過零碎、頻繁，可以先記錄下來，等累積到一定的量，或是明確需求後再交給工程師處理。

如果發現需求能用模擬的就先用模擬的，盡可能不要讓工程師把時間耗在有高機率做白工的需求變更上。

工程師

如果發現需求變更的內容不合理、次數太多，可以即時與 Tech Lead 反應，而不是用加班默默把需求的吃下來。

希望這個案例對讀者日後執行專案時有幫助，如果還有其他建議也歡迎留言分享喔～

工程師血淚史
▋ 團隊在系統開發上遇到了哪些問題
▋ 需求不斷變更，到底哪個環節出錯了(本篇)
▋ 當 Scrum Master 跟 PM 同時存在，權力與責任該如何區分？
▋ 如果沒有明確的開發流程，團隊將會無所適從
▋ 你知道對專案來說，README.md 有多麼重要嗎？

大綱
一、從空白專案來認識這套軟體
  ➤ 新增空白專案
  ➤ 跟著教學導覽走
  ➤ 新增工作
  ➤ 新增方便專案管理的欄位
  ➤ 切換任務顯示的方式
二、小結
  ➤ 方便專案管理的工具
  ➤ 整合上的困難
  ➤ 它並不適合用來直接指派任務

一、從空白專案來認識這套軟體

新增空白專案

在登入後空白的初始畫面非常簡約，點擊「新增空白專案」來看看需要設定哪些參數。

跟著教學導覽走

在 Project 建立後會有基礎學習導覽，讓你知道哪些地方需要設定；像是第一步就是給「專案命名」。

新增工作

在建立任務時主要需要設定「任務名稱、持續時間」，有需求也可以「新增子任務」。

不過也有發現到他任務的「持續時間」似乎更新上是有點 Bug 的，主任務沒有累加。

新增方便專案管理的欄位

如果有需求，可以自行「新增欄位」；以筆者過去的經驗來說，這個工具所提供的欄位都是從「專案管理」的角度出發的，像是每個任務預計完成時間、已經投入的時間、待投入時間、任務相依性…這些都能幫助使用者有效的做管理。

切換任務顯示的方式

Project 也提供不同的顯示方式，其中「面板」的顯示方式就跟 Trello 的風格很像；你可以透過「新增貯體」來將任務分類。

如果你想要從專案整體的角度來分配任務，「時間表」的顯示挺方便的；因為你可以很清晰地看到每個任務的時程；較不會發生任務互相衝突或是前置任務尚未完成後面任務就啟動的問題。

二、小結

方便專案管理的工具

老實說，相比於 List 、 Planner；Project 算是專門為了專案管理打造的軟體，無論從視覺化還是提供的功能都能讓專案經理掌握進度並與其他團隊溝通。

整合上的困難

它跟 List、Planner 有一樣的通病；就是只把某一項功能做好，但如果想要更加細節的功能就只能用超連結出去。

比如我想要在這個任務中附上照片只能用附件的方式，但這樣的方式真的很影響閱讀性；如果標題下得不夠好，也很難透過關鍵字找出任務（沒有 tag 的概念）。

它並不適合用來直接指派任務

因為任務的描述只能靠文字，加圖片還要用附件的方式；這造成被指派的負責人在閱讀時很容易直接忽略圖片，從而導致忽略部分重要訊息。

如果是用超連結導航到 OneNote 這類的筆記軟體是能解決問題；但真的對使用者而言非常不友善，每次都要在兩個軟體間不停切換。

如果要讓筆者做個簡短的使用心得，我想應該是：「Project 只適合專案經理使用，或是專案經理間的溝通；如果要用它指派任務，我覺得不太合適。」

一、官方的『新手教程』
二、了解每個角色的職權
  1.『管理員』的基本功
    ➤ 調整部門結構
    ➤ 批量增加用戶
    ➤ 調整用戶權限
    ➤ 還原刪除的使用者
    ➤ 解鎖多次登入失敗的使用者
    ➤ 發現的系統 Bug
  2.『產品經理』的起手式
  3.『項目經理』如何分配任務
  4.『研發人員』完成收到的任務
  5.『測試人員』確認每個環節的穩定性
三、體驗心得

一、官方的『新手教程』

這個新手教學並沒有依照角色權限設計，所以每個人看到的版本都是以『管理者』的角度去呈現

官方提供的教學可以讓你快速了解整個系統的作業流程，你在『教學裡面的所有操作並不會儲存』只是給你體驗而已，所以意思意思打一下就好。

教程面板說明：

• A：會有亮起來的地方讓你選擇及輸入資訊，這塊跟著走，資訊亂填即可(不會存進系統)
• B：教學的操作步驟
• C：以管理員導向的八個任務讓你體驗，接下來我的文章會更細節說明每個角色實際能操作的範疇

二、了解每個角色的職權

其實在首頁的地方就已經把每個角色的職權都說得清清楚楚了，如果發現有角色的職權跟你預計的不符合也可以再自行客製化

1. 『管理員』的基本功

管理員需要對所有職位的權限非常熟悉，並要了解每個權限具體對應到哪些功能

調整部門結構

必須要先設定好部門的結構再去新增用戶，因為用戶跟部門是有相互依賴關係的

批量增加用戶

建議用『批量』的方式建立用戶，無論在權限、密碼方面的設定都會輕鬆許多

批量新增時技巧：

• 職位高的先放：因為通常他們會是所屬部門的根目錄
• 善用『同上』的功能：相同的部門、相同職位…依照同類型的分類設定可以加快速度

調整用戶權限

在批量新增使用者的時候一個用戶只能有一個角色權限，但有能力的人在公司裡面身兼多職是常有的情形，就像我在公司是『研發 Dev』人員，但同時也需要負責『系統組織、後台設定 Admin』，所以我會給自己設定多種角色權限

如果公司規模不大，一個團隊的 leader 要身兼 『項目經理 PM』、『產品經理 PO』、『研發主管 Dev Manager』、『產品主管 PD』都是很常見的（ex：我現在的直屬主管）

還原刪除的使用者

解鎖多次登入失敗的使用者

為了避免帳號被暴力破解法盜取，禪道有登入錯誤次數的設定

發現的系統 Bug

這裡特別說明一下，禪道這個專案管理系統在權限管理、用戶管理上面的防呆不是很嚴謹，下面舉兩個範例：

• 『管理者』移除自己『管理者』的身份後還能繼續使用管理者的權限😨，需要再次登入才會生效😱（如果由其他管理者移除對方管理者身份時一樣要重新登入才會讓身份生效）

• 『管理者』可以移除自己的帳號😨，帳號移除後還能繼續操作系統😱

2. 『產品經理』的起手式

產品經理需要專注在每個產品的週期，並確認所有需求都有在進行

STEP 1：創建產品

STEP 2：維護模組

這裡的模組會用來區分『需求』的類別

STEP 3：創建計畫

每個『需求』都會隸屬於某個『計畫』

STEP 4：創建需求

『需求』就會依照剛剛創建的『模組』、『計畫』做設定

STEP 5：需求指派

需求要指派給相關的人員才能夠推動專案的進行，這裡指派讓項目經理做後續處理。

『項目經理』預設權限並不能對產品需求進行操作，即時被指派也不行；所以如果要讓他提供相關的資訊請前往：權限 > 需求> 編輯、變更需求、指派需求(打勾)

3. 『項目經理』如何分配任務

項目經裡是具體分配任務的人，他需要了解團隊中每個人的職位才能有效地指派任務

STEP 1：登入後看被指派的需求

STEP 2：創建項目

創建完項目後系統會有彈窗詢問你要不要進行後續的操作，如果選擇『返回任務列表』也還是可以做這些設定

STEP 3：管理團隊

如果沒有設定好參與項目的團隊成員，創建任務時只能指派給自己喔XD

STEP 4：創建任務

項目經理需要將創建任務並指派給相關研發人員

項目經理可以透過『燃盡圖』來觀察每個項目的實作狀況是否符合預期，這裡要特別注意的是『燃盡圖只能計算今天的數據，歷史紀錄無法修改』，所以要記得提醒組員每天更新自己的工作狀況，否則燃盡圖是無法正確顯示的。

4. 『研發人員』完成收到的任務

研發人員主要會收到來自『項目經理』的任務、『測試人員』的bug，他的工作就是每完成到一個進度做回報，方便管理人員掌握進度

STEP 1：登入後看被指派的任務和Bug

STEP 2：更新任務的資訊

• A：任務開始
• B：任務完成，使用此功能時會將任務重新指派給當時委任的『項目經理』
• C：觀看、撰寫任務工時
• D：編輯任務內容
• E：創建子任務

STEP 3：將收到的 Bug 轉成任務

『Bug』跟『任務』不同，Bug 不會紀錄完成的時間，也不會把它算進去燃盡圖中，所以如果想將 Bug 轉為自己的績效，記得先將他轉型

• 項目 > 任務 > 導入 > 導入Bug

• 勾選欲導入的 bug 並填入預計工時> 導入

此時你就會看到『 Bug 被轉型成任務嚕』～為自己爭取更多績效吧！

如果改變剛剛轉型任務的『狀態』為『已完成』會詢問是否要將關聯的 Bug 一併改為『已完成』

5. 『測試人員』確認每個環節的穩定性

測試人員需要先了解產品具體的操作方式以及每個項目的測試點，不然他是很難撰寫用例的

STEP 1：創建用例

『用例』：測試的流程撰寫

用例建議一個一個創建，因為很多細節需要填寫，以下純為流程解說

STEP 2：了解用例的使用方式

• A：觀察用例過去所有執行的結果
• B：執行用例，確認每個步驟符合預期，如果執行中發現錯誤就可以轉Bug
• C：編輯用例，調整前置條件、執行步驟、備註等等
• D：如果用例測試的結果為『失敗』，也可以在這個地方做轉 Bug 的步驟
• E：複製用例

STEP 3：測試錯誤轉 Bug

這裡我們可以發現如果結果不是『通過』，Bug 的 icon 就會亮起來

點擊『轉Bug』後就去詳細的說明這個 Bug 的內容，撰寫的越詳細越能提升工程師解決的速度

STEP 3：生成測試單檢驗成果

『用例』、『Bug』都是單項的，測試單能把這些資訊做一個彙整

藉由『測試單』還能將過去的用例導出數據

想要生成報表也沒有問題

PS.當時我在報告的這個 Tab 用了好久都不知道怎麼操作，後來發現是測試人員 (QA) 預設的權限沒有打開，創建報告的功能要測試主管(QD) 才有權限

三、體驗心得

系統操作面

這款專案軟體的操作引導是非常棒的，加上官方的中文社群非常活躍，所以如果操作上遇到問題往往 google 一下就能得到解答。

一些小缺點

因為使用者權限劃分得非常細，所以有些操作會發現沒辦法下一步；又因為功能實在太過繁雜所以使用起來會有一點學習曲線。

與其他專案管理系統的比較

• Jira：認真說 Jira 還是稍微好用一點，特別是在系統彈性以及流程規劃上面；當然這可能因為我現在用的是開源版本所造成的。
• Redmine：Redmine 需要自己安裝一大堆 plugins 才能成為一套好用的系統，單純這點禪道真的是大勝，但學習曲線 Redmine 相對比較低。
• Teams 的 Planner & Lists：基本上這兩個是幾乎無法拿來做專案管理，會非常的綁手綁腳，不建議嘗試。

管理人員
➤ 依照公司團隊建立根目錄的專案
➤ 在用戶清單中加入團隊成員
➤ 依照團隊默契建立問題樣板(或是直接使用全域問題樣板)
➤ 依據團隊建立大群組，依據職權建立小群組
➤ 建立子專案
➤ 建立新議題
開發人員
➤ 開發人員收到議題
➤ 新增子議題、相關議題
➤ 在看板調整工作進度
➤ 編輯議題
測試人員
➤ 驗證議題功能正確性
➤ 建立發現錯誤的議題並分派給相關群組

管理人員

通常都是由 team leader 擔任這個角色，如果公司允許讓管理人員擁有『管理者』的權限會更理想；因為管理團隊用戶/群組這些事情 team leader 會比較清楚，不需要一直麻煩 MIS 人員做處理。

依照公司團隊建立根目錄的專案

每個案子都需要新增一個專案，但如果全都放在專案清單會造成視覺上的錯亂，所以這裡會建議用團隊來區分案子。

STEP 1：網站管理 > 專案清單 > 建立新專案

STEP 2 ：填寫專案基礎資訊 > 建立

• 名稱：請填寫大家都看得懂的，如果專案有英文縮寫請放在代碼
• 代碼：這個欄位儲存後無法修改，請謹慎填寫
• 公開：除非是全公司都能看到的專案，不然請勿打勾
• 模組：建議全選

在用戶清單中加入團隊成員

需要用『管理者』的身份才能建立新用戶

STEP 1：網站管理 > 用戶清單 > 建立新用戶

STEP 2：填寫用戶基礎資訊 > 建立

• 管理者：跟『管理人員』的角色意義是不同的，有管理者權限的才能使用『網站管理』
• 產生密碼 & 必須在下次登入時變更密碼：建議都打勾避嫌
• 寄送帳戶資訊電子郵件給用戶：不寄信給對方他也不知道你幫他建好帳號了
• 電子郵件提醒選項：依照範例的選擇會收到最完整的 Email

依照團隊默契建立問題樣板

為了保證議題的格式有相同的 Style ，所以建議團隊要建立問題的樣板，以確保每個議題的內容都有精準描述減少來回溝通的成本。

STEP 1：在專案清單選擇專案 > 問題樣板 > 新增樣板

• 問題樣板：專門為這個專案設計的問題樣板
• 全域問題樣板：所有專案都能夠使用的問題樣板

STEP 2：填寫問題樣板內容 > 建立

• 追蹤標籤：這個樣板是給哪個追蹤標籤使用的
• 預設值：建議打勾，最後真正的預設值還是看排序，另外子專案設計的問題樣板會蓋過全域問題樣板
• 啟用：打勾後才能讓使用者選用
• 在專案樹狀結構中分享：建議打勾，因為模板通常都會共享

依據團隊建立大群組，依據職權建立小群組

每個專案都有獨立的成員列表，並賦予成員不同的角色；建議群組由大到小會分成三個層次：

• 全公司：有些專案或是資訊是要給全公司的人都知道的
• 部門團隊：比如網頁負責的是一個 Team，android app、windows app 是另外一個 Team
• 功能團隊：網頁團隊下會有不同的小組，有些負責 UI/UX 設計、有些負責後端 api 撰寫；這的層次是依造職權的分類

STEP 1：網站管理 > 群組清單 > 建立新群組

STEP 2：填寫群組名稱 > 建立

STEP 3：選擇剛剛建立的群組 > 用戶清單 > 建立新用戶 > 選擇要加入的用戶 > 新增

STEP 4：專案清單 > 加入專案 > 選擇欲加入的專案 & 加入的角色 > 新增

建立子專案

子專案才是真正的放專案資訊的地方

• 代碼：因為是子專案，建議代碼也要有關聯性方便識別
• 父專案：記得選擇
• 繼承父專案成員：建議打勾，通常成員的角色都是固定的，不太可能今天是『開發人員』明天就轉職成『測試人員』

STEP 1：網站管理 > 專案清單 > 建立新專案 > 填寫專案基礎資訊 > 建立

🌟專案重要設定說明🌟

• 成員：除了繼承父專案成員外，你還可以在這裡做角色權限調整，一個用戶可以有多重角色

• 版本：專案一定會有版本的更迭，每項議題如果都有對應的版本在管理及追蹤上可以容易釐清責任

• 議題分類清單：新人剛加入團隊時可能對成員的職權並不是很了解，如果在這裡建立分類的防可以快速幫助不熟悉團隊的人了解每個人的職權分配

• issue columns：設定議題的子議題要呈現哪些欄位

建立新議題

專案基礎配置完成後開始分配每個成員的任務，這裡先從 UI/UX 的設計圖開始

STEP 1：議題清單 > 建立新議題

STEP 2：填寫議題內容 > 建立

• 追蹤標籤＆問題樣板：問題樣板會跟著追蹤標籤顯示；用戶依照樣板填寫的資料填入必須資訊即可
• 概述：圖片可以用複製貼上，但上面只會顯示『!xxx.png!』，需要去『預覽』才能看到實際的結果

• 提及(memtion)：在撰寫議題概述的時候很長會提到其他同事(ex:這項決議是哪位長官決定、這塊功能會由誰負責…)，可以用 @ 來操作喔

• 被分派者＆分類：調整分類就會自動填入被分派者，能幫助不熟悉用戶職權的人輕鬆的做議題分配

• Checklist：作為議題的輔助，讓你紀錄要完成的細項

• 監看者(watcher)：與任務相關的同事，通常會將直屬長官設為監看者

開發人員

開發人員的涵蓋範圍很廣，包含前端、後端、硬體工程師…UI/UX 設計師等，通常會在收到管理人員分配的議題後開始作業

開發人員收到議題

原則上只要用戶被分配議題、mention提及、設定為監看者，就會收到類似的 email 通知如下：

新增子議題、相關議題

在信箱點擊連結會直接前往該議題，但收到的信件一多還是要依照以下步驟找出自己要負責的項目

STEP 1：專案清單 > 選擇專案 > 議題追蹤

STEP 2：在篩選條件中使用追蹤標籤找到由自己負責的議題

STEP 3：新增子任務

閱讀完議題的需求後再依據自己實際的工作項目去細分子議題，操作方式非常直覺就不再多做介紹

在看板調整工作進度

請注意這裡只能調整議題的『狀態』、『進度』，並不會紀錄工作時間

一個一個議題點進去更新真的很慢，所以我們可以在『看板』用拖拉議題的方式改變他的『狀態』，且能於此『更新進度』的百分比

編輯議題

被分配到議題時要記得編輯啊！不然主管以為你沒做事😞

• 狀態：可調整為『實作中』、『已解決』
• 預估工時＆完成百分比：會有報表產出，所以請認真填寫
• 紀錄時間：為了好看的工作報表就好好填寫吧
• 筆記：因為『概述』完成後就不能修改，我們要用『筆記』做後續議題的討論和紀錄

測試人員

測試人員是系統的守護者，通常會接收到由『開發人員』、『管理人員』分配的測試任務，如果在測試過程中遇到了其他的錯誤可以自行在新增議題做分配

驗證議題功能正確性

STEP 1：先找出清單中自己被指派的任務

STEP 2：依照議題概述去完成相關測試

STEP 3：依據測試結果給予議題回應

• 測試成功：狀態改為『已結束』
• 測試失敗：狀態改為『測試不符合預期』，並增加『筆記』做說明

建立發現錯誤的議題並分派給相關群組

如果是在測試項目外發現錯誤，就是自己建立新議題，並指派議題給負責的群組，如果不清楚該功能由誰負責請使用『分類』來做自動分派。

以下是我整理 Redmine 的相關資源，想更進一步了解的朋友可以參考看看：
👍 Redmine 超詳細安裝教學：Redmine 4.1.1 on Ubuntu 16.04
👍 如何用 Redmine 做專案管理＆體驗心得
👍 Redmine Plugins & Themes 介紹：那些我成功擴充的外掛
👍 用 Redmine 做專案管理 — 管理者不可不知的設定
👍 用 Redmine 做專案管理 — 一般用戶不可不知的基礎功能

🙂 讀完這篇文章後

一、專案清單
二、專案概覽
  ➤ 議題清單
  ➤ 建立新議題
  ➤ 編輯議題
  ➤ 看板

一、專案清單

• 專案分類邏輯：以團隊做區分，子專案才是實際進行的專案

二、專案概覽

這裡介紹實際上專案高頻使用功能

議題清單

建立新議題

• 追蹤標籤＆問題樣板：問題樣板會跟著追蹤標籤顯示；用戶依照樣板填寫的資料填入必須資訊即可

• 提及(memtion)：在撰寫議題概述的時候很長會提到其他同事(ex:這項決議是哪位長官決定、這塊功能會由誰負責…)，可以用 @ 來操作喔

• 被分派者＆分類：調整分類就會自動填入被分派者，能幫助不熟悉用戶職權的人輕鬆的做議題分配

• Checklist：作為議題的輔助，讓你紀錄要完成的細項

• 監看者(watcher)：與任務相關的同事，通常會將直屬長官設為監看者

編輯議題

被分配到議題時要記得編輯啊！不然主管以為你沒做事😞

• 狀態：可調整為『實作中』
• 預估工時＆完成百分比：會有報表產出，所以請認真填寫
• 紀錄時間：為了好看的工作報表就好好填寫吧
• 筆記：因為『概述』完成後就不能修改，我們要用『筆記做後續議題的討論』和紀錄

看板

請注意這裡只能調整議題的『狀態』、『進度』，並不會紀錄工作時間

一個一個議題點進去更新真的很慢，所以我們可以在『看板』用拖拉的方式改變議題的『狀態』，且能於此『更新進度』

原本以為用戶需要知道很多操作，但發現只要會上面的基礎操作後，其他延伸的功能都可以舉一反三。

以下是我整理 Redmine 的相關資源，想更進一步了解的朋友可以參考看看：
👍 Redmine 超詳細安裝教學：Redmine 4.1.1 on Ubuntu 16.04
👍 如何用 Redmine 做專案管理＆體驗心得
👍 Redmine Plugins & Themes 介紹：那些我成功擴充的外掛
👍 用 Redmine 做專案管理 — 管理者不可不知的設定
👍 Redmine 教育訓練 — 依角色權限說明

🙂 讀完這篇文章後

注：本篇文章新增外掛如文章

🌐 網站管理
  ➤ 專案清單
  ➤ 用戶清單
  ➤ 群組清單
  ➤ 角色與權限
  ➤ 追蹤標籤清單
  ➤ 議題狀態清單
  ➤ 流程
  ➤ 設定
  ➤ 全域問題樣板
  ➤ 外掛程式

🌐 網站管理

只有用戶『管理者』權限開啟時才能操作『網站管理』

專案清單

你可以設定某些角色有『建立新專案』的權限，但只有管理者可以做：

• 封存：被封存的專案將不予顯示，通常是專案完成後不希望有人再做更動時使用，若要恢復可以用『取消封存』
• 複製：有很多專案細節的選項可以自己微調做複製
• 刪除：按下去就真的會刪除了，除非是建立錯誤，否則建議用『封存即可』

用戶清單

用來新增/管理用戶，除了設定基礎資訊外，還可管理他們所屬的『群組』、『專案』

• 管理者：有打勾的才能做『網站管理』
• 鎖定：當員工離職時建議使用鎖定，這樣只會讓他無法登入但仍可保留使用者的過往紀錄
• 刪除：除非真的建立錯誤的用戶，不然不建議使用

• 電子郵件提醒選項：建議選擇『只提醒我觀察中或參與中的事物』，這樣收到的資訊最為完整

• 專案清單 & 角色：如果你只創建用戶，但沒有把他加入到專案當中，他是完全沒有功能的。

群組清單

適當的建立群組可以加快『任務派發』、『選擇專案成員』的速度

角色與權限

• 建立新角色：根據公司規模的不同，實際上可能需要更多的角色分割權限
• 權限報表：管理每個角色的權限細節

追蹤標籤清單

你可以把他當成『議題種類』的區分，標籤名稱越明確，日後管理會越精確

議題狀態清單

這個是『議題流程』會經過的『狀態』，每個角色可以使用的議題狀態是不同的，ex：只有『測試人員』才能將議題狀態改為『測試不符合』預期

流程

這塊就是用來設定每個角色在不同追蹤標籤下可以操作流程的狀態；這塊設定起來有點繁瑣，建議流程上卡關再來這裡調整會比較方便

設定

★ 一般

• 歡迎詞：如果你覺得『網站首頁』空白很難看，可以在這裡編輯
• 主機名稱：可以填寫網站的 ip 或者是 Domain name
• 協定：建議使用『HTTPS』
• 文字格式：建議選擇『Markdown』讓工程師方便協作（直接貼上 .md 類型的資訊）

★ 顯示

• 畫面主題：你可以在這裡改變 Redmine 的顯示主題
• 預設語言：你之後創建使用者時都會默認選擇

★ 驗證

• 需要驗證：建議選擇『是』，否則公開的專案會被陌生人看光光
• 註冊選項：建議選擇『停用』，儘管要管理者審核才能正式登入系統，但如果有人瘋狂亂註冊也會造成管理上的困難。

★ 專案清單

• 新建立之專案預設為「公開」：不要打勾，因為個組織間如果有要合作將成員加入專案是比較好的做法
• 新專案預設啟用的模組、新專案預設使用的追蹤標籤：基本上都是全選，要不要用還是看自己

★ 議題追蹤

• 允許關聯至其它專案的議題：因為跨組合作是可預期的，所以會打勾
• 允許議題被分派至群組：有些議題可能會需要需要小組討論、內部分配，所以會打勾

全域問題樣板

讓用戶在『建立議題』時有統一的格式，避免用戶依照自己喜好建立議題導致必要信息缺失造成溝通成本增加。

外掛程式

這裡會顯示安裝成功的 Plugins，『檢查更新』的按鈕參考就好，因為有些外掛不是直接關連到官方的。

官方網站有提供許多的 Plugins，但安裝需要注意 Ruby、Redmine 的版本，如果沒有相容通常會安裝失敗，安裝失敗會導致整個 Redmine 的網站掛掉，所以在擴充外掛前最好向全公司發個通知，並且盡量於工作作業離峰期做擴充。

以下是我整理 Redmine 的相關資源，想更進一步了解的朋友可以參考看看：
👍 Redmine 超詳細安裝教學：Redmine 4.1.1 on Ubuntu 16.04
👍 如何用 Redmine 做專案管理＆體驗心得
👍 Redmine Plugins & Themes 介紹：那些我成功擴充的外掛
👍 用 Redmine 做專案管理 — 一般用戶不可不知的基礎功能
👍 Redmine 教育訓練 — 依角色權限說明

🙂 讀完這篇文章後

一、管理者在專案創建前的準備
  ➤ 角色與權限
  ➤ 議題狀態清單
  ➤ 追蹤標籤清單
  ➤ 設定
二、專案管理的實際應用
  STEP 1：建立新專案
  STEP 2：分配議題(issue)
  STEP 3：組員收到議題的分配通知，根據需求細分子議題
  STEP 4：UIUX 完成設計，PM 分配後續工作給前端工程師
  STEP 5：前端工程師細分子議題，並開 api 需求給後端工程師
  STEP 6：後端工程師回復議題
  STEP 7：PM 規劃測試流程
  STEP 8：SIT 測試新系統功能
  🤔 流程總結
三、個人使用心得

一、管理者在專案創建前的準備

以下操作皆在『網站管理』分頁，僅列出重要功能，其他請自行摸索

角色與權限

系統僅會提供如下角色，但專案管理的流程中通常還會有『測試人員』、『UI/UX 人員』等角色，這裡就按造公司需求新增及分配權限即可

新增角色後會要定義他的工作流程，畢竟每個角色要做的任務不同

以測試人員來說，他們通常是要驗證已解決的議題是否處理完成，所以我會賦予的權限如下圖

議題狀態清單

如果你在剛剛操作角色權限設定時覺得狀態不敷使用可以在這裡增加

像測試人員就可能有『測試不符合預期』之類的狀態，新增後記得套用到對應的角色身上

追蹤標籤清單

這些標籤可以幫助你在尋找、歸納議題時的速度

設定

在『顯示』的地方可以調整語言

在『驗證』頁面參考調整以下選項：

• 需要驗證(是)：如果你沒改又忘記調整專案為不公開會讓一般民眾都可以瀏覽喔！
• 註冊選項(關閉)：如果開放註冊可能會被有心人士狂註冊，多了一堆垃圾帳號造成日後管理困難

二、專案管理的實際應用

以下用實際專案流程模擬操作，模擬公司實際職位如下

• PM(管理人員) — 開 issue 並且分配 issue
• UI/UX(開發人員) — 網頁設計相關任務
• frontend(開發人員) — 依據 UI/UX 設計完成前端
• backend(開發人員) — 配合前端需求給予資料
• SIT(測試人員) — 測試開發人員完成的功能並給予回饋

STEP 1 ：建立新專案

了解客戶需求後，由 PM 建立新專案

職位/角色：PM/管理人員

由 PM 建立一個新的專案並設定裡面的參數

建立專案時請注意：

• 名稱請填寫大家都看得懂的，如果專案有英文縮寫請放在代碼
• 『代碼』這個欄位儲存後無法修改，請謹慎
• 如果專案沒有要公開，請記得把公開的選項拿掉，避免無關人士看到

分配角色權限：建立專案後要加入成員並給予對應的角色權限

完成權限分配後的畫面如下，一個用戶可以有多重角色

建立專案版本：專案一定會有版本的更迭，每項議題如果都有對應的版本在管理及追蹤上可以容易釐清責任

建立議題分類：新人剛加入團隊時可能對成員的職權並不是很了解，如果在這裡建立分類的防可以快速幫助不熟悉團隊的人了解每個人的職權分配

STEP 2：分配議題(issue)

專案基礎配置完成後開始分配每個成員的任務，這裡先從 UI/UX 的設計圖開始

職位/角色：PM/管理人員

在建立議題的時候有幾點提醒一下：

• 概述：圖片可以用複製貼上，但上面只會顯示『!xxx.png!』，需要去『預覽』才能看到實際的結果
• 分類：如果選擇分類就會自動帶出被分派者
• 狀態：他的選項會跟之前賦予的角色權限有關，如果發現需要新的流程可以後續再做調整

STEP 3：組員收到議題的分配通知，根據需求細分子議題

PM 給予議題的大方向任務，組員再依據自己的專業將工作項目細分，這樣更方便追蹤議題的作業進度並評估個人績效

職位/角色：UIUX/開發人員

如果有設定郵件通知的話會收到跟下面類似的信件

閱讀完議題的需求後再依據自己實際的工作項目去細分子議題，操作方式非常直覺就不在多做介紹

議題清單：在這個頁面可以瀏覽所有議題，依據自己的工作完成進度去編輯『任務完成百分比』、『狀態』、『紀錄時間』，方便PM了解實際的工作狀況

STEP 4：UIUX 完成設計，PM 分配後續工作給前端工程師

PM 在議題狀態轉換時也會收到 email 通知，這時他可以做後續的議題分配

職位/角色：PM/管理人員

相關的議題清單：PM 新增議題的方式不再贅述，但這個議題因為需要參考 UI 設計的草圖，所以要在『相關的議題清單』與 UI 設計的議題作關聯

STEP 5：前端工程師細分子議題，並開 api 需求給後端工程師

前端工程師在設計前端頁面的同時也會開 api 的需求給後端工程師，兩者間配合才能完善網頁

職位/角色：前端工程師/開發人員

這塊比較不一樣的是前端工程師應該要更細節具體的描述每個 api 所需要的內容，所以除了『後端 api 需求』這個父議題外，也需要增加細部需求的子議題。

STEP 6：後端工程師回復議題

後端工程師在依據前端工程師的需求完善後用回應的方式說明 api 的格式讓前端工程師完成最後的串接

職位/角色：後端工程師/開發人員

後端 api 不是完成就好，要附上相關說明文件才能節省雙方溝通時間並留存紀錄。

STEP 7：PM 規劃測試流程

在前端工程師與後端工程師串接完成，也確定基礎的操作都穩定後就可以請 SIT 人員做測試了，相關的測試項目及流程一般會由 PM 做後續安排

職位/角色：PM/管理人員

STEP 8：SIT 測試新系統功能

SIT 依照 PM 分配的測試流程進行測試，如果正式成功就能把該議題狀態改為『已解決』

職位/角色：SIT/測試人員

SIT 測試過程中如果發現問題除了把議題狀態改為『測試不符合預期』以及回覆哪裡錯誤外；額外發現的問題也可以新增子任務詳細說明問題，並將子任務都先指派給 PM 讓 PM 再分配給相關人員做處理

🤔 流程總結

基本上就是測試到這個專案版本沒有任何問題後會再開新的專案版本，依據新的功能需求去實作；上面所敘述的流程僅供參考，實際的步驟還是需要公司內部有足夠共識才能真正讓這個專案管理工具發揮作用。

三、個人使用心得

1. 相比之前文章介紹的 Microsoft List、Planner ，這套系統我個人認為是完勝的，各種功能都非常完善，如果想要更多的功能也能透過 plugin 去做擴充，而且還是免費的XD
2. 但如果跟 Jira 相比，他功能就少了一點，比如：缺少 Sprint 的概念、沒辦法於文章中用@來tag相關人員、一個議題只能有一種追蹤標籤。但基本上功能已經夠用了，也許上面的功能都能透過 plugin 處理，這些就要後續再做研究了。
3. 功能擴充自由度相當高，公司如果想要導入這個專案管理系統建議要有工程師與 PM 一起配合研究，因為一些資訊的顯示還有流程要自己手動修改才能符合真實的需求。

想要導入 Redmine 可以參考我之前分享的文章：
👍 Redmine 超詳細安裝教學：Redmine 4.1.1 on Ubuntu 16.04
👍 Redmine Plugins & Themes 介紹：那些我成功擴充的外掛
👍 用 Redmine 做專案管理 — 管理者不可不知的設定
👍 用 Redmine 做專案管理 — 一般用戶不可不知的基礎功能
👍 Redmine 教育訓練 — 依角色權限說明

🙂 讀完這篇文章後

一、安裝環境
二、安裝順序
  STEP 1：安裝 MySQL
  STEP 2：建立 Redmine 使用者帳號
  STEP 3：安裝 RVM
  STEP 4：安裝 Ruby
  STEP 5：安裝 Passenger and Nginx
  STEP 6：設定 Nginx
  STEP 7：在 MySQL 增加 redmine 的使用者
  STEP 8：安裝 Redmine
  STEP 9：安裝 Redmine 外掛
  STEP 10：設定 Redmine 寄信功能
三、備註

一、安裝環境

官方沒有建議的硬體規格，但是看到有 文章分享 最低硬體配置如下：

• Processor: Intel Celeron (min 300 MHz)
• RAM: 1–2 GB RAM
• HDD: 30–40 GB

但通常使用最低硬體配置得到的結果就是容易卡，很多人同時上線使用時會讓卡到讓你懷疑人生，下面是我安裝時的配置目前使用起來算是流暢給大家參考用：

• Processor: 使用 VMWARE 的虛擬單核心
• RAM: 8GB RAM
• HDD: 500 GB
• OS: ubuntu 16.04

二、安裝順序

操作時請注意角色權限(root、redmine)，否則安裝到一半會卡住

STEP 1：安裝 MySQL

角色： root

1. 安裝 MySQL 套件
    ```
    apt install build-essential mysql-server libmysqlclient-dev imagemagick libmagickwand-dev
    ```
2. 安裝後驗證 MySQL Version
    ```
    mysql -u root -p
    ```

原始碼：mysql_install.md（GitHub Gist）

STEP 2：建立 Redmine 使用者帳號

角色： root

1. 建立 Redmine 使用者，資料放在 `/data/redmine`
    ```
    adduser --system \
        --shell /bin/bash \
        --gecos 'Redmine Administrator' \
        --group \
        --home /data/redmine redmine;
    ```
2. 建立 rvm group
    ```
    groupadd rvm
    ```

3. 允許 redmine 可以 sudo
    ```
    adduser redmine sudo
    ```

4. 設定 redmine 密碼
    ```
    passwd redmine
    ```

5. 將 redmine 使用者加入 rvm 群組
    ```
    usermod -a -G rvm redmine
    ```

原始碼：add_redmine_user.md（GitHub Gist）

STEP 3：安裝 RVM

角色： redmine

1. 安裝gnupg2
    ```
    sudo apt install gnupg2
    ```
2. 安裝 GPG keys:
    ```
    gpg2 --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
    ```
3. 安裝 RVM
    ```
    \curl -sSL https://get.rvm.io | bash -s stable
    ```
4. 讓 rvm 指令生效
    ```
    source /data/redmine/.rvm/scripts/rvm
    ```
5. 確認安裝的RVM版本
    ```
    rvm --version
    ```

原始碼：install_RVM.md（GitHub Gist）

STEP 4：安裝 Ruby

角色： redmine

作者的 RUBY_VERSION 為 2.3.8，這裡安裝的版本請參考 Redmine 的官方建議，如果安裝其他的版本後續安裝 Redmine 時會發生錯誤

1. 檢查 rvm 必要的套件
    ```
    rvm requirements
    ```
2. 安裝指定的 ruby version
    ```
    rvm install ${RUBY_VERSION}
    ```
3. 將此版本設定為預設
    ```
    rvm use ${RUBY_VERSION} --default
    ```
4. 確認安裝的 Ruby 版本
    ```
    ruby --version
    ```

原始碼：intsall_ruby.md（GitHub Gist）

STEP 5：安裝 Passenger and Nginx

角色： root

1. 安裝 Passenger PGP key 和 HTTPS support for package manager
    ```
    apt install -y dirmngr gnupg
    ```
    ```
    apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 561F9B9CAC40B2F7 
    ```
    ```
    apt install -y apt-transport-https ca-certificates
    ```
2. Add passenger APT repository
    ```
    sh -c 'echo deb https://oss-binaries.phusionpassenger.com/apt/passenger xenial main > /etc/apt/sources.list.d/passenger.list'
    ```
    ```
    apt update
    ```
3. 安裝 Passenger and NGINX
    ```
    apt install -y nginx-extras passenger
    ```

原始碼：install_Passenger_Nginx.md（GitHub Gist）

STEP 6：設定 Nginx

角色： root

1. 編輯 Nginx 設定檔案
    ```
    vi /etc/nginx/nginx.conf
    ```
2. 移除此行註解#：`include /etc/nginx/passenger.conf;`
    ```conf
    ...
    ##
    # Phusion Passenger config
    ##
    # Uncomment it if you installed passenger or passenger-enterprise
    ##

    include /etc/nginx/passenger.conf;
    ```
3. 接下來要調整 Nginx 的網站設定，所以建議先備份原本的設定
    ```
    cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.orig
    ```
5. 編輯 Nginx 的網站設定
    ```
    vi /etc/nginx/sites-available/default
    ```
6. 調整網站的根目錄位置以及 Passenger 設定
    ```
    #root /var/www/html; #將原本的註解或是移除
    root /data/redmine/current/public;
    passenger_enabled on;
    client_max_body_size 10m;
    ```
7. 把 location 段落註解
    ```
    #location / {
            # First attempt to serve request as file, then
            # as directory, then fall back to displaying a 404.
    #       try_files $uri $uri/ =404;
    #}
    ```

原始碼：set_nginx.md（GitHub Gist）

完成上述步驟後再做以下驗證：

1. 更改目錄權限： chown -R www-data /var/www
2. 重啟 Nginx： systemctl restart nginx
3. 驗證 Passenger and NGINX: /usr/bin/passenger-config validate-install

4. 檢查 Ngninx 狀態與 Passenger process: /usr/sbin/passenger-memory-stats

STEP 7：在 MySQL 增加 redmine 的使用者

角色： root

1. 登入 MySQL
    ```
    mysql -u root -p
    ```
3. 創建 redmine 資料庫
    ```
    CREATE DATABASE redmine CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
    ```
4. 創建 redmine 使用者，密碼記得自行調整
    ```
    CREATE USER 'redmine'@'localhost' IDENTIFIED BY 'password';
    ```
5. 給予使用者權限
    ```
    GRANT ALL PRIVILEGES ON redmine.* TO 'redmine'@'localhost';
    ```
6. 使權限生效
    ```
    FLUSH PRIVILEGES;
    ```
7. 離開 MySQL
    ```
    quit;
    ```

原始碼：mysql_add_redmine_user.md（GitHub Gist）

STEP 8：安裝 Redmine

角色： redmine

下載官方 image

1. 到[官方網站](https://www.redmine.org/projects/redmine/wiki/Download)了解最新的stable版本（筆者安裝版本為 4.1.1）
2. 前往放置 redmine image 的目錄
    ```
    cd /data/redmine
    ```
3. 下載官方 image 並解壓縮
    ```
    wget https://www.redmine.org/releases/redmine-4.1.1.tar.gz
    ```
    ```
    tar zxvf redmine-4.1.1.tar.gz
    ```
4. 建立連結資料夾 current
    ```
    ln -s redmine-4.1.1 current
    ```
5. 前往連結資料夾
    ```
    cd current
    ```

原始碼：redmine_download.md（GitHub Gist）

調整 redmine 裡面的資料庫設定

1. 將 redmine 的資料庫範例設定檔複製一份
    ```
    cp -pR config/database.yml.example config/database.yml
    ```
2. 編輯資料庫設定檔案
    ```
    vi config/database.yml
    ```  
3.  調整 production 的資訊即可，內容填上 STEP7 建立的使用者資訊即可
    ```yml
    production:
      adapter: mysql2
      database: redmine
      host: localhost
      username: redmine
      password: "your password"
      # Use "utf8" instead of "utfmb4" for MySQL prior to 5.7.7
      encoding: utf8mb4
    ```

原始碼：redmine_database_config.md（GitHub Gist）

下載相關套件

1. 先確認當前資料夾為 `/data/redmine/current`
    ```
    pwd
    ```
2. 執行 gem, bundle 安裝依賴套件
    ```
    gem install bundler
    ```
    ```
    bundle install --without development test
    ```
    > 如果安裝過程中遇到錯誤可能是因為沒有安裝到 ruby 的套件  
    > 1. 先安裝 `sudo apt-get install ruby-dev`  
    > 2. 再執行一次 `bundle install --without development test` 確認有無報錯

原始碼：redmine_install_package.md（GitHub Gist）

初始化 redmine

1. 先確認當前資料夾為 /data/redmine/current
    ```
    pwd
    ```
2. 用 Rake 啟動 redmine
    ```
    bundle exec rake generate_secret_token
    ```
3. Migrate Database Schema(初始化資料庫)
    ```
    RAILS_ENV=production bundle exec rake db:migrate
    ```
4. Load Initial Data(下面會請你選擇語言，預設為英文，語言後續都能再做調整)
    ```
    RAILS_ENV=production bundle exec rake redmine:load_default_data
    ```
5. 用 Nginx 重啟 Redmine
    ```
    sudo systemctl restart nginx
    ```

原始碼：redmine_init.md（GitHub Gist）

接下來你可以瀏覽 http:<server_ip> ，如果順利的話可以看到 Redmine 登入畫面如下：

STEP 9：安裝 Redmine 外掛

角色： redmine

Plugin 安裝方式雷同，下面以 Redmine Dashboard 2為範例安裝

1. 先進入 redmine 的 plugin 資料夾
    ```
    cd /current/plugins
    ```
2. 下載 plugin，最新的 release 請參考[官方](https://github.com/jgraichen/redmine_dashboard)
    ```
    wget https://github.com/jgraichen/redmine_dashboard/archive/v2.9.0.tar.gz
    ```
3. 解壓縮檔案
    ```
    tar zxvf v2.9.0.tar.gz
    ```
4. 移除壓縮檔
    ```
    rm v2.9.0.tar.gz
    ```
6.  安裝相關套件
    ```
    bundle install
    ```
7. 將套件相關 DB 進行 migrate 到 production
    ```
    rake db:migrate RAILS_ENV=production
    ```
8. 將套件安裝至 production
    ```
    bundle exec rake redmine:plugins:migrate RAILS_ENV=production
    ```
9. 安裝完畢後重啟讓設定生效
    ```
    sudo systemctl restart nginx
    ```

原始碼：redmine_plugin.md（GitHub Gist）

STEP 10：設定 Redmine 寄信功能

角色： redmine

如果沒做這個步驟是寄不出信的，需要做下面的調整即可

1. 進入 redmine 設定的資料夾
    ```
    cd /current/config
    ```
2. 將 redmine 的設定範例設定檔複製一份
    ```
    cp -pR configuration.yml.example configuration.yml
    ```
3. 編輯 redmine 設定檔案
    ```
    vi configuration.yml
    ```
4. 調整 production 的資訊即可，下面用 Gmail 作為範例
    ```
    production:
      delivery_method: :smtp
      smtp_settings:
        enable_starttls_auto: true
        address: "smtp.gmail.com"
        port: 587
        domain: "smtp.gmail.com" # 'your.domain.com' for GoogleApps
        authentication: :plain
        user_name: "email"
        password: "email pw"
     ```
5. 設定完畢後重啟生效
    ```
    sudo systemctl restart nginx
    ```

原始碼：redmine_email.md（GitHub Gist）

三、備註

1. 如果進入網頁時畫面沒有顯示應該是因為防火牆問題，可以用下面指令嘗試：sudo ufw allow http 、sudo ufw allow https
2. 參考資源：Redmine 安裝篇：Redmine 4.0.x on Ubuntu 16.04、Redmine Plugins and Themes、HowTo Install Redmine on Ubuntu step by step

安裝完後如果想進一步了解如何使用 Redmine，可以參考以下文章：
👍 如何用 Redmine 做專案管理＆體驗心得
👍 Redmine Plugins & Themes 介紹：那些我成功擴充的外掛
👍 用 Redmine 做專案管理 — 管理者不可不知的設定
👍 用 Redmine 做專案管理 — 一般用戶不可不知的基礎功能
👍 Redmine 教育訓練 — 依角色權限說明

🙂 讀完這篇文章後

前言：專案管理工具的抉擇

其實 Jira、Notion 是更好的專案管理工具(個人使用後的觀感)，但因為許多公司都有購買 Office 365 來使用 office、excel… 等工具，所以如果專案管理也能用 Office 365 來解決不但能節省一筆經費，更可以讓團隊把注意力集中操作同一個軟體，而不是做一件事都需要更換一個軟體。

Office 365 裡比較適合拿來做專案管理的有 Microsoft Planner 、 Microsoft Lists 這兩個，如果有興趣了解兩者的不同可以參考這篇文章，但經過考量後 Microsoft Lists 更為適合多個單位之間的合作，下面會詳細介紹我是如何使用的。

一、建立符合專案管理需求的 Lists

SETP 1: 建立空白清單

SETP 2 : 依照需求新增欄位

➤ 下面說明每個欄位的作用，可依自己的需求再做調整：

1. 任務名稱：簡單明瞭讓被指派的人員初步了解任務
2. 描述：詳細說明任務內容，如果有子任務建議使用條列式呈現
3. 進度：顯示該任務完成進度，此欄位會因為任務類型的不同而有不同的文字呈現
4. 優先度：分成 緊急>普通>不重要 3 種
5. 負責人員：PM 指派的任務對象，此欄位可選擇群組或是由多個人負責
6. 相關人員：除了負責人員外，需要追蹤該任務的人員，就像是信件的副本概念
7. 負責 PM：通常就是建立該任務的 PM 本人
8. 任務類型：分成 文件、設計、程式、測試 4種，方便透過此欄過濾出想要的資訊
9. 相關連結：可能是要測試的網址、給設計的參考範本、完成的文件連結…
10. 開始日期：被指派的人員開始作業時的時間
11. 到期日：完成該任務的時間

二、模擬專案實際情境

需求：今天有一個網站需要新增一個商品清單頁面，並且在這個頁面可以對商品進行新增、修改、刪除、查詢的動作

前期

指派設計完成 wireframe，同時 PM 分析這個頁面的細部需求規格

中期

在設計的 wireframe 與 PM 的需求規格完成後，後端工程師可以依據需求規格開始撰寫 api ，前端工程師也能依照 wireframe 先完成畫面等 api 完成後串接

後期

在前端工程師依照 wireframe 完成 UI 並串接好後端 api 後就可以請測試部門做功能上的確認，測試的功能項會建議由工程師做簡易的文件撰寫。

測試後依據測試結果將進度轉為 測試成功、測試失敗 ，如果測試失敗要說明原因並重新指派給當初負責的人員處理。

三、操作上的小訣竅

善用篩選功能找出需要的資訊

因為列表上的資訊非常多，所以我們可以依據實際的情境來做調整：

1. 將 優先度度為緊急 的篩選出來確認進度
2. 測試人員只需要瀏覽 任務類型為測試 的就好
3. 可以 用關鍵字搜尋任務名稱

使用交談功能討論任務進度

使用過本產品的人我想最大的詬病之一就是文字圖片無法複製貼上，目前看到可以複製貼上的區域只有 任務裡面的交談，如果你們有很多詳細的內容是寫在交談裡面的請記得在描述中說一下，不然大家都不知道交談裡面有更多內容。

結語：讓工具連結發揮更大功用

如果只操作 Lists 你會感覺到有些部分綁手綁腳的，但 Office 365 的工具我想當初設計的想法就是要使用者把裡面的工具互相串聯吧？所以每項工具只做出基礎的功能，如果要更深入的功能需要再與其他工具結合：

1. 如果你要 subtask 的功能要與 Microsoft Planner 結合
2. 想要撰寫更詳細的文件內容就直接超連結到 Microsoft Office

他不是一款完美的工具，但使用者可以透過其他方法讓他更好用。