دورة حياة المنتج: رحلة إحدى ميزات المنتج

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

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

T - 30 يومًا

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

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

T - 25 يومًا

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

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

تي - 15 يومًا

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

T = 0 (ويعرف أيضًا باسم ولادة ميزة المنتج)

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

T + 15 يومًا

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

T + 30 يومًا

ينتهي Sprint 1. يتم طرح جزء من ميزة المنتج. قد لا تواجه العملاء بعد ، ولكن معظم الفرق تتبع منهجيات Agile اليوم لتطوير البرامج - مما يعني أننا نبني بشكل تدريجي ومتكرر. لذلك ، بدلاً من إنشاء ميزة كبيرة في 6 أشهر وإصدارها كلها مرة واحدة ، نقوم بتقسيم كل شيء إلى أجزاء مستقلة يمكن أن تعمل بمفردها (مجموعة من قصص المستخدمين) وتكون جاهزة بسرعة للمراجعة والتكرار.
يتأكد مدير المنتج من أن الجدول الزمني للإصدار على المسار الصحيح من خلال اجتماعات ومناقشات سكروم اليومية مع المدير الهندسي ذي الصلة الذي يعمل في المشروع. في حالة وجود تأخير ، يتم تعديل الجداول الزمنية وفقًا لذلك ، أو يتم إسقاط أجزاء صغيرة من الميزات للتأكد من أن الإصدار في الوقت المحدد. بعد كل سباق ، يتم تقديم التقدم المحرز إلى مدير المنتج وأصحاب المصلحة المعنيين في اجتماع ، وبعد الموافقة يتم إصداره.
عام واحد من برنامج UpGrad لإدارة المنتجات

T + x يوم

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

T + y أيام

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

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

يحاول مدير المنتج فهم السبب الجذري للخطأ ، ووفقًا للأولوية ، يقوم بجدولة الإصلاح لدورة الإصدار التالية - يمكن إضافته في السباق الحالي إذا كان ذا أولوية عالية أو حتى سباقات السرعة اللاحقة. بعد إصلاح الخطأ وإطلاقه ، يعيش السيد فيتير ليرى يومًا آخر ، وإن كان في شكل مُعدَّل - السيد Feature 2.0 - بفضل مدير المنتج والفريق الهندسي. مجد!

T + z أيام

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

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

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

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

برنامج مميز لك: برنامج شهادة التفكير التصميمي من Duke CE