※ 本文轉寄自 ptt.cc, 文章原始頁面
看板Soft_Job
標題

[請益] PM要求實作未來會出問題的功能

時間
最新2021-01-06 22:46:00
留言106則留言,51人參與討論
推噓26 ( 33766 )
年薪300的大神們 大家好 小弟想請教各位,有沒有遇過PM或老闆提出的需求, 是網站上線後,資料量變大才可能會出問題的那種, 這時候身為負責實現工程師, (1)眼睛一閉,照做,到時候出問題再說 (2)試著跟PM溝通,解釋可能會遇到的問題,以及是否真的需要這個功能 (3)溝通無效,閃人為妙 請問單兵如何處置 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 140.109.161.23 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1577951161.A.3F1.html

106 則留言

crossdunk, 1F
看不懂 資料量變大才會出問題 那現在就會有問題啊

ww410490, 2F
是這樣的 資料量變大 導致loading過久 以及畫面變的雜亂

gundam00, 3F
先做啊 反正也不一定有機會資料量變大....

yuanruo, 4F
不要over design

ww410490, 5F
好的 我也有反省 是不是我想太多 應該收錢就乖乖做事

pttworld, 6F
有問題也不是你扛,不過有問題要修改還是你

benqm300, 7F
等慢了再說,沒出來之前都是你的鍋。

ww410490, 8F
沒錯 我就是想到 出問題還是我來改 所以是不是要提醒PM

v7q4, 9F
做好error handling、寄信給PM cc主管 說這裡可能會有問題

v7q4, 10F
PM死不改的話就不關你的事 反正你都已經先提醒了

cheeseup, 11F
你現在不做就現在被責難;現在先做之後才會被挖起來修

cheeseup, 12F
上一家公司就一堆前人留下來的洞,我是看ㄧ看之後也離開

testPtt, 13F
loading過久就給進度條 畫面就重新排版而已

ww410490, 14F
這位大大說的也沒錯 但這個需求要做的事就多了很多

nova06091, 15F
直接開扁

SimonAllen, 16F
溝通 但不是不做而是討論大資料時那些部分要隱藏或大

SimonAllen, 17F
資料功能是否刪減

ppppman, 18F
就時間與成本問題 告知做或不做的影響 把你的專業和建議

ppppman, 19F
提出 大家來討論唄

Aidan79225, 20F
先做 之後資料真的變大再來改

Ghamu, 21F
拍桌大罵 不然請他們簽切結書 簽完祝公司無災無難

Ghamu, 22F
是說實務上還是先做再說吧 哈哈哈 謝謝你們公司為台灣創造

Ghamu, 23F
工作機會

benedict76, 24F
看起來不是會出問題只是實作過程麻煩懶得做XD

pilor, 25F
lazy loading

yyc1217, 26F
看起來是想要一次性顯示所有資料? 做成分頁應該不難

sharek, 27F
同意b大...看起來是沒有好方法或架構所以不想做?

b85040312, 28F
有洞才有事做阿

sxy67230, 29F
git commit 紀錄起來,押時間跟實現的功能敘述,然後紀

sxy67230, 30F
錄未來可能會發生什麼問題,真的發生被怪罪就直接調紀

sxy67230, 31F
錄啊

s06yji3, 32F
...

vi000246, 33F
當然是先吵架 吵不贏開始做 做完又要改就能嗆回去了

final01, 34F
那是工程師的問題,幹嘛推給PM

benedict76, 35F
基本上還沒做出來的東西然後跟pm說會有問題很難說服人

benedict76, 36F
,要是我是pm也是要看屍體。

xlf, 37F
提出問題 留下書面紀錄方便以後黑PM

s06yji3, 38F
不應該是解決資料量變大會產生的問題嗎?

Masakiad, 39F
你應該要提供每一種solution 的人工、資料量跟效能的極

allenxxx, 93F
能?!也沒好到哪裡去

steve1012, 94F
資料量大就不行乍聽起來是engineer 的問題

Masakiad, 95F
樓上說這話聽起來像慣PM

mago, 96F
資料量大解法有很多種,有的甚至牽涉storage 更換, 寫拆開

iceonly, 97F
多的時候會爆掉,那就多的時候再處理啊,不然你以為系統

iceonly, 98F
維護就是在debug?再說哪有啥資料量多就不能處理的事情,

iceonly, 99F
前端量多就virtual scrolling或paging或cache,查詢慢就s

iceonly, 100F
olr或table設計好一點,資料無敵多就hadoop ecosystem弄

iceonly, 101F
下去。不過那也是之後再改的事,也沒有啥解決不了的問題

justben, 102F
看這Project賺的錢能不能抵銷出包的錢啊 XD

oread168, 103F
有文件的話可以寫一下已溝通過就好拉

oread168, 104F
怕到時候真的要改會被指指點點的話

lturtsamuel, 105F
資料量大就分頁啊== 你只是懶吧

lturtsamuel, 106F
你的資料難道會比臉書大?