COSCUP 2016 個人檢討:組織分工

MozTW BoF 全景照

記錄一些今年 COSCUP 跟我相關、關於組織與分工的變動與效果檢討。包括與議程委員會、贊助組的分工改善,以及行政組議程庶務小組工作管理方式等。

由於篇幅,本系列文章共分拆成三個部分:


議程委員會與行政組議程庶務分工定義

關於「獨立議程委員會,議程庶務併入它組」,原先在 2011 年第一次有類似編制後,我在檢討會曾提出反對意見,認為雖然立意良善、但沒有討論好分工下太容易掉球(議程跟對口的會眾組長每年都會換人,當時雙方都還不夠熟練,可能也是原因之一)。不過既然總召希望如此,而曾經擔任過議程組長跟處理過會眾、行政事務的我還算是適合的人選,那就盡力配合、當仁不讓了。

有鑑於此,近兩屆我都參與了這件事,在最開始就先跟總召及議程委員會主席定義了分工方式。今年補上一些去年沒定義好的部份,結果如這張卡片,大致順利。

結論:分工定義算是清楚了。接下來可能可以處理一下雙方工作方式對彼此影響的問題。

贊助商稿件提供說明書

為避免訊息傳遞失誤,今年開始測試給贊助商的稿件說明書

目前看起來在講者有看的情形下沒什麼問題,下次需要特別注意的地方則是內容正確性及一些例外狀況處理(雙講者等)要先列上。

嚴格講來這份文件也非全新,而是脫胎自舊的建議文件

結論:這件事應該繼續維持下去為佳,跟贊助組預先要求這份文件一定要傳遞到講師手上;需要進一步針對要搜集的資料及雙講者等狀況定義清楚。

議程組信箱引入客服信件管理系統

繼去年 attendee 之後,今年 program 這個信箱也採用 Zoho Support 作為客服信件管理系統。有義鴻主動協助幫忙議程調度的聯絡信件,狀況比去年後來我差不多一個人扛客服還順利點。

program 今年居然也有 400+ 的信件,有點可怕。業務東併西併,量很大的情形下,2016 行政組人數反而減少了(去年是直接整併助理主持額度,今年連助理主持都不夠還要另外從別組找),真的是非常配合總召節約的需求 :/

等更多人熟悉以後應該就可以實作一些責任分工方式。

結論:以系統管理客服信件是正確方向,需要帶入更多人一起分工。

公開工作事項看板

議程相關事務一直有點黑箱性質,主要是兼顧一些人性上的需求(例如不想讓你知道誰沒被選上,避免人家不好意思),不過庶務比較沒這問題,因此延續去年行政組有「預設為公開、有敏感資訊才藏起來」的想法,今年的議程庶務是用公開的 Trello 看板管理。

過程中多少有一些編制外的志工進場協助或問問題,或許明年可以再進一步拓展。希望把這樣的想法再推到其他組別,畢竟這是個不同的研討會,你應該挑戰一下的啊:那些以為一定要藏起來的事情,或許不一定要藏起來。

這個看板也順便把「放棄」的點子整理起來了,以後接手的人能藉此知道所有曾經做過或想過的事情。

結論:是還不錯的開始,還沒有引入夠多外部資源協力;把各種事情記錄起來有沒有好處就要看來年檢討。

工作切分、複雜度評估、pair working

嘗試把一些 SCRUM 的元素帶進來:

  • 在一開始就招集小組成員,過一次今年目前所知的工作項目
  • 邀請大家一起切分工作,將工作切細
  • 評估細項工作的複雜度
  • 要求每項工作都有兩人以上參與,彼此之間要能互相支援
  • 定期回報目前狀況及確認有無問題:我設定了 Slack 的 Reminder 來定期提醒大家記得把問題提出來。

沒有劃分 sprint(志工工作狀況相對不穩定,我還沒想好這時應該怎麼修改制度來因應,就不把這個相對新的東西帶進來),以這個角度來看比較純粹是看板,但整體的溝通過程還是不少。

有些部分還不錯,例如評估工作複雜度這點讓大家對於工作內容有幾次集合討論的機會,凝聚彼此的共同認知(有沒有用,明年就見真章);這個方式(搭配 SCRUM 常見的圖表)也讓我在工作開始後六週左右就知道這次的事項已經遠遠超過志工負荷,並且也藉此決定要刪掉某些內容及評估人力需求。

不過還是有些事不很順利:

  • Pair:經驗落差問題讓負載集中到少數人身上,大家都找他 pair 的話會爆
  • 人員流動:這次我這個小組有三次跟成員說再見的情形,主要也是我希望嚴格一點。不過一來一往又要重新溝通組內的工作方式,有點花時間,後來請極地狐幫忙整理了工作方式說明,稍微舒緩了這個問題。而大家到底願意付出多少承諾是另一個問題。(附註:我只會在未請假但也無進度,且三週進度幾乎掛零的情況下才踢人,這樣的要求應該還不算太嚴。)
  • 被分配工作的慣性:其實常聽到人講「有什麼需要幫忙再跟我說」,但你不需要如此,有事沒人做就可以撿起來。這想法其實跟我越來越從純推廣的「我們應該讓大家更容易貢獻」轉向「現在人過分少,我們應該先協助那些已經很主動的人,不必花太多時間把貢獻變簡單」相關。這次雖然待辦事項都已列出,但許多狀況下會發現組員手上的事情結束後還是會等著我分配工作。話說回來,或許我應該多強調幾次做完手上的就自己挑下一張。

