不要把能否勝任與自己開發(fā)還是外部購買或者與核心決策還是上下文決策的問題相混淆。你可以購買解決方案，但仍然要能勝任去部署和維護它們。事實上，客戶也要求你如此做。
也許你認為這條原則是不言而喻的:“對于我們所做的來說，我們當然是能勝任的，否則我們?nèi)绾伪３謽I(yè)務(wù)?”為了說明這個原則，我們假設(shè)你有一個因特網(wǎng)產(chǎn)品，如某種SaS平臺、電子商務(wù)產(chǎn)品或其他在因特網(wǎng)上交付的解決方案。
你的團隊對你采用的負載均衡器真正了解多少呢?你多久請求一次外部幫助來解決這些負載均衡器的問題或者實現(xiàn)新功能呢?你的數(shù)據(jù)庫又如何呢?你的開發(fā)人員或DBA知道如何判斷哪些表需要索引，哪個查詢運行得比夢愒四?你知道如何擔表移到文件系統(tǒng)上，減少爭用，提高整體生產(chǎn)力嗎?你的應(yīng)用服務(wù)器又如何?誰是處理這些問題的專家?也許，你對所有這些問題的反應(yīng)是，你并不需要親自做這些事情。你可能從其他人寫的書中讀到過，應(yīng)該發(fā)現(xiàn)自己具有與眾不同的能力的領(lǐng)域，并專注于這些領(lǐng)域。然而判定一個組件是否“非核心”或者該組件究竟應(yīng)該從外部購買還是自己開發(fā)，這并不應(yīng)該與判斷團隊是否有相應(yīng)的能力來掌控所購技術(shù)相混淆。使用第三方或開源數(shù)據(jù)庫絕對沒有問題，但這并不意味著你就不必了解數(shù)據(jù)庫，不必具備對它進行操作和故障檢修的相應(yīng)能力。
你的客戶期望你交付給他們的是一個服務(wù)，而你開發(fā)一個獨一無二的軟件來創(chuàng)建這個服務(wù)只是實現(xiàn)目的的手段。歸根結(jié)底你是在一個服務(wù)業(yè)，這一點不要理解錯了。這是一種必需的心態(tài)，如果缺乏這種心態(tài)，事實證明這會造成公司退化甚至毀滅。 Friendster過于關(guān)注“朋友圈”(F-graph)，這是一種用來計算社交網(wǎng)絡(luò)中人際關(guān)系的復雜解決方案，可能是它在個人社交網(wǎng)絡(luò)竟爭中敗給 Facebook的原因之一。這種關(guān)注背后是一種態(tài)度，一種許多軟件商店都持有的態(tài)度，即“朋友圈”所提出出的難題必須得到解決。這種關(guān)注會造成站點服務(wù)中斷或者響應(yīng)緩慢，因為系統(tǒng)在實時計算人際關(guān)系時會變得緩慢乃至停止運行。與之相反的是關(guān)注服務(wù)，即可用性和響應(yīng)時間比任何特殊功能都重要。軟件只不過是提供服務(wù)的一種手段而已。
但在我們的世界中，你所需要的不只是軟件。基礎(chǔ)設(shè)施對以高可用性的方式按時處理事務(wù)來說也很重要。就像我們可能會過于關(guān)注解決方案中的一個問題一樣，我們也可能會忽略用來提供服務(wù)的架構(gòu)中的其他組件。如果說，為了順利提供服務(wù)，我們必須在軟件方面能勝任，同樣我們必須在與此相關(guān)的其他方面也做到如此。客戶期望得到的是優(yōu)秀的中的組1件出了故障，他們不會體諒你并不是井友者也不是這方面的專家，而且也不會關(guān)心這些。
因此，雖然你不必開發(fā)解決方案中的每一部分(事實上我們也不應(yīng)該開發(fā)每一部分)，但卻要對每一部分都有所了解。對于我們采用的任何東西，我們都要能夠正確地加以使用和維護，并在它們發(fā)生故障時，能夠迅速地予以恢復。通過在自己的網(wǎng)站設(shè)計團隊內(nèi)發(fā)展這些技能或者尋求合作伙伴的支持，可以幫助我們做到這一點。團隊越大，對某個組件依賴越多，我們就越應(yīng)該具有自己的專家。而團隊越小，相應(yīng)組件的重要性越低，我們就越應(yīng)該將事情交付給外包專家去做。但如果依賴合作伙伴提供幫助，那么你們之間的關(guān)系就應(yīng)該不止于大多數(shù)設(shè)備供應(yīng)商所提供的。這些服務(wù)供應(yīng)商必須與你共擔風險。換句話說，他們需要在你的服務(wù)發(fā)生故障時，切身感受到你和你的客戶的痛苦。當客戶因為服務(wù)出現(xiàn)問題而對你大吼大叫時，你絕不能讓自己陷入這樣的境地，一方面要在這些供應(yīng)商的等待隊列中苦苦等待，另一方面最終等到的卻不是高水準的支持。
本文地址：http://knowyourextract.com//article/3526.html
