戰(zhàn)略決策有助于加速軟件項目利用商業(yè)機會，但是IT領(lǐng)導必須注意其中的陷阱和權(quán)衡取舍。

當然，IT領(lǐng)導和客戶都希望每個軟件項目都能更快地被交付。但是快速的開發(fā)也可能會導致錯誤的代碼、低劣的測試、不完整的解決方案，或者更糟的，不安全的軟件。雖然沒有人想要一個失敗的軟件項目，但有時在某些環(huán)境下--包括市場條件、業(yè)務需求、機會之窗--可以證明一些有利于速度的權(quán)衡措施是合理的。

軟件開發(fā)不僅僅是一種邏輯上的努力。它也是一門藝術(shù)，也是許多組織商業(yè)戰(zhàn)略中不可或缺的一部分。如果能夠高效、公平、簡單和安全地完成，在那些重疊的某個地方就存在著獲得更高效的開發(fā)流程的可能性。你只需要知道折衷方案，并做出有利于精簡項目而不是開發(fā)完美軟件夢想的決定。

當IT領(lǐng)導想要加速一個需要快速進行的特定軟件項目時，這里有11個戰(zhàn)略決策可供參考。

控制利益相關(guān)者的夢想

每個人都希望得到反饋，來自營銷團隊、運輸部門和會計部門的利益相關(guān)者都是帶著遠大的夢想來到會議室的。訣竅在于首先找到最容易實現(xiàn)的夢想。在一次奇跡般的會議中，我的軟件團隊發(fā)現(xiàn)，只需在一個表單字段中添加預填充的默認值，就可以為數(shù)據(jù)解析器節(jié)省數(shù)百萬小時的工作。成百上千的銷售代理每天都會從無到有地填寫這張表格。在HTML中多了幾個字符，我們就像天才一樣被對待。

讓利益相關(guān)者腳踏實地將有助于控制項目的范圍。如果你能讓利益相關(guān)者關(guān)注那些更小、更有價值的特性和改進，那么復選框的填充速度就會快得多了。

阻止開發(fā)者異想天開

不僅僅是西裝會讓人忘乎所以。開發(fā)人員也需要腳踏實地。對于項目列表上的每一個項目，開發(fā)人員都將其視為最終嘗試一些聰明的、新的、非常耗時的流行術(shù)語的一個機會。屏幕上有兩列不對齊嗎？現(xiàn)在是時候用純函數(shù)重寫整個堆棧來實現(xiàn)多梯度功率下降優(yōu)化量子學習算法了。

雖然開發(fā)人員的熱情對于實現(xiàn)一個加速的時間表是至關(guān)重要的，但是確保開發(fā)人員的熱情能夠被引導到一個精簡的目標上也是至關(guān)重要的。

削減特性

削減需求似乎是個懶人的游戲。畢竟，如果你將“一切”都重新定義為一個更小的集合，自然就能夠很容易更快完成所有事情了。

但有時，讓團隊集中精力也是必要和有用的。巧妙的方法是確?；A(chǔ)仍然足夠牢固，以便將來能夠重新處理被跳過的特性。例如，確保數(shù)據(jù)庫模式預期了某些增強功能，而這些功能是有人希望在以后的迭代中能夠添加的。如果這僅僅意味著現(xiàn)在需要稍微調(diào)整一下模式，那么當你返回到此過程中被推遲的特性時，也可以節(jié)省時間。

簡化測試

部署代碼的挑戰(zhàn)之一是在運行之前進行測試。最近的趨勢是把所有的東西都拆分成可以獨立運作的小項目。如果每個項目都必須單獨測試，那也就意味著需要進行更多的測試。一些包含大量微項目的新的微服務體系結(jié)構(gòu)必須經(jīng)過多次測試。

顯然你無法擺脫對測試的需求，但其中的一個訣竅是可以測試同時在一起工作的多個項目。有時，將幾個部分捆綁在一起可以消除獨立測試它們的需要。

簡化架構(gòu)

如果你打算去掉一些特性，把一些工作留到以后做，有時你可以重新考慮架構(gòu)的設計。有時則不是。

如果這些功能可能會在下個季度甚至明年出現(xiàn)，那么你最好把基礎(chǔ)保留好。但如果它們不是必需的，那么清除掉架構(gòu)中的大塊內(nèi)容將會是一種極大的解放。

