# 怎麼在 g0v 專案裡做專案管理

## 提案內容 2020.6.30

### 標題

牧貓人 —— g0v 混亂有序開放協作專案管理
Herding Cats –– Project Management in g0v Projects

### 摘要

來 g0v 提案許願就會成真？才沒那麼簡單，想走得長遠有影響力，需有對社會議題的理解、習慣開源社群鬆散的協作方式、做數位產品的產品開發、跨領域溝通。滿多專案隨時面臨人力、時間不足、無法說服利害關係人、開發方向不明等問題。當每個貢獻者都是獨立的貓時，該如何促進社群協作呢？

作為兩個長期提案的專案經理，我們將以環境倡議團體發起的 Disfactory 農地違章工廠回報行動，與嘗試居住新解法的 Rentea 社群為例，說明我們如何嘗試定義提案目標、釐清議題需求、定出可執行的具體項目、與開源社群協作開發、找到/運用手上的資源，從食物轉為程式碼的黑盒子中，提取專案管理的經驗和心法。

這次分享是另一個長期專案 #herding-cats 的開頭，開始訪談整理形形色色的 g0v 專案，具體來說是如何協作開發的，成為之後 g0v 專案的養分。

圖片來源：https://www.flickr.com/photos/ceardach/4549876293

### Abstract
"Herding cats" is perfect to describe project management in an open source project contributed by quite independent developers.

Civic tech adds an extra layer of complexity because you need to understand the contexts of social issues, to collaborate with diverse stakeholders with intense interdisciplinary communication. However, the project usually only has unstable contributors with limited time following unclear project goals. That is when you need to consider some project management in your projects.

We would like to share our journeys on open source project management in civic tech–– how to identify user needs, how to brainstorm solutions, how to determine project's scope, how to make a feasible development plan and how to sustain the projects with open source communities.

We hope this talk would inspire more civic hackers develop their projects in open collaboration with less struggles.

The two cases shared in the talk are Disfactory, a reporting platform on illegal factory on farmland, and Rentea, a project trying to create alternative for living in urban area.

---

===== 我是分隔線 ======

我們想透過工作坊，邀請想要用開源和技術介入公共議題的夥伴，分組模擬一次 g0v 專案開發生命週期中的坎，盡量貼近實際狀況。讓參與者了解，如何釐清專案需求和目標、如何發想可能的公民科技解法、如何定義專案規模、分工和時程。希望大家在參加後，不只意識到讓提案不簡單，也能知道需要具備哪些能力、使用哪些資源，來讓提案順利進行。

也歡迎大家在下方留言，提供可拿來練的案例，或是實際專案遇到的挑戰和困難來練習。工作坊也會整理開源專案產品開發的一些架構或是可以去思考的問題，引導參與者討論和做專案規劃。

### 其他
1. 形式
> workshop 120 min
3. 主題分類
> 「沒有人」的島 Nobody’s island
4. 三個關鍵字 3 keywords
> 專案管理, 產品開發, 開源協作
5. 相關專案資訊連結 Related projects / works URL
6. 主圖 Cover image
https://www.flickr.com/photos/ceardach/4549876293
> 這個授權是 CC-BY 2.0
8. 錄影、投影片是否以開放授權釋出？
> Yes

### 講者資訊

## 進行方式、想法

1. （根據上次討論），設定幾種常見的情境，給大家分組練習

> - 先預設好 1 ~ 2 個題目，但開放現場坑主提案，讓參與者自行選擇，最後保留前幾多人的提案，進行後續討論（所以需要 1~2 個預設提案的坑主）
> - 提案須為全新，尚未開始的狀態
> - 確定提案內容後，根據產品生命週期，提出常碰到的問題，介紹解法，並讓大家提出解法或方案
> - 主持人幫忙統整和收斂

### 情境收集

