/ CoBuild 詳細介紹
CoBuild：一套共同建造 HackIt 的方式
在前面章節我們講述了為何我們需要一套全新的方式來讓社群更好的協作，而本章節將開始詳細且具體的介紹這一方式，CoBuild！CoBuild 是 HackIt 發展出的一套共創制，深受 Holacracy（合弄制）啟發，可以說是他的變體之一，我們對合弄制做出了一些調整以利於青少年組織的運行。
在這套系統中，每位參與者不再只是執行被指定的任務，而是共同參與 HackIt 的建造。我們不依賴傳統由上而下的管理方式，而是讓每個人都能主動發現需要被改善的地方、提出想法，並參與推動改變。責任不再依附於頭銜或職位，而是透過具體的角色來承接；每個人也能根據當下的興趣與專長，在多個不同領域中發揮影響力。那麼，這套運作方式究竟是如何實現的？讓我們先從「組織是如何進步的」開始說起吧。
張力？
張力指的是：當我們感覺到「現在的狀態」和「它其實可以變得更好的樣子」之間存在落差時，那個落差我們稱之為張力。
在 CoBuild 裡，我們會經常使用一個詞：張力。
這個詞在中文裡聽起來可能有一點抽象，甚至讓人想到緊繃、衝突，或是某種不太舒服的狀態。但在這裡，張力不是壞事，也不只是情緒上的不滿。在 CoBuild 中的張力指的是，當我們感覺到「現在的狀態」和「它其實可以變得更好的樣子」之間存在落差時，那個落差就是張力。
例如，一位剛加入 HackIt 的夥伴不知道自己可以從哪裡開始參與；一場活動的報名流程讓人感到困惑；一份文件寫得太模糊，導致大家對同一件事情有不同理解；某個角色承接了太多責任，已經快要被事情壓垮。這些都不一定是誰做錯了什麼，但它們都代表 HackIt 的某個地方還有改善的空間，都是張力。
所以，張力不是抱怨。抱怨通常停在「我不喜歡現在這樣」，但張力會更進一步地指出：現在的狀態哪裡不夠好？我看見了什麼可能性？如果這件事被改善，HackIt 會不會變得更接近我們的目標？一個組織真正的進步，往往不是來自一開始就被設計好的完美架構，而是來自許多人在實際行動中，不斷發現這些細小但重要的落差，並把它們轉化成可以被討論、被承接、被改變的事情。
在傳統的上對下組織裡，張力通常需要被「往上回報」。你發現了一個問題，可能要先告訴小組長；小組長再告訴更上層的人；更上層的人再判斷這件事重不重要、要不要處理、該由誰處理。很多時候，張力還沒有真正抵達能改變它的地方，就已經在一層層傳遞中被消耗掉了。
更麻煩的是，當所有張力都需要由少數領導者消化時，組織會變得非常依賴那些人。大家會開始等待「上面」決定，小問題會慢慢累積成大問題，原本可以被快速修正的事情，最後可能變成私下的抱怨、不清楚的誤會，或是長期沒有人處理的灰色地帶。而領導者也不可能真的看見所有事情。一個人就算再負責、再有經驗，也不可能同時感受到報名頁面上的困惑、現場動線裡的不順、贊助溝通中的卡點、視覺設計上的不一致、新人加入時的迷路感，以及每一位夥伴正在承受的壓力。
因此，CoBuild 不把張力視為領導者個人的負擔。在 CoBuild 裡，張力是每個人都可以看見、提出，並”主動“協助推動的改變入口。
這並不代表任何人只要感到不滿，就可以要求整個組織立刻照自己的想法改變。提出張力不是丟出情緒，也不是把問題丟給別人解決。提出張力的意思是：我看見了一個現況與理想之間的落差，而我願意把它說清楚，讓它有機會被理解、被放到合適的位置，並被轉化成下一步行動。
有時一個張力會變成一個新的任務；有時它會讓我們調整某個流程；有時它會讓我們發現某個角色需要被新增、拆分或重新定義；也有時它會讓我們意識到，HackIt 原本的規則、文件或文化描述已經不夠清楚，需要被重新寫下來。所以，張力不是混亂的來源。真正讓組織混亂的，往往不是張力本身，而是張力長期沒有被看見，也沒有被得到處理。當張力被壓下去，它會變成抱怨。當張力只停留在情緒裡，它會變成消耗。但當張力被說清楚、被承接，並被轉化成行動，它就會成為組織進步的燃料。
這也是 CoBuild 很重要的一個信念：組織不是因為沒有張力才健康，而是因為有能力處理張力才健康。
HackIt 不追求表面上的和平。我們更在乎的是，當有人感覺到哪裡不對勁、哪裡可以更好、哪裡正在阻礙我們共同建造時，他是否有一條清楚且安全的路徑，把這件事提出並推動解決。因為每一個被好好處理的張力，都是 HackIt 變得更好的入口。當我們開始認真看待張力時，下一個問題也會自然浮現：如果張力不是單純屬於某個人的情緒，而是組織可以進步的訊號，那麼誰來處理它？誰有權限改變它？責任又應該放在哪裡？
這就需要我們從傳統的「人」作為最小單位，轉向 CoBuild 裡更重要的基本單位：角色。
從人轉變為角色
角色是 CoBuild 裡承接責任的基本單位。每個角色都有清楚的"目標"、"管轄領域"與"責任"；一個人可以同時承接多個角色，也可以在需要交接、拆分或調整角色。當某個角色開始承受過多負擔，或反覆產生難以處理的張力時，就代表我們可能需要重新定義它，甚至拆分出新的角色，讓責任變得更清楚。
當我們開始認真看待張力時，很快就會遇到另一個問題：這個張力到底是「誰」的事情？
在傳統的組織裡，我們常常會把責任直接綁在人身上。某個人是活動組長，所以活動相關的事情都要找他；某個人是視覺負責人，所以所有設計問題都變成他的問題；某個人是總召，所以只要事情不知道該找誰，最後就會回到他身上。這樣看起來很直覺。因為我們很容易用「人」來理解組織：這個人負責什麼、那個人管什麼、誰可以決定、誰應該出來處理。
但久而久之，這會產生一個問題：當責任都被綁在人身上時，我們討論的焦點很容易從「這件事需要什麼責任」變成「這個人是不是做得好」。原本只是某個流程不清楚、某個權限沒有被定義、某個責任範圍太大，最後卻很容易變成對某個人的評價。
例如，在一場 HackIt 活動裡，負責現場體驗的人可能希望報到流程更有儀式感，讓參與者一進場就感覺自己進入了一個新的世界。但負責安全相關事務的人可能會提醒，報到不能太複雜，否則會造成動線阻塞，也會讓緊急聯絡、身份確認和人流管理變得不清楚。
這時候，兩邊之間就產生了張力。
如果我們把責任直接綁在人身上，很容易會覺得：「他是不是太保守了？」「他是不是不懂體驗？」「他是不是又在限制創意？」或者反過來覺得：「他是不是只想做酷的東西，沒有想過現場風險？」
但如果我們把「人」和「角色」分開，就會看見完全不同的事情。這不是某個人和某個人的衝突，而是兩個角色正在照顧不同的"責任"。
「參與者體驗設計者」正在照顧的是參與者進入活動時的感受、沉浸感與記憶點；「現場安全照護者」正在照顧的是現場秩序、風險控管、緊急處理與參與者安全。
這兩個角色都重要，也都不是錯的。真正需要被處理的，不是誰比較有道理，而是這兩個角色背後的責任要如何被協調，讓活動既有體驗，也不失去安全。這就是 CoBuild 想做的第一個轉變：把責任從「人」身上拆開，重新放到「角色」裡。
在 CoBuild 裡，角色不是職稱，也不是身份，更不是階級。角色是一份清楚的承諾。它代表某個人願意在某個範圍裡照顧一件重要的事情，並承接推動這件事所需要的責任與權限。
我們不一定需要說：「某某人是活動組長，所以活動相關的事情都要問他。」我們可以改成說：「目前有人承接了『活動節奏維護者』這個角色，他負責維護活動流程、提醒時程風險，並確保每個階段能順利銜接。」
這兩種說法看起來很像，但背後的邏輯完全不同。
前者把權力放在人的身份上，並且帶著模糊的管轄範圍與責任，他究竟有權/應該處理哪些事情，亦或者是全部？後者把角色有著清晰的權利與責任。
當權力放在人的身份上且組織責任模糊時，很容易開始依賴少數幾個人。大家會習慣問：「這件事要不要先問某某人？」、「這個可以做嗎？」、「誰最後拍板？」而那個人也會慢慢被所有事情包圍，變成活動裡永遠不能離線的人。
但當責任被放進角色裡，事情就可以被說得更清楚。
我們可以問：這個角色的目的是什麼？它正在照顧什麼事情？它需要哪些權限，才能真的推動責任？它的範圍到哪裡結束？如果它太重，是否需要被拆成兩個角色？如果它沒有人承接，是否代表 HackIt 有一塊重要的事情正在沒有人照顧？
這些問題會讓組織開始從「找人負責」轉向「釐清責任」。
這對 HackIt 特別重要。因為 HackIt 不是一個每個人都被固定分配到某個部門的組織。我們的專案會變，活動會變，需要的能力也會變。一個人可能在某場活動裡承接現場體驗相關的角色，在另一個專案裡參與敘事設計，也可能同時協助技術工具、文件整理或新人導覽。
重要的不是他「是什麼職稱」，而是他此刻正在照顧什麼事情，因此，在 CoBuild 裡，一個人可以同時承接多個角色，也可以在某個階段交接角色。同時角色可以被新增、拆分、調整，也可以在不再需要時被移除。
這讓 HackIt 不需要把每個人固定在某個位置裡。
你不會因為曾經做過視覺，就永遠只能做視覺。你不會因為一開始加入的是活動籌備，就不能參與敘事、技術或文化設計。你也不會因為沒有某個頭銜，就不能對某件事情提出張力，或承接一個你願意照顧的角色。
CoBuild 裡的角色，不是用來限制人的邊界，而是用來讓責任變得清楚。它讓我們知道：誰正在照顧這件事？他照顧的範圍是什麼？他可以自己決定什麼？什麼事情需要和其他角色同步？當張力出現時，應該被帶到哪裡處理？
而當一個組織開始用角色來承接責任時，下一個問題也會自然出現：如果角色不再依附於傳統部門，那這些角色要被放在哪裡？不同角色之間又要如何協作、同步與調整？
這就是 CoBuild 裡的下一個重要概念：圈子。