我們應該如何面隊國外拋送過來的包呢?難道就就是長期以“包工制”形式一直做下去?
印度一家公司軟件工程師為軟件企業(yè)產(chǎn)品開發(fā)人員講授如何管理軟件測試外包項目。
我們應該如何面隊國外拋送過來的包呢?難道就是長期以“包工制”形式一直做下去?
答案是否定的。很顯然，我們的“包工制”外包項目就是靠實現(xiàn)服務賺錢，如果長此以往，那么我們做的只是低層次的IT企業(yè)或軟件企業(yè)，這種發(fā)展趨勢，決不是中國企業(yè)、中國政府所希望發(fā)展趨勢。
那么我們應該如何逐步演變“包工制”，如何借“外包”把中國的軟件企業(yè)帶到一個更高的境界?
項目外包的核心理念就是“做你最拿手的，其余的讓別人去做”。因此，我們要做好外包項目，也需要從這個理念開始。我們不是沒包接，而是沒有實力和規(guī)模接大包。所以我們要能做好外包項目，做大外包項目，首先我們要有自己最拿手最擅長的招。印度的規(guī)模編碼設計、愛爾蘭的本地化都是在IT市場競爭中獲勝了的接包的招。可是我們國內(nèi)企業(yè)，還需要磨練，還需要更強更深的技術能力和項目管理能力等招術。
軟件外包測試的興起對國內(nèi)軟件本地化企業(yè)意味著什么?筆者認為，意味著更多的機會，爭取更多軟件外包國際市場份額的機會。
筆者試圖通過多年來從事中高端軟件外包工作管理的經(jīng)歷，以一個外包測試項目為例，總結了一些外包測試項目的經(jīng)驗，與讀者共饗，以期達到拋磚引玉，共同提高外包行業(yè)管理能力的目的。限于篇幅，本文僅對測試外包中的風險管理和溝通管理做一個簡單的整理。
與國內(nèi)一直以來比較輕視軟件測試工作不同，在很多歐美軟件企業(yè)中，測試(質(zhì)量控制)是一件非常重要的工程工作。國內(nèi)企業(yè)一般在從事軟件項目開發(fā)的時候，更多的是由開發(fā)人員或者客戶人員在開發(fā)完成之后才進行一些簡單的功能測試工作，很少采用專業(yè)的測試團隊，開發(fā)與測試的比例在4:1以上，甚至高于10:1。因此，多數(shù)中國軟件的質(zhì)量水準相對要低。
與此相反的，在歐美企業(yè)中，質(zhì)量管理人員(包括事后的質(zhì)量控制和事前的質(zhì)量保證)的地位卻高的多。測試也作為一個非常獨立的職業(yè)。在IBM、Microsoft等開發(fā)大型系統(tǒng)軟件公司，很多重要項目的開發(fā)測試人員的比例能夠達到 1:2，甚至1:4。測試活動貫穿于整個開發(fā)生命周期，甚至會比普通開發(fā)人員更早介入項目。測試也是一門更講究科學方法的工程活動，測試的種類也包括單元測試、集成測試、功能測試、性能測試、β測試、驗收測試等等。
本文所介紹項目的客戶是美國一家知名的金融業(yè)軟件及服務供應商。由于金融業(yè)的特點，對于軟件的可靠性、穩(wěn)定性等質(zhì)量要求尤其的高。該公司從2005年開始將部門開發(fā)和測試工作外包到中國地區(qū)，由筆者所在公司在北京和上海分別成立了兩個團隊，采用一種類似ODC(Offshore Development Center，離岸外包中心)的模式。筆者在過去一年半的時間內(nèi)負責北京團隊的建設和管理，從最初的一個測試人員和兩個開發(fā)人員發(fā)展到現(xiàn)在的十幾人的團隊(筆者由于公司內(nèi)部工作安排已經(jīng)于去年下半年離開該項目)。從最初的從事簡單的軟件產(chǎn)品的安裝和數(shù)據(jù)移植測試，到現(xiàn)在從事其核心產(chǎn)品的全面功能測試和自動化測試，團隊的工作越來越受到客戶的認可，在客戶的軟件開發(fā)過程中的重要性也越來越高。按照人員數(shù)量來計算，該項目的測試與開發(fā)人員的比例略高于1:1。
軟件外包工作由于天然存在的地理、語言文化差別，其失敗的風險幾率就大的多了。所以從事外包的管理人員在項目啟動之前尤其要對項目中可能存在的風險因素有一個比較全面地識別和分析。比較好的一種風險識別方法是結構化的頭腦風暴法，通過集思廣益找出所有可能影響到項目進度、成本、質(zhì)量的因素。一個非常重要的風險因素的來源是項目計劃的假設和約束，一旦項目成功所作的假設不能達到，這些就會成為未來影響項目正常進展的問題。
一旦識別出盡可能多的風險因素之后，需要對這些因素進行評估，并不是所有的風險都需要去規(guī)避，所以必須分析哪些風險會對項目產(chǎn)生重大影響，哪些風險發(fā)生的可能性非常高。根據(jù)這些分析結果排出項目中優(yōu)先級比較高的風險因素(比如Top 10列表)，然后針對這些風險分別找出規(guī)避的措施以及風險發(fā)生時的應對舉措。
針對本文中提到的項目，從風險識別的角度來說，自然災害和戰(zhàn)爭等也是被識別的一些因素，由于屬于不可抗力，所以一般并不列入項目風險管理計劃，但不要因此在風險識別階段就將其排除。而時差、測試人員的英語表達能力、中美的文化差異、網(wǎng)絡的穩(wěn)定性和速度(想想前段時間的海底光纜事故)、數(shù)據(jù)傳輸?shù)陌踩?、?jié)假日安排這些做國內(nèi)項目的時候幾乎不會考慮的因素可能會是對項目的致命威脅。
對于每個風險都能找到一定的規(guī)避和減少損失的措施，筆者在項目啟動初期花費了較多時間準備金融領域的業(yè)務知識，通過夜間在家加班與客戶建立了良好的信任關系，建立了定期的會議和匯報機制，很短時間之后就確保了團隊正點上下班也不會存在時差所帶來的障礙。
學習過PMP/PMBOK的朋友可能都知道這么一個事實，一個項目經(jīng)理85%的時間都用在各方面的溝通交流上。很多項目出現(xiàn)問題都不是在技術上碰到難題，而更多的是由于溝通不暢引發(fā)的后果。
以前做國內(nèi)項目的時候一說溝通，很多人就想到要和客戶一起去吃飯喝酒。相對這種非正式的個人之間的溝通，在外包項目管理中更需要建立流暢的正式溝通渠道。這種正式的溝通渠道包括但不限于定期的電視電話會議，正式郵件往來，通過IM的工作聊天，統(tǒng)一的錯誤報告機制(Bug跟蹤系統(tǒng)及其他)等。一個非常重要但經(jīng)常被忽視的溝通渠道就是文檔，尤其是項目計劃，不少項目經(jīng)理都只是把項目計劃當作前期不得不完成的一個文檔，到項目執(zhí)行過程中即使再去閱讀也只是關注進度表部分。其實項目計劃包含了眾多內(nèi)容，除了進度表外，還包括上面提到的風險管理計劃，以及項目的范圍界定和各種項目管理流程(包括需求變更管理流程等)，它在一定意義上是合同的一部分，所以及時的更新、審核(Review)和批準(Approval)不僅僅對項目的監(jiān)控非常重要，對于開發(fā)方來說也是很好的法律上的保護。
正式的溝通還有一點非常需要注意的就是要保證良好的反饋機制。我們都知道信息在傳遞的過程中會受到噪音的干擾，尤其是在多次傳遞的情況下更容易失真。所以在建立溝通渠道的時候要建立起方便有效的反饋途徑。對于重要的文檔，一定要有合適的審核和批準機制。更為有效的一種機制還是利用類似于Mercury的Quality Center這樣的工具，由于其內(nèi)置了工作流，所以任何的問題都必須按照一定的流程進行處理，避免了因為工作忙而忘記了一些重要工作的可能。
最后需要提醒的一點的是，要保留一切溝通過程的證據(jù)。美國的金融監(jiān)管部門對金融業(yè)內(nèi)部的所有電子郵件要求保留至少5年以上以備檢查。在項目中證據(jù)的保留一方面是對自己權益的保護，另一方面也是保持完整的溝通記錄有利于后期出現(xiàn)問題的順利解決。
本站系本網(wǎng)編輯轉載，會盡可能注明出處，但不排除無法注明來源的情況，轉載目的在于傳遞更多信息，并不代表本網(wǎng)贊同其觀點和對其真實性負責。如涉及作品內(nèi)容、版權和其它問題，請在30日內(nèi)與本網(wǎng)聯(lián)系， 來信: 我們將在收到郵件后第一時間刪除內(nèi)容！
[聲明]本站文章版權歸原作者所有，內(nèi)容為作者個人觀點，不代表本網(wǎng)站的觀點和對其真實性負責，本站擁有對此聲明的最終解釋權。
4月2日：工信部規(guī)模以上電子信息制造業(yè)增長48.5%；中芯國際宣布全線日：互聯(lián)網(wǎng)企業(yè)完成業(yè)務收入1990億元；華為去年營收增長3.8%
3月29日：華為小米等手機應用商店暫停下載耐克、阿迪達斯等App；鴻蒙系統(tǒng)即將出世
3月26日：過去4年中蘋果收購的AI公司數(shù)量最多；亞馬遜發(fā)布三駕馬車中國業(yè)務戰(zhàn)略
3月25日：華為將投入超2億美元建設生態(tài)；密斯不看好金融科技公司發(fā)行數(shù)字幣
3月24日：1-2月電信業(yè)務收入2373億元；百度汽車最遲2024年量產(chǎn)
3月23日：2020四季度融合系統(tǒng)同比微弱增長0.2%；銀行推廣數(shù)字人民幣貨幣錢包
/g,); str = str.replace(/[\r\n]/g, ); return str; } var title = 軟件測試外包管理之我見; var description = clearBr( 軟件外包測試的興起對國內(nèi)軟件本地化企業(yè)意味著什么?筆者認為，意味著更多的機會，爭取更多軟件外包國際市場份額的機會。 ); var thumb = ; var url =