1. 提案週期規劃
- 在聽到提案內容後，討論出提案一個月、三個月、半年需要作到的事情，需要的人力，以及可以支持人力的資源和運作方式
- 目標：練習基本的產品規劃能力，因為開源專案人力常常分配不均
2. 討論授權
- 商業、非商業使用？允許分支？
- 出幾個狀況題，讓參與者討論該如何處理，並回頭決定該用什麼授權
- 目標：了解授權的意義與後果
3. 開源專案如何分工？
- 目標：開源專案沒有上下權力關係，參與者該如何面對要求，玩得盡興？
- 來參考個 [Github opensource guide](https://opensource.guide/)?

> [name=ael]

1. 黑客松提案完開始討論規劃
- 授權、協作的方式，例如開 cowork space
- 這邊可以引導以黑客松當天、一個月、半年、一年的角度思考。Blupa? 什麼時候要做完？
- 盤點人力：你需要怎樣的人？
2.

* 黑客松超展開錯方向
* 黑客松過於糾結技術細節，而沒有去想到 big picture and innovation
* 實作能力不夠、程度落差太大
* 參與者很忙沒時間，進度 delay
* 或者是有人要離開，交接的時候 => 可是不是通常就是寫文件
* 或者是有人很想幫忙，但找不到可以幫忙的地方
* 開發過程中，開發者跟被議題影響的人還有使用者很遠
* NGO 和政府聽不懂我們在幹嘛：包括開源文化、技術名詞和思考、數位能力、啥米是社群
* 要怎麼分工：誰適合做什麼？誰要跳出來說誰要做什麼？要怎麼把工作切開？有些無聊的事情沒有人想做。要怎麼判斷大家的程度？
* 要怎麼決定專案的 scope 、model 和技術架構（要用什麼樣的方式呈現和真的程式的技術架構）
* 專案做不下去怎麼轉型？
* 沒有人用？

提案前怎麼先偷跑、準備
> 怎樣準備一個好提案去黑客松？ => 再推坑別人投稿

要適時 call out: 專案核心參與者以外的社群參與者可以幫到什麼忙？leverage 社群的資源 => 可以給 Call Out 卡或是 Call Out 機會

> 覺得要再現黑客松當天的情境比較簡單，但是要經歷後續專案會遇到的問題比較難

### 提案收集

TBD

### 提案類型

其實提案也有分不同類型，但 ddio 還不確定該怎麼處理這件事

1. 作興趣，有機會就作一點，但沒有死線的隨性專案
2. 組織提案，有明確目標，但不懂技術的專案
3. 目標較大，想要改變其他人、組織的專案

（懂技術的人最後還是要懂議題）

只能處理一種，然後看不同組對同一個提案和 challenge 會採取的處理方式有什麼不同 => focus 在 2

做的不是技術上的創新，是怎麼做這個議題的創新。
去想像科技可以為這個議題帶來什麼樣的新的可能

1. ~~理解議題~~
==1. 釐清需求、目標==
==1. Brainstorming possible solutions==
==1. project planning: timeline, scope, 分工==

==怎麼在開源專案裡做專案管理==
要給 framework 嗎？哪些問題是要被回答的？
用 PM 101 的資源來做 workshop
定義產品和執行
e.g. 有一堆功能許願卡，然後要大家來排 prototype、MVP 需要做到什麼程度，或是要考慮什麼東西。排 backlog 的 priority

會用一個提案做例子
1. 分組釐清需求和 brainstorming
2. 針對同一個專案狀態遇到的挑戰，試著提出解決方案？

讓大家走過一遍，盡量貼近實際狀況

可以在提案裡開放大家提供可拿來練的案例以及挑戰或是困難。

### 預設參與者

1. 不知道怎麼提案或是提案後怎麼繼續做的人（新參與社群的人）想要用技術介入公共議題的人
2. 工程師、設計師等，有技術專案參與經驗的人 => 聽到提案後來參加的人
- 但也可能技能樹和專案不合
2. 議題背景，議題工作者、公務員等，對議題了解，但不一定知道怎麼作數位專案的人

### 目標（參加完之後）

低：要提一個案子沒有那麼簡單。有很多需要注意的地方
中：要知道哪邊不簡單
高：知道要怎麼解決這些問題（自己解決或找人或找方法）

### Misc.

> poga: 什麼時候開始在 open source project 會出現 PM 這個角色？ g0v 的專案通常是在很 early stage 的東西。
> ael: 越來越多人對 g0v 專案有長期影響力的期待
> wildjcrt: @poga 長期專案需要 PM，不然會連核心成員都難以工作。
>

### 0801 Summit BoF

1. 三種專案類型
- 自己題自己寫程式
- 自己個人提，自己 PM ，但做出
- 組織提，有人 PM 東西做起來

### 20201012 討論

Session TA: 對懂技術的人講如何做出 open source civic tech project ，怎麼幫別人 run 專案（？）
- 地點在好想工作室，應該會比較多科技人
- 不太理解軟體開發的人請去早餐大叔團（？）
- 怎麼想產品開發、長期運作
- 想做的人少走點岔路？
- 最後提供 Takeaways + Checklists

### 20201019 討論大綱

Slide: https://docs.google.com/presentation/d/1Oy73yGxv9dNkQZdcd13RvIAdxawuD7rRikVyGWYDjUM/edit

#### Audience

1. 沒有開源經驗，但對廣義的公共事務有興趣的技術人
- 開源，如何作為公共與技術的橋樑
- 橋的樣子，開源可以是什麼形狀
2. 我們這場特別可以說的
- 需要專案管理的橋，怎麼開始，為什麼，各種問題的解法
- 中階議程，基礎知識給連結，自己看
- 故事是，我們想要做一件事了，對某個專案有興趣了，然後呢？

#### 簡報大綱

> 議程說明：
> 想走得長遠有影響力，需有對社會議題的理解、習慣開源社群鬆散的協作方式、做數位產品的產品開發、跨領域溝通。滿多專案隨時面臨人力、時間不足、無法說服利害關係人、開發方向不明等問題。當每個貢獻者都是獨立的貓時，該如何促進社群協作呢？

- 自我介紹
- ael/Disfactory
- ddio/Rentea
- 為什麼要用有 PM 的社群來作開源專案？ @ddio
- 專案不是工程師驅動，而是由設計或議題驅動
> 舉例，以及說明工程驅動 vs 議題驅動的差別
- 想做到的事情，複雜問題，需要多人合作才做得到，程式上，或跨領域合作上，需要有人搭橋
- 不只想要完成專案，也想要長一點人的支持網絡，可能是對議題的共同興趣、實踐某種價值（開放協作、合作運動、民主），或是日常生活的支持
- FLOW
> 該來幫每個階段都下個小標
> 每段都該有個小結（？）[name=ddio]
- Discover user needs
- 理解社會議題的脈絡、應用情境、利害關係人 @ael
- Identify problems & Brainstorm solutions / 釐清問題，發展解法
- 從問題到形成開源專案，需要轉譯和對焦能力
- ~~從「為了租屋者設計的找屋工具」到「用開放的資料，為了租屋者設計，由租屋者參與製作的找屋工具」，從「為什麼找屋工具都不是為了租屋者設計」出發，把資料、爬蟲、法律、設計問題，轉為解決方案 @ddio~~
- 以 Disfactory 後台開發為例，如何決定要有哪些欄位與功能和使用哪個平台 (最後的 spec 要 merge 三個版本好崩潰喔) @ael
- Scope, feature and their priority / 在開源社群長出開發期程
- 軟體架構x開發順序，確保每步都有可驗證的東西
- Rentea 怎麼切出軟體架構，和決定先做什麼 @ddio
- ~~Disfactory 怎麼切出功能開發架構，分別怎麼決定技術 @ael~~
- yellowsoar 對於兩個專案技術架構的顧問服務 @ddio
- 資訊公開，建立主動+被動的知情管道，確保共同討論，才能順利分工 @ddio
- 怎麼確定來的人真的可以說到做到？！！
- 把工作切小，做之前先討論，確定參與者夠懂技術，確定一件事情不會只有新手負責 @ddio
- 一個不會技術的人到底要怎麼判斷呢？？？？ @ael
- Issue tracking & milestones / 敲出開放參與的節奏
- 用文件x實體小聚協助新參者入門 Hackfoldr + README @ddio
- 人員流動中的 milestone 意義：讓大家有比較短的 commitment period，可以每一階段 commit。也可以對產品有 vision。 還有私下談需求的時間。@ael
- ~~怎樣的節奏才是舒服的、非同步協作：資訊公開與回饋。~~@ael

- Impact & Evaluation / ？
- metrics 和倡議時程配合 @ael
- retrospective meetings => 所以參與者在意的是什麼？什麼可以做得更好？哪些是大家不希望踩的雷？@ael
- Sustainability
- 新血(招人跟把人留下來都好困難) & sunset plan @ael
- 轉型成 Rentea Tuesday @ddio
- 公開決策，讓社群有機發展，先於專案完成

- 開放的社群文化
- 沒有權力結構的情況下，要建立其他的參與者成就機制，才能協作 @ddio
- 權責得相符，可以給出長期承諾的優先，無論人還是技術都是
- 以程式架構、爬蟲流程、專案轉型為例
- 管理專案的同時，也要製造大家喜歡的回饋
- 新手友善環境、個人發展
- 建立團隊信任 & Engagement：讓實際貢獻的人被看到，要去把 credits 寫出來
- credit - 四週報、小聚貢獻者
- 協作之外，要抓緊自己該承擔的責任 @ddio
- PM 必須切出工作，長工作的優先順序，自己不做，沒人會做
- 但做了後，需要開放討論、思考的空間，讓人理解之外，也增加參與感
- 參與者可能會不好意思做決定，這時候就要當作決定的人
- 從自己開始的，可以適時放手
- 專案應該是屬於大家的，把工作交給願意承接的人
- 大家一同成長 @ael
- 培力 NGO 的數位能力和開放協作 => 線上工具、產品思維
- 個別參與者的個人成長與動機 e.g. 練 GIS 技術、社群感、需要作品集、轉職、議題

- Takeaways
- 以人為主，還是以事為主？ @ddio
- 如果開源專案想要落地，終究得回到人身上
- 開源專案往往由事開始找人，但透過開放參與、維護開源精神，要能維持專案的開放，就得回到人，無論是開發者還是使用者
- g0v 專案需要 PM 嗎？stitcher + 潤滑劑，保持開放性 @ael

#### ael 自我 murmur 區：

便利貼內容：
- 怎麼長出核心的人長期貢獻
- Scoping、分工
- 新人 onboard 與社群更新的成本
- 參與者的成長與參與動機
- 開源文件、基礎建設
- 跨領域 domain knowledge: e.g. 倡議、技術、法律
- 坑主幫手、專業顧問？

- 自我介紹：
- 非技術背景 => 所以我是一個無法自己把東西做出來的人
- 常常在做對焦和轉譯
- 協助已經有需求的坑主轉化需求成可以執行的專案
- 但上一個產品做死了（？）
- 專案性質：
- Blupa 量表？
- 為何需要專案管理？不是所有專案都需要 PM
- 專案生命週期？
- 不同專案的本質（有沒有時限、有沒有組織、坑主的背景）
- 公民科技專案與一般軟體開源專案的差別 // 原本應該是想講要注意社會議題的部分、context/network、跨領域。不能只把技術的部分顧好
- 如何開始：
- 人
- 問題
- solution scoping
- （文化）
- Disfactory 專案介紹
- 專案 stage
- 人數分工
- 目前專案成果
- 問題是什麼、怎麼做？不是黑盒子（need-> identify the problem-> brainstorming solutions -> scoping -> feature-> spec-> ticket-> verification）
- iteration
- 分工架構
- 怎麼拆問題到每個階段都可以驗證 @ddio 比較技術的
- 誰來做？人: individual -> team @ddio
- 非同步協作
- 動機
- commitment ：怎麼把人留下來？
- 要能夠轉動需要怎樣的角色和人才？怎麼找人？
- 自己在專案中的角色：PM 的角色？顧問的角色？
- 怎麼合作溝通？ on the same page @ddio
- 開源文化、公開協作，如何轉化不熟悉開源文化的人？
- 會議記錄
- 開發文件
- 怎麼推進專案進度？Time management:
- milestone
- 進度與留人的拉扯
- 細到怎麼分工
- 跨國合作
- 為了什麼而做？（目標：倡議目標）
- metrics
- How to define success?
- 需要注意到數位服務只是整體倡議目標/服務中的一個環節而已
- 培力/賦能
- 想去看 Red Hat 的 open source project health metrics
- 專案生命週期（？）
- sustainability
- sunset plan
- maintain
- 未來想做和改善的事？
- 不要讓自己成為 bottle neck
- 能夠換血 maintain
- growth

回到一年前會跟自己說的話？最想重來的事情？
- 可維護性
- 最小力氣: 為什麼不改其他開源專案呢？
- 容易持續轉動的東西
- 有沒有更簡單的解法？
- 怎麼讓新人 On board 快速理解議題又理解技術架構
- 工程師能夠參與功能設計更多？
- 國際化？英文
- suvival mode

想分享的秘訣？

> 哪些東西應該要放到跟小海的那一場？倡議目標？議題理解？開源文化？

R：
挑戰？
組成的人？
沒有參與過 g0v 經驗的人？會不會有很排外的文化？
//其實是有沒有寫過開源專案有差，開源的默契、公開透明、公開 channel，不想成為 bottleneck
怎麼居間協調摩擦與
自動東西被做完了、或是東西沒辦法被做完
怎麼讓不同文化的人協作

M:
人力資源不穩定
資訊如何 sync?
如何讓大家非同步協作參與

程度不一的時候進度怎麼辦？

##### References:

- https://github.com/github/opensource.guide
- https://www.redhat.com/en/blog/12-factors-measuring-open-source-projects-health

#### ddio 自我 murmur 區：

##### Audience

1. 沒有開源經驗，但對廣義的公共事務有興趣的技術人
- 開源，如何作為公共與技術的橋樑
- 橋的樣子，開源可以是什麼形狀
2. 我們這場特別可以說的
- 需要專案管理的橋，怎麼開始，為什麼，各種問題的解法
- 中階議程，基礎知識給連結，自己看
- 故事是，我們想要做一件事了，對某個專案有興趣了，然後呢？

##### 想提的點

1. 為什麼要用有 PM 的社群來作開源專案？
- 想做到的事情，複雜問題，需要多人合作才做得到，程式上，或跨領域合作上
- 不只想要完成專案，也想要長一點人的支持網絡，可能是對議題的共同興趣、實踐某種價值（開放協作、合作運動、民主），或是日常生活的支持
1. Rentea 2019
- Chloe 的聯繫，提案「為了租屋者設計的找屋工具」，想討論下一步
- 轉化問題，「用開放的資料，為了租屋者設計，由租屋者參與製作的找屋工具」
- 提到一點點工程、法律上的複雜度
- 簡單說明幾個專案的轉折
- 5 月第一次提案
- trello + slack 自介、整理大家專長
- 6 月第一次四週報
- 07-11 第一次線上小聚，程式架構、開發流程確定，小聚頻率確定
- 7 月第二次大松提案，聊設計、程式專案開發
- 8 ~ 10 三次小聚
- 11 小聚，討論轉型
- 提一下做出來的東西，包含法律、爬蟲、設計、文件、新手教學、小幫手、NPO Hub 租賃 SOP
- 幾個想分享的秘訣：
- 怎麼在沒有權力結構的情況下，讓參與者達成共識，一起分工
- 權責得相符，可以給出長期承諾的優先，無論人還是技術都是
- 資訊預設公開，提供主動與被動的知情管道，讓所有人可以參與決策
- 以程式架構、爬蟲流程、專案轉型為例
- 管理專案的同時，也要製造大家喜歡的回饋
- 四週報，給 credit
- 新手友善環境、個人發展
- 協作之外，要抓緊自己該承擔的責任
- PM 必須切出工作，長工作的優先順序，自己不做，沒人會做
- 但做了後，需要開放討論、思考的空間，讓人理解之外，也增加參與感
- 參與者可能會不好意思做決定，這時候就要當作決定的人
- 從自己開始的，可以適時放手
- 專案應該是屬於大家的，把工作交給願意承接的人
1. Rentea 2020