أهم 5 تحديات في عملية تطوير منتجات البنية التحتية للبريد الإلكتروني

البنية التحتية للبريد الإلكتروني هي النظام المترابط الذي يتيح إرسال الرسائل الإلكترونية واستلامها وتخزينها. على هذا النحو ، فإنه يلعب دورًا حيويًا في تسهيل تبادل المعلومات ، سواء كان ذلك بين B2B أو B2C.

في هذا الصدد ، تقدر شركة Radicati Group Inc. أن العدد الإجمالي لرسائل البريد الإلكتروني المرسلة سيقترب من 400 مليار في عام 2027. ومن المتوقع أن يصل عدد المستخدمين في جميع أنحاء العالم إلى 5 مليارات ، في نفس العام.

مع استمرار نمو حجم حركة البريد الإلكتروني ، يصعب إنكار أهمية وجود بنية أساسية قوية وموثوقة للبريد الإلكتروني.

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

1: قابلية التوسع

التحدي

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

العصف الذهني للتدابير بالتوازي مع تطوير المفهوم هو أمر موات. إذا لم يكن الأمر كذلك ، فيجب على المطورين القيام بذلك بإصدار MVP ، أو أنهم يخاطرون بما يلي:

• إنتاجية مفقودة
• قلة رضا العملاء
• الخسائر المالية المحتملة
• انخفاض في تصنيفات سلطة المجال
• إسقاط سمعة المرسل

الحلول:

• البنية التحتية القائمة على السحابة
• توزيع الحمل

استخدام البنية التحتية القائمة على السحابة

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

يبدو واعدًا ، لكن كيف يعمل بالفعل؟

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

1. النهج يقلل بشكل كبير من التكاليف التشغيلية.
2. كما أنه يوفر للمؤسسات حلاً قابلاً للتطوير لتلبية احتياجاتهم المتزايدة.

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

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

تنفيذ موازنة الحمل

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

الآن ، يشير موازنة الحمل إلى توزيع أحمال العمل عبر العديد من البنى والمهام في السحابة. الميزة الرئيسية هي أن المنتج الحالي يصبح قادرًا على التعامل مع الحجم المتزايد ، حتى في ذروة حركة المرور.

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

والأفضل من ذلك ، يمكن استخدام خوارزميات موازنة الحمل لضبط توزيع أحمال العمل ديناميكيًا ، بناءً على عاملين:

1. عدد الطلبات.
2. قوة المعالجة لكل خادم.

بناء جحيم واحد لمنصة الإقامة

في عام 2012 ، كانت عملية تطوير منتجات Airbnb في مرحلة محورية.

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

كانت Airbnb تواجه خيارًا محفوفًا بالمخاطر - توظيف أكثر من 1000 شخص في غضون عام أو بناء إطار عمل آلي للتعامل مع الحالات المتطورة.

نعم ، لقد اختاروا الأخير.

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

مع وجود إطار العمل في مكانه ، تم إلغاء حظر Airbnb بسرعة واستمر التوسع من 300٪ إلى 600٪ سنويًا. لاحظ أن هذه النسب المئوية تشير إلى النمو الأسي المبكر لـ Airbnb.

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

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

2: الأمن

التحدي

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

يحتاج فريق تطوير المنتج إلى مواجهة هذا التحدي في مرحلة مبكرة ، قبل الحد الأدنى من المنتج القابل للتطبيق بوقت طويل. لكنها لا تتوقف عند هذا الحد. يجب أن تكون عمليات تدقيق الأمان المنتظمة أولوية حتى لو كنت تتعامل مع منتج نهائي.

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

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

الحلول:

• التشفير
• بروتوكولات آمنة
• تحديثات إجراءات الأمان المنتظمة

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

كيف؟

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

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

ذكرنا سابقًا SSL و TLS التي تقوم بتشفير البيانات المتحركة (البيانات قيد النقل). لكن الشركات تحتاج أيضًا إلى النظر في تشفير البيانات في وضع الراحة وإنشاء مستويات وصول مختلفة إلى تلك البيانات.

