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

مقدمة

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

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

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

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

هذه هي النصائح التي ستحل المشاكل أعلاه وتجعل عملية تطوير الميزات الجديدة للمنتجات منظمة وفعالة.

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

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

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

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

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

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

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

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

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

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

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

4. بناء التوافق

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

5. مراجعة المواصفات والقياسات المحددة للنجاح

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

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

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

7. النتائج

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

أخيراً

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

ملاحظات

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

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

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

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