誰可以告訴我 這軟體需求的合理性及必要性?
1. 為什麼綠茶大杯與綠茶小杯的圖片及描述需要不一樣?
2. 為什麼綠茶大杯與綠茶小杯的冰塊圖片需要不一樣? 不就都是冰塊嗎??? 難道我賣20
種飲料及大小杯就可以設定20張不同的冰塊圖片?
一開始我以為是需求規格寫錯或沒注意 結果那位大小姐是真的想這麼做 我覺得奇怪 抓
一堆人開會 包括主管 專案經理 測試人員 開發人員 花了幾個小時 還開了2次會 都沒人
站出來反對 專案經理還覺得開這個會是浪費大家時間
最後決定交給業務決定市場是否有這個需求? 過了2天得到的答案是要做
好吧 是我很奇怪 你們想怎麼做就怎麼做
作者:
pttworld (批踢踢世界)
2018-03-20 19:31:00結果現實生活大小杯只有一張圖片
作者:
alihue (wanda wanda)
2018-03-20 19:34:00我們只要聽話做的猴子，不要雞雞歪歪的
我只是想到db schema 要大改就很煩我還回大杯冰塊用冰山圖片 小杯用碎冰 這樣是不是比較合理
作者:
ken1325 (優質水瓶男)
2018-03-20 19:50:00你意見那麼多幹嘛 乖乖做不行嗎
作者:
pilor (Formosa)
2018-03-20 19:53:00我覺得你可以去跟 PM 說 這裡不是個版
作者: wildli0422 (wild) 2018-03-20 20:32:00
推二樓，就當個聽話的猴子就好
作者:
rupcj8 (唉呀)
2018-03-20 20:34:00主管 專案經理 測試人員 開發人員在%大小姐 你只好改圖片
作者:
RINPE (RIN)
2018-03-20 20:54:00反正以後換工作是看程式 現在我都放空 要改什麼都好 不要拖到我下班就好
本來我也是堅持程式的維護性 現在看開了 反正以後維護的不會是我 在意這種細節幹嘛
作者:
yyc1217 (somo)
2018-03-20 21:37:00倒覺得這需求很清楚呀
作者:
pttworld (批踢踢世界)
2018-03-20 21:47:00好奇原本table怎麼串的，這樣就大改
因為他們還想要兩套設定並存 在網路上訂的飲料要套用上述規則 然而在實體店面POS機操作就比較簡單 但是從POS機修改商品...等資料 又要同步至網路上的設定 反之從網頁修改也要同步回POS機細節很多所以沒寫完 例如還可以設定綠茶大杯可以選甜度的無糖 但綠茶小杯不能選無糖但是實體店面綠茶大小都可以作無糖為什麼實體店面可以選無糖 但從網路上訂的就不能選無糖 這就要問大小姐
作者:
pttworld (批踢踢世界)
2018-03-20 22:06:00這是操作規則業務邏輯，一個欄位不同值代表有無除非原本沒開欄位品名、尺寸、甜度、冰量都開好，任意搭配
這個系統賣飲料只是一個例子 還要可以拿來套用到其它餐飲業POS的甜度只有一套設定 但網路上綠茶大杯可以不要無糖綠茶小杯可以不要微糖 所以有多種甜度設定 但如果從POS刪除無糖選項 那網路的綠茶大杯就會同步停用 但綠茶小杯不受影響
作者:
sanpf (sanpf)
2018-03-20 22:24:00沒辦法，誰叫人家是大小姐。
這麼細的需求要寫好一點，以後可以套用在其他地方XD
我家大小姐開的需求規格都只給一張大圖 只畫UI 加少許註解文字 其餘自行腦補 問太多就擺臭臉給你看
問到最後都開會討論了 結果我還被打臉 以後還敢有意見嗎? 唉 先做確定的部分 過幾天風頭過了再問
作者:
alihue (wanda wanda)
2018-03-20 22:50:00你就翻臉啊，要不換他們求你，要不重新找工作
我才換新工作不久而已 薪水高不代表同事水準高 前公司就沒這種鳥事找PM說也沒用 PM都直接說需求完全交給大小姐負責 真的決定不了再找我開會 結果這個需求問題真的開了會還被嫌浪費時間 這間公司的主管及PM都不主動 review需求的 大小姐說了算 我看她的職稱是 UX 設計師 所以我對她的實質權力有所誤會 現在我才知道原來她是大小姐
作者:
Ekmund (是一隻小叔)
2018-03-21 00:34:00所以，你有問過營運或是客戶，為什麼要這麼做嗎？搞不好人家有版面設計或某些工程師想不到的需求面如果你覺得被質疑時程或可行性，是不尊重你的專業那你這樣的方式不也是不尊重對方專業？如果你覺得規格不夠詳細，每次都要你腦補抓不到合作對象的胃，那代表你們真的不適合合作，就這樣要馬請別人跟她對頭，要馬請別人嘍
比較單純的看法就是「大杯綠茶」和「小杯綠茶」是兩個商品，而不是「一種商品」的兩個尺寸，至於為什麼要這樣定義就是商家那邊的問題了（說不定以後大杯綠茶有造型杯但是小杯沒有，所以要圖片不同之類的）
產品還沒開始賣 所以客戶不存在 這需求是她自己一個人想的 我有問她為什麼需要這樣複雜的設定? 她回我為什麼不行? 系統要有彈性 萬一客戶想這麼做怎麼辦 另外這篇文章所講的需求都是我看圖腦補後覺得有問題才追問出來的 一開始的規格並沒有寫 有向主管反應能不能給個功能清單 或是多一點文字描述 但UX團隊做事的方法就是畫圖 她們不會寫程式 所以根本不懂這會不會影響到後端MODEL 的設計 要加新功能也不找後端我來開會 因為她覺得畫圖只跟前端工程師有關係 這張需求的圖還是我透過其他工程師才拿到的我前公司的產品功能 工程師也會參與討論給意見 但現任公司的風氣感覺就是照做就對了 所以有些適應不良雖然主管有說我提出這個問題很好 但我沒想到會議中沒人可以做最後的決定 推給不在場的業務 如果問的方式是對業務說加新功能更有彈性好不好 當然說好啊
作者:
BignoZe (BignoZe)
2018-03-21 01:49:00這麼簡單的東西有空再這邊發文不如直接做出來...
這需求哪有什麼問題啦，真實世界大小杯的照片不一樣才是正常的吧。
作者:
shvanta (vant)
2018-03-21 09:21:00其實只要確認,業務邏輯是誰負責,詳細規則請負責人出文件你對規則有疑問就跑去問負責人就好, 按規則設計DB,coding你把所有人拉進來開會,真的是會浪費他人的時間負責人針對你疑問回答的部分,你整理起來發email確認&備查cc給直屬主管及專案PM(如果有的話). 出事拿這個保命
開個規格table 把該飲料的不同size、描述、圖片存進去這樣要改商品價錢、或是停售之類的 只要改商品主表就好
這還好吧，我們客戶還會到最後發信來問為什麼不能加珍珠 阿你們當初又沒說要這功能XD
原PO真的很奇怪。會跟需求搏鬥還找一票人進來打自己臉的工程師趕快離職去擺地攤好了。雇用你的公司真不幸，付錢給你找罪受也許你自己擺過攤後，會幫助你想通原本自己想不通的需求吧
比較好奇為什麼同類型的商品會動到schema，那個不是應該在相同系統下的東西嗎
專案需求怎樣做就怎樣做，反正有人敢扛就做，不要最後變成自己的坑。最機掰的是接案需求有寫等於沒寫，那才要命。
我覺得他的需求怎麼開無所謂，重點是你db架構怎麼設計
作者:
justben (BEN)
2018-03-22 17:46:00拿人錢財與人消災...
作者:
mathrew (Joey)
2018-03-23 08:28:00其他人都沒意見 不用管那麼多
作者: lnmlee 2018-03-23 11:33:00
多個商品名稱 綠茶（小）不就解決了 何須改架構正規化是循序漸進的 不要為了正規化而裹足不前