الممارسات الرشيقة: كيفية تجنب الأخطاء التي يرتكبها فريق التسويق لدينا

السر خارج. تعتبر إدارة المشاريع الرشيقة عاملاً في تغيير قواعد اللعبة - ولم يعد المطورون وموظفو تكنولوجيا المعلومات هم الوحيدون الذين يعرفون عنها.

بصفتك مسوقًا ، فقد سمعت بالتأكيد عن Agile. قد يستخدم فريقك بعض ممارسات Agile ، مثل سباقات المشروع والاجتماعات الاحتياطية. إذا كان الأمر كذلك ، فأنت من الأقلية. لا تزال فوائد Agile غير مستغلة إلى حد كبير من قبل فرق التسويق. وفقًا لتقرير جديد صادر عن Workfront و MarketingProfs ، يستخدم 30٪ فقط من فرق التسويق نهجًا رشيقًا لإدارة عملياتهم. من المحتمل أن يعاني 70٪ الآخرون من نفس الإحباطات التي عانى منها فريقي قبل أن نلتزم بعمل Agile.

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

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

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

قبل أن نبدأ ، دعنا نغطي بعض الأساسيات:

ما هي ممارسات أجايل؟

تؤكد الممارسات الرشيقة (التي يشار إليها غالبًا باسم "Agile") على التسليم المستمر لأجزاء أصغر من العمل على المشاريع ذات المهام المترابطة الأكبر التي قد تمتد لأسابيع أو أشهر (وهو ما يسمى تقليديًا بإدارة نمط الشلال).

تشمل الأساسيات الرشيقة:

• فريق Scrum: هذا الفريق المتعاون للغاية ، المنظم تحت إشراف خبير سكرم ، يحل المشكلات المعقدة ويقدم حلولًا في تكرارات ذات طول ثابت تسمى سباقات السرعة ، والتي يمكن أن تستمر في أي مكان من أسبوع إلى 30 يومًا. على سبيل المثال ، قد يبدأ فريق سكرم الذي يعمل على المحتوى ، سباق سريع لمدة أسبوعين يلتزم بإنشاء مخطط معلومات أو ورقة بيانات جديدة.
• الحد الأدنى من المنتج القابل للتطبيق (MVP): عند التخطيط للتسليم ، تؤكد مبادئ Agile على إخراج المشروع في البرية بأسرع ما يمكن حتى يتمكن فريقك من الاستجابة في وقت مبكر لمشاكل حقيقية. لتحقيق نموذج التسليم المستمر ، يشجع أساتذة سكرم الفرق على تحديد MVP ومعرفة أكثر الطرق إبداعًا لإنهاء المنتج ضمن حدود العدو. على سبيل المثال ، إذا بدأت سباقًا سريعًا لمدة أسبوعين لإنشاء كتاب إلكتروني بصفتك أفضل لاعب ، ومرض المصمم الخاص بك ، فقد تقرر إعادة تعريف MVP لهذا العدو كسلسلة من منشورات المدونة وتصميم الكتاب الإلكتروني في اليوم التالي العدو.
• اجتماع الوقوف اليومي: يقف أعضاء الفريق في دائرة لمدة 15 دقيقة أو نحو ذلك كل صباح لمناقشة المهام التي أنجزها فريق سكروم ، ومجالات التركيز ، والحواجز التي قد تعيقهم عن إنهاء عملهم السريع المحدد. في نهاية السباق ، تقدم فرق Agile مجموعة محددة من المشاريع ، والتي يتم تقييمها وتحسينها بعد ذلك في السباق التالي. تتضمن بعض فرق سكروم أيضًا اجتماعات بأثر رجعي ، حيث يناقشون أوجه القصور في العملية التي يمكن معالجتها في السباق التالي.

لماذا يجب على المسوقين استخدام Agile؟

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

يسمح اعتماد نموذج Agile للتكرار المستمر لفريق التسويق الخاص بك باختبار الرسائل أو الحملات الجديدة بسرعة ، والاستجابة بشكل أسرع لتحديثات المنتج ، وتحديد التوقعات مع أصحاب المصلحة الذين يطلبون العمل من فريقك.

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

