Re: [討論] 外包的軟體合約通常有具體的需求規範嗎?
※ 引述《Aurim (Who cares?)》之銘言：
: 學藝多久不是重點，重點是客戶完全是未開化的軟體蠻人，就算對方是派學有專精
: 的IT人員來負責初步接洽，但是他們的上級多半不是在這行很有sense的人，愈是
: 在主管職待久的、愈是有內部權威的、記性愈差的，愈傾向朝令夕改，今天不記得
: 昨天決定了什麼，明天又不記得今天決定了什麼，一個月反覆改變意見十次也不奇
: 怪。就不用說尊重專業了：什麼事情是Java或Windows上不能做到的，他們不會在
: 乎；什麼事情是某個平台上很難做到的，他們也不在乎。
:
: 高高在上久了的人，多半不會面對這種朝令夕改的窘境，反而比較像是讓他人面對
: 朝令夕改窘境的人。就像數學家證明「x^n+y^n=z^n，當n,x,y,z為正整數，在n>2
: 時無解」證明了三百年，一個小小的額外要求耗費的工程可能超乎外行人的想像。
:
政府機關的 e 化, 一直就是充滿了這類人的問題.
讓軟體業長不大的, 其實不是需求規格改來改去, 這只是會降低賣方的利潤,
但多數狀況不致於致命, 很少聽說軟體驗收不過, 軟體公司破產的. 反而像
是惡性競爭的手段, 競爭者會跟買方說一些難聽的話鼓動買方去更改功能.
功能常改, 需求不斷, 總是造成很多的商機, 但是都做不好, 所以金額就低,
是一種需求夠多又餓不死人, 但要壯大組成強有力的壓倒性競爭力又不行的
狀態.
舉個例, 就所知的狀況也持續爭議了近 20 年. 大學裡究竟是使用一個
單一的集中式資料(訊)庫好, 還是分散式的資料庫 ? 學校就是老師, 學生.
教師的開課, 學生的課程成績歸教務處. 導師活動輔導, 學生生活住宿則歸
學生事務處. 但教師與職工的人事薪資資料則全在人事室, 早期電腦化, 有
業務就有人就有設備經費, 就照原來的人工系統, 各自建立各自掌管自己的
資料庫. 每次一有涉及的異動就相互埋怨一方沒通知另一方, 老是資訊遲遲
跟不上. 可是一談起集中這些分散的資料庫歸一方管理又如何 ? 連電算中心
都不肯幹, 因為業務單位會趁機把工作丟過來, 但不會把人與經費移過來,
各處也就抱著資料各擁山頭, 永遠上演無法及時更新的老故事, 永遠抱怨匯
出更新的資料不全, 費時煩人. 但也永遠拿經費發包出去一些軟體的案子,
變相僱長工跑腿替單位做雜事, 不然就是僱一些約聘低薪的資訊人員幹手工
活.
那麼能不能解決這種長痛問題 ? 譬如讓電算中心做個收存各分散式資料
庫資料的匯整備援集中系統又如何 ? 好歹解決安全備援也能提供最新的更新
資料通知. 這個建議至少說了十年, 十年前可能太先進, 但現在也不怎麼樣
了, 可是上面的主管永遠就會聽見下面的反對聲音. 畢竟 e 化一做, 很多美
好胡鬧的事會消失, 大家心中都不肯, 所以就長成這樣, 僵在那.
在上的大官都得靠在下的小職員做事, 小職員對 e 化是充滿了恐懼, 聘
人也越來越臨時化, 也越派遣化, 起薪不增反降, 後果就這些大官只能越來
越健忘, 受到壓力都是朝令夕改, 就像馬路挖溝挖了埋, 鋪了又立即挖, 忙
得不亦樂乎, 個個都餓不死也長不大. 這種小額的公務機關軟體外包就像鴉
片, 養一堆小公司帶幾個 PG , 活得辛苦與快樂(又有軟體外包了)也都不知
道為甚麼會辛苦與快樂.
製造工業化與資訊自動化的威脅, 其實都是外來的創意打破既有的壟斷
性利益平衡, 都是入侵式的破壞讓既得性利益自行滅亡. 帶有隱性失業的農
業, 內耗性的政府補貼式小額工程都有這種長不大無從競爭的特色.
在軟體公司都長不大時, 說公務經費機關的軟體外包可能才是鴉片的根源,
可能是太過殘忍, 但這可能是真正的問題根源.
: 在這種環境待久的人會明白，針對這種情況，應對之道不是要求客戶盡快定案所有
: feature request，而是把自己的系統設計得靈活有彈性，不管怎麼改都很好改，
: 可以迅速改好、新增刪改任何功能。
:
: 怎樣以最小程式、資料變動去應付最大需求變化，agile programming, agile
: database management, 一堆agile相關技巧都是用來應付這種鳥事的。台灣的學校
: 不知道要到何年何月才會教這種東西。
:
: Workflow的概念讓資訊系統處理工作流程的變更成了更容易的事情，我們能不能把
: 同樣概念應用到code flow, data flow？從流程圖可以生成BPEL，有些BPEL4J engine
: 可以從BPEL生出Java code來。.NET也有CodeDOM能將表示語意的expression tree
: 自動雙向轉換成C#/VB.NET/IL code，程式功能的修改可不可以簡化成只是重新畫
: 幾個圖，就盡可能重複使用舊code來實作出新功能來？
:
現在也是有人強調資工系的大一就要教 Agile Method , 任何管用的技術方法當然
都要引進, 不然外國的強盜小偷衝進來, 還可能不知道人家端了啥道具, 為何就是
頂不住 ?
: 不斷重複打造大同小異的輪子，你捉摸出萬流歸宗的道理了嗎？程式中會出現的
: design pattern就只有那些，business process pattern就只有那些。可是道行
: 粗淺的程式員還是得為了這些大同小異的東西天天在那邊新增刪改一堆code，時
: 間就是金錢，我們雖然很難管理野蠻客戶的需求變更，但是我們還是可以想辦法
: 把程式員需要的勞動與生出的bug數降到最低。
:
: 從一個系統的各部分可以切割出變動性大小不一的部分。除了面對未開化客戶的
: 反覆變動需求，程式員也可能要面對豬頭SA/SD/主管的變更要求，像是案子做到
: 一半才要變database table schema，要求你變動一些function/method/class/
: interface name，怎樣把變更時間降到最少，可能製造的bug降到最少？這種事情
: ，往往不是在IDE或文字編輯器裏頭用個Replace in files的功能替換一下字句就
: 解決了的。各家IDE近來新增的refactoring功能雖然減輕了人們面對類似要求時
: 的負擔，但是更核心的問題還是少有人觸及：當你一定要面對這類變動時，你能
: 夠有什麼樣的方法，以不變應萬變的，以最少代價去應付這類問題？
:
台灣以前(III SEED Project)也猛講用 Automatic Code Generator 的技術來對付
變動性的需求, 只要泡泡圖重新拉拉線, 規格敘述改寫幾行, 新的程式就自動產生
了. 可是當年的最大問題就是: 需求都定義不明, 規格也說不清, 如何寫出敘述明
確的規格 ? 而方向上就偏往更難的 AI 鑽, 就鑽成個不了了之.
新的方法沒有這麼高段, 也不這麼強調不用寫程式就拉拉線就可以快樂的變出程
式來. 即使有這種東東也不符合生態的變化, 碰上既得利益的 PG 非打死她不可.
現在看見的方法就是融合特定領域的應用, 派熟悉現有產品的一群顧問工程師與
客戶直接溝通, 列出配合客戶需求的項目, 調整可設定的參數表讓整套軟體系統
調適成客戶要的系統. 在整套系統的架構設計就能有彈性與可重組性. PG 不會消
失, 但人家的 Architect 在概念與思惟上讓你比不過, PG 不愛面對客戶就讓受
過訓的客戶顧問與客戶使用者一一懇談, 列出需求所需的參數表, 在整個競爭上
不得罪客戶的既得利益, 但就把跟不上的同行給擠掉了. 無敵的 Automatic Code
Generator 是無敵的變形金剛坦克的思惟, 可是一旦被有資本經費的人掌控了,
可能連造他出來的 PG 都被自己的工具給逼死了, 所以後者想法根本就很難成功.
同樣是面對變動的需求跟規格, 但突破式的創意方法必然是前進的力量大於阻力,
尤其是競爭者陷入迷惑狀況時, 特別有奇襲的功效.
: 第三種需要變更程式的情形，就是既有的code出了bug。當我寫一個新功能，我
: 也有可能同時引入了一個以上的bug。我要怎樣方便測試者與客戶在出問題時，
: 更快找出問題出處，更快解決問題，不用等到我把新引入的bug修掉？人們寫程
: 式時，如果能時時回到這些問題上反覆思索，必然能有所得，讓自己把事情做得
: 更好、更快。在動手寫code之前先把這些事情想好，日後所要花費的額外變動功
: 夫就會減少。
:
: 改變他人，不如改變自己。你不肯接受變更，別人肯，你的生意可能就飛了。
:
軟體工程的某些新方法如果發生一堆人不覺得有甚麼, 而某些人又覺得是有甚麼,
又能應用出一些名堂時, 就要特別的留意, 因為一個上下差距就拉開了競爭力.
Aurim 提到的在新功能增添時可能造成不匹配的 BUG , 如果一方有其方法, 使得
發生的機率低, 其競爭力之強就是可預期的.
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.115.1.146
※ 編輯: ggg12345 來自: 140.115.1.146 (10/10 16:36)
討論串 (同標題文章)
Soft_Job 近期熱門文章
PTT職涯區 即時熱門文章
61
112
