定制軟件app開發(fā)是一項艱巨的任務 - 即使對于非常簡單的解決方案也是如此。這也是您的公司可能進行的最大投資之一。在為您的團隊創(chuàng)建定制解決方案時，把事情做好是值得的。

問題在于，有太多不同的考慮因素需要牢記。各種技術(shù)、運營甚至創(chuàng)意決策都會影響定制開發(fā)項目的最終成功。

閱讀 - 無論您是否收回成本。

項目脫軌的一個常見原因是不同的利益相關(guān)者都專注于自己的一小部分。

設(shè)計師只想談設(shè)計。后端開發(fā)人員無法看到過去的數(shù)據(jù)。最終用戶只關(guān)心他們自己的特定痛點。項目經(jīng)理只是想降低開發(fā)成本。ETC。

如果沒有清晰的總體思路，我們通常會得到一個不能讓任何人完全滿意的解決方案。

今天，我們將介紹您需要了解的有關(guān)構(gòu)建可真正提高投資回報的自定義軟件app的所有信息。

具體來說，我們正在深入探討您選擇走定制路線的情況、您將享受到的好處以及您將遇到的挑戰(zhàn)。

我們還將介紹如何實現(xiàn)這一目標的實際方面 - 整合工具堆棧、建立團隊、資源開發(fā)以及如何構(gòu)建成功的開發(fā)流程。

然后我們將總結(jié) Budibase 如何永遠改變定制構(gòu)建的游戲規(guī)則。

但首先，我們需要回到基礎(chǔ)。

什么是定制軟件app開發(fā)？

這似乎是不言自明的，但實際上需要解開的內(nèi)容比您想象的要多得多。從非常高的層面來看，定制軟件app開發(fā)是構(gòu)建定制軟件來解決您獨特的業(yè)務問題的過程。

當然，還有更多的事情要做。

首先，定制構(gòu)建不只有一種。實際上，這可以采取相當廣泛的形式——從完全新穎的研發(fā)項目到仍然需要一點個性化的相對簡單的解決方案。

除此之外，我們還會遇到一些與如何開發(fā)自定義軟件app相關(guān)的灰色區(qū)域，稍后我們會看到。在定制業(yè)務軟件app方面，找到一種適合所有定義的方法有點困難。

例如，如果您的開發(fā)人員從頭開始編寫新的解決方案，那么沒有人會質(zhì)疑這是自定義構(gòu)建。如果他們在現(xiàn)有軟件app模板的邊緣進行擺弄或更改某些開源解決方案，那么您將陷入更黑暗的境地。

如果他們將您的徽標貼在現(xiàn)成的 CRM 上，我們可能不會將其稱為自定義軟件app。

那么這里的界線在哪里呢？

讓我們退后一步，更詳細地考慮一下自定義軟件app。

什么是自定義軟件app？

同樣，從表面上看，這似乎是一個有點奇怪的問題，但請耐心等待。因此，我們知道定制軟件軟件app是為您的業(yè)務流程構(gòu)建的。通常 - 由于您必須定制 - 它們是從頭開始構(gòu)建的。

無論我們使用什么技術(shù)來構(gòu)建軟件app，這都是事實 - 盡管這仍然是一個重大決定，正如我們將看到的。這可能涉及 JavaScript 和 Python 等常見語言或 NodeJS、Rails 或 Angular 等框架。

我們甚至可以使用軟件app開發(fā)平臺來創(chuàng)建軟件app并在軟件app商店（例如 iOS 和 Android）上發(fā)布它。

同樣，我們會及時回到這個話題。

現(xiàn)在，我們想考慮一下自定義軟件app通常做什么。也就是說，我們可能需要為哪些類型的用例開發(fā)定制解決方案？

這里一個明顯的問題是，如果我們走定制軟件app構(gòu)建的道路，通常是因為我們有市場無法滿足的非常具體的要求。

但一般來說，自定義軟件app是圍繞復制業(yè)務中某些特定流程、規(guī)則集或邏輯的目標構(gòu)建的 - 通常是為了比我們手動更有效地實現(xiàn)這一點。

就其本質(zhì)而言，這將是我們業(yè)務所獨有的邏輯。

因此，我們可能會構(gòu)建一個軟件app，對提交、審查和批準某些特定資源的請求的流程進行編碼——要么是因為現(xiàn)有的解決方案在商業(yè)上不可用，要么在商業(yè)上不可行。

定制或定制

我們已經(jīng)提到過這樣一個事實：定制業(yè)務軟件app開發(fā)在構(gòu)建特定解決方案所需的實際開發(fā)工作范圍方面可能存在很大差異。

因此，舉一個簡單的例子，想想構(gòu)建一個簡單的進氣表單和一個將火箭降落在火星上的腳本之間的區(qū)別。顯然，兩者都是軟件，但它們幾乎不屬于同一聯(lián)盟。

思考這個問題的一種方法是區(qū)分定制和定制。事實上，它們之間仍然沒有清晰的概念界限，但它仍然是一個有用的框架。

那么我們在這里的意思是什么？

一方面，我們擁有從頭開始構(gòu)建的解決方案——真正的定制工具。另一方面，我們擁有基本上現(xiàn)成的解決方案，但我們添加了一些配置、個性化或擴展功能。