ما الأخطاء التي يجب تجنبها؟

إذا كنت تفكر في اعتماد Agile في فريقك ، حتى إذا كنت تبحث ببساطة عن تبسيط العمليات داخل فريق التسويق الخاص بك ، فستحتاج إلى تجنب هذه الأخطاء التسويقية الأربعة التي ارتكبها فريقنا:

1. أطلقنا على أنفسنا اسم Agile دون القيام بواجبنا.
2. فشلنا في تعيين أصحاب المشكلة.
3. ركزنا على المخرجات بدلاً من المشاكل.
4. لقد تكدسنا بدلاً من تحديد الأولويات (وتظاهرنا بأننا نستطيع إنجاز كل شيء).

الخطأ الأول: أطلقنا على أنفسنا اسم Agile دون القيام بواجبنا

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

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

قبل إنشاء عمليات Agile على فريق التسويق الخاص بك ، قم بأداء واجبك. افتح كتابًا أو كتابين. أوصي بالبدء بـ Scrum بواسطة Jeff Sutherland (المعروف للكثيرين كأحد آباء Agile) و Hacking Marketing بواسطة Scott Brinker. اقرأ أيضًا بعض مقالات CMI الممتازة عن التسويق السريع Agile.

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

الخطأ الثاني: فشلنا في تحديد أصحاب المشكلة

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

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

لا أزال أقرأ؟ انا أعتقد ذلك.

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

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

لمنع إعادة العمل في اللحظة الأخيرة ، نقوم الآن بتعيين مثل هذا الشخص - مالك المشكلة - لكل مشروع.

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

كانت ملكية المشكلة ناجحة بشكل خاص لفريقنا لعدة أسباب:

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

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

الخطأ الثالث: ركزنا على النتائج بدلاً من المشكلات

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

فكر في المساهمين الفرديين في فريقك: المطورين ، ومؤلفي النصوص ، والمصممين ، وأدوار التنفيذ الأخرى المماثلة. كم مرة طُلب منهم "تصميم هذه الشريحة" أو "كتابة هذا الكتاب الإلكتروني" مع القليل من السياق لسبب قيامهم بذلك؟

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

في الواقع ، يمكن أن يكون لنقص العمل الموجه الغرض آثار خطيرة على أكثر من مجرد أساليب التسويق الخاصة بك. في دراسة استقصائية لأعضاء LinkedIn ، خطط أكثر من 60٪ من المشاركين الذين لم يكونوا في وظائف موجهة لغرض معين لمغادرة شركتهم خلال ثلاث سنوات أو أقل.

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

بدلاً من ذلك ، نبدأ كل مشروع ببيان المشكلة ، والذي يتبع تنسيقًا يسمى بانتظام قصص المستخدمين في عالم التطوير Agile. يبدو هذا التنسيق مثل هذا:

عندما يحدث __________ ، أريد أن ________ ، حتى نحصل على هذه النتيجة القابلة للقياس: ___________.

إليك مثال على هذا النوع من بيان المشكلة (أو قصة المستخدم) من مشروع افتراضي:

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

يتيح حل المشكلة كفريق للجميع أن يكون لهم مصلحة في النتيجة.

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

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

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

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

الخطأ الرابع: حشرنا أنفسنا بدلاً من تحديد الأولويات (وتظاهرنا بإمكانية إنجاز كل شيء)

إذا حاولت أن تتلاءم قدر الإمكان مع كل سباق تسويقي رشيق ، كما فعلنا ، فأنت تفعل ذلك بشكل خاطئ.

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

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

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

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

أجريت حديثًا مؤخرًا مع مدير الهندسة في شركتنا الذي يدير عملية Agile لفريق منتجاتنا. عندما ذكرت أن فريقنا لم يتقن التقدير أبدًا ، قال هذا:

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

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

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

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

استنتاج

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

ما هي الأخطاء التي ارتكبتها فرقك عند تنفيذ عمليات Agile؟ كيف عالجت تلك الأخطاء؟ واسمحوا لنا أن نعرف في تعليق.

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

صورة الغلاف بواسطة جوزيف كالينوفسكي / معهد تسويق المحتوى