谁可以告诉我 这软件需求的合理性及必要性?
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
多个商品名称 绿茶（小）不就解决了 何须改架构正规化是循序渐进的 不要为了正规化而裹足不前