這就是我們說有一個頻譜在起作用時的意思。

這每一端都傾向于不同的好處、挑戰(zhàn)、缺點和用例。因此，我們需要的解決方案越量身定制，我們預計需要承擔的工作量、費用和等待時間就越多。

同樣，如果我們選擇定制某些現(xiàn)有解決方案，我們就會在功能、能力、個性化甚至我們可能實現(xiàn)的性能方面受到一定程度的限制。

而且，正如您可以想象的那樣，這兩個節(jié)點之間有一大堆空間。當我們開始考慮企業(yè)用來開發(fā)自定義軟件app的一些特定工具和策略時，這一點將變得更加明顯。

定制與商用

我們可以得出的另一個重大區(qū)別是定制和商業(yè)現(xiàn)成的。事實上，這些實際上是對立的。COTS 工具是您可以購買并向用戶推出的軟件app。

當這是一種選擇時，它通常是一個非常有吸引力的選擇 - 至少，假設(shè)市場上的產(chǎn)品無論如何都具有一定的質(zhì)量。因此，如果我們談論的是諸如文字處理器之類的東西，那么 COTS 選項自然更有意義。

也就是說，當 Word 和 Google Docs 就在那里時，構(gòu)建自己的自定義文字處理器幾乎沒有意義。

就像以前一樣，這里涉及很多權(quán)衡。

當市場上出現(xiàn)商用解決方案時，有趣的問題才真正開始出現(xiàn)?；蛘摺辽佼斢袧撛诘倪x擇時。

在這種情況下，我們需要審查可用的產(chǎn)品，以確定它們?nèi)绾斡行У貪M足我們的要求。我們還需要就財務上最明智的前進道路做出判斷。

定制軟件app開發(fā)的好處是否超過成本。換句話說…

我們什么時候會選擇定制構(gòu)建？

這個問題讓 IT 領(lǐng)導者夜不能寐。我們真正需要知道的是，定制構(gòu)建的業(yè)務案例何時比購買現(xiàn)成產(chǎn)品更有利。我們知道，一種情況是 COTS 工具不可用。

但還有什么時候呢？

為了回答這個問題，讓我們思考一下自定義軟件app開發(fā)的一些最重要的優(yōu)點和缺點。

我們將從專業(yè)人士開始。

定制開發(fā)的好處

正如潛在的用例一樣，企業(yè)將定制構(gòu)建確定為最具吸引力的選擇的具體原因可能存在很大差異。

為了更好地理解這一點，讓我們考慮一下您可能想要實現(xiàn)的一些具體好處。

所有權(quán)

所有權(quán)對于大型組織來說尤其重要。也就是說，真正擁有他們使用的工具。由此產(chǎn)生了一些重要的、切實的好處。

一方面，所有權(quán)與控制權(quán)直接相關(guān)。當我們擁有自己的解決方案時，我們就可以決定如何使用它們。這滿足了從我們?nèi)绾螛?gòu)建技術(shù)能力到維護工具的實際方面的一切。

同樣，在某些情況下，我們可能希望保留對解決方案的所有權(quán)，因為它們是關(guān)鍵任務甚至是絕密的，因此我們會通過使用我們不擁有和控制的工具來創(chuàng)造不必要的風險。

功能性

其他時候，選擇定制構(gòu)建將是實現(xiàn)我們所需功能的唯一方法 - 或者至少是最具成本效益的方法。顯然，這可能是一些完全邊緣的用例，沒有人提供解決方案。

但更常見的是，我們處理的是看起來相對較小的需求，排除了現(xiàn)成的解決方案。典型的例子是對遺留工具或數(shù)據(jù)源的支持。

例如，您的團隊可能需要一個解決方案來實時管理和報告庫存損失/破損。但您的庫存管理系統(tǒng)有點過時，因此市場上的解決方案都不支持它。

最終，您想要更新整個庫存管理堆棧。與此同時，定制解決方案可能是滿足您當前更緊迫需求的最具成本效益的方式。

生命周期管理

這與控制權(quán)和所有權(quán)的概念有關(guān)。這里的基本結(jié)果是，定制軟件app開發(fā)使我們在生命周期管理方面處于主導地位。我們決定何時啟動、更新、擴展和棄用我們的工具。

我們可以指出一些特別重要的場景。一是產(chǎn)品的實際壽命。工具的任務越關(guān)鍵，我們就越希望避免供應商終止支持、取消某個功能或完全停用某個工具。

另一方面，對于 COTS 解決方案，我們需要考慮供應商的路線圖如何與我們的預期需求保持一致。例如，如果我們知道我們將在某個給定點需要某個特定功能，那么供應商是否有計劃實現(xiàn)這一點？

這里的要點是，自定義軟件app開發(fā)本質(zhì)上消除了此類問題，為我們提供了更多的輸入和對解決方案生命周期的控制。

成本

成本是一個非常棘手的問題。事實上，這里并沒有一個簡單的規(guī)則。正如 - 定制軟件app開發(fā)不一定比替代方案更便宜或更昂貴。

不過也有可能。

您看，影響成本/收益計算的因素有無數(shù)，包括您的內(nèi)部 IT 資源、COTS 解決方案的成本、您對特定工具的期望價值、支持安排等等。

