在好想工作室中參與其他案子累積經驗時，過程中剛好碰到這個案主挑戰賽的活動，主要是給一些在好想工作室一些還在學習的學員讓他們有接案的經驗，可以參考這一篇：
練功活動: 模擬案主!! - iT 邦幫忙::一起幫忙解決難題，拯救 IT 人的一天

本來沒有要參加，但在最後一刻還是加入了進去。

以下就來談談我這次的經歷跟學習到的經驗吧！

模擬案主

這個案主挑戰賽由工作室內資深的前輩進駐者擔任案主，他們會根據之前做過的案子，挑選其中的難題作為挑戰賽的主軸，包括題目設定和驗收的故事。在挑戰賽的過程中，參賽者可以和案主不斷互動，獲得寶貴的指導和建議。

比賽分成幾組進行，主辦方會根據參加者的程度平均分配隊伍。這次比賽主要分成三個組別，每組由三個人組成，並在一個禮拜內完成案主的需求，編寫出一個完整的網站。

一切始於一個風和日麗的下午，所有參加這次案主挑戰賽的人都聚集在大會議室裡。我看著大家，人數很多讓我感到有點緊張。主辦方首先要求我們寫下想和誰組隊的名字，我隨手寫下了一個名字，然後交了出去。接著是主辦方的操作，他們通過一個我不太了解的機制，選出了我的兩個隊友。分組組合印在會議室的大白板上，主辦方開始講解比賽的注意事項。

這時，我凝視著前方的白板，看了看我的隊友。除了我之外，沒有人有寫程式的經驗，其中一個人甚至不太會切版，我的汗慢慢從臉上滑下來。

開始分配

一旦離開大會議室，挑戰賽就正式開始了。每個小組都開始討論並分配任務。

雖然時間只有一個禮拜，理論上必須趕快開始進行，但我認為在這種情況下，越是早期就要花更多的時間來分配任務。因為一開始難度高，後面才會變得簡單。因此，我們需要採取慢慢來比較快的心態，開始分析我們小組的未來。

我知道，這個挑戰賽不僅僅是考驗技術能力，否則最厲害的人一起做一定最快。但這樣做就沒有必要分組，而且實際工作中也不可能單打獨鬥，必須依賴於團隊的力量！因此，協作能力是這次挑戰賽的關鍵。

我開始確定每個隊友的能力，然後思考他們可以負責的工作。我的底線是，所有隊友都需要參與和貢獻，最終先分配一個整體方向。

我負責的是專案中的 JavaScript；隊友 A負責專案中的切版；隊友 B負責專案中的套件。

我扛下程式的部分是因為其他兩個隊友剛開始學習前端不久，所以我決定負責這個部分。至於隊友A，他的切版能力還不錯，所以我交給他專案中的切版。最後，隊友B負責的部分比較困難，因為他的切版能力不足。後來我想到，專案中有些套件可以直接從網路上找別人做好的來使用，最好的情況下只需要改改樣式，所以我就把這部分交給了他。初步的任務分配就這樣完成了。

注定遇到的雷

在合作接案時，有些問題是必然會遭遇的，其中一個就是 Git 的版控管理。這個問題之所以令人感到不安，是因為當協作人數增多時，若沒有事先定義一套統一的規範，讓大家遵守相同的 commit 格式和分支操作規則，每個人都依照自己的習慣進行開發，最終將造成混亂和衝突，因為每個人的習慣都不一樣，不知道要聽誰的意見。

因此，我們這個團隊採用了 Git Flow 的流程開發方式，讓大家能夠遵循一套統一的規範。這包括 commit 紀錄的格式和分支的使用場景。每個分支都有其獨特的功能，合併分支時需要透過一個非自己的人進行程式碼檢查，並且透過 PR 的方式確認是否可以進行合併。透過這些方式，我們能夠減少 Git 版控管理的問題發生機率。

除了版控管理外，另一個不可避免的問題是重複和衝突。然而，我們這個團隊巧妙地避免了這個問題。