結論:考量志工實際狀況,可能還是要退一步把整個大專案(Story)交給同一個人負責會比較好;工作方式要先文件化方便參考及後續成員加入;下次可以考慮看看要不要把 Sprint 的概念也拉進來。

工作坊審稿引入非工作人員協助

如同前面提到,我總是想嘗試更開放的方法(我知道相對 gøv 的習慣還是比較保守一點啦哈哈),這次在工作坊的部分也進一步試圖邀請不在編制內的志工參與審稿。有鑒於這是第一次嘗試,我選擇了比較封閉式的成員招募方法:

  1. 先隨機從「開放源碼貢獻者」中抽 15 位,排除掉屬性比較重複的
  2. 發信問他們願不願意幫忙這個實驗專案,要承諾在兩週內至少兩天上一次討論空間參與討論,並且不能揭露大家討論的內容
  3. 同意者加入某個討論空間,我們把題目、介紹等資料公佈給他們,他們可以就裡面的東西互相提議討論(我們也同時拿應該要跟投稿者問清楚的問題問投稿者)
  4. 兩週後一人三票投票,投票結果作為參考。
  5. 能完整跑完這兩週的我們也承諾賦予 VIP 資格

可參考這張卡片的描述。由於招募時已經是從開源貢獻者申請名單裡找,也就是招募對象本來就對開源有些熱情與概念,因此合作與討論上都還蠻順利的,大家也都遵守承諾認真審查。以此方式,同時也可以增加參與者對於大會的認同感,讓 COSCUP 更符合社群共同協辦的想法。

最後整理的入選名單,票數我都遮起來了(且並非案票數排序),只留 Open Networking Workshop 的部分當範例

除了前面提到的招募方式外,討論時的方法如圖:

  1. 用 Trello 開權限給招募進來的志工,請他們先看「請先讀我」以了解討論方式。
  2. 每個議題一張卡,大家可以在卡內討論
  3. 如果有要追問原申請者的問題,可以發問後標示特別標籤;我會去把問題整理好列入 Checklist,筱潔幫忙每天巡一次還沒詢問的問題、並且把問題轉給原申請者後標為完成(這樣我們就知道還有哪些問題還沒問),並且在申請者回答後再轉述到卡上
  4. 兩週後大家投票選擇希望列入議程的工作坊,我們再從最高票的開始排入議程。

討論方式看起來沒什麼大問題,審查後邀請大家提供回饋也多為正面。雖然增加了議程庶務上的一些負擔(追問的部分),但還是挺值得的。

結論:這個方式蠻順的,強烈推薦繼續沿用。有時間可以想一下追問的部分怎樣會更好。

預先排定電子報內容方向

如某次聊天,我認為目前 COSCUP 很缺乏對大眾提供自產內容的能力,這次也有打算提前規劃電子報內容,但因各種因素、仍是到最後才急急忙忙做了點分工與議題規劃。沒能在有空的時候先處理,擠到最後面已經分身乏術。

這邊在下次應該要整合一下其他組(行銷?)的力氣來做,像這幾屆般全部由行政組自己編人的話有點浪費人才。

結論:想解決的問題依然存在,下回或可試試看整合行銷的力量來做。

主持注意報、助理主持文件

此次還兼控助理主持的相關事務,不過一方面參與者大多已有經驗,二方面也利用了以前的文件,不算太費心。有改變的地方可能是做了固定可以參照的「主持注意報」,把臨時要請主持人宣導的事情丟在上面並提供建議宣導時機,方便參照。

格式:日期時間、建議發表時機、語句範例

但我的感覺是沒有發揮什麼作用,可能原因包括:

  1. 大家還是會期待有變更時喊一下,而不是養成固定參考文件的習慣。(畢竟其實不會經常有事情要宣佈)
  2. 今年各組請主持人宣導的項目大幅度減少,可能因為需求都跑到 App 去了?不過有一成以上的參與者不使用 App,這邊應該要在檢討會討論一下。

剩下的優點… 大概是有個明確文件記錄給後手參考。

至於助理主持本身,去年將助理主持正式納入會前籌備人員之後,就不再單純只招募「當天出現就好」的人了。但今年行政組自己人手不夠,所以最後還是從別組請人來幫忙,但發生被找來的人在細節還沒出來之前覺得被晾著的情形。一方面應該是我們在招募時不慎建立了錯誤期待,二方面或許一開始提供的過往參考文件太快進入細節了。加一段 overview 在前面可能好點:

助理主持的功能恰如其名:協助主持人。在會前分配班表後,你會與同時段的主持人相互合作彼此分工,協助議程順利進行。這不是一件很難的工作,你一定可以很快上手,遇到問題的時候也不必緊張 — 要緊張的是主持人跟場控 ;) 所以帶著計時器跟時間提醒牌,好好享受議程吧!

今年度的助理主持注意事項請參考此文件

結論:主持注意報不算成功,不過別有用途,若每次更新還是喊一下的話應該多少有用。助理主持文件缺 Overview。