因此，我們可能已經(jīng)擁有一支內(nèi)部開發(fā)人員團隊?；蛘?，我們可能根本沒有 IT 部門。我們需要找出從長遠來看最具成本效益的采購解決方案是什么。

稍后我們將考慮自定義軟件app開發(fā)項目的一些對其成本產(chǎn)生巨大影響的方面。

可擴展性

與生命周期管理一樣，自定義軟件app開發(fā)提供了可擴展性方面的優(yōu)勢，因為我們比 COTS 解決方案擁有更大的靈活性和影響力。

與以往一樣，我們可以指出兩種不同的可擴展性類別：水平和垂直。例如，我們添加新功能的容易程度與添加新用戶或容量的容易程度之間的關(guān)系。

其中每一個都可能受到多種方式的影響，包括技術(shù)和許可方面的考慮。

問題的關(guān)鍵在于，如果您將來想要修改或構(gòu)建您的解決方案，您需要自己完成此操作。當然，另一方面是我們不需要等待供應商也這樣做。

安全

最后，我們有安全保障。對于大型組織來說，這通常是進行定制開發(fā)的真正動力。無法回避的事實是——至少有時——滿足我們安全需求的最佳方式是使用完全定制的解決方案。

這可能是因為您需要實現(xiàn)特定的工具來保護您的軟件app - 或者涉及第三方本身可能會造成安全漏洞。

其他時候，關(guān)鍵的是托管和部署。例如，您可能會受到內(nèi)部規(guī)則的限制，這些規(guī)則規(guī)定某些類型的解決方案必須自托管，甚至托管在特定類型的硬件上。

自定義軟件app還提供了使用我們自己的身份驗證工具或 SSO 的可能性。

定制開發(fā)挑戰(zhàn)

當然，定制軟件app開發(fā)帶來了一系列我們無法用 COTS 工具應對的挑戰(zhàn)。其中一些是非常明顯的。其他可能不是你首先想到的事情。

其他的實際上只是我們剛才經(jīng)歷過的好處的另一面。

因此，值得探索我們可能遇到的一些實際問題。

讓我們直接開始吧。

為內(nèi)部開發(fā)項目提供資源

大多數(shù)企業(yè)在定制開發(fā)時最擔心的無疑是成本。這主要包括勞動時間。就像 - 你需要向開發(fā)人員支付工資。

當然，這是假設(shè)您目前雇用內(nèi)部開發(fā)人員 - 但您很可能沒有雇用內(nèi)部開發(fā)人員。這似乎是一個顯而易見的觀點，但它具有巨大的影響，因此值得詳細說明。

您擁有的現(xiàn)有開發(fā)能力越多，您就越能夠吸收新項目 - 包括在分配資源時。

例如，如果您必須從頭開始構(gòu)建團隊，則自定義項目的前期成本將會高得多。即便如此，當今的企業(yè)仍面臨全球合格開發(fā)人員的短缺，這使得尋找人才變得異常困難。

不幸的是，這可能意味著定制開發(fā)僅對某些類型的企業(yè)開放 - 至少使用傳統(tǒng)的開發(fā)工具。

管理定制開發(fā)項目

無論我們是內(nèi)部還是外包定制開發(fā)，我們都將面臨管理項目的挑戰(zhàn)。你看，構(gòu)建軟件時可能會出現(xiàn)很多問題。在很多情況下，這又回到了金錢的問題上。

盡管這看起來很瘋狂，但定制開發(fā)項目超出預算幾乎是常態(tài)——要么是因為范圍蔓延、雄心勃勃的時間估計、不可預見的依賴關(guān)系，要么是其他一些問題。

首先，我們需要以與任何其他類型的人才完全相同的方式來考慮項目管理時間。

這里重要的是，有效的項目管理技能可以幫助我們避免許多我們可能認為是定制開發(fā)生活中的事實的大問題——比如錯過最后期限、預算膨脹和溝通不暢。

不幸的是，找到合適的項目管理人才本身就是一個挑戰(zhàn)。

連續(xù)性問題和保留知識

我們在定制開發(fā)中要處理的一個問題是知識保留和連續(xù)性，這不是 COTS 解決方案的一個因素。

我們在這里是什么意思？

理解知識保留的一個簡單方法是從這樣一個前提開始：沒有人比構(gòu)建解決方案的人更了解解決方案。因此，他們可以更輕松地維護、支持或擴展相關(guān)工具。

但是，我們需要平衡這一點與現(xiàn)實，即開發(fā)人員在職業(yè)生涯中傾向于從一家公司跳到另一家公司。因此，我們的挑戰(zhàn)是通過確保在定制項目期間記錄隱性知識來減輕這種影響。

這可能意味著實施正式的知識庫工具或定義關(guān)于代碼庫中的注釋的明確規(guī)則和期望。

實際上，內(nèi)部構(gòu)建比外包構(gòu)建要容易一些——因為我們有更高程度的監(jiān)督和控制。

吸收風險和責任

最后，當我們選擇定制軟件開發(fā)時，我們需要承擔額外的風險。這里的基本原則是——尤其是內(nèi)部構(gòu)建——如果出現(xiàn)問題，沒有人可以責怪外部人員。

根據(jù)我們合同的具體情況，外包構(gòu)建的情況可能會略有不同 - 盡管我們?nèi)匀槐仁褂?COTS 工具承擔更多的風險。

