تطوير المنتج عملية شاقة. يحتاج السوق باستمرار إلى حلول جديدة ، لكن الفشل ينتظر أي شركة في طريق خلق الابتكار. في هذه المقالة ، قمنا بتجميع تجربتنا الخاصة
في خدمة التكنولوجيا الفائقة لمحاولة معرفة المشاكل التي قد تنشأ عند تطوير منتج جديد وكيفية تجنبها.
1. ننسى العملية ، والعمل من أجل النتيجة
عند تطوير منتج ، غالبًا ما تكرس الشركات كل اهتمامها ومواردها لعملية الإبداع والإنتاج. حتى إذا تم تنفيذ كل مرحلة من مراحل العمل "وفقًا للتكنولوجيا بدقة" ، فقد لا تكون النتيجة وردية كما بدت في البداية.
دراسة حالةقبل ثلاثة أشهر ، قدم فريق Rookee عملية تحليلات نظام معقدة. كان على المحلل طلب وجمع أبحاث التسويق ، وإعداد خيارات الحلول ، وطلب الحسابات المالية ، وتصميم الخوارزميات ، وتعيين المهام لـ UX ، وتحديد متطلبات العمل ، وحماية قراراته ، وتتبع النتيجة بعد الحساب ، ونقلها إلى التشغيل ، إلخ. يمكن أن يصل الحمل على محلل واحد إلى 15 مهمة في اليوم. جسديًا ، لا يمكن للأخصائي المرور من خلال العديد من المهام المتنوعة يوميًا. ليس من المستغرب أنه مع مثل هذا الحجم ، كان عمل المحلل عنقًا ضيقًا في حل المشكلات الشائعة. لتحسين الكفاءة ، ذهبت العديد من الأشياء. ونتيجة لذلك ، تخلت الشركة عن مثل هذه العملية المعقدة وتبسطها جذريًا ، حيث وزعت المسؤوليات بين المتخصصين المختلفين. زادت الكفاءة ، وبدأت عملية التحليلات تحدث بشكل أسرع.كيف تتجنبإذا كانت عملية تطوير المنتج معقدة للغاية والنتيجة لا تلبي التوقعات ، فمن الضروري مراجعة العمليات الحالية وتصبح أكثر مرونة مع التغييرات في كل مرحلة من مراحل العمل.
2. حافظ على مزامنة الأمر عالية
تعد القدرة على العمل ضمن فريق مهارة مهمة لا يمتلكها الجميع. من الناحية العملية ، غالبًا ما تنشأ المواقف عندما يتطلب تنفيذ مهمة واحدة إشراك العديد من المتخصصين في وقت واحد.
على سبيل المثال ، تنطوي مهمة إدخال رمز ترويجي في النظام على عمل مطور أمامي وخلفية. إذا لم يتمكن هؤلاء الناس من الاتفاق فيما بينهم ، فقد تنشأ مجموعة متنوعة من المشاكل. على سبيل المثال ، من وجهة نظر المرئي ، سيتم تنفيذ المهمة ، ولكن بدون خوارزمية تطوير آليات الشفرة الترويجية ، لن تعطي هذه المهمة أي قيمة.
دراسة حالةعندما ظهرت العديد من المنتجات المختلفة في خدمتنا ، بقيت فرق التطوير لكل منتج خاصة بهم. مستخدم واحد وحساب واحد والمنتجات والفرق مختلفة. اتصل بنا أحد العملاء بطريقة أو بأخرى وقال إننا أرسلنا له رسائل غير مرغوب فيها. اتضح أن جميع الفرق أرسلت إليه رسائل عندما كانت هناك حالات تتطلب الانتباه (على سبيل المثال ، كان الرصيد يقترب من الصفر ويمكن تعليق الخدمة). ونتيجة لذلك ، تلقى المستخدم حوالي 40 رسالة من الخدمة في الأسبوع. تم إجراء تحليل للرسائل الإخبارية بالبريد الإلكتروني. بعض الحروف مجتمعة. نحن الآن نعمل على استراتيجية البريد الإلكتروني التي ستصلح جميع أوجه القصور في النهاية.كيف تتجنبلتحقيق التزامن عبر المهام ، قم بتنسيق إجراءات الفريق / الفرق التي تعمل على نفس المنتج. على سبيل المثال ، قم بإجراء "عرض توضيحي" عام للتصميم والتطوير ، وأبلغ الفرق الأخرى بالميزات الجديدة. أنشئ مستندًا متاحًا للجميع مع محفوظات إصدار تصف بوضوح ماذا ومتى وبأي فريق تم القيام به ، مع إضافة ارتباط إلى المهمة في تعقب المهام.
3. تجنب ترقيات المنتج كما هو مطلوب من قبل المستخدم.
حددت منتجات جديدة مشاكل أثناء التشغيل. ليس سراً أن بعض التحسينات على المشاريع قد بدأها المستخدمون الذين اتصلوا بخدمة الدعم. لا أحد يجادل: يجب تحسين المنتجات ، ولكن قبل التسرع في "إصلاح الفجوات" ، يجب أن تبحث عن السبب الجذري للمشكلات.
اجمع طلبات المستخدم لفترة كافية من الوقت. اعتمادًا على عدد المكالمات إلى خدمة الدعم ، يمكن أن تكون هذه الفترة إما أسبوعًا أو شهرًا أو أكثر. حلل المشكلات وحدد المشكلات المتكررة وحل المشكلات التي يشتكي منها المستخدمون في أغلب الأحيان. إذا كانت المشكلة محجوبة في طبيعتها ، أي أنها تؤثر على التشغيل الصحيح للمستخدم في النظام ، قم بحلها على الفور.
4. دعوة المطورين لمناقشة مهام المشروع والتصميم
في كثير من الأحيان ، بعد أن استلم متطلبات الأعمال للعملاء ، شرع المصمم في وصف منطق المهام. إذا لم تأخذ في الاعتبار الميزات التقنية للنظام ، فقد تحصل على حل ينتج عنه 3 أشهر من التطوير.
دراسة حالةمرة واحدة في Rookee ، حدث موقف. لقد رسموا الواجهة التي يوجد بها معالج لإنشاء مشروع في أحد المنتجات: في الخطوة الأولى ، يقوم المستخدم بتسجيل الدخول إلى خدمة أخرى للحصول على معلومات منه (في Yandex.Direct) ، في الخطوة الثانية ، يتم تحديد قائمة معلمات العمل. تم الحصول على المعلمات من خلال تنفيذ طلب الرمز المميز المحدد في الخطوة الأولى.
تم عرض الواجهة على العملاء ، المتفق عليها ، وتم إرسالها إلى المطورين. عندما رأى المطورون هذا ، قالوا: "هنا يجب عليك عرض فيلم ، لأنه إذا كان لدى المستخدم الكثير من البيانات ، فيمكنه الانتظار لفترة طويلة جدًا. بالإضافة إلى ذلك ، فإن هذا الحل الأمامي ليس سهل الاستخدام ".
ونتيجة لذلك ، كان علي إعادة كل شيء ، مع الأخذ في الاعتبار ردود الفعل من المبرمجين.كيف تتجنبدعوة المطورين للمشاركة في مناقشة المشاريع وصياغة المتطلبات وإشراكهم في التصميم. من خلال دمج المطورين في العمل في المراحل المبكرة ، يمكنك تقليل الوقت المستغرق لإنشاء مشروع بشكل كبير ، وتجنب تكاليف إعادة العمل غير الضرورية ، والاستغناء عن شعر رمادي إضافي بسبب عدم تجاوز الموعد النهائي.
5. تبسيط. رائعة ، عندما تكون فعالة
بشكل دوري ، يخرج المتخصصون التجاريون بأفكار رائعة عند إنشاء منتجات جديدة أو وضع اللمسات الأخيرة على المنتجات القديمة. لسوء الحظ ، ليس كل عبقري في الطلب ويمكن تحقيقه.
دراسة حالةلزيادة المبيعات ، غالبًا ما تستخدم استراتيجيات البريد الإلكتروني لحقوق الطبع والنشر. هناك العديد من الطرق لتنفيذها: إعداد إرسال الأحداث ، خدمة رسائل إخبارية عبر البريد الإلكتروني من جهة خارجية ترسل رسائل بريد إلكتروني عند إشارة الخدمة ، وتنفيذ منطق تشغيل واحد على جانب الخدمة الخاصة بك واستخدام نموذج قياسي أو عالمي للبريد ، إلخ.
في بعض الأحيان تقرر الشركات أن تسير بطريقتها الخاصة ولا تحب أي شخص آخر. عند كتابة الرسالة الأولى للمستخدمين في الفريق ، اعتقدوا أنها ستكون الأخيرة. ثم أرسلوا رسالة أخيرة. وأكثر ... عندما كان هناك الكثير من الرسائل ، نفذ الفريق خدمته لإنشاء قوالب. تم ذلك لمدة شهرين ولم تكن جيدة مثل الخدمات المتخصصة الموجودة. ونتيجة لذلك ، توصلت الشركة إلى حل مثالي - دمج خدمة بريدية لطرف ثالث.كيف تتجنبإذا كان تنفيذ الابتكار يبدو معقدًا للغاية ، فتخلص منه.
لا تضيع الوقت في إنشاء الخدمات التي ستفقد بوضوح للخدمات القائمة. أجب على سؤالك ، هل تحتاج حقًا إلى أداة يصعب صيانتها ، ولكنك تمتلكها؟
6. تجنب التفسير الغامض للمتطلبات
تخلق المهمة الغامضة سوء فهم يمكن أن يؤدي إلى نتائج غير مرغوب فيها. على سبيل المثال ، قد يسأل أحد المحللين: "أضف خمسة أفيال بجوار حقل التسجيل". لأعضاء مختلفين في الفريق ، قد يكون هناك إصدارات مختلفة من هذا "بجانب": يمين ويسار وأعلى وأسفل.
إذا لم يتم فهم المتطلبات بشكل كامل ، فيجب طرح أسئلة توضيحية. يجب أن يتعلم أعضاء الفريق كيفية تعظيم تفاصيل كل مهمة لتجنب الارتباك والتفكير. تتم مناقشة مستوى تفاصيل المتطلبات داخل الفريق. يمكنك أيضًا تطوير نموذج المعارف التقليدية الذي يناسب الجميع ، وكتابة هدف المهمة والمنطق وواجهة المستخدم فيه بالتفصيل قدر الإمكان.
7. تذكر الجمهور المستهدف.
من الغريب أن هناك أناسًا يؤمنون: من الأفضل جذب أكبر عدد ممكن من المستخدمين ، ومن بينهم سيكون هناك بالتأكيد جمهور مستهدف للمنتج. الأمر ليس كذلك. قد يكون لديك منتج معين يكون مستهلكوه شريحة محددة من المستخدمين.
دراسة حالةالجمهور المستهدف للمنتج ربات منازل ، لكن المشروع أراد الحصول على الكثير من الحركة. بعد أن أنفقت مبلغًا كبيرًا على الإعلانات ، بدأت الشركة في نشر لافتات غامضة على بوابات الأعمال الكبيرة على أمل جلب عملاء مذيبين. زادت حركة المرور بشكل كبير ، ولكن المبيعات لم تزد. عندما أجرينا استبيانًا حول سبب زيارة المستخدمين للموقع وعدم شراء أي شيء ، اتضح أن معظمهم ببساطة ليسوا جمهورًا مستهدفًا. المنتج المقترح ببساطة لم يعجبهم. تم إجراء تغييرات على الحملة الإعلانية ، وتم حل المشكلة بعد مرور بعض الوقت.كيف تتجنبفي البداية ، من الأفضل تركيز جهودك على جذب حركة المرور المستهدفة وإجراء تعديلات على الحملات الإعلانية وتحديد المواقع إذا كان زوار الموقع ليسوا بالتأكيد عملائك المحتملين.
8. تجنب تقاطع الاختبارات المقسمة عند اختبار الفرضيات
قد تنشأ مثل هذه المشكلة إذا كانت الفرضيات سيئة التخطيط أو إذا كان المحللون غير مؤهلين بشكل جيد.
دراسة حالةبدأت الشركة في اختبار نسختين من نموذج التسجيل على الصفحة المقصودة (يرى 50٪ من المستخدمين إصدارًا واحدًا ، و 50٪ يرون الآخر). ثم أصبح من الضروري اختبار فرضية أخرى في منطقة الدفع ، وبدأ اختبار آخر. وقد أدى ذلك إلى تعقيد عمل المحللين ، حيث استغرق تقسيم الأتراب وقتًا طويلاً بطريقة لتقييم تأثير التغييرات على الإجراءات النهائية للمستخدم. استغرق جمع البيانات وقتًا أطول مما كان مطلوبًا عند إجراء الاختبارات واحدًا تلو الآخر.كيف تتجنبعند إجراء اختبارات A / B ، لا تسمح بالتقاطع. حاول فصل المستخدمين بحيث يشارك شخص واحد في تجربة واحدة فقط. إذا كنت لا تزال تجري اختبارين في وقت واحد فجأة ، فقم بتقييم 4 مجموعات:
- الإصدار الأول من الهبوط + الخيار الأول في منطقة الدفع ؛
- الإصدار الأول من الهبوط + الخيار الثاني في منطقة الدفع ؛
- خيار الهبوط الثاني + الخيار الأول في منطقة الدفع ؛
- خيار الهبوط الثاني + الخيار الثاني في منطقة الدفع.
9. لا تخلط بين رأيك وبين رأي المستخدم
أحد الأخطاء النموذجية هو تبني رأي المرء لرأي المستخدم. إذا كنت تحب منتجًا وتصميمه وسهولة استخدامه ، فأنت تفهم كيفية التفاعل معه ، وليس حقيقة أن المستخدم سيشاركك حماسك.
عند تطوير كل منطقة منفصلة للواجهة ، ضع في اعتبارك رؤية الخدمة بأكملها ككل. لا تفكر للمستخدم. اسأله (على سبيل المثال ، باستخدام طريقة مجموعة التركيز) كيف يشعر بالراحة أكثر وأكثر دراية وأفضل مما يتوقعه من منتج جديد. قبل إطلاق المنتجات ، تجري Yandex اختبارات وجهًا لوجه: تجتمع مع المستخدمين ، وتنظر في ردود أفعالهم ، وتطرح أسئلة غير مريحة على فرضيته.
إذا كنت تعرف مسبقًا رأي المستخدم في التطوير ، فيمكنك تجنب العديد من المشكلات في المستقبل.
10. سجل الأحداث إلى أقصى حد
في حالة وجود موقف مثير للجدل في تشغيل أي وحدة نمطية للنظام ، يكون من الأسرع والأسهل التحول إلى سجلات الأحداث. إلا إذا كانوا كذلك بالطبع. إذا كنت كسولًا ولم تقم بتسجيل الأحداث ، فسيتعين عليك العمل بجد للعثور على المصدر الأساسي للمشكلة عند حدوثها.
كيف تتجنبسجل الأحداث إلى أقصى حد. هذا لا يعني أنك بحاجة إلى بدء تسجيل كل التفاصيل الصغيرة ، مثل حركة المستخدم باستخدام الماوس ، ولكن يجب تسجيل المعلومات الأساسية التي تحدث مع الكائن.
الخلاصة
قد تواجه أي شركة مشاكل عند تطوير منتجات جديدة. الشيء الرئيسي هو الاعتراف بالأخطاء ، واستخلاص النتائج واتخاذ الإجراءات حتى لا تحدث مرة أخرى في المستقبل.
وفي ممارساتك التنموية ، حدث الفشل وكيف تعاملت معها؟ أخبرنا عن تجربتك في التعليقات.
نشرتها إيكاترينا هينديكاينن ، محللة نظم رئيسية ، خدمة
Rookee