回撥性能的保證

當時間充裕時，每個人都希望在毫秒內(nèi)就得到答案，同時還能夠確保數(shù)據(jù)被復制到三個地理上獨立的數(shù)據(jù)中心上，以防颶風和地震的同時襲擊。誰不想要完美呢？

但通常，高性能也意味著需要大量額外的緩存層、負載平衡層和復制層，而這些額外的層需要花費時間來進行構(gòu)建、配置、調(diào)試和維護。減少開發(fā)時間的最簡單方法之一是說服利益相關(guān)者，如果屏幕刷新時間長了一點，希望他們可以稍微放松，或者打消這個想法--他們中的一些人會因為故障而自動消失。并不是每個項目都像腦部手術(shù)那樣需要那么多的精確度和可靠性。

利用現(xiàn)有的代碼

花費更多時間的最簡單的方法就是探索一種新的技術(shù)。是的，從長遠來看，對下一代進行投資是很重要的，但現(xiàn)在不是有人敲桌子要求更快完成的時候。使用與你在過去幾十個項目中使用的相同的語言和數(shù)據(jù)庫會更快更簡單。你將移動得更快，而且有時還可以重用代碼塊。不僅如此，你還將保持一致性，使開發(fā)人員更容易在項目之間移動。

接受技術(shù)債務

當開發(fā)人員想要完成某些事情時，他們喜歡談論“技術(shù)債務”。通過現(xiàn)在承諾一個有限的或快速的解決方案，開發(fā)人員可以把修復或填補空白的工作留給未來。這是一個需要認真考慮的真實概念，但有時人們的確會想要在操縱流程時調(diào)用它。

一些技術(shù)債務是可以接受的。使用最新的數(shù)據(jù)庫或最新的語言技術(shù)并不總是必要的。有時候，我們可以跳過三代或四代的神奇技術(shù)，直接進入最新的版本。跳躍式的前進可以避免很多頭痛和熬夜。

這是一種藝術(shù)的游戲，它不是沒有危險的。但很多時候，技術(shù)債務的幽靈遠比跳過幾代更新的現(xiàn)實更加糟糕。

開源

太多的項目中有太多的自定義代碼了。如果你想完成某件事情，而很有可能其他人也有同樣的煩惱。有時其他人或組織已經(jīng)啟動了一個開源項目，現(xiàn)在也正是你加入的機會。

開源不是萬能的。天下也沒有免費的午餐。你經(jīng)常需要做出妥協(xié)，并與其他團隊一起工作，以匯集一些適合個人的代碼。當這個流程運行良好時，你只需為開源項目貢獻一小部分時間，那么每個人就都會成功。

使用基本的工具

許多項目都可以使用現(xiàn)成的工具來完成。使用標準web表單（比如Drupal、Google Forms或是Survey Monkey）可以構(gòu)建的內(nèi)容是令人驚嘆的，這些表單也可以將數(shù)據(jù)轉(zhuǎn)儲到執(zhí)行分析的電子表格中。這不是?；^。它甚至可能不會被程序員防御聯(lián)盟稱為是“編碼”工作。但是，如果它可以以一種可靠和可重用的方式交付答案，那么它就是完成大型開發(fā)項目最快的方式。

實事求是

我們都夢想建立一個病毒式的傳播網(wǎng)站，所以我們總是計劃處理最極端的負載。我看到過一些細心的架構(gòu)師描述他們的三層系統(tǒng)，其中到處都有負載平衡器和復制的數(shù)據(jù)庫，所有這些都可以支持一個每天可以照顧100人的項目。如果適當進行擴展是容易的，那就不會是問題，但是增加這些層會增加項目的復雜性，延長構(gòu)建時間，并使維護變得更加復雜。引入新的程序員也會變得困難得多，而解決哪怕是最小的問題也需要長時間的團隊會議。確實，一些較新的無服務器工具（如谷歌App Engine）簡化了伸縮性，但在復雜性和成本方面也需要進行權(quán)衡。

優(yōu)秀的工程師能夠預見未來可能出現(xiàn)的奇怪問題。但是，良好的成本工程需要對可能性有實事求是的態(tài)度，也許，當這些異常值出現(xiàn)時，是可以決定接受糟糕的性能甚至是失敗的。