那么我們談論的是哪些類型的風險呢？

最大的一個是項目失敗- 這意味著您的解決方案要么從未交付，要么無法解決其針對的問題。由于相關(guān)的沉沒成本，這種情況發(fā)生得越深入，效果就越差。

其他重大風險包括錯過最后期限或解決方案不滿足其初始要求的更多次要情況。

我們還需要考慮定制軟件開發(fā)所承擔的額外責任。

這些是我們承擔的責任，而其他采購策略可能不需要我們承擔這些責任。因此，如果我們購買現(xiàn)成的工具，我們通常不需要擔心維護代碼庫，但對于自定義構(gòu)建，我們可能需要擔心。

同樣，我們最終將承擔額外的責任，如托管、支持、入職和其他相關(guān)成本，如果我們選擇 COTS 解決方案，我們可能不會承擔這些成本。

這些并不是無法克服的挑戰(zhàn)，但它們確實表明在確定自定義軟件app是否確實是最可行的選擇時需要非常仔細的考慮。

定制軟件app開發(fā)流程只需 9 個步驟

當然，仔細考慮是一回事。更好的是，我們有一個清晰的、可重復的框架來確定在我們的特定情況下什么是最佳選擇。

這正是我們將在自定義軟件app開發(fā)過程的九步指南中提供的內(nèi)容。更具體地說，我們將詳細介紹您將解決方案從構(gòu)思到推出時需要做出的核心決策。

讓我們深入了解一下。

1. 問題設(shè)置

首先，我們必須選擇一個我們認為可以通過自定義軟件app改進的用例。當然，在很多情況下，我們不會像突然出現(xiàn)的那樣去尋找用例。

即便如此，我們?nèi)匀恍枰宄亓私馕覀兿胍褂米远x解決方案解決的確切問題，然后才能進一步進行。

這意味著回答一些具體問題。一個明顯的起點是我們需要我們的未來解決方案做什么。我們也可以更深入地探究原因。因此，我們需要嘗試并了解相關(guān)流程在實現(xiàn)更廣泛的業(yè)務目標中的作用。

如果我們改進該流程的性能，它將如何影響我們的利潤？

我們還需要考慮誰將使用您的解決方案，以及誰將從中受益（因為這些人可能不是同一個人）。

2. 需求收集和用戶研究

明確定義我們的核心問題后，我們可以開始將其轉(zhuǎn)化為更具體的技術(shù)要求。

假設(shè)我們想要構(gòu)建一個工具來管理我們的員工如何與客戶來回發(fā)送合同。要為此創(chuàng)建功能要求列表，我們可以首先列出每種類型的用戶應該能夠執(zhí)行的每個操作- 以及不需要用戶的操作。

幾分鐘后將詳細介紹第二部分。

我們還需要考慮所謂的非功能性需求。我們可能對某個特定解決方案有某些需求，但這些需求與其本身的用途無關(guān)。例如，對特定托管平臺或 SSO 工具的支持。

最后，我們希望進行徹底的用戶研究。具體來說，我們需要了解核心用戶的需求 - 包括他們的數(shù)字素養(yǎng)水平、用戶體驗偏好、典型設(shè)備使用情況以及可能影響我們選擇構(gòu)建的解決方案的任何其他因素。

3. 數(shù)據(jù)建模

接下來，我們可以開始考慮軟件app的數(shù)據(jù)層。我們需要做的第一件事是創(chuàng)建一個理論圖景，稱為數(shù)據(jù)模型。本質(zhì)上，這是我們的軟件app執(zhí)行我們想要的操作所需的所有數(shù)據(jù)的概述。

首先，它需要的每個數(shù)據(jù)實體。例如，在我們前面的示例中，這可能是客戶、員工、合同和請求。然后，我們可以針對這些實體存儲的每個屬性 - 客戶端可能有名稱、地址和電話號碼。

接下來，我們要定義每個實體之間的關(guān)系。一個客戶可以有很多合同。每份合同必須有一名客戶和一名員工。ETC。

最后，我們需要定義數(shù)據(jù)的來源和存儲位置 - 無論這意味著創(chuàng)建一個全新的數(shù)據(jù)庫還是依賴于現(xiàn)有源的連接。

查看我們有關(guān)如何開發(fā)數(shù)據(jù)模型的指南 以了解更多信息。

4. 定義流程

數(shù)據(jù)模型就位后，我們接下來需要做的就是將可能的應用內(nèi)操作列表轉(zhuǎn)換為可應用于我們剛剛定義的實體的流程 - 以及如何執(zhí)行這些操作。

讓我們考慮幾個例子來說明我們在這里的意思。

在我們的合同管理示例中，我們需要員工能夠使用其狀態(tài)屬性來跟蹤客戶是否已閱讀其合同。我們需要合約遵循的定義的事件序列，在每個事件之后更新其狀態(tài)屬性。

例如，一旦客戶端打開文件，狀態(tài)屬性就會更新為read。

我們在這里所做的本質(zhì)上是為我們每個可能的操作定義if this, then this規(guī)則。

此時，我們還將考慮哪些操作應該自動化。例如，通知客戶已在其名下創(chuàng)建了一份新合同，或通知員工其合同之一的狀態(tài)屬性已更改。

5、界面設(shè)計

