المحتوى عن 'نهاية المنتج'.



مزيد من الخيارات

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المُحتوى


التصنيفات

  • الإدارة والقيادة
  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • السلوك التنظيمي في المؤسسات
  • عالم الأعمال
  • التجارة والتجارة الإلكترونية
  • نصائح وإرشادات
  • مقالات ريادة أعمال عامة

التصنيفات

  • مقالات برمجة عامة
  • مقالات برمجة متقدمة
  • PHP
    • Laravel
    • ووردبريس
  • جافاسكربت
    • لغة TypeScript
    • Node.js
    • React
    • Vue.js
    • Angular
    • jQuery
    • Cordova
  • HTML
    • HTML5
    • إطار عمل Bootstrap
  • CSS
    • Sass
  • SQL
  • لغة C#‎
    • ‎.NET
    • منصة Xamarin
  • لغة C++‎
  • لغة C
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • برمجة أندرويد
  • لغة R
  • الذكاء الاصطناعي
  • صناعة الألعاب
  • سير العمل
    • Git
  • الأنظمة والأنظمة المدمجة

التصنيفات

  • تصميم تجربة المستخدم UX
  • تصميم واجهة المستخدم UI
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب GIMP
    • كريتا Krita
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • نصائح وإرشادات
  • مقالات تصميم عامة

التصنيفات

  • خوادم
    • الويب HTTP
    • قواعد البيانات
    • البريد الإلكتروني
    • DNS
    • Samba
  • الحوسبة السّحابية
    • Docker
  • إدارة الإعدادات والنّشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
    • ريدهات (Red Hat)
  • خواديم ويندوز
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • شبكات
    • سيسكو (Cisco)
  • مقالات DevOps عامة

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • استسراع النمو
  • المبيعات
  • تجارب ونصائح
  • مبادئ علم التسويق

التصنيفات

  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • مقالات عمل حر عامة

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
  • أندرويد
  • iOS
  • macOS
  • ويندوز
  • الترجمة بمساعدة الحاسوب
    • omegaT
    • memoQ
    • Trados
    • Memsource
  • أساسيات استعمال الحاسوب
  • مقالات عامة

التصنيفات

  • شهادات سيسكو
    • CCNA
  • شهادات مايكروسوفت
  • شهادات Amazon Web Services
  • شهادات ريدهات
    • RHCSA
  • شهادات CompTIA
  • مقالات عامة

أسئلة وأجوبة

  • الأقسام
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة البرمجة
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات
    • أسئلة الشهادات المتخصصة

التصنيفات

  • ريادة الأعمال
  • العمل الحر
  • التسويق والمبيعات
  • البرمجة
  • التصميم
  • DevOps

