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

[aoksc (重出江湖)]

我覺得這問題答案是「有技術很好，但沒技術也沒差」

不管是產品經理、專案經理都是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
→ bheegrl: 但是PM不懂技術怎麼知道USER提得是天馬行空的幻想?
首先

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
→ bheegrl: 不懂技術的PM不一定是差的PM，但是上限就是比懂技術的低
→ bheegrl: 當然秀下限的就不論了，半瓶水響叮噹是自古皆然
推 jej: 有些狗屁不拉雜的PM 完全不考慮團隊技術能力的滿足客戶腦補
→ jej: 做出來爛東西後責任全部是RD 的而這種PM卻活的好好的
→ jej: 然後平常只會嘴責任他扛 這種PM被fire掉才是大快人心吧
→ jej: 就是一堆沒有專業的課程不斷教導PM不需要技術
→ jej: 才造成台灣軟體一直沒有很強的原因 因為溝通層很弱阿
→ jej: 然後又一直強調PM有PM的專業
推 jej: 這就像是交響樂團的指揮不會樂器樂理一樣
→ jej: 怎麼可能聽的出來音樂的差異
推 abccbaandy: 想到前陣子對岸很紅的：根據手機殼顏色變換手機背景
推 citycode: 所以指揮有指揮的專業，他不用跟樂器的人比樂器專業，
→ citycode: 樂理本來就是指揮必須要會的專業。
推 citycode: 不會指揮的人，樂器再厲害也當不了指揮。這不就是各有各
→ citycode: 的專業？
→ cool413: 如果遇到不懂技術 又自以為這功能很簡單 然後跟客戶簽完
→ cool413: 才回來報工時跟壓交期的呢？
推 xephon: https://www.youtube.com/watch?v=BKorP55Aqvg
→ BeardSmallGG: 指揮不用比演奏的人還會演奏 但指揮要完全不會演奏
→ BeardSmallGG: 一種樂器是不可能的 一堆垃圾PM完全不會寫程式
推 lovdkkkk: 洋鄉民的討論 https://bit.ly/2NZX1GH 參考看看
推 AMAKOTO: PM跟RD的專業有部分交集，沒把交集以外的部分補完，如何
→ AMAKOTO: 做好一個PM?這不就是各有專業?
推 yamakazi: 你們公司都沒Architect?
推 jej: 架構師在交響樂團的角色叫做作曲者
→ jej: 和討論中的指揮與樂器有段距離
推 aria0520: Architect是RD升上去的工程職好嗎....
→ aria0520: 工程師 -> 資深 -> 主任 -> 架構
→ remmurds: 主任聽起來很傳產
推 GGFACE: 主任就是principleㄚ
→ GGFACE: pal啦
推 zased: 這版大多是RD，用RD看天下，不懂管理一直糾結技術，完全沒
→ zased: 搞懂何謂PM。你這篇真的很委婉了哈哈
推 aria0520: 可惜台灣一堆PM根本不懂管理^^ 簡直就是欠嘴
→ aria0520: 一堆PM PM看天下 自以為多會管 然後在那炫耀自己多閒
→ aria0520: 快笑死
→ aria0520: 為什麼大多RD對PM有這印象 好好反思一下 別再縮在同溫層
→ aria0520: 然後自己取暖說他們都沒搞懂何謂PM QQ
→ aria0520: 傲慢 覺得自己完全不用去了解技術的這些PM 哈
→ aria0520: 好的PM帶RD上天堂 可惜台灣一堆這種傲慢PM 哀
推 OhNo386: 但若真不懂點技術，你怎麼知道rd可以做還是不能做跟做多
→ OhNo386: 久？時間管理就已不合格了
推 OhNo386: 討論與對話的前題基本上雙方水平是一致的. 不然誰開個需
→ OhNo386: 求天馬行空，時程也壓不準，最後也只癑淪為老闆的傳話桶
→ OhNo386: 而已
→ OhNo386: 台灣最缺的反而是管理而不是rd
→ OhNo386: 但也是有你說的站在雙方立場思考的pm，但畢竟是少數。遇
→ OhNo386: 過的大部分都是單向傳遞資訊（命令）而不是真的想跟你溝
→ OhNo386: 通（可能說了也不懂），所以造成溝通斷層而一連續的問題
→ OhNo386: ，產品出不來、rd離職、客戶棄單
推 OhNo386: 基本上沒有一點溝通天份的不要當pm對大家都比較好，技術
→ OhNo386: 部分反而可以跟rd套交情慢慢學。但若說都不需要技術就有
→ OhNo386: 點言過其實了
→ OhNo386: 因為不懂技術的pm有可能整天被rd耍還自己不知道。
推 jej: RD到底可不可以作？我還看過傲慢的PM臉很臭的和RD說
→ jej: 所以究竟是可不可以？ 造您這樣說PM應該要能判斷才對
→ jej: 但實值上卻是傲慢又不專業的PM居多
→ keke0421: RD都需要跟PM合作，那為啥一堆ＲＤ都覺得PM很廢= =?
推 sean2449: Google的PM就一定要技術
推 Csongs: 好奇PM薪水是多少
→ bosshsieh: 不懂技術能估時間我想也是亂估的
→ shooter555: PM需要的技術就是畫圖 排流程 跟嘴炮
→ oherman: 現實是得罪RD比得罪客戶活得久，所以無理的要求PM照法漏
推 v7q4: 前幾天我PM說:「C#和Java語法幾乎一樣啊 我之前有學過!
→ v7q4: 所以把Java的程式改成C#應該很快吧!」
→ Ekmund: 抱歉 我完全不覺得提的需求RD一定做得出來這句話成立...
→ Ekmund: 當組織稍微大一點 分工細 權限死 但是窗口、規格混亂時
→ Ekmund: 沒產業或技術經驗的PM唯一能做的事 一樣是壓時程
→ Ekmund: 搞到這種地步 RD自己下去做需求訪談才有救
→ Ekmund: 不破壞規則玩不下去的情況太多了
推 tony3939: 所以那些完全不懂技術的PM到底怎麼當上PM的
推 jej: 樓上 這是一個很奇妙的問題 更奇妙的問題是
→ jej: 就連PMP這麼大的招牌 課本上沒有地方說PM可以不需要技術
→ jej: 但上課老師卻拼命的灌輸PM不需要技術這觀念
→ jej: 只想速成的老闆們根據老師們的說法就上了 在構成沒技術也行
→ jej: 從老闆到員工一條鞭更是軟體業的問題啊
推 jej: 像是CMMI PMP的課本開宗明義就說了PM需要適當的了解產業知識
→ jej: 但被扭曲成軟體業不需了解程式 這才是最神奇的地方
推 hotkt247: 有些user提出來的需求看似很合理，但大部分都是在開始co
→ hotkt247: ding的時候才發現根本不符合程式邏輯，或是前面根本沒
→ hotkt247: 建置資料卻要莫名生出來啊！不懂技術亂接案到後面真的
→ hotkt247: 很可怕。
推 linkmusic: 我是業務偶而會兼PM,如果你覺得PM不會技術也行那可能你
→ linkmusic: 們家PM重要度太低，重要度低的PM就不要談什麼管理了，
→ linkmusic: 你有見過工程師頭是靠所謂管理專業駕御底下的人嗎？講
→ linkmusic: 難聽點沒有一點技術底你連要唬弄user或說服工程都編不
→ linkmusic: 出個合理的說法，你說有技術長那也要技術長把自己程度
→ linkmusic: 降10你聽的懂才行，如果全部推給技術長去對user那PM的
→ linkmusic: 存在意義？
推 shadow0828: 通常我們家我都要求PM去談一定要帶工程師去
→ shadow0828: 工程師聽一下user的需求 有些很快就知道怎麼寫了
推 appleboy46: 樓上正確啊，沒帶工程師去是要談什麼
→ hotkt247: 可是如果PM會技術的話又何必帶工程師出門？coding的工程
→ hotkt247: 師真的沒有那麼多時間出門開會呀！
→ stkoso: 一定要工程師談的話那要PM幹嘛
推 oherman: pm負責辣滴塞讓客戶爽就好了，這點是rd做不到的
→ rucarl: 還要帶 RD 開會的話，不就顯得這 PM 不行嗎？
→ linkmusic: 還有一種業務(PM)顧客關希很好，就算自家Rd開天窗桶樓
→ linkmusic: 子還是能把客戶按耐好，給自家人很多buffer或CP很好，
→ linkmusic: 但這種厲害的是業務能力不是什麼管理能力，就算不太懂
→ linkmusic: 技術還是有Rd幫賣命，這才叫各有專業
→ linkmusic: 但這類客戶會賣面子的大約都管理級的了
推 KanzakiHAria: 這篇正解 重點不是會不會技術 而是擋掉
→ KanzakiHAria: 大家看不起的廢物PM是因為只當傳聲筒 只會轉發郵件
→ KanzakiHAria: 這種垃圾存在反而浪費公司資源
→ KanzakiHAria: 反之  好的PM可以有效運用公司資源
→ bitcch: User想的到的需求基本上RD一定做的出來？
→ DCTmaybe: 身為一個RD我必須跟樓上說確實如此,只是有沒有必要罷了
→ stkoso: 要做是真的都能做 但現實上還要考量效能與時程
→ stkoso: 如何在多方角力中取得平衡才是專業所在
推 aria0520: 其實很多純軟公司都是RD-PM輪調雙修啦
→ Ekmund: 抱歉 還是不可能 RD並不負責成本
→ Ekmund: 遇到機器效能不足 或是欠缺某些需要license的場景
→ Ekmund: 跟不可能是等義的 但總會有許願這種事的User在
推 leveger0903: 好的PM帶公司上天堂 不好的PM可能會把公司搞垮
→ leveger0903: 我覺得懂技術有會溝通又有同理心的PM是上上之人
→ MagicMomo19: 看看求職網,pm薪水頂多5,60k頂天了,是能要求多高
推 sxy67230: 一堆人可能沒看過客戶有需求就說好的PM，產品流程弄得
→ sxy67230: 亂七八糟，把一堆功能都擠在同一頁，最後loading大爆炸
→ sxy67230: ，在叫RD善後的
推 sxy67230: 還有那種客戶押不可能的時程還在跟人說好，快爆炸在找RD
→ sxy67230: 加班到吐血的