定義了流程后，就可以開始設(shè)計界面了。

根據(jù)您使用的自定義軟件app開發(fā)工具，這在實踐中可能看起來相當不同。因此，我們不要陷入特定工具和方法的泥潭，而應該思考我們想要實現(xiàn)的目標的原則。

對于大多數(shù)自定義軟件app開發(fā)項目，我們并不完全擔心如何娛樂我們的用戶。相反，我們的目標是找到最有效的方法來指導用戶執(zhí)行定義的操作，而不影響準確性。

為了實現(xiàn)這一目標，我們可能會選擇使用專門的設(shè)計人員，然后他們將他們的線框圖傳遞給開發(fā)人員來創(chuàng)建工作軟件app?；蛘呶覀兛赡軙褂酶F(xiàn)代的軟件app構(gòu)建實踐，例如低代碼開發(fā)。

稍后我們會更多地考慮這個問題。

6. 發(fā)展

數(shù)據(jù)模型、流程層和 UI 設(shè)計就位后，我們就可以開始將它們整合在一起。至少，這就是傳統(tǒng)軟件app開發(fā)項目中的工作方式，其中每個元素基本上都是單獨硬編碼的。

然后，它們?nèi)拷M合成一個工作軟件app。

當然，現(xiàn)在這不是唯一的選擇。看，從技術(shù)角度來看，大多數(shù)內(nèi)部業(yè)務構(gòu)建并不那么復雜，因此從頭開始對所有內(nèi)容進行硬編碼不一定是最具成本效益的選擇。

相反，越來越多的自定義軟件app開發(fā)利用現(xiàn)代工具來幫助加快這一過程。

稍后我們將看到 Budibase 如何在這方面發(fā)揮帶頭作用。

7. 測試

有了可用的軟件app，我們就可以進入開發(fā)項目的測試階段。

然而，測試并不是一個單一的事情。

相反，我們需要測試軟件app的各個不同方面。您首先想到的可能是功能測試。換句話說，檢查以確保我們的軟件app執(zhí)行我們期望的操作。

還有用戶測試。一旦我們知道我們的軟件app實際上可以正常工作，我們就需要弄清楚我們的用戶界面的有效性。那么，用戶是否直觀地知道如何執(zhí)行不同的操作？

他們能如此快速準確地做到這一點嗎？他們需要額外的培訓嗎？

這是一個很容易被低估的領(lǐng)域，但我們可能會對項目的投資回報率產(chǎn)生巨大的影響 - 特別是如果我們預計會有更大的用戶量。

最后，我們可以考慮一些更宏觀的東西，這些東西至少與測試松散地聯(lián)系在一起。具體來說，是與我們的核心用例相關(guān)的問題。請記住，我們最終試圖通過定制開發(fā)解決一些特定的業(yè)務問題。

我們需要部署工具來幫助我們衡量進展情況 - 無論是自動報告、自定義儀表板還是其他策略。

8. 推出

當我們確信我們的解決方案能夠有效地發(fā)揮作用時，就該推出了。這是我們定制開發(fā)項目的另一個階段，可以決定投資回報率的成敗。

考慮這里的挑戰(zhàn)規(guī)模的一種方法是從操作角度概念化您的軟件app推出，就像它是一項技術(shù)練習一樣。因此，一方面，我們面臨著表面上的技術(shù)挑戰(zhàn)，比如實際部署我們的解決方案。

另一方面，我們面臨著同樣重要的軟挑戰(zhàn)，例如安排、記錄和提供培訓。

同樣，推出新解決方案與您如何淘汰要替換的任何工具密切相關(guān) - 無論這是另一個軟件app還是管理相關(guān)工作流程的其他策略。

例如，如果我們的用例類似于訂單處理，我們不能有任何服務中斷，那么我們需要圍繞這一事實制定策略。這可能需要精心設(shè)計的轉(zhuǎn)換活動或更漸進的推出。

無論如何，到此階段結(jié)束時，您的現(xiàn)實世界用戶應該可以啟動并運行您的自定義軟件app。

9、維護與優(yōu)化

最后，我們將在解決方案上線后繼續(xù)對其進行管理。從一些相互關(guān)聯(lián)但仍然獨立的線索來思考這個問題是很有用的。第一個是典型的維護和支持活動。

換句話說，確保您的軟件app繼續(xù)按您的預期工作，包括查找錯誤并推出補丁和修復。

下一步更關(guān)注更新我們的解決方案。這和維護之間的界限很模糊——但區(qū)別在于我們所做的任何改變的新穎程度。因此，錯誤修復和全新功能之間的區(qū)別。

最后，我們進行了優(yōu)化。也就是說，努力讓我們的工具更加有效。實踐中的情況很大程度上取決于我們的基本目標。例如，我們同樣可以依賴性能改進、用戶體驗優(yōu)化或流程更改。

在這三個方面，重要的是要記住，我們的需求幾乎不可避免地會隨著時間的推移而發(fā)生變化——跨越許多不同的層面。因此，我們可能需要應對全新的挑戰(zhàn)，或者我們可能只是需要隨著時間的推移增加容量或用戶。

這里需要認識到的重要一點是，定制軟件app開發(fā)的本質(zhì)意味著這是我們的問題。我們沒有足夠的供應商來為我們擔心這個問題。

