PDIS 實習日誌:學習「團隊」


Posted by Lai Yen Ju on 2020-07-09

92 天中的第一天

團隊成員們的角色,該長成什麼樣子?需要時間觀察跟溝通。但每次分組進行專案設計,都帶著這份「初心」?開始,破滅的也總是對夢幻團隊的想像。

這次參與的 RAY 4.0 計畫依然如此,因為大家都是熱愛使用者研究但經驗生嫩的學生,可是專案設計總需要人來管理、需要分工協調、需要提出解決方法、需要各種的討論才能迸發火花。

不潮,才是好用的協作工具

團隊內正好有位對技術、科技產品非常有熱情的夥伴,其實我自己也有這種迷戀科技的傾向,愛好嘗試各種新奇的筆記軟體、生產力工具,正當熱烈討論使用哪種 Markdown 服務建立筆記、在 GitLab 建立管理文檔時,我才驚覺到組內還有兩位完全不知道該如何撰寫 Markdown 文檔。

該如何快速、方便的協作,最後考量的仍然是使用者,當我們在做使用者研究,只考慮到產品使用者,卻忽略團隊夥伴的專案參與感受,就有點說不過去,畢竟本來實習計畫本來就沒有為大家提供這方面的 on-board 訓練,強求團隊夥伴都會 Markdown 等同額外增加對方的工作量,不見得是成本效益平衡的做法。

Google Doc 仍然是最棒的選擇,滿足即時線上協作跟夥伴的使用熟悉程度。

必須用不熟悉的協作工具,該如何快速上手?

唐鳳辦公室旗下的 PDIS 提倡遠端協作工作,因此強調隱私與安全的協作工具是必備品,PDIS 為 RAY 4.0 實習生準備了以下協作工具:

  • GSuite:使用 Google Drive 儲存各類文檔、共用信件清單。
  • GitLab:PDIS 自行架設 GitLab 社群版,作為團隊專案管理工具。
  • Rocket chat:類似 Slack 即時訊息服務,PDIS 的所有成員以及團隊成員間主要傳送訊息的方式。

其中 GitLab 是我完全不熟悉的工具,一是因為自己以往習慣使用 GitHub,不了解 GitLab 的使用方式,二是沒有正式使用過 card board 卡片式專案管理方法,而夥伴們也沒有人有相關的管理或使用經驗,因此只能

Google,而我找到這篇文章將 GitLab issue 專案管理方法說明的很簡單易懂,還附圖當作範例。

看完後,我覺得這次的實習專案管理,可以採用 workflow 方法,搭配六步殺設計流程,以階段作為主要分類表:

  1. 了解使用者
  2. 定義核心議題
  3. 打造 wireframe
  4. low-fidelity prototype
  5. high-fidelity prototype
  6. 專案發表

以上就是各個階段的目標,在每個主分類表內,塞入要達到該目標須完成的任務們,而任務的標籤包含截止時間、負責人員、進行狀態(to-do、doing 或 finished ),如果遇到任務是需要小組成員一起討論或各自找時間確認文檔,就使用 @ 夥伴名稱的方法。

用這個方式的好處是,兩個月份的研究規劃也一併在 GitLab issue 中安排好了,而且還視覺化呈現;而且團隊夥伴對目前任務進行到哪個階段都會有共識,因為都看得到,而在分配工作時,也較好刺激個人的主動性,畢竟任務就攤在那裡等著大家去撿拾,較快完成工作的人也知道現階段還有哪些工作沒完成,就可以繼續撿起來做。

但這個專案管理方式遇到一個問題:誰來主責管理?

PM 的任務不是打雜

參與這個計畫,其實也想多磨練自己管理專案的能力,不過團隊夥伴中有位自願擔任 PM,有意願跟熱情是好事,但沒有管理經驗的話,該怎麼做呢?

學韓總機是個好辦法

PM 的任務是要規劃專案內的任務時間、分配工作,理想的 PM 需要熟悉使用者研究的方法、知道如何帶領討論、主持會議,對完全沒有經驗的人來說,真的很難,所以才該學一下韓國瑜,當不太熟悉研究方法、有點害怕主持會議、不知道該如何帶討論,就看看有沒有其他組員會的!

今天的實體工作坊是個觀察組員能力的好時機,因為平時大家都或多或少會吹噓自己的優點,隱藏自己的缺點, 所以看看實戰狀況就可以知道大家的能力值到哪裡。 工作坊後,大概可以了解每個人的特質跟擅長能力,到時 PM 只要做到好好地將任務分派給合適的人即可。

雖然現在的 GitLab issue 排起來有點災難,但有個起頭就是好事。期待下次跟夥伴的實體見面,到時應該有很多能討論的部分。


原文發佈於 Substack


#PDIS #專案管理







Related Posts

Laravel blade 基礎

Laravel blade 基礎

2020 COSCUP 感想

2020 COSCUP 感想

[ week 6 ] 前端基礎 HTML

[ week 6 ] 前端基礎 HTML


Comments