記得十數年前，老仙已經向老闆們建言可考慮與印度軟體公司合作，時至今日，眾所周知印度是全球擁有最多CMM(Capability Maturity Model，軟體能力成熟度模型 )五級的軟體公司的國家，隨之而崇拜印度資訊科技業者蜂擁而至，然而假如今天有人再問老仙對印度軟體開發有甚麼看法的話？老仙的答案恐怕真的有所保留了。如果你搞的不是什麼世紀級大專案，更不是在什麼世界級企業內辦事，我勸你真的要「三思而後行」！
十數年前，本尊因為印度等地的軟體公司對軟體開發流程甚有認識，英語溝通能力也不差，成本也低，在溝通管理以至軟體質量上都有保證。遺憾的是當CMM-5的標籤被廣泛吹噓後，老仙對這些「成功人士(公司)」便感冒了。不是說CMM的制度有什麼問題(按：老仙還不夠格批評SEI。)；也不是說她們對軟體開發不認識(按：CMM-5團隊嘛，一定比老仙厲害。)，然而如果你們像老仙一樣不夠格的話，我勸你還是想清楚才和她們合作。又說些故事給大家聽聽吧：有位客戶發覺他委託開發的手持裝置(mobile device)開機畫面有些字拼錯了，一改就兩個月了；又有位客戶希望在一個軟體畫面的核准方塊(check box)中做不一樣的設定(default setting)動作，結果是三個月後還未開始修改，你能想像這些會在中國人的軟體公司上出現嗎！你懷疑老仙的說法嗎？讓老仙用「最簡潔」的文字告訴當一個簡單修改要求(change request)提出後，「它」將會如何地暢遊大觀園吧！
「它最順利」的旅程開始→業務員篩選→業務部主管批核認可送交研發→專案經理檢示有否超越工作範圍(out of scope)→送交主任系統建構師(software architect)判斷修改對整體架構的影響→審示後由專案經理轉交系統工程師研究解決方案→方案再經專案經理轉交相關測試人員、技術文檔管理者商討→選定最可行、最便捷的方案(此時有可能還沒有認真的涉及工時及報價資料)後書面轉呈業務部→業務員在確認再沒有收費的空間後交出建議，要求客戶確認建議的修改方案是他們最終的要求→是則待收到客戶簽妥文件後再轉交研發部→如沒有任何變更，研發部再仔細計算後發出確切的修改文檔，正式開展修改工程並告知客戶何時可交付驗收。如果「它」途中有什麼不測的變故，以上程序勢必重來一次，精彩吧！
其實上述流程已經被老仙簡化了不少，由此可見，要製作一個有質量保證的軟體真的不容易吧！CMM-5也真的不是蓋的！不過，你的公司真的有能力和她們周旋嗎！？
沒有留言:
發佈留言