您好，沒問題！（也有收到您臉書的回訊，我一併回復在這邊）

文章發布後請告知網址，我會於原文標註轉載並互相連結。謝謝您。

剛剛在瀏覽您網站時，看到您撰寫的《從臉書產品經理的一則貼文，探討軟體開發的流程與分工問題》這篇文章，很適合科技島讀者。
不知您是否願意授權我們以『原文原PO，並註明原文作者及出處連結』的方式讓我們轉載於科技島網站，跟科技人一起分享呢？謝謝。

靜待回覆！並附上科技島網站連結，給您參考 :
https://www.technice.com.tw/
聯絡Email:
techniceeditor@gmail.com

Thank you for sharing the good post! I like what he said in key points below, and it’s related to my recent experience!

– PMs are responsible for the outcomes of the team; the inputs are subjective. Your goal should be to find the best combination of inputs to maximize the outcomes of your team.
– The more senior a PM you become, the more impact you can have with strategy. Freeing your own capacity while not allowing outcomes to suffer requires meta-execution.
– But regardless of your delegation abilities, you will stay accountable for execution.

需求不清楚這件事，終歸要回到「需求」本身。其實不管是不是接案公司， PM 都很常被問「為什麼要做」，而我們的工作確實就是該解決這個疑慮，才能推動人去產出。

情況一、 上級逼我做

如果是成熟的工程師，其實我會直接告訴他，這個是公司或上級決策，而我找不到數據或其他證據說「做了會不好」。既然沒有 downside，那就試試看，畢竟有些 business insight 可能是產品端看不出來的。如果秉持著敏捷的精神，在迭代很快的情況下，試一試無妨。

當然，我也會在該階段就跟工程師或設計師討論清楚，如果做了成果真的不好，之後可能有哪些調整方向（藉此來決定東西要做多死或多彈性，也讓他們知道這可能是個中長期的工）

情況二、 發案端的需求不明確

這個就很仰賴窗口的溝通囉。其實我的商務/行銷也會發一些假設需求，我自己當商務時也會提給 PM 需求。
理想來說，PM 接到需求後，到合約簽定或真正決策前，不會照單全收。因為 PM 一定要搞清楚「這個需求背後想達成什麼目標」以及「衡量的指標」。
如果對方沒有指定作法，那作法就跟工程師討論（只要抓緊目標就好）。但若對方指定作法，就看工程上有沒有什麼困難，再討論執行方法。或者，用一些不花工程時間的方式作 a/b testing，效果貼近需求，再進工程。

但話說回來，這樣來回溝通的時間成本很高！因此遇到不明確的發案端，經驗感覺「要討論很久」時，更要講清楚時程跟預算。

我以前跟某A 百貨公司討論 APP 開發案時，對方先是說三個月內要做一款 EDM 型的 APP，當時估完覺得加上一些小功能，合約簽訂後三個月內可以用四人團隊搞定。
結果後來對方又說，想改成 3 個月內做一款跟 B 百貨一樣的 APP，要有會員系統、線上結帳、還有可以管控的後台，最好還要有線上金流。
這下時程跟人力規模就完全不一樣了。

假設你或工程師主管經驗豐富，應該能就這個案子拆解一個可行的方案，比如三個月內可以做到什麼程度，然後驗收要分期，明確說明哪些東西可能要第二期交付（比如 3-6個月時出第二版帶金流功能）。

公司想賺錢，會想要什麼都接，但如果前期不先談定比較合理的產出，那下到執行層一定會有很多怨言。
而假如你覺得自己不是最理想的人月／資源評估者，一定要多問問其他有經驗的人。如果可以，多問一點，比如「這個功能要做三個月，是涵蓋到什麼程度？這個東西可以拆做，分不同時間 delivery 嗎？還是一定要三個月才能做完？做完是包含哪些功能？」這樣如果發案端不滿意評估的時程，你還有拆期程去分期交付的機會。

記住，你是 PM 的話，最重要的事情是釐清原因跟需求優先級，講清楚交付的可行性。然後，你要為這個結果負責。

情況三、 團隊成員不理解/不支持你
最後，工程師越資深、越成熟，通常越能理解上層或PM的難處（有些東西確實就是沒道理），這些有賴 PM/工程師日常多多互相理解。
但話說回來，不是決策者的人，不應該有「這需求不夠好所以我不做」的心態。若該員不是專案負最終責任的人，那他的義務是「提出潛在風險」並跟PM合力擬出「可行的解法」，而不是就「不幹了」。
如果真的遇到這種人（不管是工程師還是其他職能），直接找上級主管協調可能比較快，或是約對方1:1面談，釐清真正的問題是什麼。

竹下隆一郎在書籍《不善社交的內向人，怎麼打造好人脈？》曾經說過，人的煩惱分為「白宮煩惱」跟「咖啡廳煩惱」。前者是人生永恆的重大課題（比如戰爭怎麼消失、經濟怎麼成長），後者則是跟家人朋友會聊的生活煩惱。
如果成員不斷質疑「這個功能做下去超沒用，會傷害公司商譽」，但客戶或主管就是堅持要，有時候不妨就直接跟成員說：「等你成為出錢的人，再來煩惱做下去會不會妨礙商譽吧」。

以上淺見，希望有回應到你的問題。