[問題] 商業邏輯的處理

[LaPass (LaPass)]

靠JAVA吃飯吃了快一年了
在技術上是沒遇到什麼太大的問題
因為一般的需求，在技術上都不會複雜到哪裡去...
頂多就是弄弄報表、輸入輸出資料、讀寫資料庫、檔案傳來傳去之類的而已
在大不了就是call api去跟其他東西串在一起



但是
有些地方讓我很感冒
這個問題舉個例子來講會比較容易講

既然要舉例子
蠻多網頁初學的範例都用留言板
那還是舉留言板來當例子吧.....



通常，顧客會說：「我要個留言板」
然後開始說規格
例如.....
留言時要留的資料要有：
   姓名、地址、身分證字號、電話.....

身分要有：
   留言板管理人員、留言發佈者.....

流程是：
  發佈者發佈一則留言 => 顯示於列表
  發佈後可以修改留言內容



表面的規格是這樣寫，但實際上問了之後，客戶還會說更多細節
例如：
   「留言板管理人員可以看留言中的所有資料，包含身分證字號、電話
   一般人看列表只能看到姓名跟留言內容
   管理者也能修改留言內容，而且修改過後，留言者就不能修改
   管理者能刪除留言
   留言發佈後，留言者就不能修改姓名、電話、地址，只能夠修改內容
   (略)」

看起來很煩，寫起來也很煩

但這也還好，寫完後如果就這樣沒事也就算了......
通常寫完後還會這樣：

   「我看過留言版了，有些地方要小修改一下.....」

   「多加個審核者身份，所有留言要經過審核者審核通過才能發佈
   留言管理者看不到未審核通過的內容，若是審核通過，可以看到審核者是誰
   審核不通過的話，可以留下審核不通過的原因，退回留言者
   留言者編輯後可以重新送出
   審核通過的留言內容就不能修改

   多加個閱讀者身份，只有閱讀者才能從列表中看見發佈的留言
   但一樣看不到身份證之類的資訊」



好不容易依照要求改完之後，也可能有第三次：
   「新增個搜尋列表，可以搜尋所有留言，但是要卡身分限制
   留言者只能看見自己發的留言，審核者只能看見自己審核的留言

   多加個評分者，我老闆說要對留言打分數
   因此所有留言審核通過後就要送交評分者評分，打完分數後要歸檔匯出報表
   可以計算某位留言者的某段時間內的留言評分，以及某部門的留言平均分數
   就不用閱讀者了
   (追問後才知道，評分者不能看身分證字號，但可以看電話 etc )

   把你那個會員系統也給整合進來，需指定評分者、審核者能評分、審核
   特定部門的留言者的留言」



接下來還可能有第四次、第五次.....



但是最讓我賭爛的是最後一次



  「前幾天我已經跟公司的人都示範過這套系統了。
    但是那些人(留言者、審核者、評分者、管理者)覺得用舊方法做就好....
    所以，現在改成，留言者自己跟審核者決定留言內容，把留言內容e-amil給評分者
    評分者改完分數後，再轉交給助理歸檔
    所以你要把那個留言板系統改成助理的歸檔系統
    並可以由助理一人記錄評分、留言內容
    身分證字號、姓名，並加個上傳檔案的欄位記錄e-mail電子檔」



請告訴我.....
有沒有任何Solution可以解決這種機車的商業邏輯？

orz.....

