
كل شيء كما في الحياة.
الخلفية
في المنهجيات الكلاسيكية ، لم يكن دور مالك المنتج. لأول مرة ، ظهر دور مالك المنتج في إطار عمل سكروم. قبل ذلك ، كان دور مدير المشروع في منهجية PMI PMBoK هو الأقرب في المعنى. احتوى دور مدير المشروع على عدد من التناقضات وتضارب المصالح:
- كان مدير المشروع مسؤولاً عن كل من الفريق والعلاقة مع العميل. لسوء الحظ ، فإن مصالح العميل تتعارض مع مصالح الفريق.
- كان مدير المشروع مسؤولاً فقط عن مرحلة إنشاء المنتج. لا يهتم مدير المشروع بما سيحدث لاحقًا ، الشيء الرئيسي هو إنهاء المشروع بالخصائص اللازمة والجودة وتلبية الميزانية في الوقت المحدد.
- لا يحتاج مدير المشروع إلى معرفة كيفية بيع المنتج والترويج له. وبالتالي ، هناك العديد من المشاريع الفاشلة في السوق ، ولكنها ناجحة رسميًا (تم الانتهاء منها في الوقت المحدد وفي حدود الميزانية).
حل هذه المشاكل ، صانعي سكروم:
- قسمنا دور مدير المشروع إلى قسمين: سيد سكروم ، الذي يعتني بالفريق ، وهو نوع من المربية الصارمة ولكن المحبة ، وصاحب المنتج.
- جعلوا ذلك بحيث لا تنتهي مسؤولية مالك المنتج عند الانتهاء من التطوير ، ولكنها تستمر خلال فترة التشغيل التجاري.
- قررنا أن اختصاص مالك المنتج يشمل: التسويق والمبيعات والمعرفة التجارية ومجال الموضوع.
من هو صاحب المنتج؟
مالك المنتج هو جندي عالمي يفهم ما هو تطوير البرمجيات ؛ يعرف دورة حياة التطوير ؛ يمثل كيفية الترويج لمنتج وبيعه ، ويفهم ظروف السوق واتجاهات السوق المستهدفة ؛ يعرف واجهة المستخدم و UX ؛ يمكن التنبؤ بقياسات المنتج الرئيسية وقياسها.
قد تبدو قصة مالك المنتج المثالي كما يلي:
- عمل في مجال تكنولوجيا المعلومات كمطور أو مخطط أو مصمم.
- بفضل صفات التواصل والقيادة ، والتي تعتبر نادرة في تكنولوجيا المعلومات ، فقد نمت لتصبح مدير المشروع.
- لم أتوقف عند هذا الحد وبدأت أتطور في اتجاه الأعمال والتسويق والمبيعات.
ولكن ، هذا مثالي ، ولكن من الناحية العملية: أي شخص يأتي بـ "أفكار رائعة" يعتبر نفسه صاحب المنتج. علاوة على ذلك ، عندما لا يتم إطلاق هذه الأفكار ، يمكنك إلقاء اللوم على التطوير أو المصممين أو التسويق أو المبيعات.
7 خطايا صاحب المنتج
- لا تطرح فرضيات عمل قابلة للقياس. أي إذا قمنا بتنفيذ هذه الميزة ، فسوف نحصل على مثل هذه الميزة: زيادة التحويل بنسبة n٪ ، وتقليل تكلفة المستخدم بمقدار m روبل ، وكسب الكثير من المال. علاوة على ذلك ، من الضروري ليس فقط تسمية القيم العشوائية للمقاييس ، ولكن أيضًا لتبرير هذه القيم.
- لا يشرح أهداف التغيير للفريق. إذا لم يفهم المقاول أو يشارك الأهداف ، تنشأ مشكلتان: المقاول لا يفعل ما يريده مالك المنتج ؛ يفعل ذلك بشكل سيئ وبطيء. بالإضافة إلى ذلك ، فإن الفريق هو الرقيب الأساسي على الفكرة. لا يمكنك أن تثبت للفريق قيمة الفكرة ، فكر فيما إذا كانت الفكرة منطقية.
- لا تشارك في التنفيذ. إذا لم يتحقق مالك المنتج من القطع الأثرية: قصص المستخدم ، والنماذج الأولية ، والمخططات الانسيابية ، والنتيجة ، فلن يحصل على ما يريد.
- لا تشارك في القبول. يجب أن يقبل مالك المنتج التغييرات الجاهزة قبل اختبار المتخصصين للتأكد من أنهم قد فعلوا ما هو مطلوب وبجودة مناسبة.
- لا يتحقق من النتائج. بعد طرح فرضيات العمل القابلة للقياس ، تحقق مما إذا كانت قد تحققت لتحقيق النتائج المتوقعة أم لا. أي تحقق من الخطة مع الحقيقة.
- لا يستخلص الاستنتاجات. بعد إدخال التغييرات ، من الضروري ليس فقط مقارنة الخطة بالحقيقة ، ولكن أيضًا لفهم سبب تحقيق هذه النتائج أو عدم الوصول إليها. في المستقبل ، حاول تعزيز النتائج الإيجابية ومستوى النتائج السلبية.
- لا يفكر في ما سيحدث للمنتج في المستقبل. من وكيف سيدعم المنتج ويطوره ويبيعه.
صاحب المنتج المثالي
إزالة الجسيمات "لا" من القائمة السابقة والحصول على مالك المنتج المثالي.
نصائح
- كلما عرفت المزيد عن المجالات ذات الصلة ، والأعمال التجارية ، والموضوع ، والمنافسين ، كان من الأسهل العثور على فكرة جيدة.
- كلما نجحت في الميزات ، زادت مصداقيتك مع الفريق والعميل. في مرحلة ما ، ستبدأ السلطة في العمل من أجلك.
- يستفيد الجميع - العميل لديه ميزات ناجحة ، فريق nishtyaki.