8 استراتيجيات عملية رشيقة لفرق التسويق الهزيل

نحن متحمسون للتكنولوجيا ، ونعمل عن بعد ونبني تطبيقاتنا الخاصة (بما في ذلك Turbine ، وتطبيق الموارد البشرية و Fizz + Ginger ، وهو تطبيق تقني لتحسين محركات البحث لمستخدمي HubSpot). نحن نعمل في شركات التكنولوجيا بما في ذلك Microsoft و Symantec و LinkedIn و HP ، ونحن نأتي من خلفية تطوير برمجيات (كان الرئيس التنفيذي لدينا يدير شركة ألعاب كمبيوتر لمدة عشر سنوات).

لذلك تتوقع منا أن يكون لدينا نهج هندسي أكثر للتسويق ، حتى لو كان معظمنا "مبدعين". وفي الواقع ، تلهم منهجية أجايل العديد من ممارسات العمل لدينا.

نشاركها هنا لإظهار أن الأشخاص التسويقيين والمبتكرين التقنيين يمكنهم التحدث بنفس اللغة. نعتقد أنه يمكنك إدارة التسويق كنشاط بسيط وفعال من حيث التكلفة واستعارة أفضل الممارسات المرنة من هندسة البرمجيات لجعلها تعمل بكفاءة. هنا كيف نراه.

كان هذا المحتوى متاحًا في الأصل كجزء من كتابنا الإلكتروني "التسويق الفعال من حيث التكلفة لشركات B2B الطموحة" (من الصفحة 21). على هذا النحو ، لديك خيار تنزيل المواد الأصلية كملف PDF إذا قمت بملء هذا النموذج:

1. تحرير الأقران

غالبًا ما يعمل المبرمجون الذين يستخدمون طريقة Agile في أزواج ، إما عن طريق الترميز معًا أو قلب الشفرة ذهابًا وإيابًا بينهما لمراجعة الأقران. إنها عكس الصورة المعتادة للمبرمج البطل وهو يحرق زيت منتصف الليل ، لكنها تعمل. يحسن جودة الكود والإنتاجية.

في Articulate ، نقوم بتعيين فريق لكل مهمة كتابة. عادة ، يكتب شخص واحد وسيقوم شخص آخر بالتعديل. قد يذهبون ذهابًا وإيابًا عدة مرات. في كثير من الأحيان ، نناوب الأدوار في نفس الحملة لنسخ مختلفة. مؤخرًا ، قمنا بتعيين رئيس تحرير لإبقائنا على صواب أيضًا.

2. التسويق القائم على الاختبار

مع التطوير السريع ، تتم مطابقة كل تغيير تجريه على الكود بتحديث لبرنامج الاختبار الآلي للتأكد من أن التغييرات لا تفسد ما يعمل بالفعل.

في التسويق ، وخاصة التسويق عبر الإنترنت ، كل شيء تقريبًا (ويجب أن يكون) قابلاً للاختبار. هل تحصل هذه الصفحة على تحويلات أكثر من تلك؟ هل هذا CTA أفضل؟ وما إلى ذلك وهلم جرا. إنه يعطينا صورة واضحة لما هو الأفضل لزيادة عائد الاستثمار.

لكن فكرة اختبار الانحدار تعني أيضًا أن ما ينجح اليوم يحتاج إلى اختبار مستمر للتأكد من أنه لا يزال يعمل غدًا.

3. لا الجرش ، لا نضوب

لا يقوم المطورون ذوو العقلية الرشيقة بإجراء تمارين الجرش. لا يوجد كافيين وبيتزا طوال الليل. بدلاً من ذلك ، يخططون لعملهم حول 40 ساعة عمل أسبوعياً يمكن إدارتها ولكن مركزة.

يجب على المسوقين أن يفعلوا الشيء نفسه ، حتى لو كان ذلك يعني قول "لا" لتسريع الوظائف. كما يقولون في تكساس ، "عدم التخطيط من جانبك لا يشكل حالة طارئة من جانبي". بعد كل شيء ، العمل المتسرع غالبًا ما يكون عملاً قذرًا.

من الأفضل جمع البيانات ومراجعة خططك بشكل متكرر في ضوء ما تتعلمه. نحن ندرك أنه لا يمكننا القيام بذلك بشكل صحيح طوال الوقت ، لكننا نسعى للقيام بذلك.

4. قصص المستخدم ، وليس المواصفات