تمّ العثور على 1 نتيجة

  1. إنّ أفضل شيء يفعله مدير مُنتج ما هو أن يقرّر أين تنتهي حدود مُنتجه، وأين تبدأ مهمّة مُنتج آخر. لا يستحق التطبيق كلفة الإنشاء أو التّسجيل، ناهيك عن سعر الشراء الحقيقي إذا كان الأثر الذي يُحدثه صغيرًا. وبالمثل إذا كان الأثر الذي يحدثه كبيرًا جدًّا فسيصطدم مع البرامج الموجودة مسبقًا أو تدفّق العمل workflow الذي اعتاد عليه المستخدمون بالفعل. إنّها معضلة المُنتج المعتدل، يجب عليك أن تجد المُنتج المناسب فحسب. مثال: تطبيق تعقب الوقت Time trackingيعتبر تعقّب الوقت، كحد أدنى مطلق (أي في صورته القاعدية)، مجرّد جمع قائمة من الأرقام، وإذا كان هذا هو أقصى ما يقدّمه التّطبيق فسيكون عديم الفائدة. حيث أنّ مستندات جوجل أو اكسل تقوم بهذه المهمة بالفعل. وسندرك عند هذه النّقطة أنّ البساطة مبالغ فيها، وأنّه ليس هنالك ما يمكن إضافته لتحسين التّطبيق، لا مجموعة من الخطوط، ولا خصائص HTML5 ولا المؤثّرات الصّوتيّة. وكحد أعلى، يمكن أن يشتمل تعقّب الوقت على إدارة المشاريع، الميزانيّات، المتعاقدين، قوائم الحسابات، تعقّب وصولات الاستلام، ورصد الموظّفين. إنّ التّطبيقات التي تتضمن العديد من المهام تتجاوز حدودها لتتخطاها إلى أراضي مُنتجات أخرى يعتمد عليها المُستخدم بالفعل (كـ Xero، Ballpark، Basecamp، إلخ.) إنّ المُنتجات توجد لحل المشاكل التي تحدث في تدفّق العمل، وتمتلك نقطة بداية ونقطة نهاية في ذلك التدفّق. ولكي تعرف مواقع هذه النقاط يجب أن تفهم تدفّق العمل بالكامل. لنلقي نظرة على تدفّق العمل لفريق يقوم بطلب وجبات الغداء كل يوم. إذا كنت تقوم ببناء تطبيق يساعد الفريق على طلب وجبات الغداء كل يوم، يمكن أن يكون تدفّق العمل كالتالي: يجوع أحدهم.يقوم أحدهم بإخبار بقية أفراد الفريق.تتم المناقشة حول الخروج لتناول الطعام أم القيام بالطلب.تتم مناقشة أخرى حول المكان الذي يُطلب منه.يتم تمرير قائمة بأماكن مختلفة بين الجميع.يتم التّوصل إلى قرار ما بسرعة.يُعيّن شخص ما لجمع طلبات الجميع.يقوم ذلك الشخص بالطلب.يقوم ذلك الشخص بإخبار الجميع عن وقت التسليم وكلفة الطلب.الوقت يمضي.يصل الطعام، ويؤكل.يتحقق الشخص الذي قام بالطلب من الأشخاص الذي دفعوا والذين لم يدفعوا مقابل الوجبة.تتم التّسوية المالية، أو أنّها تؤجل إلى الغد.سيتحدّث بعضهم عن الوجبة في فيس بوك أو تويتر، وبعضهم يقوم بنشر الصور على إنستجرام، وآخرون يقيمونها على Yelp.يعود الجميع إلى العمل.بإمكانك عندما تفهم تدفّق العمل بالكامل أن تركّز على المجموعة الجزئية الأكثر إشكالًا التي يحلّها مُنتجك، أو بدلًا من ذلك، التركيز على الجزء الذي بإمكانك جعله أكثر متعة وإثارة للاهتمام. هنالك مقال للمطّور Don Dodge بعنوان "هل مُنتجك عبارة عن فيتامين أم مسكّن ألم" والذي يناقش فيه الفرق بين الخيارين. من أين يجب أن تبدأ؟إنّ الخطوة الأولى لمُنتجك يجب أن تتحدّد عندما تستطيع إضافة قيمة. بالنسبة للمثال أعلاه، ربّما تكون هذه هي الخطوة الرابعة. يمكن في البدايات المبكّرة أن تقوم ببناء مُنتجات للدردشة أو البريد الإلكتروني، ونادرًا ما تكون البداية فكرة جيّدة. من الأمثلة الواقعية على ذلك تطبيق TripIt. يقوم هذا التطبيق بتقديم الحلول لإدارة الرحلات. يمكن أن تكون خطوة البداية لهذا التطبيق هي البحث عن الرحلات، لكنّ TripIt لم يستطع إضافة قيمة في هذه الحالة. إنّ أوّل مرحلة يمكنهم إضافة قيمة عندها هي بعد أن يتم الحجز. قام TripIt بإضافة حل رائع وذلك بفهم تدفّق العمل بالكامل. إنّ آخر أمر يمكن أن يحدث قبل أن يستطيع TripIt إضافة قيمة هو أن "يفتح المستخدم رسالة تأكيد الحجز"؛ هذه هي المرحلة الأولى التي يستطيع فيها TripIt إضافة قيمة لكي يبدأ مع تلك الرسالة ويقوم بالاستيراد من هناك. وبالمثل، يبدأ إنستجرام عن طريق استيراد شبكات التواصل الاجتماعي الخاصة بك، أو يبدأ تطبيق تعقّب الوقت عن طريق استيراد المشاريع من Basecamp. إنّ واجهات التّطبيقات الجيّدة وميزات الاستيراد تساعد المستخدمين على الاستمتاع ببداية سهلة التّشغيل. أين يجب أن تتوقف؟ يجب أن تقوم ميزانيّتك، سواءً كانت ميزانية الوقت أو المال، بحد نطاق المُنتج من دون تحديده (أي من دون تحديد/تعريف نطاق المُنتج) . يجب أن تحدّد الميزانية الكبيرة كيفية حل المشكلة وليس عدد المشاكل التي تعالجها، حيث أنّه من شبه المستحيل أن تحاول معالجة تدفّق العمل بأكمله من البداية حتّى النهاية ولجميع فئات المستخدمين. يجب أن يتوّقف مُنتجك عندما: تسعى وراءه شركات رائدة ومعروفة في السوق (مثل PayPal، IMDB، Expedia) وأنت لست على استعداد للمنافسة.تنتهي المرحلة التالية من المنتج بالعديد من الطرق المختلفة باستخدامه من قبل العديد من الفئات المختلفة من المستخدمين. مثلًا، محاولة معالجة الرواتب في تطبيق تعقّب الوقت قد تكون صعبة أو معقّدة.تشتمل المرحلة التالية على مستخدمين نهائيين end users مختلفين عن المستخدمين في المراحل السابقة، مثلًا المدراء، المحاسبين، إلخ.يصل إلى مرحلة لا تستطيع فيها تقديم أي قيمة.حدد وألغ الخطوات عديمة المعنى إذا انتهى المستخدم من استخدام تطبيقك وكانت الخطوة التالية التي سيقوم بها هي تنزيل ملف لإرساله إلى عبر البريد الإلكتروني، فإن هذه خطوة عديمة المعنى. إذا كان المستخدم سيقوم بتصدير بياناته الماليّة كملف CSV ومن ثم يقوم بتحميله وتحويله إلى ملف XLS ثمّ إرساله عبر البريد الإلكتروني إلى المحاسب، فهذه الخطوة عديمة المعنى أيضًا. وإذا تم الانتهاء من مشروع، ثم يتم تنزيل جميع الملّفات، تحويلها إلى ملفات مضغوطة ثم إرسالها إلى العميل للأرشفة، فهذه خطوة عديمة المعنى أيضًا. غالبًا ما يكون البريد الإلكتروني مصدرًا للخطوات عديمة المعنى التي نادرًا ما تحمل معلومات كافية ("قام شخص ما بنشر تعليق")، أو أنّها لا تحيل إلى إجراءات بديهيّة (التأكيد، التأشير كـ "محلول"، إلخ). وبشكل عام، يجب أن تتكون لديك صورة واضحة عن الخطوة التي يجب إزالتها في الحالة التي يقوم في المستخدم بالنقر خلال سلسلة من الخطوات دون أخذ فكرة معيّنة أو اتخاذ قرار معيّن على طول المسار. الخطوات المستقبليةحاول دائمًا أن تكمل النواقص وتسد الثغرات في المُنتج قبل توسيعه. إنّ الانتقال من البرامج الجاهزة إلى برامج الاشتراك subscription هو بمثابة مكافأة للمُنتجات الموثوقة والكاملة، وليس المُنتجات مُفرطة الخصائص والمليئة بالأخطاء. إنّ توسيع المُنتج ليقوم بحل مشاكل أكبر يمكن أن يعود بفوائد كبيرة، لكن لا يمكن لذلك أن يحدث إلّا إذا كان الأساس راسخًا. فإذا كان مُنتجك الأساسي ليس شاملًا، ستؤدي إضافة ميزات إضافية إلى جعل الأمور أسوء. كثيرًا ما يُكتب هذه الأيام حول تحري البساطة، لكن هناك التباس في الأمر؛ حيث أنّ هنالك فرق أساسي بين تبسيط المُنتج وعمل مُنتج بسيط. إنّ تبسيط المُنتج يؤكّد على إزالة جميع التعقيدات غير الضّرورية لكي يستطيع كل المستخدمين حل مشاكلهم بأكبر كفاءة ممكنة. أمّا عمل مُنتج بسيط يعني التركيز على مجال معين واختيار أصغر المجموعات الجزئية من تدفّق العمل حيث يمكن للمُنتج أن يقدم قيمة. ولذلك ينطوي المُنتج الفعّال القاعدي MVP على خطر تصنيفه كحلّ جزئي أو نقطي point solution، أو حتّى أسوء من ذلك؛ اعتباره "خاصيّة وليس مُنتج". لذلك يجب أن تراعي "أين ترسم الخط" عندما تقوم ببناء مُنتج بسيط. ترجمة -وبتصرّف- للمقال Where to Draw the Line لصاحبه: Des Traynor. حقوق الصورة البارزة: Designed by Freepik.