因此，我們無法回避的另一個因素是需要選擇為我們提供很大程度的靈活性和敏捷性的開發(fā)工具和方法。

在接下來的幾個部分中，我們將深入探討這些主題。

讓我們首先檢查一下自定義軟件app開發(fā)方法。

軟件app開發(fā)方法

在我們深入研究可用的具體選項之前，值得停下來思考一下我們所說的方法論到底是什么意思。基本上，這是我們應用于項目的系統(tǒng)或開發(fā)方法。

這決定了我們項目的結(jié)構(gòu)，以及我們使用的工具、相關(guān)人員的角色、相對的資源占用，以及我們?nèi)绾螛?gòu)建工具的一系列其他元素。

說明這一點的最好方法就是直接介入。因此，以下是我們可以使用的主要軟件app開發(fā)方法。

傳統(tǒng)方法和瀑布方法

首先，我們有基于瀑布的方法。這些確實是鎮(zhèn)上幾十年來唯一的演出，但現(xiàn)在它們不再那么流行了。這個名字是關(guān)于它們?nèi)绾喂ぷ鞯囊粋€很好的線索。

基本上，在瀑布框架內(nèi)，自定義軟件app開發(fā)項目遵循高度不靈活的固定順序。我們收集我們的需求，然后制定我們將如何預先實現(xiàn)這一目標的路線圖。

在前一個階段完成之前，我們無法進入項目的下一階段。一旦我們繼續(xù)前進，就沒有回頭路了。

如果我們從一開始就確切地知道我們想要構(gòu)建什么，并且我們知道我們絕對不想偏離這一點，那么這很好。然而，在我們需要更多靈活性的情況下，它并不理想。

不幸的是，這是大多數(shù)軟件項目。

看，需求發(fā)生了變化?；谄俨嫉姆椒ǖ膯栴}在于它們未能考慮到這一事實。這通常會給我們留下符合我們要求的解決方案，但并不能真正解決他們要解決的問題。

這在很大程度上解釋了過去二十年左右替代方法論的流行。

敏捷方法論

到目前為止，其中最普遍的是敏捷。這是對我們一直在探索的傳統(tǒng)方法的一些缺點的回應。具體來說，它尋求比瀑布項目提供更多的變化適應性。

這需要我們改變構(gòu)建自定義軟件app開發(fā)項目的方式。

其關(guān)鍵特征是構(gòu)建軟件的迭代方法。這意味著我們逐步構(gòu)建軟件，分階段可能只持續(xù)幾周或幾個月——每個階段都致力于構(gòu)建的特定方面。

這樣，如果我們遇到不可預見的問題、邊緣案例或我們對核心問題的理解發(fā)生變化，我們就可以更靈活地調(diào)整我們的方法。在每次迭代中，我們從需求收集到交付我們需要的功能子集。

我們通常會對每次迭代中的內(nèi)容有一個路線圖，但是當我們發(fā)現(xiàn)新的需求時，這也可能會改變。

這樣做的好處是，我們可以更加緊密地關(guān)注我們要解決的具體業(yè)務問題。一個潛在的缺點是，我們在項目一開始就無法準確掌握要構(gòu)建的內(nèi)容。

這使得敏捷構(gòu)建不適合某些類型的軟件app項目 - 特別是如果相關(guān)軟件app需要以非常特定的方式與項目的其他方面相適應 - 就像我們之前關(guān)于計算著陸模塊軌跡的示例。

精益方法論

精益是作為傳統(tǒng)瀑布式思維的替代方案而出現(xiàn)的另一類方法論。這是基于簡化流程和持續(xù)改進的雙重原則。

具體來說，這意味著圍繞四步循環(huán)構(gòu)建開發(fā)項目——識別、計劃、執(zhí)行和審查。

因此，我們解決一個問題，弄清楚我們想要如何解決它，實施我們的解決方案，然后考慮哪些有效，哪些無效。

不過，這種配對開發(fā)方法只適合某些類型的項目。

也就是說，由較小的團隊構(gòu)建的相對簡單的解決方案，可以輕松管理構(gòu)思和審查會議。

RAD、公民開發(fā)和無/低代碼開發(fā)

到目前為止，我們所看到的方法很大程度上假設(shè)我們正在與傳統(tǒng)的開發(fā)團隊合作。然而，這不一定是企業(yè)進行定制軟件app開發(fā)的一貫方式。

面對全球合格開發(fā)人員的短缺，許多公司正在轉(zhuǎn)向替代策略 - 要么充分利用現(xiàn)有的開發(fā)人員，要么授權(quán)其他用戶創(chuàng)建自定義軟件app。

最值得注意的是，分別通過快速軟件app開發(fā)和公民發(fā)展。

兩者都有可能大大減少輸出解決方案所需的時間和金錢 - 但這依賴于用正確的技術(shù)支持我們的努力。

這是過去幾年無代碼和低代碼開發(fā)平臺迅速流行的領(lǐng)域之一。

此類平臺旨在使用戶能夠更快地執(zhí)行常見的開發(fā)任務，或者完全消除某些類型的開發(fā)需求。

稍后我們將更詳細地探討其工作原理。

定制軟件app開發(fā)工具

這是一個巨大的主題 - 坦率地說，遠遠超出了任何博客文章可以全面涵蓋的范圍。相反，值得做的是運行我們需要熟悉的工具類。

