# 專案管理從0到1：從點子萌發到落地上線的辛酸血淚

時間：2023/09/27
地點：資訊系館 4202
講者：盧淑君 Anita Lu
* [共筆連結](https://hackmd.io/@yeeway/gdscncku0927)
* [活動頁面](https://gdsc.community.dev/events/details/developer-student-clubs-national-cheng-kung-university-presents-gdsc-ncku-she-ke-zhuan-an-guan-li-cong-0dao-1/)
* [簡報連結](https://www.canva.com/design/DAFur_F6-IA/9iYZ_qbbyLRoG6Q5E2fLog/view?utm_content=DAFur_F6-IA&utm_campaign=designshare&utm_medium=link&utm_source=publishsharelink&fbclid=IwAR07D4AncL2G0HcUYOl0ZR7cvepISR22MIVnhAufyYSJKEwullQR7D7t-QQ)
* [相簿連結](https://photos.app.goo.gl/3BEUmKMMqp4qLjxPA)
* [錄影連結](https://youtu.be/5QqdFJlTAKY)
* [延伸資源](https://hackmd.io/@anitaLu/SJEzF8kep)
---
## 開發流程

NCKU PASS串連講師個人修課經驗
* 初次摸索
* 以工資系的系統分析與設計為基礎
* 提供校方檢視學生數據
* 遇到的問題：在開發階段還要改需求！會造成前後端嚴重負擔

* 二代開發
* 實際摸索後遇到困難
* 加入行銷，優化功能 增加使用率
* 發現一開始亂畫的流程圖，有點像設計思考的三個鑽石
* 最後發現其實沒有做到最後一個鑽石
* 進入業界後發現最前期的準備與最後收尾沒有做得很好

Three diamond 開發流程：
1. 需求調研：需求探索+定義問題
2. 設計迭代：設計展開+原型
3. 場域驗證：設計測試+實踐

關於專案，我們可以融合上面各種方法，並這樣做：
1. 專案準備
3. 專案目標定調
4. 設計迭代
5. 開發具體實施
6. 最後準備(部屬)

## 專案帶領

> 你自己，是誰？
首先，要知道專案經理的目的和角色是什麼？
包含前期的準備、方向，中期確認進度掌握中、風險和應對解決。

> 如果專案經理也要參與開發的話，其實也要考慮一下，畢竟專案經理的loading 也滿大的。所以如何賦權跟指派任務也很重要

### 一、專案目標設定
你會想要帶領團隊去哪裡？
不能光是自己想，要考量團隊需求、想法
1. 專案確認：大流程時程、訂出大主題方向
2. 組成專案小組：了解大家的強項，弱勢、雷點，釐清各自目標，設定共同目標
* 例如知道自己有任何風險或是為難的話，可以先提供給團隊知道
* 讓團隊的風險降到最低
4. 專案啟動會議：召集利害關係人
::: success
如何設立**共同目標**？ 以講者自身經驗來說
1. 提升經驗、作品集
2. 想認真做到上線並實際使用
3. 可以直接創業當老闆
考慮的範圍越來越大，而不是只有自己
:::
成就感、歸屬感 都是專案管理的重點，有時候維護一個團隊，比做好最終的結果還難！

>時程有限盡量小題大作：野心不要太大，要從大家有興趣的點出發！

**以ncku pass為例：**
校方痛點：檢視學生的活動歷程，學校想知道學生到底在做什麼學什麼
學生痛點：想要把專案做上線
因為校方的需求難以滿足，成本過高，最後才改成現在的Ncku pass

點子發想：
* 可以以現有的專案，加上某個特殊的想法
* 如果AAA加上BBB，
例如交友軟體+AI->Alnimal
* 或是從一個痛點、需求、癢點（想成為的樣子）或疑問開始
* 也可以跟學校or其他店家談合作~
學校其實有蠻多東西想作，但找不到學生合作的
例如教發中心就有很多

### 二、專案目標定調
發散完了，可以收斂回來！

* 收斂工具：Persona、使用者經驗流程圖、心智圖
* 問題定義公式：HMW 我們如何能 幫助＿＿＿人，解決＿＿＿＿問題

### 三、設計迭代
1. 設計展開：brainstorming/ 水平思考法 : 包含「六頂思考帽」、「概念扇」、「抽絲法」等思考工具
2. 設計原型：低擬真->高擬真 MVP
3. 這邊偏向設計師的專業，PM不用全部栽進去做

### 四、開發具體實施

這邊就讓各自做各自的工作就好，不用規劃的過於細緻，大家會瘋掉

### 五、最後準備
1. 場域驗證：情境確認、主流程與例外流程
2. 壓力測試
3. 收尾：
4. 結案報告/作品集/分享會

推薦的個案分享： [eyebus](https://www.eyebustw.com/)

## 風險變數
其中一種風險的可能性來自不同領域的溝通落差，每過一手都有可能造成資訊落差
e.g. 專案目標到設計師，設計師到工程師、團隊到客戶
### 調整規格
調整規格非常耗費成本，如何避免？
1. 需求分析上越縝密越好
2. 專案規格書寫清楚
3. 需求提供優先順序，讓工程師優先解決某些項目
* 重要度(使用者或專案進程)和解決難度去排序

推薦文章：[如何撰寫產品需求與規格文件？給產品經理的問題、心法與實作小撇步！](https://medium.com/3pm-lab/how-to-write-product-requirements-document-5860260716c2)

### 專案範疇
堅守專案的開發範疇，不然客戶會一直要東要西的