PTT職涯區 / Soft_Job (軟體人)

[問題] 商業邏輯的處理

看板Soft_Job (軟體人)作者 (LaPass)時間13年前 (2012/11/22 14:25), 編輯推噓16(16推 0噓 46→)
留言62則, 21人參與, 最新討論串1/2 (看更多)
靠JAVA吃飯吃了快一年了 在技術上是沒遇到什麼太大的問題 因為一般的需求，在技術上都不會複雜到哪裡去... 頂多就是弄弄報表、輸入輸出資料、讀寫資料庫、檔案傳來傳去之類的而已 在大不了就是call api去跟其他東西串在一起 但是 有些地方讓我很感冒 這個問題舉個例子來講會比較容易講 既然要舉例子 蠻多網頁初學的範例都用留言板 那還是舉留言板來當例子吧..... 通常，顧客會說：「我要個留言板」 然後開始說規格 例如..... 留言時要留的資料要有： 姓名、地址、身分證字號、電話..... 身分要有： 留言板管理人員、留言發佈者..... 流程是： 發佈者發佈一則留言 => 顯示於列表 發佈後可以修改留言內容 表面的規格是這樣寫，但實際上問了之後，客戶還會說更多細節 例如： 「留言板管理人員可以看留言中的所有資料，包含身分證字號、電話 一般人看列表只能看到姓名跟留言內容 管理者也能修改留言內容，而且修改過後，留言者就不能修改 管理者能刪除留言 留言發佈後，留言者就不能修改姓名、電話、地址，只能夠修改內容 (略)」 看起來很煩，寫起來也很煩 但這也還好，寫完後如果就這樣沒事也就算了...... 通常寫完後還會這樣： 「我看過留言版了，有些地方要小修改一下.....」 「多加個審核者身份，所有留言要經過審核者審核通過才能發佈 留言管理者看不到未審核通過的內容，若是審核通過，可以看到審核者是誰 審核不通過的話，可以留下審核不通過的原因，退回留言者 留言者編輯後可以重新送出 審核通過的留言內容就不能修改 多加個閱讀者身份，只有閱讀者才能從列表中看見發佈的留言 但一樣看不到身份證之類的資訊」 好不容易依照要求改完之後，也可能有第三次： 「新增個搜尋列表，可以搜尋所有留言，但是要卡身分限制 留言者只能看見自己發的留言，審核者只能看見自己審核的留言 多加個評分者，我老闆說要對留言打分數 因此所有留言審核通過後就要送交評分者評分，打完分數後要歸檔匯出報表 可以計算某位留言者的某段時間內的留言評分，以及某部門的留言平均分數 就不用閱讀者了 (追問後才知道，評分者不能看身分證字號，但可以看電話 etc ) 把你那個會員系統也給整合進來，需指定評分者、審核者能評分、審核 特定部門的留言者的留言」 接下來還可能有第四次、第五次..... 但是最讓我賭爛的是最後一次 「前幾天我已經跟公司的人都示範過這套系統了。 但是那些人(留言者、審核者、評分者、管理者)覺得用舊方法做就好.... 所以，現在改成，留言者自己跟審核者決定留言內容，把留言內容e-amil給評分者 評分者改完分數後，再轉交給助理歸檔 所以你要把那個留言板系統改成助理的歸檔系統 並可以由助理一人記錄評分、留言內容 身分證字號、姓名，並加個上傳檔案的欄位記錄e-mail電子檔」 請告訴我..... 有沒有任何Solution可以解決這種機車的商業邏輯？ orz..... ※ 編輯: LaPass 來自: 61.59.16.65 (11/22 14:25)
→
11/22 14:27, , 1F
你需要解決的是客戶不是商業邏輯
11/22 14:27, 1F
→
11/22 14:28, , 2F
解決方法很簡單 修改要錢
11/22 14:28, 2F
→
11/22 14:28, , 3F
如果改不會痛的話 他們就無所謂 隨便改
11/22 14:28, 3F
→
11/22 14:29, , 4F
不收錢的話 痛當的然是你不是他們
11/22 14:29, 4F
→
11/22 14:35, , 5F
雖然接案不是我負責的，但應該是標案 orz.....
11/22 14:35, 5F
推
11/22 14:37, , 6F
先做假的給他們改到爽
11/22 14:37, 6F
推
11/22 15:09, , 7F
負責的人硬一點,定好規格後修改要加錢 就可以解決
11/22 15:09, 7F
推
11/22 15:13, , 8F
書上有看到外國的一個做法(但我覺得現實上不太可行)
11/22 15:13, 8F
→
11/22 15:14, , 9F
跟客戶討論數個功能,然後一兩個星期搞定,由客戶驗收
11/22 15:14, 9F
→
11/22 15:14, , 10F
再要求數個功能,再一兩個星期,再驗收,repeat,直到結束
11/22 15:14, 10F
→
11/22 15:15, , 11F
因為功能不多,所以程式的結構上可以寫的好一點,有彈性一點
11/22 15:15, 11F
→
11/22 15:15, , 12F
以後即使要改也比較好改
11/22 15:15, 12F
→
11/22 15:16, , 13F
日後客戶若要求哪個地方要大改的話,也比較有立場拒絕
11/22 15:16, 13F
推
11/22 15:19, , 14F
依照合約走 謝謝指教
11/22 15:19, 14F
→
11/22 15:21, , 15F
redmine + git log 列修改報表照工時算錢 XDD
11/22 15:21, 15F
推
11/22 16:25, , 16F
其實應該要要求客戶他們自己先內部討論
11/22 16:25, 16F
→
11/22 16:26, , 17F
不慣的定時跑客戶 show一些初版給他們看 同TYC大 過來經驗QQ
11/22 16:26, 17F
→
11/22 16:32, , 18F
不一定要驗收 但是要一個階段一個階段弄
11/22 16:32, 18F
→
11/22 16:32, , 19F
常常提修改的都不是END-USER 後來改一改長官又會問END USER
11/22 16:32, 19F
→
11/22 16:32, , 20F
意見 然後說你還是以他們的意見為主吧 ...OOXX
11/22 16:32, 20F
→
11/22 16:52, , 21F
scrum表示:
11/22 16:52, 21F
推
11/22 16:52, , 22F
可是我覺要看需求分析者的能力 分析好修改少
11/22 16:52, 22F
→
11/22 16:53, , 23F
不過看起來這product owner沒能力阿
11/22 16:53, 23F
推
11/22 17:02, , 24F
這算是管理議題,除了合約內容外,也跟溝通技巧有關.
11/22 17:02, 24F
→
11/22 17:04, , 25F
這因為需求可能會沒完沒了,實務上才會有所謂的Best Practice
11/22 17:04, 25F
→
11/22 17:04, , 26F
,就是不希望user弄出太多無關Best Practice的發想.
11/22 17:04, 26F
→
11/22 17:07, , 27F
通常說服客戶[不要這麼做]比[我什麼都能做]還重要.後者通常
11/22 17:07, 27F
→
11/22 17:07, , 28F
是菜鳥愛逞強,最後搞死自己又收不到錢.
11/22 17:07, 28F
推
11/22 17:09, , 29F
推樓上 嘴砲技能真的很值錢=_=+
11/22 17:09, 29F
→
11/22 17:11, , 30F
進度線可能會扭來扭去的 但是要讓他往同一個方向收斂而非發散
11/22 17:11, 30F
推
11/22 19:52, , 31F
有時候你也可以[嚇]客戶: 之前也有客戶要求這樣,結果就..
11/22 19:52, 31F
推
11/22 21:39, , 32F
如果覺得可以扯,user提需求我第一句一律回"這個要大改喔"
11/22 21:39, 32F
→
11/22 21:40, , 33F
不少user就會退一步了....XD能嘴砲還是盡量嘴砲
11/22 21:40, 33F
推
11/22 21:44, , 34F
推樓上 能引導顧客真的不是一天兩天的修為
11/22 21:44, 34F
→
11/22 21:49, , 35F
所以有時候寫程式比工地工人還賤!!!不好意思~請原諒我說話
11/22 21:49, 35F
→
11/22 21:50, , 36F
就是這麼直~人家工地工人要多拆個什麼、加個什麼~沒錢是沒
11/22 21:50, 36F
→
11/22 21:51, , 37F
可能動工的~可是寫程式套個責任制就要你改到死去活來...
11/22 21:51, 37F
推
11/22 22:06, , 38F
BPEL + BPS?
11/22 22:06, 38F
推
11/22 22:31, , 39F
但是從客戶的角度立場他處裡的滿有邏輯，先把架構弄出來
11/22 22:31, 39F
→
11/22 22:32, , 40F
然後把各種備案都準備好，等長官看完後可盡可退，是人才阿XD
11/22 22:32, 40F
→
11/22 22:34, , 41F
不過之前的公司業務都會把可能發生的狀況跟客戶先約定好
11/22 22:34, 41F
→
11/22 22:35, , 42F
盡量避免背後靈出沒的狀況，要求太過份直接反映對方主管
11/22 22:35, 42F
→
11/22 22:36, , 43F
大部分還是靠高層解決這種繁瑣的窘境
11/22 22:36, 43F
推
11/22 22:42, , 44F
有時候USER講了一大堆 其實他只是要那樣子而已 先聽完
11/22 22:42, 44F
→
11/22 22:43, , 45F
再慢慢拆解 折衷 說這個可能要改到架構喔 如果改成ooo呢
11/22 22:43, 45F
→
11/22 22:43, , 46F
不斷的折衷下去 最後就會回到user最單純要的XDDD
11/22 22:43, 46F
→
11/22 22:45, , 47F
一開始就要討論好定出規格 接著照規格開發
11/22 22:45, 47F
→
11/23 01:05, , 48F
歡迎來到軟體業。
11/23 01:05, 48F
→
11/23 01:06, , 49F
即使討論出來的規格，即使會議記錄白紙黑字，客戶要翻臉
11/23 01:06, 49F
→
11/23 01:06, , 50F
不付錢，你還是得做。
11/23 01:06, 50F
推
11/23 01:13, , 51F
不過有規格還是比沒規格好,雖然還是會被拗,但總比胡搞亂搞好
11/23 01:13, 51F
→
11/23 01:15, , 52F
我覺得軟體專案最重要就是看在[錢]的份上.雖說錢不是萬能,但
11/23 01:15, 52F
→
11/23 01:15, , 53F
沒錢萬萬不能.客戶出得起錢,你被拗尚能忍受,客戶窮光蛋一個,
11/23 01:15, 53F
→
11/23 01:16, , 54F
即便用軟求你你也受不了.你沒時間一直陪他耗啊.
11/23 01:16, 54F
→
11/23 01:18, , 55F
客戶最大,<-這句話不太對; 出得起錢的客戶最大 <-還比較有理
11/23 01:18, 55F
→
11/23 09:36, , 56F
照合約做 規格寫進合約修要收錢 公司請你要花錢
11/23 09:36, 56F
→
11/23 09:36, , 57F
你花錢間在客戶上難度不收錢?
11/23 09:36, 57F
→
11/23 09:38, , 58F
你是受雇 不是奴隸 不一定要先做好 你可以先用雛型給看
11/23 09:38, 58F
→
11/23 09:39, , 59F
然後再討論 然後定流程跟功能反正你就包SASD的工作就是了
11/23 09:39, 59F
推
11/23 11:56, , 60F
系統分析要做啊
11/23 11:56, 60F
→
11/23 13:14, , 61F
推how
11/23 13:14, 61F
→
11/27 07:59, , 62F
哪邊有商業邏輯? 遇到澳客而以
11/27 07:59, 62F
‣ 更多 LaPass 的文章
文章代碼(AID): #1GhSLD2m (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文：
完整討論串 (本文為第 1 之 2 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共2篇)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 LaPass 的文章
文章代碼(AID): #1GhSLD2m (Soft_Job)