لا يتعامل التطوير السريع مع الأساليب الرسمية أو المواصفات التفصيلية أو أي من الطرق الأخرى التي يحاول بها مديرو المشاريع عزل أنفسهم عن نزوة العميل. (راجع قاموس Devil's Marketing لمزيد من المعلومات.)

بدلاً من ذلك ، يطلب من العميل والمطور التعاون في وصف النتيجة المرجوة. التنسيق بسيط ، وقصص مستخدم قصيرة - على سبيل المثال: "يمكن للمستخدمين إنشاء حساب جديد" أو "بصفتي X ، أريد Y بسبب الفائدة Z". كلما كانت هذه القصص أكثر تحديدًا ، كان ذلك أفضل. يمكن للمسوقين اتباع نهج مماثل ، وتحديد المخرجات ، مثل أسلوب أو موضوع مقال ، بدلاً من المدخلات مثل عدد الساعات التي سيستغرقها كتابتها. (هذا ما نقوم به. لا توجد جداول زمنية هنا في Articulate!) التعاون مع عملائنا شيء نقدره حقًا - ينتج عنه مخرجات أفضل وأكثر قيمة.

أيضًا ، تركز قائمة مراجعة ملخص المشروع الخاصة بنا على أهداف العمل والجماهير (كلمتنا لـ "المستخدمين") بدلاً من المواصفات التفصيلية.

5. حدد مدى الصعوبة ، لا تقدر المدة

ربما تستخدم Jira أو ClickUp أو أي شيء لإدارة المشروع. تتجنب أدوات إدارة المشروع هذه منهجية الشلال المعتادة والجداول الزمنية. بدلاً من مطالبة المطورين بتحديد المدة التي ستستغرقها "القصة" ، تسأل أدوات إدارة المشاريع الرشيقة عن مدى تعقيدها ومدى أهميتها بالنسبة إلى المهام الأخرى.

بمرور الوقت ، يتتبعون الوقت الذي تستغرقه لإكمال أنواع مختلفة من المهام ، وبعد فترة قصيرة يمكنهم التنبؤ بموعد إنهاء المهام القادمة المختلفة. في Articulate ، على سبيل المثال ، نميل إلى استخدام طول الكلمة كبديل للتعقيد عندما يتعلق الأمر بكتابة المحتوى ، مع بعض التحذيرات للمقاطع الفنية بشكل خاص. نستخدم النقاط لتقدير الجهد والوقت والتكلفة وما إلى ذلك.

6. اجتماعات "الوقوف"

بدلاً من اجتماعات الحالة غير المحدودة والمكالمات الجماعية ، يعقد المطورون الرشيقون اجتماعات "الوقوف" في بداية الأسبوع (أو اليوم) لمشاركة المعلومات. نحن نفعل الشيء نفسه (عمليًا ، نعمل عن بُعد). وكما يوحي الاسم ، إذا وقف الناس ، فإنهم يميلون إلى عدم التحدث كثيرًا!

7. توقع التغيير ، لا تقاومه

تتضمن معظم مشاريع البرامج مواصفات تفصيلية يتم وضعها في حجر بمجرد بدء التطوير. المشكلة في مثل هذا النهج هي أن الظروف تتغير ، وفي كثير من الأحيان ، لا يعرف العميل ما يصلح له حتى يراه في الكود.

يشجع التطوير السريع على مشاركة العميل ويفترض أن المشروع سيتغير بمرور الوقت. من خلال تقسيمه إلى سباقات سريعة قصيرة (انظر النقطة التالية) ورصاصات صغيرة ومحددة جيدًا ، يكون المشروع الرشيق أكثر مرونة.

بشكل عام ، نتبع هذا النهج في Articulate ، مما يسمح للعملاء ونتوقع منهم تقديم ملاحظاتهم حتى من خلال المراجعات المتعددة. يمكن أن تكون التعليقات وإعادة الكتابة محبطة بالتأكيد. لكن توقعهم ، وحتى احتضانهم ، يساعدنا على القيام بعمل أفضل لعملائنا. في حدود المعقول.

8. سباقات السرعة ، وليس سباقات الماراثون

يهدف التطوير السريع إلى "الحد الأدنى من المنتج القابل للتطبيق" في وقت مبكر ، وتحسينات تدريجية صغيرة بمرور الوقت. إنه يتجنب المشاريع الملحمية ومسيرات الموت التي ابتليت بها الأجيال السابقة من تطوير البرمجيات.

يجب أن تكون مشاريع التسويق هي نفسها: موقع الويب الخاص بك لم ينته أبدًا ولكن لا ينبغي أن يستغرق بناؤه دهورًا. وبالمثل ، فإن التوعية التسويقية لقناتك هي مشروع مستمر - وليست مهمة لمرة واحدة للمتدرب.

وكالات التسويق ، مثل كل الأعمال الأخرى ، لا تستطيع أن تكون راضية عن نفسها ، لكن الابتكار صعب. لقد وجدنا أن التعلم من المجالات الأخرى وترجمة هذه الدروس إلى أعمالنا استراتيجية ذكية وفعالة من حيث التكلفة - ويمكن أن تكون مجزية إلى حد ما!

لذا ، فرق التسويق ، تشجّع. ليس عليك أن تكون مهندس برمجيات أو أن تكون خبيرًا في يوغي لتكون رشيقًا.