أساسيات دورة تطوير المنتج

مقدمة

قبل أن يتطور Justin.tv إلى توتيش (Twitch) وسوشال كوم (Socialcam)، أمضينا سنوات بفهم غير صحيح لكيفية بناء المنتج. كان لدينا اجتماعات متعرجة حول المنتجات حيث لم نكتب قراراتنا، ولم نقم بتحديد منتجات جديدة بعناية، لذلك غالباً ما كانت لدى أعضاء الفريق أفكار مختلفة قليلاً حول ما كنا نبنيه. أردنا دائماً بناء منتجات مكتملة التكوين بدلاً من التركيز على بناء أصغر المنتجات القابلة للعمل MVP، ونادراً ما كنا نحدد تحليلات المنتجات الجديدة ومواصفاتها المطروحة (spec’d the analytics)، لذلك لم نكن نعرف غالباً كيف كانت تلك المنتجات تعمل بعد الإطلاق.

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

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

خطوات تنظيم عملية تطوير المنتج

حدد طول دورة التطوير الخاصة بك

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

حدد هدفك (أهدافك) وحدد قائد المنتج (the Product Lead)

لقد أجرينا اجتماعاً واحداً وفقط واحد للفريق. لقد كان اجتماع المنتج وقد حدث في اليوم الأول من دورة التطوير. أحياناً يستمر هذا الاجتماع لمدة خمس ساعات (آسف).

كل اجتماع حول المنتج ركز على واحد من الأهداف الثلاثة:

• زيادة إنشاء المحتوى
• زيادة المستخدمين الجدد
• زيادة الاستبقاء (retention)أو ما يدعى الحفاظ على المستخدمين الحاليين.

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

بصفتي رجل المنتج (the product person) في الفريق، كان دوري حماية وتحسين دورة التطوير والإشراف على اجتماعات المنتج لضمان شعور جميع أعضاء الفريق بالراحة وهم يساهمون. في كثير من الأحيان، مجرد الحصول على فرصة للتعبير عن فكرتك ومشاهدتها مكتوبة على السبورة – حتى لو لم يتم بناؤها – يزيد بشكل كبير من القبول من قبل الفريق.

العصف الذهني المنظم والشامل

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

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

بناء التوافق

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

مسح المواصفات والقياسات المحددة للنجاح

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

العمل أثناء دورة التطوير

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

النتائج

في نهاية اليوم، لم تحقق سوشال كوم (Socialcam) حلمنا بأن نكون ” إنستغرام (Instagram) للفيديو”. في الواقع، ما كان يجب أن نبنيه يبدو أقرب كثيراً إلى سنابشات (Snapchat). لكن هذه العملية سمحت لنا بالتكرار بسرعة كبيرة. نتيجةً لذلك، تمكنا من إنتاج قائمة طويلة من الميزات الرائعة بسرعة كبيرة: مرشحات الفيديو، وحدود الفيديو، وعناوين الفيديو، والمقاطع الصوتية للفيديو، وتحسينات تغذية الفيديو، وإعادة التصميمات المرئية المتعددة، وملفات تعريف المستخدمين، والقنوات الموصى بها، وتبديل الكاميرا الخلفية والأمامية أثناء الفيديو، والكثير الكثير. كما سمح لنا بتجربة ميزات النمو التي أنتجت 16 مليون عملية تنزيل في حوالي 3 أشهر وأكثر من 100 مليون شخص يشاهدون الفيديو على موقعنا خلال نفس الفترة الزمنية. والأهم من ذلك، أننا قمنا بكل هذا العمل بسرعة وكفاءة، دون جدالات كبيرة، أو مشاكل تتعلق بالتزام المؤسسين، أو أي مشاكل جماعية على الإطلاق. أحياناً أتساءل ما الذي كان سيحدث إذا واصلنا البناء لعام آخر بدلاً من بيع الشركة … لكن هذه قصة أخرى.

أخيراً

شكراً لك جيرالد و جويف وكريج على مساعدتي في هذا المنشور، أمون و غولاوم، شركائي المؤسسيين في سوشال كوم (Socialcam)، وجوستين، وإيميت، وكايل على النجاة من كل آلام الأيام الخوالي في Justin.tv.

ملاحظات

هذه المحاضرة:

بواسطة: مايكل سيبل Michael Seibel، مدرسة الشركات الناشئة، حاضنة الأعمال YC

ترجمة وتدقيق لغوي: لمى عبد الستار

مراجعة: هدى الميداني

نص المقالة بالإنكليزية:

https://www.ycombinator.com/library/4e-product-development-cycle-fundamentals