趕上我在本月早些時(shí)候 #MartechDay 之前積壓的數(shù)據(jù)和主題——其中包括 2022 年?duì)I銷技術(shù)前景和 2022 年 Stackies——清單最上面是來(lái)自 AgileSherpas 的最新敏捷營(yíng)銷狀態(tài)報(bào)告。

與往常一樣，這是一份關(guān)于如何以及為何在營(yíng)銷中使用敏捷方法的出色而全面的報(bào)告。從上圖中可以看出，敏捷已進(jìn)入各種營(yíng)銷活動(dòng)：營(yíng)銷運(yùn)營(yíng)、創(chuàng)意服務(wù)、網(wǎng)站運(yùn)營(yíng)、社交媒體、廣告等。

它甚至被應(yīng)用在事件營(yíng)銷中（30%），長(zhǎng)期以來(lái)，這一直是懷疑者的首選示例：「哦，敏捷永遠(yuǎn)無(wú)法為事件工作?！?nbsp;（公平地說，在虛擬/混合事件世界中，事件營(yíng)銷的節(jié)奏和適應(yīng)性顯著提高。）

但與去年不同的是，當(dāng) 51% 的參與者報(bào)告使用敏捷營(yíng)銷時(shí)，這次只有 43% 的人使用了。這接近 2020 年的 42%。敏捷營(yíng)銷是否正在倒退？

當(dāng)然，最明顯的免責(zé)聲明是調(diào)查樣本。即使有 513 名營(yíng)銷人員參與了這項(xiàng)最新調(diào)查，但它仍然只是多元化營(yíng)銷領(lǐng)域的一小部分，無(wú)疑會(huì)受到選擇偏見的潮起潮落的影響。

但還是。經(jīng)過近 15 年的敏捷營(yíng)銷倡導(dǎo)，這一運(yùn)動(dòng)的勢(shì)頭似乎……停滯不前？

敏捷營(yíng)銷原則、實(shí)踐和標(biāo)簽

然而，敏捷營(yíng)銷的原則如今似乎被普遍接受為福音真理。我想不出我在過去幾年遇到的一個(gè)營(yíng)銷人員沒有接受適應(yīng)性、從實(shí)驗(yàn)中學(xué)習(xí)、迭代改進(jìn)、跨團(tuán)隊(duì)協(xié)作、更深入地了解工作中的工作和團(tuán)隊(duì)以及賦權(quán)等

營(yíng)銷已經(jīng)成為一種敏捷的職業(yè)，徹底地。

經(jīng)典的敏捷實(shí)踐——比如 Sprint、每日例會(huì)、看板等——似乎也得到了廣泛的推廣。盡管在許多情況下，它們已經(jīng)從原始形式演變而來(lái)。我們稍后會(huì)回到這個(gè)話題，因?yàn)槲艺J(rèn)為這是后敏捷的轉(zhuǎn)折。

但是標(biāo)簽?zāi)?？沒那么多。在營(yíng)銷討論中，我很少聽到 Sprint、例會(huì)或看板這些術(shù)語(yǔ)。甚至「敏捷營(yíng)銷」這個(gè)詞出現(xiàn)的頻率也沒有幾年前那么頻繁。

敏捷營(yíng)銷 VS 敏捷開發(fā)趨勢(shì)

Google 趨勢(shì)中的幾張圖表有助于說明所發(fā)生的事情。首先，讓我們看看搜索詞「敏捷營(yíng)銷」的增長(zhǎng)情況：

Google 趨勢(shì)：敏捷營(yíng)銷

該圖表顯示了該詞在過去 18 年中的相對(duì)搜索量。你可以看到它在 2017 年左右達(dá)到頂峰。（在 Hacking Marketing 發(fā)布一年后。巧合？）從那時(shí)起，它就上下波動(dòng)了。但它在很大程度上達(dá)到了天花板。

為了更好地了解敏捷營(yíng)銷的絕對(duì)搜索量，您需要將其與另一種趨勢(shì)進(jìn)行比較。因此，讓我們將它與它的前身「敏捷開發(fā)」進(jìn)行比較：

Google 趨勢(shì)：敏捷營(yíng)銷與敏捷開發(fā)

有兩件事突然出現(xiàn)。首先，敏捷營(yíng)銷只取得了敏捷開發(fā)所獲得的很小的份額。其次，自 2010 年以來(lái)，對(duì)敏捷開發(fā)的興趣一直在穩(wěn)步下降。大約是巔峰時(shí)期的 1/4。

2010年發(fā)生了什么？DevOps 的興起。

Google 趨勢(shì)：敏捷開發(fā)與 DevOps

事實(shí)上，DevOps 成為了站在敏捷開發(fā)肩膀上的巨人。它的受歡迎程度使敏捷開發(fā)相形見絀，即使在它的全盛時(shí)期也是如此。與這兩者相比，敏捷營(yíng)銷幾乎沒有形成規(guī)模。

