freedomhome wrote:
這不就一活脫脫?(恕刪)
歡迎去偉大的祖國領口罩~不送
個人積分：140分
文章編號：76789123
個人積分：286分
文章編號：76789252
個人積分：286分
文章編號：76789341
個人積分：44分
文章編號：76789389
JasonQ wrote:
預購端要具備金流、還要透過網路消費方式確認貨款來自信用卡、網銀、支付軟體、ATM....
這些系統的複雜度都比超商貨到付款還簡單！！？
兩者系統設計差異在那你知道嗎？
只差在“需不需要額外的第三方處理金流”而已....
要不要賭一下，口罩2.0處理金流的一定是額外的廠商？
是不是額外廠商不重要
不管是銀行(刷卡,ATM)、第三方支付....
基本上就是把入帳款項對映到訂單的過程
我寫過銷售系統中串接金流的程式，你想討論也行
不過我想知道你有沒有寫過串接金流的程式？
但是先付款後出貨，或先出貨後付款
這兩者的處理邏輯就差很大了....
先付款的情況下，不設計逾時未取也沒關係
但後付款的情況下，就要設計逾時未取的機制
JasonQ wrote:
超商的進銷存系統只要每週統計一次餘料數量就好，一個簡單動作回報剩餘數量，下一批配送就扣除這些數量不就好了？
不做扣除棄標數量(餘料數量)豈不更簡單
反正寫程式的不是你
東加一些功能、西加一些功能
反正寫程式的人就是要把沒急迫性的功能也一併完成就對了？
而且以藥局的狀況來說
有些藥局不知為什麼就會剩個零星的數量
藥師說就是賣光了，但不知為什麼數量對不上
你這樣扣餘料數量也沒很保險
個人積分：286分
文章編號：76789627
個人積分：44分
文章編號：76789650
JasonQ wrote:
你都可以接受整個系統多個廠商要合作、要確認收款狀況、要準備退款系統的資訊匹配....
卻認為貨到付款、餘料扣帳會很難設計！！！？
不是難不難設計的問題
而是時效性的問題
有些東西的確是不難設計
但不代表不用花時間去設計、撰寫、測試...
我寫過銷售系統中串接金流的程式，你想討論也行
不過我想知道你有沒有寫過串接金流的程式？
反正寫程式的不是你
東加一些功能、西加一些功能
反正寫程式的人就是要把沒急迫性的功能也一併完成就對了？
一個多月前貼過的
雖然一些細節不太一樣
但基本概念應該是差不多的
https://www.mobile01.com/topicdetail.php?f=638&t=6015201&p=1#76367313
簡單說
(方法一)是利用健保系統
(方法二)是利用超商的售票系統
已經一個多月了
如果要用(方法二)來開發也早就可以弄出來了
例如火車票(用身分證號訂票)可以透過超商售票系統取票
所以只要比照火車票的做法進行一些修改
全國的四大超商總數大約是11500左右
四大超商+健保藥局=18000個點，增加不少通路
個人積分：286分
文章編號：76789776
mig33 wrote:
不是難不難設計的問題...(恕刪)
所以這系統是你開發的？
所以你知道開發這個系統沒有給工程師時間開發？
你既然做跟串接金流的系統，那你應該知道“貨到付款”走的是超商的金流系統？收到錢就入帳，沒收到錢就標注棄標...
對口罩分配系統設計來說，更省下了串接預付金流的程式碼與驗證不是嗎？
一個很簡單的設計不做，卻選擇超商金流以外的第三方廠商金流？堅持做預付？（還要擔心付款系統會不會因為人數過多而崩潰....）
然後你跟我說，工程師沒時間驗證系統？
PS. 我支持擴展通路到超商、超市...或是其他商業通路。但是我不認為需要大張旗鼓的透過預付系統支付費用。甚至於....
只要保留貨到付款付款方式就好！！
系統既簡單、也不用擔心付款系統湧入過多使用者而崩潰，更不用擔心退款、保留貨品的問題....
對了！現在藥房的配送方式可是貨到付款系統呢！
追加新的付款模式比沿用已有的金流模式還要簡單！！！？
個人積分：44分
文章編號：76789816
JasonQ wrote:
所以這系統是你開發的？
所以你知道開發這個系統沒有給工程師時間開發？
你既然做跟串接金流的系統，那你應該知道“貨到付款”走的是超商的金流系統？收到錢就入帳，沒收到錢就標注棄標...
對口罩分配系統設計來說，更省下了串接預付金流的程式碼與驗證不是嗎？
如果這個東西像你說的那樣
那為什麼大多數的線上零售系統都是先付款再處理出貨？
(月結的不算)
雖然PChome、Momo、Yahoo....現在都有貨到付款的選項
但在更早期時，這些系統的確都是先付款才出貨
沒道理一個你口中比較簡單的模式(貨到付款)反而比較晚期才出現
"串接預付金流的程式碼與驗證碼"也不難
你還是先回答你到底有沒有寫過串接金流的程式？
個人積分：286分
文章編號：76789991
mig33 wrote:
如果這個東西像你說的...(恕刪)
1. 所以這是沒當過總統不能批評蔡英文的邏輯？
2. 你提的網購系統設計考量主要在於：
a. 資金走自己的金流系統可以做最大化的資金運用 - 不用等物流廠商月結貨款
看看淘寶為何要推動支付寶就知道了...
b. 棄標退換貨的成本問題 - 網購平台不是獨家賣家，商品也不是人人爭搶的商品，被取代性很高，也沒有實名懲罰辦法，更不用說....沒有防疫需求的大義保障賣家的權益....
你覺得，政府目前販賣口罩、分配口罩是為了獲利？ 是為了掌控金流？
更不用說....預付收款還要考慮付款給廠商月結模式的帳務問題....
我上面也補充了，目前藥房分配模式不就是貨到付款？ 不用現有金流系統，而是用新的付款金流？
個人積分：44分
文章編號：76790163
JasonQ wrote:
1. 所以這是沒當過總統不能批評蔡英文的邏輯？
所以每一件事不管正不正確，你都要批評？
不正確的你固然要批評
但大致正確的你也是要批評？
JasonQ wrote:
看看淘寶為何要推動支付寶就知道了...
我用支付寶的情況下
也是要先付款，賣家才出貨啊
只不過先付的錢是由支付寶保管
JasonQ wrote:
我上面也補充了，目前藥房分配模式不就是貨到付款？ 不用現有金流系統，而是用新的付款金流？
藥房的模式比較像是"商品寄賣"模式
每個模式都有每個模式最適合的做法
一堆人都知道"貨到付款"被棄標的現象不算少
你看看已經公佈的口罩2.0規則有沒有關於棄標的定義和罰則？
https://www.cna.com.tw/news/firstnews/202003105012.aspx
沒有棄標的定義和罰則的情況下
當然是把系統設計成先付款再出貨
你這麼有心，你趕快擬一下棄標的定義和罰則
讓大家一起討論看看你"建議"的做法有無問題好嗎？
說不定口罩3.0版就納入貨到付款和棄標罰則....
補充：
附上"人話神話"介紹供你參考
生小孩就是需要九個月，這是很難的問題嗎？
這是需要時間才生的出來，但技術上並不難啊
https://zh.wikipedia.org/wiki/人月神话#內容簡介
焦油坑
跟只為私人使用而單獨寫出來的組件程式相比，做出軟體系統產品（programming systems product）所要付出的代價將是九倍以上。估計產品化（productizing）的代價是三倍，若要對組件從事設計、整合、測試，進而凝聚成為一個系統，則代價也是三倍，而且這方面的成本計算基本是獨立的。[1]
“史前時期最駭人的景象，莫過於一群巨獸在焦油坑裏做垂死前的掙扎。不妨閉上眼睛想像一下，你看到了一群恐龍、長毛象、劍齒虎正在奮力掙脫焦油的束縛，但越掙扎，焦油就纏得越緊，就算他再強壯、再利害，最後，都難逃滅頂的命運。過去十年間，大型系統的軟體開發工作就像是掉進了焦油坑裏…… ”
——佛瑞德·布魯克斯[2]
軟體開發的另一個難題，是從單一程式到軟體系統過程中，所造成複雜度的快速上升，期間並需要包含不同的活動與技能，使得軟體開發必須面對多樣性的挑戰。布魯克斯最早認識到設計程式、開發軟體的差別，他以程式與系統、產品的差異，解釋兩者之間的不同，並以3×3的複雜度加以說明。[3]
人月神話
人月神話（英語：The mythical man-month）：這部分講述人力和時間並不呈現線性關係。指出以大量人員和較短的時間，並不能縮短軟體的開發進度。一窩蜂的作業方式無助於軟體生產，且會製造麻煩，產生出更差的軟體。向進度落後的專案追加人力，只會使進度更加落後。因為新進的人員需要時間了解整個專案，而增加額外的溝通消耗。當有N個人必須在這群人之中進行溝通時（無階級關係），當N增加，其輸出M將抵消其效益，甚至倒退（最後幾天所完成的進度，遠不如剛開始幾天所完成的進度。像是發現了許多錯誤）。
●團隊交流公式：n(n-1)/2
●範例：50個開發人員，就要50(50-1)/2=1225個溝通管道
用「人月」來衡量工作規模的大小是危險的，也是一個容易遭到誤解的迷思，使用人月的前提必須是在人力和工時可以互換的情況之下：當一份工作因具有連續性的限制而不可切分時，就算投入再多的人力，也不會對時程有所影響，生小孩就是需要九個月，你叫多少個媽一起生都一樣，軟體工程就是像這樣的工作，因為它必須除錯，而除錯本身就具有連續性的本質。[1]