透過明確的分工，將程式開發和切版工作完全獨立出來，我們基本上不會遇到重複的問題。例如，若一個頁面由兩個人負責切版，可能會出現同一區塊但樣式不同的情況，或者需要反覆修改衝突部分的情況。然而，這樣的問題在我們的團隊中相對較少。基本上，當隊友 A 瘋狂地切版時，我就負責撰寫功能，或者我先完成 API 串接，再由隊友 A 繼續切版。雖然偶爾會發生衝突，但是基本上相當少，我也盡量避免碰到切版的部分，並將這個任務交給隊友 A。

參與挑戰賽的過程

評估專案需求後，我們最終是決定用 vue 的框架來完成這次挑戰的模擬案，之前有接過 vue 的專案，所以我有一些把握不至於最終會做不出來，把環境建好之後，大家都開始做自己分配好的任務，準備開始一個禮拜的挑戰賽。

在過程中，我知道一定會遇到很多我不熟悉的地方，需要先研究後才能實際操作。因此，我有心理準備。然而，在一開始時，我有些過於樂觀，以為可以同時進行挑戰賽和原本的專案，但事實證明，即使顧好挑戰賽也顯得有些吃力。在過程中遇到了很多卡住的問題，例如無法理解的錯誤訊息，即使找了很久也無法解決。除了處理自己的工作外，我還必須不斷地撥出時間處理其他人的問題，這對我來說是很困難的挑戰。

這個挑戰賽總共有兩次的驗收，第一次是在兩天後，第二次是在恰好一週後。由於時間非常緊迫，因此在第一次驗收時基本上還沒有完全完成。在第一次驗收期間，由於我不會拒絕的原因，被擔任模擬業主的前輩們硬生生地追加了許多功能和細節。所以兩天後的第一次驗收結束後，我大概就感覺到我後面這幾天不用睡覺了。

越接近尾聲，狀況就像雨後春筍一樣不斷湧現。我猜想這也是挑戰賽精心策劃的難題。例如在驗收前幾天才把後台資料齊全，不斷修改設計，並增加了一些臨時額外的需求。我覺得主辦方的模擬案主們在這方面扮演得非常好，將真實可能反覆無常、挑剔的角色演繹得栩栩如生，我們組就盡可能的把這個鍋子(需求壓力)給蓋好，不要讓他滿爆出來，心中不停默念著一切都好。

在驗收前的一天，我們得知一些套件的需求可能超出了隊友的能力，因此我需要自己來處理。此外，還有一些新的額外功能需要開發，但我仍覺得這部分可以應付。然而，正當我們在本地端測試專案時，發現手機載入速度非常緩慢，明顯不正常，令人崩潰。更奇怪的是，這個問題只出現在 iOS 手機和平板上，而在 Android 手機和電腦上則沒有。我們嘗試尋找問題的原因，從下午找到晚上，直到回家，但仍然無法找到答案。為了解決這個問題，我花了一整天的時間。由於我平常是搭乘公共交通工具通勤，當天最後一班車已經要發車了，所以我只好回家了，因此沒有足夠的時間完成原本要開發的功能。這個問題是致命的，如果我們無法解決它，那麼我們的團隊將面臨失敗的命運。

最終，我決定先部署網站，即便只是樣子，也能讓我們看到網站的表現如何。但奇蹟般地，在部署後，網站突然恢復正常了。我感到非常震驚，也很開心，因為這意味著我們有機會通過明天的驗收。

於是，我開始加緊完成剩餘的任務，並在驗收前夕趕出了一個八成像的網站，雖然過程中有些波折，但最終還是成功地完成了挑戰賽，拿到了第一名，我覺得我跟組員都很棒。

參賽後記

完成比賽後，我第一個感受是時間過得真快。一周的時間在弄模擬專案的過程中消逝了，但我也學到了很多，不僅主辦方關心每一組的進度，也講解了一些重點幫助大家進入狀況。因此，我學到了很多在正式接案中與業主對談時的技巧和細節，例如：

  • PM 金三角
  • 如何確認需求，Story
  • 可開工條件
  • demo 展示給業主看的要點
  • 最小可行性 MVP

總的來說，我很喜歡這次的參賽體驗。通過這次比賽，我更深刻地意識到自己確實還有許多不足之處。還有很多東西我不會，但我想這次挑戰賽結束之後，我感到的不是單純的放鬆，而是要再去開拓自己還不足的學習之路。因為我有了許多方向可以參考，期待在未來面對壓力時可以更加游刃有餘!