"وعد الخنصر ، لن نخترقك!"

هذه حالة عمل سلبية إلى حد ما ، لكنها تُظهر بوضوح أن هناك دائمًا جانبين من جوانب الأمان - البرنامج والأشخاص.

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

في الأساس ، كان هذا يعني أن المحتالين عبر الإنترنت استخدموا موظفي Mailchimp المطمئنين ، وربما عديمي الخبرة ، للوصول إلى البيانات المحمية. قام المحتالون بخداع الموظفين للحصول على أوراق اعتمادهم ، وبالتالي قاموا باختراق الأشخاص ، وليس النظام نفسه. ومع ذلك ، تم الكشف عن معلومات حساسة لنحو 133 عميلاً.

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

3: الموثوقية

التحدي

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

لماذا؟

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

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

الحل:

• تنفيذ أنظمة التكرار والنسخ الاحتياطي
• مراقبة البنية التحتية بانتظام

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

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

عند الحديث عن المراقبة ، من الأفضل أن يقوم المطورون بإنشاء إنذارات فوق المراقبة. على سبيل المثال ، يجب ضبط الإنذارات للظروف التالية:

1. إذا بدأت العمليات في استهلاك المزيد من الذاكرة.
2. إذا كانت هناك مشكلات معينة في معالجة البيانات / الحوسبة.
3. في حالة 500 رد كود.

تتعلق هذه الإنذارات بدعم البنية الداخلية وإدارة المنتج عند الطلب ؛ كلاهما يجب أن يتم إنشاؤهما أثناء عملية تطوير البرنامج ، أو مع إطلاق المنتج الناعم.

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

كيف فعلها العمالقة

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

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

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

4: قابلية التشغيل البيني

التحدي

تشير إمكانية التشغيل البيني إلى قدرة البنية التحتية للبريد الإلكتروني ، أو أي خدمة SaaS ، على التكامل والعمل بشكل جيد مع التطبيقات الأخرى.

عادةً ، يجب أن تتضمن عمليات الدمج ما يلي:

1. إدارة علاقات العملاء (CRM)
2. تخطيط موارد المؤسسات (ERP)
3. مخزن البيانات

ما الفائدة؟

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

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

الحل:

• معايير مفتوحة
• التوافق عبر الأنظمة الأساسية

المعايير المفتوحة هي مواصفات متاحة للجمهور تسمح للأنظمة المختلفة بالعمل معًا.

تشمل المعايير الرئيسية المفتوحة مع البنية التحتية للبريد الإلكتروني بروتوكول نقل البريد البسيط (SMTP) ، وبروتوكول Post Office Protocol ، الإصدار 3 (POP3) ، وبروتوكول الوصول إلى الرسائل عبر الإنترنت (IMAP).

بالنسبة للتوافق ، يجب تصميم البنية التحتية للبريد الإلكتروني للعمل مع أنظمة تشغيل مختلفة (Windows و macOS و Linux) ، بالإضافة إلى متصفحات الويب المختلفة (Google Chrome و Mozilla Firefox و Safari وغيرها).

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

أخيرًا ، تحتاج فرق التطوير إلى إيلاء اهتمام وثيق للتوقيعات وحلول البريد العشوائي وسجلات DNS والمزيد ، فيما يتعلق بجعل برامجهم تعمل بشكل جيد مع عمليات تكامل الجهات الخارجية.

باختصار ، يتلخص هذا في اتباع التنسيقات والبروتوكولات القياسية في كل مرحلة من مراحل عملية تطوير المنتج. بعد ذلك ، يمكن للمهندسين تخصيص مهام سير العمل الخلفية والواجهة الأمامية عند الضرورة.

قطع علينا بعض سلاك

إذا كنت تعتقد أن Slack نجح في إعادة ابتكار الطريقة التي نتعاون بها ، فلن تكون مخطئًا. لكن السؤال هو كيف فعلوا ذلك.

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

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