在這里值得重申的是，定制開發(fā)可以涵蓋絕對巨大的用例范圍，其中許多用例需要自己的利基工具 - 而且我們也不可能在這里展示全部可能性。

相反，我們專注于最典型的內(nèi)部構(gòu)建。考慮到這一點，對于大多數(shù)業(yè)務軟件app，您可能需要記住以下類型的自定義開發(fā)工具。

傳統(tǒng)開發(fā)、編碼語言和框架

我們將從您可能最熟悉的傳統(tǒng)工具方式開始構(gòu)建軟件。硬編碼解決方案。直到最近，絕大多數(shù)自定義軟件app都是通過坐下來實際編寫自定義代碼來構(gòu)建的。

例如，JavaScript、Python、C#、.Net 或任何其他編程語言。

在其中的每一個中，我們還將依賴各種框架和庫來幫助加速不同類型的開發(fā)任務。

事實上，這是一種無處不在的做事方式，您可能永遠不會停下來思考傳統(tǒng)軟件app構(gòu)建工具的優(yōu)缺點。

明顯的賣點是——至少在特定語言可以實現(xiàn)的范圍內(nèi)——我們實際上只受到我們擁有的編碼技能所能實現(xiàn)的限制。

缺點是我們需要很高的技能水平才能做任何事情。開發(fā)人員的工資很高，但從技術(shù)角度來看，內(nèi)部構(gòu)建通常相對簡單，因此這里的成本/收益計算有很大的優(yōu)化空間。

在本文的其余部分中，我們將看到一些實現(xiàn)此目的的策略。

數(shù)據(jù)管理工具

數(shù)據(jù)管理工具本身就是另一個大話題。我們之前看到，準確、有代表性的數(shù)據(jù)是任何數(shù)字解決方案的基礎(chǔ)。毫無疑問，我們?nèi)绾喂芾磉@些數(shù)據(jù)也至關(guān)重要。

最明顯的挑戰(zhàn)與實際構(gòu)建自定義軟件app的數(shù)據(jù)層有關(guān)。

數(shù)據(jù)庫管理 (DBMS) 工具自然是其中最重要的元素之一 - 包括 MySQL 或 Postgres 等家喻戶曉的名字，以及 GraphQL 和 NoSQL 平臺等較新的參與者。

然而，對于許多現(xiàn)代解決方案，我們需要更廣泛地思考數(shù)據(jù)如何在整個組織中移動，而不是應用僅考慮某一特定軟件app所需的數(shù)據(jù)的孤立思維。

這使得許多 IT 團隊將注意力轉(zhuǎn)向有效的數(shù)據(jù)倉庫和管道解決方案。

請查看我們的數(shù)據(jù)管理工具指南以了解更多信息。

開發(fā)環(huán)境、版本控制和協(xié)作工具

與我們剛才所說的硬編碼解決方案不同，還有開發(fā)人員如何以及在何處編寫、部署和協(xié)作代碼的問題。

根據(jù)您的團隊規(guī)模和項目的具體情況，您可能在這里有嚴格的政策，或者您可能為開發(fā)人員提供一定程度的靈活性以使用他們自己喜歡的工具。

像您選擇的 IDE 這樣簡單的事情可能會對項目的成功產(chǎn)生巨大影響 - 不同的平臺提供各種生產(chǎn)力功能、快捷方式以及對特定技術(shù)的支持。

版本控制是另一個重要問題，既允許同事在生產(chǎn)中就代碼庫的不同方面進行協(xié)作，又允許他們在解決方案上線后維護和支持解決方案。

托管和部署工具

我們還可以考慮您的開發(fā)團隊將如何部署和托管您的解決方案 - 無論這意味著使用本地基礎(chǔ)設(shè)施、云平臺還是混合解決方案 - 每個解決方案都需要自己的特定工具堆棧來支持您的工作。

目前，這里的熱門問題無疑是容器化——將運行軟件app所需的所有資源捆綁到可以在任何環(huán)境中托管或部署的容器中。

我們還需要考慮 DevOps 要求，包括管理容量、基礎(chǔ)設(shè)施監(jiān)控和維護的平臺，以及一整套安全性、可訪問性和身份驗證工具。

稍后我們將了解 Budibase 如何處理自定義軟件app的托管和部署。

設(shè)計工具

以完全不同的方式，我們擁有您的團隊用來設(shè)計軟件app前端界面的平臺。

這是我們可能會看到不同企業(yè)之間差異最大的一個領(lǐng)域。一方面，我們擁有完全硬編碼的設(shè)計，依賴于 CSS、HTML、Rails、React、Angular 或其他編碼語言。

另一方面，我們擁有完整的視覺設(shè)計工具，例如拖放所見即所得編輯器、軟件app構(gòu)建工具和其他平臺，使我們能夠構(gòu)建界面，而無需具備太多技術(shù)技能。

然后我們在這兩個極點之間有一個非常擁擠的空間。

然而，您需要在此處做出的關(guān)鍵決策相對簡單。如果您的團隊只構(gòu)建相對簡單、重復的界面，那么每次都從頭開始花費精力和費用就沒有多大意義。

例如，Budibase 提供完全自動生成的 CRUD 屏幕，使您可以在幾秒鐘內(nèi)輸出工作業(yè)務軟件app。