※ 編輯: LaPass          來自: 61.59.16.65          (11/22 14:25)
→ StubbornLin:你需要解決的是客戶不是商業邏輯
→ StubbornLin:解決方法很簡單 修改要錢
→ StubbornLin:如果改不會痛的話 他們就無所謂 隨便改
→ StubbornLin:不收錢的話 痛當的然是你不是他們
→ LaPass:雖然接案不是我負責的，但應該是標案 orz.....
推 liberation:先做假的給他們改到爽
推 KYOFIGHTER:負責的人硬一點,定好規格後修改要加錢 就可以解決
推 tyc5116:書上有看到外國的一個做法(但我覺得現實上不太可行)
→ tyc5116:跟客戶討論數個功能,然後一兩個星期搞定,由客戶驗收
→ tyc5116:再要求數個功能,再一兩個星期,再驗收,repeat,直到結束
→ tyc5116:因為功能不多,所以程式的結構上可以寫的好一點,有彈性一點
→ tyc5116:以後即使要改也比較好改
→ tyc5116:日後客戶若要求哪個地方要大改的話,也比較有立場拒絕
推 minikai:依照合約走 謝謝指教
→ chrisQQ:redmine + git log 列修改報表照工時算錢 XDD
推 gmoz:其實應該要要求客戶他們自己先內部討論
→ gmoz:不慣的定時跑客戶 show一些初版給他們看 同TYC大 過來經驗QQ
→ gmoz:不一定要驗收 但是要一個階段一個階段弄
→ gmoz:常常提修改的都不是END-USER 後來改一改長官又會問END USER
→ gmoz:意見 然後說你還是以他們的意見為主吧 ...OOXX
→ iceonly:scrum表示:
推 sing10407:可是我覺要看需求分析者的能力 分析好修改少
→ iceonly:不過看起來這product owner沒能力阿
推 bobju:這算是管理議題,除了合約內容外,也跟溝通技巧有關.
→ bobju:這因為需求可能會沒完沒了,實務上才會有所謂的Best Practice
→ bobju:,就是不希望user弄出太多無關Best Practice的發想.
→ bobju:通常說服客戶[不要這麼做]比[我什麼都能做]還重要.後者通常
→ bobju:是菜鳥愛逞強,最後搞死自己又收不到錢.
推 gmoz:推樓上  嘴砲技能真的很值錢=_=+
→ gmoz:進度線可能會扭來扭去的 但是要讓他往同一個方向收斂而非發散
推 bobju:有時候你也可以[嚇]客戶: 之前也有客戶要求這樣,結果就..
推 tyc5116:如果覺得可以扯,user提需求我第一句一律回"這個要大改喔"
→ tyc5116:不少user就會退一步了....XD能嘴砲還是盡量嘴砲
推 edward13:推樓上 能引導顧客真的不是一天兩天的修為
→ andymai:所以有時候寫程式比工地工人還賤!!!不好意思~請原諒我說話
→ andymai:就是這麼直~人家工地工人要多拆個什麼、加個什麼~沒錢是沒
→ andymai:可能動工的~可是寫程式套個責任制就要你改到死去活來...
推 codemonkey:BPEL + BPS?
推 xsoho:但是從客戶的角度立場他處裡的滿有邏輯，先把架構弄出來
→ xsoho:然後把各種備案都準備好，等長官看完後可盡可退，是人才阿XD
→ xsoho:不過之前的公司業務都會把可能發生的狀況跟客戶先約定好
→ xsoho:盡量避免背後靈出沒的狀況，要求太過份直接反映對方主管
→ xsoho:大部分還是靠高層解決這種繁瑣的窘境
推 gmoz:有時候USER講了一大堆 其實他只是要那樣子而已 先聽完
→ gmoz:再慢慢拆解 折衷 說這個可能要改到架構喔 如果改成ooo呢
→ gmoz:不斷的折衷下去 最後就會回到user最單純要的XDDD
→ FMDream:一開始就要討論好定出規格 接著照規格開發
→ howshou:歡迎來到軟體業。
→ howshou:即使討論出來的規格，即使會議記錄白紙黑字，客戶要翻臉
→ howshou:不付錢，你還是得做。
推 bobju:不過有規格還是比沒規格好,雖然還是會被拗,但總比胡搞亂搞好
→ bobju:我覺得軟體專案最重要就是看在[錢]的份上.雖說錢不是萬能,但
→ bobju:沒錢萬萬不能.客戶出得起錢,你被拗尚能忍受,客戶窮光蛋一個,
→ bobju:即便用軟求你你也受不了.你沒時間一直陪他耗啊.
→ bobju:客戶最大,<-這句話不太對; 出得起錢的客戶最大 <-還比較有理
→ conanist:照合約做  規格寫進合約修要收錢 公司請你要花錢
→ conanist:你花錢間在客戶上難度不收錢?
→ conanist:你是受雇 不是奴隸 不一定要先做好 你可以先用雛型給看
→ conanist:然後再討論 然後定流程跟功能反正你就包SASD的工作就是了
推 RickyOrange:系統分析要做啊
→ loser5566:推how
→ sbob:哪邊有商業邏輯? 遇到澳客而以