在這期間,我(wǒ)(wǒ)們發現80%的需求方都容易犯如下(xià)一(yī)些緻命的錯誤:
小(xiǎo)程序到底是什麽不清楚,盲目要求要做小(xiǎo)程序。感覺做個小(xiǎo)程序很簡單,所以描述需求的時候非常模糊。急着想要報價,在自己對需求不确定的時候就要報價。然後就按這個報價開(kāi)始做。不知(zhī)道自己要什麽,想做個派單平台說要做的是滴滴出行。缺乏耐心,不明白(bái)也從未想過自己要做的東西有多複雜(zá)。自己不知(zhī)道要做的東西的具體(tǐ)功能,需求要靠服務商(shāng)來猜,而且還要即時得到報價。
事實告訴我(wǒ)(wǒ)們,這些問題一(yī)定會導緻以下(xià)結果:
産品做出來跟自己想的完全不一(yī)樣。在外(wài)包項目中(zhōng),有超過一(yī)半的甲方項目經理由于項目失敗而被迫離(lí)職/降職。産品上線的時候漏洞百出,反複修修補補解決不了問題,最後必須推翻重做。誤把自己都不确定需求時得到的不靠譜報價當做真實報價去(qù)開(kāi)始做預算,導緻後期資(zī)金預算跟不上,繼而導緻項目失控或者爛尾。
現在市場上存在的幾種小(xiǎo)程序的開(kāi)發方式如下(xià):
使用小(xiǎo)程序生(shēng)成工(gōng)具直接生(shēng)成
由于小(xiǎo)程序的第三方分(fēn)發特性,有很多技術實力強的第三方服務商(shāng),會結合一(yī)些具體(tǐ)的應用場景(例如:企業展示,電(diàn)商(shāng))做大(dà)量的小(xiǎo)程序框架。
需求方可以通過APPx第三方服務商(shāng)提供的配置界面,通過插入文字,圖片與商(shāng)品的方式,一(yī)鍵生(shēng)成小(xiǎo)程序。目前在市面生(shēng)成小(xiǎo)程序絕大(dà)多數都是基于這個方式來做。
用後端雲服務開(kāi)發
将小(xiǎo)程序的服務器租賃、維護等後端的開(kāi)發和部署部分(fēn)交給後端雲服務提供商(shāng),而将主要資(zī)源投入到小(xiǎo)程序的前端産品設計與研發上,這樣節省了開(kāi)發資(zī)源,也縮短的項目周期。
缺點是由于後端雲服務的黑盒子特性,性能上會有不穩定,與安全性的風險;同時對後續擴展開(kāi)發與功能升級也有局限性。
原生(shēng)開(kāi)發
原生(shēng)開(kāi)發是目前最常用和最成熟的方式,越重視細節成本越高。我(wǒ)(wǒ)建議大(dà)家在預算充足的情況下(xià),都使用原生(shēng)開(kāi)發的方式。
模闆方案
另外(wài)再聊聊模闆方案,目前看到市面上多小(xiǎo)程序模闆方案,不可置否使用成熟的模闆解決方案能節省很大(dà)的成本,小(xiǎo)程序也不例外(wài)。
但是模闆方案也一(yī)樣價格存在巨大(dà)的差異。同樣的一(yī)個行業方案模闆可能價格也上下(xià)差出來十倍,原因也是因爲細節功能完全不一(yī)樣,可能功能差了十幾倍。
如果你在買之前不仔細觀察細節功能,那麽一(yī)定會出現購買後完全不能使用的情況。原因是模版不是爲你的業務定制的,需要再進行二次開(kāi)發。
考慮到定制化的需求服務,其業務邏輯都有其獨特性,絕大(dà)多數情況也無法直接拿預定制的模版進行運營上線。