無/低代碼開發(fā)工具

最后，我們有低代碼和無代碼平臺，我們之前提到過。簡而言之，這些旨在加快構(gòu)建自定義軟件app的過程并使之民主化。

但重要的是，我們可以指出這個市場中的一些不同細分市場，這些細分市場有助于我們熟悉。

概念化這一點的一種方法是考慮目標用戶。

因此，在市場的一端，我們擁有旨在允許非開發(fā)人員構(gòu)建解決方案的工具。這更像是無代碼部分，正如您可能期望的那樣，其想法是用戶可以輸出解決方案，而不需要知道如何編碼。

在市場的另一端，我們有針對專業(yè)開發(fā)人員的工具。這里的核心思想是加速特定類型的構(gòu)建任務，而不是必然降低進入門檻。

正如您可以想象的那樣，兩極都需要權(quán)衡。使用更易于訪問的無代碼工具，您通常會看到相應的較低水平的靈活性或?qū)Ω嗬δ艿闹С帧?/span>

相比之下，更復雜的工具（尤其是傳統(tǒng)供應商提供的工具）通常只有當您鎖定在更廣泛的生態(tài)系統(tǒng)中時才能發(fā)揮最佳性能。

稍后我們將看到 Budibase 如何融入市場。

定制開發(fā)需要多少錢？

這是一個重要的問題，我們今天已經(jīng)多次提到過。這顯然是一個重要的考慮因素，但也是一個很難概括的問題。我們可能會輕率地問一根繩子有多長？

這有點陳詞濫調(diào)，但它指出了一個重要的原則。

也就是說，無數(shù)因素決定了您開發(fā)自定義軟件app的成本 - 尤其是我們之前探討的有關(guān)如何選擇構(gòu)建它的所有問題。

我們需要應對的另一個不幸的現(xiàn)實是，定制軟件app項目因超出預算而聲名狼藉。

這里的風險特別高——尤其是因為與開發(fā)相關(guān)的高昂勞動力成本。

我們有很多可以依賴的策略來減輕這種風險。我們不能低估首先獲得準確成本估算的作用。

除此之外，我們還可以通過利用首先減少開發(fā)項目資源占用的策略來大大降低預算超支的風險。

我是否需要內(nèi)部開發(fā)團隊來構(gòu)建自定義軟件app？

還值得停下來更深入地思考誰提供了我們的定制軟件app開發(fā)。您的情況的答案可能與您的競爭對手有很大不同，因此了解其外觀的不同排列非常重要。

但總的來說，我們有三個選擇：

1. 內(nèi)部開發(fā)人員。

2. 非開發(fā)人員的內(nèi)部同事。

3. 外部開發(fā)人員。

理論上，您也可以選擇外部非開發(fā)人員，但很難想出為什么這樣做的原因。因此，讓我們堅持三個現(xiàn)實的選擇。

每個都有優(yōu)點和缺點。我們已經(jīng)看到了這對于內(nèi)部開發(fā)人員和外包項目的影響。

但是依靠非開發(fā)人員來構(gòu)建解決方案又如何呢？您可能會對此表示懷疑，這是可以理解的，因為這對許多企業(yè)來說都是未知的領(lǐng)域。正如我們之前暗示的，這里的關(guān)鍵是為您的團隊提供正確的無/低代碼工具。

那么有哪些優(yōu)點和缺點呢？

這里的最大賣點是速度和成本。兩者都與我們不需要給開發(fā)人員增加負擔這一事實有關(guān)。因此，我們避免了支付他們可能更高的勞動力成本以及始終存在的開發(fā)積壓的需要。

缺點是我們可以期望非專家構(gòu)建任何定制解決方案。畢竟，專業(yè)開發(fā)人員的高薪是有原因的。我們在這里受到團隊技能以及我們?yōu)樗麄兲峁┑墓ぞ吖δ艿南拗啤?/span>

由于這種權(quán)衡，許多企業(yè)將依賴非開發(fā)人員，他們可以構(gòu)建有問題的解決方案，但仍然求助于專家來解決更復雜或關(guān)鍵業(yè)務的用例。

定制開發(fā)的其他注意事項

在結(jié)束之前，我們還需要了解有關(guān)自定義軟件app開發(fā)的其他信息嗎？

當然，我們并未涵蓋您可能遇到的所有疑問或問題。相反，我們的目標是覆蓋盡可能廣泛的領(lǐng)域，以便您對將遇到的廣泛決策有充分的了解。

盡管如此，我們?nèi)匀豢梢杂行У靥剿饕恍┡c我們迄今為止看到的任何類別都不完全相符的關(guān)鍵點。

一種觀點是，定制軟件app開發(fā)總是與某種潛在的業(yè)務問題或痛點緊密地交織在一起。因此，構(gòu)建一個全新的軟件app通常并不是我們唯一的選擇。

許多企業(yè)犯的一個大錯誤是，追求可以通過更好的流程輕松解決的問題的技術(shù)解決方案。因此，在我們致力于可能昂貴的定制解決方案之前，探索我們所有的選擇非常重要。

即使我們無法用非技術(shù)解決方案完全解決我們的用例，尋求這樣做通常會給我們帶來更簡化的流程，因此更容易數(shù)字化，言鼎科技。