但值得注意的是，DevOps 源于敏捷。引用它的維基百科文章：

「敏捷開發(fā)團(tuán)隊(duì)……無(wú)法『通過早期和持續(xù)交付有價(jià)值的軟件來(lái)滿足客戶』，除非他們包含與其應(yīng)用程序相關(guān)的運(yùn)營(yíng)/基礎(chǔ)設(shè)施責(zé)任，其中許多是自動(dòng)化的?！?/span>

DevOps「旨在縮短系統(tǒng)開發(fā)生命周期并提供高質(zhì)量軟件的持續(xù)交付?！谷绻皇墙桓兜浖_發(fā)的最終機(jī)制，那么什么是持續(xù)集成/持續(xù)部署 (CI/CD)？

正如《阿甘正傳》可能會(huì)說的那樣，「敏捷與敏捷一樣。」

云中「運(yùn)輸」的成本直線下降

需要明確的是，DevOps 不是一種敏捷管理方法。它甚至不像其他運(yùn)營(yíng)職能（例如營(yíng)銷運(yùn)營(yíng)）那樣屬于「運(yùn)營(yíng)」團(tuán)隊(duì)（在大多數(shù)情況下）。相反，它是開發(fā)人員用來(lái)快速、迭代和安全地發(fā)布軟件的一組實(shí)踐、流程和技術(shù)。它利用了大量的自動(dòng)化和儀器。

DevOps 優(yōu)化構(gòu)建和部署軟件，但決定構(gòu)建什么以及何時(shí)仍需要在高于此的級(jí)別上發(fā)生。理論上，Scrum 等敏捷開發(fā)方法可以為這些決策提供框架。但我認(rèn)識(shí)的大多數(shù)開發(fā)團(tuán)隊(duì)不再明確使用這些方法。大多數(shù)人都發(fā)明了自己的流程，從敏捷方法中提取概念并對(duì)其進(jìn)行調(diào)整，并利用 Jira 等開發(fā)項(xiàng)目管理工具。

我的看法：DevOps——更廣泛地說，云——極大地降低了迭代開發(fā)軟件的成本。早在創(chuàng)建 Scrum 等敏捷方法的時(shí)代，交付的成本和復(fù)雜性要高得多。Scrum 的僵化結(jié)構(gòu)是一種有效且必要的管理方式。今天在良好的 DevOps 環(huán)境中？沒有必要？

這并不是說戰(zhàn)略、規(guī)劃、路線圖、優(yōu)先級(jí)以及圍繞它們所需的所有協(xié)調(diào)與協(xié)作都是不必要的。它們與以往一樣對(duì)成功至關(guān)重要。但是 Scrum 的僵化將其轉(zhuǎn)化為迭代發(fā)布周期？沒有必要？

營(yíng)銷中有 DevOps 的等價(jià)物嗎？

營(yíng)銷運(yùn)營(yíng)與 DevOps 是一種不同的生物。一方面，它是營(yíng)銷組織中的一個(gè)角色/團(tuán)隊(duì)，而不是所有營(yíng)銷人員都使用的實(shí)踐/流程。

然而，有一些共同的 DNA。在許多方面，營(yíng)銷運(yùn)營(yíng)團(tuán)隊(duì)充當(dāng)類似于 DevOps 的推動(dòng)者，使?fàn)I銷人員能夠快速、迭代和安全地「發(fā)布」?fàn)I銷活動(dòng)。營(yíng)銷運(yùn)營(yíng)管理技術(shù)棧和流程以實(shí)現(xiàn)這一點(diǎn)——通過大量的自動(dòng)化和儀器。

然而，隨著 martech 中越來(lái)越多的無(wú)代碼功能的興起，營(yíng)銷運(yùn)營(yíng)也為營(yíng)銷人員提供了越來(lái)越多的自助服務(wù)功能。正如軟件部署操作通過 DevOps 被「左移」（即向上游移動(dòng)）到更多開發(fā)人員手中一樣，更多執(zhí)行營(yíng)銷的能力——包括內(nèi)部和外部營(yíng)銷「部署」——正在轉(zhuǎn)移到普通營(yíng)銷人員的手中。

我不知道這種現(xiàn)象有什么名字。這是營(yíng)銷運(yùn)營(yíng)某些方面的一種草根化（理想情況下，在專家營(yíng)銷運(yùn)營(yíng)團(tuán)隊(duì)的指導(dǎo)、治理和保護(hù)下）。但它越來(lái)越類似于 DevOps。更多的人可以快速、輕松、安全地發(fā)布更多營(yíng)銷信息。

就像軟件一樣，戰(zhàn)略、規(guī)劃、路線圖、優(yōu)先級(jí)、團(tuán)隊(duì)協(xié)調(diào)和協(xié)作對(duì)于有效利用這種分布式創(chuàng)造的力量至關(guān)重要。但同樣，在過去十年中，部署大多數(shù)營(yíng)銷方式的成本也大幅下降。這在營(yíng)銷生產(chǎn)過程中造成了更多的松懈，這使得僵化的敏捷營(yíng)銷方法……沒有必要了？

