Re: [討論] 大家覺得PM需要有技術背景或會寫程式嗎？

看板Soft_Job作者 (重出江湖)時間4年前 (2019/11/10 10:45), 4年前編輯推噓34(34推 0噓 89→)
留言123則, 36人參與, 4年前最新討論串5/6 (看更多)
我覺得這問題答案是「有技術很好，但沒技術也沒差」 不管是產品經理、專案經理都是PM 他們專注的點本來就該是在產品功能跟需求本身 會技術當然有助於他們可以比較明確的評估「這做不做的到」「做這個要多久」 但沒技術就不能當好PM嗎？也未必 重點還是PM能不能幫忙擋需求 說服User天馬行空的幻想 懂得安撫RD 當起User跟RD之間的溝通橋樑 這才是PM該做的事 如果PM不能夠站在RD的立場 那PM會技術搞不好更糟 「我也以前（十年前）也是有寫過程式，這個應該很簡單」 「我以前也寫過類似的功能，給你一天的時間應該夠吧」 （但可能環境的不同時間要更多） 遇到本來就不懂技術的PM你可以安慰自己人家就是沒寫過程式 但遇到這種寫過又喜歡把以前經歷套用到現在的PM你拳頭才真的硬到不行 所以我認為PM應該還是專注在產品功能面上 當然可以去試著理解專案用到的架構與技術特性 但做這些事目的也是為了要在與User談判時 提高對於需求的可行性以及時程預估的準確性 但最重要的還是PM能否擔任與User之間的溝通橋樑 這才是PM在團隊中最重要的任務 ※ 引述《annedoo (安安)》之銘言： : 大家好，我本身是產品經理、專案經理都做過的PM， : 大學念的科系名字裡有個「資」字但非本科生， : 好奇身為軟體工程師的各位，認為PM到底需不需要是技術背景、甚至會寫程式呢？ : 我大學的時候也有程式設計的課， : 但就是在那時候發現自己寫得不快、寫得不好、也沒興趣，所以很挫折， : 因此覺得這輩子絕對不會做跟寫程式有關的工作！ : 最近突然看到一個粉專（我是PM，有興趣自己查，他們來板上發過文）， : 寫了篇文章說明為什麼PM需要有技術背景： : （以下不完整節錄） : 作為一個技術出身的 PM，我會建議產品經理們真的要懂一些技術。更準確來說，PM 要懂的不是技術，而是用技術解決問題的思維。這樣不僅可以幫助 PM 更好的和 RD 溝通，也幫助 PM 從更多面向思考如何解決用戶需求。 : 　 : 什麼是技術解決問題的思維，我們可以簡單理解為四個要素：前端、API、後端、資料庫。 : 　 : 舉一個最常見的需求：用戶註冊。以四個要素分別來看的話可能會拆解成如下步驟： : 　 : 1. 前端：用戶輸入註冊資訊並送出 : 2. API：接收用戶資訊，傳遞到後端 : 3. 後端：驗證註冊資訊是否合規，處理資料格式 : 4. 資料庫：於 users table 寫入用戶資料 : 　 : 接著可能還會需要回傳對應的結果並展示在前端等等，我們這裏不作討論。這樣分解下來，每個技術環節分別要做什麼就十分明確了，RD 腦內也能開始把這樣的邏輯轉化成程式碼。 : 　 : 那 PM 對於技術該懂到什麼程度呢？越多越好。如果一個 PM 技術力越強，RD 就會對你越尊敬。一來他們知道你跟他們有共同語言，是跟他們站在一起的；二來他們也知道，若不接受你提出的需求，你完全可以跳過他們自己動手。 : 　　 : 最後也是最重要的，PM 如何提高技術能力？ : 　 : 1. 向 RD 學習：回到開頭的情境，有的 PM 可能會在被 RD 拒絕後灰心喪氣，甚至直接怒言相向，但這其實是一個鍛鍊技術思維的好機會。這時候我們可以根據上面的四要素，來和 RD 溝通是哪些環節碰到問題。對於實現不了這件事情，是因為現有架構的限制，還是說超過了技術本身的能力。於是，RD 可能會如此回覆你：「因為資料庫裡沒有這個欄位，我們也就沒辦法展示在前端給用戶看」，這才是真正的原因。一次兩次後，你會發現問出笨問題的頻率越來越低，你越來越常幫 RD 們擋下技術上不合理的需求，團隊的關係也會變得更緊密。 : 　 : 2. 動手寫程式：要鍛鍊技術能力最好的方法莫過於自己動手寫程式了。其實寫簡單程式並沒有太難，不需要買很多書來看，不需要懂計算機概論，只需要在 Youtube 上找些簡單的教學來看，然後訂一個題目來實作就行。 : 　 : 簡單開始的幾個步驟： : 1. 完成開發環境的建置 : 2. 瞭解變數宣告、if/else 判斷及 for/while 迴圈等基本語法 : 3. 完成一個「Hello world!」 : 4. 完成一個小題目：例如 To-Do-List : 　 : （以上不完整節錄） : 1. 不知道大家認不認同這個文章的想法呢？ : 2. 在自己的經驗中，PM有/沒有技術背景造成了多大的差異呢？ : 3. 在了解技術這方面，有什麼可以給軟體業產品經理、專案經理的建議XD : 我身邊有/沒有技術背景的PM都有， : 私心認為兩種都可以做得很棒，在團隊內部可能也會是不同的定位取向， : 不過自己說不準，感覺還是要合作最密切的工程師大大來分享比較實際～ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 150.117.240.188 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1573353915.A.CD8.html
→
11/10 10:55, 4年前 , 1F
但是PM不懂技術怎麼知道USER提得是天馬行空的幻想?
11/10 10:55, 1F
首先 User想的到的需求基本上RD一定做的出來 因為User提需求必定是從他個人過往經驗 或者是目前系統上他覺得沒有的東西來跟你許願 但重點是「做這個功能的目的是什麼？」「做這個是為了要解決什麼問題？效益多大？」 「真的有需要這個需求？」「是不是有更簡單的方式達成User要的東西？」 這些問題的探討都不太需要什麼很深的技術底 就純粹需求面的討論 PM應該要先確認需求的必要性 因為有時候就真的只是User自己想到 這功能也沒說非要不可 PM口才夠好的話也許就能說服User這需求其實沒必要 當然現實中未必那麼順利 真的沒辦法說服那就是帶回去跟RD討論評估可行性以及所需時間 或者是跟RD討論有沒有其它替代方案 之後再跟User繼續釐清跟說服 除非每次開會就要馬上決定 那頂多就是帶一個Tech Leader或者是資深的RD去開會 ※ 編輯: aoksc (150.117.240.188 臺灣), 11/10/2019 11:12:00
→
11/10 10:59, 4年前 , 2F
不懂技術的PM不一定是差的PM，但是上限就是比懂技術的低
11/10 10:59, 2F
→
11/10 11:01, 4年前 , 3F
當然秀下限的就不論了，半瓶水響叮噹是自古皆然
11/10 11:01, 3F
推
11/10 11:20, 4年前 , 4F
有些狗屁不拉雜的PM 完全不考慮團隊技術能力的滿足客戶腦補
11/10 11:20, 4F
→
11/10 11:20, 4年前 , 5F
做出來爛東西後責任全部是RD 的而這種PM卻活的好好的
11/10 11:20, 5F
→
11/10 11:20, 4年前 , 6F
然後平常只會嘴責任他扛 這種PM被fire掉才是大快人心吧
11/10 11:20, 6F
→
11/10 11:23, 4年前 , 7F
就是一堆沒有專業的課程不斷教導PM不需要技術
11/10 11:23, 7F
→
11/10 11:23, 4年前 , 8F
才造成台灣軟體一直沒有很強的原因 因為溝通層很弱阿
11/10 11:23, 8F
→
11/10 11:23, 4年前 , 9F
然後又一直強調PM有PM的專業
11/10 11:23, 9F
推
11/10 11:35, 4年前 , 10F
這就像是交響樂團的指揮不會樂器樂理一樣
11/10 11:35, 10F
→
11/10 11:35, 4年前 , 11F
怎麼可能聽的出來音樂的差異
11/10 11:35, 11F
推
11/10 11:52, 4年前 , 12F
想到前陣子對岸很紅的：根據手機殼顏色變換手機背景
11/10 11:52, 12F
推
11/10 12:06, 4年前 , 13F
所以指揮有指揮的專業，他不用跟樂器的人比樂器專業，
11/10 12:06, 13F
→
11/10 12:06, 4年前 , 14F
樂理本來就是指揮必須要會的專業。
11/10 12:06, 14F
推
11/10 12:13, 4年前 , 15F
不會指揮的人，樂器再厲害也當不了指揮。這不就是各有各
11/10 12:13, 15F
→
11/10 12:13, 4年前 , 16F
的專業？
11/10 12:13, 16F
→
11/10 13:17, 4年前 , 17F
如果遇到不懂技術 又自以為這功能很簡單 然後跟客戶簽完
11/10 13:17, 17F
→
11/10 13:17, 4年前 , 18F
才回來報工時跟壓交期的呢？
11/10 13:17, 18F
推
11/10 13:52, 4年前 , 19F
11/10 13:52, 19F
→
11/10 14:00, 4年前 , 20F
指揮不用比演奏的人還會演奏 但指揮要完全不會演奏
11/10 14:00, 20F
→
11/10 14:01, 4年前 , 21F
一種樂器是不可能的 一堆垃圾PM完全不會寫程式
11/10 14:01, 21F
推
11/10 14:44, 4年前 , 22F
洋鄉民的討論 https://bit.ly/2NZX1GH 參考看看
11/10 14:44, 22F
推
11/10 14:51, 4年前 , 23F
PM跟RD的專業有部分交集，沒把交集以外的部分補完，如何
11/10 14:51, 23F
→
11/10 14:51, 4年前 , 24F
做好一個PM?這不就是各有專業?
11/10 14:51, 24F
推
11/10 17:40, 4年前 , 25F
你們公司都沒Architect?
11/10 17:40, 25F
推
11/10 18:28, 4年前 , 26F
架構師在交響樂團的角色叫做作曲者
11/10 18:28, 26F
→
11/10 18:28, 4年前 , 27F
和討論中的指揮與樂器有段距離
11/10 18:28, 27F
推
11/10 18:33, 4年前 , 28F
Architect是RD升上去的工程職好嗎....
11/10 18:33, 28F
→
11/10 18:36, 4年前 , 29F
工程師 -> 資深 -> 主任 -> 架構
11/10 18:36, 29F
→
11/10 19:09, 4年前 , 30F
主任聽起來很傳產
11/10 19:09, 30F
推
11/10 19:23, 4年前 , 31F
主任就是principleㄚ
11/10 19:23, 31F
→
11/10 19:23, 4年前 , 32F
pal啦
11/10 19:23, 32F
推
11/10 23:08, 4年前 , 33F
這版大多是RD，用RD看天下，不懂管理一直糾結技術，完全沒
11/10 23:08, 33F
→
11/10 23:08, 4年前 , 34F
搞懂何謂PM。你這篇真的很委婉了哈哈
11/10 23:08, 34F
推
11/10 23:34, 4年前 , 35F
可惜台灣一堆PM根本不懂管理^^ 簡直就是欠嘴
11/10 23:34, 35F
→
11/10 23:35, 4年前 , 36F
一堆PM PM看天下 自以為多會管 然後在那炫耀自己多閒
11/10 23:35, 36F
→
11/10 23:35, 4年前 , 37F
快笑死
11/10 23:35, 37F
→
11/10 23:37, 4年前 , 38F
為什麼大多RD對PM有這印象 好好反思一下 別再縮在同溫層
11/10 23:37, 38F
還有 45 則推文
推
11/11 13:53, 4年前 , 84F
我是業務偶而會兼PM,如果你覺得PM不會技術也行那可能你
11/11 13:53, 84F
→
11/11 13:53, 4年前 , 85F
們家PM重要度太低，重要度低的PM就不要談什麼管理了，
11/11 13:53, 85F
→
11/11 13:53, 4年前 , 86F
你有見過工程師頭是靠所謂管理專業駕御底下的人嗎？講
11/11 13:53, 86F
→
11/11 13:53, 4年前 , 87F
難聽點沒有一點技術底你連要唬弄user或說服工程都編不
11/11 13:53, 87F
→
11/11 13:53, 4年前 , 88F
出個合理的說法，你說有技術長那也要技術長把自己程度
11/11 13:53, 88F
→
11/11 13:53, 4年前 , 89F
降10你聽的懂才行，如果全部推給技術長去對user那PM的
11/11 13:53, 89F
→
11/11 13:53, 4年前 , 90F
存在意義？
11/11 13:53, 90F
推
11/11 14:24, 4年前 , 91F
通常我們家我都要求PM去談一定要帶工程師去
11/11 14:24, 91F
→
11/11 14:25, 4年前 , 92F
工程師聽一下user的需求 有些很快就知道怎麼寫了
11/11 14:25, 92F
推
11/11 15:33, 4年前 , 93F
樓上正確啊，沒帶工程師去是要談什麼
11/11 15:33, 93F
→
11/11 15:40, 4年前 , 94F
可是如果PM會技術的話又何必帶工程師出門？coding的工程
11/11 15:40, 94F
→
11/11 15:40, 4年前 , 95F
師真的沒有那麼多時間出門開會呀！
11/11 15:40, 95F
→
11/11 16:07, 4年前 , 96F
一定要工程師談的話那要PM幹嘛
11/11 16:07, 96F
推
11/11 16:25, 4年前 , 97F
pm負責辣滴塞讓客戶爽就好了，這點是rd做不到的
11/11 16:25, 97F
→
11/11 16:35, 4年前 , 98F
還要帶 RD 開會的話，不就顯得這 PM 不行嗎？
11/11 16:35, 98F
→
11/11 17:07, 4年前 , 99F
還有一種業務(PM)顧客關希很好，就算自家Rd開天窗桶樓
11/11 17:07, 99F
→
11/11 17:07, 4年前 , 100F
子還是能把客戶按耐好，給自家人很多buffer或CP很好，
11/11 17:07, 100F
→
11/11 17:07, 4年前 , 101F
但這種厲害的是業務能力不是什麼管理能力，就算不太懂
11/11 17:07, 101F
→
11/11 17:07, 4年前 , 102F
技術還是有Rd幫賣命，這才叫各有專業
11/11 17:07, 102F
→
11/11 17:08, 4年前 , 103F
但這類客戶會賣面子的大約都管理級的了
11/11 17:08, 103F
推
11/11 21:30, 4年前 , 104F
這篇正解 重點不是會不會技術 而是擋掉
11/11 21:30, 104F
→
11/11 21:31, 4年前 , 105F
大家看不起的廢物PM是因為只當傳聲筒 只會轉發郵件
11/11 21:31, 105F
→
11/11 21:31, 4年前 , 106F
這種垃圾存在反而浪費公司資源
11/11 21:31, 106F
→
11/11 21:32, 4年前 , 107F
反之 好的PM可以有效運用公司資源
11/11 21:32, 107F
→
11/11 21:48, 4年前 , 108F
User想的到的需求基本上RD一定做的出來？
11/11 21:48, 108F
→
11/11 22:15, 4年前 , 109F
身為一個RD我必須跟樓上說確實如此,只是有沒有必要罷了
11/11 22:15, 109F
→
11/11 22:44, 4年前 , 110F
要做是真的都能做 但現實上還要考量效能與時程
11/11 22:44, 110F
→
11/11 22:44, 4年前 , 111F
如何在多方角力中取得平衡才是專業所在
11/11 22:44, 111F
推
11/11 23:48, 4年前 , 112F
其實很多純軟公司都是RD-PM輪調雙修啦
11/11 23:48, 112F
→
11/12 00:32, 4年前 , 113F
抱歉 還是不可能 RD並不負責成本
11/12 00:32, 113F
→
11/12 00:34, 4年前 , 114F
遇到機器效能不足 或是欠缺某些需要license的場景
11/12 00:34, 114F
→
11/12 00:35, 4年前 , 115F
跟不可能是等義的 但總會有許願這種事的User在
11/12 00:35, 115F
推
11/13 12:55, 4年前 , 116F
好的PM帶公司上天堂 不好的PM可能會把公司搞垮
11/13 12:55, 116F
→
11/13 12:56, 4年前 , 117F
我覺得懂技術有會溝通又有同理心的PM是上上之人
11/13 12:56, 117F
→
11/14 10:23, 4年前 , 118F
看看求職網,pm薪水頂多5,60k頂天了,是能要求多高
11/14 10:23, 118F
推
11/21 20:07, 4年前 , 119F
一堆人可能沒看過客戶有需求就說好的PM，產品流程弄得
11/21 20:07, 119F
→
11/21 20:07, 4年前 , 120F
亂七八糟，把一堆功能都擠在同一頁，最後loading大爆炸
11/21 20:07, 120F
→
11/21 20:07, 4年前 , 121F
，在叫RD善後的
11/21 20:07, 121F
推
11/21 20:10, 4年前 , 122F
還有那種客戶押不可能的時程還在跟人說好，快爆炸在找RD
11/21 20:10, 122F
→
11/21 20:10, 4年前 , 123F
加班到吐血的
11/21 20:10, 123F
‣ 更多 aoksc 的文章
文章代碼(AID): #1TntcxpO (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 5 之 6 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共6篇)
‣ 更多 aoksc 的文章
文章代碼(AID): #1TntcxpO (Soft_Job)