المحتوى عن 'saas'.



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

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

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

نوع المُحتوى


التصنيفات

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

التصنيفات

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

التصنيفات

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

التصنيفات

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

التصنيفات

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

التصنيفات

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

التصنيفات

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

التصنيفات

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

أسئلة وأجوبة

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

التصنيفات

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

تمّ العثور على 5 نتائج

  1. هذا الجزء الثاني من سلسلة من جزأين تتحدث عن الحوسبة السحابيّة. نرجو أن تكون قرأت موضوع تعلم الحوسبة السحابيّة: المتطلبات الأساسيّة، وكيف تصبح مهندس حوسبة سحابيّة قبل قراءة هذا المقال، إذ يحوي المقال السابق معلومات مهمة، وشرحًا للمصطلحات المستخدمة في هذا الموضوع. ينقسم هذا المقال إلى قسمين، يناقش القسم الأول عيوب الحوسبة السحابيّة والمشكلات التي يمكن أن تواجهها، ويعدّ مقدّمة للقسم الثاني. أما القسم الثاني، فيتحّدث عن الانتقال إلى الحوسبة السحابيّة والمزايا والعيوب وسيساعدك على تجهيز خطّة للانتقال الأمثل، بحيث تستفيد من المزايا وتتجنب المساوئ في الانتقال. مقدمة إذا كنت ترغب في تقديم خدمات رقميّة أيًّا كان نوعها، فعليك تقدير كلّ أنواع الموارد، بما في ذلك المعالج والذاكرة والتخزين والشبكة. إن اختيار أيّ الموارد ستستخدم لتقديم تلك الخدمات - سواء سحابيّة أو محليّة - عائد لك. ولكنّك ستحتاج بكل تأكيد للبحث والتخطيط. ستحتاج إلى فهم مزايا وعيوب الحوسبة السحابيّة وكيف تأخذ نقاط ضعفها في الحسبان. لقد أفادت الخدمات السحابية العديد من المؤسسات، وذلك بتقليل التكاليف، وتمكينها من التركيز على الجانب المتعلّق بالأعمال الخاصّة بها، بدلًا من القضايا المتعلّقة بتقنيّة المعلومات والبنية التحتيّة لها. وعلى الرغم من الكثرة الحديث عن أهميتها في الأوساط التقنيّة، إلّا أنّها قد لا تخلو من العيوب، وخاصّة في الأعمال الصغيرة. لدى معظم الشركات حمل واحد على الأقل يعمل في نظام حوسبة سحابية. رغم هذا، فالانتقال إلى الحوسبة السحابيّة قد لا يكون الخيار الصحيح للجميع. وعلى الرغم من أنّ البيئات السحابيّة عامّة تكون قابلة للتوسعة، ويعتمد عليها، ومتاحة دائمًا، يجب أن لا تدع هذه النواحي وحدها تقود قراراتك. بالنسبة للشركات التي تبحث في الانتقال إلى الحوسبة السحابيّة لأوّل مرّة، فهناك الكثير من النواحي التي يجب أخذها بعين الاعتبار؛ مثل الفوائد والمخاطر التي يتضمّنها كل نوع من أنواع الحوسبة السحابيّة المناسبة لشركتك. سنناقش هنا العناصر الأساسيّة التي عليك أخذها بعين الاعتبار عندما تفكّر بالانتقال إلى الحوسبة السحابيّة. سنتحدث عن بعض العيوب الرئيسيّة، وسنعرض بعض النصائح والطرق السليمة لاستخدامها والتي من الممكن أن تستخدمها الفرق التقنية للتعامل مع تلك العيوب. يمكنك صياغة نمط محدّد لهذه العمليّة، وذلك باستخدام توجُّه مُفصَّل ومجهًَز مُسبقًا لفهم أمن الحوسبة السحابيّة. بالنسبة للشركات التي تبحث في الانتقال إلى الحوسبة السحابيّة لأوّل مرّة، فهناك الكثير من النواحي التي يجب أخذها بعين الاعتبار؛ كالفوائد والمخاطر التي يتضمّنها كل نوع من أنواع الحوسبة السحابيّة المناسبة لشركتك. سنناقش في هذا المقال العناصر الأساسيّة التي عليك أخذها بعين الاعتبار عندما تفكّر بالانتقال إلى الحوسبة السحابيّة. توضيح عيوب الحوسبة السحابيّة 1. انقطاع الخِدمة يُعدّ انقطاع الخدمة (downtime) أحد أهمّ عيوب الحوسبة السحابيّة. بما أن أنظمة الحوسبة السحابيّة تعتمد على الإنترنت، فيحتمل حدوث انقطاع في الخدمة في أيّ وقت، ويمكن أن يحدث لأيّ سبب كان. هل يمكن لشركتك أن تتحمل انقطاع الخدمة أو بطئها؟ لقد كلّف انقطاع خدمة الحوسبة السحابيّة التابعة لأمازون (AWS) عام 2017 شركات مساهمة عامّة أكثر من 150 مليون دولار أمريكيّ. للأسف، لا توجد شركة آمنة من هذا، وخاصّة بالنسبة للأعمال الحسّاسة التي لا تتحمل أن تنقطع. في شهري حزيران وتمّوز (5 و6) من عام 2019، تعرّض عدد كبير من الشركات لانقطاع في الخدمة، بما في ذلك Cloudflare (وهو مزوّد خدمة مهمّ لمواقع الإنترنت)، وGoogle، وAmazon، وShopify، وReddit، وVerizon، وSpectrum. أفضل الممارسات لتقليل انقطاع الخدمة المخطط له في بيئة الحوسبة السحابيّة تصميم خدمات متاحة باستمرار مع أخذ الاسترجاع من الكوارث بعين الاعتبار. استفِد من ميزة تعدّد المناطق (multi-availability zones) التي يتيحها مزودو الخدمة السحابيّة في البنية التحتيّة لديك. إذا كانت خدماتك لا تتحمّل انقطاع الخدمة، فخذ بعين الاعتبار نشر خدمتك في عدّة مناطق، مع تدارك آليّ للانقطاعات لتتجنّب انقطاع الخِدمة قدر الإمكان. حدِّد ونفِّذ خطّة للاسترجاع من الكوارث تتوافق مع أهداف مؤسستك لتقليل وقت الاسترجاع من الكوارث قدر الإمكان (RTO) وأهداف نقطة الاستعادة (RPO). خذ بعين الاعتبار تنفيذ خدمة اتصال مخصّصة مثل AWS Direct Connect أو Azure ExpressRoute أو Dedicated Interconnect أو Partner Interconnect. تقدّم هذه الخدمات اتصال شبكة مخصّص بينك وبين مكان وجود الخدمة السحابيّة. يمكن أن يقلِّل هذا من العرضة إلى خطر انقطاع الخدمة المؤقت الذي قد تسببه الإنترنت. اقرأ تفاصيل اتفاقيّة الخدمة (Service Level Agreement - SLA). هل تضمن لك أن تكون الخدمة متاحة 99.9% من الوقت أو حتى أكثر من ذلك؟ هذا الانقطاع الذي يشكِّل 0.1% يساوي 45 دقيقة شهريًّا أو حوالي ثماني ساعات في العام. 2. الأمن والخصوصيّة على الرغم من إنّ مزودي الخدمة ينفذون أفضل معايير الأمن والإجراءات التي يتطلّبها المجال، إلّا أنّ تخزين البيانات والملفات المهمّة عند مزوّدي خدمة خارجيّين يفتح دائمًا المجال للمخاطرة. يجب أن تغطّي أيّ محادثة تتعلّق بالبياناتِ الأمنَ والخصوصيّةَ، وخاصّة عندما يتعلّق الأمر بإدارة البيانات الحسّاسة. يجب أن لاننسى ما حدث لـCode Space واختراق لوحة تحكّمهم على AWS، والذي أدى إلى حذف بياناتهم مما تسبب في أغلاق الشركة. إن اعتمادهم على بنية تحتيّة بعيدة معتمدة على الخدمات السحابيّة يعني المخاطرة بجعل كلّ ما يتعلّق بهم لدى شركة أخرى. إن كلّ مزود خدمة سحابيّة يتوقّع منه إدارة وتأمين البنية التحتيّة العتاديّة التي تقوم عليها الخدمة. وعلى الرغم من ذلك، تقع على عاتقك مسؤوليّة إدارة وصول المستخدمين، ولهذا عليك أن توازن بحذر كلّ حالات الخطر المحتملة. وعلى الرغم من أن الاختراقات التي كشفت معلومات بطاقات بنكيّة ومعلومات الدخول إلى حسابات على الإنترنت لا تزال جليّة في أذهان العامّة، إلّا أنه قد تم اتخاذ إجراءات لتأمين البيانات؟ ومن الأمثلة على هذه الإجراءات القانون العامّ لتأمين البيانات ( General Data Protection Rule - DGPR )، والذي تم سنّه في الاتحاد الأوروبيّ لإعطاء المستخدمين قدرة اكبر على التحكّم ببياناتهم. وعلى الرغم من ذلك، ما زلت بحاجة إلى معرفة المسؤوليات التي تقع على عاتقك، وأن تتّبع أفضل الممارسات المتعلّقة بهذا الشأن. أفضل الممارسات لتقليل مخاطر الأمن والخصوصيّة هذه النقطة مهمّة: افهم نموذج التشارك في المسؤوليّة لدى مزوّد خدمة الحوسبة السحابية الذي تتعامل معه. ستتحمل أنت مسؤولية ما يحدث في داخل شبكتك ومنتجك. نفّذ الإجراءات الأمنيّة في كلّ مستوى من مستويات خدمتك. اعرف من المفترض أن يكون لديه وصول لكل مورِد وخدمة، وقيّد الوصول قدر الإمكان. إذا خان أحد الموظفين الأمانة (أو أخطأ في أمر ما) وكان لديه وصول إلى الخدمة التي تقدّمها، فسترغب بأن تكون الأضرار في أضيق إطار ممكن. تأكّد من أنّ مهارات فريقك ترقى إلى المستوى المطلوب. إن مقال أهم عشرة أشياء يجب على المختصّين في الأمن الإلكترونيّ معرفتها ممتاز لفهم طريقة تجنب المشكلات المتعلّقة بالأمن والخصوصيّة في الحوسبة السحابيّة. اعتمد توجّها مبنيًّا على تقييم المخاطر من أجل تأمين الموارد التي في النظام السحابيّ واجعل سياسة الأمن تشمل الأجهزة. استخدم نظام استيثاق متعدد الجوانب لكل الحسابات التي تصل إلى البيانات الهامّة في النظام. عليك بالتشفير والتعميّة، ثم عليك بالتشفير والتعمية. فعّل التشفير أينما استطعت. الأهداف السهلة للّصوص هي أماكن تخزين الأشياء، وهذا ينطبق على الحوسبة السحابيّة؛ مكان تخزين البيانات مثل Amazon S3 أو Azure Blob Storage هي أماكن تخزين معلومات الزبائن، وهي هدف مهم للمخترقين. إنّ مجرّد تفعيل التشفير على S3 كان سيكفي لمنع الاختراق الذي حصل في شهر تمّوز عام 2019 - لو أنه استُخدِم - والذي كشف بيانات مئة مليون شخص. 3. التعرّض للهجوم إنّ جميع مكونات الحوسبة السحابيّة متّصلة بالإنترنت، مما يجعلها معرّضة للاختراق في حال وجود ثغرات لم يعرف عنها الفريق المسؤول عن النظام أو لم يغلقها؛ بل إنّ أفضل الفرق تعاني من هجمات واختراقات أمنيّة من وقت لآخر. وبما أنّ الحوسبة السحابيّة مبنيّة كخدمة عامّة، فستجد البعض بدأ الركض قبل أن يتعلّم المشي، إذا صحّ التعبير. فعلى أيّ حال، لا أحد من مزودي الخدمات السحابيّة يختبر مدى براعتك في إدارة النظام قبل أن يعطيك خادمًا لتديره: كل ما يُطلب منك هو أن تدفع لاستخدام الخدمة وحسب. أفضل الممارسات للمساعدة في تقليل الهجمات الإلكترونيّة على الخدمة السحابيّة اجعل الأمن محورًا مهمًا لجميع العمليات التقنيّة. ابقِ جميع الفرق التي تعمل معك على اطّلاع على كلّ ما يتعلّق بأفضل الممارسات لأمن الحوسبة السحابية أولًا بأوّل. تأكّد من تفقُّد ومراجعة السياسات والإجراءات الأمنيّة باستمرار. أمِّن سرّيّة المعلومات وقيّد الوصول إليها لتتجنب المشكلة قبل حدوثها. استخدم الخدمات السحابيّة مثل AWS Inspector، وAWS CloudWatch، وAWS CloudTrail، وAWS Config لجعل التحكّم بالالتزام تلقائيًّا. اكتشف المشاريع والاختبارات الخارجة عن أهداف المؤسسة. امنع الدخول باستخدام كلمة المرور عن الحسابات التي لا تحتاج الولوج إلى النظام. غيِّر مفاتيح الوصول وكلمات المرور باستمرار. تابع المدونات والمواقع المتعلّقة بأمن المعلومات وما تعلن عنه لتكون على دراية بالهجمات المعروفة. طبّق أفضل ممارسات الأمن للبرمجيات مفتوحة المصدر التي تستخدمها. نكرر، استخدم التشفير كلّما أمكن وأينما أمكن. ستساعد هذه الممارساتِ المؤسّسةَ على مراقبة حركة البيانات الهامّة ومدى عرضتها للمشكلات الأمنيّة، وستساعدها كذلك على حماية الأنظمة الهامّة من الهجمات والاختراقات، وعلى استيثاق الوصول إلى البنية التحتيّة والبيانات، وذلك من أجل الحماية من المخاطر الإضافيّة المحتملة. 4. الوصول المحدود والمرونة بما أنّ البنية التحتيّة المعتمدة على الحوسبة السحابيّة بأكملها مملوكة ومدارة ومراقبة من مزوّد خدمة الحوسبة السحابيّة، فهي تبقي القليل فقط من التحكّم في يد الزبون. قد يجد مستخدمو الحوسبة السحابيّة أنّ التحكمَ الذي لديهم في الوظائف والتنفيذ للخدمات في البنية التحتية المستضافة سحابيًّا محدودٌ، وذلك بدرجات متفاوتة، حسب الخدمة التي يقدّمونها. قد تقيّد اتفاقية استخدام الخدمة السحابيّة والسياسات الإداريّة ما يمكن للزبائن فعله بتطبيقاتهم. يحتفظ الزبائن بحقّ التحكّم بتطبيقاتهم وبياناتهم وخدماتهم، ولكن قد لا يكون لديهم نفس القدر من التحكم فيما يتعلّق بالبنية التحتيّة للنظام الخلفيّ وبما يجري خلف الكواليس. أفضل الممارسات لضمان قدرٍ من التحكّم والمرونة خذ بعين الاعتبار الاستفادة من شريك يقدّم خدمة الحوسبة السحابيّة ليساعدك على تنفيذ وتشغيل ودعم خدمات الحوسبة السحابيّة. افهم مسؤوليّاتك ومسؤوليّات مقدّم الخدمة السحابيّة في نموذج المسؤوليّة المشتركة، وذلك من أجل الحدّ من التنصّل من المسؤوليّة وكذلك للحدّ من الأخطاء المحتملة. خذ الوقت الكافي لفهم مستوى الدّعم الأساسيّ الذي يقدّمه مزوّد الخدمات السحابيّة الذي تتعامل معه. هل يفي هذا المستوى من الخدمة بمتطلّباتك؟ يقدّم مزودو خدمة الحوسبة السحابيّة دعمًا إضافيًّا فوق الدعم الأساسيّ مقابل تكلفة إضافيّة. تأكّد من فهمك لاتفاقيّة مستوى الخدمة (Service Level Agreement - SLA) المتعلّقة بالبنية التحتيّة والخدمات التي ستستخدمها وكيف ستؤثّر الاتفاقيّة على زبائنك. 5. البقاء عالقًا عند مزوّد معيّن من العيوب التي تُأخذ بالحُسبان عند التعامل مع الحوسبة السحابيّة هي احتمال أن تبقى عالقًا عند مزوّد خدمة سحابيّة معيّن. إن الانتقال بسهولة بين مزودي الخدمة السحابيّة لم يصل إلى المستوى المطلوب من التطور، وقد تجد المؤسسات صعوبة في نقل خدماتها من مزوّد خدمة إلى آخَر.قد تنشأ صعوبات نتيجة للاختلاف بين مزودي الخدمة مما قد يتسبب بتكاليف إضافيّة وتعقيدات في الإعداد. إنّ الفجوات التي يمكن أن يتسبب بها الانتقال من مزوّد إلى آخر من شأنها أن تؤدي إلى تعريض أمن وخصوصيّة البيانات إلى الخطر. أفضل الممارسات لتقليل الاعتماد على مزوّد الخدمة صمِّم نظامك بما يتوافق مع أفضل ممارسات هندسة الحوسبة السحابيّة. تتيح كلّ خدمات الحوسبة السحابيّة فرصًا لتحسين الإتاحة والأداء، وفصل الطبقات المختلفة، والحدّ من عنق الزجاجة في الأداء. إذا بنيت خدماتك بما يتوافق مع أفضل ممارسات هندسة الحوسبة السحابيّة، فسيقل احتمال أن تواجه مشكلات تتعلق بالانتقال من منصّة حوسبة سحابيّة إلى أخرى. افهم جيدًا ما يسوّقه لك مزودو الخدمة لتتجنّب أن تعلق عندهم. طبّق استراتيجيّة تعدد السحابات لتجنب أن تعلق عند مزود خدمة معيّن. على الرغم من أن هذا قد يتسبب بتعقيدات في كلّ من التطوير والتشغيل، إلّا أنها لن تكون بالضرورة معقدة لدرجة أن تثنيك عن ذلك. يمكن تدريب الفرق لتكون مستعدّة لهندسة واختيار أكثر التقنيات والخدمات اتساقًا مع احتياجاتك. اتبع سياسة المرونة المضمّنة عندما تصمِّم تطبيقات، وذلك من أجل جعلها قابلة للنقل في أيّ وقت. ابن تطبيقاتك مستخدمًا الخدمات التي تقدّم ميزة الاستفادة من مزايا الحوسبة السحابيّة كإحدى أولويّاتها، كأن تتكون من برمجيّات وخدمات مصغّرة ومجزّأة وقابلة للنقل. فكّر باستخدام الحاويات وKubernetes. 6. القلق من ارتفاع الكلفة يمكن أن يُنظَر إلى اعتماد حلول الحوسبة السحابيّة على نطاق ضيّق ولمشاريع قصيرة الأمد على أنّها مكلفة. رغم هذا، تنبع أهمّ فوائد الحوسبة السحابيّة من إمكانيّة خفض التكلفة. يمكن أن تقدِّم خدمات الدفع حسب الاستخدام مرونة أكثر وتكلفة عتاد أقلّ، ولكن قد ينتهي المطاف بفاتورة عليها رقم أكبر من المتوقّع. إلى أن تتأكّد من ما يناسبك، يُنصَح بأن تجرّب عددًا من العروض. يمكنك أيضًا استخدام حاسبة التكلفة التي يقدّمها مزودو الخدمة، مثل AWS و Google Cloud Platform. أفضل الممارسات لخفض التكلفة حاول أن لا تحدّد مدى استخدام خدماتك، بل ابحث عن الخدمات المتغيّرة ذاتيًّا حسب الاستخدام. تأكّد من إمكانيّة تقليل مواصفات الخدمة بقدر إمكانيّة زيادتها. ادفع مسبقًا واستفد من الخدمات المحجوزة إذا كنت تعلم الحدّ الأدنى لاستخدامك. اضبط خدماتك لتبدأ وتتوقّف آليًّا لتوفير المال عندما لا تستخدمها. أنشئ تنبيهات لتتبّع نفقات الحوسبة السحابيّة. الفوائد المحتملة للانتقال إلى الحوسبة السحابيّة العديد من المشاكل يمكن حلّها بالانتقال إلى الحوسبة السحابيّة. فيما يلي بعض الحالات التي يمكن أن تستفيد فيها من الانتقال. يواجه تطبيقك ازديادًا في كميّة البيانات المارّة فيه، مما يصعّب زيادة الموارد لحظيًّا لتناسب الطلب. تحتاج إلى تقليل التكلفة التشغيليّة بينما تزيد كفاءة تقنية المعلومات. يتطلب زبونك تنفيذًا ونشرًا سريعين للتطبيق، ولهذا يريد تطويرًا أكثر وتقليلًا للتأخير الذي قد ينشأ من البنية التحتيّة. يريد زبائنك توسيع أعمالهم جغرافيًّا، ولكنك تعتقد بأن تجهيز بنية تحتيّة متعدّدة الأقاليم سيكون تحدّيًا كبيرًا، وذلك لما فيه من مجهود متعلّق بالإدارة والوقت والكوادر البشريّة والسيطرة على الأخطاء. مواكبة النمو المتزايد للاحتياج إلى تخزين البيانات صارت أكثر صعوبة وتكلفة. تحتاج إلى بناء فريق تطوير موزّع جغافيًّا. تسمح بيئة الحوسبة السحابيّة للموظفين البعيدين الوصول إلى التطبيقات واستخدامها عبر الإنترنت. تحتاج إلى تأسيس نظام استرجاع من الكوارث ولكن تجهيزه لمركز بيانات بأكمله قد يضاعف التكلفة، وسيحتاج أيضًا إلى خطة معقّدة للاسترجاع من الكوارث. يمكن تطبيق أنظمة الاسترجاع من الكوارث المعتمدة على الحوسبة السحابيّة أسرع، وستعطيك تحكّمًا أفضل بكثير بالموارد التي لديك. تتبُّع وتطوير البرمجيات التي يحويها الخادم يأخذ وقتًا، ولكنه مهم، ويحتاج إلى تطوير دوريّ وأحيانًا فوريّ, سيهتم مزود خدمة الحوسبة السحابيّة بهذا الأمر في بعض الأحيان تلقائيًّا. وكذلك، تهتم بعض نماذج الحوسبة السحابية ببعض الأمور الإدارية كالنسخ الاحتياطيّ لقواعد البيانات وتحديث البرمجيّات والصيانة الدوريّة. تكلفة رأس المال والتكاليف التشغيليّة: تحوِّل الحوسبةُ السحابيّةُ تقنيةَ المعلوماتِ إلى نموذج الدفع مقابل الاستخدام، وهي ميزة مغريةٌ وخاصّةً للشركات الناشئة. المخاطر المحتملة نتيجة الانتقال إلى الحوسبة السحابيّة رغم أن المخاطر التي تنطبق على كلّ حالة تعتمد كثيرًا على طبيعة البيئة المراد نقلها، إلّا انّ هناك عيوب عامّة تتعلق بالانتقال إلى الحوسبة السحابيّة التي عليك أخذها بعين الاعتبار. إذا كان تطبيقك يخزّن ويسترجع بيانات حسّاسة جدًّا، فقد لا تتمكن من إبقائها في النظام السحابيّ. وكذلك قد تحُدّ متطلّبات التوافق خياراتك. إذا كان الإعداد الموجود لديك من قبل يفي باحتياجاتك، ولا يحتاج الكثير من الصيانة والتحجيم والإتاحة، وكان جميع زبائنك راضين عنه، فلِمَ تعبث به؟ إذا كانت بعض التقنيات التي تعتمد عليها حاليًّا مملوكة، فقد لا يُسمَح لك قانونًا بنشرها على نظام سحابيّ. قد تعاني بعض العمليات من تأخير إضافيّ عند استخدام تطبيقات سحابيّة عبر الإنترنت. إذا كان العتاد بين يدي شخص آخر أو جهة أخرى، فقد تخسر الشفافية والتحكم اللازمين لتتبع مشاكل الأداء. قد يسبب "الجيران" في بعض الأحيان "إزعاجًا" عبر الموارد المشتركة (الإنترنت). قد لا يتبع تتصميم ومعمارية تطبيقك معمارية الحوسبة السحابيّة الموزّعة، ولهذا قد يتطلّب بعض التعديلات قبل نقلها إلى الحوسبة السحابيّة. البقاء عالقًا عند مزود خدمة سحابيّة معيّن: قد يكون من الصعب المغادرة أو الانتقال إلى منصّة سحابيّة أخرى بمجرد أن تبدأ باستخدام بيئة سحابيّة معيّنة. انقطاع الخدمة: يحدث هذا للجميع، ولكنك قد لا ترغب بأن تكون الأمور بيد شخص آخر. باتّباع هذا الأسلوب في التفكير، إذا كنت تفكّر بنقل أعمالك إلى الحوسبة السحابيّة، فقد تسأل نفسك عن العثرات الشائعة التي يمكن أن تواجهها عند النقل. ما نموذج الحوسبة السحابيّة الذي تحتاجه؟ إذا كنت قررت تجربة الحوسبة السحابيّة، فسيكون عليك اختيار نموذج الحوسبة السحابيّة الذي من الممكن ان تستخدمه. فيما يلي أكثر هذه النماذج شيوعًا: البنية التحتيّة كخدمة: Infrastructure as a Service (مثل AWS، وAzure، وGoogle Cloud، و Alibaba Cloud). المنصّة كخدمة: Platform as a Service (مثل AWS Elastic، وBeanstalk، وHeroku، وGoogle App Engine، وEngine Yard). البرنامج كخدمة: Software as a Service (مثل Google G Suite، وOffice 365، وSalesforce، وNetSuite). وهنا يكمن قرار مهمّ عليك اتّخاذه. النوع الأول هو الأفضل للشركات التي لا مانع لديها من استضافة تطبيقاتها في مراكز بيانات شركة أخرى، وتفضِّل أن يهتم غيرها بالبنية التحتيّة العتاديّة لتركّز بالكامل على تطوير ونشر ومتابعة تطبيقها. رغم هذا، إذا كنت تفضّل أن تكون تطبيقاتك قابلة للنقل، فقد ترغب في أن تضع البرمجية في منصّة PaaS متينة تقدّم بيئة بنية تحتيّة كاملة (وواضحة). إنّ تبّني PaaS سيقلّل أيضًا الوقت الذي تحتاجه لتكون جاهزًا للسوق - وذلك لأنها ستكون مجهّزة مسبقًا بمعظم المتطلّبات اللازمة لتشغيل برمجيّاتك. ستحتاج إلى نشر أعلى طبقة في تطبيقك فقط، وفي بعض الأحيان التطبيق نفسه وحسب. أمّا عن SaaS، فهو نموذج توصيل محتوى تكون البرمجيات الانتاجيّة فيه مستضافة مركزيًّا ومرخّصة حسب الاشتراك. فيما يلي جدول يوضّح ما توفّره كلّ من النماذج الثلاثة المذكورة أعلاه. IaaS PaaS SaaS تخزين البيانات منصّة التطبيق برنامج إدارة الزبائن الأجهزة الظاهريّة قاعدة البيانات إدارة الأعمال نظام توصيل محتوى التطوير الأمن الشبكة التكامل الأدوات الحوسبة table { width: 100%; } thead { vertical-align: middle; text-align: center; } td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } خاصّة أم عامّة أم هجينة؟ لنفترض أنّك اخترت نموذجًا سحابيًّا، وقد حان الوقت لاختيار النوع. لديك ثلاثُ خيارات أساسيّة: عامّ: جميع الموارد التي لديك مستضافة بالكامل لدى واحد أو أكثر من مزودي خدمة الحوسبة السحابيّة، مثل AWS، Azure، GCP، Alibaba، DigitalOcean، …إلخ. خاصّ: تُنشئ نظام الحوسبة السحابيّة الخاصّ بك بنفسك باستخدام منصّة مثل OpenStack أو VMWare vCloud. هجين: مواردك موزّعة على منصات خاصّة وعامّة، مع اتصالات بينها تتابعها أنت. يمكن أن يكون الخيار الهجين جذّابًا بسبب مزجه الجيد لكل من الاستخدام عند الطلب والاستقرار والإتاحة الدائمة والأمن والتكلفة التشغيلية القليلة. باستخدام هذا النوع يمكنك أن تجمع بين مزايا النوعين. سنشرح فيما يلي كيف تعمل الحوسبة السحابيّة الهجينة في شركة معيّنة. لنتخيّل أنّ تطبيقك المبنيّ للإنترنت يزدهر من ناحية الشعبية وعدد المستخدمين. ستحتاج إلى الموارد اللازمة للتوسعة باستمرار، وذلك من أجل أن تواكب الطلب المتزايد عليه. يجب أن تتمكن من زيادة الموارد المستخدمة إلى أقصى حدّ عندما يصل الاستخدام حدّه الأقصى، وأن تقلل تلك الموارد عندما لا تحتاجها وذلك لخفض التكلفة. يمكن فعل ذلك في الحوسبة السحابيّة العامّة. افترض بأن البيانات التي يجعمها تطبيقك سرّيّة جدًّا، ولا يمكن تخزينها خارج نطاق المؤسّسة. وهنا يمكن أن نستفيد من النوع الهجين. يمكنك في هذه الحالة أن تختار الأجزاء التي يمكنها أن تسكن السحابة العامّة، والأجزاء التي ستبقى في مركز البيانات عندك. يقول موقع RightScale في تقرير له أنّ الشركات تتبنى استراتيجيّة تعدد مزودي الخدمة 84%، وأنّ 58% منها تخطط لاستخدام حوسبة سحابيّة هجينة. تقييم التطبيقات للنقل إلى الحوسبة السحابيّة ما إن تختار النموذج والنوع، يبدأ التحدّي الحقيقيّ. لقد حان الوقت لنرى إذا كانت التطبيقات التي لديك جاهزة للنقل إلى الحوسبة السحابيّة. فيما يلي بعض العوامل التي عليك أخذها بعين الاعتبار: تعقيد تصميم التطبيق بعض التطبيقات القديمة معقدة جدًا ومترابطة داخليًّا إلى حد بعيد، مما يجعل مستخدميها غير راغبين في إعادة برمجتها. رغم هذا، فالمتطلب الرئيسيّ لأي انتقال ناجح هو أن تتبع التطبيقات معمارية موزعة، ويجب أن تكون من أساسها قابلة للتحجيم. يمكن لأدوات مثل PaaSLane و Cloudamize أن تساعدك على تقييم إلى أيّ مدى تطبيقاتك جاهزة لنقلها إلى منصّة سحابيّة. إنّ خدمة AWS’s Migration Hub تحوي كلّما تحتاجه من أدوات لاكتشاف وتقييم ذلك. تعقيدات التكامل لكل تطبيق نقاط تكامل، كبوابات الدفع، وخوادم البريد، وخدمات الويب، والتخزين الخارجي، والمزودين الخارجيين. من الضروريّ جدًّا تحليل أثر الانتقال إلى الحوسبة السحابية على هذه الاعتماديات. ستواجه في بعض الأحيان تحديات غير متوقعة تتعلق بالاتصال والاستيثاق، وعليك تحديدها وحلّها قبل حدوثها. أكثر المهام أهميّة (ومللًا) تحديد كلّ نقاط التكامل هذه. وبما أن التطبيقات القديمة قد يكون توثيقها ضعيفًا، وقد يكون المطورون الملمّون بتفاصيلها غير متاحين، فقد تحتاج إلى تفقّد أجزائها كلّها يدويًّا. تزداد المهمّة تعقيدًا إذا كنت تفكّر بترحيل مئات التطبيقات التي تعمل حاليًّا في مركز البيانات لديك. يمكن مواجهة العديد من هذه التحديات بالاعتماد على معرفة فريقك للتطبيقات، وعلى أداة اكتشاف الموارد (سواء مفتوحة المصدر أو تجارية). يمكن لأداة اكتشاف الموارد مساعدتك على تحديد كلّ إعدادات الخوادم في شبكتك، بما في ذلك تفاصيل الاتصال. على سبيل المثال، لنقل أن لديك مركز بيانات فيه شبكة تستضيف مئة تطبيق. يمكن لأداة الاكتشاف تلك أن تقدم لك نظرة عامّة للنظام بأكمله. ويمكنها أيضًا أن تعطيك تفاصيل متفرقة يمكنها مساعدتك في تقييم إدارة السعة العامّة (general capacity management، مصطلح إداريّ). من أدوات اكتشاف الموارد المعروفة BMC Atrium و HP DDMA. تقدّم Cloudamize أداة يمكنها اكتشاف التطبيقات والأجهزة آليًّا، ويمكنها أيضًا عمل خرائط باعتماديات التطبيقات آليًّا، وذلك من أجل اكتشاف الاعتماديات بين التطبيقات. نظام التشغيل المضيف ما إن تقرّر الانتقال إلى الحوسبة السحابيّة، من الضروريّ أن تعلم إذا كان باستطاعتك نشر تطبيقك على نفس نظام التشغيل. يمكن أن يعمل تطبيقك على نظام تشغيل محدّد (أو إصدار محدّد من نظام التشغيل). إذا لم يكن هذا النظام متوافقًا مع مزود الخدمات السحابيّة، فسيكون عليك أن تجد نظام تشغيل بديل يمكن استخدامه، أو مزود خدمات سحابيّة آخر، أو أن تلغي مشروع النقل من أساسه. على سبيل المثال، لا يتيح معظم مزودي الخدمات السحابيّة خيارات لأنظمة تشغيل 32بت، وقد يكون لدى البقيّة متطلّبات اشتراك غير متوقّعة. من الضروريّ أن تجري بحثًا في هذا الأمر قبل التخطيط للنقل. قاعدة بيانات التطبيق من المعروف أن قاعدة البيانات جزء هامّ من أيّ تطبيق. يستثمر الزبائن كثيرًا في خوادم قواعد البيانات، وغالبًا في تراخيصها أيضًا. إضافة إلى ذلك، قد لا ترغب في نقل قواعد البيانات الآن، وذلك بسبب تعقيدها وحساسيّة البيانات التي فيها، كما أن نقل كميات ضخمة من البيانات ليست بالأمر السهل. في جميع الأحول، عليك أن تتأكد من أن طرق النقل التي ستستخدمها يمكن الاعتماد عليها إلى حدّ بعيد، ويمكن كذلك عكسها في حال حصول مشكلة كبيرة غير متوقّعة. يوفّر معظم مزودي الخدمات السحابيّة أدوات نقل خاصّة بهم. ولهذا من الضروريّ أن تقيّم هذه الخدمات قبل أن تضغط زرّ البدء. فمثلًا، تقدم AWS خدمة Migration Hub، والتي - على حد تعبيرهم - "تسهّل وتسرّع الاكتشاف والنقل من مراكز بياناتك إلى AWS Cloud". وهناك العديد من من مزودي خدمة نقل البيانات كطرف ثالث، مثل Attunity CloudBeam، وATADATA ATAmotion، وCloudEndure Live Migration، وRacemi DynaCenter. الشبكة لا تدعم معظم بيئات الحوسبة السحابيّة ميزة multicasting، ولهذا إذا كان تطبيقك يعتمد على هذه الميزة، فعليك أن تفكّر جيدًا قبل أن تخطو أيّ خطوة. موازنة الأسعار لدى العديد من مزودي الخدمات السحابيّة حاسبات تكلفة من شأنها أن تساعدك على تقدير التكاليف الحقيقيّة التي ستواجهها عند الانتقال إلى الحوسبة السحابية، ومقارنتها بالتكلفة الحاليّة، ومنها AWS TCO (Total Cost of Ownership) calculator و Azure Pricing Calculator. يسمح لك موقع Cloudamize بمقارنة التكاليف لدى كلّ من AWS وAzure و Google Cloud Platform (GCP)، بحيث يمكنك من الاختيار بينها بما يتوافق مع مدى الحمل الذي يقوم به تطبيقك. إثبات المفاهيم (Proof of Concept) من الأفكار الرائعة دائمًا بناء "إثبات للمفاهيم" (أي تجربة الأمر عمليًّا على نظام بديل ومنفصل عن النظام الحقيقيّ الذي تستخدمه، وذلك للتأكد من أن كل شيء يعمل كما يجب) على نطاق صغير قبل نقل التطبيق الحقيقيّ إلى الحوسبة السحابيّة. لن تتوقع هذه النماذج كل المشاكل التي يمكن أن تحصل، ولكنها ستوضّح التحديات التي يمكن أن تواجهها بوضوح أكثر، وستساعدك على فهمها. من الأمور التي عليك البحث فيها أثناء تنفيذ هذه الخطوة: مقارنة الأداء مع التطبيق الموجود فعليًّا. مستويات التعقيد أثناء ترحيل التطبيق. التحديات المتعلقة بالشبكة والتي يجب العمل على حلّها. إمكانيّة الاعتماد عليها. تقييم دعم مزود الخدمة. خُلاصة القول تستفيد العديد من المؤسسات من المرونة التي تقدّمها خدمات الحوسبة السحابيّة، فيما يتعلّق بإمكانية تشغيلها وإيقافها وتغيير حجمها ومزاياها والدفع حسب الاستخدام. رغم هذا، وكما في أيّ خدمة بنية تحتيّة، يجب عليك تقييم مدى ملاءمة الحوسبة السحابيّة لحالة الاستخدام لديك تحديدًا، وذلك لعمل تقييم مبني على المخاطر المحتملة (risk-based evaluation). خصِّص وقتًا للبحث والتخطيط لتفهم كيف ستؤثِّر الحوسبة السحابيّة في أعمالك. لا يمكن حصر كلّ التحديات التي يمكن أن تواجهها عند النقل في مقال واحد، ولكننا حاولنا هنا الوقوف على بعض المشاكل الشائعة التي يجب أن تأخذها بعين الاعتبار قبل بدء هذا العمل. شاركنا تجربتك في نقل عملك إلى الحوسبة السحابية في التعليقات. ترجمة -وبتصرف- للمقالين: Disadvantages of Cloud Computing لصاحبه Andrew Larkin. Cloud Migration Risks & Benefits لصاحبه Jeremy Cook.
  2. يتشابه إطلاق الشركات مع البقاء على قيد الحياة في جوانب عدّة، فإما أن تجد عملاء يدفعون لك، أو تفشل شركتك وتموت فكرتك. يضعك النظر إلى عملك بهذه الطريقة (الحادة) ضمن الحالة الذهنية الصحيحة، من الممتع أن تحلم بما ستفعله حين تمتلك إيراداتٍ وأرباحًا بالملايين، ولكن إن عجزت عن جذب عملائك القلائل ليدفعوا لك، فلن تُتاح لك فرصة بيع العميل رقم 1000 أو 10000. إذن، كيف يمكنك بناء الطلب؟ وكيف تجد عملاء؟ لا توجد إجابة بسيطة، ولكن مفتاح النجاح يكمن في إيجاد آلية لتوليد الطلب يمكن تكرارها. ما هو توليد الطلب؟ لا شكّ أنك سمعت بمصطلح «توليد الطلب» (Demand generation) الذي طُرح كعبارة رنانة مرتبطة بالشركات الناشئة، لكن نحتاج لتعريف واضح للمصطلح قبل أن نبدأ. توليد الطلب هو خلق أنظمة تعمل على زيادة وعي عملائك المستهدفين بمنتجك وخلق سوق. يُمكننا تفصيل التعريف ضمن عدة عناصر لجعله أكثر وضوحًا: المنتجات: الأشياء الملموسة التي تبيعها. العملاء: الأشخاص الذين يشترون منتجك. الأنظمة: مزيج من الأشخاص والعمليات والتكنولوجيا التي يمكن استخدامها مرارًا وتكرارًا. الوعي: إدراك كيانك وما تفعله شركتك. الطلب: الاهتمام بما تفعله شركتك، والقيمة التي تقدمها. يتباين نظام توليد الطلب الذي تُنشئه بحسب نوع المنتج الذي تبيعه والعملاء المستهدفين. ومع ذلك، هناك قوالب مشتركة بين الأنظمة، ولا بدّ من تذكرها دومًا. 1. انطلق من وجهة نظر مُحددة شركتك موجودة لحل مشكلة. ربما ظهرت كبيان مشكلة مثل "البريد الإلكتروني مكلف للغاية" أو "بات إيجاد سيارة أجرة أمرًا صعبًا للغاية". أو مع انطلاقة صيحة جديدة مثل "الذكاء الصنعي" أو "البلوك تشين". بغض النظر عن السبب، لا بدّ من امتلاك شركتك غاية من وجودها إلى جانب رغبتك في جني الكثير من المال. 2. حدد موقعك اسأل نفسك عن المستفيد من منتجك، وهي طريقة أخرى للسؤال عن صفات عميلك الحقيقية. ما إن تمتلك الإجابات، سيصبح بمقدورك تحديد القيمة الفعلية التي تقدمها شركتك للعميل، وما يميزك عن منافسيك. فيما يلي مثال عن شركة خيالية: بالاعتماد على الاسئلة أعلاه، سنفصّل العبارة السابقة لنحصل على ما يلي: ما هو المنتج؟ مجرفة ذكية. من هو العميل؟ مزارعو البصل. ما القيمة المُضافة بالنسبة لهم؟ توفير الوقت من خلال تسريع زراعة أسرع. ما الذي يجعل المنتج أفضل من الطريقة القديمة؟ تقليل آلام أسفل الظهر قياسًا بالمجارف التقليدية. 3. افهم عميلك لا قيمة لأفضل استراتيجيات التسويق في العالم إن لم يرَ أحد رسالتك. والطريقة الوحيدة للتأكد من رؤية عملائك لها هي بفهم سلوكياتهم وطريقة تفكيرهم. يمكن لبحث السوق أن يكون سريعًا ومجانيًا تقريبًا، لذا فقيامك بواجبك في البداية سيوفرعليك الكثير من العمل الإضافي لاحقًا. كلما كنت أكثر تحديدًا بشأن عميلك المستهدف، أصبح فهم كيفية الوصول إليه والرسالة التي يجب استخدامها أسهل. بالعودة لمثالنا التخيلي، فمزارعي البصل هم شريحة أصغر وبسلوكيات مختلفة موازنةً بأصحاب المنازل الذين يفضلون أداء المهام بأنفسهم. مما يعني أن احتياجاتهم وعاداتهم مُحددة أكثر، وهذا ما يمنحك ميزة كبيرة (عبر تضييق نطاق الإجابات عن الأسئلة التالية التي تحتاج إلى طرحها): كيف يشتري عملائي المستهدفين منتجات مُشابهة؟ أين يجتمع عملائي المستهدفون مع أشخاص يُشبهونهم؟ من أين يحصل عملائي المستهدفون على المعلومات على الصعيد الشخصي؟ من أين يحصلون على معلوماتهم على الصعيد المهني؟ عمّن يبحثون؟ بمن يثقون؟ أي أوقات السنة هو الأكثر أهمية بالنسبة لهم؟ كلما كنت أكثر تحديدًا، كان ذلك أفضل. إن زار كل مزارع بصل في العالم مؤتمر البصل السنوية (OnionCon)، فعليك إذن تدّوين ذلك مع ذكر أسماء المحاضرين خلال السنوات الماضية. وإذا كانوا جميعًا يستمعون إلى برنامج OnionPod، فيتوجب عليك تدوين ذلك أيضًا والاستماع للأرشيف لاكتشاف الموضوعات التي يناقشونها. 4. انشئ طرائقًا للوصول إلى جمهورك هذا بسيط: تخيّل كل الطرق التي يمكنك من خلالها الوصول إلى جمهورك ثم اكتب كل فكرة ضمن قائمة طويلة. في هذه المرحلة، لا ضير من تسجيل كل فكرة تخطر في بالك -كبيرة كانت أم صغيرة- حيث سنُقيّم جدواها لاحقًا. دونك بعض الطرق للوصول إلى مزارعي البصل: شراء مساحات إعلانية في مؤتمر OnionCon أو برنامج OnionPod الإعلان عبر الفيسبوك على أساس الاهتمام: البصل. الاستعانة بإعلانات غوغل أدوردز مستهدفين كلمة "مجرفة". إرسال عينات لجميع المتحدثين في مؤتمر OnionCon. بعد الانتهاء من ذلك، سنصل إلى الحقيقة المرّة: الأرقام. 5. اربح (على الورق) على غرار ابتكار الأفكار، يتميز إنشاء نماذج بسيطة من المنتج -لمساعدتك على تحديد الأولويات والنقاط التي تتطلب التركيز- بانخفاض التكلفة والسرعة والسهولة. ويتضمن القيام بذلك دراسة المسارات والخطوات المختلفة التي قد يتخذها العملاء لشراء منتجك، متبوعةً ببعض الحسابات الأساسية. إليك مثالًا على فكرتنا لرعاية حلقة من برنامج OnionPod، والذي يتقاضى 1000$ لقاء الإعلان: عدد مستمعي البرنامج: 25000. بفضل الإعلان، يزور 2% من المستمعين (500 شخص) موقعك الإلكتروني. يشتري 2% من هؤلاء الزوار (10 أشخاص) مجرفة. ومع 100$ لكل مجرفة، ستبلغ مبيعاتك 1000$. والآن، بعد خصم جميع تكاليف صناعة هذا المجرفة (أجور التصنيع، مصاريف التخزين، وغيرها) ستتكون لديك فكرة تقريبية عما إذا كانت رعاية البرنامج فكرة مربحة تستحق المتابعة. كما أن ذلك سيُشكل فرصة رائعة للتفكير في طرق التحسين. للقيام بذلك، عليك صياغة نظرية من النتائج، بحيث يمكن للأخيرة أن تتغير إذا حسّنت عنصرًا معين من استراتيجيتك. ربما بإنشاء إعلان أفضل ورفع نسبة زائري موقعك من مستمعي OnionPod لـ 5 ٪، أو بزيادة سعر المجرفة لرفع ربحية كل عملية بيع. أثناء تنسيقك لهذه العوامل في نموذجك، ستتعلم بسرعة ما إذا كانت حساباتك دقيقة أم لا. صُغ افتراضاتك المتحفظة وطبّقها بكل صرامة على كل تكتيك تفكر فيه. ومع ذلك لا تنسق خلف الأرقام، فهذا عمل وليس دينًا. عندما يكون مسار التسويق صحيحًا، فيتوجب عليك تصنيف كل فكرة من خلال عاملين: الصعوبة (التكلفة، وقت التنفيذ، الجدوى) والتأثير (الإيرادات، الربح، العملاء الذين حصلت عليهم). في المراحل المختلفة لنمو شركتك، ستتحسن أشياء عدة: ربما تكون الآن عملية جذب العملاء، ولكن لاحقًا ستكون الربحية. تحتاج نظامًا واحدًا فقط لتعمل تحتاج الشركات الكبرى للعديد من أنظمة توليد الطلب ذات الخصائص المختلفة للربحية والاستحواذ التي تعمل معًا لتحقيق النمو. لكنك لا تحتاج إلى مثل هذا النظام المعقد (حتى الآن)، لذلك ركز على إيجاد نظام يعمل فحسب. عندما تجد استراتيجية فعّالة، طبّقها بقدر استطاعتك. وفي كل مرة تضعها قيد التنفيذ، ستزيل المعوقات وتزيد من تأثيرها. ستساعدك قناة توليد الطلب الأولى هذه -عندما تعمل بشكل صحيح- على البقاء في السوق لفترة كافية للتفكير في الفكرة الكبيرة التالية. ويمكنك الرجوع إلى قائمة الأفكار الطويلة (وإضافة اختبار جديد إلى هذا المزيج) كلما احتجت لزيادة نمو شركتك. ترجمة -وبتصرف- للمقال SaaS marketing 101: marketing for growth and survival لصاحبه BRIAN KOTLYAR
  3. لعلك قرأت من قبل مقال بول غراهام الشهير "الشركات الناشئة=النمو" والذي يشرح فيه الفرق بين الشركات التقليدية والشركات الناشئة، ويصف بول الشركة الناشئة "بأنها شركة مصممة للنمو السريع". بشكل عام، يعتبر النمو إشكالية جيدة لأنه يعني أنك وجدت وسيلة ملائمة نوعًا ما لقياس سوق المنتج، كما يعني أن لديك إيرادات فعلية من عملاء نشطين. برغم ذلك، عندما أجرى باحثون في جامعة كاليفورنيا في بيركلي وستانفورد دراسات لقياس معدل النمو في أكثر من 3000 شركة ناشئة، كانت النتيجة الجوهرية التي توصلوا إليها هي أن التوسع السابق لأوانه كان السبب الأكثر شيوعًا للفشل. يجلب النمو السريع سواءً كان ذلك على مستوى العائدات أو الموظفين مجموعة من العقبات، والتي قد تؤدي إلى غرق شركتك بشكل غير متوقع، إذا لم يكن لديك استراتيجية قوية للتعامل معها. وباعتبار أن المقياس الأساسي الذي نقيس به النمو هو الإيرادات، يترتب على ذلك أن فريق المبيعات ينمو أسرع من أي وظيفة أخرى تقريبًا. وبخبرة تزيد على 25 عامًا كصانعة أرباح، تعتبر Tara Bryant مخضرمة في مساعدة الشركات في التغلب على العقبات التي تواجهها في خطط الإيرادات المعقدة، بدءًا من الشركات الناشئة وحتى أفضل 500 شركة في قائمة مجلة Fortune . وبصفتها النائب الأول لرئيس قسم المبيعات في Pipedrive، فهي المسؤولة حاليًا عن بناء فرق المبيعات الفعالة التي تحقق إيرادات دائمة. وخلال حياتها العملية، تمكنت من زيادة المبيعات السنوية بنسبة 100% أو أكثر في مؤسسات كبيرة وسريعة النمو، لقد شهدت كل من (إيجابيات وسلبيات) انتصارات وإخفاقات النمو الجنوني، وانضمت إلينا على البث الصوتي لتشاركنا رؤيتها حول كيفية تحقيق النمو الدائم. لمعرفة كيف تتجنب مخاطر النمو الهائل، إليك النصائح الجوهرية لتارا فيما يلي. تأكد من المعايير الثقافية أثناء النمو يمكن أن تكون ثقافة الشركة معقدة وخصوصًا عندما تعاني الشركات الناشئة من النمو السريع؛ الموظفين الجدد يتأهلون بسرعة مدهشة، والقيادة تعمل على تطوير سياسات حديثة للتعامل مع المشكلات الجديدة بمجرد ظهورها ومناقشة كل شيء بدايةً من تقارير النفقات وحتى حوافز الموظفين. ويعد التوظيف أحد أكبر مجالات الاستثمار في شركتك، لهذا من الضروري بذل جهود كبيرة في التجنيد والحفاظ على الموظفين سعداء. شركة Zappos تتفهم ذلك جيدًا وتقدم لموظفيها الجدد 2000 دولار في حال قرروا مغادرة الشركة لأنهم وجدوا أنها غير مناسبة لهم. كما يقضي المدراء الجدد أيضًا خمسة أسابيع في التدريب على ثقافة الشركة حيث يجيبون على مكالمات العملاء ويعملون في مستودعات Zappos، كل هذا قبل أن يبدأوا العمل في الوظيفة التي اختيروا لها. إن حماية وتعزيز الثقافة الإيجابية يشبه إلى حدٍ كبير تدعيم الصداقات الصحية مثل الإجراءات التي قد تبدو صغيرة كالتحدث عن القيم باستمرار أو الاعتراف بجهود الموظفين الإبداعية أو التخطيط للوقت الترفيهي الذي يعزز التواصل بين أعضاء الفريق، كلها تلعب بالفعل دورًا كبيرًا في جعل شركتك مكانًا جذابًا للعمل. وترى تارا أن أساليب التوظيف الصحيحة التي تدعم ثقافة الشركة هي التي تميّز Piperdrive عن غيرها من الشركات: افعل الكثير بأقل عدد قد يخدعك النمو السريع ويقودك إلى التفكير في أن الوقت قد حان للتوسع وتعيين موظفين جدد، لكن قبل أن تُقدِم على هذه الخطوة عليك التحقق من أن فريق العمل الأساسي يعمل بأقصى طاقته. يقول بيتر دراكر عالم الإدارة الشهير "ما لا يمكن قياسه، لا يمكن تطويره". لإنشاء آلية عمل بسيطة ومعتدلة، من المهم وضع مقاييس صحية من أجل مواصلة النجاح مثل قضاء الوقت في أنشطة عالية القيمة. قد يعني هذا من وجهة نظر المبيعات، اتباع طريقة طلب اقتراحات العملاء بدلًا من المكالمات الجافّة أو التركيز على الاحتفاظ بالعملاء الحاليين بدلًا الحصول على عملاء جدد. إذا لم تُسوّى هذه الأمور، فيجب عليك الضغط على فرامل التوظيف، كما فعلت تارا بشجاعة عندما أدركت أن الشركة بحاجة للعمل على ما لديها قبل التسرع لملء المقاعد. تعرف ما إذا كان ممثلوك صيادين أو مزارعين تُظهر الأبحاث أن ما تنفقه من أجل الحصول على عميل جديد، يكلف خمسة أضعاف الوقت الذي يمكن أن تحصل فيه على عائد من عميل حالي، ومع ذلك، 18% فقط من الشركات تعطي الأولوية للاحتفاظ بالعملاء. بالطبع يُعد كلًا من الإحتفاظ بالعملاء، وكسب عملاء جدد أمرًا بالغ الأهمية لشركتك، ولكن بدلًا من تكليف فريق مبيعات واحد بالمهمتين، يُفضّل تقسيم المهمة وتعيين أشخاص مناسبين لهذا المنصب. وكل نهج يلعب على جزئية مختلفة، فالاحتفاظ بالعميل يتطلب مهارات شخصية مثل إدارة العلاقات، في حين أن اكتساب عميل جديد يدور حول ترغيب العملاء المحتملين وشرح كيف أن منتجك سيحل مشكلاتهم القائمة. لهذا توصي تارا بتعيين فريقين متميزين للقيام بكل مهمة. احذر من التحول قبل أوانه بينما تتمتع شركة SaaS بنجاح سريع، فمن الطبيعي أن تستكشف طرقًا جديدة وتفكر فيما إذا كان الوقت قد حان للانتقال إلى مستوى أعلى، لكن التحول من تقديم خدمات صغيرة أو متوسطة إلى التنافس في ساحة المؤسسات والشركات الكبرى يعد تحولًا كبيرًا ويمثل مخاطرة كبيرة. يوصي توماس تونجوز، الرأسمالي المغامر بتقييم دقيق لما إذا كان الوقت قد حان لتحقيق هذه القفزة، لأن فرق المبيعات في الشركات الكبرى تكون عادةً أكبر من الشركات الصغيرة حيث تسند إليها أدوار جديدة مثل هندسة المبيعات والتسويق الميداني، فهل أنت مستعد بالفعل للاستثمار؟ سؤال جوهري آخر، هل سينجح المنتج لديك في كلا السوقين، إذا كان البيع للشركات الصغيرة والمتوسطة يتطلب خطة تنفيذية واحدة والشركات الكبرى تتطلب أكثر، فقد يؤدي ذلك إلى انخفاض مواردك. الأمر له علاقة أيضًا بالتسويق، قد يكون جهد وتكلفة تطوير إعلانات مختلفة تمامًا، أكبر من استعداد الشركة للتعامل معها في هذه المرحلة. بالنسبة لتارا فالسؤال الأهم: هل حقًا سيخدم المنتج احتياجات العميل؟ ترجمة وبتصرف للمقال The ugly side of growth – how to scale your sales team sustainably لصاحبه GEOFFREY KEATING
  4. هذا المقال يوضّح بالرسوم البيانيّة كيف يمكن لمعدّل خسارة الزّبائن شهريًّا (أو ما يسمّى انحسار عدد المستخدمين Churn) أن يؤثّر سلبًا على مشاريع البرمجيّات الخدميّة SaaS عند توسّعها. كما ينظر المقال أيضًا إلى عامل غريب بإمكانه أن يسرّع نموّ شركة البرمجيّات الخدميّة SaaS بشكل كبير، ألا وهو عامل الانحسار العكسيّ Negative churn. ملاحظة: يمكن تطبيق هذا المقال على أيّ نشاط تجاريّ ذي عائد متكرّر Recurring revenue وليس محصورًا بالبرمجيّات الخدميّة SaaS وحدها. مقدمة عندما يزداد حجم شركة البرمجيّات الخدميّة، يزداد معها حجم قاعدة المشتركين subscriptions لدرجة يصبح فيها معدّل الزّبائن الذين يلغون اشتراكاتهم كبيرًا جدًّا. هذه الخسارة في العائدات تتطلّب الكثير من المشتركين الجدد لكي يعوّضوا هذا الانحسار الضائع، ممّا يجعل النّمو الإجماليّ للشّركة بطيئًا. لتوضيح هذه النّقطة قمت ببناء نموذج بسيط ورسمت مخرجاته في المخطّط أدناه. يبدأ المخطّط عندما يكون العائد المتكرّر الشّهريّ MRR عند الصّفر، وقيمة الاشتراكات من الزّبائن الجدد بحدود 10 آلاف دولار في الشّهر الأوّل، وتزداد بمقدار ألفين كلّ شهر (موضّح بالخط الأزرق المنقّط في المخطّط أدناه). الخطّان الأحمر والأصفر يظهران الخسارة في العائدات بسبب انحسار عدد المستخدمين. وهما يوضّحان أثر الانحسار عندما يكون بمعدّل 2.5% للأصفر، و5% للأحمر. بالنّظر إلى المخطّط أعلاه يمكننا ملاحظة أنّ الانحسار في الأشهر الأولى من حياة الشّركة النّاشئة ليس رقمًا كبيرًا. لكن عندما تقترب الشّركة من عامها الخامس، فحتّى مع معدّلٍ ضّئيل نسبيًّا من الانحسار (2.5% فقط) فإنّك تخسر 64 ألفًا كلّ شهر، وهذا بحدّ ذاته رقمٌ كبيرٌ يصعب تعويضه من خلال المشتركين الجدد. وبمعدّل 5% يصبح هذا الرقم 90 ألفًا. المخطّط أدناه يظهر تأثير الانحسار على العائدات الشّهريّة المتكرّرة في كلا الحالتين، وهو كبير إلى حدّ ما. تأثير الانحسار العكسي من الممكن أن ننشئ برمجيّة خدميّة SaaS أو أيّ نوع آخر من الأعمال القائمة على فكرة العائدات المتكرّرة، بطريقة تمكّنّنا من الحصول على ما أسمّيه بالانحسار العكسيّ negative churn. هذا يحصل عندما تتمكّن من تحقيق عائدات جديدة تعوّض الخسارة النّاتجة عن الانحسار، هذه العائدات الجديدة ليست عبر المشتركين الجدد وإنّما عبر التّوسّع expansions أو زيادة مبيعات الزّبون up sales أو المبيعات المتقاطعة cross sales لقاعدة الزّبائن الحاليّين. المخطّط أدناه يظهر ما يحصل للاشتراكات في خدمتك إذا كنت تحصل، إضافةً إلى الزبائن الجدد، على توسّع في العائدات من قاعدة زبائنك الحاليّين بنسبة 2.5% كلّ شهر (الخطّ الأخضر). إنّ النّتيجة مذهلة، التّوسّع في العائدات من الزّبائن الحاليّين شيئًا فشيئًا أصبح رقمًا كبيرًا، ومع نهاية العام الخامس أصبح يساهم بما يقارب 180 ألف دولار شهريًّا. لنلقٍ نظرة على العائدات المتكرّرة الشّهريّة الإجماليّة لنرى تأثير الانحسار العكسيّ هنا (الخط الأخضر في المخطّط أدناه): إنّها نتيجة رائعة. فالنّشاط التّجاريّ قد أصبح أكبر من ثلاثة أضعاف انحسارٍ معدّله 2.5%. إذا من الواضح أنّ الوصول إلى انحسارٍ عكسيّ أصبح أحد أهمّ مسرّعات النّموّ. وبما أنّه من الصّعب تحقيقه فهذا يطرح أمامنا سؤالًا آخر: ما الذي يحصل إذا لم نتمكّن من تحصيل انحسار عكسيّ، لكنّنا تمكّنّا من تخفيض الانحسار إلى 0%؟ انظر الخطّ المنقّط أدناه: إنّ انحسارًا بمعدّل 0% هو أكثر بحوالي ستّين في المئة من الخطّ الأصفر (انحسار بمعدّل 2.5%). كيف يمكنك تحقيق انحسار عكسي؟ حتّى تصل إلى الانحسار العكسيّ عليك أن تحقّق واحدًا أو أكثر من المتطلّبات التّالية: وسّع أرباحك من المنتج الحاليّ. والطّريقة الأفضل لتحقيق ذلك هي بوضع سياسة أسعار تقوم على زيادة السّعر بناء على زيادة الاستخدام، بالاعتماد على بعض المتغيّرات التي يتوقّع زيادتها مع الوقت. فعلى سبيل المثال عليك أن تدفع أكثر حتّى تحصل على مساحة تخزينيّة أكبر في Dropbox، وكذلك تدفع أكثر كلّما ازداد عدد المشتركين في القائمة البريديّة الخاصّة بك عندما تتعامل مع شركات التّسويق بالبريد الإلكتروني، وهكذا. زد مبيعاتك للزّبائن. عبر عرض نسخة للمنتج الحاليّ تتضمّن مزايا أكثر. شجّع زبائنك على شراء منتجات أو خدمات إضافيّة تتقاطع مع المنتج الحاليّ. هل أستخدم نفس موظفي المبيعات لكل من التوسع / زيادة المبيعات / المبيعات المتقاطعة؟ عادة ما أفضّل فصل هيكليّة المبيعات sales organization في شركتي إلى صيّادين hunters يعقدون الصّفقات مع زبائن جدد، ومزارعين farmers يعملون على زيادة الأرباح من الزّبائن الحاليّين. وهناك سببان وراء ذلك: التّركيز: إذا كنتُ أنا موظّفًا لديّ الخيار بين التّواصل مع زبون حاليّ لزيادة الرّبح منه، وبين أن أصل إلى زبون جديد، فبالتّأكيد سأختار الزّبون الحالي لأنّه الأسهل. وبالتّالي سيقلّ التّركيز على الزّبائن الجدد. مهارات مختلفة: إنّ المهارات المطلوبة للمبيعات عن طريق التّوسّع expansion sales عادة ما تتعلّق بكيف يمكن تحقيق نجاح كبير لتجربة الزّبون مع المنتج. فالمهارات المطلوبة هنا تشمل الاستشارات، وخدمة الزّبائن، والخبرة في استخدام المنتج نفسه، أكثر من أن تكون مجرّد مهارات في المبيعات. كيف يمكن تتبع العوامل المختلفة التي تجلب الاشتراكات بفرض أنّ شركتك لديها طريقة للحصول على المبيعات التوسّعيّة expansion sales، فإنّ عدد الاشتراكات لديك سيعتمد على المكوّنات التّالية: لذا فمن المنطقيّ أن نتتبّع كلّ من العوامل الثّلاثة على حدة في مخطّط بياني يشبه هذا: متى يجب التركيز على الانحسار العكسي؟ كثير من قرّاء هذا المقال هم – على الأرجح – في بدايات شركاتهم النّاشئة، ولا أريد أن أعطيهم التّصوّر بأنّ عليهم منذ الآن التّركيز على استراتيجيّات التّسعير المعقّدة، والمنتجات المتنوّعة التي تتيح عمليّات زيادة البيع up sell و البيع بالتّقاطع cross-sell، فهذا مازال مبكّرًا على شركتك طالما أنّها ما زالت في السنتين الأولى والثّانية. إنّما الأهمّ في هذه المرحلة أن تحصل على قاعدة واسعة من الزّبائن، وهذا يعني عادة أن تكون طريقة التّسعير بسيطة حتى ولو لم تحصل على كاملة القيمة المُمكنة التي يُمكن استخراجها من العميل الواحد. أساليب تساعدك على تقليص انحسار المشتركين churn 1. اتصل بزبائنك إذا كنت في المراحل الأولى من حياة شركتك النّاشئة، ومعدّل الانحسار لديك كبير، فإنّ أهمّ ما يجب البدء به هو أن تتصّل بزبائنك الذين يلغون اشتراكهم لتعرف السّبب. أنصح بأن يقوم بذلك المدراء أو أصحاب الشّركة أنفسهم، فهم الوحيدون القادرون على تغيير رؤية المنتج ككلّ، أو المحدّدات الأخرى المتعلّقة بالخدمة بناء على التّغذية الرّاجعة feedback من هؤلاء الزّبائن. عادة ما ستخبرك هذه المكالمات بأنّ المنتج لا يحلّ مشكلة الزّبون، أو أنّ لديه مشكلة في استخدامه. وحلّ هذه المشاكل يكون إمّا بتغير المنتج، أو بتغيير الطّريقة التي تقدّم فيها الدّعم حول طريقة استخدامه. 2. قس تفاعل الزبائن مع المنتج أو بكلمات أخرى: قِس مدى سعادة الزّبون، لكن بالطّبع هذا أمر من الصّعب قياسه. عوضًا عن ذلك أنا أنصح بأن تقوم بقياس تفاعل الزّبائن مع المنتج، ويمكنك القيام بذلك بإضافة بعض الأدوات للمزايا المختلفة في المشروع، والتي تصدر تقريرًا لتفاعل المستخدم ترسله إلى قاعدة البيانات الخاصّة بك. وبوضع وزنًا محدّدًا لكلّ حدث من هذه الأحداث المختلفة يمكنك أن تصل إلى تقييمٍ عامّ لمدى تفاعل الزّبون مع المنتج أو الخدمة. وهذا التّقييم الإجماليّ هو علامة هامّة تدلّك على الزّبائن الذين يستثمرون المنتج بشكل جيّد ويحصلون على نتائج جيّدة، وبالتّالي لا يرجح أن ينسحبوا قريبًا، كما تدلّك على أولئك الذين هم في خطر. والآن يمكنك أن تستخدم موظّفي الدّعم لديك وتدفعهم إلى التّواصل مع هؤلاء الأشخاص الذين يبدو أنّهم يحتاجون المساعدة، ليقدّموا لهم العون والنّصائح حول كيفيّة استثمار المنتج بشكل أمثل. 3. اعرف ما هي المزايا التي تدفع الزبون إلى التمسك بالمنتج عانت شركة HotSpot في مراحلها الأولى من انحسارٍ شديد في المستخدمين، وذلك بسبب أنّ المنتج الأوّليّ كان يركّز على تهيئة المواقع لمحرّكات البحث SEO، وفي اللّحظة التي يصل فيها الزّبون إلى تهيئة موقعه بشكل كامل فإنّه يشعر أنّه ليس بحاجة لأن يدفع المزيد. لذلك قاموا بالبحث عن المزايا التي يمكن إضافتها لجعل الخدمة تجذب الزّبون على المدى الطّويل. إحدى الطّرق لذلك هي أن تجعل جزءًا أساسيًّا من خدمتك مرتبط إلى درجة كبيرة بأعمال يوميّة يقوم بها الزّبون، والطّريقة الأخرى هي أن تكون الخدمة نفسها مخزنًا لبيانات هامّة يحتاجها الزّبون. ففي اللّحظة التي تصبح أنت فيها من يقوم بتسجيل هذه البيانات، فسيكون من الصّعب على الزّبون أن يتحوّل عنك إلى أيّ مكان آخر. اسأل نفسك إذا كنت تعرف المزايا التي تجعل المنتج "يعلق" stick بالزّبون، ومن خلال قياسك لتفاعل الزّبائن استكشف إذا ما كانوا يصلون فعلًا إلى هذه المزايا ويستخدمونها. وإلّا فهؤلاء الزّبائن معرّضين للاختفاء في أيّة لحظة. 4. خصص أفضل موظفيك ليتولوا مهمة الحفاظ على الزبائن الذين يتصلون لإلغاء اشتراكهم فهناك إمكانيّة أن تنقذ زبونك الذي يوشك على الرحيل، لكنّك بحاجة إلى مهارات عالية في المبيعات حتّى تتمكّن من تحقيق ذلك. 5. حاول أن تعقد مع الزبون صفقة لمدة أطول كل النّقاش السّابق كان يفترض أنّ الزّبائن لديك يقومون بتجديد الخدمة كلّ شهر. فإحدى الطّرق لتخفيض الانحسار هو بأن تطلب من المستخدمين أن يدفعوا مقدّمًا أجر الخدمة لعدّة أشهر تالية (ستّة أشهر أو سنة.) وهكذا ستقلّص الانحسار بأن جعلت الزّبون يلتزم مع خدمتك لفترة أطول، وبالتّالي يحصل على تجربة أطول من التّفاعل مع المنتج وتجريب جميع إمكانيّاته. لكنّ سلبيّة هذه الطّريقة أنّها ستخفّف من حجم مبيعاتك dampen sales، لذلك أفضل طريقة لمعالجة الأمر هي أن تجرّب عدّة مرّات حتّى تصل إلى الصّيغة الأمثل. كما يمكنك أن تجعل الصّفقات طويلة المدى متاحة دون أن تجعلها إجباريّة. 6. ابحث عن العوامل الأخرى التي قد ترتبط بانحسار المستخدمين فربّما أنت تبيع الزّبائن الصّغار والكبار معًا على سبيل المثال. فعلى الأرجح ستخسر الزّبائن الصغّار أكثر من الكبار. وهذا قد يدفعك إلى أن تركّز في جهود المبيعات والتّسويق على فئة محدّدة هي التي تجلب لك الرّبح الأكبر ( مع الأخذ بعين الاعتبار CAC و LTV). لكنّك قد تجد أيضًا أنّ الزّبائن الذين يأتون من قناة معيّنة هم الأكثر عرضة لأن يلغوا اشتراكهم بعد مدّة، وفي حال حصل هذا فإمّا أنّ هؤلاء ليسوا مناسبين للمنتج، أو أنّك بحاجة لأن تُجري بعض التّعديلات على المنتج نفسه لجعله أكثر ملاءمة لاحتيجاتهم. إدارة الانحسار أصعب عندما توجه منتجك إلى الشركات الصغيرة السّبب في ذلك يعود إلى الشّركات الصّغيرة هي أكثر عرضة للتّوقّف، بالإضافة إلى أنّ لديها القدرة على تخفيض النّفقات بسرعة في حال لم تجري أمور العمل على ما يرام. أضف إلى ذلك أنّه من الصّعب في هذه الحالة أيضًا أن تحصل على ما سمّيناه انحسارًا عكسيًّا، وذلك لكون الكثير من الشّركات الصغيرة لديها حدودًا واضحة لما يمكنها دفعه مقابل خدمات معيّنة. كيف يؤثر الانحسار على قيمة الشركة Valuation إذا كنت تعرض شركتك النّاشئة على مموّلين فلابدّ أن تتوقّع منهم أن يبدوا اهتمامًا خاصًّا لمعدّل الانحسار لدى شركتك، حتى ولو كنتَ في مراحلك الأولى، فهذا يعطيهم انطباعًا لمدى جودة المنتج وملاءمته للسّوق. وهناك تقارير صدرت عن بنوك استثمار كبيرة تتحدّث عن العوامل التي تؤثر في قيمة شركات الخدمات البرمجية. فرغم أنّ معدّل النّمو هو العامل الأهم، فإنّهم يؤكّدون أيضًا على أنّ كلًّا من الاحتفاظ بالزّبائن retention وزيادة المبيعات upsell هما عاملان قويًّا يحتلّان المرتبة الثّانية. فالدّراسة تظهر أنّ زيادة تدريجيّة بمعدّل 2% في الاحتفاظ بالزّبائن تؤدّي إلى زيادة أرباح higher multiple بمعدّل 20% وأنّ زيادة تدريجيّة بمعدّل 2% في زيادة المبيعات upsell تؤدّي إلى زيادة أرباح بمعدّل 28%. ترجمة -وبتصرّف- للمقال: Unlocking the Path to Negative Churn لكاتبه David Skok.
  5. إنّ إتقان تخطيط صفحات الويب بدون إتقان لغة CSS سيكون كمن يحاول السباحة على أرضٍ جافة، ولكن على عكس السباحة التي عندما تتقنها تبقى معك طول الحياة فإنّه لا يوجد مرحلة يمكنك عندها التوقف عن التعلم وتقول أنّك أتقنت CSS فهذه اللغة تتطور بسرعة يومًا بعد يوم. كما أنّ تعلم وإتقان هذه اللغة سيكون أكثر تحديًا بسبب وجود إختلافات في كيفية تطبيق ودعم هذه اللغة من قبل المتصفحات (حتى بين الإصدارات المختلفة للمتصفح نفسه). ولمدة تناهز العشر سنوات كان مطوّرو الويب يتصارعون ويعانون من الدعم المتشتت وغير المتناسق لخصائص CSS3 في كل إصدار جديد للمتصفحات. ولكن لنتفق على شيء ما وهو أنّ إتقان CSS شيء لا بد منه لأي مطور ويب جيد. وفي هذا المقال سوف نأخذكم في جولة لنتعرف على مبادئ CSS في تخطيط الصفحات وسوف نبدأ من التقنيات التي ظهرت في CSS2 وانتهاءً بآخر ما ظهر في CSS3. ملاحظة: سوف نستخدم HTML5 وSass في هذا المقال. ويمكنك الحصول على الشيفرات البرمجية كاملة من هنا. إحدى حالات الاستخدامإنّ من أفضل الطرق لتعلم أي تقنية هو أن يكون هناك حالة استخدام محددة تحاول دعمها أو أنّك تبحث عن حل لمشكلة ما. وحتى نهاية هذا المقال سنركز على حالة استخدام بمجموعة من المتطلبات. ستكون حالة الاستخدام التي سنعمل عليها عبارة عن تخطيط لتطبيق ويب (Web App) مع بعض السلوكيات المتغيرة/الديناميكية (dynamic)، بحيث سيكون هناك عناصر ثابتة في الصفحة مثل الترويسة (header) والتذييل (footer) وقائمة رئيسية (navigation) وقائمة فرعية (sub-navigation) وقسم محتوى قابل للتمرير(scrollable content). ستكون المتطلبات الخاصة بتخطيط الصفحة كما يلي: التخطيط الأساسي:الترويسة، التذييل، قائمة رئيسية وقائمة فرعية وهذه العناصر ستبقى ثابتة عند التمرير (scroll).سوف تشغل القائمة الرئيسية والقائمة الفرعية أي مساحة عمودية فارغة.سوف يشغل قسم المحتوى المساحة المتبقية في الصفحة وسوف يحتوي على منطقة قابلة للتمرير.السلوكيات المتغيرة/الديناميكية:سوف تحتوي القائمة الرئيسية على أيقونات فقط بشكل افتراضي، ولكن يمكن لها أن تتمدد لتحتوي على بعض النصوص (وأيضًا تتقلص/تنطوي لتظهر الأيقونات فقط مرة أخرى). اختلافات في تخطيط الصفحة:ستحتوي بعض الصفحات على قائمة فرعية بجانب القائمة الرئيسية والبعض الآخر لا. استخدام تقنيات CSS2 هذا هو تخطيط HTML5 الذي سوف نستخدمه: <body class="layout-classic"> <header id="header"></header> <nav id="nav"></nav> <aside id="subnav"></aside> <main id="main"></main> <footer id="footer"></footer> </body> 1. الموضعة الثابتة (position: fixed)في CSS2 يمكنك الحصول على عناصر ثابتة في الصفحة (مثل الترويسة، التذييل...الخ) عن طريق توظيف نموذج تخطيط يَستخدم الموضعة الثابتة (يستخدم position: fixed). سوف نستخدم أيضًا الخاصية z-index لنتأكد بأنّ العناصر الثابتة سوف تظهر فوق جميع العناصر الأخرى في الصفحة، بحيث تقوم هذه الخاصية بتحديد مكان العنصر إمّا أعلى أو أسفل عنصر آخر، فالعناصر التي تحتوي على قيمة z-index كبيرة سوف تظهر فوق العناصر التي تحتوي على قيمة z-index أقل. هناك شيء مهم يجب عليك تذكره وهو أنّ خاصية z-index لن تعمل إلا بوجود خاصية position، أي أنّك إذا استخدمت خاصية z-index على أحد العناصر ولكنك لم تستخدم خاصية position على نفس العنصر فإنّ خاصية z-index لن تعمل. وبالنسبة لنا، فسوف نستخدم القيمة 20 (وهي أعلى من القيمة الافتراضية) حتى نُبقي العناصر الثابتة فوق العناصر الأخرى في الصفحة. وسوف نستخدم خاصية width ونعطيها القيمة 100% وهذا سيسمح للعناصر بالتمدد أفقيًا بالقدر الذي تستطيعه. #header, #footer { position: fixed; width: 100%; z-index: 20; } #header { top: 0; height: 5em; } #footer { bottom: 0; height: 3em; }هذا بالنسبة للترويسة والتذييل، ولكن ماذا بالنسبة للقائمة الرئيسية (nav#) والفرعية (subnav#)؟ 2. تقنية التوسع/التمدد في CSSبالنسبة للقائمة الرئيسية (nav#) والفرعية (subnav#)، سوف نستخدم تقنية تسمى بتقنية التمدد (CSS Expantion) بحيث تُستخدم هذه التقنية على العناصر التي تحتوي على الخاصية position: fixed (بحيث يبقى العنصر ثابت في الصفحة) أو الخاصية position: absolute (بحيث يتم موضعة العنصر بناءً على أقرب عنصر حاوي يحتوي على الخاصية position بقيمة غير القيمة static). يمكن الحصول على تمدد رأسي/عمودي (vertical) باستخدام الخاصيتين top و bottom وإعطائها قيم محددة بحيث يتمدد العنصر عموديًا ليستخدم المساحة العمودية المتبقية وفقًا لتلك القيم، أي أنّ ما نقوم به هو ربط الجزء العلوي للعنصر بمسافة محددة من الجزء العلوي للصفحة وكذلك ربط الجزء السفلي للعنصر بمسافة محددة من الجزء السفلي للصفحة مما سيؤدي إلى تمدد العنصر ليشغل المساحة العمودية بين هاتين النقطتين (العلوية والسفلية). ونفس الأمر ينطبق على التمدد الأفقي بحيث نستخدم الخاصيتين left و right ونعطيها قيم محددة بحيث يتمدد العنصر أفقيًا ليشغل المساحة الأفقية المتبقية وفقًا لتلك القيم. وبالنسبة لنا في هذه الحالة فإننا نريد أن نستخدم التمدد العمودي: #nav, #subnav { position: fixed; top: 6em; /* ترك مسافة فوق الترويسة */ bottom: 4em; /* ترك مسافة تحت التذييلة */ z-index: 20; } #nav { left: 0; width: 5em; } #subnav { left: 6em; /* leave 1em margin to right of nav */ width: 13em; }3. الموضعة الإفتراضية/الساكنة (static)سوف نستخدم الموضعة الساكنة لموضعة منطقة المحتوى القابلة للتمرير، بحيث تظهر العناصر وتتموضع بالترتيب كما تظهر بالتدفق الطبيعي للمستند (كما تظهر في ملف HTML)، وبما أنّ جميع العناصر الأخرى في الصفحة متموضعة بشكل ثابت فإنّ هذا العنصر سيكون هو العنصر الوحيد الذي يظهر وفقًا للتدفق الطبيعي للمستند. ونتيجة لذلك فكل ما نحتاجه لموضعة العنصر بشكل مناسب هو استخدام الخاصية margin حتى لا يحصل تداخل بينه وبين العناصر الأخرى الثابتة (الترويسة، التذييل والقائمتين الرئيسية والفرعية): #main { margin: 6em 0 4em 20em; }وبهذا نكون قد أتممنا متطلبات التخطيط الأساسي باستخدام CSS2 وبقي علينا أن نهتم بأمر المتطلبات الإضافية الخاصة بالسلوكيات المتغيرة/الديناميكية. 4. السلوكيات المتغيرة/الديناميكية باستخدام تقنيات CSS2ذكرنا سابقًا بأنّ القائمة الرئيسية سوف تحتوي على أيقونات فقط بشكل افتراضي، ولكن يمكن لها أن تتمدد لتحتوي على بعض النصوص (وأيضًا تتقلص/تنطوي لتظهر الأيقوانات فقط مرة أخرى). لنبدأ أولًا بإعطاء القائمة الرئيسية عندما تكون متمددة عرضًا (width) بقيمة 5em زيادة على عرضها الرئيسي (أي يصبح عرضها عندما تتمدد 10em)، وسوف نقوم بذلك عن طريق إنشاء class باسم "expanded" بحيث يمكننا ديناميكيًا (باستخدام الجافاسكربت) إضافته أو إزالته من القائمة الرئيسية: #nan { left: 0; width: 5em; &.expanded { /* Sass notation */ width: 10em; } } يمكنك بالأسفل رؤية كود الجافاسكربت (jQuery في حالتنا هذه) الذي سوف نستخدمه لإضافة أو إزالة الـclass الذي يحمل الاسم "expanded" عندما يقوم المستخدم بالنقر على أيقونة القائمة: $('.layout-classic #nav').on('click', 'li.nav-toggle', function() { $('#nav').toggleClass('expanded'); });يمكن الآن للقائمة الرئيسية أن تتمدد أو تتقلص بكل سهولة. ولكن هناك مشكلة صغيرة وهو أنه عندما تتمدد القائمة الرئيسية فإنها سوف تتداخل مع القائمة الفرعية وهو ما لا نريده بكل تأكيد، ولذلك سوف نحتاج إلى تعديل الأمور قليلًا. يمكنك الآن رؤية واحدة من المشاكل/القيود في CSS2، فسوف نحتاج الآن إلى كتابة العديد من الأكواد الخاصة بقيم العناصر المتموضعة بشكل ثابت، ونتيجة لذلك فسوف نحتاج إلى تعريف classes باسم "expanded" إضافية حتى نسمح للعناصر الأخرى بأن تتموضع لاستيعاب القائمة الرئيسية عندما تتمدد، وبذلك سوف نحتاج إلى كتابة المزيد والمزيد من الأكواد الإضافية. #subnav { left: 6em; width: 13em; &.expanded { left: 11em; /* تحريكها لليمين */ } } #main { margin: 6em 0 4em 20; z-index: 10; &.expanded { margin-left: 25em; /* تحريكها لليمين */ } }سوف نحتاج أيضًا إلى إضافة أكواد جافاسكربت إضافية لإضافة أو إزالة الـclass "expanded" لتلك العناصر عندما يقوم المستخدم بالنقر على القائمة الرئيسية. $('.layout-classic #nav').on('click', 'li.nav-toggle', function() { $('#nav, #subnav, #main').toggleClass('expanded'); });سيكون كل شيء أفضل الآن. 5. اختلافات تخطيط الصفحة باستخدام تقنيات CSS2كنا قد ذكرنا مسبقًا بأنّ بعض الصفحات لن تحتوي على قائمة فرعية. ولنكون أكثر دقة فإننا نريد للقائمة الفرعية أن تختفي عندما يضغط المستخدم على أيقونة "المستخدمين" (users) الموجودة في القائمة الرئيسية. سوف نبدأ أولًا بإنشاء class بالاسم "hidden" وفيه الخاصية display: none: hidden { display: none; }كما أننا سنستخدم الجافاسكربت لإخفاء القائمة الفرعية وذلك عن طريق تطبيق الفئة "hidden" على هذه القائمة عندما يقوم المستخدم بالنقر على أيقونة "المستخدمين" (users): $('#nav.fa-user').on('click', function() { $('#subnav').toggleClass('hidden'); });وبهذا يمكن للعناصر أن تختفي عند النقر على أيقونة "المستخدمين" ولكن المساحة التي كانت تحتلها سوف تبقى غير مستخدمة بدلًا من أن تقوم العناصر الأخرى باستخدام تلك المساحة. وحتى نحصل على السلوك المطلوب عندما نقوم بإخفاء القائمة الفرعية فإننا سوف نستخدم المحدد المجاور(adjacent sibling selector) وهو يأتي على شكل إشارة الجمع +. 6. المحدد المجاوريُستخدم المحدد المجاور لتحديد عنصرين واختيار العنصر الثاني الذي يأتي مباشرة بعد العنصر الأول. فعلى سبيل المثال، سيقوم الكود التالي باختيار العنصر الذي يحمل ID بقيمة main والذي يأتي مباشرة بعد العنصر الذي يحمل ID بقيمة subnav: #subnav + #main { margin-left: 20em; }استخدمنا الكود في الأعلى لإعطاء العنصر main# الخاصية margin-left: 20em فقط إذا كان هذا العنصر يأتي مباشرة بعد العنصر subnav#. ولكن عندما يتمدد العنصر nav# (بحيث يتم إضافة الفئة expanded إلى العنصر main# بناءً على الكود الذي كتبناه سابقًا) فإننا نريد للخاصية margin-left أن تحتوي على القيمة 25em. #subnav + #main.expanded { margin-left: 25em; }وأمّا إذا كانت القائمة الفرعية subnav# مخفية فإننا نريد للخاصية margin-left الخاصة بالعنصر main# أن تحتوي على القيمة 6em: #subnav.hidden + #main { margin-left: 6em; }ملاحظة: واحدة من مساوئ استخدام المحدد المجاور هو أن الـDOM سوف يحتوي دائمًا على العنصر subnav# حتى لو كان غير ظاهر في الصفحة. وأخيرًا، إذا كان العنصر subnav# مخفيًا وnav# متمددًا فإننا نريد الخاصية margin-left للعنصر main# بأن تكون بالقيمة 11em: #subnav.hidden + #main.expanded { margin-left: 11em; }خاتمةكل شيء إلى الآن يظهر في مكانه الصحيح من دون الحاجة إلى استخدام أكواد جافاسكربت كثيرة، ولكن يمكنك ملاحظة أن الكود يمكن أن يكون كبيرًا ومعقدًا إذا ما أردنا إضافة المزيد من العناصر إلى الصفحة. لاحظ أيضًا أنّه باستخدام CSS2 سيكون هناك الكثير من الأكواد لموضعة كل شيء في مكانه المناسب. لذلك سوف نقوم في الدرس القادم باستخدام بعض تقنيات CSS3 الجديدة وإعادة تخطيط الصفحة باستخدام تلك التقنيات. ترجمة -وبتصرّف- للمقال CSS Layout Tutorial: From Class+ic Approaches to the Latest Techniques لصاحبه Laureano Martin Arcanio.