كيفية بناء برامج المحمول مع التركيز على النمو

ملاحظة مني: هذا المقال من تأليفي ، بنيامين جرول (شريك ورئيس قسم النمو في Atomico) و Hemant Bhonsle (مهندس متنقل في Zenefits). إذا كنت ترغب في مزيد من التحليل والبصيرة بهذا الشكل ، يتم تسليمها شهريًا (ish) إلى صندوق الوارد الخاص بك ، قم بالتسجيل في دليل المشغل (النشرة الإخبارية) هنا.

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

لقد بدأت مؤخرًا إدارة لقاء نمو مع جوي كوتكينز وآندي يونغ للجمع بين ممارسين آخرين في صناعتنا.

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

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

تينيت رقم 1: (بي) الإصدارات الأسبوعية على سرعات التنفيذ المتنقلة والأسبوعية

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

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

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

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

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

لتلخيص ، الآثار الإيجابية لإصدار سريع وإيقاع التنفيذ:

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

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

تينيت # 2: التحكم في ميزات العميل المحمول مع عناصر تحكم الخادم

يتمثل أحد الجوانب المهمة للغاية في تطوير الأجهزة المحمولة المحلية اليوم في الحفاظ على التحكم من جانب الخادم في سمات العميل المختلفة. أصبح هذا معيارًا على مدار الأعوام القليلة الماضية ، حيث ظهرت العديد من الشركات حول هذا المفهوم ، مما سمح للمطورين بتكوين تطبيقاتهم بسهولة لقراءة الإشارات من الخادم وتعديل واجهة المستخدم / UX وفقًا لذلك وإظهار الميزات المناسبة فقط. تقوم العديد من شركات البرامج الكبيرة ببناء أنظمة تقوم بذلك من البداية. كان لدى Facebook بعض الأنظمة التي فعلت ذلك ، بما في ذلك Gatekeeper (GK) و Quick Experience (QE). تم بناء أنظمة مماثلة في Uber و Pinterest و Zenefits ، إلخ. بعض الأمثلة على الأدوات المتاحة بسهولة والتي تشمل Optimizely و Mixpanel و Apptimize و Firebase.

هناك بعض الأسباب التي تجعل سمات العميل التي يتحكم فيها الخادم هي المعيار لتطوير المحمول:

  • تجربة أفضل للعملاء - نظرًا للتأخير بين تقديم التطبيق وتوافره لعملائك ، فقد يستمر تعطل العميل والأخطاء حتى يتم نشر إصلاح عاجل. من خلال سمات العميل التي يتحكم فيها الخادم ، يمكن التخفيف من هذه الأعطال (على سبيل المثال ، ميزة جديدة تسبب تعطلًا على جهاز Nexus 6 ، لذلك يتم إيقاف تشغيل الميزة على مستوى الخادم لجميع المستخدمين الذين يستخدمون هذا الجهاز وتتوقف الأعطال). يمكن القول إن هذه مشكلة أقل بالنسبة لتطبيقات Android ، ومع ذلك ، قد لا يزال هناك تأخير لبضع ساعات بين الإرسال والإصدار. أيضًا ، لا يتم تشغيل التحديث التلقائي لبعض المستخدمين.
  • المزيد من عمليات التثبيت - في عالم حيث يتعطل التطبيق عند بدء التشغيل لمدة يوم أو نحو ذلك ، قد يحصل التطبيق على العديد من التقييمات السلبية. يمكن أن يؤدي ذلك إلى انخفاض التصنيف في متجر تطبيقات Google Play / iOS App Store ومعدل تحويل أقل من صفحة التطبيق إلى تثبيت التطبيق (على سبيل المثال ، من المرجح أن أقوم بتثبيت تطبيق بتصنيف 4.5 نجوم مقارنة بتصنيف 3.5 نجوم) . هذا لا يشكل عاملًا في العملاء الذين "أحرقتهم" والذين لن يعودوا أبدًا ، ولا الصحافة السلبية التي قد تضر بعلامتك التجارية.
  • تطوير أقل توحيدًا / أكثر مرونة - عندما يعلم المهندسون أنه يمكن إيقاف تشغيل ميزة غير كاملة بتكوين خادم ، فإن هذا يقلل من النفقات العامة للتطوير.

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

فمثلا:

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

من الشائع أن تسبق اسم النظام الأساسي ، لذلك عادةً "ios_" أو "android_" ، وإلحاق تاريخ صنع العلم ، لذلك شيء مثل "_aug_2017". لذلك بالنسبة للإصدار الأول من ميزة الدفعات التي يتم إصدارها على iOS ، قد ترى علامة مثل "ios_payments_v1_aug_2017". يساعد الحصول على التاريخ حتى تتمكن الفرق من الاحتفاظ بخط زمني بسيط في رمز وقت إصدار ميزات مختلفة. يساعد وجود النظام الأساسي بحيث يؤدي إيقاف تشغيل العلم إلى إيقاف تشغيله فقط للنظام الأساسي المناسب بدلاً من جميع المستخدمين ، إذا كان التعطل أو المشكلة فقط على أحدهما وليس الآخر.

إدارة جلسة نمو مع شركات محفظة Local Globe في لندن

العقيدة رقم 3: تمديد عناصر تحكم الخادم لميزات الأجهزة المحمولة إلى اختبارات A / B لزيادة التعلم إلى أقصى حد

يعد التحكم في الميزات بطريقة ثنائية فقط (true == show ، false == hide) أمرًا رائعًا كمحول لتشغيل الأشياء وإيقاف تشغيلها للمستخدمين. في العديد من الحالات ، على الرغم من ذلك ، نود طرح أشكال مختلفة للميزات لمعرفة ما يريده عملاؤنا استنادًا إلى استخدامهم لهذه الميزة.

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

تتيح لنا هذه العملية:

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

توسيع مثال لميزة الدفعات التي ناقشناها سابقًا:

قم بإجراء الاختبار:

  • نريد اختبار A / B لون زر الدفع لمعرفة ما إذا كان هناك تأثير على مشتريات المستخدم
  • بالإضافة إلى علامة "payments_v1" ، نرسل الآن من الخادم مفتاح "payments_v1_button_color" مع المتغيرات ، مثل "blue" و "green" و "red"
  • انتظر حتى تحصل على نتائج ذات دلالة إحصائية من تتبع العميل

اتخاذ قرار بشأن النتيجة:

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

أزل اختبار A / B عندما يكون ذلك آمنًا:

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

استنتاج:

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

TL ؛ نسخة DR

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

إذا كنت ترغب في مزيد من التحليل والبصيرة بهذا الشكل ، يتم تسليمها شهريًا (ish) إلى صندوق الوارد الخاص بك ، قم بالتسجيل في دليل المشغل (النشرة الإخبارية) هنا.