新的敏捷實(shí)踐：

DARCI、Slack、「Work OS」

說到 Slack，或者，嗯，Slack，過去 10 年也帶來(lái)了工作溝通和協(xié)作產(chǎn)品創(chuàng)新的爆炸式增長(zhǎng)。例如，Slack 和 Microsoft Teams 已經(jīng)變得無(wú)處不在——以及與之?dāng)U展和集成的整個(gè)應(yīng)用生態(tài)系統(tǒng)。新一代工作管理平臺(tái)，例如 Asana、ClickUp、Monday.com 和（面向營(yíng)銷人員的）Workfront，為復(fù)雜、快速變化的優(yōu)先事項(xiàng)、項(xiàng)目和工作流程提供了更好的結(jié)構(gòu)和可見性。

2020-2022年Martech Landscape管理類別的增長(zhǎng)

事實(shí)上，從 2020 年到 2022 年，martech 領(lǐng)域的管理類別的百分比增長(zhǎng)幅度最大。

這些工具對(duì)工作的完成方式產(chǎn)生了重大影響。他們中的許多人結(jié)合或啟用了敏捷實(shí)踐。幾乎沒有人使用敏捷營(yíng)銷方法的術(shù)語(yǔ)。但敏捷的精髓就在那里：透明度、優(yōu)先級(jí)、問責(zé)制、進(jìn)行中的管理、識(shí)別障礙和瓶頸。

同時(shí)，我想說的是，Slack 和 Teams——由大遷移到遠(yuǎn)程工作加速——已經(jīng)有效地取代了大多數(shù)團(tuán)隊(duì)的例會(huì)。

但這并不是說例會(huì)的基本原則已經(jīng)消失。相反，這些企業(yè)通訊平臺(tái)通常使團(tuán)隊(duì)更容易以相對(duì)低影響的方式全天保持聯(lián)系。與在固定時(shí)間窗口內(nèi)等待下一次例會(huì)相比，出現(xiàn)的問題可以更快地解決，這越來(lái)越無(wú)法與分布式團(tuán)隊(duì)成員的日程安排保持一致。

嘿，我仍然是面對(duì)面合作的忠實(shí)擁護(hù)者，我同意沒有它會(huì)丟失一些東西。但是獲得了其他東西。無(wú)論好壞，遠(yuǎn)程和混合團(tuán)隊(duì)都是新常態(tài)。在這個(gè)美麗新世界中，對(duì)于許多人來(lái)說，Slack 和 Teams 比日常例會(huì)更適合。

這不僅僅是技術(shù)。我認(rèn)為是針對(duì)特定需求的「點(diǎn)解決方案」的管理方法——與一整套實(shí)踐相比，如正式的敏捷營(yíng)銷——已經(jīng)普及，以實(shí)現(xiàn)更好的跨職能協(xié)作和多方?jīng)Q策（如 DARCI 模型）。

凈效應(yīng)？營(yíng)銷團(tuán)隊(duì)變得越來(lái)越敏捷。

他們只是不一定將他們的做法視為正式的「敏捷營(yíng)銷」。

從敏捷營(yíng)銷到……營(yíng)銷？

數(shù)字營(yíng)銷發(fā)生了什么？它變成了營(yíng)銷。

不是因?yàn)闋I(yíng)銷變得不那么數(shù)字化了。恰恰相反。數(shù)字化變得如此深入到營(yíng)銷人員所做的一切事情中，以至于該行業(yè)的標(biāo)簽回歸到了中庸之道：營(yíng)銷。我認(rèn)為這是數(shù)字營(yíng)銷運(yùn)動(dòng)的勝利，而不是失敗。

同樣，敏捷營(yíng)銷是否只是變成了……營(yíng)銷？

也許「敏捷營(yíng)銷」將作為一項(xiàng)明確的運(yùn)動(dòng)重新開始增長(zhǎng)。或者，它可能會(huì)被一些新命名的方法所取代，這種方法更接近于 DevOps 在軟件開發(fā)行業(yè)中的地位?；蛘咭苍S只是隱含在現(xiàn)代營(yíng)銷團(tuán)隊(duì)的運(yùn)作方式中。

敏捷就像敏捷一樣。

無(wú)論如何，我仍然相信有一個(gè)巨大的機(jī)會(huì)可以教營(yíng)銷團(tuán)隊(duì)如何最好地利用所有這些平臺(tái)、實(shí)踐和流程。在當(dāng)今的環(huán)境中，通過良好的培訓(xùn)、支持、咨詢和咨詢服務(wù)來(lái)幫助營(yíng)銷團(tuán)隊(duì)實(shí)現(xiàn)最佳績(jī)效的需求從未如此強(qiáng)烈。

我們?nèi)绾畏Q呼它真的很重要嗎？