[PM系列 - 我做產品的日子] 專案經理的日常

- 專案經理的日常 -

好像掛個經理就很厲害

Hi, 我是史蒂芬, 

與接案公司配合, 是一個Freelance的專案經理.

主要的工作圍繞在:
- 與客戶洽談需求

- 與工程師講解需求

- 請工程師喝飲料

- 測試產品

- 跟客戶催款

- .......等等

以下我們分階段來說~

＊接洽＊

通常都是收到朋友的 一則訊息或是一通電話,

對方表示：有朋友有網站或是app的需求想要聊一下,

這時只會大概知道產品的輪廓跟產業.

通常會加一個群組來聊, 但是用打字來講解需求,會是一件很沒有效率的事情

往往都會約一個電話會議 or 見面聊.

=> 通常都是透過FB or Line 來做第一步的認識, 此時我會大概看一下對方的FB, 來推測他想做的產品跟他目前握有的資源是否相符合. 也可以在會議前有多一些瞭解

＊需求訪談＊

無論是透過電話會議或是面對面開會,

最重要的有三個重點：

1. 功能  2. 交期  3. 預算

瞭解客戶需要的功能, 才能夠規劃成tickets 給工程師估時,

知道交期, 才可以推估說需要幾個工程師一起進行,

最後由以上資訊,推估出此次產品的預算

＊開案＊

簽約後, 緊接而來就要開工了

透過 wireframe & userstory 來定義畫面跟功能

此時會有三個角色：
1. （業主）提供想法
2. （ＰＭ）確認需求, 文件化

3. （設計師）出圖

此時還不會有工程師的角色進來,

主要考量在於 畫面尚未定版的時候, 需求可能會修改

不論是前端工程師 or 後端工程師, 此時都可以會做白工

故不建議偷跑

＊與工程師 & 規則＊

當畫面以及需求都定義清楚了, 此時也大約有兩週的tickets的量

(兩週的tickets量, 需要知道工程師每週可以提供得時數, 以及他的預估時數來判斷)

就可以請工程師開工拉~

在開始討論之前, 要定義每週開會時間, 每週release時間,

之後就要開始解說本週的規劃

＊與工程師溝通的Tickets＊

撰寫 Tickets 有幾個大方向：

1. 單條時數不超過 8hr

2. 不同條tickets 時數可以合併報

3. 有畫面一定要附上畫面連結

4. 有檔案一定要附上檔案連結

5. 工程師可以提出修改tickets

6. 工程師可以留言

Tickets 主要是的用意在於溝通

每次我一定會帶工程師一起run過一遍tickets.

因為我的規劃可能會有缺失, 或是我的敘述工程師可能會看不懂

此時透過視訊會議, 來講解, 減少認知上的差異

＊每週測試＊

與工程師訂定的release 時間通常會早於與業主開會前兩天,

收到當天進行測試, 並且記錄哪邊需要修改

隔天與工程師開會, 如果不多, 請工程師解完之後rlease一版 fix 本週的進度

如果太多, 需要討論是否延到下週再relase 或是 過兩天解完release

＊業主開會＊

核對上週進度, 確認下週進度

這時候通常業主會新增一些需求, 視情況來調整進度

（但在需求新增的時候, 業主對於結案日,是不會改變的, 所以當下要告知, 這樣新增可能會影響到日後的結案日）

＊結案＊

依照合約的不同, 對於結案的定義也不同, 

如果是時數約,可能就沒有所謂的結案,因為就一直修改,但是每週tickets 量會下降很多, 

對於專案約, 我通常都是用兩次修改的表來規範結案,

順序是：

業主測試 > 討論內容(表1) > 工程師調整 > 業主測試 > 討論內容(表2) >工程師調整 >結案 

但這邊會遇到的問題可能是, 有些要調整的地方可能是架構上的問題,或是難以處理的Bug

這些都是要在結案前, 跟業主提醒的事情

～恭喜你, 完成了一個專案~

在接案蠻常遇到的事, 請神容易送神難, 很多時候接下一個案子到最後因為雙方的認知不同,往往鬧得不愉快, 業主可能會認為做得還不夠, 但PM會覺得客戶的任何需求都在凹, 此時都會是在於雙方有疑慮時, 要透過溝通來化解.

溝通是專案經理必修的課程

後續會針對個階段會有更詳細的分享啦~

敬請期待~