اعتمادًا على حجم ونطاق عملك ، يمكنك توصيل Jira و Notion و Coda وتطبيقات Google وغير ذلك من أجل الحصول على جميع الإشعارات وقنوات البيانات تحت سقف واحد. كل ذلك في غضون أيام أو حتى ساعات.

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

5: إدارة توقعات الأداء

التحدي

يتمثل التحدي المتمثل في إدارة توقعات الأداء في ضمان أن المنتج يلبي احتياجات ومتطلبات المستخدمين النهائيين. لهذا السبب ، من الآمن مقارنة توقعات الأداء بتوقعات المستخدم ، لا سيما عند تطوير SaaS.

لكي نكون واضحين ، فإن نجاح منتج البنية التحتية للبريد الإلكتروني ، أو أي SaaS ، يعتمد إلى حد كبير على مدى جودة إدراك المستخدمين النهائيين والعملاء المستهدفين له. هذا هو - مدى تلبية المنتج لتوقعات أداء المستخدم.

مع تزايد الاعتماد على البريد الإلكتروني ، يتوقع المستخدمون أن تكون البنية التحتية آمنة وسريعة وموثوقة. بالإضافة إلى ذلك ، يريد المستخدمون أن يكون:

• سهل الاستخدام
• يمكن الوصول إليها من أجهزة متعددة
• كن قادرًا على التعامل مع حركة البريد الإلكتروني على نطاق واسع

الحل:

• اختبارات
• تحسين
• تواصل واضح
• حلقات التعليقات

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

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

توفر جميع الاتصالات والاختبارات للمطورين ملاحظات العملاء المؤهلين والتي بدورها تساعد في تلبية احتياجاتهم وتوقعاتهم. تتمثل الخطوة الحاسمة هنا في دمج التعليقات المقدمة في عمليات تطوير المنتج.

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

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

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

معركة العمالقة

كما ذكرنا سابقًا ، يستكشف هذا القسم المجالات التي ربما فشلت فيها Microsoft في توقعات الأداء ، مما يفسح المجال أمام المنافسين للازدهار. هناك القليل من القصة التي تتعلق بكل من Apple و Google.

بحلول الوقت الذي أصدروا فيه MPP (حماية خصوصية البريد) في سبتمبر 2021 ، كانت Apple قد تغلبت بالفعل على Google في حصة سوق عميل البريد الإلكتروني. في ذلك الوقت ، كانت حصة Apple تقترب من 59٪ ، وكانت Google عند حوالي 28٪ ، لكن Microsoft Outlook تأخرت كثيرًا عند حوالي 5٪.

الآن ، ما هي الأسباب التي يمكن أن تكون السبب وراء تعرض مايكروسوفت لهزيمة شديدة؟

للعثور على الإجابة ، يجب أن ننظر إلى الماضي قليلاً.

أطلقت Google خدمة Gmail في الأول من أبريل ، قبل عقدين تقريبًا. ولم يستغرق الأمر وقتًا طويلاً حتى أدركت Microsoft أنها ليست مزحة كذبة أبريل. دفع والد Windows بقوة ليظل مهيمناً لمدة عشر سنوات. ولكن بمجرد أن سيطرت Gmail على السوق في عام 2015 ، كان ذلك في الغالب بمثابة دوامة هبوطية لـ Outlook.

لكن لماذا؟

من الآمن المجادلة بأن الأسباب هي توقعات الأداء الفاشلة. في الأساس ، كان Gmail أسرع وأسهل في الاستخدام ، كما أنه يوفر واجهة أكثر انسيابية. إلى جانب المزيد من الميزات وسعة التخزين الأكبر بكثير (1 جيجابايت - 500 مرة أكثر من Outlook في ذلك الوقت) ، فليس من المستغرب أن يفوز Gmail.

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

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

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

اصنع منتجات جيدة

الآن ، يجب أن يكون لديك فهم قوي للتحديات الحاسمة في عملية تطوير المنتج. لتسليط الضوء ، لا يهم حقًا نوع المنتج الذي تقوم بتطويره.

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

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