Yalın pazarlama ekipleri için 8 Çevik süreç stratejisi

Hevesli teknoloji tutkunlarıyız, uzaktan çalışıyoruz ve kendi uygulamalarımızı oluşturuyoruz (bir İK uygulaması olan Turbine ve HubSpot kullanıcıları için teknik bir SEO uygulaması olan Fizz+Ginger dahil). Microsoft, Symantec, LinkedIn ve HP gibi teknoloji şirketleri için çalışıyoruz ve yazılım geliştirme geçmişinden geliyoruz (CEO'muz on yıl boyunca bir bilgisayar oyunları şirketini yönetti).

Dolayısıyla, çoğumuz "yaratıcı" olsak bile, bizden pazarlamaya daha çok mühendislik yaklaşımına sahip olmamızı beklersiniz. Ve aslında çevik metodoloji, çalışma uygulamalarımızın çoğuna ilham veriyor.

Bunları burada, pazarlamacılarla teknoloji mucitlerinin aynı dili konuşabildiklerini göstermek için paylaşıyoruz. Pazarlamayı yalın, uygun maliyetli bir faaliyet olarak yürütebileceğinize VE verimli çalışmasını sağlamak için yazılım mühendisliğinden çevik en iyi uygulamaları ödünç alabileceğinize inanıyoruz. İşte böyle görüyoruz.

Bu içerik ilk olarak 'Hırslı B2B şirketleri için uygun maliyetli pazarlama' (s.21'den itibaren) e-kitabımızın bir parçası olarak mevcuttu. Bu nedenle, bu formu doldurursanız orijinal materyali PDF olarak indirme seçeneğiniz vardır:

1. Meslektaş düzenleme

Çevik yöntemi kullanan programcılar genellikle çiftler halinde çalışırlar, ya birlikte kodlarlar ya da akran incelemesi için ikisi arasında kodu ileri geri değiştirirler. Gece yarısı yağını yakan kahraman programcının olağan görüntüsünün tam tersi ama işe yarıyor. Kod kalitesini ve üretkenliği artırır.

Articulate'te her yazma görevi için bir ekip atarız. Genellikle bir kişi yazar ve ikinci bir kişi düzenler. Birkaç kez ileri geri gidebilirler. Genellikle, farklı kopya parçaları için aynı kampanyadaki rolleri değiştiririz. Son zamanlarda, bizi de haklı çıkarması için bir Genel Yayın Yönetmeni tuttuk.

2. Test odaklı pazarlama

Çevik geliştirme ile, kodda yaptığınız her değişiklik, otomatik test yazılımında yapılan bir güncellemeyle eşleştirilerek, değişikliklerin zaten çalışır durumdakileri bozmadığından emin olunur.

Pazarlamada, özellikle çevrimiçi pazarlamada, neredeyse her şey test edilebilir (ve edilmelidir). Bu sayfa şu sayfadan daha fazla dönüşüm alıyor mu? Bu CTA daha mı iyi? Ve benzeri. Bize yatırım getirisini en üst düzeye çıkarmak için neyin en iyi olduğuna dair net bir resim sunuyor.

Ancak regresyon testi fikri aynı zamanda bugün çalışan bir şeyin yarın da çalıştığından emin olmak için sürekli olarak test edilmesi gerektiği anlamına gelir.

3. Egzersiz yok, tükenmişlik yok

Çevik fikirli geliştiriciler egzersizi yapmazlar. Tüm gece boyunca kafein ve pizza yakıtı yoktur. Bunun yerine, çalışmalarını yönetilebilir ancak odaklanmış 40 saatlik bir çalışma haftası etrafında planlıyorlar.

Bu, işleri aceleye getirmek için "hayır" demek anlamına gelse bile, pazarlamacılar da aynı şeyi yapmalıdır. Teksas'ta dedikleri gibi, 'sizin planlama eksikliğiniz benim açımdan acil bir durum teşkil etmez.' Ne de olsa, aceleye getirilen işler genellikle baştan savma işlerdir.

Veri toplamak ve öğrendiklerinizin ışığında planlarınızı yinelemeli olarak gözden geçirmek daha iyidir. Bunu her zaman doğru yapamayacağımızın farkındayız, ancak bunun için çabalıyoruz.

4. Spesifikasyonlar değil, kullanıcı hikayeleri

Çevik geliştirme, resmi yöntemlerle, ayrıntılı spesifikasyonlarla veya proje yöneticilerinin kendilerini müşteri kaprislerinden korumaya çalıştıkları diğer yöntemlerle ilgilenmez. (Daha fazlası için Şeytanın Pazarlama Sözlüğü'ne bakın.)

Bunun yerine, müşteriden ve geliştiriciden istenen sonucu açıklamak için işbirliği yapmalarını ister. Format basit, kısa kullanıcı hikayeleri – örneğin: 'kullanıcılar yeni bir hesap oluşturabilir' veya 'Bir X olarak, Z avantajı nedeniyle Y istiyorum'. Bu hikayeler ne kadar spesifik olursa o kadar iyidir. Pazarlamacılar benzer bir yaklaşım benimseyip makalenin yazılması için gereken saat sayısı gibi girdiler yerine makalenin stili veya konusu gibi çıktıları belirleyebilirler. (Yaptığımız şey bu. Articulate'de zaman çizelgesi yok!) Müşterilerimizle işbirliği gerçekten değer verdiğimiz bir şeydir - daha iyi, daha değerli çıktılarla sonuçlanır.

Ayrıca, proje brifing kontrol listemiz, ayrıntılı özelliklerden ziyade iş hedeflerine ve hedef kitlelere (bizim "kullanıcılar" kelimemiz) odaklanır.

5. Zorluğu ölçün, süreyi tahmin etmeyin

Muhtemelen proje yönetimi için Jira veya ClickUp veya başka bir şey kullanıyorsunuzdur. Bu proje yönetimi araçları, olağan şelale metodolojisinden ve zaman çizelgelerinden kaçınır. Çevik proje yönetimi araçları, geliştiricilerden bir "hikayenin" ne kadar süreceğini belirtmelerini istemek yerine, bunun ne kadar karmaşık olduğunu ve diğer görevlere göre ne kadar önemli olduğunu sorar.

Zamanla, farklı görev türlerini ne kadar sürede tamamladığınızı izlerler ve kısa bir süre sonra yaklaşan farklı görevleri ne zaman bitireceğinizi tahmin edebilirler. Örneğin, Articulate'de, özellikle teknik parçalar için bazı uyarılarla birlikte, içerik yazımı söz konusu olduğunda, kelime uzunluğunu karmaşıklık için bir vekil olarak kullanma eğilimindeyiz. Çaba, zaman, maliyet vb. tahmin etmek için puanları kullanırız.

6. 'Ayağa kalk' toplantıları

Çevik geliştiriciler, bitmek bilmeyen durum toplantıları ve konferans görüşmeleri yerine, bilgi paylaşmak için haftanın (veya günün) başında 'ayakta' toplantılar düzenler. Biz de aynısını yapıyoruz (neredeyse uzaktan çalışıyoruz). Ve adından da anlaşılacağı gibi, insanlar ayağa kalkarsa pek konuşmazlar!

7. Değişim bekleyin, onunla savaşmayın

Çoğu yazılım projesi, geliştirme başladıktan sonra kesinleşen ayrıntılı spesifikasyonlar içerir. Böyle bir yaklaşımla ilgili sorun, koşulların değişmesi ve genellikle müşterinin kodda görene kadar kendileri için neyin işe yaradığını bilmemesidir.

Çevik geliştirme, müşteri katılımını teşvik eder ve projenin zaman içinde değişeceğini varsayar. Çevik bir proje, kısa sprintlere (sonraki noktaya bakın) ve küçük, iyi tanımlanmış maddelere bölünerek daha esnektir.

Genel olarak, Articulate'te bu yaklaşımı benimsiyoruz ve müşterilerin birden çok revizyon yoluyla bile geri bildirim vermelerine izin veriyor ve bekliyoruz. Geri bildirim ve yeniden yazma elbette sinir bozucu olabilir. Ancak onları beklemek, hatta onları kucaklamak, müşterilerimiz için daha iyi bir iş çıkarmamıza yardımcı olur. Mantık dahilinde.

8. Maratonlar değil Sprintler

Çevik geliştirme, başlangıçta 'minimum geçerli bir ürün' ve zaman içinde küçük artımlı iyileştirmeler hedefler. Önceki yazılım geliştirme nesillerini rahatsız eden destansı projelerden ve ölüm yürüyüşlerinden kaçınır.

Pazarlama projeleri aynı olmalıdır: web siteniz hiçbir zaman tam olarak bitmez, ancak oluşturulması çok uzun sürmemelidir. Benzer şekilde, kanal pazarlama desteğiniz devam eden bir projedir - bir stajyer için tek seferlik bir görev değildir.

Diğer tüm işletmeler gibi pazarlama ajansları da kayıtsız olmayı göze alamaz, ancak inovasyon zordur. Diğer alanlardan öğrenmek ve bu dersleri kendi işimize çevirmek akıllı ve uygun maliyetli bir stratejidir - ve bunun oldukça ödüllendirici olabileceğini gördük!

Öyleyse, pazarlama ekipleri, cesaretlenin. Çevik olmak için bir yazılım mühendisi veya usta bir Yogi olmanıza gerek yok.