البحث في الموقع

يصبح البحث عن برنامج جديد عمليةً شاقةً وتستهلك وقتًا إذا تمت بالطريقة الخطأ، ويمكن تقليل الوقت الذي تستهلكه إلى النصف بتجنب هذه الأخطاء الشائعة، وهذه الأخطاء مأخوذة من أصحاب الخبرة في تجديد البرامج التي تستعملها الشركات وكيفية تصحيح الأخطاء في تلك البرامج، وقد شاركوها بعد العمل عشرات السنين مع الكثير من الشركات عرفوا خلالها الأخطاء التي تؤدي الشركات إلى اختيار البرامج الخطأ. ستة مزالق تؤدي إلى اختيار منصة دعم العملاء الخطأ توجد نتائج ملموسة أكثر لاكتشاف نقاط الخطأ من اكتشاف النقاط الإيجابية، وبما أن هناك الكثير من المحتوى على الإنترنت يدافع عن كل منصة مدعيًا ملاءمتها لكل شركة مهما كان عملها، فقد وجب تصحيح تلك المفاهيم المغلوطة، ومن شأن هذه القائمة المساعدة في اتخاذ قرار مدروس وسريع ومبني على المعلومات عند البحث عن أفضل منصة دعم عملاء للشركة. 1. شراء البرنامج دون تفكير لمجرد أنه أشهر برنامج وذلك بسبب نجاح ذلك البرنامج تسويقيًا، مثل مفهوم السباحة مع التيار أسهل من السباحة عكسه، ونظن وجود الاسم اللامع للشركة دليل على أفضليتها، وذلك هو أكبر خطأ يقع فيه أصحاب الشركات الصغيرة عند شراء برنامج دعم عملاء، فهو يقود إلى الإحباط وخيبة الأمل. يُعدّ استخدام فريق دعم مكون من 300 عضو لمنصة ما ليس مبرِّرًا، لأنه يستعمل نفس المنصة فريقًا آخر مكونًا من 3 أعضاء، فلا يمكن إسقاط ما ينطبق على الفريق الأول على الفريق الثاني، وما يزيد الطين بلةً هو أن تلك المنصات الشهيرة تكون في أغلب الأحوال هي الأغلى سعرًا. قد تستطيع الشركات الضخمة تحمل تكلفة أدوات الخدمة التي تكلف آلاف الدولارات، لكن الشركات الصغيرة تحتاج إلى بدائل عمليةً أكثر، حيث يجب عليها التمهل في تحليل هذه المنتجات الرائجة. صحيح أنها قد تناسب الشركة، لكن الخطأ هو افتراض مناسبتها دون البحث بما يكفي. 2. التركيز بتزمت على عدد الخصائص الموجودة في المنتج تُعَد العلاقة بين الحجم والجودة علاقةً طرديةً في عقول الكثيرين، وهي المقولة المسيطرة على قراراتهم عند شراء المنتجات، حيث يظنون أن المنتج المحتوي على "مميزات" أكثر هو الأفضل والأنسب، وبالحقيقة لا توجد فائدة من إنفاق الأموال على الكثير من الأشياء، بل الفائدة الحقيقية تكون بالاعتناء بما يستحق الاعتناء، فقد تكون كومة كبيرة من الخصائص في البرنامج غير مجدية لشركة ما ولا تحسن من سير عملها وبالتالي لا قيمة لها، وكثير من الشركات لا تستخدم كل الخصائص الموجودة في برنامج خدمة العملاء الذي تشتريه، وبالتالي فإن معظم المنصات مناسبة لأن معظم الخصائص تبقى بلا استخدام. يروي أحد الخبراء قصةً حصلت معه فيقول أن صاحب الشركة استدعاه لينفذ مهمةً كان يمكن للبرنامج إنجازها بأحد تلك الخصائص الكثيرة، لكن لم يفعّلوها لسبب أو لآخر، فعُثر على البريد الوارد للشركة في حالة فوضى عارمة استغرق ترميمها شهورًا قبل تفعيل الخاصية، لذلك فإذا لم تُشغل منصة دعم العملاء الشركة من بداية الطريق، فلا يهم عدد الخصائص التي تحتويها، وهذه المنصة لا تناسب الشركة. 3. استبعاد المستقبل من الحسابات يسيطر ضيق الأفق على كثير من قرارات الشركات والأعمال خاصةَ بالنسبة للشركات الصغيرة، حيث يجب على المنتج التمتع بالقابلية ليصاحبها في نموها، لكن لا يمكن التنبؤ بالمستقبل، يُعدّ حصر الهدف من شراء برنامج الدعم في حل المشكلات الحالية له آثاره على المدى البعيد، ولهذا ينبغي إذًا التركيز على المرونة والتكيّف: هل يسهل ضبط الخصائص إذا لزم تعديلها في المستقبل؟ هل يُمْكن الإضافة إلى المنصة دون إحداث تغييرات جذرية في سير العمل؟ هل يجب دفع المال لإضافة المزيد من الخصائص إلى المنصة؟ تُعدّ المشكلة الحالية بالنسبة لمعظم فرق دعم العملاء الصغيرة هي الاستجابة لكل العملاء، فيبدؤون بالردود الآلية والجاهزة لتسريع الرد على العملاء دون الحاجة لتوظيف المزيد موظفي الخدمات، في المستقبل قد ترغب الشركة في إضافة المجلدات والقواعد التي تنظم أنواع الاستفسارات لتسريع الردود، وستقرر في نهاية المطاف إنشاء قاعدة معرفة ليخدم العملاء أنفسهم تلقائيًا، ثم ستحتاج إلى التقارير التي تعتمد على مدخلات من بيانات العملاء للمساعدة في ضبط الأمور. وينبغي الحرص على توفر هذه الخصائص الأساسية في المنصة، وأن تكون مزودةً بخريطة تطوير للمنتج مليئة بالأدوات والتطويرات التي يمكن استخدامها في المستقبل. وعلى مركز الخدمات جعل هذه العناصر واضحةً بحيث يمكن حل المشاكل فورًا بمعرفة مسبقة للخطوات، كما يجب الحرص على الإحاطة بأي مبالغ إضافيةً أو تعديلات قد تلزم مستقبلًا حتى لا تأخذ الشركة على حين غرة وتحبطها حين يحين ذلك الوقت. 4. أخذ الاستخدامات المستقبلية للمنصة في الحسبان فقط نادرًا ما يقع مسؤولو الدعم في هذا الفخ، لكن يميل مؤسسو الشركات إلى تركيز أنظارهم على المستقبل كثيرًا، فينظرون إلى ما بعد عشر سنوات، أي عندما يكون فريق المبيعات قد حقق كل أهدافه فيما يتعلق بالأرباح، ويتضاعف نمو الشركة، وتشتري المنتجات التي تلائمها خصيصًا. صحيح أنه يُفترض بقاء أحلام مؤسسي الشركات حقيقةً، لكن ذلك لا ينفي وجوب أخذ ظروف الحاضر في الحسبان. لعل ذلك يذكرنا بالقصة التي ذكرت سابقًا في مقال عن ذلك المدير اشترى برنامجًا لمجرد أنه يمكنه تنفيذ مهمة ما؟ ذلك مثال نموذجي للتفكير الغارق في المستقبل الذي يؤدي إلى إهمال الحاضر، الأولوية في البداية للعملاء المتوفرين حاليًا، ويعبّر عن ذلك هرم مُقترح لتطبيقه في مجال دعم العملاء، شبيه بهرم ماسلو Maslow: يتحمس أصحاب الشركات كثيرًا لـ"مستقبل" تجربة المستخدم ولإضافة ميزات جديدة مثل المحادثات المباشرة واستخدام مواقع التواصل الاجتماعي والحجز الآلي، لكنهم يغفلون عن إرضاء عملائهم الآن بتحسين أشياء بسيطةً مثل سرعة الاستجابة والاستجابة الذكية لكل استفسار، ولهذا ينبغي تحقيق رضا العملاء الحاليين أولًا، ثم يأتي الإبداع. 5. تجاهل الإشعارات التحذيرية والإشارات الحمراء عندما تكون الشركة غارقةً في طلبات الدعم، فسيسهل استخدام أيسر الحلول دون تفكير فيه، فالغريق يتعلق بقشة كما يقال، لكن هذه العجلة قد تعمي الشركة عن رؤية مشاكل فادحة: التعقيد في صفقات التسعير. المبالغة في طول قائمة الخصائص. إرشادات الاستخدام المعقدة. عدم الاستجابة لدى فريق خدمة العملاء. هناك مؤسسو شركات يرون قائمة المشكلات هذه بأكملها ويتغاضون عنها، ظانين أن المنتج سيصبح مفهومًا للعملاء حين يستخدمونه، أو أن عضوًا آخر في الفريق سيجد ضالتنا، إلا أن هذه الأعراض المذكورة تشير إلى غياب الوضوح والفاعلية من طرف المنتج نفسه وليس الشركة ويجب التعامل معها بجدية، قد لا يستخدم مؤسسو الشركات منصة خدمة العملاء يوميًا، لكن القادة المثاليين هم من يفهمون أساسيات أدوات فريقهم ما يجعلهم قادرين على التحدث بناءً على معرفة عن سير عمل فريق الدعم ويقدموا حلولًا عمليةً لمشاكلهم. 6. عدم الاستفادة من الفترات التجريبية المجانية لا عجب في أن كل شركة خدمات برمجية تقدم تجربةً مجانيةً لبرامجها، فالناس نادرًا ما يستخدمونها، أو لا يعطون تلك التجربة المجانية حقها، فيشغّلون البرنامج وينقرون بضعة نقرات هنا وهناك، ثم يقررون أن البرنامج جيد بناءً على نظرة عابرة. بالإضافة إلى ذلك، عندما يبدأ المرء تجربة مجانية واحدة، يشعر بأنه ملزم بتجربة برنامج آخر للموازنة بين أكثر من برنامج وذلك صحيح، فينبغي عليك الموازنة، لكن هذه العملية ستأخذ وقتًا أكثر الآن، لذا ينصح بضبطها وتجنب موازنة أكثر من ثلاثة برامج في نفس الوقت، وتحديد أسبوع لعملية الموازنة والبحث وجعل البت في هذه المسألة هي الأولوية القصوى خلال هذا الأسبوع. تبدأ العملية بجمع المعلومات من موقع الشركة، واستعراض صفقاتها التسعيرية، وقائمة خصائص برنامجها وإرشادات استخدامه، والتفاعل مع فريقها، وإذا وُجدت هذه الأمور جيدةً، فسيأتي دور التجربة المجانية، وينبغي الثقة بأن الجودة في كل تلك الجوانب لا يمكن اجتماعها في كل المنتجات، وعدد المنتجات التي ينطبق عليها ذلك ستكون ثلاثةً على الأكثر، الخطوة التالية هي بدء تنفيذ العمل اليومي باستخدام البرنامج ذي التجربة المجانية، وتسمح معظم منصات دعم العملاء بإرسال رسائل البريد الإلكتروني واستقبالها في البريد الوارد خلال التجربة المجانية، فينبغي استغلال تلك الميزة، وحث أعضاء الفريق على التعاون في العمل على المنصة والتفاعل مع عملاء حقيقيين عليها ورصد أي مشاكل في الاستخدام، كما يجب وضع تقديرات وأطر زمنيةً واقعيةً، وسوف تستطيع الشركة اتخاذ قرار مدروس والانتقال من مرحلة التجربة إلى استخدام البرنامج بطريقة دائمة. 7. مشكلة اللغة بما أننا نتحدث عن خدمة العملاء في العالم العربي فإن منتجات خدمة العملاء المختلفة حول العالم لا تدعم اللغة العربية بالكامل، أو قد تدعم اللغة العربية بصورة سيئة وتعيسة، لذلك سيضطر المعنيون بإدارة هذه الفرق إلى البحث عن موظفي خدمة عملاء يجيدون اللغة الإنجليزية ليتمكنوا من العمل على هذه المنصات والتعامل معها ومع رسائلها ومشاكلها، والتواصل مع مطوري هذه المنصات سيكون باللغة الأجنبية حصرًا. لاحظت شركة حسوب هذه المشكلة وأعلن مؤسسها عبدالمهيمن الآغا أنه يعمل مع فريقه على تطوير منصة دعم فني تدعى زيتون وأشار إلى أنها منصة عربية بالكامل ستوفر تجربة استخدام مثالية ومحسنة باللغة العربية. دليل شراء منصة دعم عملاء يُستحسن التعلم من الأخطاء المذكورة، والبدء بالبرنامج الصحيح لتجنب الوقوع فيها، ومن شأن هذه النصائح قيادة الشركة إلى منصة دعم العملاء الأمثل لها. يمكن أن تشكل عملية إجراء البحوث ضغطًا، لكن تنفيذها بواقعية ومسؤولية يجعل اتخاذ القرار الذكي يتم في وقت أقصر، بتحديد العملية بوقت وترتيب الأولويات، وتجنب المزالق الشائعة، يمكن اختيار أفضل برنامج للفريق. ترجمة وبتصرف للمقال Buying a Customer Support Platform? Here are 6 Mistakes to Avoid لصاحبته Melissa Rosen. اقرأ أيضًا أفضل برامج لإنشاء قاعدة المعرفة للشركات الناشئة والمشاريع الصغيرة تعريف اتفاقية مستوى الخدمة ونصائح للشركات الصغيرة الاختلاف بين دعم العملاء وخدمة العملاء كيف تساعد خدمة دعم العملاء في دفع عجلة الإيرادات في مشروعك التجاري

كثيرًا ما يتكرّر هذا السيناريو: يأتي مطوّر وِب بنيّة إضفاء ”العصريّة“ لأحد المواقع (أي ليحسّن تجربته على المحمول أو يعدّل لوحة الألوان المستعملة فيه أو الخطوط أو أيّ شيء آخر)، وينتهي الأمر بأن يهدم إحدى أكثر المشاريع التجارية ازدهارًا على الإنترنت – أن يقتل الموقع بأخطاء السيو SEO (اختصار Search Engine Optimization أو ”تحسين محرّكات البحث لظهور الموقع“). وحين أقول ”كثيرًا“ فلستُ أبالغ أو أضخّم الأمر، بل أقصدها. فحين يراسلني زبونين اثنين مستقلّين يواجهان المشكلة ذاتها وفي أسبوع واحد، تكون ”كثيرًا“ حقًا. إليك ما يصف هذان الزبونان معًا وصفًا عادلًا: إذًا، ما سبب المشكلة؟ في الحالتين أعلاه: انعدام كفاءة مطوّر ووردبريس الذي أعاد تطوير الموقع، وتدميره لسيو الموقع (أي ترتيبه في عمليات البحث الطبيعيّة) وهو يعمل على التصميم الجديد. ولكن ولحسن الحظ، فأخطاء مطوّري ووردبريس تتشابه. هذا المقال مُوجّه لمُلّاك المواقع والمطوّرين على حدّ سواء، ويحاول شرح الطرائق الثلاثة الرئيسيّة التي ينفّذها مطوّر ووردبريس بلا قصد، فيُضرّ بترتيب عمليات البحث الطبيعيّة للموقع. سأحاول تقديم الطريقة التي يقدر بها مُلّاك المواقع حماية أنفسهم من أخطاء المطوّرين، كما ويعلم بها المطوّرين لئلا يقعوا في أيّة مشاكل شبيهة. أخطاء ثلاثة لتتجنّبها: كيف يقتل المطوّر سيو الموقع غالبًا ما يُضرّ المطوّر عديم الكفاءة بترتيب موقع ووردبريس في نتائج البحث – يُضرّه بثلاث طرائق رئيسية. بالطبع هناك أخرى غيرها ولكن هذه هي الأساسية. (ولو كنت مهتمًا، فالزبونان اللذان راسلاني هذا الأسبوع واجها نتائج الخطأين #1 و #2 بالترتيب). نفصّل أدناه كلّ مشكلة من هذه المشاكل بذكر: وصف عام لها، وطرائق حدوثها، وعواقبها وطريقة تجنّبها في مشاريعك على الوِب. لو كنت مطوّرًا فاقرأ الآتي واحرص على ألا تتسبّب بهذه المشاكل كي لا يضع الزبائن على اسمك علامة حمراء. ولو كنت مالكًا لموقع فحاول أن تُدرك ماهيّة هذه المشاكل وأعراضها خصوصًا لو بدأت تشكّ بأن ثمة مشاكل في أداء الموقع في عمليات البحث الطبيعية. وطبعًا، كيف تحمي نفسك منها. 1. ترك خيار ”منع محركات البحث من أرشفة هذا الموقع“ مؤشّرًا في موقع ووردبريس حين يُنشر لو أمكنني فقط إزالة هذا المربّع من ووردبريس، لو أمكنني… وظيفة الخيار ”منع محركات البحث من أرشفة هذا الموقع“ (Discourage Search Engines) هي كما يقول بالضبط، فهو يُخبر محرّكات البحث بأن تتجاهل الموقع تمامًا. لو أردت تفاصيل أكثر عن طريقة عمله فرجاءً اقرأ مقالي حول الموضوع. كيف تحدث المشكلة التأشير الخطأ لهذا المربّع يحصل في حالات عدّة مختلفة، إلّا أنّ الحالة المنتشرة هي تأشيره بينما يجري تطوير الموقع، ونسيان إلغاء تأشيره حين يُنشر. حين يُؤشّر على هذا المربّع يعرض ووردبريس تنبيهًا صغيرًا يقول ”Search Engines Discouraged“، ويمكن لمالك الموقع والمطوّر ألّا يعلمان به لشهور أو حتّى سنين. نتيجة هذه المشكلة هي أنّ جوجل سيُلغي فهرسة (كما طلبت تمامًا) موقعك و”ينسى وجوده“. ما إن يرى جوجل أنّ هذا المربّع مؤشّر فستخرج من نتائج عمليات البحث الطبيعيّة تمامًا. تبعات المشكلة النتيجة؟ بالضبط ما فعلناه: سيختفي الموقع من كل عملية بحث طبيعية وتحت أيّ ظرف كان. وبالنسبة إلى عمليات التحسين هذه، فهذا يعني ”الصفر المطلق“ وليس هناك ما هو أسوأ من هذا. ولو كنت تراقب حركة الناس في موقعك بانتظام ستلاحظ تأثير هذا بسرعة. فخلال أسبوع أو اثنين (ومع احترام جوجل طلبك بعدم فهرسة الموقع) سترى حركة الناس الطبيعية (أي من نتائج البحث) انخفضت إلى حدود الصفر أو الصفر حتى. بنظرة أولى سترى أن الحركة بشكل عام انخفضت 50 أو حتى 70 بالمئة بدون أن تعرف لذلك سببًا واضحًا. ولكن، إلغاء تأشير المربّع لن يحلّ المشكلة، فجوجل يعمل بالأقدميّة. أي أن المواقع التي كان لها تقييم س لعدد من عمليّات البحث لأشهر وسنوات متواصلة ستبقى كذلك لهذه العمليات، ذلك لأنّها موجودة منذ زمن طويل، وهذا سبب من الأسباب. التقييمات تتوارث -إن صح التعبير-، فحتّى الشهر أو الشهرين بعد إلغاء الفهرسة بالإجبار سيضرّ بتقييمات الموقع ويصعّب من إصلاحه بسرعة إلى حدّ الإستحالة. يمكن القول أنّ ”مكانك في الطابور ضاع“. صحيح أنّك غادرته لبرهة قصيرة، ولكنّك الآن ستبدأ من آخره. فعلتُ هذا مرّة لأحد زبائني حين بدأت عملي، وكان أمرًا شنيعًا. إيّاك تأشير ”Discourage Search Engines“ بنفسك ودرّبها -أي نفسك- لتكون يقظة وواعية لهذا الخيار في المواقع المنشورة التي تعمل عليها. الوقاية مهما حصل وفي أيّ زمان ومكان، لا تؤشّر ”Discourage Search Engines“. لو كنت مالكًا لأحد المواقع فاطلب من المطوّر صنع ”صفحة قريبًا“ تُخفي المحتوى كما يُخفيه الخيار ذاك. كما وتيقّظ إلى ذلك التنبيه الصغير بأنه ”تمّ منع محركات البحث من أرشفة موقعك“ (Search Engines Discouraged). 2. عدم تحويل الروابط 301 حين تغيير الروابط الدائمة إن كان موقعك يحظى بحركة بحث مهولة، فعليك أن تتيقّظ لأمر آخر: تغيّرت الروابط الدائمة؟ نسبة التوتّر: ارتفعي! يشير مصطلح ”الروابط الدائمة“ إلى روابط منشوراتك وصفحاتك ”الدائمة“. هذه بعض التغييرات عليها: تنتقل صفحة النبذة من http://mysite.com/about إلى http://mysite.com/about-us. تنتقل المدوّنات من نسق http://mysite.com/article-title إلى نسق http://mysite.com/month/year/article-title. ينتقل موقعك من http://mysite.com إلى https://mysite.com. ينتقل موقعك من https://mysite.com إلى https://mynewsite.com. تكفي هذه الأمثلة، وتذكّر: التغييرات على الروابط الدائمة تحدث متى ما تغيّرت عنواين الروابط الحاليّة، ولأيّ سبب كان. وهذه ”العناوين“ هي حقًا ما يستعمله جوجل لسرد المحتوى في موقعك، تمامًا كما عنوان منزلك حيث يصل المرء إليه، وعنوان بريدك الإلكتروني حيث تصل الرسائل إليه. كيف تحدث المشكلة لنعرف كيف يمكن أن تقتل التغييرات على الروابط الدائمة سيو موقعك، نطرح السؤال: ماذا يحدث إن تغيّر أحد العناوين ولم يعرف جوجل بهذا التغيير؟ الإجابة: العنوان القديم ”يضيع“، فما من محتوًى فيه بعد الآن. وجوجل لا يعلم أين ذهب هذا المحتوى، فلا يبالي لذلك وينقل صفحات المواقع الأخرى أعلى التقييمات – المواقع التي فيها الكلمات المفتاحية التي كانت موجودة في العنوان ”الضائع“. يمكن أن تحدث هذه المشكلة في داخل موقع ووردبريس، أو بينما تنقل موقعًا من نظام آخر إلى ووردبريس. لو كنت في موقع ووردبريس موجود فعلًا فيمكن أن تغيّر أنت مالك الموقع أو أحد مطوّريك – يمكن أن تغيّر بنية روابط الموقع الدائمة، أو تغيّر رابط أحد المنشورات (أو أكثر) وتكون ضحيّة لإحدى المزايا غير المتّسقة لووردبريس بخصوص طريقة تحويله للروابط هذه. (فمثلًا، يحوّل ووردبريس تلقائيًا المنشورات ويترك الصفحات، أي أنّك إن لم تحوّلها يدويًا فستضيع تقييمات صفحاتك.) أمّا عند الانتقال من نظام آخر إلى ووردبريس، فيمكن أن ينسى المطوّر (أو لا يعلم) بأنّ عليه تحويل الروابط القديمة: about-us.html إلى store/product-name.asp، أو store/product-name.asp إلى /shop/product-name/، وهكذا دواليك. في هذه الحال ستعطب كل الروابط القديمة، وهذه مشكلة عامّة وشنيعة جدًا. لو أردت معرفة ما على المطوّر إدراكه بخصوص الشغل التقني وراء تحويل الروابط الدائمة، فقد فصّلت هذا أدناه: تبعات المشكلة تختلف تبعات هذه المشكلة حسب مقدار المحتوى الذي لم يُحوّل وكم هو مهمّ هو. التبعة المتوسّطة لهذه المشكلة هي أن تفقد ترتيب بعض العناوين غير المهمّة كثيرًا. مثلًا تنتقل /privacy-policy/ إلى /our-privacy-policy/، يأتي جوجل ويُدرك الرابط بعد أسابيع قليلة، مع ذلك فذاك غير مهمّ إذ أنّ الصفحة القديمة لن تكون بتقييم أصلًا (من يريد صفحة بيان الخصوصية؟!). أمّا التبعة الأشدّ وقعًا هي أنّك تملك موقعًا معروفًا قديمًا وتعطب أو تضيع أو ينسى جوجل روابطها كلّها. إن تركت الأمر دون علاج فأنت ببساطة تبدأ موقعك من الصّفر بنظر السيو. فكلّ ”العناوين“ الجيّدة التي وَثِق بها جوجل اختفت، والآن عليك أن تكسب ثقته من جديد بعناوين جديدة كليًا لا تترابط مع القديمة بأيّ شكل من الأشكال. يمكن للحالة الثانية أن ترمي بمبيعات إحدى المشاريع التجارية الأكثر ازدهارًا إلى القعر، إلى الصفر. هذه هي الحال التي يواجهها أحد زبائني كما وضّحت في بداية المقال. أكرّر، لو كنت تراقب من حركة الناس في الموقع بانتظام ستلاحظ تأثير هذا بسرعة خلال أسبوع أو اثنين، وسترى انخفاض الحركة بشكل عام 50 بالمئة أو أكثر. ولو دقّقت أكثر فسترى أنّ الحركة من عمليات البحث الطبيعيّة صارت فجأة صفرًا أو ما يقارب الصفر. الوقاية حتّى لو لم تدرك التقاصيل التقنيّة فعليك أن تكون دومًا يقظًا لأيّ من أراد تغيير روابط موقعك. هذا اختبار بسيط يمكنك إجرائه: اكتب الرابط الذي سيتغيّر على ورقة (أو عددًا كبيرًا منها) وركّز على صفحات موقعك الرئيسية، أي تلك التي فيها كلمات مفتاحية تساعد على ترتيب الموقع مثل أقوى المقالات تأثيرًا أو صفحات المنتجات الرئيسية في الموقع. بعد أن تحدث التغييرات، اكتب الروابط القديمة وانظر لو ظهرت الصفحات الجديدة تلقائيًا. لو ظهرت فأنت في أمان. لو لم تظهر واحدة أو أكثر وظهرت صفحة خطأ (أكان فيها ”404“ أم لا)، فلا تسكت إلّا حين حلّ المشكلة. والأفضل لو كان هناك شخصين تقنيّين يفحصان التحويلات فيضمنان أنّ التغييرات حصلت كما يجب. بصفة عامّة، تحقّق مرة واثنتان من أيّ تغيير يحصل على الروابط الدائمة. للأسف فتحويلات 301 معقّدة: فمثلًا مصاعب إصدارات http وhttps من الموقع، وإصدارات www وغير www من الموقع والشرطات المائلة النهائية تحتاج اطّلاعًا واسعًا وتيقّظًا لتعمل كما يجب. لهذا يفضّل جلب شخصين تقنيّين لذلك. فالمئة دولار التي ستدفعها لتوظّف مستقلًا مدرّبًا يفحص تحويلات 301 أثناء الترحيل سيجنّبك مئات وآلاف بل ربّما ملايين الدولارات التي ستخسرها في تقييمات البحث التي حافظ عليها الموقع. 3. إعادة كتابة المحتوى بلا اكتراث لكلماته المفتاحيّة هذه المشكلة عامّة وشاملة أكثر. صحيح أنّ المشكلتين الأولى والثانية يمكن أن يقتلا سيو الموقع، إلّا أنّ هذه تسمّمه لا أكثر. بعبارة أخرى، تظهر تبعات هذه المشكلة ببطئ أكثر وعلى نحو أقلّ، ويمكن أن يكون حلّها أسهل. ولكنّ ملاحظتها وتحرّيها أصعب بكثير، ويمكن ألّا يعلم مالك الموقع تمامًا ما يجري، أو لا يعلما بوجود مشكلة من الأساس. كيف تحدث المشكلة كيف تحدث هذه؟ كالآتي: تعيد تطوير موقع يعتمد في تقييماته على كلمات مفتاحيّة مهمّة. لا يكترث الموقع الجديد بالطريقة التي كان يُقيّم بها المحتوى القديم. يتوقّف (بمرور الوقت) تقييم الموقع على هذه الكلمات. كيف يحدث هذا؟ بطرق شتّى فظيعة. أمّا أرجحها وأجسمها هي أن المطوّر الجديد أعاد كتابة كلّ محتوى الموقع بنفسه بلا أن يهتمّ، أو يفّكر ويأمل بأداء الموقع الحالي في عمليات البحث. فلنرى معًا هذا المثال. لنقل أنّ الكلمة المفتاحيّة الأهمّ في الموقع هي ”المزارع الطبيعيّة اليابانيّة“. ولكنّ المطور لم يبحث في الكلمات المفتاحية، كما وأنّه يحبّ عبارة ”الغابات الاستوائيّة“ لنفس المنتجات بتلك الكلمة. ورأى بأنّ على الموقع استقطاب كلّ من هو في شرق آسيا، وليس فقط اليابان. وهكذا، يغيّر كلّ مرّة تتكرّر فيها ”المزارع الطبيعيّة اليابانيّة“ في الموقع إلى ”الغابات الاستوائيّة الآسيويّة“. وبعدها تضيع حركة الناس (من عمليّات البحث الطبيعيّة) في عمق الغابة. وطبعًا هذه ليست الطريقة الوحيدة بل هناك طرائق عدّة وشتّى يمكن أن يُقتل بها سيو الموقع، وهي تتخطّى الطرق الصحيحة ليبقى فيه سليمًا - تتخطّاها بمئات بل آلاف الطرائق. فلنقل مثلًا أنّ أغلب المحتوى بقي كما هو، ولكنّك بدّلت ترويسات النصوص في الموقع مثل <h1> و<h2> وعوّضتها لتكون رسومات جميلة جذّابة مصمّمة بِحِرفيّة عالية، وفيها نفس النص، لكنّك لم تضع وسوم alt لهذه الصور. بهذا سيكون احتمال تعرّض الموقع لنكسة سيو عالٍ، ولن يعرف أحدٌ أسباب ذلك إلّا المطوّرين الدارسين للأمر أو محترفي السيو. تبعات المشكلة هنا، تعتمد التبعات على طريقة تقييم المحتوى السابقة، إضافةً إلى مدى سوء المحتوى الجديد (حسب السيو) موازنةً بالقديم. (طبعًا، لو كان المحتوى الجديد أفضل من القديم فسيكون هذا الفرق حسنًا! وهذا ما نأمله… إلّا لو كنت تتبّع استراتيجية محتوى تعتمد على السيو وانتقل إلى أخرى لا تعتمد عليه، هنا لن يكون التحسين حسنًا أبدًا. لحظة، تحسين؟) يمكن ألّا يُلحظ الفرق أبدًا لو قلّ مقدار كلمات صفحة ”النبذة“ المفتاحية بسبب إعادة كتابتها بلا اكتراث، ويمكن أن يكون الفرق صاعقًا لو قرّر أحد بأنّ أكثر منتجات السوق الإلكتروني مبيعًا لا تحتاج بالضرورة إلى عنوان أو وصف، بل صور فقط… وهكذا ينزل تقييم كل منتج ستّين مرّة. كما أنّه من الصعب التكهّن بمدى تعرّض الموقع لهذه الأمور، أكان سريعًا أو بنحوٍ أبطأ. ستأتي يومًا وترى بأنّ ”التقييم صار صعبًا“ فجأةً دون سبب، ولا تدري أكان هذا بسبب عبارة البحث التي يزيد عدد المتنافسين عليها، أو أكان ثمّة خطب في الموقع تقنيًا (وسوم <title>؟ وسوم schema.org؟ سرعة الموقع، أو حتّى ”ما هذا الذي يجري بموقعي؟!“. وكأنّه يتجرّع السمّ قطرة قطرة ولا يقدر أيًّا من العامّة تشخيص علتّه. ولهذا السبب بالذات لزامٌ عليك أن تتجنّب الوقوع في هذا الوحل من الأساس. الوقاية نصيحتي هنا لتتجنّب هذه الكوارث البيئيّة هي بأنّ توظّف كاتبي محتوى مهرة يفهمون السيو. لو كان المحتوى الحالي ذا تقييم محترم في البحث فيجب أن تكون التغييرات كلّها بلا استثناء على يد شخص يعرف السيو قلبًا وقالبًا. لو لم يكن الشخص الذي يكتب محتوى موقعك محترفًا في السيو، فعليه أن يكون على اطّلاع كافٍ به كي يكون اختصاصه لاحقًا لو أراد. ولكن للأسف فالسيو نفسه (كما وتطوير الوِب) هي وظائف ينقصها الرقابة الجيدة وليست مستقرّة، وبذلك فالمعيار أنزل بكثير ممّا يجب أن يكون. وهنا يدخل الإثبات بالتعارف إلى الموضوع. فعليك أن تقبل بكاتب محتوًى رشّحه أحد الثِّقات بأنّ الكاتب يفهم السيو جيدًا، أكان من رشّحه لك مطوّرًا أو مسوّقًا تقنيًا أو كاتب إعلانات أو مالك إحدى المواقع أو سيو آخر أو أيًا كان على هذه البسيطة. إن لم تعرف مَن يمكنه أن يرشّح لك شخصًا فابحث عن سيو ذو سمعة محترمة وأجرٍ عالٍ وادفع ثمن ساعة من وقته فيتحدّث مع الشخص الذي سيدقّق الموقع كي يتأكّد أكان الشخص أهلًا بالمهمة أم لا. أو يمكنك سؤاله (هذا ذو الأجر العالي) لو يعرف أحدًا يحوّلك إليه. ابتعد عن متاهات السيو! توظيف مطوّري الوِب عمليّة فيها خطورة. فأولئك الذي يُعيدون تصميم مطعمك لا يحرقوه أبدًا، على العكس تمامًا مع مطوّري الوِب! قصّتان في أسبوع واحد عن مشاريع تجارية مزدهرة رجعت شهورًا أو أعوامًا حتّى، والسبب أخطاء المطوّرين. آمل أن تكون الآن على دراية أكبر بكوارث السيو التي عليك تجنّبها أكنت مالكًا لأحد المواقع أو مطوّرًا. كما آمل أن تكون دائمًا مُدركًا لما سيحصل من أمور آتية. خُذها من أخطاء مجرّب: لن تكسب جائزة ”لا تخف أنا ذكي وسأكون على خير حال“ لو أخذت مسؤولية سيو المشاريع التجارية الحقّة على الإنترنت. وأخيرًا، أخطّط فعلًا لمقال يواصل على هذا يشرح ما تفعل لو تضرّر موقعك من هذه المشاكل أعلاه، فترقّبه. ما هي أخطاء السيو التي أضرّت بك أو بأحد زبائنك؟ شاركنا النقاش! ترجمة -وبتصرف- للمقال ‎“My Developer Ruined My Site’s SEO”: Three Huge SEO Mistakes and How to Avoid Them لصاحبه Fred Meyer

جميعنا نعلم أن التعهيد الخارجي للبرمجيات هو عبارة عن كارثة منتظرة في أية لحظة. في البداية تعثر على شركة تعدك بالحصول على كل ما تتمناه في منتج واحد، خلال وقت وميزانية محددين، بأعلى جودة ممكنة، مع واجهة استخدام جذابة، وتقنية متطورة، ودعم مدى الحياة دون متاعب. تقتنع بهذه المزايا وترسل لهم الدفعة الأولى؛ وهنا تبدأ الرحلة، ففريق العمل بالكاد يفهم متطلباتك، والجودة متدنية، ومع تجاوز كل الحدود المتوقعة للزمن والميزانية؛ يبلغ مستوى الإحباط لديك عنان السماء. بل إن "أفضل" جزء من ذلك كله هو أنه لا يمكن إيقافه؛ وإلا فستذهب كل الأموال التي أنفقتها هباء وسيكون عليك البدء من الصفر. لذا ستضطر للاستمرار بالارتباط مع هذا الفريق ﻷن تكلفة "الفراق" عنهم ستكون باهظة. ولكن؛ هل هناك طريقة أفضل للتعهيد الخارجي للبرمجيات؟ نعم؛ من الممكن القيام بذلك بطريقة صحيحة وخالية من المتاعب كليًا، ولكن عليك أن تكون مستعدًا لتعديل فلسفة الإدارة الخاصة بك. المبادئ الرئيسية هنا هي كالتالي: عليك أن تصارح فريق التعهيد بهواجسك بشكل مستمر ومنفتح. عليهم أن يبوحوا لك بالمخاطر والمشكلات التي تقابلهم بشكل مستمر ومنفتح أيضًا. هذان العاملان أساسيان لنجاح التعهيد الخارجي للبرمجيات؛ ولكن للأسف غالبًا ما يتم تجاهلهما. تعلّمت هذين المبدئين من المعلم وي لياو زي، إذ قال بما يتعلق بالاستراتيجية العسكرية في الصين القديمة عام 239 ق.م: دعوني أبرهن على هذا القول من خلال طرح بعض الأمثلة العملية عن كوارث التعهيد الخارجي للبرمجيات؛ وشرح كيفية تجنّب حصولها إذا اتبعت مبادئً تبلغ من العمر 2500 عام. أطول من الوقت المتوقع؛ أكثر من الميزانية المتاحة دائمًا ما يخبرك أفراد الفريق بأن المنتج جاهز بنسبة 95%، لكن هناك مع ذلك بعض المزايا غير المنفّذة أو المعطّلة. لقد قاموا بالكثير من العمل؛ ولقد دفعتَ الكثير من المال، لكن المنتج القابل للتسويق غير جاهز بعد؛ إنه يتطلب أسبوعًا إثر أسبوع؛ وشهرًا بعد شهر، دائمًا هناك تراكم، ولا يمكننا ببساطة أن ننتهي من ذلك، لقد بدأتَ ترى المشروع في كوابيسك، ولم يعد للأدوية المهدئة تأثير مساعد، هل يبدو لك هذا كله مألوفًا؟ الحقيقة التي ستدركها لاحقًا أنه لا يهم نوع العقد الذي وقعته مع شركائك في التعهيد الخارجي، كم عدد البنود التي حددتها، وكم عدد الوعود التي أُبرمت، إنهم يرغبون بالحفاظ عليك عميلًا دائمًا؛ أو على الأقل؛ ما دام في حسابك المصرفي شيء ما لتقدمه. كلاكما ترغبان بالنجاح بالتأكيد، لكن في حين يعني نجاحك كصاحب مشروع إطلاق المنتج النهائي للمستخدم، فإنّ نجاحهم كفريق تطوير برمجي يعني الاستمرار مطوّلًا بكتابة الشيفرات البرمجية لك، وهما هدفان لا يشتركان إلا بحيز ضيق، بل حتى يمكن القول أنهما هدفان متعارضان: فنجاحك يعني فشلهم. سيُسمعك أعضاء فريق التعهيد الكثير من العبارات من قبيل: أنهم يرغبون بإتمام بناء المنتج والتعاقد معك من جديد مستقبلًا؛ وسيقولون أن دافعهم الرئيسي هو سعادتك والحصول على منتج يشير لاسمك بقوّة؛ وسيؤكدون لك أن رضا العميل مقدّم لديهم على المال. على كل حال؛ أفترض أن لديك الجرأة الكافية لتعترف بالحقيقة: كل هذا محض كذب. إن الغالبية العظمى من مشاريع التعهيد الخارجي للبرمجيات تبوء بالفشل (انظر التقرير الأخير لـ CHAOS) ولعلّ مطوري البرمجيات يدركون هذه الحقيقة بشكل أفضل منك، إذ يعيشونها يوميًا مع مئات المشاريع؛ ولن يكون مشروعك استثناء من بينها. وهكذا؛ دعنا ننسى الوعود الجميلة ونسلط الضوء على الحقائق المتعبة، أنت الآن لوحدك. إليك ما أوصي به على ضوء المبادئ المذكورة آنفًا، تأكد من فهم الفريق لنقطتين: الوقت والميزانية والمجال المحدد لعملك. عواقب تجاوزهم هذه الحدود. وهذا يتعلق بالجزء الأول من المبادئ (عليك أن تصارح فريق التعهيد باهتمامك وقلقك بشكل مستمر ومنفتح). لكن ما يحدث عادة أن فريق التعهيد يبقى جاهلًا بالعمق الحقيقي للعمل؛ ما يسمعه فقط هو عبارة تتكرر على مسامعه مع كل مشروع (بأسرع وقت ممكن). والحقيقة أن عبارة "في أسرع وقت ممكن" ليست ميقاتًا محددًا، على العكس من ذلك؛ فهي تثبط الهمم خلافًا لما تفعله المواعيد الثابتة. يجب أن يكون لدى الفريق علم بالتاريخ الدقيق الذي ترغب باستلام المنتج فيه؛ وما الذي تريد استلامه بالضبط و"لماذا"، وعندما لا تكون الأمور واضحة ودقيقة بهذا الشكل سيبدأ العمل يتجه وفق منحى لا ترغب به. أؤكد هنا على سؤال "لماذا"؛ فمعظم أصحاب المشاريع يواجهون صعوبة في الإجابة عليه. لماذا تريد أن يكون المنتج جاهزًا مع بداية حزيران القادم؟ فقط لأنك سئمت من الانتظار؟ هذه ليست إجابة سديدة، فسأمُك من الانتظار لا يهم ما دام ثمة مال في حسابك المصرفي؛ لذا سيستمر الفريق في استنزافك، ولن يحترموا الموعد الذي أعطيته لهم. عجزك عن الإجابة على هذا السؤال أو عن إيضاحه للفريق سيجعلهم يشعرون بعدم وجود أهداف واضحة تتجه لها في عملك؛ الأمر الذي سيفقدك تقديرهم لتصرفك. إليك كيف يمكن أن يكون تحديد الزمن والتكلفة بشكله الصحيح: يجب أن تكون المزايا أ،ب وج جاهزة في الأول من شهر حزيران القادم، لأننا سنبدأ حملة تسويقية في الخامس منه. وإذا لم أطرح هذه المزايا سأخسر 25 ألف دولار من تكاليف التسويق، وإذا حدث ذلك سأضطر لخفض ميزانية التطوير الشهرية للنصف. عندما يسمع فريق التعهيد الخارجي هذه الكلمات؛ ويشعرون بأهمية المهلة المحددة لهم، سيتحولون إلى شريك حقيقي بالنسبة لك؛ وستبدأ أهدافهم بالتماشي مع أهدافك، لأنهم يعرفون مغبّة تجاوز العلامات الموضحة -ماديًا وزمنيًا-، ويدركون أن المتاعب التي ستواجهها جراء ذلك ستنتقل إليهم أيضًا. توقف عن طلب إتمام المنتج خلال "أسرع وقت ممكن"، توقف عن مهاتفة الفريق مرتين يوميًا؛ والصراخ والشكوى لمدة ساعة من أدائهم الضعيف، توقف عن استخدام هذه اللهجة في رسائلك الإلكترونية، هذه الضوضاء التي تحدثها لن تساعدك في الحصول على أي شيء؛ على العكس من ذلك، فهي تعقّد المسألة؛ ﻷنك تفقد احترامهم لك شيئًا فشيئًا، وعندها سيبدؤون بمعاملتك كبقرة حلوب تدفع لهم المال -وبالإضافة إلى هذا كشخص غبيّ وعاطفي-. بدلًا عن ذلك؛ قم بواجبك ووضح المعالم الحقيقية لمشروعك، فكر بالحدود اللازمة لكل من الوقت؛ المجال؛ والميزانية. اكتب ذلك بعبارات واضحة وموجزة، وتأكد أن تكون هذه الحدود واقعية وأن تتضمن الإجابة على السؤال الأهم: لماذا؟ لماذا تريد المنتج مع بداية شهر حزيران؟ لماذا تخصص مبلغًا أقل من 50 ألف دولار؟ لماذا تريد هذه المزايا الخمس في النسخة الأولى من المنتج؟ لماذا تريد أن يكون تطبيق الويب الخاص بمنتجك جاهزًا للتعامل مع ألف زيارة في نفس الوقت؟ لماذا تريد تطبيق الموبايل في الإصدار الأول؟ أجب على هذه الأسئلة لنفسك، وتأكد من كون الإجابات واضحة ومفهومة من قبل فريق التعهيد الخارجي، لا تخفِ عنهم هذه المعلومات. المنتج غير متقن تماما لديك أحلام بالحصول على موقع إلكتروني شبيه بـ Pinterest، سريع، سهل الاستخدام والتصفح، ويجعلك فخورًا عندما تستعرضه على زملائك. لكن كل ما تراه أمامك عبارة عن موقع غير متقن نهائيًا، بطيء، مع مظهر قبيح أيضًا. تطلبُ منهم القيام بشيء لإصلاح ذلك، ولا تحصل إلا على مزيد من الوعود. يستمر المشروع في استنزاف أموالك وتتضخم الميزانية المخصصة له، لكن ذلك لا يحسّنه ولا يزيد مظهره جمالًا، بالإضافة للفرق الشاسع بينه وبين Pinterest. يتزايد الإحباط يومًا إثر يوم؛ ولا تجد سبيلًا للخروج من ذلك كله. والنصيحة الوحيدة التي تتردد في محيطك هي بإعادة تصميم الموقع من الصفر مع فريق برمجي آخر. ألا يبدو لك هذا السيناريو مألوفًا؟ أعتقد أن السبب الرئيسي للوصول إلى هذه النهاية السيئة هو الخوف من الخصام، ففي بداية المشروع تسعى للحفاظ على علاقة جيدة مع فريق التعهيد الخارجي دون الإساءة لأي شخص منهم. وتحرصُ على عدم التدخل بعملهم لما قد يحمله ذلك من إهانة، ولعلّك لا ترغب أيضًا بالتعبير عن مخاوفك حيال جودة المنتج لئلّا تثبط فريق العمل، مع أملٍ لا تفصح عنه أن يتحسن المنتج في المستقبل، لكنك في المستقبل ستشعر أنك وصلت متأخرًا للغاية. مجددًا؛ مع استحضار المبادئ القديمة للفيلسوف الصيني؛ أود أن أنصحك بوضع إجراءات روتينية للتحقق من النتائج والتعبير عما يقلقك منذ اليوم الأول للمشروع. بالنسبة لنا فيTeamed.io فإننا نسأل العملاء أن يكونوا متواجدين على منصة GitHub ليستطلعوا ما نقوم به أولًا بأول، وأن يضيفوا تعليقاتهم على أيّ مشكل يلاحظونه مُباشرة على منصة GitHub. بالإضافة إلى أننا لا نمنّي صاحب المشروع بالكثير بخصوص الجودة؛ بل ونشجعه على أن يكون متشائمًا بهذا الخصوص؛ فقد أدركنا أننا بهذه الطريقة نخفف من مخاطر حدوث "الإحباط التراكمي". حاول أن تقوم بشيء مشابه مع فريق التعهيد الخارجي؛ لا تخف من الإساءة لأحد؛ فلطفك لن يساهم بالحفاظ على المشروع؛ بل لعله أسوأ ما تسديه لنفسك. مهما بدا لك منهج النقد المتكرر مثيرًا للنزاعات فهو صحيّ بشكل أكبر من السلام الناجم عن الصمت -السلام المؤدي إلى حروب في النهاية-، حاول أن تجد صيغة مناسبة لتوصل انطباعاتك وآرائك لفريق التعهيد بشكل منتظم، كن منفتحًا على هواجسك وصارح بها الفريق بانتظام حسب الوصية الأولى، وبهذا الشكل تحافظ على استقرار المشروع وتقلل من حصول المخاطر بأكبر شكل ممكن. بالإضافة إلى ذلك فمن الجيد للغاية أن تدعو من حين لآخر مُراجعين تقنيين لتحصل على آرائهم المستقلة حول منتج قيد التطوير. لا يمكنني الاعتماد على وعودهم تتصل بهم، تضع خطة للعمل، توضّح المعالم الأساسية، تعرّف المزايا المطلوبة، تحدد الأساسيات، تتّفقان على الجودة، ومن ثم تنتهي المكالمة. بعد عدة أيام تكتشف أن ذلك كله كان مضيعة للوقت، لا يمكنهم الإيفاء بوعودهم فهناك طارئ ما يحدث دومًا ويمنعهم من ذلك، أحدهم مريض، انهار الخادوم، بعض البرمجيات لا تؤدي الوظيفة المطلوبة، أجزاء من الكود البرمجي لم تعد تعمل.. إلخ. تتصل بهم مجددًا، تعبّر عن إحباطك بلهجة اتهام، تعود لتعريف المزايا المطلوبة مجددا؛ وتوضح من جديد كل ما ذكرته في مكالمتك السابقة، وبعد عدة أيام ستعود لنقطة البداية عينها، أليس كذلك؟ ألا يبدو هذا مشابهًا لما يحدث معك؟ انطلاقًا من تجربتي؛ فإن هذه الحالة من عدم القدرة على التنبؤ وعدم المصداقية تنجم عن صاحب المشروع نفسه وليس عن فريق التعهيد الخارجي. يحدث هذا عادة عند عدم إصغائك لهم؛ أو خوفهم من إخبارك بالحقيقة -وهما وجهان لعملة واحدة ويحملان التأثير نفسه على مشروعك-. البعض يسمي هذا بـ "التطوير المدفوع بالخوف" أو "fear-driven development". الفريق خائف منك؛ وهو مضطر للكذب عليك حتى تستمر بالعمل معه -والدفع له-. بشكل عام؛ سيخبرونك بما تودّ سماعه منهم: المشروع سينتهي قريبًا، العلل البرمجية يمكن إصلاحها بسهولة، مشاكل الأداء ثانوية وبسيطة، جودة بنية المشروع ممتازة، والفريق متحمس لعمله معك. عندما تسمع أيًا من هذه العبارات عليك أن تسأل نفسك: هل يشجعهم تعاملك على قول الحقيقة؟ وهل تمتنّ لهم لمصارحتك بالأخبار الحقيقية وإن كانت سيئة؟ مع استحضارنا مجددًا للمبدئين المذكورين أعلاه، أنصحك بالتأكد من اعتماد نهج المكافئة أو العقوبة تبعًا لشفافية فريق التعهيد الخارجي بنقل الأخبار لك؛ وأن يكون ذلك مقارنة مع أهداف المشروع لا حسب مشاعرك الشخصية. لا يجب على فرق تطوير البرمجيات أن تسعى لأن يكون العميل سعيدًا على الدوام؛ على العكس، فالمشروع المرجّح للنجاح هو ذاك الذي يكون فيه العميل بمزاج سيء ويحكم عليه بالفشل. لأوضح لك الأمر: إذا كنت تَسعد لكل خبر جيدٍ يزفه لك الفريق وتكافئهم عليه، فأنت تدرّبهم على الكذب. وإذا كنت تتوقع منهم تقديم أخبار جيدة باستمرار، فأنت لا تشجعهم على نقل الحقيقة دائمًا؛ ولا على فعل ما هو لمصلحة المشروع -لا لمصلحتك الشخصية-. أنت تثنيهم بذلك عن مجادلتك، بمعنى آخر؛ أنت تغلق قناة التواصل المفترضة بينك وبينهم؛ ولا تسمح للمعلومات أن تصل منهم إليك. وبهذه الطريقة تعزل نفسك عنهم، ويبدأ الفريق بالعمل ضدّك؛ وليس معك. ما أود نصحك به عمليًا هو كالتالي: أولًا: أعلن بشكل منتظم عن أهدافك وحدود مشروعك كما ذكرنا سابقًا، تأكد من فهم الفريق لخططك العملية والسبب الكامن ورائها -كإجابة على سؤال لماذا؟-. ثانيًا: اسأل الفريق بانتظام عن المشاكل والمخاطر التي تواجههم. اسألهم عن الأسباب التي تدفعهم للاعتقاد بضرورة تعديل أهداف المشروع، أو حتى بشكل أفضل؛ اطلب منهم أن يوثقوا المخاطر ويرسلوها لك بانتظام، كافئهم على شفافيتهم ومصداقيتهم بإرسال تقارير المخاطر. جرّب هذا النهج وسوف تفاجأ بما ستحتويه قائمة المخاطر من أشياء مثيرة للاهتمام. ترجمة -وبتصرف- للمقال How to Avoid a Software Outsourcing Disaster لكاتبه Yegor Bugayenko. حقوق الصورة البارزة: Designed by Freepik.

قد يتحول التصميم الطباعي إلى حقل للألغام بالنسبة للمبتدئين، فهناك العديد من اﻷخطاء البسيطة التي يقعون فيها والتي تؤثر وبشكل كبير على جودة الطباعة النهائية، ومع كون الطباعة عملية مكلفةً جداً، فإن الوقوع في مثل هذه اﻷخطاء سيسبب خسارة كبيرة في بعض الأحيان. نأمل أن توفر لك معرفة هذه اﻷخطاء المعلومات الكافية لتحضير التصاميم بالصورة الصحيحة لعملية الطباعة. اعرف الفرق بين RGB و CMYK غالبًا ما يقع المبتدؤون في فخ عدم التمييز بين نظامي اﻷلوان RGB و CMYK، فنظام RGB (أحمر، أخضر وأزرق) نظام ألوان جمعي additive يستخدم فيه الضوء لمزج اﻷلوان، وكلما أُضيف ضوء أكثر كان اللون الناتج أكثر إشراقا وحيوية. يُستخدم هذا النّظام في التّصاميم الرقمية التي تعرض على الشاشة فقط، وذلك ﻷن الشاشات تستخدم هذا النظام في العرض، إلا أن المشكلة تظهر عند تصميم عمل فني طباعي باستخدام أدوات تعمل على هذا النظام. أما نظام CMYK (السماوي، الأرجواني، اﻷصفر واﻷسود (المفتاح)) فهو نظام ألوان طرحي subtractive، حيث تمزج اﻷحبار ﻹنتاج درجات اﻷلوان المختلفة بصورة تشبه كثيرًا مزج الرَّسام للألوان، وكلما زادت كمّية الحبر الممزوجة كان اللون الناتج غامقًا أكثر. ونظراً لكون طيف اﻷلوان الناتج عن الضوء أوسع بكثير من الطيف الناتج عن اﻷحبار، فإن برامج التّصميم تحتوي على نمط CMYK خاص لتحديد سلسلة اﻷلوان (gamut) التي يمكن الاستفادة منها في التصميمات التي ستذهب إلى الطباعة. قد يؤدّي اعتماد نظام RGB بدلاً من CMYK إلى اختيار ألوان تبدو جميلة على الشّاشة ولكن لا يمكن طباعتها على الورق (دون استخدام أحبار خاصّة)، لذا ﻻ تفاجأ إذا وصلتك المطبوعة بألوان باهتة. راقب قيم ألوان CMYK تصبح اﻷلوان في نظام CMYK أغمق كلما زادت كمية الحبر، وتتم عملية إضافة اﻷلوان باستخدام مطبعة اﻷوفست offset (أو طابعة رقمية للكميات الصّغيرة)، حيث توضع طبقات من اﻷحبار اﻷربعة السماوي، الأرجواني، الأصفر واﻷسود على نفس المساحة في الورقة وذلك ﻹكساءها بالحبر وإنتاج مدى أوسع من اﻷلوان، وتحدد الشبكة النقطية Halftone Screen كمية الحبر المستخدمة خلال الطّباعة. أما في برامج التّصميم فإن عمليّة اختيار اﻷلوان سهلة وبسيطة، إذ يمكن الاستفادة من أداة اختيار اﻷلوان Color Picker أو اختيار اﻷلوان من لوحات اﻷلوان الجاهزة Swatches أو إدخال قيم C, M, Y و K يدويًّا. يجب الانتباه كذلك إلى أن اﻷلوان النّاتجة من نسب عالية من ألوان الطباعة اﻷربعة ستصبح مشبعة جدّا، وإذا تجاوز مجموع هذه النّسب 280% فإنّ اﻷلوان ستصبح داكنة وبشعة، وقد تحدث حالة نقع الحبر set-off (عندما يبقى الحبر رطباً فينتقل من ورقة إلى أخرى)، كذلك قد تظهر ألوان التّصميم جيدةً على شاشة الحاسوب، لكنها ستبدو في الطّباعة أغمق من ألوان التّصميم اﻷصليّة. قد يؤدّي استخدام مزيج من أحبار مختلفة إلى احتماليّة جعل المطبوعة ضبابيّة، ويظهر هذا التّأثير جليًّا في النّصوص، إذ أن ألواح اﻷلوان الأربعة لا تكون متطابقة عند وضعها فوق بعضها البعض (فيما يعرف بالمطابقة Registration) والنتيجة هي نصّ ضبابيّ تصعب قراءته. يمكن تجنّب هذه الحالة باستخدام لون واحد فقط، واعتماد القيمة 100% K (اﻷسود) ستعطي نصًّا أسودا ذا حواف حادّة وواضحة. لا تستخدم اللون اﻷسود الخاص بالفوتوشوب افتح برنامج الفوتوشوب واضغط على المفتاح D في لوحة المفاتيح لإعادة تعيين اللّونين الخلفيّ واﻷماميّ إلى القيم الافتراضيّة. اختر اللّون اﻷسود الذي سيُنتجه البرنامج، إنّه أسود أليس كذلك؟ انظر اﻵن إلى قيم CMYK التي تكوِّن هذا اللون، ستجد أنّه مؤلّف من 75% سماويّ، 68% أرجوانيّ، 67% أصفر و 90% أسود (المجموع 300%) وهذه كمّيّة كبيرة جداً من الحبر ستوضع على الورق، لذا تعوّد على اختيار اللّون اﻷسود يدويًّا. يمكن اختيار النّسب 0,0,0,100 للنّصوص ذات الحواف الحادّة واللّون اﻷسود، ولكنّ هذه القيم لن تعطي نتيجة جيّدة إذا ما استُخدمت في تلوين المساحات الكبيرة، إذ سيبدو اللّون رماديًّا داكنًا، لذا يمكن استخدام ما يسمّى بـ (اﻷسود الغني Rich Black) وهناك الكثير من النّسب المقترحة لهذا اللّون ولكن اﻷكثر شيوعًا هي 50,40,40,100. تعمل اﻷلوان اﻹضافيّة على جعل اللّون اﻷسود غامقًا بما فيه الكفاية مع مراعاة عدم تجاوز مجموع النسب لـ 280%. انتبه إلى أوزان الخطوط تؤدّي الشبكات النّقطية وظيفتها بصورة رائعة وذلك من خلال السّيطرة على كمّية الحبر التي ستوضع على الورق، ويتم ذلك عن طريق استخدام عدد أقل من النّقاط الصّغيرة في المساحات التي لا تحتاج إلى تغطية كثيرة. ولكنّ المشكلة هنا هي فقدان التفاصيل وخاصّةً عندما تكون النّصوص صغيرة أو ناعمة؛ لذا - وبحكم التجربة - فإنّ الحدّ اﻷدنى لوزن الخط هو 6 نقاط وهذا الحد يتغير بتغير نوع الخط، فعلى سبيل المثال سيختفي خطّ Helvetica Ultra-Light في أوزان أعلى من هذا الحد نظرًا لنعومته الفائقة، لذا يجب الانتباه إلى هذا اﻷمر عند إعداد المطبوعات ذات المقاسات الصغيرة. استخدم الدقة الصحيحة تؤثر الدقة في الحاسوب على مقاس الصورة في الشاشة فقط، أما في الطباعة فتحدد الدقة مدى الوضوح الذي ستظهر عليه التصاميم. يُعدّ المقدار 72ppi (نقطة في البوصة) مثالياً لصور اﻹنترنت، أما للطباعة فإن المقدار القياسي هو 300ppi، وكلما زادت النقاط أو البكسلات التي يمكن وضعها في كل بوصة، زادت كمية التفاصيل التي يمكن المحافظة عليها بعد إعادة إنتاج الصورة بواسطة الأحبار. يجب التأكد دائمًا أن دقة التصميم هي 300ppi، ولو حاولت وضع صورة ذات دقة 72ppi في ملف دقته 300ppi ستلاحظ أنها أصبحت صغيرة جدًّا وذلك ﻷن البرنامج سيقوم بإعادة تحجيمها لتلائم الدقة الجديدة، لذا ستحتاج إلى صور ذات أحجام كبيرة جدّا عند التّعامل مع الملفات بدقة 300ppi، وستصبح صور الإنترنت العشوائيّة عديمة الفائدة. يجب الانتباه كذلك إلى أنّه ليس باﻹمكان زيادة الدقة لملف ذي دقة متدنّية، لذا تأكد من استخدام الدقة الصحيحة قبل الشروع بالتصميم لتتجنب إعادة العمل من جديد. ﻻ تنس التسييل Bleed ليست الدقة وحدها عاملًا مهما في التصميم الطباعي، فعليك أن تتذكر التسييل كذلك. يُعرف التسييل بأنه المسافة الزائدة حول حوافّالتّصميم والتي تمتدّعبرها عناصر الخلفيّة القريبة من تلك الحواف، ما يمنع ظهور حواف بيضاء في المطبوعة إذا ما حصل أي خطأ طفيف في عمليّة قص الورق. وتختلف مسافة التّسييل من مطبعة إلى أخرى ومن مشروع إلى آخر، لذا ﻻ تتردّد في الاتّصال بالمطبعة الّتي ستتعامل معها لمعرفة كافّة التّفاصيل. راجع التصميم وصحح اﻷخطاء على الرغم من مراجعة هذه المقالة وتصحيح اﻷخطاء فيها، إلا أنها قد تحتوي على بعض اﻷخطاء، وعملية تصحيح اﻷخطاء سهلة على اﻹنترنت، ولكن تخيل ما ستشعر به عند استلامك لخمسة آلاف نسخة من مطبوعتك لتجد فيها خطأً فادحا يتكرر في كل نسخة منها. ليس باﻹمكان تصحيح اﻷخطاء بعد الطباعة، لذا خذ الوقت الكافي لمراجعة التصميم، راجع المسافات بين الحروف والكلمات، اﻷقواس، الفواصل والنقاط، صحح اﻷخطاء اﻹملائية والنحوية قدر اﻹمكان، ولا تعتمد تمامًا على المصححات اللغوية اﻵلية، إذ قد تفوتها بعض اﻷخطاء، وبالمناسبة الصورة أعلاه ليست حقيقية. ترجمة ـوبتصرّفـ للمقال 7Beginner Mistakes to Avoid When Designing for Print لصاحبه Chris Spooner. حقوق الصورة البارزة: Designed by Freepik.

عندما يصبح المرء مديرًا، فإَنّه سيخوض تجربة جديدة تمامًا، ولهذا السبب يخشى المديرون الذين يباشرون عملهم للمرة الأولى من ارتكاب الأخطاء. يدلُّ هذا الخوف على التحلّي بالحرص والمسؤولية، ولكنَّ ارتكاب الأخطاء هو من صميم الإقدام على خوض تحدٍ جديد، حيث يذكر ايون فاليس (Ion Valis) في كتابه الخطأ العظيم أنَّه: «من المهم جدًا أن نتعلم من أخطائنا» إنّ فعل بعض الأمور بطريقة خطأ هو جزء من الطبيعة الإنسانية، وعندما يكون المدير إنسانًا فإنَّه سيكون مديرًا جيدًا. ارتكاب المديرين للأخطاء أمرٌ لا مفرَّ منه، ولكنَّ الأمر المهم هو أن يحاولوا التعلُّم وتطوير أنفسهم من خلال الاستفادة من هذه الأخطاء، ومن الجيد أيضًا أن يَقُوا أنفسهم من الوقوع في الأخطاء منذ البداية لكي يكون النجاح حليفهم. فيما يلي بعض الأخطاء الشائعة التي يرتكبها المديرون الجدد، وبعض النصائح التي تساعد على تجنب هذه الأخطاء. 1. التركيز على التفاصيل والتدخل في كل صغيرة يجب أن يكون المديرون على دراية شاملة بالمشاريع التي يعمل عليها موظفوهم وبكيفية ملائمة هذه المشاريع لأهداف الفريق والشركة، إذ يتوجب على الموظف عندما يترَّقى إلى مدير أن يغيِّر من طريقته السابقة التي كانت تعتمد على التركيز على التفاصيل. قد يشعر المدير الجديد أنَّه مضطرٌ إلى توجيه موظفيه في كل خطوة من خطوات المهام الموكلة إليهم، و -الأسوأ من ذلك- قد يشعر أنَّه مضطرٌ إلى القيام بأعمالهم نيابةً عنهم. يتمثل دور قائد الفريق في توجيه فريقه من خلال وضع الأهداف والتنسيق مع الجميع لأجل تحقيقها، وهذا يعني أنَّ عليه تشجيع الموظفين أثناء عملهم على تحقيق الأهداف مع إعطائهم الحرية في اختيار طريقة العمل. نصيحة: اعقد اجتماعًا في المراحل المبكرة لمناقشة الأهداف المشتركة والتخطيط للمشاريع التي تتماشى مع هذه الأهداف؛ فهذا الأمر سيوحِّد جهود الجميع وسيمنحك الثقة للتنحي جانبًا وإتاحة المجال أمام موظفيك للعمل باستقلالية. 2. عدم التعامل مع الموظفين بطريقة فردية من المعلوم أنَّ فريق العمل يتعاون في سبيل تحقيق الأهداف المشتركة، ولكنَّ هذا الفريق مكوَّن من مجموعة من الأفراد ولكل فردٍ منهم مهاراته وشخصيته التي تميّزه عن غيره، كما أنَّ كل موظف يُقدِّم منفعةً مختلفة، ويُشكِّلون معًا مجموع الفريق. «يجب أن يكون المدير واعيًا بالفروقات بين الموظفين وأن يتجنَّب معاملتهم جميعًا بنفس الطريقة.» عندما يتعلق الأمر بالأهداف فعلى المدير أن يكون ذو نظرة واسعة، ولكن عليه أن يعرف موظفيه وأدوارهم على نحوٍ أكثر فردية؛ فهم لا يملكون مهاراتٍ مختلفةً فحسب، بل لديهم أيضًا احتياجاتٍ مختلفة ويحتاجون منه أنواعًا مختلفة من الدعم. نصيحة: بعد أن تجتمع مع فريقك كمجموعة واحدة، اجتمع مع كل موظفٍ منهم على حدة لمناقشة مهامه الفردية وأسلوبه في العمل، إذ ستساعدك معرفة الموظفين على المستوى الشخصي في دعمهم بفاعليةٍ أكبر. 3. إعطاء الأولوية للرؤساء عوضًا عن فريق العمل يتضمن عمل المدير نقل محور اهتمامه ما بين فريق العمل الخاص به ورؤسائه، وينبغي عليه أن يسعى إلى تحويل الأهداف التي يريدها رؤساؤه إلى أفعالٍ يقوم بها فريق العمل الخاص به، ومن ثمَّ عليه أن يبيِّن لرؤسائه كيف أنَّ العمل الذي أنجزه الفريق قد حقَّق النتائج المرجوَّة. قد يكون من الصعب معرفة كيفية توزيع الاهتمام والتأكد من رضا الجميع، ولكنَّ نجاح المدير يظهر من خلال نجاح فريق العمل الخاص به، ولذلك فإنَّ إعطاء الأولوية لفريق العمل سيساعد المدير على حصد النتائج التي يتوقعها رؤساؤه منه، كما أنّ دور المدير ينطوي على الدفاع عن موظفيه أمام رؤسائه. نصيحة: اجتمع مع رؤسائك لكي تحدِّد بوضوح توقعاتهم وكيف يمكن أن تتماشى أهداف فريقك معها، وانقل هذه المعلومات إلى موظفيك حتى تستطيعوا النجاح كفريق عملٍ واحد. 4. التصرف كرئيس مسيطر بدلاً من التصرف كقائد من أحد أهم المفاهيم الخطأ المتعلقة بالمدير هو أنَّ بإمكانه إصدار الأوامر بسبب امتلاكه سلطةً ونفوذًا، ولكن وجوده في موضع يسمح له بتنظيم عمل الموظفين لا يعني أن يتسلط على من هم حوله. «المدير الجيد ليس أسمى من فريق العمل الخاص به، بل هو جزءٌ منه.» يُعدُّ توجيه فريق العمل نحو النجاح من الأمور المناطة بالمدير، ولكن يقع على عاتقه أيضًا التأكد من أنَّ موظفيه لديهم كل ما يحتاجونه لتحقيق النجاح، وعندما يتعلق الأمر بمساندة الموظفين فإنَّ فهم نموذج القيادة الخَدَميِّة يمكن أن يكون نقطة بداية جيِّدة لذلك. نصيحة: كن جزءًا من فريق العمل واجعل جميع موظفيك يشاركون في اتخاذ القرارات الجماعية وفي وضع الأهداف؛ إذ يرغب الموظفون في معرفة كيف يساهم العمل الذي يقومون به في تحقيق الأهداف الكبرى للفريق وللشركة. 5. التصنع من الأخطاء الشائعة التي يرتكبها المديرون الجدد هي محاولة التصنُّع؛ فعندما يتقلَّدون منصبهم الجديد، قد يضغطون على أنفسهم لكي يبدوا مثاليين، ولكن من الأفضل دائمًا أن يكون المرء صادقًا. غالبًا ما تنبع محاولة التصنُّع -بطريقةٍ ما- من الخوف من ارتكاب الأخطاء، ومن طُرق التصنُّع المنتشرة التي ينبغي الانتباه لها: التظاهر بمعرفة كل شيء: عندما يصبح المرء مديرًا، فإنَّه سيخوض عملية تعلُّم، ويستغرق الأمر وقتًا لكي يصبح مُلمًّا بعمله، ولا بأس إن لم تكن لديه معرفة بكل الأمور في اليوم الأول الذي يتولّى فيه العمل، ويُمكنه أن يطرح الأسئلة وأن يكون صريحًا ومُحبَّاً للمعرفة، وأن يضع في باله بأنّه من الممكن أن يتعلم أشياءً جديدة من موظفيه. إخفاء التحدِّيات: لا ضَيْر في أن يتحدث المدير مع المديرين الآخرين ومع رؤسائه بخصوص التحديات التي تواجهه، فهو ليس وحيدًا، كما يمكن أن يُكسبه التحدُّث مع الأشخاص الذين مرُّوا بهذه التحديات نظرةً أكثر عمقًا. محاكاة أساليب القيادة: يُمكن أن يتعلم المدير الكثير من المديرين الذين يُكِنُّ لهم احترامًا، ولكن عليه أن يتجنب محاولة تقليد أساليبهم، فكل مدير يُشكِّل مع فريق العمل الخاص به مجموعةً فريدة، لذلك من المهم أن يجد أسلوب القيادة الأنسب لتحقيق أهدافه. خلق الحواجز: يتمحور عمل المدير حول العلاقات بين الأفراد وإدارتهم، لذلك من المهم أن يتصَّرف على سجيَّته وأن يتقبَّل أخطاءه وأن يتعامل بإنسانية، فهذا سيساعده على بناء الثقة بينه وبين موظفيه. نصيحة: اغتنم فرص التدريب كلّما استطعت، وشجِّع موظفيك على إعطائك ملاحظات تتعلق بأدائك كمدير حتى تتمكَّن من تحسين نفسك باستمرار. يُعدُّ ارتكاب الأخطاء جزءًا لا يتجزأ من خوض أي تحدٍ جديد، ولكنَّ النصائح السابقة عبارة عن طُرُق بسيطة تساعد المدير الجديد على وقاية نفسه من الوقوع في الأخطاء الكبيرة وتجنُّبها. علينا أن نتذكًّر أنَّه من الطبيعي أن يرتكب المدير وموظفوه أخطاءً، والأمر الأكثر أهمِّيةً هو كيفية التعلُّم وتطوير النفس من خلال الاستفادة من هذه الأخطاء. ما الأخطاء التي ارتكبتها عندما أصبحت مديرًا جديدًا؟ حان دورك الآن لتترك تعليقًا تخبرنا من خلاله عن الأخطاء التي ارتكبتَها عندما كنتَ مديرًا جديدًا وكيف تعلَّمتَ منها. ترجمة -وبتصرف- للمقال How to Avoid 5 Mistakes New Managers Make لصاحبته Nora St-Aubin

قد يزور عميلك المُحتمل موقعك الشّخصي الآن بينما تقرأ هذا المقال، سمع عنك ذلك العميل واعتقد بأنّه من العظيم أن يتعامل معك، ولحسن حظّك فإن له ميزانيّةٍ عالية. لكن ما إن تصفّح ذلك العميل موقعك حتّى غيّر رأيه، لم يتصل بك، وبدلًا من ذلك تراجع وذهب ليبحث عن شخصٍ آخر. هل تريد ذلك أن يحدث ؟ بالتأكيد لا. لكنّه يحدث أكثر مما تعتقد، لذلك دعنا نصلح الأمورَ الآن. موقعك الشّخصي الذي تعرض خدماتك من خلاله قد يشوّه صورتك ويجعلك تبدو ضيّق الأفق، ساذجًا، غير كفءٍ، عديمَ الخبرة، أو قد يُعطي الانطباع بأنّك تُعاني من جميع هذه العُيوب. يؤسفني قولُ ذلك، لكنّ هذا الأمر صحيحٌ في 80% من الأوقات ولهذا أرغب في التّحذير من الأمر. عندما تقوم بأحد هذه الأخطاء التّالية في موقعك، فإنه لن يخدمك أو يلمِّع اسمك: الإفراط في الرسميّة، فالطريقة المتكلّفة تصنع فجوةً بينك وبين العملاء.أن تكون ودودًا بشكلٍ مفرط ومبتعدًا عن الرسميّة، من المفترض ألا تستخدم الاختصارات أو الوجوه التعبيرية وألا تنشر معلوماتٍ عن حياتك الخاصة على موقعك الإلكتروني.الإلحاح واللهث وراء زيادة المبيعات، أساليب المبالغة والضغط غالبًا ما تصدُ العملاء المحتملين.اختلاف لهجتك على مختلف صفحات الموقع بشكلٍ كبير لسعيك لكسب رضا الجميع.الكتابة عن نفسك بضمير الغائب، كأن تقول: "ندى أشرف كاتبة ومدوِّنة مستقلة".الكتابة عن نفسك بصيغة الجمع، كأن تقول: "راسلنا وسنرد عليك في أقرب وقت".ألا تكتب مُحتوى موقعك الإلكترونيّ بنفسك.بالتأكيد هناك استثناءات لهذه القواعد العامّة فلربّما تحتاج أن تستخدم اللغة الرسميّة بشكلٍ أكبر في موقعك ليناسب سوقك المستهدف مثلًا. أنت الأكثر درايةً بنوع العملاء الذين تستهدفهم وتريد أن تجذبهم لموقعك. لكن إن كنت لا تملك أسبابًا منطقيّة لاختيارك الطريقة التي تكتب بها في موقعك، فقد حان الوقت لأن تفكّر في الأمر بمزيدٍ من العمق. الكتابة بصوت يُعبّر فعليّا عنك هي رهانك الرابح عندما تكتب عن نفسك وخدماتك، سواءً كنت مدوّنًا على الإنترنت أو كاتبًا على أرض الواقع. لماذا الكتابة بصوت يعبر بصدق عنك هي أفضل ما يمكنك القيام بهيزور عميلك المحتمل موقعك ليعرف المزيد عنك وعن شخصيّتك، وبناءً على ذلك يقرّر إن كان يناسبه التعامل معك أم لا. كتابة رسالةٍ مناسبةٍ للقارئ، رسالةٌ واضحة وحقيقيّة، تجعلك تقطع شوطًا طويلًا، سواءً في مجال صياغة موقعك أو الربح من خدماتك. الرسالة الرئيسية التي تريد إيصالها من الموقع الذي تعرض خدماتك من خلاله هي: "وظّفني فأنا أهلٌ لذلك" لا يتوجّب عليك ذكر ذلك صراحةً -رغم أنّ القيام بذلك قد يكون السّبب الذي قد يدفع بأصحاب بعض المشاريع إلى توظيفك- بيانُ أهليّتك وكفاءتك أولويّة، وتستطيع أيضًا إضافة أسبابٍ إضافيّة تغري العملاء المحتملين بالتعامل معك. تستطيع التغلُّب على قلّة الخبرة بالحماسة وامتلاك مهارات التعلم، وبإمكانك أن تتغلب على قلّة معرفتك بالبحث. ارتكابُ هذه الأخطاء –التي ذُكِرت في المقال- في موقعك قد يجعل العميل يتوجّس منك خيفة ويخشى التعامل معك. كيف تستعيد صوتك المتفردلا تقلق، لكلّ مشكلةٍ حل، إذا كانت صياغة موقعك لا تعبّر عنك بشكل جيّد، فأمامك 4 خطوات بسيطة لتعالج هذا الأمر: اطلب من أحد أصدقائك أن يجري مقابلةً معك عن عملك، خبراتك وخلفيّتك الثقافيّة، والخدمات التي تقدمها. استعمل هذه المقابلة كمرجعٍ لصياغة مُحتوى موقعك الشّخصي، حاول أن تحافظ على طريقتك الطبيعية غير المتكلّفة عندما تكيّف نصّ المقابلة ليتناسب مع موقعك.اقرأ الصيغة الحاليّة من موقعك بصوتٍ مرتفع لشخصٍ يعرفك جيّدًا. اطلب منه أن يرفع يده كلّ مرّةٍ لا يشعر فيها أنّ الكلام يصفك فعليّا، وسيسلط ذلك الضوء على النواحي التي يجب عليك تعديلها.حدّد سوقك المستهدف لتستطيع تكييف صياغة موقعك لجذب العملاء المثاليين، تخيّل أنّك تُجري محادثةً معهم على انفراد.اطّلع على مواقع المستقلين الذين تنظر لهم بعين الإعجاب، حلّل كيف أشبعوا مواقعهم من شخصيّاتهم المتفرّدة، ولاحظ العناصر الناجحة التي تستطيع محاكاتها.عندما تستخدم صوتك الخاص للتعبير عن نفسك، سيفهم العملاء أكثر من تكون. ستجذب المشاريع التي تناسبك، وستتجنب إضاعة وقتك في تلك التي لا تناسبك. كل ما عليك فعله -ببساطةٍ- هو أن تكون "أنت"، وأنت تسمح لموقعك أن يُظهر جانبًا من شخصيتك. ترجمة -وبتصرف- للمقال Why Your Freelance Writer Website Makes You Sound Like an Idiot لصاحبته Sophie Lizard. حقوق الصورة البارزة: Designed by Freepik.

سنلقي في هذا الدرس نظرةً إلى آلية التعامل مع الأخطاء و الإشارات أثناء تنفيذ السكربتات. يُقاس الفرق بين البرمجة الجيدة والتعيسة عادةً بمدة استقرار البرنامج ومرونته، أي قابلية تعامل البرنامج مع الحالات التي لا تسير فيها الأمور على ما يرام. حالة الخروج تتذكر من دروسنا السابقة أنَّ كل برنامج مكتوب بطريقة جيدة سيُعيد حالة خروج عندما ينتهي تنفيذه؛ فإذا انتهى تنفيذ البرنامج بنجاح، فستكون حالة الخروج مساويةً للصفر، وإن كانت حالة الخروج مساوية لقيمة مختلفة عن الصفر، فهذا يدلّ أنَّ البرنامج قد واجهة مشكلةً ما منعته من إتمام مهمته. من المهم جدًا التحقق من حالة خروج البرامج التي تستدعيها في سكربتاتك، ومن المهم أيضًا أن تُعيد سكربتاتك حالة خروج مفيدة عندما تنتهي. لقد مرّ عليّ مدير أنظمة يونكس قد كتب سكربتًا لنظام إنتاجي يحتوي على السطرين الآتيين: # Example of a really bad idea cd $some_directory rm * هذه طريقة سيئة جدًا لكتابة البرامج، لأنها تعمل بشكلٍ جيد لو لم يحدث أيّ خطأ. فالسطر الأول ينقل مجلد العمل الحالي إلى المسار الموجود في المتغير ‎$some_directory ثم يحذف جميع الملفات الموجودة في ذاك المجلد؛ وهذه هي الحالة الطبيعية لتنفيذ السكربت، لكن ماذا يحدث لو لم يكن المسار الموجود في المتغير ‎$some_directory موجودًا؟ سيفشل -في هذه الحالة- تنفيذ الأمر cd ثم سيُنفِّذ السكربتُ الأمرَ rm في مجلد العمل الحالي، وهنا ستقع الكارثة! بالمناسبة، واجه سكربت مدير الأنظمة البائس هذه المشكلة ودمَّر جزءًا كبيرًا مهمًا من النظام الإنتاجي؛ لا تدع ذلك يحدث لك! مشكلة السكربت السابق أنَّه لم يتحقق من حالة خروج الأمر cd قبل الاستمرار وتنفيذ الأمر rm. التحقق من حالة الخروج هنالك عدِّة طرائق تستطيع فيها الحصول على حالة الخروج والتصرف وفقًا لها. أول طريقة هي معاينة محتويات متغير البيئة ‎$?‎، الذي يحتوي على حالة خروج آخر أمر مُنفَّذ. يمكنك رؤية ذلك في المثال الآتي: $ true; echo $? 0 $ false; echo $? 1 تذكَّر أنَّ الأمرَين true و false لا يفعلان شيئًا سوى الانتهاء بحالة خروج تساوي 0 و 1 على التوالي وبالترتيب. وعبر استخدامهما سنرى كيف يُعيد المتغير ‎$?‎ حالة الخروج لآخر أمر مُنفَّذ. نستطيع كتابة السكربت بهذه الطريقة بعد التحقق من حالة الخروج: # Check the exit status cd $some_directory if [ "$?" = "0" ]; then rm * else echo "Cannot change directory!" 1>&2 exit 1 fi تفحصنا محتوى الأمر cd، وإن كان لا يساوي الصفر، فسيطبع رسالة خطأ في مجرى الخطأ القياسي (standard error stream) وسينتهي تنفيذه مع ضبط حالة الخروج إلى 1. صحيح أنَّ النسخة السابقة تقدِّم حلًا لمشكلتنا، إلا أنَّ هنالك طرائق أفضل ستقلل مقدار الكتابة التي نحتاج لها. سنستخدم في المثال الآتي العبارة الشرطية if مباشرةً، لأنَّها تحقق من حالة خروج الأمر الذي يليها ثم تتصرف وفقًا لذلك. يمكننا إعادة صياغة السكربت كالآتي: # A better way if cd $some_directory; then rm * else echo "Could not change directory! Aborting." 1>&2 exit 1 fi تحققنا هنا أنَّ تنفيذ الأمر cd قد نجح، وبعد ذلك سينُفّذ الأمر rm؛ أو ستظهر رسالة خطأ فيما عدا ذلك وينتهي البرنامج بحالة خروج تساوي 1، مما يشير إلى حدوث مشكلة أثناء التنفيذ. دالة خروج عند حدوث خطأ لمّا كنّا نتحقق من الأخطاء مرارًا وتكرارًا في برامجنا، فمن المعقول أن نكتب دالةً لإظهار الأخطاء، مما يوفِّر علينا بعض الكتابة ويُنمّي إحساس الكسل لدينا :-) . # An error exit function error_exit() { echo "$1" 1>&2 exit 1 } # Using error_exit if cd $some_directory; then rm * else error_exit "Cannot change directory! Aborting." fi معاملات التحكم: "و" AND وَ "أو" OR يمكننا تبسيط السكربت كثيرًا باستخدام معاملَي التحكم "AND" و "OR"، وسأقتبس الفقرة الآتية من صفحة دليل bash لشرح آلية عملهما: سنستعمل الأمرَين true و false مجددًا لكي نشاهد آلية التعامل مع AND و OR عمليًا: $ true || echo "echo executed" $ false || echo "echo executed" echo executed $ true && echo "echo executed" echo executed $ false && echo "echo executed" $ باستخدام هذه التقنية، يمكننا إعادة كتابة نسخة مختصرة أكثر من السكربت السابق: # Simplest of all cd $some_directory || error_exit "Cannot change directory! Aborting" rm * إن لم يكن إنهاء البرنامج مطلوبًا، فيمكننا كتابة السكربت بالصيغة الآتية: # Another way to do it if exiting is not desired cd $some_directory && rm * صحيحٌ أننا أخذنا جميع الاحتياطات الممكنة في مثال cd، إلا أنني أود أن أشير أنَّ الشيفرة يمكن أن تتعرض للمشاكل البرمجية الشائعة، خصوصًا إذا كُتِبَ اسم المتغير الذي يحتوي على مسار المجلد الذي نريد حذف محتوياته بشكلٍ خاطئ. ففي هذه الحالة ستضع الصَدَفة قيمةً فارغةً بدلًا من اسم المتغير وسينتج تنفيذ الأمر cd، لكنه سينتقل إلى مجلد المنزل للمستخدم الحالي، ثم سيحذف كل ما فيه! تحسين دالة الخروج عند حدوث خطأ هنالك عددٌ من التحسينات التي نستطيع إجراءها على الدالة error_exit، أود أن أضع اسم البرنامج في رسالة الخطأ كي أوضِّح من أين تأتي رسالة الخطأ؛ وذلك مهمٌ خصوصًا في السكربتات الكبيرة والمعقدة التي تُستدعى فيها سكربتات داخل سكربتات… لاحظ أيضًا تضمين متغير البيئة LINENO الذي سيساعد في تحديد السطر الذي حدثت فيه المشكلة. #!/bin/bash # A slicker error handling routine # I put a variable in my scripts named PROGNAME which # holds the name of the program being run. You can get this # value from the first item on the command line ($0). PROGNAME=$(basename $0) error_exit() { # ---------------------------------------------------------------- # Function for exit due to fatal program error # Accepts 1 argument: # string containing descriptive error message # ---------------------------------------------------------------- echo "${PROGNAME}: ${1:-"Unknown Error"}" 1>&2 exit 1 } # Example call of the error_exit function. Note the inclusion # of the LINENO environment variable. It contains the current # line number. echo "Example of error with line number and message" error_exit "$LINENO: An error has occurred." استخدام الحاضنات ({}) داخل الدالة error_exit هو مثالٌ عن "توسعة المعاملات" (parameter expansion)، يمكنك وضع حاضنات حول اسم المتغير (كما في {‎${PROGNAME) إذا أردت عزل المتغير عمّا حوله من نصوص. يُفضِّل البعض وضع الحاضنات حول كل متغير، وهذا الأمر منوطٌ بك. الشيء الآخر الذي أريد الإشارة إليه هو {"‎${1:- "Unknown Error الذي يعني أنَّه لو لم يكن المعامل 1 (أي ‎$1) مُعرَّفًا، فضع السلسلة النصية "Unknown Error" مكانه. يمكن إجراء الكثير من عمليات معالجة النصوص باستخدام توسعة المعاملات. الإشارات Signals لا تستطيع اعتبار أنَّ الأخطاء هي المُسبِّب الوحيد لإنهاء البرنامج على نحوٍ غير متوقع، فعليك أن تحتاط من الإشارات (signals) أيضًا. ليكن لديك المثال الآتي: #!/bin/bash echo "this script will endlessly loop until you stop it" while true; do : # Do nothing done بعد أن تُشغِّل هذا السكربت، فسيبدو وكأنَّه علّق، لكنه -مثل أغلبية البرامج التي تُعلِّق- قد دخل في حلقة تكرار ولم يخرج منها. فالسكربت في مثالنا ينتظر أن يُعيد الأمر true حالة خروج لا تساوي الصفر، وهذا لن يحدث أبدًا. وسيستمر تنفيذ السكربت إلى أن تُرسِل الصَدَفة bash إشارةً له لإيقافه. يمكنك إرسال إشارة بالضغط على Ctrl+c التي تُسمى SIGINT (مختصرة من SIGnal INTerrupt). إنهاء البرامج التي تستقبل إشارات بشكل سليم حسنًا، يمكن أن تأتي إشارة وتؤدي إلى إنهاء تنفيذ السكربت، لكن لماذا نهتم بذلك؟ لا يؤدي إنهاء السكربت عبر الإشارات في العديد من الحالات إلى مشاكل، لكنها تحتاج إلى معالجة في بعض الحالات. لننظر إلى مثالٍ آخر: #!/bin/bash # Program to print a text file with headers and footers TEMP_FILE=/tmp/printfile.txt pr $1 > $TEMP_FILE echo -n "Print file? [y/n]: " read if [ "$REPLY" = "y" ]; then lpr $TEMP_FILE fi يُعالِج السكربت السابق ملفًا نصيًا مُمَرَّرًا كوسيط في سطر الأوامر عبر الأمر pr الذي يُخزِّن الناتج في ملف مؤقت (temporary file)، ثم سيسأل المستخدم عمّا إذا كان يريد طباعة الملف، فلو وافق المستخدم عبر كتابة y فسيُمرَّر الملف المؤقت إلى الأمر lpr للطباعة (يمكنك وضع الأمر less بدلًا من lpr إذا لم تكن لديك طابعة موصولة بحاسوبك). عليّ أن أعترف لك أنَّ السكربت السابق فيه العديد من المشاكل التصميمية؛ وعلى الرغم من استخدامه لاسم الملف المُمرَّر عبر سطر الأوامر، لكنه لا يتحقق أنَّ القيمة فارغة، ولا يتحقق إن كان الملف موجودًا فعلًا. لكن الفكرة التي أريد التركيز عليها هي أنَّه عندما ينتهي تنفيذ السكربت، فسيُبقي خلفه ملفًا مؤقتًا. من المستحسن أن نحذف الملف المؤقت ‎$TEMP_FILE عند انتهاء تنفيذ السكربت، ويتم هذا بسهولة بإضافة السطر الآتي في نهاية السكربت: rm $TEMP_FILE قد تظن أننا حللنا المشكلة، لكن ماذا سيحدث لو ضغط المستخدم على Ctrl+c عندما تظهر الرسالة "Print file? [y/n]:‎" سينتهي تنفيذ السكربت عند الأمر read ولن يُنفَّذ الأمر rm أبدًا. سنحتاج إذًا إلى طريقة لمعالجة الإشارات مثل SIGINT عندما يضغط المستخدم على Ctrl+c. لحسن الحظ، توفِّر bash طريقةً لتنفيذ الأوامر فيما إذا استقبِلَت إشارةٌ ما. الأمر trap يسمح لك الأمر trap بتنفيذ أمر عندما يستقبل سكربتك إشارةً. يعمل هذا الأمر كالآتي: trap arg signals حيث signals هي قائمة بالإشارات التي تريد «اعتراضها» أو معالجتها، و arg هو الأمر التي سيُنفَّذ عندما تُستقبَل واحدة من الإشارات المُحدَّدة. يمكننا التعامل مع الإشارات في سكربت الطباعة السابق كما يلي: #!/bin/bash # Program to print a text file with headers and footers TEMP_FILE=/tmp/printfile.txt trap "rm $TEMP_FILE; exit" SIGHUP SIGINT SIGTERM pr $1 > $TEMP_FILE echo -n "Print file? [y/n]: " read if [ "$REPLY" = "y" ]; then lpr $TEMP_FILE fi rm $TEMP_FILE أضفنا الأمر trap الذي سيُنفِّذ الأمر rm $TEMP_FILE إذا استقبل السكربت إحدى الإشارات المذكورة، التي هي أكثر الإشارات التي ستواجهها، لكن هنالك المزيد منها التي تستطيع ذكرها أيضًا. انظر ناتج الأمر trap -l لرؤية القائمة الكاملة. يمكنك أيضًا ذكر الإشارات بأرقامها بدلًا من أسمائها. الإشارة 9 التي لا ترحم! هنالك إشارة لا تستطيع التعامل معها داخل السكربت: إشارة SIGKILL أو الإشارة رقم 9. ستُنهي النواة أيّ عملية تُرسَل لها هذه الإشارة مباشرةً دون العودة إلى البرنامج أو السماح له بإجراء أيّ عملية لمعالجة الإشارة. ولأنه هذه الإشارة تُنهي البرامج التي تُعلِّق أو لا تستجيب، فربما تظن أنَّها أسهل طريقة لإنهاء برنامج ما. وقد ترى الأمر الآتي عندما يأتي ذكر الإشارة SIGKILL: kill -9 وعلى الرغم من أنَّ هذه الإشارة تُتِمُّ عملها بسرعة وسهولة، لكن تذكَّر أنَّ البرنامج لن يستطيع معالجة هذه الإشارة، ولا بأس في ذلك في بعض الحالات؛ لكن قد يُسبِّب مشاكل في بعضها الآخر. حيث تُنشِئ بعض البرامج المعقدة (وحتى بعض البرامج غير المعقدة) ملفات اسمها lock files لمنع تشغيل عدِّة نسخ من نفس البرنامج في نفس الوقت. فعندما تُرسَل إشارة SIGKILL إلى برنامج يستخدم lock files، فلن يكون لديه فرصة لحذف ذاك الملف؛ وسيؤدي وجود ذاك الملف إلى منع تشغيل البرنامج إلى أن يُحذَف يدويًا. استعمل SIGKILL كملاذٍ أخيرٍ لك. دالة clean_up صحيحٌ أنَّ الأمر trap حلّ المشكلة، لكننا لاحظنا بعض المحدوديات؛ خصوصًا أنَّه لا يقبل إلا سلسلةً نصيةً وحيدةً تحتوي الأمر الذي سيُنفَّذ عندما تُستقبَل الإشارة. يمكنك الالتفاف على هذه المحدودية بوضع ; بين عدِّة أوامر، إلا أنَّ هذه الطريقة بشعة المظهر. فمن الأفضل إنشاء دالة ستُستدعى عندما ينتهي تنفيذ السكربت. أُسميّ هذه الدالة عادةً clean_up. #!/bin/bash # Program to print a text file with headers and footers TEMP_FILE=/tmp/printfile.txt clean_up() { # Perform program exit housekeeping rm $TEMP_FILE exit } trap clean_up SIGHUP SIGINT SIGTERM pr $1 > $TEMP_FILE echo -n "Print file? [y/n]: " read if [ "$REPLY" = "y" ]; then lpr $TEMP_FILE fi clean_up يمكن استعمال دالة clean_up في البُنى التي تهتم بمعالجة الأخطاء. فيجب على أيّة حال أن "تُنظِّف" ما خلّفه السكربت بعد انتهائه (لأي سببٍ كان). هذه هي النسخة النهائية من برنامجنا التي حسّنّا فيها معالجة الأخطاء والإشارات: #!/bin/bash # Program to print a text file with headers and footers # Usage: printfile file # Create a temporary file name that gives preference # to the user's local tmp directory and has a name # that is resistant to "temp race attacks" if [ -d "~/tmp" ]; then TEMP_DIR=~/tmp else TEMP_DIR=/tmp fi TEMP_FILE=$TEMP_DIR/printfile.$$.$RANDOM PROGNAME=$(basename $0) usage() { # Display usage message on standard error echo "Usage: $PROGNAME file" 1>&2 } clean_up() { # Perform program exit housekeeping # Optionally accepts an exit status rm -f $TEMP_FILE exit $1 } error_exit() { # Display error message and exit echo "${PROGNAME}: ${1:-"Unknown Error"}" 1>&2 clean_up 1 } trap clean_up SIGHUP SIGINT SIGTERM if [ $# != "1" ]; then usage error_exit "one file to print must be specified" fi if [ ! -f "$1" ]; then error_exit "file $1 cannot be read" fi pr $1 > $TEMP_FILE || error_exit "cannot format file" echo -n "Print file? [y/n]: " read if [ "$REPLY" = "y" ]; then lpr $TEMP_FILE || error_exit "cannot print file" fi clean_up الطريقة المثالية لإنشاء ملفات مؤقتة هنالك عدِّة إجراءات يمكننا اتخاذها لتأمين الملف المؤقت الذي استخدمه السكربت. من تقاليد نظام يونكس استخدام المجلد ‎/tmp لتخزين الملفات المؤقتة التي تستعملها البرامج. يمكن للجميع الكتابة إلى ذاك المجلد، وقد يُسبِّب ذلك لك بعض المخاوف الأمنية. تجنّب كتابة الملفات في مجلد ‎/tmp إن كان ذلك ممكنًا. التقنية المُستحسنة هي كتابة الملفات إلى مجلد محلي مثل ‎~/tmp (أي مجلد tmp الموجود في مجلد المنزل للمستخدم المُنفِّذ للسكربت)؛ وإن كان لا بُد، فعليك اتخاذ بعض الخطوات للتأكد أن أسماء الملفات المُخزَّنة في مجلد ‎‎/tmp غير متوقعة؛ حيث تسمح أسماء الملفات المتوقعة للمخترقين أن يُنشِئوا وصلات رمزية إلى ملفات أخرى التي يريدون منك أن تكتب فوقها. الاسم الجيد للملف المؤقت هو الاسم الذي يسمح لك بمعرفة مَن الذي كتب الملف، ولكنه ليس متوقعًا بشكلٍ كامل. استخدمنا السطر الآتي في السكربت أعلاه لإنشاء اسم الملف المؤقت ‎$TEMP_FILE: TEMP_FILE=$TEMP_DIR/printfile.$$.$RANDOM سيحتوي المتغير ‎$TEMP_DIR على ‎‎/tmp أو ‎~/tmp اعتمادًا على توفر المجلد ~/tmp، ومن الشائع تضمين اسم البرنامج في اسم الملف، وهذا هو سبب وضعنا للكلمة "printfile". ثم استخدمنا متغير الصَدَفة $$ لتضمين مُعرِّف العملية (PID) الخاص بالبرنامج. وهذا سيُحدِّد تمامًا ما هي العملية المسؤولة عن الملف. وبالطبع لا نستطيع أن نعتبر أنَّ رقم العملية كافٍ لجعل اسم الملف غير متوقع؛ لهذا أضفنا متغير الصَدَفة ‎$RANDOM لتضمين رقم عشوائي في اسم الملف. وبالآلية السابقة، أنشأنا اسمًا لملفٍ مؤقتٍ سهلُ التعرف وغير متوقع. خاتمة حسنًا، لقد أنهينا هذه السلسلة، أرجو أن تكون قد وجدتها مفيدةً ومسلية في آن واحد. وأنصحك بإكمال مسيرتك في سطر الأوامر وسكربتات الصَدَفة بقراءة كتاب سطر أوامر لينُكس لمترجمه عبد اللطيف ايمش. ترجمة -وبتصرّف- للمقالين Errors And Signals And Traps (Oh My!) - Part 1 و Errors And Signals And Traps (Oh, My!) - Part 2 لصاحبهما William Shotts.

تؤكد البيانات أن سوء الإدارة قضية حقيقية وهامة، فحسب دراسة لمؤسسة Gallup فإن واحدًا من كلّ اثنيْن تركا العمل اعترف بأنه فعل ذلك للفرار من مدير سيء. في الواقع، %70 من العوامل التي تساهم في سعادة الموظَّف في العمل مرتبطة مباشرةً بمديرك. ورغم ذلك فمديرون قلّة يطرحون على أنفسهم ذلك السؤال الصعب: هل أنا حقا سبب في رحيل الأشخاص من الشركة؟ وهل كان ذلك بسبب شيء اقترفته، أم بسبب شيء فاتني أن أقوم به؟ أستطيع القول، من خبرتي الخاصة، أن المديرين يعانون من شيء ما شبيه بتأثير دانينغ-كروجر Dunning-Kruger effect، فهم يفترضون أن المشكلة ليست فيهم إنما في موظفيهم. ما عليك إلا أن تلقي نظرة على البيانات لترى لمن يوجه المدراء اللوم. أظهر استطلاع للرأي على عيّنة شملت 5247 مديرا وظّفوا أكثر من 20 ألف شخص أن هؤلاء المديرين يرون - بعد مرور 18 شهرا على التوظيف - أن 46% من الموظفين الجُدد أخفقوا في عملهم، بينما نجح 20% فقط. بالنسبة لأسباب الإخفاق فهي - حسب المديرين - على النحو التالي: القابليّة للتعلّم: 26%. الذكاء العاطفي: 23%. انعدام الحافز: 17%. المزاج: 16%. الكفاءة العملية (التقنية): 11%. وما أهم ما تعلمه المديرون الذين شاركوا في الاستطلاع؟ أنهم كانوا بحاجة لطريقة أفضل في إجراء مقابلات التوظيف ليقتلعوا الفشل قبل وصوله إلى فريقهم! بالنسبة لأي انسان عاقل فلن يكون لهذا الكلام (الخلاصة) أي معنى. فالقاسم المشترك ليس 46% من الموظفين، بل المدير. هل كانت المشكلة حقا أن نصف الأشخاص لم يكن بمقدورهم تعلم وظيفتهم أو الاهتمام بها؟ أم أن أولئك المديرين، الأقل عددا بكثير، قد بالغوا في تقدير قدراتهم في تعليم ودمج وإلهام موظفيهم الجدد؟ لقد قدت فرقا من المهندسين لعقد تقريبا، وعندما أنظر إلى مسيرتي المهنية في الإدارة أكتشف أني كنت أفكر باستمرار أني “مدير جيد”، بل وعظيم أحيانا. كنتُ أنسب كل المشاكل التي واجهتها إلى الناس الذين كانوا تحت إمرتي وليس لنفسي. وبإعادة النظر الآن أجد أنه من الواضح أني كنت حقيقةً مديرًا غِرًّا وساذجًا جدا، مفرطًا في الثقة وغير ماهر بالقدر الكافي. كنت ذلك المدير الذي يرتكب أخطاء كثيرة. هذا الإفراط في الثقة في طريقة الإدارة إنما هو فخ أرى كثيرين يسقطون فيه، ولكن لحسن الحظ يمكن تجنب ذلك الفخ باتباع بعض الخطوات المشروحة أدناه. واظب على طلب النصيحة يعرف مهندس البرمجيّات أنه يحتاج، مهما كانت خبرته، لمن يراجع شفرته البرمجيّة قبل نشرها في بيئة إنتاج. المخاطرة بنشر تعديلات غير مُراجعة لا تحدث إلا في حالة الطوارئ القصوى. بالمثل؛ على الأشخاص الذين يمارسون الإدارة أن يطلبوا من الأقران رأيهم في المشاكل التي تواجههم في إدارة الأشخاص، قبل اتخاذ أي قرار؛ سواء تعلق الطلب بمديريهم المباشرين، مديرية الموارد البشرية أو غيرهما. وكلما كانت العواقب المحتملة لإجرائك أكبر زاد اجتهادك وإصرارك في طلب الحصول على المساعدة ومراجعة الأقران قبل القيام به. شخصيًا، أناقش تقييم أداء الموظّف مع أقراني ورئيسي قبل تسليمه؛ وإن حدث ووجدت أن في فريقي أفرادًا لا يؤدون أعمالهم على نحو حسن، فإني أطلب المساعدة في كيفية تدريبهم بطريقة مختلفة. يمكنك حتى فعل ذلك في جميع الأمور تقريبا. سواء كانوا أشخاصًا ذوي صلة أو لا، فسوف تحصل على نتائج أفضل في النهاية. بمجرد اعتقادك أنك حقًا أتقنت مهاراتك الإدارية فإنك حينئذ معرض بدرجة كبيرة كبير للإخفاق. لا تلق اللوم، تحمّل المسؤولية المشاركة في المسؤولية هو أحد قيم فريق الهندسة لدينا ويُطبَّق أيضا لإدارة الأشخاص تماما كما يُطبَّق في مجال الهندسة. ليس من ثقافتنا أن تقول “تلك ليست مشكلتي” أو أن تقول ” ليس هذا خطئي”. لا أيسر للمدير من التبرأ من المسؤولية ولوم شخص في الجهة المقابلة من الطاولة إذا لم يؤدّ عمله على النحو الذي يرضيك. الواقع أن كل شخص من مرؤوسيك منفرد ومختلف عن الآخرين. إذا لم يؤت أسلوب إدارة ثماره مع الشخص الجالس أمامك، رغم أن هذا الأسلوب نجح مع ثلاثة فرق عمل سابقة فهذا فليس معناه بالضرورة أن ذلك خطؤه. يمكن النظر إلى المديرين كما يُنظَر إلى مدربي الفرق الرياضية الجيدين؛ إذ أن الحكم على المدرب لا يكون على أساس أداء لاعبي فريقه كل على حدة، ولكن من خلال مجهود الفريق بأكمله. بالمثل فإن المسؤولية تقع على عاتقك لتتأكد أن أسلوب الإدارة المستخدم مع مرؤوسيك هو الأسلوب الأمثل لهم. يجب عليَّ مراجعة نفسي على الدوام لأتأكد أني أتحمل قدرا من المسؤولية يبقي على العلاقات داخل الفريق جيدة؛ كما أساعد بفعل كل ما أستطيع القيام به لجعل الأمور أفضل. وبدلا من إلقاء اللوم على الآخرين عندما تسوء الأمور، فإني أحاول أن أستكشف دوري في هذا الوضع: ما هي الأشياء التي فعلتها وما هي الأشياء التي لم أفعلها والتي ساهمت جميعها في المشكلة التي أمامنا؟ إن وجدت أي مشكلة في تحديد تلك النقاط، فإني أرجع للوراء للخطوة الأولى أعلاه. وأطلب النصيحة من أقراني.. وفي أحيان كثيرة، فإني بعد ممارسة ذلك التمرين أكتشف ان الخطوة السليمة التالية ليست إعطاء”ردود ارتجاعية بناءة” لأحد أفراد فريقي عن أخطاءه، ولكن الخطوة السليمة التالية يجب أن تكون الحصول على رد ارتجاعي عن كيفية دعمهم على نحو أفضل في المستقبل. كن متعاطفا في ردودك الارتجاعية أكثر أداة فاعليةً لتنمية العاملين تحت إمرتك وتطوير فريقك هي الردود الارتجاعية؛ إلا أنها من أصعب الأمور انجازًا على نحو سليم. تسبّب الردود الارتجاعية إذا ما استخدمت على نحو خاطئ في تأثير ضار ملازم غير مرغوب فيه إطلاقا. أنتظر دائما وقتا قبل تسليم ردي الارتجاعي حتى أفهم كيف يُحتَمل أن يتلقى الشخص الآخر ذلك الرد. هل من الممكن أن أرى في الأرجاء مصافحات حماسية للتهنئة؟ أم أن الموظف سيشعر بالألم والانزعاج؟ حاول أن تولي عناية خاصة بالآثار العامة المترتبة على الرد الارتجاعي الذي تقدمه. الرد الارتجاعي الصريح يمكنه أن يكون محفزًا للمهندس المحنك الذي يرنو بعينيه لخطوة أعلى توصله للمستوى التالي، ولكنه في الوقت ذاته عقبة في طريق الموظف الغِر والذي يجد صعوبة في الاستقرار. . استعمل الذكاء العاطفي والتعاطف. و يمكنك دائما إرجاء ردك الارتجاعي لوقت آخر ولوضع أكثر خصوصية أو أقل توترا. تذوق طعم نجاحك أحد أفضل الاشياء بخصوص كونك مهندسا في شركة ناشئة هو حلقات الرد الارتجاعي. يمكنك أن تبني أولوياتك وتصمم وتبني وتنقل السلع لأيدي المستخدمين. كل ذلك خلال أسبوع وربما يوم أو يومين على الأكثر. وحلقات الرد الارتجاعي تلك هي وقود لمعنويات فريقك، ولها تأثير إيجابي في إنتاجيّته كما أنها تُمدّ كل عضو في الفريق بالسعادة والرضا عن الوظيفة. لسوء الحظ فإنه من السهل بالنسبة للمدير أن ينغمس وحده طوال الوقت في التطلع للمستقبل، خصوصا بالتركيز على المشاكل. عندما تقوم بذلك فإن مناعة فريقك ستضعُف إذ سيشعر أعضاءه بعدم التقدير وأنهم مجرّد موظّفين عاديين لا أهمية لهم. تأكد من الاحتفال بنجاح فريقك وتأكد أن أعضاء فريقك يعلمون أنهم مؤثرون. ليس من الضروري أن تعلق الرايات في السقف ويمكن ان يكون ذلك الاحتفال من البساطة بمكان، كإعطاء أحدهم ردًّا ارتجاعيًّا مفصلًا في أمر قد أداه تماما على نحو جيد ، أو تمرير بعض الردود الارتجاعية الايجابية والتي تلقيتها من رئيسك عن عمل حديث قام به فريقك، أو الحديث إيجابيا عن عمل أحدهم على منصة التواصل داخل الشركة. المدير العظيم يُشيِّد شركات عظيمة عندما تستمر في التواضع، طلب النصيحة، تحمّل المسئولية بدلا من اللوم وتقديم ردود ارتجاعية متعاطفة فأنت على النهج السليم لتكون مديرًا جيّدًا. لكن، كما رأينا، النجاح في الإدارة يولّد الرضا، وهو ما يجعل الوقوع في فخ العادات السيئة كالغرور أو الثقة المفرطة أمرا سهلا. بمجرد إحساسك أنك أحكمت مهاراتك في الإدارة تكون على شفا التعرض للإخفاق. أنت في حاجة مستمرة لتكرار مراجعتك لما يلزمك لتكون مديرا جيدا، وإلا فأنت تخاطر بفقد أفضل الأفراد العاملين تحت إمرتك للأبد. ترجمة - بتصرف - لمقال People leave managers, not companies. Don’t let that manager be you لصاحبه Rich Archbold. حقوق الصورة البارزة محفوظة لـ Freepik

يسعى جميع العاملين في المشاريع التّجاريّة إلى تقديم تجربة دعمٍ فنّي ممتازة للعملاء. فنحن نبذل كلّ ما في وسعنا طوال الوقت لتقديم أفضل خدمةٍ ممكنة، كما نمضي إلى أبعد ما يمكن لنسعد العملاء، ومع ذلك، لا تزال هنالك تعليقاتٌ سلبيّة وشكاوى نتلقّاها من العملاء. لكن ربّما كانت المشاكل التي تعاني منها بسيطة حقًا، وقد يؤدّي التّخلّص من هذه المشاكل إلى زيادة رضا العملاء بسهولة. إليك سبعة أخطاء قاتلة في تجربة الدّعم الفنّي، وأتمنّى أن لا تقوم بها. 1. قلة التدريب / عدم معرفة المنتج بشكل دقيق يهدف الدّعم الفنّي إلى حلّ مشاكل العملاء. لن يتّصل العملاء بك لإجراء دردشة معك أو لمجاملة الشّركة، فلدى كلّ عميلٍ منهم مشكلة، ولا يهمّ إذا كانت المشكلة معقّدة أم لا، ينبغي أن يكون الفريق مستعدًا لحلّها بأسرع وقتٍ ممكن. إنّ أهمّ جزءٍ في التّدريب على الدّعم الفنّي هو التدريب على المنتَج أو الخدمة. يجب أن يعرف الموظّفون كلّ شيءٍ عن المنتجات. لا يمكن أن نتخيّل موظّف مبيعات في شركة Apple مثلًا لا يعرف الفرق بين iPhone 6 و iPhone 6s. ويُعَدّ التّدريب على المهارات الشخصيّة أمرًا مهمًا أيضًا، حيث يجب أن يتعلّم معظم الموظّفين كيف يتصرّفون في المواقف التي تكون عصيبةُ أحيانًا، لكن قد يخفق أكثر الأشخاص تعاطفًا ورعاية في مساعدة العميل إذا لم يكن قد تدرّب على المُنتَج بشكلٍ مناسب. 2. تحويل الموظف إلى إنسان آلي إنّ التحدّث مع موظّفٍ يتكلّم بنبرة إنسانٍ آلي من الأشياء التي أكرهها كثيرًا. وكأنّ البعض يعتقد بأن وجود المشاعر البشريّة في الحديث أمرٌ غير مناسب في الدّعم الفنّي. حيث يبدو الموظّف وكأنّه يقرأ نصوصًا مكتوبة جاهزة، وربّما يفعل ذلك فعلًا، ويبدو آليًا/رسميًا إلى نحو كبير بشكلٍ يجعلني أرغب في قطع الاتّصال على الفور. يجب على كلّ موظّفٍ في الدّعم الفني أن يكون قادرًا على التكيّف مع الطّريقة التي يتحدّث بها العملاء. إذا كان العميل يتحدّث بشكلٍ رسمي، فيجب أن يتحدّث الموظّف إليه بشكلٍ رسمي. وإذا كان العميل يلقي النّكات، فيجب أن يطلق الموظّف العنان لحسّ الفكاهة لديه. فالنّقاش البشري الطّبيعي أمرٌ مستحب في الدّعم الفنّي، ويساعد في إجراء التّواصل الحقيقي، كما يجعل تجربة الدّعم الفنّي إيجابيّة. 3. المجيب الآلي على الهاتف بما أنّنا تحدّثنا عن الإنسان الآلي، فليس هنالك شيءٌ أكثر إزعاجًا من الاتّصال بالدّعم الفنّي وأن يجيب نظام المجيب الآلي IVR. فأنا أفقد صبري على الفور حين أضغط على الأزرار محاولًا الوصول إلى الوجهة المطلوبة، ولا أعلم أين أنا في المتاهة الافتراضيّة. كما أنّ موسيقى وضعيّة "الانتظار" الرّهيبة سببٌ آخر يجعل هذا النّظام سيّئًا للغاية. في معظم الأحيان تكون الموسيقى سيّئة فعلًا، وحتّى إذا لم تكن سيّئة، فإنّ جودة الصّوت تجعلها أسوأ. باختصار، لا تستخدم نظام المجيب الآلي أبدًا، فأقلّ الموظّفين كفاءةً أفضل بكثيرٍ من نظام IVR. 4. عدم حل المشاكل بالشكل المناسب مهما كان منتجك رائعًا ومهما كنت تركّز على العملاء، فإنّك سوف تتلقّى شكاوى من العملاء. وكلّما أسرعت في اتّخاذ إجراءٍ لحلّ المشاكل في فريق الدّعم، كان ذلك أفضل. أهمّ شيءٍ هو أنّ العملاء الذين تمّ حلّ شكواهم بشكلٍ مناسب يمكن أن يوصوا بمُنتجاتك وأن يبقوا عملاء مخلصين لك. بالإضافة إلى أنّك حين تتعامل مع كلّ شكوى على أنّها فرصةٌ للتعلّم، يمكنك تحسين خدمتك وإثبات أنّك مهتمٌّ بما تفعله للعملاء. 5. عدم التواجد على الشبكات الاجتماعية يُعَدّ عدم التّواجد على الشّبكات الاجتماعيّة من الأخطاء الرّهيبة، لأنّك بذلك لا تكون موجودًا حيث يتواجد العملاء. والأمر ببساطة أنّه يُفترض أن يساعد فريق الدّعم الفنّي العملاء. والانضمام إلى القنوات نفسها التي يتواجدون عليها هو أفضل طريقةٍ لتريهم أنّك تحبّ المساعدة. إليك ما قاله Mick Griffin الذي يعمل في Brand24 في حلقة من حلقات Business Sidekick: 6. عدم الاستجابة على الشبكات الاجتماعية إنّ التّواجد على الشّبكات الاجتماعيّة أمرٌ جوهريّ، ويجب عليك أيضًا أن تردّ على جميع التّعليقات على الشّبكات الاجتماعيّة دائمًا، ولا سيّما إذا كانت التّعليقات سلبيّة. قد تتساءل، لماذا عليك الاهتمام بالأشخاص الذين يتركون تعليقاتٍ سلبيّة على الشّبكات الاجتماعيّة؟ والجّواب هو أنّ الشّبكات الاجتماعيّة علنيّة. وعندما يكتب أحدٌ شيئًا سيئًا عن منتجك أو الخدمة التي تقدّمها، فيمكن أن يراها كلّ الجّمهور على الشّبكات الاجتماعيّة. ويحكم النّاس عليك بناءً على عدّة معايير وهي سرعة استجابتك، وردّ فعلك، وردّ فعل العملاء، وكيف انتهى الأمر كلّه. وقد تحصل على الكثير من المراجعات السلبيّة إذا أخفقت في الرّد. 7. نسيان المبادئ الأساسية الدّعم الفنّي عملٌ صعب، فهنالك الكثير من التّدريب، والعمليّات والكُتَيّبات، والمهام اليوميّة، بالإضافة إلى الكثير من الأشياء التي يجب عليك فعلها وتذكّرها. ومن الطّبيعي أن تنسى سعر مُنتج ما، أو تنسى فيما إذا كانت ميّزةٌ معيّنة ضمن الخطّة ولا بأس بذلك، لكنّ هنالك شيءٌ لا يمكنك نسيانه، ألا وهو أنّ الدّعم الفنّي يتعلّق بالتّواصل الإيجابي. لا يمكنك نسيان "صباح الخير"، "شكرًا لك"، و "من فضلك"، ولا يمكنك نسيان الإصغاء الإيجابي. لا يمكنك أن تتحدّث مع العملاء أثناء تناولك الطّعام، أو إرسالك رسالةً نصيّة، أو طلاء أظافرك. لا يمكنك الصّراخ في وجههم أو مجادلتهم. ورغم أنّ ذلك يبدو بسيطًا، إلّا أنّ عدد الموظّفين الذين ينسون هذه القواعد البسيطة لا يُصَدّق. لا تكن موظف دعم فني سيئ إذا كنت قارئًا نهمًا لمقالات وكُتب الدّعم الفنّي، فلا بدّ أنّك تعرف سهولة تحوّل الشّركة إلى "شركة لا تقدّم الدّعم الفنّي" وأن تكسب شهرةً أبديّة بوصفها شركة تقدّم تجربةً فظيعة للعملاء. أعتقد أنّك لا تهدف إلى ذلك، لذا تعامل مع الأخطاء القاتلة التي أوردتها كمرجعيّةٍ لك في الدّعم الفنّي. كلّما حرصت على أن لا يضطرّ العملاء للتّعامل مع هذه المشاكل، كلّما اقتربت من الهدف الذي تسعى إليه في الدّعم الفنّي، ألا وهو تجربة رائعة في الدّعم الفنّي. ترجمة -وبتصرّف- للمقال Seven Deadly Sins of Customer Service Experience لصاحبته JUSTYNA POLACZYK.

هذه هي الأخطاء (أو الخطايا) التي يتجنّبها المؤسّسون النّاجحون، والتي عليك تجنّبها أيضًا. لقد لاحظت أنّ الأشخاص الذين أحاول الاقتداء بهم يحاولون بذل كلّ ما في وسعهم لتجنّب أنواع السّلوكيات التي أعتبرها أخطاء قاتلة، كما أنّ روّاد الأعمال النّاجحين يتّبعون ويشاركون العديد من العادات الإيجابيّة. أودّ اليوم أن أشارك معكم الأخطاء القاتلة السّبعة في ريادة الأعمال. وتتحمّل أنت مسؤوليّة ارتكابك لهذه الأخطاء. 1. فقدان التركيز تظهر يوميًا منشورات جديدة في المدوّنات عن "الشّيء الوحيد الذي يجب أن تفعله لتنمية شركتك"، وما شابه ذلك. لكنّ المشكلة هي أنّك قد تجد 100 "شيء وحيد" مختلف في 100 من هذه المنشورات. لا بدّ من أنّني أرتكب الخطأ نفسه. فنحن نشارك دائمًا "عددًا من الأشياء" التي وجدناها ناجحة في أمر محدّد. لكنّني أحاول دائمًا الحدّ من هذه الخلاصات، محذّرًا من أنّها قد لا تكون مناسبة لك، وأنّ عليك أن تكون حذرًا جدًا بشأن ما تحاول تنفيذ هذه الأشياء عليه. يدرك المؤسّسون النّاجحون أنّ محاولة اتّباع التّكتيكات طريقة مؤكّدة لتشتيتك وإبعادك عن مسار أهدافك في الصّورة الأكبر. لا تُسئ فهم الموضوع، أنا لا أقول أنّه لا ينبغي أن تجرّب أشياء جديدة وتختبر أساليب مختلفة لمواجهة تحدّيات النّمو. فهذه في النّهاية هي الطّريقة الوحيدة لتحديد ما هو فعّالٌ حقًا. لكنّ موجة منشورات النّصائح التّكتيكيّة التي نواجهها قد أحدثت ثقافة تجربة مليون شيءٍ صغير دفعةً واحدة، دون تنفيذ شيءٍ واحد على أكمل وجه. لذلك فمن الضّروري جدًا أن تكون لديك خطّة، وأن تركّز على هذه الخطّة بدقّةٍ متناهية. ضع أهدافًا قصيرة المدى بما يكفي لتتمكّن من إعادة التّقييم وإعادة التّنظيم كلّ بضعة أشهر أو نحو ذلك، لكن حافظ على تركيزك خلال هذه الفترات. إذا لم يكن الأمر مُخطّطًا له فإنّه لن يحدث. 2. افتراض أنك تعلم ما هو الأفضل عندما أطلقنا موقع Groove منذ سنوات، قمنا بإنشاء المنتَج وموقعنا، بناءً على فرضيّات أنّنا على درايةٍ بالسّوق الذي نستهدفه. لكن بعد أن أنفقنا حوالي $50,000، انتهى بنا المطاف بإنشاء تطبيقٍ ضخم يحتوي على جميع الميّزات التي اعتقدنا أنّ المستخدمين يريدونها، لكنّه في الحقيقة لم يتماشى مع احتياجات السّوق على الإطلاق، ومع المُحتوى التّسويقي الذي يجب أن يتطابق معه. عندما لم نكن نلقى القبول الذي نريده، كنا نبحث ونقضي مئات السّاعات في التحدّث مع مستخدمينا والعملاء المتوقّعين لمعرفة السّبب، وتخلّصنا من كامل ما بنيناه من الأساس وبدأنا مجدّدًا، وركّزنا هذه المرّة على بناء أبسط برنامج دعم فني يمكننا بناؤه، مدفوعين بالأشياء التي أصبحنا نعرف أنّها تهمّ حقًا، مقابل الأشياء التي اعتقدنا أنّها تهمّ. وعندئذٍ تغيّر كلّ شيءٍ بالنّسبة لنا، ولا زلت أنظر إلى ما أسّسناه في البداية على أنّه ربّما يكون أكبر خطأ ارتكبناه على الإطلاق. لا يعمل روّاد الأعمال العظماء بناءً على الافتراضات، بل يعملون بناءً على فهمٍ عميق للغاية لعملائهم. 3. التفكير من منظور ضيق إنّ مجتمع الشّركات التّقنيّة النّاشئة مجتمعٌ مترابط. فمن ناحية، أعتقد أنّ ذلك أمرٌ جيّدٌ جدًا، لأنّ بناء شركة ناشئة أمرٌ صعب، ودعم الأفراد لبعضهم البعض مفيدٌ للغاية. وقد منحني هذا المجتمع الكثير من التّعليقات الرّائعة والعلاقات والفرص. لكن في نفس الوقت، فإنّ وجودك في مثل هذه المجموعة الصّغيرة قد يغيّر طريقة تفكيرك. وقد رأيت الكثير من روّاد الأعمال الذين لا يستطيعون التطلّع إلى ما هو أبعد من الشّركات النّاشئة التي تقدّم البرمجيّات الخدميّة SaaS كعملاء محتملين، لسببين: 1. لأنّ ذلك هو كلّ ما يرونه حولهم 2. لأنّ هذه هي طبيعتهم (يعني يقدّمون فعلًا خدمات لشركات ناشئة أخرى) ولكنّ هذا المجتمع يشكّل جزءًا صغيرًا جدًا من الشّركات الموجودة. أن تبيع منتَجًا للشّركات النّاشئة لأنّك طوّرت منتجًا يستهدف الشّركات النّاشئة، يختلف عن بيعه إلى شركات ناشئة لأنّها تشكّل السّوق الوحيد الذي تراه، لأنّ ذلك يضع سقفًا غير مرئي لنموّك، حيث ستواجه صعوبات جمّة لتجاوز هذا السّقف إذا لم تخرج وتستكشف الأسواق الأخرى. إنّ معظم الشّركات النّاشئة النّاجحة التي نعجب بها لا تحقّق الجّزء الأكبر من إيراداتها من شّركات نّاشئة أخرى، وذلك لأنّ المال لا يأتي من هنا. 4. الشلل التحليلي يقضي النّاس الذين يعملون في الشّركات في جميع أنحاء العالم وقتًا طويلًا جدًا كلّ يوم في اتّخاذ القرارات الكبيرة والصّغيرة. وينطبق الأمر بشكلٍ خاص على الشّركات النّاشئة، حيث نؤسّس كلّ شيءٍ من الصّفر. ومع الشّعور بالتملّك الذي يرافق ذلك، نشعر بحاجةٍ لجعل كلّ جزءٍ من العمل مثاليًا. لسوء الحظ فإنّ ذلك يُلحِق ضررًا كبيرًا بنا. وذلك درسٌ سبب لي ألمًا لأنّني لم أتعلّمه مبكّرًا. لكن بمرور الوقت، استوعبت هذا الدّرس جيّدًا، وتوصّلت إلى نفس النّتيجة التي توصّل إليها Mark Susler والذي شرح الأمر بشكلٍ جيّد عندما قال: يدرس روّاد الأعمال العظماء الأمور جيّدًا، لكنّهم لا يسمحون للتّحليل بإبطاء أعمالهم. 5. تجنب الانزعاج أتحدّث إلى أشخاص يريدون أن يسعوا وراء فكرة شركتهم النّاشئة، إلّا أنّهم لا يفعلون ذلك. ويقولون أنّهم يخشون الفشل. لكنّني لست واثقًا أنّ ما يخيفهم هو الفشل، وإنّما الانزعاج. وهو الانزعاج الذي تشعر به عند قولك للنّاس أنّك قد فشلت. أو من معرفتك لذلك، أو من سماع كلمة "لا"، أو من تقبّل حقيقة أنّ الأمور لم تصبح كما أردتها. يبدو الاختلاف سخيفًا، إلا أنّني أعتقد أنّه مهمٌ فعلًا. لأنّ تقبّل الشّعور بالانزعاج أسهل بكثيرٍ من تقبّل الفشل. يؤدّي تجنّب الشّعور بالانزعاج إلى الحفاظ على الموظّفين السيّئين في الفريق، وضياع الفرص من جميع الأحجام، وتوقّف النّمو بشكلٍ مفاجئ، وخمول الشّركات في نهاية المطاف. 6. عدم الاعتناء بنفسك لقد تحدّثت إلى عددٍ لا يحصى من المؤسّسين في الأربعينيات والخمسينيات والستّينيات من أعمارهم والذين يتمنّون لو أنّهم قد اعتنوا بأنفسهم بشكلٍ أفضل حين كانوا في العشرينيات والثّلاثينيات من أعمارهم. وذلك أمرٌ أخشاه للغاية، لأنّني قد أكون مهووسًا على غرار معظم المؤسّسين الذين أعرفهم. لا يعني ذلك أنّني مهووسٌ بالعمل "60 ساعة في الأسبوع"، وإنّما مهووسٌ لدرجة أقول فيها "نسيت أن أتناول الطّعام، وأنام، وأعبّر عن تقديري للنّاس الذين يحيطون بي". يجب عليّ بذل جهدٍ كبير لئلا أعمل كثيرًا. وبالرّغم من أنّني لست مثاليًا، إلّا أنّني أبذل هذا الجّهد من أجل صحّتي. فعندما يكون المؤسّس بصحّةٍ سيّئة، فإنّه يُلحِق الضّرر بموظّفيه، وعملائه، وشركته ونفسه. لا تنس أن تتناول طعامًا صحيًا، كن نشطًا، وخذ إجازة بين الحين والآخر. 7. عدم الاستثمار في ثقافة الشركة قضينا الكثير من الوقت وبذلنا الكثير من الطّاقة ونحن نحاول تأسيس بيئة فريقنا الذي يعمل عن بعد. وذلك لأنّ روّاد الأعمال الذين أثق بهم كثيرًا حذّروني من الأخطار الكبيرة لعدم الاستثمار في ثقافة الشّركة، وليس لأنّني أعرف بالفطرة أنّه أمرٌ مهم. حيث يقول David Hauser: لا يمكن أن يكون الوقت مبكّرًا أبدًا للاستثمار في بناء ثقافة قويّة، ولا يفوت الأوان أبدًا (تقريبًا) على تصحيح مسار المشروع. كيف تطبق ذلك على مشروعك يهدف نشر هذه الأخطاء السّبعة إلى تجنّبها. ومن خلال شرح الأخطاء، أتمنّى أن أكون قد ساعدتك على تحديد الأخطاء التي يمكنك أن تتوقّف عن فعلها اليوم، وقد يكون لذلك تأثيرٌ كبير على عملك، بغضّ النّظر عن المكان الذي وصلت إليه في رحلة شركتك النّاشئة. ترجمة -وبتصرّف- للمقال The 7 Deadly Sins of Entrepreneurship لصاحبه Alex Turnbull. حقوق الصورة البارزة: Designed by Freepik.

لا تخلو أيّ لغة برمجة محترمة من وسيلة لمعالجة الأخطاء. تحتوي لغة سي شارب على آليّة قويّة لمعالجة الأخطاء. تشبه هذه الآلية إلى حدّ ما تلك المستخدمة في لغة Java. هناك نوعان أساسيّان من الأخطاء التي قد تنتج عن البرنامج: النوع الأوّل هي أخطاء أثناء التصميم، أي أثناء كتابة الشيفرة، وهي أخطاء يمكن اكتشافها بسهولة من خلال مترجم سي شارب الذي يتعرّف عليها ويعطيك وصفًا عنها، وقد يزوّدك أيضًا ببعض المقترحات للتخلّص منها. بالنسبة للنوع الثاني من الأخطاء فهي التي تنتج أثناء تنفيذ البرنامج runtime errors. توجد الكثير من الأسباب لحدوث مثل هذه الأخطاء. فمن القسمة على صفر إلى القراءة من ملف غير موجود أو حتى استخدام متغيّر مصرّح على أنّه من نوع مرجعيّ ولكن لم تتم تهيئته بعد بمرجع إلى كائن. عند حدوث مثل هذه الأخطاء ترمي بيئة التنفيذ المشتركة CLR استثناءً exception يحتوي على معلومات بخصوص الخطأ الذي حدث، فإذا كنت مستعدًّا لالتقاط هذا الاستثناء فستنجو، وإلّا سيتوقّف برنامجك عن العمل بصورة مفاجئة. التقاط استثناء من خلال عبارة try-catch إذا صادفتك عبارة برمجيّة تحتوي على عمليّة حسابيّة أو على استدعاء لتابع آخر، أو أيّ شيء قد يثير الريبة في نفسك، فمن الممكن مراقبتها أثناء تنفيذ البرنامج باستخدام عبارة try-catch. تتألّف هذه العبارة من قسمين: القسم الأوّل هو قسم المراقبة try، والقسم الثاني هو قسم الالتقاط catch. الشكل "الأبسط" لهذه العبارة هو التالي: try { //عبارة برمجيّة مريبة } catch(Exception exp) { //هنا يُلتقط الاستثناء وتتمّ معالجته } يمكن أن يحوي قسم try على عبارات برمجيّة بقدر ما ترغب. عندما يصادف البرنامج أثناء التنفيذ خطأً ما، سيتوقّف التنفيذ عند العبارة التي سبّبت الخطأ، ثم ينتقل فورًا إلى قسم الالتقاط catch. لاحظ معي أنّ قسم catch سيُمرَّر إليه وسيط من الصنف Exception. الصنف Exception موجود ضمن نطاق الاسم System، وهو الصنف الأب لجميع الاستثناءات. إذ أنّ أي استثناء مهما كانت صفته (بما فيها الاستثناءات التي يمكنك أن تكتبها أنت) يجب أن ترث من هذا الصنف. بعد حدوث الاستثناء والانتقال إلى قسم catch، سيحتوي الوسيط exp على معلومات حول مكان حدوث الاستثناء وسبب حدوثه، وغيرها من المعلومات التي قد تكون مفيدة لمستخدم البرنامج. تجدر الملاحظة بأنّ البرنامج لن يدخل إلى القسم catch أبدًا ما لم يحدث استثناء ضمن القسم try. لنرى الآن البرنامج Lesson16_01 الذي سيعرّفنا على الاستثناءات بشكل عمليّ. يحتوي هذا البرنامج البسيط على عبارة try-catch وحيدة سنعمل من خلالها على توليد خطأ بشكل مقصود أثناء التنفيذ، وسنتعلّم كيفيّة المعالجة. 1 using System; 2 3 namespace Lesson16_01 4 { 5 class Program 6 { 7 static void Main(string[] args) 8 { 9 int x = 5; 10 int y = 0; 11 int result; 12 13 try 14 { 15 result = x / y; 16 } 17 catch(Exception exp) 18 { 19 Console.WriteLine("The following error has occurred:"); 20 Console.WriteLine(exp.Message); 21 } 22 23 Console.WriteLine("Good Bye!"); 24 } 25 } 26 } من الواضح أنّ هذا البرنامج يتجّه لأن يجري عمليّة قسمة على صفر في السطر 15 ضمن القسم try. عند وصول البرنامج إلى السطر 15 وإجراء عمليّة القسمة هذه، سيتولّد استثناء يؤدّي إلى انتقال التنفيذ مباشرةً إلى قسم catch في السطر 17. في قسم catch يعرض البرنامج معلومات عن هذا الخطأ باستخدام الخاصيّة Message لكائن الحدث exp. في النهاية يعرض البرنامج في السطر 23 رسالة توديعيّة للمستخدم. نفّذ البرنامج لتحصل على الخرج التالي: The following error has occurred: Attempted to divide by zero. Good Bye! جرّب الآن تغيير قيمة المتغيّر y لتصبح 1 مثلًا وأعد تنفيذ البرنامج. ستلاحظ ظهور الرسالة التوديعيّة فقط على الشاشة، أي أنّه لم يحدث أي استثناء هذه المرّة. على كلّ الأحوال لا ينصح باستخدام معالجة الاستثناءات من أجل حالة القسمة على صفر في البرنامج السابق. ملاحظة: في الواقع يمكن الاستغناء عن الوسيط الذي يمرّر إلى قسم catch بشكل كامل، وفي هذه الحالة لن يكون بإمكانك الحصول على معلومات حول الاستثناء المُلتقط. سيبدو شكل عبارة try-catch على الشكل التالي: try { //عبارة برمجيّة مريبة } catch { //هنا يُلتقط الاستثناء وتتمّ معالجته } من الممكن استخدام هذا الأسلوب إذا كنّا على يقين حول طبيعة الخطأ الذي سيحدث. عبارة try-catch أكثر تطورا تصادفنا في بعض الأحيان حالات يكون من الضروري معها مراقبة أكثر من عبارة برمجيّة مريبة ضمن قسم try. لقد اتفقنا أنّه عند حدوث أيّ استثناء ضمن قسم try سينتقل التنفيذ إلى قسم catch. ولكن كيف سنميّز العبارة التي سبّبت هذا الاستثناء في قسم try؟ توجد العديد من الأصناف التي ترث من الصنف Exception والتي يُعتبر كلّ منها استثناءً مخصّصًا أكثر للمشكلة التي قد تحدث. فمثًلا كان من الممكن في البرنامج Lesson16_01 السابق أن نستخدم الصنف DivideByZeroException بدلًا من الصنف Exception في عبارة catch، وذلك لأنّه يرث (بشكل غير مباشر) من الصنف Exception، وسيعمل البرنامج كما هو متوقّع. ولكن في هذه الحالة لن تستطيع catch التقاط سوى الاستثناءات التي تنتج عن القسمة على صفر. في كثير من الحالات قد تتسبّب العبارات البرمجيّة الموجودة في قسم try باستثناءات متنوّعة لا توجد علاقة فيما بينها. مما يفرض علينا استخدام الصنف Exception لكي نلتقط بشكل مؤكّد أي استثناء قد يصدر عنها، أو أن تساعدنا سي شارب في هذا الخصوص! في الحقيقة الخيار الثاني هو الأفضل وهو جاهز. يمكننا في الواقع إضافة أقسام catch أخرى بقدر ما نرغب بعد قسم try. سيوضّح البرنامج Lesson16_02 هذه الفكرة من خلال فتح ملف نصي ومحاولة قراءة محتوياته. لاحظ أنّنا سنستخدم هنا نطاق الاسم System.IO. 1 using System; 2 using System.IO; 3 4 namespace Lesson16_02 5 { 6 class Program 7 { 8 static void Main(string[] args) 9 { 10 string contents; 11 12 Try 13 { 14 using (StreamReader sr = new StreamReader("myfile.txt")) 15 { 16 contents = sr.ReadLine(); 17 } 18 19 Console.WriteLine("This file contains {0} characters.", contents.Length); 20 } 21 catch(NullReferenceException nullExp) 22 { 23 Console.WriteLine("The file does not contain any data."); 24 } 25 catch(FileNotFoundException notFoundExp) 26 { 27 Console.WriteLine("File: {0} not found!", notFoundExp.FileName); 28 } 29 } 30 } 31 } يستخدم هذا البرنامج قسميّ catch. القسم الأوّل (الأسطر من 21 إلى 24) يلتقط استثناءً من النوع NullReferenceException وهذا يحدث عند محاولة استدعاء تابع أو خاصيّة من متغيّر يحتوي على null بدلًا من مرجع لكائن حقيقي. أمّا القسم الثاني (الأسطر من 25 إلى 28) فهو يلتقط استثناءً من النوع FileNotFoundException والذي يحدث عند محاولة القراءة من ملف غير موجود. نفّذ البرنامج السابق وستحصل على الرسالة التالية في الخرج: File: C:\\Users\Husam\documents\visual studio 2015\Projects\Lesson16_02\Lesson16_02\bin\Debug\myfile.txt not found! وهذا طبيعي تمامًا لأنّني لم أنشئ الملف myFile.txt في هذا المسار. لاحظ كيف يضيف الصنف FileNotFoundException خاصيّة جديدة له وهي FileName (السطر 27) من النوع string التي تحوي مسار الملف مع اسمه. أنشئ الآن الملف myFile.txt واتركه فارغًا، ثمّ ضعه ضمن نفس المجلّد الذي يحوي الملف التنفيذي للبرنامج (موجود ضمن bin\Debug\). أعد تنفيذ البرنامج وستحصل على الرسالة التالي: The file does not contain any data. السبب في ظهور هذه الرسالة هو الاستثناء NullReferenceException وذلك لأنّنا حاولنا الوصول إلى الخاصيّة Length (تعطينا عدد المحارف الموجودة ضمن متغيّر نصي) من المتغيّر النصي contents رغم أنّه يحتوي على null (تذكّر بأنّنا تركنا الملف myFile.txt فارغًا). اذهب إلى الملف myFile.txt الذي أنشأناه قبل قليل، واكتب بعض الكلمات ضمنه واحفظ الملف، ثمّ أعد تنفيذ البرنامج Lesson16_02 من جديد. يجب الآن أن تحصل على رسالة تخبرك بعدد الأحرف التي كتبتها ضمن الملف. ملاحظة: يجب الانتباه إلى ترتيب أقسام catch. فلو كان مثلًا أوّل قسم catch موجود بعد قسم try يلتقط استثناءً من النوع Exception فعندها لن يستطيع أي قسم لاحق التقاط أي استثناء، لأنّ جميع الاستثناءات سيلتقطها هذا القسم الأوّل. السبب في ذلك أنّ الصنف Exception هو الأب العام لجميع أصناف الاستثناءات الأخرى، فيمكن له التقاطها. عبارة try-catch-final يمكن إضافة قسم أخير لعبارة try-catch اسمه final. وكما يوحي اسمه، فهذا القسم يمكن له أن يحتوي على عبارات برمجيّة سيتمّ تنفيذها بعد أن يدخل البرنامج إلى القسم try العائد له. وذلك سواءً أحدث استثناء ضمن try أم لم يحدث. تكمن فائدة وجود هذا القسم، في أنّه قد نواجه أحيانًا بعض الحالات التي تتطلّب إجراء بعض المهام عندما نفرغ من قسم try مثل إغلاق بعض المصادر المفتوحة، أو تحرير الذاكرة بشكل فوري وغيرها. الشرط الوحيد لاستخدام هذا القسم الاختياري هو أن يكون آخر قسم في عبارة try-catch. سنعدّل البرنامج Lesson16_02 ليدعم القسم final. انظر البرنامج Lesson16_03. 1 using System; 2 using System.IO; 3 4 namespace Lesson16_03 5 { 6 class Program 7 { 8 static void Main(string[] args) 9 { 10 string contents; 11 12 try 13 { 14 using (StreamReader sr = new StreamReader("myfile.txt")) 15 { 16 contents = sr.ReadLine(); 17 } 18 Console.WriteLine("This file contains {0} characters.", contents.Length); 19 } 20 catch(NullReferenceException nullExp) 21 { 22 Console.WriteLine("The file does not contain any data."); 23 } 24 catch(FileNotFoundException notFoundExp) 25 { 26 Console.WriteLine("File: {0} not found!", notFoundExp.FileName); 27 } 28 finally 29 { 30 Console.WriteLine("Good Bye!"); 31 } 32 } 33 } 34 } سواءً كان الملف myFile.txt موجودًا أم غير موجود، أو كان يحتوي على بيانات أم فارغاً، ستظهر العبارة !Good Bye على الشاشة. ملاحظة: من الأفضل دومًا أن تحاول عدم استخدام عبارة try-catch وأن تستخدم عبارة if لاختبار الحالات التي تواجهك قبل تنفيذها. استخدم try-catch إذا كان ذلك ضروريًّا. والسبب في ذلك أنّ عمليّة معالجة الأخطاء بشكل عام تتطلّب المزيد من الموارد المخصّصة للبرنامج، مما قد يؤثّر على أداء البرنامج في حال تمّ استخدامها بشكل غير مدروس. تمارين داعمة تمرين 1 عدّل البرنامج Lesson16_02 بحيث يمكن الاستغناء عن عبارة try-catch تمامًا. (تلميح: ستحتاج إلى استخدام عبارتيّ if في هذه الحالة). تمرين 2 لتكن لدينا الشيفرة التالية: string input = Console.ReadLine(); int t = int.Parse(input); تطلب الشيفرة السابقة من المستخدم أن يدخل عددًا على شكل نص لتعمل على تحويله إلى قيمة عدديّة باستخدام التابع int.Parse. المطلوب هو إضافة عبارة try-catch إلى الشيفرة السابقة لمعالجة استثناء ممكن الحدوث في حال أدخل المستخدم قيمة مثل "u" وهي لا يمكن تحويلها إلى قيمة عدديّة كما هو واضح. (تلميح: استخدام الاستثناء FormatException الذي يُعبّر عن هذه الحالة). الخلاصة تعرّفنا في هذا الدرس على كيفيّة معالجة الأخطاء التي تظهر أثناء تنفيذ البرنامج. في الحقيقة هذا الموضوع ذو شجون! وهناك الكثير ليقال، ولكن يكفي الآن أن تتعرّف على المبادئ الأساسيّة لالتقاط الاستثناءات، وكيفيّة معالجتها. يمكنك استخدام هذا الأسلوب في جميع التطبيقات التي تُنشئها باستخدام سي شارب، مثل تطبيقات الويب بأنواعها، وتطبيقات سطح المكتب، وحتى تطبيقات الأجهزة الذكيّة باستخدام تقنيّة Xamarin.

إن دفع الناس إلى التسجيل في تطبيقك الخاصّ أمر صعب للغاية، إذ أنّه يتطلب الكثير من الوقت والجهد والمال، ومع ذلك فهناك الكثير من الشركات التي تخسر هؤلاء العملاء بعد تجربتهم الأولى للبرنامج مباشرة، ومن المؤكّد أنّك لا ترغب في أن تكون شركتك من ضمن هذه الشركات. لنتعرف معًا على بعض الأخطاء الشائعة في تهيئة العملاء الجدد (user onboarding) والتي يمكن أن تكون سببًا في إلحاق الضرر بمشروعك التجاريّ. 1- الاعتماد على الواجهة فقط لتوضيح قيمة المنتج يمرّ مستخدم البرمجيات بلحظة يتمكن فيها من إدراك قيمة البرنامج الذي يستخدمه. إنّها اللحظة التي تصبح فيها قيمة المنتج الذي تقدّمه إلى المستخدم واضحة بشكل كبير، ويكون لسان حاله "حسنًا، لقد فهمت الآن". لسوء الحظّ قد تأتي لحظة الفهم هذه متأخرة بعض الشيء خصوصًا عندما يضطرّ المستخدم إلى قضاء بعض الوقت في التعرف على واجهة البرنامج وعلى القيمة الكلية للمنتج. لا تأمل الحصول على البيتزا بمجرد اتباع بعض التعليمات التي تخصّ إعداد العجينة أو الصلصة. يتطلب تحقيق الإنجازات المهمّة وضع سياق عمل واضح ومناسب قبل الشروع بالعمل. وفي حالتنا هذه، سيكون سياق العمل هو مقدار الفائدة التي سيجنيها المستخدمون جرّاء استخدامهم للمنتج الذي تقدّمه إليهم. فهم المستخدمين لطبيعة منتجك قبل التسجيل للحصول عليه سيكون في صالحك من ناحيتين، الناحية الأولى هي أنّ ذلك سيوجّه جميع نشاطاتهم اللاحقة باتجاه واضح وهادف، والناحية الثانية هي أنّ لحظة الفهم هذه ستشكل حافزًا كبيرًا للتسجيل في المنتج، بدلًا من الاعتماد على عامل الفضول فقط. إنّ إيصال فكرة المنتج الذي تقدّمه قبل التسجيل فيه لن يزيد من أعداد المستخدمين وحسب، بل سيوفّر لهؤلاء المستخدمين تجربة ثرية عند تعاملهم مع المنتج للمرة الأولى. فائدة: إن كنت غير متأكد من الطريقة التي توصل عملائك إلى لحظة الفهم، فاتّصل بأحد العملاء المحتملين وحاول إقناعه بأن يبدأ باستخدام المنتج بعد أن يطّلع على ما تقدّمه في موقعك التسويقي فقط. إن لم يكن ذلك كافيًا، فحاول تذكر الأمور الإضافية التي استعنت بها في إقناع العميل وأضفها إلى الإنشاء copy حسب الحاجة. 2- عدم معرفة الإجراءات التي تؤدي إلى التحويل من المؤكّد أنّك لن تستفيد من لحظة الفهم إن لم تتمكن من دفع المستخدمين إلى الخوض في هذه التجربة الفريدة بشكل مباشر. إن لحظة الفهم تشير إلى إدراك المستخدمين للفائدة التي يقدّمها المنتج الخاصّ بك، في حين تشير لحظة الانبهار "wow moment" إلى أنّ المستخدمين قد تمكّنوا من تجربة هذه الفائدة بأنفسهم. ولتتأكّد من أنّ المستخدمين يحصلون بالفعل على الفائدة التي تعدهم بها في موقعك التسويقي، يجب عليك أن تتتبّع معدّلات التحويل الناجح. لقد أظهرت الإحصائيات أنّ ما يقارب 50% من المستخدمين الذين يسجّلون للحصول على المنتج يسجّلون الدخول بعد ذلك مرة واحدة فقط ولا يعودون بعدها إلى الموقع مطلقًا. هذا يعني أنّك تستثمر الكثير لجلب المستخدمين الجدد لتخسر نصفهم مباشرة بعد زيارتهم الأولى، إذًا ما الذي يمكن القيام به لإيقاف هذا النزيف؟ تمكّن Josh Elman من شركة Greylock Partners من حل هذه المشكلة بالشكل التالي: تابع Josh آخر 20 شخص تحوّلوا بنجاح إلى عملاء وتتبّع نشاطهم في الموقع خطوة بخطوة، ليتمكن من تشخيص الأمور التي دفعتهم إلى الوصول إلى نقطة التحول. إنّ فهم النشاطات التي تؤدي إلى التحويل سيساهم بشكل كبير في دفع المستخدمين باتجاه هدفك النهائي ألا وهو تحويلهم إلى عملاء. إن عملية تهيئة المستخدمين الفعّالة ليست تلك التي تعمل على جعل المستخدمين الجدد نشطين في الموقع، وإنما هي تلك التي تدفع بهؤلاء المستخدمين إلى العودة مجدّدًا. فائدة: بالإضافة إلى تتبّع عدد المستخدمين الذين تمكّنوا من إكمال كلّ خطوة من خطوات عملية التحوّل إلى عملاء، حاول كذلك قياس الوقت الذي يستغرقه هؤلاء للوصول إلى تلك النقطة، فالوقت ثمين جدًّا وهو أثمن وأثمن في اللحظات الأولى التي يتعامل فيها العميل مع المنتج الذي تقدّمه. 3- فقدان الزخم في اللقاء الأول يجدر بك أن تنظر إلى تجربة الاستخدام الأوّل من منظور مساعدة المستخدم على تحقيق الفائدة بدلًا من إكماله لبعض المهامّ التي أعددتها له، فالسبب وراء تسجيل المستخدم الجديد في الموقع للحصول على المنتج ليس أنّه متحمّس لمعرفة ما تقوم به كل تلك الأيقونات المنتشرة في واجهة الاستخدام، بل لأنّه مهتم بالقيمة التي وعدت بتقديمها إليه. لذا يجب أن تهدف تجربة الاستخدام الأوّل إلى إشعار المستخدم بهذه القيمة من خلال إرشاده وبأيسر الطرق وأسهلها إلى تحقيق هذا المكسب الأوّلي الصغير. يجب أن يرتبط هذا المكسب الصغير بمجمل الخدمات التي يقدّمها منتجك، فشعور المستخدمين الجدد بالفائدة الكبيرة التي سيحصلون عليها من المنتج الذي تقدّمه ستزيد من احتمالية عودتهم إليك مرة أخرى. وبمجرّد أن تتعرّف على الأمور التي تريد توجيه المستخدمين إليها في تجربة الاستخدام الأوّل، ابدأ بإزالة جميع العقبات التي تحول دون وصول المستخدمين إلى الهدف المنشود. سجّل جميع الإجراءات التي يجب أن يتّخذها المستخدم لتحقيق ذلك المكسب الصغير، ثم ابدأ بالتخلص من جميع الأمور التي يمكن القيام بها في وقت لاحق. إن فترة تهيئة المستخدمين الجدد ليست فترة ملائمة لإجراء التجارب، لذا إن لم تكن متيقنًا من جدوى طلب المعلومات الإضافية مثل أرقام الهاتف أو عدد الموظّفين، فمن الأفضل أن تترك هذا الأمر وتعمل بمبدأ (إن كنت في شك، فاترك الأمر). على سبيل المثال، إن كنت قادرًا على القيام بالأمر دون طلب تأكيد عنوان البريد الإلكتروني، ولو بشكل سريع، فتجنب إنقاص الزخم الذي يتمتع به المستخدم عندما تلجئه إلى الدخول في معمعة بريده الإلكتروني قبل أن يتمكن من القيام بشيء يذكر في التطبيق الخاصّ بك. ولكن تذكّر دائمًا أن هذا المبدأ لا يشبه المبدأ القائل: "أبق الأمور مختصرة وغير قابلة للتذكر"، ففي دراسة أجرتها Lumosity مؤخّرًا تبيّن أن إبطاء الأمور وجعل المستخدمين يفكّرون في التجربة التي سيمرّون بها قد زاد من احتمالية بقائهم، ومؤكّد أن أصحاب الدراسة لم يتمكنوا من معرفة ذلك دون اللجوء إلى تتبع معدلات التحويل. فائدة: أن الأداء السيّئ للموقع هو من الأمور التي تتسبّب في فقدان الزخم، ففي كل مرة يستغرق فيه تحميل الصفحات وقتًا طويلًا ستزداد فرصة تحوّل المستخدم إلى موقع آخر، أو الانشغال بتحضير كوب القهوة الذي كان يتوق إلى تناوله. حاول الإبقاء على المستخدمين من خلال تقليل المدة اللازمة للاستجابة، أو على الأقل مخاطبة المستخدم بأنّ موقعك يعمل لإنجاز شيء ما من أجله. 4- عدم مشاركة المستخدم فرحة تحقيق النجاح ألن تشعر بالسعادة عندما تشطب عنصرًا من عناصر قائمة المهام التي يجب عليك إنجازها هذا اليوم؟ ما هو شعورك فيما لو أنجزت جميع المهام التي وضعتها لنفسك ضمن هذه القائمة، ثم قمت بتجعيد الورقة وإلقاءها في سلة المهملات، ثم النظر إلى السماء وأنت تتخذ وضعية البطل المنتصر؟ ما المانع من جعل المستخدمين يمرّون بتجربة مماثلة عندما يحققون نجاحهم الأول؟ أستغرب في كثير من الأحيان تلك الحالات التي يتحدّى فيها المستخدم جميع الاحتمالات ويشقّ طريقه لتحقيق الانتصار الحقيقي الأول في تطبيق معين، ولكن الشركة القائمة على ذلك التطبيق تكون غير موجودة للاحتفال بهذا الإنجاز. إن اللحظة التي ينجز فيها المستخدمون مهمّة ذات أهمية تكون فرصة كبيرة لإضفاء بعض المشاعر الإيجابية بينهم وبين شركتك. كن حريصًا على أن يعلم المستخدمون بأنّهم يقومون بعمل رائع وذلك من خلال تقدير الإنجاز الذي حقّقوه والتعبير عن السعادة التي تشعر بها حيال ذلك. أسمّي فرص التصميم هذه بـ "حالات النجاح" (success states) وأعتقد أنّها متاحة في جميع الأوقات؛ لذا كن سبّاقًا في إيجاد لحظات النجاح في تجربة المستخدم الخاصّة بموقعك وتصميم شيء يمنح تلك اللحظات شيئًا من الواقعية. ليس من الضروري أن يكون التصميم فخمًا وقويًّا، فاستخدام عبارة "أحسنت، عمل رائع" في الوقت الصحيح قد يفي بالغرض. فائدة: استفد من هذه اللحظات لأنها فرصة جيّدة للتعبير عن شخصيتك، كما هو الحال مع Mailchimp والتي تقوم بذلك من خلال حركة High five واقعية. 5- عدم متابعة المستخدمين بعد انتهاء تجربة الاستخدام الأول تمكّنت أخيرًا من توضيح الفائدة التي سيجنيها المستخدمون من المنتج الذي تقدّمه، وشخّصت الخطوات التي يجب عليك اتخاذها بادئ الأمر، ثمّ بدأت بتمهيد الطريق أمام المستخدمين لإتمام تلك الخطوات، لتحتفل معهم بعد ذلك بأول إنجاز يحقّقونه. عظيم، ولكن ما الذي ستفعله بعد ذلك؟ الإجابة بسيطة: اجعلهم يعودون إليك مرّة أخرى وقدّم إليهم المزيد. من المؤكّد أنّه لن يسعك القيام بالكثير من الأمور في موقعك لدفع الناس إلى العودة إليه مرة أخرى. بدلًا من ذلك يمكنك التواصل مع المستخدمين باتباع الطريقة التقليدية: رسالة إلكترونية ذات قيمة موجّهة ترسلها في الوقت المناسب. غالبًا ما يساء استخدام رسائل دورة الحياة Lifecycle emails في تطبيقات الإنترنت، وإن كنت ستعتمد على رسالة ترحيب مملّة وتتأمّل بعدها أن تكون رسالة (لقد انتهت الفترة التجريبية الخاصّة بك) المرسلة بعد أسبوعين كافية لدفع الناس إلى الحصول على القيمة الكلية التي يقدّمها منتجك إليهم، فاعلم حينها أنّك تقدم على مجازفة كبيرة. بالنسبة إلي فإنّي أحبّذ أن تكتب قائمة بالخطوات المهمّة التي يجب على المستخدمين إنجازها لتحقيق الفائدة القصوى من البرنامج، ثم اكتب سلسلة من رسائل البريد الإلكتروني التي يمكن إرسالها إلى الأشخاص الذين لم ينجزوا خطوة معيّنة من الخطوات غير المنجزة. فائدة: لا تأمر الناس باتخاذ إجراء معيّن عندما تكتب هذه الرسائل، بل حاول استخدام أسلوب تقديم المنفعة التي لا تفصلهم عنها سوى النقر على الفأرة. على سبيل المثال: إن كان لديك تطبيق للمواعدة، فلا تخاطب المستخدمين بعبارة "يرجى رفع أكثر من صورة واحدة" بل اسألهم: "هل تعلم أن الأشخاص الذين يمتلكون أكثر من صورة واحدة تزداد فرصتهم في الحصول على الموعد خلال يوم واحد بنسبة 60%". من لا يرغب في الحصول على المزيد من المواعيد. نجاح مشروعك التجاري من عدمه يعتمد على تجربة الاستخدام الأول إن إدارة مشروع تجاري برمجي أمر صعب، فمشاغل الناس في تزايد مستمر، وفترات اهتمامهم في تناقص مستمر أيضًا، إضافة إلى وجود المنافسين في كل مكان، ولا يمكنك الاعتماد على الانطباعات الأولية المفاجئة في بناء خطتك التي ستتبعها في كسب العملاء. لقد قمت باستثمار الكثير من الوقت والجهد والمال في بناء مشروعك التجاري، وعلى الأرجح فأنت تمتلك منتجًا رائعًا ترغب في مشاركته مع الآخرين، لذا لا تجعل كلّ ذلك يضيع سدًى لأنّ تجربة الاستخدام الأوّل كانت سيئة. لا تدّخر جهدًا في جعل عملية التهيئة عملية مثالية ومتكاملة لتكون قادرًا على دفع المستخدمين إلى العودة إليك مرة أخرى. ترجمة -وبتصرّف- للمقال Are You Making These 5 Common User Onboarding Mistakes لصاحبه Samuel Hulick.

ثمة الكثير من الطرق للحصول على نتائج أفضل في مشاريعك التجارية، أعتقد أن أقربها ورودًا إلى ذهنك هو زيادة كبيرة في الميزانية؛ أو عقد شراكة مع شخص مؤثّر، لكنني أتحدث عن طريقة أسرع وأكثر سهولة؛ إنها ببساطة: تحسين صفحات الهبوط الخاصة بك. عندما تهتم بصفحة الهبوط وتصممها بالطريقة المثلى ستحصل على نتائج جيدة وسريعة، فعلى سبيل المثال ازدادت المبيعات من بعض صفحات التحويل مليون دولار عقب تطويرها -نعم الرقم صحيح- مليون دولار من صفحة هبوط بسيطة واحدة. جربتُ ذلك بشكل شخصي منذ عدة سنوات مضت، وكان ذلك مع شركة تحصل على معظم حركة المرور على موقعها من خلال شراء إعلانات الدفع لكل نقرة Pay per click؛ كانوا ينفقون ما يقارب 12 ألف دولار يوميًا على النقرات، لكن من خلال تعديل واحد على زر الدعوة للعمل Call to action button تضاعف معدل التحويل، ثمة قصة أخرى لخبراء في معدل التحويل جنوا مليون دولار عبر إعادة تصميم صفحة الهبوط فحسب. بالتأكيد لا يمكن لأيّ كان أن يضمن لك أرباحًا صافية بمليون دولار بمُجرّد تعديل صفحة الهبوط الخاصة بك، لكن ذلك قد يحدث بالفعل؛ وبإمكانك -من خلال اتباع بعض النصائح- الحصول على نتائج أفضل. لا يمكننا الحديث عن الأرباح فقط من صفحات التحويل دون التطرق للجانب المظلم فيها، فصفحة التحويل السيئة ستؤثر سلبًا بشكل كبير على نشاطك التّجاري. سأقدم لك في هذا المقال قائمة من أسوأ الأخطاء وأكثرها شيوعًا في صفحات الهبوط، والتي ستكون -عبر تجنبها- في طريقك للانضمام لأصحاب المليون دولار. 1. عدم استخدام أية صفحات هبوط ينفق أصحاب المشاريع الكثير على تنظيم الحملات التسويقية، لكن بعضهم يبددون جهودهم عبر إرسال المتجاوبين مع حملاتهم إلى الصفحات الرّئيسية على موقعهم عوضًا عن صفحات هبوط خاصة، فهل أنت من ضمنهم؟ قد يبدو لك أمرًا غير ذي أهمية، لكنني أعتقد أنك ستغيّر رأيك عندما تعلم أن إنشاء صفحة هبوط خاصة بحملتك التسويقية سيزيد من أرباحك -على الأرجح- بمعدل 30-40%، وهو ما كشفت عنه معظم اختبارات A/B التي تقارن بين مردود صفحات الهبوط والصفحات الرئيسية للمواقع. لكن؛ ما سبب ذلك؟ إنه يتعلق بما يدعى "نسبة الانتباه" Attention ratio، والتي تشير إلى عدد الأفعال التي يمكن للزائر القيام بها في الصفحة. إذا أمكن للمستخدم القيام ب 15 إجراء مختلف، فنسبة الانتباه ستكون 1:15، أما إن كان ثمة إجراء واحد متاح للمستخدم عبر الصفحة فإن نسبة الانتباه ستكون 1:1. تكون صفحات التحويل مثالية عند نسبة انتباه 1:1. إليكم في الصورة التالية مثالًا على نسبة انتباه 1:1: ما نراه في هذه الصورة هو رابطان -وكلاهما بلون برتقالي-، وكلاهما أيضًا يقودانك لفعل الأمر ذاته. قارن الصورة السابقة مع الصورة التالية بنسبة انتباه 1:15، ثمة الكثير مما يمكن أن يشتت الزائر عن الإجراء الوحيد الذي ترغب الشركة منه بالقيام به: تسجيل الدخول لتجريب نسخة مجانية. 2. عدم اختبار صفحات الهبوط من الفوائد التي تجنيها عند الالتزام باختبارات صفحة الهبوط هو اكتساب خبرة، فكلما أطلقت صفحة هبوط جديدة مستقبلًا ستدرك أنها تسير قدمًا نحو الأمام. لماذا؟ لأنه ومن خلال الصبر؛ والاختبارات الصحيحة إحصائيًا، يمكنك الحصول على صفحات هبوط أفضل فأفضل، وهو ما يعني نتائج أكثر جودة، والذي سيحقق لمشروعك المزيد من النجاح بالتأكيد، هل يعجبك هذا؟ ليس الأمر مجرد رأي شخصي، فقد تم تقييم اختبارات A/B -أو الاختبارات المقسمة Split-testing- لصفحات الهبوط كأفضل وسيلة لزيادة معدل التحويل من قبل المسوقين الذين شملهم استطلاع أجراه موقعا Ascend2 و WiderFunnels "تقرير صفحات الهبوط المثلى 2015". 3. اختبار صفحة الهبوط بطريقة خاطئة وهو خطأ شائع بين المسوقين، يحدث ذلك عندما تعتمد على نتائج أولية من إصدار واحد من الاختبار -خلال الأيام الأولى فحسب- وتتأكد من أن الأمور تسير بطريقة عظيمة، بعدها سيأتي من سيحاول تغيير رأيك -شريكك أو أحد الزبائن- ويقول لك "كفاك هوسًا بهذه الاختبارات، نتائج النسخة B تبدو أفضل بكثير من نتائج النسخة A، توقف عن تضييع وقتك بها". هنا تحديدًا أنصحك بشدة ألا تستسلم، سيكون الأمر صعبًا تحت الضغط، لكن عليك التحلي بالصبر والتمسك بالأرقام والإحصائيات الرياضية؛ والتي تفيد بوجوب إجراء الاختبار لفترة طويلة كفاية للحصول على نتائج صحيحة إحصائيًا. عانيتُ شخصيًا الكثير من نتائج الاختبارات التي أظهرت في بداياتها تفوّق نسخة على أخرى بكل جدارة وبكل وضوح في بادئ الأمر، لكن يومًا بعد آخر انحدر هذا التّفوّق ببطء، وفي النهاية؛ كانت النتيجة تعادلًا، إنها نتيجة مملة، لكنني أرجح أنك ستفضل الاعتماد عليها في مشروعك مقابل الاستناد إلى نتائج اختبار خاطئة، أليس كذلك؟ لذا أنصحك بإعطاء الاختبار الوقت اللازم له للحصول على نتائج دقيقة، وهو ما يعني عادة أسبوعًا واحدًا على الأقل، للحصول على إحصائيات أكثر تحديدًا يمكن الاستعانة بأدوات من قبيل: A/B Test Sample Size Calculator الخاص بـ Optimizely. 4. صفحة الهبوط غير متوافقة مع أجهزة النقال أعتقد أنك تعرف أن عدد متصفحي الإنترنت من أجهزة النقال يفوق عددهم من أجهزة الحاسب، لذا يجدر بك أن تراعي ذلك أثناء بناء صفحة الهبوط الخاصة، بحيث لا يقتصر توافقها على أجهزة الحاسب فحسب. كتب كيري باترز مقالًا كاملًا عن توافق صفحات الهبوط مع أجهزة النقال، ومن أهم النقاط الواردة فيه: اكتب عناوين رئيسية من 5 كلمات أو أقل. لا تنسَ تضمين شعار شركتك. بسّط تصميمك واستخدم مساحات بيضاء فيه. حافظ على بساطة الصياغة واجعل زر الدعوة للعمل بارزًا. 5. لا يفهم الزائر الإجراء الذي يفترض القيام به في صفحة الهبوط اختبار سريع: إذا عرضت صفحة الهبوط الخاصة بك على شخص لم يتصفحها سابقًا، هل سيكون قادرًا على إجابتك على الأسئلة التالية بعد خمس ثوان من استعراضها: ما الغرض من صفحة الهبوط هذه؟ ما الذي تعرضه؟ ما الإجراء الذي ترغب من زائر الصفحة القيام به؟ كيف يمكنه تنفيذ هذا الإجراء؟ جرب هذا الاختبار السريع على مجموعة مختلفة من الأشخاص، من الأفضل أن يكونوا من جمهورك المستهدف. إذا واجه الأشخاص صعوبة في الإجابة على هذه الأسئلة الأساسية بعد بضعة ثوان من استعراض صفحة هبوطك فأنت أمام مشكلة: الرسالة التي تود إيصالها من خلالها ليست واضحة كفاية. لكن هذه المشكلة سهلة الإصلاح نسبيًا: عليك أن تعيد صياغة نص صفحة الهبوط الخاصة بك، مع مراعاة التالي: اعتمد على أبسط وأقوى وسيلة لجذب انتباه زوارك. ابحث عن الفقرات التي يمكن أن تستبدلها بقوائم نقطية Bullet points. يجب أن لا يزيد طول أية فقرة عن أربعة أسطر. بسّط أية عبارة يمكن أن تبسّطها. استخدم أية كلمات أو تعابير يمكنها أن تجذب الزائر وتدفعه للتفاعل. ابحث عن كل ما يمكن حذفه. 6. تحميل صفحة الهبوط بطيء للغاية يمكن لبطء تحميل صفحات الهبوط أن يؤثر سلبًا بشكل كبير على معدلات التحويل. ويعتبر تحميل الصفحة بطيئًا إذا استغرق ما يزيد عن ثانيتين لفتحها. سنستعرض هنا مقتطفات من انفوغرافيك "كيف يؤثر زمن التحميل على أرباحك" من قبل KissMetrics. إذا لم تكن متأكدًا من سرعة تحميل صفحتك يمكنك الاستعانة بأداة قياس سرعة التحميل من جوجل Google’s PageSpeed Insights، ستحصل أيضًا على نصائح وتعليمات لإصلاح أية مشكلة موجودة. فكّر في استخدام ترميز مسرّع تحميل الصفحات للهواتف النقالة (Accelerated Mobile Pages (AMP في بناء صفحات هبوطك، وهو نسخة مبسطة من HTML من إصدار جوجل لتسريع تحميل صفحات الإنترنت على الهواتف النقالة. قد لا تحصل على نتائج من استخدام الترميز الجديد في غضون الشهر المقبل؛ لكن يجب علينا جميعًا أن نحيط علمًا به، ونفكر باستخدامه بأقرب وقت. 7. صفحة الهبوط لا تحتوي صورة للمنتج يجب أن تضم صفحة الهبوط صورة لمنتجك، ولا يعني اختصاصك في مجال الخدمات؛ أو كون شركتك تقدم برمجيات كخدمات عبر الإنترنت SaaS إعفاءك من ذلك، فبالنسبة للخدمات: يمكنك عرض الخدمة التي تقدمها، أما بالنسبة لـ SaaS: أرفق رسمًا بيانيًا يوضح نتائج عمل البرمجية التي توفّرها شركتك. من المهم ألا تتضمن صفحة الهبوط اشتريتها على الإنترنت (أو حتى حصلت عليها بشكل مجاني)، فوجودها يضرّ بمصداقيتك بشكل كبير. إذا كنت تعرض كتابًا إلكترونيًا في صفحة الهبوط؛ ننصحك بتضمين تصميم ثلاثيّ الأبعاد للكتاب، ثمة الكثير من الأدوات التي تسمح لك بتصميم غلاف ثلاثي الأبعاد لكتاب إلكتروني، من قبيل BoxShot وهي أداة متاحة للاستخدام المجاني على الإنترنت. فائدة: حافظ على اتساق رسالتك ما بين يقرأه الزائر في حملتك التسويقية وبين ما يستعرضه في صفحة الهبوط. لا تعرض للناس إعلانًا يقول "ابدأ مشروعك الخاص في عطلة نهاية الأسبوع القادمة"، في حين تحتوي صفحة الهبوط معلومات عن مؤتمر لأصحاب المشاريع الصغيرة، فالرسالة هنا غير متناسقة. من المهم بشكل خاص أن يكون عنوان صفحة الهبوط متطابقًا مع ما قرأه الزائر للتو في إعلانك قبل الانتقال للصفحة. الخلاصة لم نتناول في هذا المقال كل الأخطاء المتعلقة بصفحات الهبوط بالتأكيد، لكننا غطينا الأخطاء الأكبر والأكثر تكرارًا، لنستعرضها سريعًا على سبيل الإعادة: لا ترسل الزوار للصفحة الرئيسية لموقع الشركة، استخدم صفحات الهبوط. اضبط برنامج اختبارات مستمر. دع الاختبارات تنفّذ على الفترة الزمنية التي تحتاجها للحصول على نتائج صحيحة إحصائيًا -أسبوع واحد على الأقل-. تأكد من توافق صفحات الهبوط الخاصة بك مع أجهزة النقّال. تأكّد من أن يكون نص صفحة الهبوط واضحًا جليًا للزائر. تأكد من سرعة تحميل صفحة الهبوط خلال ثانيتين أو أقل. ضمّن الصفحة صورة لمنتجك أو للخدمة التي تقدمها، من الأفضل أن تكون صورة حقيقية لموظف أو لمنتج من شركتك، لا صورة مأخوذة من الإنترنت. هل لديك تجارب سابقة مع صفحات الهبوط؟ هل أحرزت ربحًا كبيرًا منها؟ شاركنا تجربتك وأفكارك في التعليقات. ترجمة -وبتصرف- للمقال Most Common Landing Page Mistakes – And How To Fix Them لكاتبته Pam Neely.

بعد أن ازدادت السكربتات التي نكتبها تعقيدًا، فأحببت أن أشير إلى بعض الأخطاء الشائعة التي قد تصادفك أثناء مسيرتك. سنتعرض في هذا الدرس مثالًا ونعمل على تحليل الأخطاء التي قد نرتكبها، ولنسمِّ ذاك السكربت trouble.bash، تأكد من كتابة السكربت كما هو موجود حرفيًا. #!/bin/bash number=1 if [ $number = "1" ]; then echo "Number equals 1" else echo "Number does not equal 1" fi يجب أن يُخرِج السكربت السابق السطر "Number equals 1"، لأنَّ المتغير number يساوي 1، إن لم تحصل على المخرجات التي توقعتها، فتحقق من صحة كتابتك للسكربت، فربما ارتكبتَ خطأً… المتغيرات الفارغة عدِّل السطر الثالث من السكربت من: number=1 إلى: number= ثم شغِّل السكربت مرةً أخرى، وستحصل هذه المرة على المخرجات الآتية: $ ./trouble.bash /trouble.bash: [: =: unary operator expected. Number does not equal 1 كما لاحظت، عَرَضَت الصَدَفة bash رسالة خطأ عندما شغلنا السكربت، وربما ظننتَ أنَّ حذف القيمة "1" من السطر الثالث قد أدى إلى خطأٍ بنيوي (syntax error) لكن هذا ليس صحيحًا، ألقِ نظرةً إلى رسالة الخطأ مجددًا: ./trouble.bash: [: =: unary operator expected يمكننا ملاحظة أنَّ ‎./trouble.bash يُبلِّغ عن الخطأ، الذي يرتبط -بشكلٍ أو بآخر- مع ]؛ تذكَّر أنَّ ] هو اختصارٌ للأمر المُضمَّن في الصَدَفة test. ومن رسالة الخطأ السابقة استطعنا تحديد أنَّ الخطأ يحدث في السطر الخامس وليس الثالث. عليّ القول بادئ الأمر أنَّه لا توجد أيّة مشكلة في السطر الثالث، حيث number=‎ صحيحة بنيويًا؛ فقد ترغب في بعض الأحيان بحذف القيمة المُخزَّنة في متغيّر. يمكنك التحقق من سلامة هذه الصياغة بكتابتها وتجربتها في سطر الأوامر: $ number= $ أرأيت! لا توجد رسالة خطأ، لكن ما هو الشيء الخاطئ في السطر الخامس؟ لقد جربناه قبل تعديل السكربت ولم يكن يسبب أيّة مشاكل. لكي نفهم هذا الخطأ، علينا أن ننظر إلى الموضوع من وجهة نظر الصَدَفة. وَضَعَت الصَدَفة، في السطر الخامس، قيمة المتغير number عندما رأت ‎$number. ففي أول محاولة لتشغيل السكربت (أي عندما كان number=1)، بدَّلَت الصدفة المتغير ‎$number بالرقم 1 كما يلي: if [ 1 = "1" ]; then لكننا عندما أزلنا قيمة المتغير (number=‎)، فستحاول الصدفة تنفيذ ما يلي: if [ = "1" ]; then وهذا خطأ، ويُفسِّر أيضًا ما تبقى من رسالة الخطأ التي حصلنا عليها. المُعامِل = هو معامِل ثنائي، الذي يعني أنَّه يتوقع وجود عنصرين (كل عنصر على طرف). وما تحاول الصَدَفة إخبارنا به هو أنَّ هنالك عنصرٌ واحدٌ فقط، ولهذا يجب وضع معامل أحادي (مثل !) الذي يتطلب وجود عنصر وحيد فقط. علينا تعديل السطر الخامس إلى ما يلي لحل هذه المشكلة: if [ "$number" = "1" ]; then وسترى الصَدَفة ما يلي (إذا كانت قيمة number=‎): if [ "" = "1" ]; then وبهذا تجنبنا هذا الخطأ. تعلمنا من هذا الخطأ أمرًا مهمًا عند كتابة السكربتات: خذ بعين الاعتبار ماذا سيحدث لو كانت قيمة أحد المتغيرات فارغة. غياب إحدى علامات الاقتباس عدِّل السطر السادس وأزل علامة إغلاق الاقتباس من نهاية السطر: echo "Number equals 1 ثم شغِّل السكربت مرةً أخرى وستحصل على: $ ./trouble.bash ./trouble.bash: line 8: unexpected EOF while looking for matching " ./trouble.bash: line 10 syntax error: unexpected end of file هذه مشكلةٌ أخرى شائعةٌ تُسبِّب مشاكل في أماكن أخرى في السكربت. ماذا يحدث لو استمرت الصَدَفة بحثها عن علامة إغلاق الاقتباس لمعرفة نهاية سلسلةٍ نصيةٍ ما، لكنها وصلت إلى نهاية الملف ولم تجدها. يصعب كثيرًا اكتشاف هذا النوع من الأخطاء في السكربتات الطويلة؛ وهذا أحد الأسباب التي تدفعك لتجربة السكربتات بين الحين والآخر عندما تكتبها لوجود كمية قليلة من الشيفرات الجديدة التي عليك اختبارها. أرى أيضًا أنَّ استخدام المحررات النصيّة التي توفِّر تلوينًا للشيفرات يساعد كثيرًا في الكشف عن مثل هذه الأخطاء. عزل مكان المشكلة قد تكون عملية إيجاد الأخطاء والعِلل في برنامجك صعبة ومحبطة، هذه بعض التقنيات التي قد تستفيد منها: اعزل أجزاءً من الشيفرات بوضع علامة تعليق قبل الأسطر التي لا تريد أن تنفذها الصَدَفة. طبِّق هذا على كتلة من الشيفرات لكي ترى إن اختفت مشكلة معيّنة. وبهذه الآلية ستعرف ما هو الجزء الذي يسبب (أو لا يسبب) المشكلة. على سبيل المثال، لو عدنا إلى السكربت الذي فيه علامة اقتباس ناقصة، فيمكننا أن نعزل المشكلة كالآتي: #!/bin/bash number=1 if [ $number = "1" ]; then echo "Number equals 1 #else # echo "Number does not equal 1" fi سنعلم بعد وضع عبارة else في تعليق ثم تشغيل السكربت أنَّ المشكلة ليس في عبارة else حتى لو أشارت رسالة الخطأ إلى ذلك. استخدم الأمر echo للتحقق من القيم. فبعد أن تكتسب خبرة في تتبع العلل، ستكتشف أنَّ العلل ستتواجد في مكانٍ مختلف عن المكان الذي تتوقع وجودها فيه. إحدى المشاكل الشائعة هي افتراضك أنَّ التسلسل المنطقي لبرنامجك صحيحٌ تمامًا، وعندما ترى مشكلة في مرحلة ما في البرنامج فستفترض أنَّها موجودة هناك؛ وهذا خاطئ في معظم الحالات. يمكنك وضع أوامر echo في الشيفرة أثناء محاولة تنقيح (debugging) الأخطاء لكي تحصل على رسائل تؤكد لك أنَّ البرنامج يعمل كما تتوقع. هنالك نوعان من الرسائل التي عليك وضعها. الغرض من أول نوع هو الإعلان أنَّ التنفيذ قد وصل إلى مكان معيّن في البرنامج، ولقد رأينا ذلك سابقًا عند كتابتنا لشيفرات وهمية في الدوال التي أضفناها. وهذا مفيد لكي تعلم أنَّ مسار تنفيذ البرنامج مماثل تمامًا لما نتوقعه. النوع الثاني يعرض قيم المتغيرات المستخدمة في الحسابات أو الاختبارات. قد تجد في بعض الأحيان قسمًا من السكربت لا يُنفَّذ تنفيذًا سليمًا لأنك افترضت أنَّ شيئًا ما في ما سبقه من الشيفرات صحيحٌ؛ إلا أنَّ فيه مشكلةً تؤدي إلى فشل تنفيذ ما يليه من الشيفرات. مراقبة تشغيل السكربت من الممكن أنَّ تعرض لك bash ما الذي يحدث عندما تُشغِّل السكربت. وذلك بإضافة الخيار ‎-x في أول سطر من السكربت كما يلي: #!/bin/bash -x وعندما ستُشغِّل السكربت، فستعرض bash كل سطر ستحاول تنفيذه (بعد تعويض قيم المتغيرات…). تُسمى هذه التقنية بالتتبع (tracing)، وهذا مثالٌ عنها: $ ./trouble.bash + number=1 + '[' 1 = 1 ']' + echo 'Number equals 1' Number equals 1 تستطيع أيضًا أن تستعمل الأمر set داخل السكربت لتفعيل أو تعطيل التتبع. استخدم set -x لتشغيل التتبع و set +x لتعطيل التتبع، مثال: #!/bin/bash number=1 set -x if [ $number = "1" ]; then echo "Number equals 1" else echo "Number does not equal 1" fi set +x ترجمة -وبتصرّف- للمقال Stay Out Of Trouble لصاحبه William Shotts.

تظهر بعض الأخطاء الشائعة بكثرة عند محاولة رفع ملفات إلى خادوم باستخدام بروتوكول FTP، وتذهب الأسباب إلى أبعد من أن تكون نتيجة خطأ في إدخال عنوان الخادوم، اسم المستخدم، كلمة المرور أو رقم المنفذ. هذا المقال موجّه إليك إن كنت تستطيع الاتصال بـ FTP محليًّا فقط، أو كنت تواجه مشكلة انقطاع الاتصال باستمرار، حيث سنلقي نظرة على الطرق المتوفرة لإصلاح أكثر 3 أخطاء شيوعًا. 1. لا يمكن إجراء الاتصال إطلاقا قد يحصل أن يبقى الاتصال غير ممكنًا حتّى بعد التحقق من أنّ بيانات الاتصال صحيحة، وتكون الخطوة الأولى باتجاه الحل هي التحقّق من نمط الإرسال في الإعدادات، هل هو سلبي passive أم نشط active؟ سنستخدم FileZilla كمثال لتوضيح الفكرة، فبعد فتح البرنامج نضغط على "تحرير Edit" في القائمة العُلويّة، ونختار "إعدادات Settings". في النافذة التي ستظهر لنا، نقوم باختيار "FTP" ضِمن "الاتصال Connection" وذلك في شجرة الخيارات التي تظهر جانبًا، للتحقّق فيما إذا كان الاتصال في النمط passive أو active، فإن كان النمط سلبيّ passive (وهو الافتراضي) فقم بتغييره إلى النمط النشط active، أو العكس كما في الصورة: لنختر الآن العنصر المسمّى "النمط السلبي Passive mode" في القائمة، ونقوم بتفعيل خيار "رجوع كامل إلى النمط النشط Fall back to active mode"، فإن كان الخيار نشطًا، قم بتفعيل الخيار الثاني بدلًا عنه "استخدام عنوان IP الخارجي بدلًا من ذلك Use the server’s external IP address instead"، وتأكّد من ألّا تقوم بتفعيل الخيار الثاني المذكور إلّا إذا اخترت نمط الاتصال السلبيّ passive سابقًا، تبيّن الصورة التالية الخطوات المذكورة: لا تنس الضغط على زر "حسنًا OK" في الزاوية اليمنى السفلية لحفظ تغييراتك، ومن ثم حاول الاتصال بالخادوم مجدّدًا. 2. خطأ "العديد من الاتصالات Too Many Connections" إن كنت قادرًا على الاتصال بالخادوم دون مشاكل، لكنّ الاتصال يستمر بالانقطاع عند محاولة رفع أو تنزيل ملفّات، فقد يكون هناك عدة أسباب لذلك، ومنها ظهور خطأ يخبرك بوجود العديد من الاتصالات، فهو يرجّح غالبًا أنّ إعدادات خادومك لا تسمح إلا بعدد قليل من الاتصالات عبر FTP، وقبل أن نبادر إلى إصلاح الخطأ، تأكّد بأنّك قمت بإنهاء اتصالك الحالي عبر FTP قبل المتابعة وإلا ستمضي ساعات في محاولة إصلاحه. وبهدف التوضيح، سنستخدم لوحة تحكّم الخادوم WHM كمثال حول إصلاح هذه المشكلة. فبعد تسجيل الدخول في WHM، نتوجه من الصفحة الرئيسية إلى صفحة "إعدادات الخدمة Service Configuration"، ومنها إلى "إعدادات خادوم إف تي بي FTP Server Configuration"، حيث سنرفع عدد الاتصالات المسموحة في حقل الحدّ الأعلى للاتصالات وحقل الحدّ الأعلى للاتصالات لكل IP، وستكون الأمور بخير طالما أنّ هذين الرقمين أعلى مما كانوا عليه من قبل. عادة ما أقوم بوضع الرقم 100 في كل حقل لأكون بأمان، ولا تنس أن تضغط على "حفظ Save" في أسفل الصفحة لتخزين التغييرات. يتطلب دخول لوحة تحكم WHM أن تملك صلاحية مدير النظام root، فإن لم تملك هذه الصلاحية قم بالاتصال بمزوّد خدمة الاستضافة واشرح المشكلة لهم لمساعدتك. حان الوقت الآن لإيقاف الاتصالات الحاليّة يدويًا، وسنوضّح كيف يتم ذلك عبر لوحة تحكّم العميل cPanel. فبعد تسجيل الدخول إلى الّلوحة، نتوجّه إلى قسم الملفّات ونضغط زر "إدارة جلسات إف تي بي FTP Session Control". سنقوم في الصفحة التي تظهر لنا، بإغلاق جميع الاتصالات المعروضة بالضغط على زرّ × الأحمر الموجود على جانب كل سطر، وبعد الانتهاء نضغط زرّ إعادة التحميل reload لتحديث القائمة والتأكّد من عدم تبقّي أيّة اتصالات. هنا يكمن الجزء الذي يكون من المهمّ فيه أن تكون قد أنهيت اتصالك الحالي في البرنامج الذي تستخدمه للاتصال عبر FTP كما أشرت سابقًا، فلو لم تقم بذلك سلفًا، ستجد المزيد والمزيد من الاتصالات التي تظهر لديك في القائمة عند كل تحديث لها، الأمر الذي قد يضيع لك الكثير من الوقت قبل أن تكتشف السبب. وحتى لا تتفاجأ، فمن الطبيعيّ أن تجد العديد من الاتصالات التي ستضطر لإنهائها، خصوصًا إن كنت تواجه هذه المشكلة تحديدًا، لذا تأكّد من أنّك قمت بإنهاء جميع الاتصالات حتى آخر واحد منها. لنعد الآن إلى FileZilla ونضغط على "تحرير Edit" في القائمة، ومن ثمّ "إعدادات Settings" وأخيرًا نختار عنصر القائمة المسمّى "عمليات الإرسال Transfers"، ونتأكد من أنّ قيمة "أقصى عمليّات متزامنة للإرسال Maximum simultaneous transfers" ليست كبيرة وعادة ما تكون هذه القيمة إما 1 أو 2. لا تنس أن تقوم بحفظ أيّ تغييرات قد أجريتها أيضًا. يجب أن تكون الآن قادرًا على إجراء اتصال وتحميل أو تنزيل بعض الملفّات، ولكن إن بقيت تعاني من مشاكل، فعد مجدّدًا إلى "عمليات الإرسال Transfers" وتأكّد فيما إذا كان الحدّ من عمليات التحميل والرفع المتزامنة إلى حوالي 5 أو 10 سيساعد في حلّ المشكلة، فهو يساعد في بعض الحالات النادرة رغم أنّه غير ضروري عادةً. 3. خطأ في إرسال ملف أثناء رفعه إن كنت تستلم رسالة خطأ غريبة عادة عند محاولة رفع الملفات، فإنّ سببها معظم الوقت هو الوصول إلى الحدّ الأقصى لحجم الملف المسموح رفعه. لحسن الحظ فإنّ من السهل تصحيح هذه المشكلة إن كنت تملك صلاحية مدير للنظام ولكن إن لم تكن فسيتوجّب عليك الاتصال بمزوّد خدمة الاستضافة لإجراء التصحيح. لنرى كيف يتم التصحيح باستخدام لوحة تحكم WHM. نتوجّه أولًا إلى "إعدادات الخادوم Server Configuration" في القائمة ثمّ إلى صفحة "محرّر إعدادات بي اتش بي PHP Configuration Editor". بعدها نختار "النمط المتقدّم Advanced mode" في أعلى الصفحة لتظهر جميع الإعدادات المتاحة، كما في الصورة: سنجد إلى الأسفل قليلًا خيارين هما "post_max_size" و "upload_max_filesize"، سنقوم بزيادة الرقم الموجود في الحقلين إلى أيّ قيمة نرغب بها ولكن تذكّر فقط بأنه في حال وضع قيمة كبيرة جدًا فسنخاطر بأن نتجاوز مساحة التخزين المخصصة من مزوّد خدمة الاستضافة. أستخدم عادة القيمة 3000M (التي تعني 3000 ميغابايت) وأجدها مناسبة لي، لكنّي أعلم مسبقًا بأنّي أملك مساحة التخزين الكافية لها، لذا فإن استخدام القيمة 120M - 320M تبدو عمليّة أكثر بشكل عام. لا تنس ضغط زرّ "حفظ Save" في أسفل الصفحة عند الانتهاء، ومن ثمّ حاول مجدّدًا رفع ملفّاتك ويفترض أن تتم العمليّة بنجاح، ولكن في حال لم يحدث ذلك، فتأكّد مجدّدًا من أنّ حجم كلّ ملف من الملفات التي تحاول رفعها أقل من القيمة التي اخترتها. الخلاصة من المحتمل جدًّا أن تضطرّ إلى اتباع الخطوات الثلاثة السابقة للوصول إلى النتيجة المرجوّة، ولكن إن استمرت المشكلة، فإنّ هذا هو الوقت المناسب للاتصال بمزوّد خدمة الاستضافة لمساعدتك، فقد تكون المشكلة متعلّقة بالخادوم لديهم. من المهمّ جدًّا في حال رفع ملفّات موقع ويب، التحقّق فيما إذا كان الموقع يعمل عند طلبه عبر شبكة الإنترنت، فإن لم يكن كذلك فسيكون لديك مشاكل أخرى يتطلب معالجتها أولًا. فيما عدا ما ذكرناه، فقد أصبح لديك ما تحتاجه لنقل ملفّاتك عبر FTP دون أخطاء. ترجمة -وبتصرّف- للمقال 3Common WordPress FTP Upload Errors and How to Fix Them لصاحبته Jenni McKinnon.

إنّ تتبّع أنشطة المبيعات قد يكون أمرًا صعبًا، ففي لحظة تجد أنّ عملك مع عميل محتمل يسير على أكمل وجه، وفي اليوم التالي تدرك أنّ فرصة البيع تلك قد ضاعت منك بعيدًا. وفي بعض الأحيان يكون مسار المبيعات sales pipeline رائعًا في بداية الربع، مع ذلك ينتهي الأمر بإنهاكك وعدم وصولك إلى الهدف المنشود. إذًا ما الخطأ الذي ارتكبته؟ ربّما يكون السبب هو عدم التخطيط لمسار المبيعات وإدارته بكفاءة. فقد وجدت دراسة نُشرت في مجلة Harvard Business Review أنّ ما يقارب نصف المدراء التنفيذيين (44%) لشركات (B2B (Business-to-Business يعتقدون أنّ مؤسساتهم تدير مسارات مبيعاتها بشكل سيّء. وكلما ساءت طريقتهم في إدارة عملية البيع، قلّت قدرتهم على تحقيق نمو في عائداتهم. وبالعكس، إذا كانت عمليات البيع تُدار بصورة جيّدة ستساعد على تحقيق نمو إيرادات سنوي يصل إلى 28%. مع ذلك، ليس هناك سرّ حقيقي أو طريق مختصر للنجاح في المبيعات، فالأداء المتميّز في المبيعات دائمًا يتطلّب العمل الشاق. لكّن اتّباع منهجيات مُحدّدة في مجال المبيعات ستسهّل عليك الأمور كثيرًا، وسترتقي بك إلى مستوى أعلى من الاتساق في تحقيق النجاح. ففي النهاية لا يتعدّى علم المبيعات أكثر من منهج فعّال، ومقدار الوقت والجهد الذي أنت على استعداد لاستثماره. ابذل المزيد من الوقت والجهد مع المبيعات، وستكون لديك فرصًا أكبر للنجاح. بإمكانك أن تحقق تقدمًا بدراسة منهجك الحالي والمعالجة الحازمة لأخطاء المبيعات التي يواجهها فريقك بانتظام. فيما يلي قائمة من التحديات الرئيسية التي يواجهها موظفو المبيعات: 1. منهجية المبيعات Sales Process غير محددة بوضوح في العادة، يُواجَه هذا التحدي فقط في الشركات الناشئة في مراحلها المبكرة أو المنتجات التي أطلقت حديثًا. يجب أن تركّز منهجيّة المبيعات Sales Process لشركتك بالدرجة الأولى على عملائك وتعكس سلوكهم الشرائي. يجب أن لا تكتفي أبدًا بمنهجيات المبيعات العامة. وعلاوة على ذلك، تتغيّر معالم السّوق وقواه، وسلوك العميل مع مرور الوقت، وفي بعض الأحيان بوتيرة أسرع مما يُتوقّع. لذلك طوّر منهجية المبيعات حسب مقتضى الحاجة. 2. الفهم الضحل للعملاء واحتياجاتهم إذا كان هناك عامل وحيد ينهض بالشركة الناشئة أو يحط بها فهو فهم العملاء واحتياجاتهم. تملك بعض المنتجات أو الخدمات التي تم تطوريها في الماضي طموحًا وتطورًا إبداعيًا أو تقنيًا أكثر من المنتجات المنافسة لها، لكنّها مع ذلك تفشل، ولسبب واحد بسيط: المنتج لا يجذب العميل. والشيء نفسه ينطبق على منهج المبيعات؛ فإذا كان يتجاهل كيفية شعور العميل، سيصبح من الصعب جدًا، وأصعب من المتوقّع بيع حتى أكثر المنتجات روعة. تحدّث مع العملاء وابنِ محادثات حول احتياجاتهم والمشاكل التي يريدون حلّها. ثم أشرك فريق المبيعات لتحديد كل مرحلة من مراحل دورة المبيعات بشكل صحيح اعتمادًا على التغذية الراجعة من العملاء. وهذا سيساعدك على رسم مسار مبيعات أكثر دقّة والذي من شأنه أن يرشدك إلى مكان العميل، بالإضافة إلى سلوكه المحتمل، في كل مرحلة من مراحل الدورة. 3. محاولة جذب العميل غير المناسب بمجرد الانتهاء من إقامة محادثات جارية مع العملاء وتدوين الصفقات المنتهية، يجب أن تكون قادرًا على إنشاء ملف تعريفي للعميل المثالي customer profile، بالإضافة إلى ملف دقيق للعملاء الذين من المحتمل أن يأخذوا الكثير من وقتك ويتركوك معلقًا دون الوصول إلى نهاية للصفقة. وبما أنّه يجب أن تقوم بإتمام الصفقات بأسرع وقت ممكن، التزم مع العملاء الذين يتناسبون والملف المثالي، واقضِ وقتًا أقل بكثير مع النوع غير المناسب من العملاء المحتملين. 4. فهم غير مكتمل لكيفية الفوز بالصفقات أو خسارتها المبيعات ليست مجرد النجاح في إبرام صفقة البيع أو الفشل في إبرامها. فمن المهم أن تفهم ما هي العوامل التي أدت إلى النتيجة الحالية ومن ثمّ تدمج هذا الفهم أو الإدراك مع منهجك في المبيعات. راجع أنشطتك ومراسلاتك مع العملاء المحتملين الذي قاموا بشراء منتجك ومع أولئك الذين لم يفعلوا، ولاحظ تفاصيل الأنشطة التي قد تؤدي إلى رؤى واضحة حول التوقيت الصحيح، منهج البيع، أو التسعير، والتي يمكن أن تساعدك على توليد العملاء المحتملين. 5. قلة التركيز/تحديد الأولويات قد تفقد أنت أو فريقك التركيز وتبذل المقدار غير المناسب من الوقت والطاقة على المهام ذات التأثير الضئيل. هناك قصة قديمة حول وضع الصخور، الحصى، والرمل في وعاء. إذا قمت بوضع الحصى والرمل أولًا في الوعاء، لن يتسع المجال لوضع الصخور فيما بعد. لكن إذا قمت بوضع الصخور أولًا، وصببت الرمل والحصى بعد ذلك، سيتّسع الوعاء لكل شيء. تفكّر في هذه الحكمة وطبّق نفس المبدأ على منهجك في البيع، ووضح لمندوبي المبيعات في فريقك أي الصفقات التي يجب متابعتها، أو أي الأنشطة التي يجب البدء بها والتركيز عليها في الوقت الحالي. 6. التركيز على النتائج بدلا من الأنشطة فيما مضى، كان صبّ الجهود نحو النتائج من صفات القائد أو المهني الرائع. ربّما ما تزال هذه الصفة تحمل معنى إيجابيًا اليوم، لكن عندما يتعلّق الأمر بالمبيعات، فإنّ التركيز على الأنشطة يمكن أن يعود عليك بنتائج أفضل؛ أي تحقق مبيعات أعلى. والسبب في ذلك هو أنّ البحوث أظهرت أنّ تحديد الأهداف الموجهة نحو النتائج أقل قابلية للتحقيق من تحديد الأهداف التي تركّز على الأنشطة. والفكرة هي أن تقوم بتحديد أنشطة ذات مستوى ونوع مناسب لتحقيق النتائج المرغوبة. 7. عدم وجود صلة بين أنشطة المبيعات الأساسية والأهداف بما أنّ الأنشطة تنافس النتائج بكونها العامل الأكثر قابلية للتطبيق الذي يجب وضع الأهداف من أجله، من المنطقي تحويل أنشطة المبيعات الأساسية والمحددة إلى أهداف بحد ذاتها، مثل مكالمات العميل، الاجتماعات الترويجية، المراسلات، وغيرها من الأحداث. بهذه الطريقة تقوم بوضع رقم محدد ودقيق لفرص المبيعات لتحقيق نسبة نجاح مقبولة لفترة معيّنة. على سبيل المثال، إذا كنت تحتاج إلى إتمام خمس صفقات لتحقيق الأرباح التي تستهدفها، وكانت نسبة نجاح البيع هي واحد من كل خمسة، فيجب أن تحدد نشاط يركّز على هدف توليد على الأقل 25 عميل محتمل في الفترة. 8. عدم تخصيص الوقت بكفاءة بما أنّ المبيعات هي بمثابة لعبة أرقام (أي كلما زاد عدد الصفقات التي تعقدها في أقل وقت ممكن، زاد عدد مبيعاتك)، فإنّ نجاحك يعتمد بشكل كبير على مدى سرعتك في إتمام صفقات البيع. وهذا يعني أنّه يجب أن تخطط لوقتك عبر جميع الأنشطة في عملية البيع، بتقليل الوقت الذي تقضيه على العملاء المحتملين غير المناسبين، تحديد الأولويات لأنشطتك التي ستولّد أفضل النتائج، وإيجاد الإطار الزمني الأكثر فعالية للعروض، المكالمات الأولية، المتابعة، والأنشطة الأخرى. 9. عدم استخدام الأدوات/التقنيات المناسبة يجب أن تستخدم الأدوات أو التكنولوجيا المناسبة للمساعدة على توليد الصفقات، واعتمادًا على المجال الذي تنشط فيه، نموذج الأعمال، وحجم فريق المبيعات. فإذا كان الفريق صغيرًا وينفّذ عمليات بسيطة، سيكفيك استخدام قالب مسار مبيعات مبسّط. وبخلاف ذلك، يجب أن تقوم بدراسة فيما إذا كانت الأدوات التي تستخدمها (إن وجدت) تناسب احتياجاتك التشغيلية والاستراتيجية. لقد أصبحت العديد من المجالات أكثر تنافسية من ذي قبل، ونتيجة لذلك يخدم نوع التكنولوجيا أو الأداة المحددة التي تعتمدها كنوع من العوامل التي تقلب الموازين وترجّح الكفّة في صالح الشركات التي تستغل الموارد التي تطابق نماذج الأعمال الخاصة بها بصورة مثالية. كقاعدة عامة، الجأ إلى الحلول السّحابية، التعاونية، والمتوافقة مع الأجهزة المحمولة والتي تتميز بقدرات تحليل قوية. 10. التركيز غير العملي على البيانات والتحليلات قد يفاجئك هذا الأمر، لكنّ بعض موظفي المبيعات يشكون من أنّ إدارة علاقة العملاء CRM في شركاتهم تتطلّب كمًا هائلًا من البيانات (بعضها غير ضروري)، مما يضرّ بسرعة، وأحيانًا دقّة استخدام التّحليلات. صحيح أنّه من الجيّد معرفة أكبر قدر من المعلومات ذات الصلة بصفقة أو عميل محتمل، لكنّ تبسيط العملية للتركيز على إتمام صفقات البيع سيؤدي إلى امتلاك معدل عائدات أعلى على المدى البعيد. لذلك الجأ إلى الحلول الذكية ذات قدرات تنبؤ دقيقة، وإلى الخصائص التعاونية القوية التي تتيح لجميع أصحاب المصلحة المساعدة في بناء بيانات حول الحسابات، بالإضافة إلى الواجهات البديهية لتمثيل الإحصاءات والرؤى الفعّالة للشركة. 11. عدم استخدام البيانات لتحسين منهج المبيعات إذا لم تكن تدرس نجاحك وفشلك بشكل دوري لاستنباط الرؤى وجمع المعلومات منها، فأنت تهمل أحد الأنشطة الضرورية في عملية المبيعات والمُتمثّل في التعلّم. تتيح لك التحليلات إمكانية تبسيط عملية البيع، والذي بدوره يمكّنك من تحقيق الكثير مقابل بذل القليل. وباستخدام البيانات لتحسين منهجك في البيع، ستقوم بصياغة خطة لنمو شركتك. لم يفت الأوان بعد على إصلاح مسار المبيعات لكي تحافظ شركتك على نجاحها، يجب أن تحرص على تعقّب منهج المبيعات ومواءمته مع السلوك المتغيّر لعملائك. تحقق فيما إذا كانت هناك حاجة إلى تغيير المراحل التي تكوّن دورة المبيعات، ثم قم بتكرار ذلك iteration على منهج المبيعات عند الضرورة. حدد نقاط الضعف في كل مرحلة، ثم عالجها بكفاءة قدر استطاعتك. ولكي تساعد شركتك على تحقيق مبيعات أعلى، ترجم منهج المبيعات إلى مسار تعاوني ومركّز على هدف، والذي من شأنه أن يدفع فريقك إلى اتخاذ الإجراءات الصحيحة في أية لحظة. وتذكّر أنّ هناك علم لتتبّع المبيعات، وهو يبدأ بإدارة كل مرحلة من مراحل عملية البيع بكفاءة. ترجمة -وبتصرّف- للمقال 11Rookie Sales Mistakes That Are Killing Your Performance لصاحبه: Joseph Mapue. حقوق الصورة البارزة: Designed by Freepik.

والآن وأنا في السّنة العاشرة من عملي الحر كمصمّمة مع رُوّاد الأعمال والمسوّقين، أجد مراجعة سنواتي المهنيّة ممتعة ومخيفة في آن واحد فقد عشت خلالها النّجاح العظيم والفشل الذريع. والنصائح التي أقولها هنا هي خلاصة تجارب شخص لم يفشل مرة أو مرتين بل العديد من المرات، وللمفارقة فإن هذا الفشل هو ما أكسبني خبراتٍ عظيمة . وأملي أن أُجّنبك القليل من الأخطاء التي ارتكبتها بدوري، وأن تَتحقّق بدورك من صحة القرارات التي اتخذتها خلال عملك الحر. حاول أن تتعامل مع الأسئلة التالية كاختبار لك، هل أنت مستقل مبتدئ كثير الأخطاء؟ اكتشف ذلك بنفسك. هل تثق بانطباعاتك ؟ إذا انتابك إحساس غير طبيعي عند لقائك لعميل ما، اتركه. لا أجد مفردات أكثر للتعبير عن الفكرة إنه فقط الشعور الذي يستولي عليك عندما تقابل شخصًا ما لأول مرة، تسمع قصّته وماذا يريد أن يقوم به. جميعنا ينتابنا شعور ما في حالات مشابهة؛ وهذه حقيقة لابد من مواجهتها: الحدس أداة مهمّة لاتخاذ القرارات في مجال الأعمال. ربما نجَم نفورك من العمل نفسه من كونه غير مناسب لمهاراتك أو ربما بسبب شخصية العميل. وبواقع التّجربة، في كل مرة انتابني شعور سيء تجاه مشروع أو عميل ما ولم أصدق حدسي كان نصيبي الفشل فيه (رغم ما أتعلّمه بسبب ذلك) هل أنت صادق مع نفسك ومع مواهبك؟ لقد كنت الأسوأ على الإطلاق في هذا الموضوع لطالما أردت أن أكون كل شيء للعملاء مصمّمة ومديرة أعمال ،الحقيقة أنني لست رسّامة ولست خريجة جامعات عريقة. وبالنسبة لي فأنا أحتاج إلى مستوى معين من غير الرسمية في علاقتي مع العملاء والشفافية التامة فيما يتعلق بموهبتي كمصمّمة.أظهر كل ما تحتاجه لتكون الشّخص الذي أنت عليه، لا تخف، دع شخصيتك تظهر بشكلها الطبيعي عندما تتعامل مع العملاء، إنها لمستك الشخصية "علامتك التجارية" التي ستجعلهم يصفونك دومًا بأنّك "غير تقليدي”. هل تحتفظ بنسخة احتياطية من بياناتك؟ رعب فقدان البيانات وملفات العمل الثّمينة يشبه الرعب الناجم عن مشاهدة ثلاثة أفلام رعب في آن واحد أشعر بالإحراج عندما أعترف بأني خضت هذه التجربة مرتين. وهو مُحرج حقًا لأنه من السهل جدًّا حفظ نسخة احتياطية من البيانات، ولكن مشكلتي أني لا أفكر بالأمور التّقنية والشبكات..الخ كجزء من عملي مثل العديد من المصمّمين إلى أن ينفجر شيء ما في وجهي وأجد نفسي بعدها مستلقية على الأرض أبكي في مشهد مريع للغاية. حقيقةً عندما تعمل لصالحك الشخصي فإن حفظ نسخة عن بياناتك هو مسؤوليتك أنت وواجبك تجاه نفسك وعملائك، وهي عملية بسيطة وسهلة عليك أن تجعلها أولوية أثناء عملك. إليك بعض الخدمات التي استخدمتها أو بحثت عنها والتي تساعدك في ذلك: Dropbox: هو خطّتي القادمة لحفظ البيانات الخاصة بعملي، فقد دعوت بعض الأصدقاء لتجربة هذا التطبيق وحصلت نتيجةً لذلك على مساحة تخزين مجانية تقارب 20 غيغا بايت وهو تطبيق موثوق وفعّال. Google Drive: هو خيار غير مكلف تقريباً 4.99$من أجل 100غيغا بايت من السعة التخزينية.لقد استخدمت هذه الخدمة وكنت مسرورة بها ولكني وجدت عملية المزامنة فيها أبطأ مُقارنة بـDropbox. CrashPlan أو Carbonite: قمت مؤخرًا بالبحث عن خيارات التخزين لكميات كبيرة من البيانات مايقارب 4TB. Dropbox هو تطبيق ممتاز للمشاريع الحالية والبيانات التي أريد الوصول إليها من قواعد اعتيادية، ولكن مازال لدّي تيرابايتات من بيانات العملاء السابقين والتي لا أثق بقدرتي على الوصول إليها عبر أقراص التخزين الصلبة القديمة والعديدة التي أملكها هنا وهناك. وسعر 4$ من أجل كمية غير محدودة من البيانات هو حقًّا سعر لا يُضاهى، توفر Crashplan أيضًا خدمة النسخ الاحتياطي المنظّم، حيث عليك فقط أن ترسل لهم أقراص التخزين الصلبة التي تحتوي البيانات وسيقومون بنسخها وبذلك لن تحتاج لقضاء أسابيع في رفعها على الشبكة، وهو بلا شك خيار جيّد إذا كنت تبحث عن مكان لحجوم كبيرة من البيانات. هل تعمل مع عميلك المثالي؟ عندما بدأت عملي كمصمّمة مسّتقلة كنت متحمّسة للعمل مع أي شخص، عندما تكون جديدا في الموقع من السّهل أن تفكر بهذه الطريقة فأنت بحاجة إلى عمل وإلى مدخول مالي و تُبرّر ذلك بحاجتك إلى الخبرة وأنك لا تستطيع أن تكون انتقائيًا من البداية، بالطبع أنا أفهم هذا التفكير ولكن كلما أسرعت في تحديد نمط العملاء والعمل الذي يحفّزك ويجعلك متحمّسا للاستيقاظ في الصّباح للعمل كلما كان ذلك أفضل. بالطبع علينا جميعاً أن نتعلم العمل مع جميع أنماط الناس، لكن إذا لم تُكوّن نوعًا من الصّداقة مع العميل قبل توقيع العقد أو استلام المشروع فلربما هذا العميل ليس من نوعية العملاء المثالية بالنّسبة لك. ولكن بطبيعة الحال عقود العمل الحر تطبق غالباً على مشاريع لمرة واحدة فقط فإنّ هناك احتمال كبير أن لا يتوفّر لك الكثير من الوقت لبناء وتطوير هذه العلاقة / الصّداقة مع العميل. ونادرًا ما ستمتلك وقتًا كافيًا لتعرف المزيد حول العميل وبناء علاقة صداقة معه إلّا في حال وَقّعت عقدًا طويل الأمد، أمّا في المشاريع القصيرة المدى سيكون عظيما جدًّا إذا استطعت اختيار عملاء بإمكانك العمل معهم بدون خلاف ناجم عن صراع العلاقات الذي يظهر في البداية. لقد اكتشفت هذا بعد أن خسرت بعض العملاء وبعدها عرفت مالذي أبحث عنه في العميل، ربما ستحتاج أن تمر بهذه العملية لتتمكن من تحديد عميلك الأمثل. هل لديك ميزانية محددة لنشاطك كعامل مستقل؟ عندما تنطلق في عملك كمبتدئ في مجال العمل الحر تكون لديك رغبة ملّحة لتأمين كل ما تحتاجه من أجل العمل كمستقل بكفاءة – على الأقل هذا ما حدث معي– حيث اشتريت الكثير من العتاد (حاسوب، شاشة خارجية، فأرة مُتطّورة، لوحة مفاتيح مُتقّدمة جدًا...) حيث أنني مهووسة بالتّقنية وأحب مثل هذه الأشياء. لكن بعد أن تختفي مشاعر الفرحة بكل هذا العتاد الجديد، ستجد بأنّك قد اشتريت أمورًا كثيرة ربما لست بحاجة لها الآن أو أنه بإمكانك تنفيذ عملك على أكمل وجه من دونها. الأدهى والأمر هو لما تقترض لشرائها. لذلك قرّر ماهو الحد الأدنى الذي تحتاجه لسير نشاطك بسهولة واكتب قائمة بالأشياء التي تتمنى شرائها في المستقبل وستكون محفّزًا رائعًا لك خلال عملك. هل تسوق لنفسك كمجموعة وليس كفرد؟ إذا كنت تعمل لوحدك تأكد أن عملاءك يعلمون ذلك، من الجيّد أن تدير عملك الحر تحت اسم مجموعة ولكن قد يسبب هذا إرباكًا للعملاء، ويعتقدوا أنه لديك موظّفين يعملون بأدوار مختلفة في المشاريع، برأيي يجب أن تكون واضحًا وشفّافًا حول من تكون، ماذا تفعل وما لا يُمكنك القيام به. ماذا يحصل عندما لا تكون صريحاً حول استخدام متعاقد خارجي لأداء جزء من العمل ؟ المشكلة الأصغر مع عمل هؤلاء المتعاقدين هي على صعيد المسؤولية، إذا كان المتعاقد الخارجي يؤدي عمله بشكل مثالي دائمًا فهذا جيّد، أما إذا لم يكن؛ فتوجيهاتي لك إذا كنت لا تستطيع القيام لوحدك بالمشروع كاملًا، هو أن تُعطي العميل الخيار بتوظيف مستقل آخر لأداء هذا الجزء من العمل. وهذا يعود بنا إلى فكرة اختيار العميل المثالي، إذا كان العميل يبحث عن مستقل واحد لأداء كامل المشروع فربما لا يكون العميل الأمثل لك. هل وقعت عقدا قبل البدء بالعمل؟ لا يهم مهما كان حجم المشروع كبيرًا أم صغيرًا فالعقد بيان العمل وقائمة التسليم هي أمور ضروريّة جدًا قبل البدء بأي مشروع وإلا كيف ستتفق مع عميلك عن التّوقعات و شروط الدفع؟ أتذكر أنني كنت متوترة دومًا حول الطلب من العميل أن يُوقّع عقد عمل قبل البدء به والآن أدرك تماماً أن توتري ذلك كان ناجما عن خوفي من خسارة العمل في حال طلبت ذلك والآن أعلم أن العميل الذي يرفض توقيع العقد في البداية هو ليس العميل الأفضل لي. هل أضفت قيمة حقيقية لعميلك؟ ربما فعلت ولكنك لست متأكدًا ماهي القيمة التي أضفتها، اسأل عملاءك الحاليين والسّابقين غالبًا سوف يُوضّحون لك السبب الذي من أجله يعملون معك مرة تلو الأخرى أفضل مما ستعرف أنت. هل تريد طريقة واحدة تتغلب فيها على منافسيك؟ طريقة تنجح فيها كل مرة لأن لا أحد يفعلها ؟وفّر خدمة عملاء لا نظير لها. فكّر فيها قليلاً؛ نحن نعيش في عالم لا تُقَدّم فيه خدمات للزّبون الذي يتوق بدوره لاهتمام من بائعيه، لذلك إذا أردت أن تتميّز وتصنع قيمة مضافة لعملك حدّد ماهي خدمة العملاء الأفضل التي يحتاجها زبونك وقم بذلك. هل تتقاضى الكثير أو أقل من القدر الكافي؟ إذا كنت تتقاضى القليل جدًا مقارنة بعملك فهذا مأزق بلا شك أما إذا كنت تتقاضى أكثر مما يحدّده السوق لموهبتك فهذه مشكلة أيضًا، كنت أبحث عن مُصمم مستقل لتنفيذ بعض المهام منذ أشهر، وتواصلت مع مُصمّم تخرّج من مدرسة التصميم منذ أقل من سنة ومعرض أعماله شبه فارغ، وحدّد تسعيرًا ساعيًا سيكون مناسبًا لو كان معرض أعماله تحتوي أعمالًا بجودة ذلك السعر ولكن الأعمال التي شاهدتها لم تكن بجودة نصف هذا السّعر. الحل أن تنظر إلى ما يتقاضاه أقرانك وأقصد بالأقران الأشخاص الذين لديهم أعمال بجودة مقاربة لجودة عملك. هل لديهم مشاريع يعملون عليها بشكل متواصل وتضمن لهم دخلاً ثابتًا؟ إن كان الأمر كذلك فهذا يعني بأن الأسعار التي يطلبونها متوافقة مع جودة الأعمال التي يُقدّمونها. بالتالي بإمكانك أن تبدأ من هذا السعر. هل تنظم وقتك بشكل جيد؟ بعد أن تحدّد أفضل أوقات العمل بالنسبة لك اصنع جدولًا والتزم فيه، لا يهم إن كانت إنتاجيتك أعلى في المساء أو الصباح الباكر فصنع روتين خاص بيوم عملك هو طريقة تساعدك في قياس إنتاجيتك وإدارة تواصلك مع العملاء. بالنسبة لي فإن وقت العمل الأفضل يكون في الصباح، أما بعد العشاء فأعمل على تلك المهام التي لا تحتاج إلى ذكاء إبداعي وهذا يتغير أحياناً خلال السنة وأعدل برنامجي تبعًا له. لا تدري كيف تنظّم وقتك؟ شاهد هذه الفيديو والتي يشرح فيها صاحبها كيف يستخدم الورقة والقلم لتحديد قائمة مهامه: ماهي أخطاؤك كمستقل مبتدئ؟ لست أنا الوحيدة التي أملك قصصاً رهيبة عن العمل الحر أليس كذلك؟ شاركنا بتجاربك، ما الأخطاء التي ترتكبها وما النّصائح التي ترغب في تقديمها لغيرك من المُتسقلّين؟ ترجمة -وبتصرّف- للمقال:Top 10 Mistakes Made by New Freelancers لصاحبته: Jen Gordon.

أنا فخور بفريقنا الذي أسسناه، لكنّ الوصول إلى هذه المرحلة لم يكن أمرًا سهلًا. وسأتحدث في هذا المقال عن أخطائنا الموجعة التي ارتكبناها عند توظيف الموظفين. عندما تقوم بزيارة صفحة "من نحن" لأي شركة، ستجد على الأغلب ترويسة تحتوي على العبارة التالية (أو ما شابهها): "نحن [نحل مشكلة معيّنة] لـ [عميل معيّن]" الشيء الثابت والمشترك بين جميع الشركات هو أنّ الكلمة الأولى غالبًا ما تكون "نحن". وكما هو متعارف عليه، أنّ أساس أي شركة ناجحة هو فريقها، وأنّ تحقيق النجاح سيصبح عسيرًا جدًا بدون أولئك الناس الرائعين. من النصائح المتكررة والشائعة التي أسمعها من روّاد الأعمال الذي يعملون على شركاتهم الثانية أو الثالثة هي أنّه بعد المراحل الأولى من النمو، يجب أن ينصبّ تركيز المدير التنفيذي على التوظيف، وإذا لم يستطع القيام بذلك على الوجه الصحيح، ستصبح كل الأمور الأخرى غير مهمة. حتى أنّ أفضل الأفكار ستفشل وتنهار على أكتاف الأشخاص الذي لا يستطيعون تنفيذها. إنّ العثور على الأشخاص الرائعين، الموهوبين، والشغوفين، وكذلك توظيفهم والحفاظ عليهم هو من الأمور التي حاولت القيام بها منذ بداية شركتنا Groove، وبعد ثلاث سنوات من نشأتها، كانت لدينا العديد من العثرات. بعضها كانت ثانوية ولم ينتج عنها سوى إضاعة الوقت. وأخرى كلفتنا غاليًا في الإنتاجية وكانت مضرّة جدًا بثقافة فريقنا، مما تطلب الأمر شهورًا لتجاوزها والتحسّن من بعدها. اليوم، سأشارككم أخطائي الأكثر إيلامًا (والأكثر أهمية) التي ارتكبتها فيما يتعلّق بالتوظيف في شركتي، وعلى أمل أن أتمكّن من مساعدتك في تجنّب الوقوع فيها بنفسك. 1. عدم التحقق من المراجع بدقة كافية تنويه: نقصد بـ"المراجع" references هنا قائمة بالأشخاص الذين يذكرهم المُتقدّم للوظيفة لما نسأله عن أسماء أشخاص عمل معهم في الشّركات التي ذكرها في سيرته الذّاتية (يعني للتّحقق من صحة ما يقوله في سيرته الذّاتية). نعم، أنا أدرك أنّ التّحقق من المراجع هي وسيلة غير كافية لفحص كفاءة المرشّح وأهليته. وأعلم أنّ المرشّحين سينتقون الأشخاص الذين سيشيدون بهم ويقدّمون مراجعات برّاقة عنهم. وكذلك أعلم أنّ أولئك الذين يحبّون مرشحًا معينًا، من غير المرجّح أن يقولوا أمورًا سلبية عنه. مع ذلك، أعتقد أنّه من المهم التواصل مع الناس الذين يقدّمهم المرشح كخطوة أولى. لكن، وكما تعلّمت من تجربتي، ما يفوق ذلك أهمية هو أن تبذل جهدًا أكبر في هذا الأمر وتتحقق من غيرهم من معارف المرشّح. فعالم الشركات الناشئة هو عالم صغير، والوصول إلى أعضاء العديد من الفرق في مجتمعنا لا يستغرق سوى بضع نقرات عبر البريد الإلكتروني أو لينكدإن. لذلك فإنّ الوصول إلى معلومات عن المرشّح عبر الاتصالات المتبادلة، وبعناية، مع الأخذ في الاعتبار حقيقة أنّ زملاء المرشّح الحاليين قد لا يعرفون أنه بصدد مقابلة عمل حاليًا، يمكن أنّ يجنّبك الكثير من المشاكل في المستقبل. منذ سنوات مضت، كان لدينا موظف لم يدم في وظيفته أكثر من شهرين. لقد كان رائعًا في مقابلات التّوظيف، وقد تحققنا من المراجع التي قدّمها، لكنّه ببساطة لم ينجح عندما تعلّق الأمر بالعمل. وبعد أشهر من فصله عن العمل، التقيت في أحد الاجتماعات بأحد معارف ذلك الموظف الذين عملوا معه من قبل. وبدون حتى الكشف عن الكثير حوله، اتّضح بسرعة أن مكالمة هاتفية سريعة معه قبل أن أتقدم بعرض إلى ذلك الشخص كان بإمكانها أن تجنّبني توظيفه. ومنذ ذلك الحين، أصبحت أبذل جهدًا أكبر (بتكتم واحترام) في التحقق من موثوقية المرشّح للوظيفة عبر طرف ثالث. 2. إضاعة الكثير من الوقت في ملاحقة المرشح يتطلّب التوظيف الجيّد الكثير من الجهد والوقت، لكنّه قد يستغرق الكثير جدًا من الوقت إذا سمحت أنت بذلك. وإحدى الوسائل للقيام بذلك هي قضاء الكثير من الوقت في ملاحقة مرشّح من غير المحتمل انضمامه. بالطبع، ينطبق هذا الأمر بشكل أقل على عمليات التوظيف عالية المستوى، إذ تصبح مجموعة المرشحين المؤهلين محدودة أكثر وأكثر كلما زاد مستوى الخبرة المطلوبة، لذلك توقّع أن تقضي الكثير من الوقت على هذا النوع من التوظيف. لكن بالنسبة لأغلب المناصب، هناك الكثير من المرشحين المتميّزين في السوق. على سبيل المثال، التسويق؛ حيث ستحصل على نتائج أفضل إذا سعيت إلى توظيف الأشخاص الذين يرغبون بالفعل في العمل معك، مقابل أولئك الذين لا يرغبون في ذلك. لقد تعلّمت هذه الطريقة الصعبة منذ سنتين مضت، عندما صادفت أحد المطورين الذي ظننت أنّه سيكون إضافة رائعة إلى الفريق. لكن الاجتماع الواحد أدى إلى ثلاثة، وقبل أن أدرك، تبين أنّني كنت أبذل كل ما في وسعي في سبيل إقناعه للانضمام إلى Groove. وفي نهاية المطاف رفض الانضمام. لكن ليس قبل أن أقضي 8 أسابيع في الأخذ والرّد، وليس قبل أن أحبط بسبب كلفة الوقت التي أضعتها بالفعل، وبسبب تصرّفي المستميت. الطريف في الموضوع هو أننا قمنا بتوظيف شخص آخر لنفس الدور، والذي عمل بصورة جيّدة للغاية، بعد أسبوعين من ذلك. صحيح أنّ السعي وراء المرشحين ذوي المؤهلات العالية يمكن أن يكون مغريًا، إلا أنني أحاول جهدي أن أنظر إلى الصورة بشكل أشمل وأن أكون أكثر مراعاة لكلفة السعي وراء الشخص الذي لا يريد الانضمام إلينا، والذي يمكن أن يعيقنا عن توظيف غيره من المرشحين الرائعين الذين يريدون ذلك. 3. التوظيف بسرعة كبيرة هناك فكرة سائدة وقديمة في عالم الشركات الناشئة: "وظّف بسرعة، وافصل/اطرد بسرعة أكبر". ومفهوم هذه الفكرة هو أنّك في الشركة الناشئة تحتاج إلى التحرّك بسرعة وعدم الإسهاب في التفكير في القرارات، لذلك وظّف بسرعة، وإذا اتضح أنّك قمت بتوظيف شخص غير مؤهل، افصله فورًا عن العمل. بعد السنوات الخمس الماضية، لم أعد أؤيّد هذه الفكرة، على الأقل الجزء الأول منها. لعلّي تعلّمت من بعض الأخطاء الأخرى، الأمر الذي جعلني أكثر حذرًا في التوظيف، لكن في كل مرّة أندم فيها على توظيف شخص ما، يتبيّن أنني قمت بتوظيفه بسرعة كبيرة ودون تفكير كافٍ. يمكن تطبيق مفهوم "وظّف بسرعة" على الشركات الناشئة الممولة بصورة جيّدة والتي يجب أنّ تستخدم الملايين من الدولارات بسرعة وتبني فريقًا يولّد نموًا سريعًا. لكن بالنسبة للشركات الصغيرة التي تنشأ من الصفر بفريق صغير، فإنّ كل عملية توظيف جديدة يمكن أن تغّير الفريق بطريقة يمكن أن يشعر بها الجميع. وقد وجدتُ أنّه من المهم جدًا بالنسبة لي أن أكون أكثر حذرًا ومنهجيّة في تقديم عروض العمل (بدلًا من الانفعال والتسرّع). وقد ساعدني هذا الأمر في مواقف عديدة في العثور على مرشحين أفضل صادفتهم بينما كنت أحاول توظيف مرشّح متوفّر ربما لا يُناسب احتياجاتي بالضبط ولكنّه يخدم الغرض. 4. عدم فصل الموظف غير المؤهل بسرعة كافية بالإضافة إلى إدراكي بأنّ التوظيف السريع ليس مناسبًا لي، تعلّمت (وبشكل مؤلم) أنّ عدم فصل الموظف غير المؤهل بسرعة كافية يمكن أن يكون معرقلًا جدًا. في الفرق الصغيرة يمكن أن يصبح وجود الأفراد السيئين ضارًا جدًا. سواء كان السبب عدم تنفيذهم للأعمال الموكلة إليهم، أو عندما تلعب أمور أخرى دورًا في الموضوع، كالأنا مثلًا. إذ أنّ حلقة واحدة ضعيفة يمكن أن تقطع سلسلة كاملة. لقد بيّن لي صديق له خبرة في مجال الشّركات النّاشئة سبب تأخير مؤسسي الشركات النّاشئة فصل الموظفين السّيئين، حيث قال لي: لا أحد منا يحب أن يكون مخطئًا، لكن أحد الدروس الصعبة التي تعلّمتها كمؤسس هو أنّ كونك مخطئًا أفضل بكثير من أن تدع الموقف السيئ يزداد سوءًا؛ وخطئي كان أنني فقط لم أكن أطبّق ذلك عندما يتعلّق الأمر بفصل الموظفين. الحقيقة هي أنّ المحادثة مع الموظف الذي ستفصله ستكون صعبة، والشعور سيكون مزعجًا، إلا أنّ عدم فصله لن يكون منصفًا لا لفريقك، ولا لعملائك، ولا لشركتك. 5. عدم معرفة قيمنا الأساسية، وتقديم الموهبة على التّوافق والانسجام مع الشركة/الفريق من أكبر الأولويات التي نركّز عليها هذه السنة هي وضع القيم الأساسية لشركتنا Groove. وما نقصده هنا هي القيم الأساسية الحقيقة التي تحفّزنا، وليست تلك العبارات التحفيزية المبتذلة. ومع أنّ هذا المشروع ما يزال قيد التطوير، إلا أنّه أثبت وبوضوح أنّ امتلاك مجموعة معرّفة من القيم الأساسية يجعل من عملية التوظيف أسهل بكثير. فمهما كان المرشّح موهوبًا، لا يمكن أن يكون مؤهلًا للوظيفة إذا لم يتناسب وقيمك الأساسية. قبل بضع سنوات، كنت متحمسًا بشكل خاص حول أحد المرشحين والذي كان في طليعة أقرانه من حيث الموهبة. وكل من طلبتُ منه التحدث مع ذلك المرشّح أعجب به. لكن في غضون أسابيع، اتضح أنّه يريد معاملة خاصّة. فهو يريد العمل على أمور "عالية المستوى"، وكان يتذمر، أو ينزعج، عندما يتوجب عليه العمل على أي شيء يعتبره أقل من مستواه. ما زالت نعمل على تحديد القيم والمبادئ الأساسية لشركتنا النّاشئة، لكن حتمًا لن يكون سلوك هذا الموظّف أحدها. ولو كان ذلك المرشّح يمثّل قيمنا الأساسية بصورة جيّدة، لربما نجح في عمله مع الفريق. 6. عدم تأكيد فيما إذا كان الفريق تقليديا (يعمل في مكتب مشترك) أو يعمل عن بعد لم يمض الكثير على تحوّلنا إلى فريق يعمل عن بعد 100%. وقد حصل ذلك بعد أن حثّني أحد مستشارينا، David Hauser، على اتخاذ هذا القرار المهم في اجتماعنا الفصلي. بالرغم من أنّنا قبل ذلك كنا دائمًا فريقًا يعمل عن بعد، إلا أنّه كانت لدي بعض الشكوك فيما إذا كان الفريق قابلًا للتوسعة، وفيما إذا كان حقًا هو مستقبل Groove. وهذه الشكوك تمت ترجمتها إلى تخبّط حول الأمر، بما في ذلك المرور بفترة كنت أسعى فيها إلى توظيف موظفين جدد بشكل حصري من المدينة التي يقع فيها مقرّنا. لقد كان هذا فشلًا كبيرًا من ناحيتين. الأولى، أنّ هذا الأمر أثّر في معنويات الفريق، حيث يتساءل الموظفون فيما إذا كان سيُطلب منهم الانتقال إلى مقر الشّركة. والثانية أنّه ألحق الضرر بالتوظيف، حيث كنت أقضي وقتي في السعي وراء أفضل المرشحين الذين استطعت العثور عليهم في منطقة/مدينة واحدة. لكنّ ذلك لا يُقارن بأفضل ما يمكن أن أعثر عليه فيما لو قمت بتوسيع بحثي. لقد قضيت أسابيع في السعي وراء المرشحين الذين كنت سأرضى بتوظيفهم، على الرغم من أنّهم ليسوا الأفضل، وهذا الأمر كان من المشتتات التي أدت إلى إبطاء تقدمنا ولفترة طويلة جدًا. وأخيرًا فتح تحولنا إلى فريق يعمل عن بعد بالكامل أفاقًا واسعة أمامنا وجعل من توظيف المواهب الرائعة دون تقديم الكثير من التنازلات أمرًا أسهل بكثير. كيف تطبق ذلك على شركتك إنّ التوظيف صعب جدًا ولكنّه من الأمور الحاسمة لنمو الشركة. وعندما تقوم بتوظيف المرشحين سترتكب الأخطاء، وربّما أخطأت بالفعل، كما ارتكبت أنا الكثير. لكنّ كلّ خطأ هو فرصة للتعلّم والقيام بما هو أفضل في المرة القادمة. آمل من خلال مشاركة أكبر أخطائي أن أساعدك في تجنّب ارتكابها في شركتك. ترجمة -وبتصرّف- للمقال Our Startup's Biggest Hiring Fails From $0-250K/Month لصاحبه: Alex Turnbull. حقوق الصورة البارزة: Designed by Freepik.

تعرفنا في الدرسين الماضيين عن مفهوم حاويات لينكس (LXC) ومبدأ عملها ثم شرعنا في كيفية البدء في استعمالها. سنعرج في هذا الدرس إلى كيفية استغلال مختلف نقاط ومراحل دورة حياة حاويات لينكس (LXC) لإدراج بعض من الإضافات (hooks) التي تقوم بإجراء مهمة ما. إضافات إدارة دورة التشغيل بدءًا من أوبنتو 12.10، أصبح من الممكن تعريف إضافات (hooks) تُنفَّذ عند نقاط محددة من دورة تشغيل الحاوية: الإضافات التي تحدث قبل التشغيل تُنفَّذ من مجال أسماء المضيف قبل أن تُنشَأ طرفيات أو نقاط وصل الحاويات؛ إذا أُجري أي وصل في هذه الفترة، فيجب أن يُنظَّف في إضافة تحدث بعد إيقاف التشغيل. الإضافات التي تحدث قبل الوصل تُنفَّذ في مجال أسماء الحاوية، لكن قبل أن يوصل جذر نظام الملفات؛ سينظف أي وصل لنظام الملفات في هذه الفترة تلقائيًا عند إيقاف تشغيل الحاوية. إضافات الوصل هي إضافات تنفذ بعد وصل أنظمة ملفات الحاوية، لكن قبل أن تُنفِّذ الحاوية pivot_root لتغيير جذر نظام ملفاتها. الإضافات التي تحدث بعد إيقاف التشغيل ستنفَّذ بعد إيقاف تشغيل الحاوية. إذا أعادت أيّة إضافة خطأً، فسيلغى تشغيل الحاوية، لكن أي إضافة تحدث بعد إيقاف التشغيل ستنفَّذ، ستُسجَّل أيّة مخرجات تولد من السكربت بأولوية التنقيح (debug). رجاءً راجع صفحة دليل lxc.container.conf لصيغة ملف الضبط التي سيحدد الإضافات؛ يمكن أن تأتي بعض أمثلة الإضافات في الحزمة lxc لتخدم كمثال حول طريقة كتابة إحدى تلك الإضافات. سطر الأوامر لدى الحاويات عدد مضبوط من «أسطر الأوامر» (consoles)؛ أحدها موجودٌ دائمًا في ‎/dev/console؛ الذي يظهر في الطرفية عندما تُشغِّل lxc-start ما لم تحدد الخيار ‎-d؛ يمكن إعادة توجيه ناتج خرج ‎/dev/console إلى ملف باستخدام ‎-c console-file في الأمر lxc-start؛ يمكن تحديد عدد إضافي من أسطر الأوامر باستخدام المتغير lxc.tty المضبوط عادةً إلى 4؛ يمكن أن تظهر أسطر الأوامر تلك في ‎/dev/ttyN (حيث N أكبر أو تساوي 1، وأصغر أو تساوي 4)؛ ولتسجيل الدخول إلى console 3 من المضيف، فنفِّذ الأمر: sudo lxc-console -n container -t 3 إذا لم تحدد الخيار ‎-t N، فسيتم اختيار سطر أوامر غير مُستخدَم؛ للخروج منه، استخدام عبارة الخروج Ctrl-a q؛ لاحظ أن عبارة الخروج لا تعمل في سطر الأوامر الناتج عن lxc-start دون الخيار ‎-d. استكشاف الأخطاء التسجيل إذا حدث شيء ما خاطئ عند تشغيل حاوية، فإن أول خطوة هي الحصول على سجل كامل من LXC: sudo lxc-start -n C1 -l trace -o debug.out هذا سيؤدي إلى جعل lxc يسجل في أعلى درجة إسهاب، التي هي trace، وسيكون ملف التخزين هو ملف باسم «debug.out»، إذا كان الملف debug.out موجودًا مسبقًا، فستُضاف معلومات السجل الجديد إليه. مراقبة حالة الحاوية هنالك أمران متوفران لمراقبة تغيرات حالة الحاوية: lxc-monitor الذي يراقب حاويةً أو أكثر ﻷي تغيرات في الحالة، حيث يأخذ اسم الحاوية مع الخيار ‎-n كالعادة؛ لكن في هذا الحالة، يمكن أن يكون اسم الحاوية تعبيرًا نمطيًا من نمط POSIX للسماح بمراقبة مجموعة من الحاويات؛ يستمر lxc-monitor بالعمل ويعرض تغيرات حالات الحاويات؛ أما lxc-wait فينتظر تغيِّرًا محددًا في الحالة ثم ينتهي تنفيذه؛ على سبيل المثال: sudo lxc-monitor -n cont[0-5]* هذا سيعرض جميع تغيرات الحالة لأي حاوية تطابق التعبير النمطي؛ بينما: sudo lxc-wait -n cont1 -s 'STOPPED|FROZEN' سينتظر إلى أن تتغير حالة الحاوية cont1 إلى STOPPED أو FROZEN ثم ينتهي. الوصل من الممكن في أوبنتو 14.04 الوصل (attach) إلى مجال أسماء حاوية، أبسط طريقة هي تنفيذ: sudo lxc-attach -n C1 الذي سيبدأ صدفة موصولة لمجال الحاوية C1، أو داخل الحاوية؛ آلية عمل الوصل هي معقدة جدًا، مما يسمح بوصل مجموعة فرعية من مجالات أسماء (namespaces) الحاوية ونمط الحماية (security context)، راجع صفحة الدليل لمزيدٍ من المعلومات. درجة إسهاب init في الحاوية إذا أكمل LXC بدء تشغيل الحاوية، لكن فشل إكمال تنفيذ init فيها (على سبيل المثال، لم يُعرَض محث الدخول)، فمن المفيد طلب درجة إسهاب أكبر من عملية init، فلحاوية upstart: sudo lxc-start -n C1 /sbin/init loglevel=debug يمكنك أيضًا بدء تشغيل برامج مختلفة عن init، على سبيل المثال: sudo lxc-start -n C1 /bin/bash sudo lxc-start -n C1 /bin/sleep 100 sudo lxc-start -n C1 /bin/cat /proc/1/status واجهة LXC البرمجية API يمكن الوصول إلى غالبية وظائف LXC عبر واجهة برمجية (API) مُصدَّرة من liblxc التي تكون ارتباطاتها متوفرة لعدة لغات برمجية بما فيها بايثون، و lua، وروبي، و go. ما يلي هو مثال عن استخدام ربط بايثون (المتوفرة في حزمة python3-lxc)، التي تُنشِئ وتبدأ حاوية، ثم تنتظر إلى أن يوقف تشغيلها: # sudo python3 Python 3.2.3 (default, Aug 28 2012, 08:26:03) [GCC 4.7.1 20120814 (prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import lxc __main__:1: Warning: The python-lxc API isn't yet stable and may change at any p oint in the future. >>> c=lxc.Container("C1") >>> c.create("ubuntu") True >>> c.start() True >>> c.wait("STOPPED") True الحماية يربط مجال الأسماء المعرفات (ids) إلى الموارد؛ لكنه لا يوفر للحاوية أي معرِّف يمكنه أن يشير إلى المورد، لذلك يمكن أن يُحمى المورد؛ وهذا هو أساس بعض الحماية الموفرة لمستخدمي الحاوية؛ على سبيل المثال، مجال أسماء IPC معزول تمامًا؛ لكن مجالات أسماء أخرى فيها بعض «التسربات» (leaks) التي تسمح للامتيازات بأن تُستخرَج بشكل غير ملائم من الحاوية إلى حاوية أخرى، أو إلى المضيف. افتراضيًا، تُشغَّل حاويات LXC بسياسة AppArmor التي تقيّد بعض الأفعال، تفاصيل دمج AppArmor مع LXC موجودة في قسم «AppArmor» في الدرس السابق، الحاويات دون امتيازات تربط الجذر في الحاوية إلى مستخدم دون امتيازات في المضيف، وهذا يمنع الوصول إلى ملفات ‎/proc و ‎/sys التي تمثل موارد المضيف، وغيرها من الملفات المملوكة من الجذر في المضيف. الثغرات في استدعاءات النظام ميزة أساسية من مزايا الحاويات أنها تشارك النواة مع المضيف؛ وهذا يعني أنه إذا حوت النواة على أيّة ثغرات في استدعاءات النظام (system calls)، فيمكن أن تستغلها الحاوية؛ وبعد أن تتحكم حاوية بالنواة، فيمكنها أن تسيطر سيطرةً كاملةً على أي مورد معروف للمضيف! بدءًا من أوبنتو 12.10، يمكن أن تقيَّد الحاوية من مرشِّح seccomp، إن Seccomp هو ميزة جديدة في النواة التي تُرشِّح استدعاءات النظام التي يمكن أن تُستخدَم من المهمة وأولادها؛ بينما يتوقع الوصول إلى إدارة سهلة ومحسنة للسياسة في المستقبل القريب، لكن تحتوي السياسة الحالية على قائمة بيضاء بسيطة لأرقام استدعاءات النظام؛ يبدأ ملف السياسة برقم الإصدار (الذي يجب أن يكون 1) في أول سطر ونوع السياسة (الذي يجب أن يكون whitelist) في ثاني سطر؛ وتُلحَق بقائمة أرقام، كل رقم في سطر. سنحتاج عادةً لتشغيل حاوية بتوزيعة كاملة إلى عدد كبير من استدعاءات النظام؛ لكن لحاويات البرامج، يمكن أن نقلل عدد استدعاءات النظام المتوفرة إلى رقم قليل؛ وحتى للحاويات التي تشغل توزيعات كاملة يمكن الحصول على فوائد أمنية إذا حذفت -على سبيل المثال- استدعاءات النظام المتوافقة مع 32 بت في حاوية 64 بت؛ راجع صفحة دليل lxc.container.conf للمزيد من التفاصيل حول كيفية ضبط الحاوية لتستخدم seccomp؛ لن تُحمَّل افتراضيًا سياسة seccomp. مصادر كتاب «Secure Containers Cookbook» يشرح كيفية استخدام أنماط الحماية لجعل الحاويات أكثر أمانًا. مشروع LXC مُستضاف في linuxcontainers.org. مشاكل LXC الأمنية مذكورة ومناقشة في صفحة وكي «LXC Security». ترجمة -وبتصرف- للمقال Ubuntu Server Guide: LXC.

راجعت مؤخرًا مئات من العروض التي قدّمتها شركات ناشئة لـ Capital Factory، وقد كان أغلبها ورقيًا ومصوّرًا (فيديو)، في حين تمّت دعوة 20 منهم لتقديم العروض بشكل شخصي. وقد تبلورت لديّ بعض الملاحظات المهمة: يرتكب الجميع نفس الأخطاء.الأشخاص الذين يتجنّبون خطأ واحد فقط من هذه الأخطاء أشخاصًا يتميّزون عن البقية.ترتبط هذه المشاكل بشكل أساسي بالمبدأ الذي تقوم عليه الشّركة النّاشئة أو بسلوك مؤسّس الشركة (ولا علاقة لها بالجانب الخاص بالبحث عن الحصول على استثمار.)من المحتمل أنّك ترتكب الكثير من هذه الأخطاء أيضًا. أرجو أن لا يتبادر إلى ذهنك أنّي ألومك على ذلك، إذ لم يتضّح الأمر بالنسبة إليّ إلا بعد مشاهدة مئات العروض، وهذا غير ممكن بالنسبة إليك. لذا أقدّم إليك في هذا المقال مجموعة من هذه الأخطاء وطرق علاجها. مزايا غير تنافسيةيعتقد المؤسّس أن المزايا التي يتحدّث عنها هي مزايا تنافسية وتُميّزه عن غيره، في حين أن ما يتحدّث عنه ليس مزايا تنافسية إطلاقًا. على سبيل المثال "لدينا إمكانيات فريدة مُتعلّقة بالـ SEO" أو "هذه المزيدة فريدة من نوعها" ليست مزايا تنافسية. للمزيد حول الأمر اقرأ هذا المقال الذي سبق وأن كتبته حول الأمر: لا، هذه الميزات لا تجعل شركتك الناشئة أفضل من غيرها. خلو الشركة من أفضلية غالبةلا تملك الشّركة ما يجعلها مُختلفة عن غيرها من الشّركات النّاشئة. تحتاج إلى مزية خارقة لا يمتلكها أحد ولن يستطيع أحد على وجه الأرض أن ينافسك عليها (ربما لأنّك غيرك سيفوقك في الجوانب الأخرى). للمزيد عن الأمر اقرأ مقالي: المزايا الحقيقية التي تميز الشركات الناشئة الناجحة عن غيرها. لم يذكر أحد أنه سيقوم بشراء منتجلن تحتاج إلى إجراء دراسات إحصائية كبيرة لتبدأ بالعمل على شركتك النّاشئة، ولكن ما يثير الدهشة هو أن هناك من المؤسسين من يطلق مشروعه قبل إيجاد ولو شخص واحد فقط يمتلك الرغبة الحقيقية في دفع المال مقابل المنتج الذي تقدّمه هذه الشركة. ستجد تفاصيل أوفى حول الأمر في مقالي: من أخبرك أن أحدا ما قد يرغب بشراء منتج كهذا؟. التحديد غير الصحيح لمكانك بين المنافسينيتفرّع هذا الخطأ إلى فرعين متعاكسين: الأول: الاعتقاد الجازم بأنّ تفرّدك يعني عدم وجود المنافسة. والثاني: تحديد مواصفات شركتك بالاعتماد على المنافسين بدلًا من بناء هويّتك ورسالتك الخاصّة. تفاصيل أوفى حول الأمر في مقالي السّابق: قم بتحديد مكان شركتك بين المنافسين بهذه الطريقة. عدم وجود طريق واضح للوصول إلى العملاءإن كانت خطّة التسويق الخاصّة بك تعتمد على اختبارات A/B والحصول على المشتركين عن طريق RSS، فإنّك ضائع لا محالة. هناك بعض الأخطاء الشائعة التي ارتأيت أنّها ليست بحاجة إلى مقالات خاصّة لكل منها: عدم القدرة على وصف الشركة خلال 60 ثانيةربما تكون قد سمعت عن حديث المصعد Elevator pitch، ولكن عندما طلبنا القيام به لم يفلح أحد تقريبًا في القيام به بالشكل الصحيح. قدرتك على وصف الشركة بشكل موجز وسريع أمر مهمّ جدًا، حتى ولو لم تصل إلى مرحلة الحصول على الاستثمار لأنّ قدرتك على القيام بذلك يعني أنّك تفهم عملائك جيّدًا وتفهم كذلك الرغبة التي تدفعهم إلى شراء منتجاتك. بناء المنتج لنفسك لا للسوقتبدأ الكثير من الأفكار العظيمة بمبدأ "ما حكّ جلدك مثل ظفرك" ولكنّ لا يمكن اعتماد هذا المبدأ كخطّة للمشروع التجاري. غالبًا ما تفترض أنّك وعميلك متماثلان، وتريان المشكلة من نفس المنظار، وترغبان في حلّها بنفس الطريقة، وترغبان في دفع الأموال لقاء ذلك. ولكنّ هذا ليس بصحيح، فأنت لا تشبه عملائك على الإطلاق، وأحد الأسباب هو أنّك تمتلك الحافز الكافي لترك عملك وإطلاق شركتك الخاصّة. ومن السهل أن تفسح المجال أمام أفكارك المسبّقة الغريبة لتمنعك من ملاحظة رغبات السوق. التظاهر بعدم وجود الأخطاءهناك الكثير من نقاط الضعف يمكن أن تبتلى بها: شركتك الناشئة هذه هي شركتك الأولى التي تُطلقها، انعدام الخبرة والجهل بمبادئ التسويق، برنامج مليء بالأخطاء، وغيرها. لا مشكلة في كل ذلك ما دمت تعترف بوجود هذه الأخطاء وتحاول مواجهتها والتخلّص منها، أمّا إن كنت مصرًا على الكذب عليّ وعلى عملائك بشأن هذه الأخطاء، فهذه مشكلة كبيرة، فالكذبة المتعمدة كذبتان. لا تعرف ما لا تعرفه لا يهمّني إن لم تؤهّلك سيرتك الذاتية لبناء شركتك الناشئة، فسيرتي الذاتية كانت كذلك. ولكن إن كانت إجابتك على أي سؤال يطرح عليك: "وما أدراني؟ أنا لا أعلم." فسأعرف حينها أنّك لست جاهلًا وحسب، بل غير قادر على التخلص من هذا الجهل. كيف لي أن أعلم بأن هذا لن يتسبب في انحراف مشروعك التجاري عن الهدف إلى أن تنفد الأموال من بين يديك في نهاية المطاف؟ أنا لا أعلم. ترجمة - وبتصرّف - للمقال 5Lessons from 150 startup pitches لصاحبه Jason Cohen. حقوق الصورة البارزة: Designed by Freepik.

إليك مجموعة من الاستراتيجيّات السريّة التي يُخيّل لرياديّي الأعمال أنّها استراتيجيّات ناجحة ومفيدة للشّركات النّاشئة، بينما هي عكس ذلك تمامًا، كفيلة بقتل شركتك في مهدها! احرص على أن تبقى في "الوضع الخفي" حتى اللحظة الأخيرةإنّ آخر ما قد تحتاجه أيّة شركة ناشئة هو أن يعلم النّاس بأمرها. يمكنك أن تحصل على اهتمام الآخرين في وقت لاحق، ليس ذلك بالأمر الصّعب بتاتًا. لكن في مراحل عملك الأولى، لا تريد أن تشوّش تفكيرك بأولئك الزّبائن الذين يثيرون الضّجة على باب مكتبك، خاصّة أثناء انهماكك بإعادة بناء قواعد البيانات الخاصّة بالبرنامج. لا تنسى أيضًا أنّ عليك أن تولي موضوع المنافسة اهتمامًا كبيرًا في هذه المرحلة بالذّات، فليس هناك أسوأ من أن يقوم منافسٌ آخر بالإعلان عن إطلاق منتجه في نفس الوقت الذي تُعلن فيه أنت عن منتجك المماثل. عليك إذًا أن تُبقي جميع أفكارك في سريّة تامّة. وبعد ذلك، ما إن تُطلق المنتج فسيتوافد إليك – تلقائيًّا – ملايين النّاس الذين سيسمعون عنك بما فيهم المنافسين، لكن الفرق حينها أنّك ستكون قد تقدّمت عن الآخرين بما يزيد عن أربعة أشهر كاملة، ممّا يجعل منافستك في ذلك الوقت مستحيلة، حتى ولو رغب بذلك طالبَين في جامعة ستانفورد يملكان ميزانيّة بقيمة 150 ألف دولار! وهذا يعني أيضًا أنّه من الأفضل ألا تتحدّث إلى عملائك المحتملين، فالكلام ينتقل بسرعة! ناهيك عن أنّ هؤلاء العملاء الذين سوف يدفعون لك لاحقًا 20$ في الشهر، قد يغيّرون رأيهم بعدما تعرض عليهم فكرة المشروع، على الأرجح أنّهم سيقرّرون توفير هذا المبلغ وعوضًا عن شراء المنتج منك قد يتركون عملهم الحاليّ ويؤسّسون شركة تشبه شركتكَ تمامًا ويضعونك خارج اللعبة. صدّقني، رأيهم في المنتج لا يستحقّ كلّ تلك المخاطرة! وإيّاك ثمّ إيّاك أن تتواصل مع رياديّي الأعمال الآخرين أو المستشارين الذين بإمكانهم ببساطة أن يستحوذوا على أفكارك. اكتفِ بقراءة قصّة ولادة أيّة شركة ناشئة، واستمع إلى مقابلاتٍ مع مؤسّسي الأعمال المشهورين، وستجد أنّ هناك قاسمًا مشتركًا بين الجميع، إذ لم يكن لأيّ منهم أيّ مشرف أو موجّه، وجميعهم لم يجدوا أيّة فائدة ملموسة من التّحقق من صلاحيّة الأفكار، ولا حتّى شعروا بحاجة إلى جلسات عصف ذهنيّ بالتّشارك مع أشخاص سبق لهم أن خاضوا في مجالات مشابهة. كل ذلك ليس له أيّة قيمة في عالم الأعمال. إياك أن تطلق منتجا فيه أخطاءبوجود كلّ أولئك الملايين من العملاء الذين يترقّبون إطلاق المنتَج، فآخر ما سيتوقّعونه منك أن تفاجئهم بإصدار أوّلٍ غير مستقرّ ومليء بالأخطاء والمشاكل. انظر حولك جيّدًا، كل شركات البرمجيّات الأخرى في العالم تنتظر حتى يخلو المنتج تمامًا من أيّ خلل برمجيّ، وبعدها تقوم بإطلاقه. ولهذا السّبب فقط تجد أنّ منتجاتهم خالية من أيّة أخطاء تتعلّق بقابليّة الاستخدام usability، وجميعها تصدر دون أن تنقصها أيّة مزيّة هامّة. بوجود كلّ تلك المنتجات الكاملة -من اللحظة الأولى لإطلاقها- يبدو وجود موقع مثل UserVoice مثير للرّيبة، على الأرجح هنالك بعض الحمقى الذين يهتمون بهذه الأمور السخيفة! ومن ثمّ فأنت تعلم أنّ درهم وقاية خيرٌ من قنطار علاج، فلم لا تأخذ وقتًا كافيًا في الإعداد للمنتج قبل إصداره، حتى لو استغرق منك ذلك عدة سنوات! إياك أن تسأل أحدا إن كان سيدفع ثمن منتجكفبالطبع سيدفعون، يمكنك معرفة ذلك بعمليّة حسابيّة سهلة: افرض أنّ العميل باستخدامه لهذا المنتج سيوفّر 45 دقيقة يوميًّا. وبفرض أنّ قيمة السّاعة الواحدة بالنّسبة له تساوي 20$ فقط، ولا يعمل أكثر من عشرين يومًا في الأسبوع، عندها سيكون قد وفّر حوالي 300$ في نهاية الشّهر، فالمنتج يبدو -وبلا شكّ- أنّه مدرّ للمال، ولن يطيق الزّبون أن يعيش بدونه، بل ربّما سيشتريه مرّتين! هكذا ببساطة يتمّ اتّخاذ القرارات الماليّة، ببرود أعصاب وعقلانيّة، وباستخدام أبسط مبادئ الرّياضيّات. فلماذا إذًا تضيّع وقتك ووقت عملائك في التّحقّق من أمرٍ محتّم؟ ابدأ ببرمجة المنتج أولاأنت تعلم أنّ برمجة التّطبيق هو أمر صعبٌ وشائك، لديك خبرة سنوات في هذا المجال وهذا هو الجزء من المشروع الذي تعرفه جيّدًا، وبالتّالي تعرف المتاعب التي ستكون بانتظارك. الجزء الأسهل من العمل هو جذب انتباه النّاس والحصول على كميّة مبيعات مُرضية. من السّهل أن تأتي بالنّاس إلى موقعك، إيّاك أن تفكّر أنّ هناك مليار موقع آخر يسعون للفت الانتباه أيضًا، بل والأكثر من ذلك، سيكون من السّهولة بمكان أن تحوّل هؤلاء الزوّار إلى زبائن مباشرة بمجرّد أن يصلوا إلى موقعك، وإلا فلمَ قد يأتي أحدهم إلى موقع ما إن لم يكن ينوي الشّراء بالفعل؟ سهلٌ أيضًا أن تحصل على متابعة إعلاميّة مستمرّة، سينهال المدوّنون المشهورون من كلّ حدب وصوب ليكتبوا عنك وعن منتجك طوال الوقت. كما أنّ بإمكانك أن تُبرم اتّفاقيّات إعادة بيع المنتج reseller deals بكلّ سهولة ويُسر، فكّر بالأمر، الكل سيرغب في التّوسيق وبيع مُنتجك. لا داعي لأن تضيّع وقتك في ذلك الجزء المتبقّي من العمل، فالمنتج المتميّز يسوّق لنفسه بنفسه. لا تصدّق أولئك الذين يقولون أنّ العالم مليء بالشّركات النّاشئة التي تمتلك منتجات رائعة، وبالكاد عميلًا واحدًا أو اثنين! بل كلّ ما عليك التركيز فيه في البداية هو البرمجة وكتابة الشيفرات، هذا هو الجزء من العمل الذي تتقنه وتعلم خفاياه بشكل جيّد. عليك أن تقضي وقتًا أطول في عمل ما تُتقن. لا تحاول أن تواجه مخاوفك الآن، كلّ ما عليك فعله أن تغمض عينيك وتتعلّم بعض الاختصارات الجديدة في محرّر النّصوص البرمجيّة الذي تستخدمه، وعندما تصل إلى المهام الأخرى فلكلّ حادث حديث. إياك أن تعمل بجدمجرّد بناء شركة ناشئة هو أمر صعب بحدّ ذاته، أرجوك لا تزد الأمر سوءًا بالانهماك فيه وتحميل نفسك فوق طاقتها. جميع مؤسّسي الأعمال الرائدين –كما تعلم – لا تزيد ساعات عملهم الأسبوعيّة عن ثلاثين ساعة، صحيحٌ أنّها إحدى المؤشّرات التي تجعلك تبدو شغوفًا بعملك، لكن ليس عليك أن تستيقظ يوميًّا في السّاعة الثانية فجرًا فزعًا من عملك غير المُنجز، تذكّر أنّك بحاجة لأن تحظى بقسط وافر من النّوم. ستيف جوبز مثلًا لم يكن يعمل بشكل ثابت ومستمرّ، بيل جيتس كانت لديه هوايات عديدة، مارك زوكربيرج لم يكن مربوطًا مع حاسبه يأخذه معه أينما مضى، وكذلك المدوّن Tim Ferris الذي حصل على أعلى رقمٍ من المبيعات لكتبه بمجرّد أنّه كان يكتب ومن ثمّ يروّج لها، هذا الشّخص لم يكن يعمل أكثر من أربعة ساعات في الأسبوع كلّه. من أخبرك أنّه من متطلّبات الشّركة النّاشئة أن تستحوذ على عقلك وتفكيرك؟ إنّها شائعة غير صحيّة اخترعها جميع مؤسّسي الشّركات النّاشئة الذين تمّت مقابلتهم على Mixergy ويبلغ عددهم حوالي 300، لا تصدّقهم، جميع هؤلاء كاذبون. في الواقع، كلّ هؤلاء المؤسّسين يعيشون حياة متوازنة وصحيّة، إنّهم لا يريدونك أن تعلم السّر الكامن وراء حياتهم الهانئة ونجاحاتهم الباهرة، فهم يريدون أن يلقوا بمنافسيهم بعيدًا. لا تحرق أعصابك من أجل شركتك، فتأسيس شركة من الصّفر هو عمل اعتياديّ مثل أيّ أمر آخر، تستطيع أن تمارس العمل في ساعات العمل، ويمكنك أيضًا أن تتمتّع بجميع أيّام الإجازات طوال العام. ماذا عنك؟ هل من نصائح أخرى ترغب بتقديمها في هذا السّياق؟ شارك زملاءك الرياديّين حكمًا أخرى مشابهة للتي ذكرتُها وأفدنا من خبرتك في التّعليقات. مترجم -بتصرّف- عن المقال “Stealth mode” and other f’ing brilliant strategies لكاتبه Jason Cohen. حقوق الصورة البارزة: Designed by Freepik.

أعتقد أنك قد ارتكبت أحد هذه الأخطاء التي سأوردها في هذا المقال عند تعاملك مع العملاء، وربّما دون أن تشعر بذلك، وقراءتك لهذا المقال يجعلني مطمئنًا بأنّك تسعى لنيل رضا عملائك، وأنّك تعرف حقّ المعرفة أن نجاح مشروعك التجاري يعتمد وبشكل كبير على رضاهم وسعادتهم، ومن المؤكّد أنّك ترغب في أن يطّلع عملاءك على مدى حرصك واهتمامك بهم. ولكن قد يصدر منك بعض التصرّفات التي تثير غضب العملاء وتكون سببًا في شعورهم بالاستياء، دون أن تكون قاصدًا لذلك. الأخطاء الستة التالية هي اﻷكثر إغاظة للعملاء، وعليك تجنبها إن كنت حريصًا بحقّ على سعادة عملائك ورضاهم عنك. 1- العبارات الجاهزةإن اﻻحتفاظ بمجموعة من الردود الجاهزة في برنامج الدعم الفني الخاصّ بك أمر جيّد ﻷنّه يساعد في توفير الوقت والجهد، فلا تعود هناك حاجة لكتابة نفس العبارات والجمل مرارًا وتكرارًا، ولكن يجب أن تكون هذه العبارات موجّهة إلى عملائك بصورة شخصية، لا أن تبدو وكأنّها عبارات "معلّبة" جاهزة. في استطلاع للرأي أجرته شركة American Express سنة 2011 حول أسوأ العبارات التي يواجهها العملاء وأشدّها إثارة للغضب والانزعاج، كانت العبارة الفائزة هي: 2- الانتظار لفترات طويلةلا تمثّل السرعة في الاستجابة العامل اﻷكثر أهمّية في الدعم الفني غير أن هذا لا ينفي كونها أمرًا مهمًّا، ففي استطلاع للرأي أجرته Forrester تبيّن أنّ 41% من العملاء يتوقعون أن تصلهم رسالة من الدعم الفني في غضون 6 ساعات، أما نسبة الشركات التي شملها الاستطلاع والتي تستجيب لرسائل العملاء خلال هذا المدّة من الزمن فكانت 36% فقط. تكتسب سرعة الاستجابة أهمّية أكبر في وسائل التواصل الاجتماعي، حيث يتوقع 32% من المستخدمين أن تكون استجابة فريق الدعم الفني في غضون 30 دقيقة، في حين يتوقع 42٪ أن تكون الاستجابة خلال 60 دقيقة. 3- اﻹحالة إلى شخص آخراستطلعت دراسة أخرى عن أسوأ اﻷمور التي قد يواجهها العملاء من قبل فرق الدعم الفني، فكانت إجابة 37% منهم: "اﻹحالة إلى شخص آخر". ونعني بذلك أن يحيلك أحد أعضاء فريق الدعم الفنيّ إلى عضو آخر وقد يحيلك هذا اﻷخير إلى عضو ثالث وهكذا، ومن المؤكّد أنك قد مررت بهذه التجربة وتعرف طبيعة المشاعر التي تنتاب الإنسان عندما يتعرّض لمثل هذا الموقف. لقد مررت بهذا الموقف مؤخرًّا، فقد حجزت تذكرة سفر في إحدى شركات الطيران إلا أنّ موعد الرحلة تغير، ولم أعد قادرًا على الوصول إلى المطار في الوقت المناسب، فقرّرت الاتصال بشركة الطيران إلا أن المجيب اﻵلي أخبرني أن عليّ الانتظار لمدة ساعة، لذا توجّهت إلى صفحة Twitter الخاصة بالشركة طلبًا للمساعدة. فماذا كان الجواب؟ "يرجى الاتصال بفريق Advantage على الرقم 800-882-8880 لمعرفة الخيارات المتاحة". الدعم الفنيّ الجيد لا يعني معرفة اﻹجابة الصحيحة على الدوام، بل يعني أن لا يضطرّ العملاء إلى البحث عن الإجابة الصحيحة لأنّك أنت من سيقوم بذلك. “أنا لا أعرف، ولكن سأتحرى اﻷمر ﻷجلك" هذه العبارة هي من أفضل العبارات التي يمكنك استخدامها عند تقديم الدعم الفنيّ. 4- الفظاظةﻻ أحد يحب أن يعامله اﻵخرون بفظاظة، ولكن قد تصدر منك أحيانًا بعض الكلمات التي تجعلك تبدو فظًّا في أعين العملاء، حتى لو كنت غير قاصد لذلك، ومن هنا تأتي أهمية استخدام أسلوب الكلام المناسب في تقديم الدعم الفنيّ. فعلى سبيل المثال استطلع استبيان أجرته شركة Software Advice آراء بعض العملاء في مقارنة بين أسلوب الكلام الرسميّ وغير الرسميّ من قبل فرق الدعم الفنيّ. على الرغم من أن نسبة 65% من العملاء – على اختلاف أعمارهم وأجناسهم – يفضلون الأسلوب الرسميّ فإن النسبة تتغيّر بشكل ملحوظ عندما يتلقّى العميل الرفض من قبل الدعم الفنيّ باستخدام هذا الأسلوب. فقد ذكر 78% من المشمولين بالاستطلاع أنّ للأسلوب غير الرسميّ الزائد عن حدّه (كاستخدام بعض العبارات العامّية الدارجة أو اﻷيقونات التعبيريّة Emoticons تأثيرًا سلبيًّا في تجربة التعامل مع الدعم الفنيّ، وخاصة عندما يجابه طلبهم بالرفض. إن المبالغة في استخدام الأسلوب غير الرسميّ في تعاملك مع العملاء عندما تريد رفض شيء معيّن يعني أنّك لا تأخذ طلبهم على محمل الجدّ، وسيشعرون أنّك تعاملهم بفظاظة. 5- محاولة دفع العميل إلى الترقية إلى خدمات أغلى بشكل سيءقد يكون ترغيب العميل بترقية الخدمة أو المُنتج Upselling مفيدًا في بعض اﻷحيان، إذ أنّه يوطّد علاقتك بالعميل ويرفع القيمة الكلية للزبون lifetime value (المبلغ الكلّي الذي سيدفعه العميل طيلة المدّة التي يبقى فيها عميلًا) ويساعدك في نموّ مشروعك التجاري. غير أنّ هذا الترغيب لن يجدي نفعًا إن لم تقم به بصورة صحيحة؛ إذ يجب أن يشعر العميل بأنّه يستفيد من التعامل معك بشكل كبير، وأنّ الفائدة ستغدو أكبر وأكبر إن قام بشراء العرض اﻹضافي. لنأخذ ما جرى مع Chris Yeh كمثال: لنتخيل موقف Chris لو أنّه كان منزعجًا أو غاضبًا من الشركة؟ هل كان سيقبل بهذا العرض الترغيبي؟ كلا وبكل تأكيد؛ لذا ﻻ تحاول ترغيب عميل غاضب أو منزعج، ولا ترغّب العميل في منتجك إن لم يقدّم له فائدة إضافية. يصف Jeffery Gitmore وجهة نظر العميل إلى العروض الترغيبيّة بالعبارة التالية: "أخبرني كيف سأستفيد. فإنّك لن تستفيد ما لم أحقق أنا الفائدة". إن لم يحقّق العميل الفائدة المرجوة من عرضك الترغيبيّ فلا تحاول تقديم العرض على اﻹطلاق. 6- عدم تقديم الاعتذارهناك الكثير ممّا يمكنك فعله لتهدِّأ من روع العميل، إذ يمكنك إرجاع أمواله، أو تقديم المنتجات مجّانًا، أو منحه حسابًا مجّانيًّا لمدة عام واحد، ولكن لا تنسَ اﻷثر الكبير الذي سيتركه اعتذار بسيط في نفس ذلك العميل، وليس من الضروريّ أن تكون مخطئًا لتقدّم الاعتذار، بل يمكنك التعبير عن أسفك تجاه ما يشعر به العميل من سوء وانزعاج. أنا لا أحب رؤية العميل مستاءً على اﻹطلاق، وهذا يدفعني للتعبير عن أسفي واعتذاري لما يشعر به العميل من الغضب أو الانزعاج، سواء أكنت أتحمّل مسؤولية الخطأ أم ﻻ. في دراسة أجرتها Carey School of Business في جامعة ولاية أريزونا، بلغت نسبة العملاء الذي يشعرون بالرضا بعد حصولهم على تعويض مادّي إلى 37٪، غير أن هذه النسبة تتضاعف لتصل إلى 74% عندما تقدّم الشركة الاعتذار إضافة إلى التعويضات. عامل زبائنك كما تحب أن تعامَل أنتيكره الناس إجبارهم على الانتظار، أو التعامل معهم بفظاظة أو بأخلاق سيّئة، كما يغيضهم أن يشعروا بأنهم لا يحصلون على الاهتمام الكافي، ومع أنّنا نحرص جاهدين على أن يشعر العميل بمقدار تقديرنا واحترامنا له، إلا أن اﻷمور قد تسوء في بعض اﻷحيان، لذا حاول أن تتذكر اﻷمثلة السابقة على الدوام وانتبه لما ستخاطب به عملائك مستقبلًا لتحوز رضاهم وسعادتهم. ترجمة –وبتصرّف– للمقال The 6 Customer Service Mistakes That Annoy Customers Most لصاحبه Len Markidan.

ساد اتجاه قويّ هذا العام بين المسوقين من مختلف أنحاء العالم لتأكيد قدرتهم على زيادة الاستثمار ضمن مواقع التواصل الاجتماعي، حيث انتشرت العديد من الدراسات التي تبرهن على الدور الكبير لهذه الوسائل بوصفها إحدى أهم أدوات المسوقين، كما تدعي الكثير من الدورات التدريبية المتاحة على الإنترنت – المجانية منها والمدفوعة - قدرتها على تحويلك إلى "ساحر" على وسائل التواصل الاجتماعي في دقائق معدودة. باختصار، أمدت وسائل التواصل الاجتماعي المسوقين بالقدرة على العمل بشكل عالمي بعد أن كان عملهم قاصرًا على نطاق ضيق. من هذا المنطلق سأفترض حضورك على وسائل التواصل الاجتماعي أو أنك ستسعى إلى ذلك قريبا. في العموم إن كنتَ تُدير حسابك الشخصي على الشبكات الاجتماعية بطريقة مذهلة لسنوات عدّة، فإنه ينبغي عليك معرفة أن تسويق الأعمال على هذه الشبكات أمرٌ مختلفٌ تمامًا. فما قد يحقّق نتائج رائعة على حسابك الشخصي قد يأتي أحيانًا بنتائج كارثية لعلامتك التجارية. إليك بعض الأخطاء الشائعة والقاتلة على مواقع التواصل الاجتماعي والتي ينبغي عليك الابتعاد عنها على الفور: 1. العدوانية مع العملاءرغم بداهة ذلك إلا أنّه من الجيد التأكيد على أن مواقع التواصل الاجتماعي هي أدوات للتواصل مع المعجبين والمتابعين، لذا ينبغي عليك كسب صداقتهم وعدم الدخول في خلافاتٍ معهم.ففي حين أنه من السهل جدًا بالنسبة للمستخدمين تنفيس الإحباط والغضب على علامتك التجارية باستخدام الشبكات الاجتماعية، رغم ذلك فإن الرد بنفس الإساءة والغضب على العملاء مهما كان أسلوبهم سيئًا فكرة أكثر سوءًا . فعملك كراعٍ لعلامة تجارية هو تهدئة العملاء الغاضبين والحفاظ على انطباع لائق بعلامتك أمام باقي المعجبين، تذكّر دومًا أنه لا مجال لمشادة كلامية مع العملاء الساخطين. 2. مشاركة محتوى غير ذي صلةتؤّكد جميع نصائح التسويق على الإنترنت ودون استثناء على أهمية نشر المواضيع التي تلقى اهتمام جمهورك فقط وذات الصلة الوثيقة بعلامتك التجارية، فالجمهور إذا لم يهتمّ لمنشوراتك فإنه بطبيعة الحال سيفقد اهتمامه بعلامتك التجارية، وكما أن تراجع معدل المشاركة يقلل من استخدام العلامة التجارية وبالتالي يخفّض من المبيعات، لذا لا تتورط منذ البداية في هذه المتتالية وتجنب المواضيع غير المرتبطة بك لأنها وباء مميت للمبيعات. 3. تكرار نشر ذات المواضيع مرات عديدةما هو الأسوأ من نشر المواضيع غير المرتبطة بعلامتك التجارية؟ إنه إعادة نشر المواضيع لمرات عدّة. لا أحد يُحب الملل؛ لذا اسعَ جاهدًا كي لا تكون واحدًا من أولئك المُملين على وسائل التواصل الاجتماعي، وإن كنتَ تواجه مشكلة في إيجاد مواضيع جديدة ذات صلة بعلامتك التجارية كل يوم، فاطّلع على ما تنشره العلامات التجارية الأخرى ذات الصلة بك وأعد نشرها بعد تصريح منهم. إليك أسلوبًا آخر، أجرِ مسابقات أو اطرح بعض الأسئلة على متابعيك في تلك الأيام التي لا تجد فيها أفكارًا للكتابة، افعل أي شيء باستثناء تكرار نفس المضمون عدّة مرات. بكل الأحوال إذا كنت لا تزال مُصرًا على إعادة استخدام محتوىً قديم، فاعمل على إعادة توظيفه "كتغيير هيئته؛ فإن كان نصًا حوّله إلى فيديو مثلا أو غيّر منصة النشر، وهكذا باختصار بثّ حياة جديدة في الموضوع القديم ثم أعد نشره مجددًا. 4. صفحات التواصل الاجتماعي الميتةيشتدّ حماس العديد من أصحاب العمل عند إنشائهم حسابات العلامة التجارية الخاصة بهم على منصات التواصل الاجتماعي، وفي حين يتمكّن عدّدٌ منهم من الحفاظ على حضورهم الفعّال على وسائل التواصل الاجتماعي وإبقاء حساباتهم نشطة وتنمية المزيد من المعجبين، إلا أن جزءًا آخر كبير من الشركات تنشغل عن القيام ببعض الأعمال اليومية اتجاه حساباتها على مواقع التواصل الاجتماعي أو تتشتت جهودها في عدد كبير من هذه المنصات وتكون النتيجة هي صفحات اجتماعية ميّتة.تجنب هذا الخطأ عن طريق البدء مع أكثر منصة اجتماعية ملائمة لجمهورك المستهدف، واحصر جهودك بدايةً بها ، وما أن تبدأ بتحقيق المبيعات انتقل إلى منصة أخرى ملائمة لعملائك. على سبيل المثال: إذا كانت علامتك التجارية تستهدف النساء، يمكنك أن تبدأ على موقع Pinterest ثم توسّع ببطء إلى فيس بوك وتوتير و LinkedIn بهذا الترتيب . 5. الإلحاح بطلبات الشراءكيف يمكن للتركيز الزائد على المبيعات في منشوراتك ضمن وسائل التواصل الاجتماعي أن يؤثر سلبًا عليها ؟ أليس في ذلك تناقضًا؟ لا ليس هناك تناقض، يعود ذلك لسبب وجيه وهو أن وسائل التوصل الاجتماعي ليست المكان الذي يقصده المشتركون من أجل التسوق، بل بهدف التواصل مع الأهل والأصدقاء. لذا إن قاموا بمتابعتك فهذا شيءٌ ثانوي لهم ، وليس الغرض الأساسي من وجودهم هناك. لذا تجنب وضع المنشورات التي تجعلك تبدو كالباعة المتجولين والذين يُلحّون على الزبائن بالشراء، فهذه الطريقة ستفقد متابعيك اهتمامهم بعلامتك التجارية ومن ثم البحث عن خيارٍ أفضل. 6. عدم الرد على التعليقات أو الاستفساراتليست الشبكات الاجتماعية مجرد منبر للتعبير عن وجهات نظرك فقط ، فهي علاوةً على ذلك منصة للحوار بين علامتك التجارية والمستخدمين. لذا لا تكتفي بنشر آرائك ومنشوراتك ومن ثم الاكتفاء بالمرور السريع على تعليقات المستخدمين. توقف خذ نفسًا عميقًا ثم قم بالرد عليهم كلًا على حدا، أشعرهم بالاهتمام ، أجب عن الاستفسارات بشأن منتجاتك، عالج طلبات خدمة العملاء وأنهِ أيّة قضايا عالقة بأسرع ما يمكن. أشعرهم بأن خدمة العملاء لديك موجودة وقوية، وأنك تتحكم في زمام الأمور. 7. عدم تخصيص ساعة على الأقل يوميا لوسائل التواصل الاجتماعيالشبكات الاجتماعية أدوات قوية للغاية حيث يمكنها أن تقدّم لك كل ما تريد معرفته كنِسب المشاهدين، النقرات، التحويلات والمبيعات. رغم ذلك فإنه لن يمكنك تحقيق نتائج مرضية بمجرّد إنشاء حساب ثم الجلوس ساكنًا ، بل تحتاج إلى متابعة العمل لجني ثماره. في العموم تُخصّص الشركات عادةً أفرادًا بعينهم للتعامل مع حسابات التواصل الاجتماعي، أما إذا لم تملك ميزانية كافية لذلك ، فكن متأكدًا أنت وفريقك من تخصيص ساعة واحدة على الأقل كل يوم كي تقوم بالآتي: متابعة ما ينشر حول العلامة التجارية الخاصة بك.الرد على استفسارات العملاء والتعليقات.إنشاء ومعالجة ونشر المحتوى.تتبع وقياس وتحليل أثر وسائل التواصل الاجتماعي في إجمالي الحركة على موقعك والتحويلات المتحققة من هذه الشبكات.المزيدكانت هذه أهم تعليقاتي على عاداتنا في التعامل مع وسائل التواصل الاجتماعي والتي يمكن أن تؤثر مباشرة على المبيعات. هل تنطوي تجربتك على أي من العادات السامة الأخرى؟ بادلنا الأفكار، فنحن نُحب أن نسمع منك. ترجمة - وبتصرّف- للمقال Toxic Things You Do on Social Media That Are Killing Your Sales لصاحبه Simon Horton.

من الوهلة الأولى يبدو لنا إطار العمل هذا وكأنّه بسيط ويسهل التعامل معه، وبالطبع هو كذلك والبدء باستخدامه ليس بالأمر الصعب فتوثيق هذا الإطار مكتوب بشكل ممتاز ويحتوي على الكثير من الشيفرات البرمجية المتعلقة باللغات HTML، CSS وجافاسكربت. وصحيح أنّ المغالطات المهمة مذكورة في ذلك التوثيق، ولكن بعض الأخطاء والمشاكل قد تكون غير ظاهرة أو قد تكون موجودة في حالات استخدام غامضة. ولأنّ إطار عمل Bootstrap يبدو بسيطًا وسهل الاستعمال فإنّ هذا الإطار انتشر كالنار في الهشيم وبدأ الكثير من المطورين باستخدامه مما أدّى إلى حدوث الكثير من الأخطاء وظهور بعض المشاكل. لذلك سوف نقوم في هذا المقال بسرد 10 أخطاء شائعة يقوم بها مستخدمو هذا الإطار. الخطأ 1: إساءة فهم هذا الإطار في المقام الأولهناك بعض المفاهيم الخاطئة موجودة في عقول المطورين حول هذا الإطار، وقد يكون ذلك بسبب أنّ هذه المفاهيم غير موجودة بشكل صريح وواضح في الموقع الخاص بإطار العمل أو بسبب أنّ المطورين لا يأخذون الوقت الكافي لقراءة توثيق هذا الإطار. وقد يقوم المطورون بالقيام بالعديد من الأمور بشكل خاطئ وبعدها يلقون اللوم على إطار العمل نفسه، لذلك دعونا نوضح بعض الحقائق المهمة. إنّ إطار العمل Bootstrap يُعتبر إطار عمل شامل ومتكامل ولكنه ليس ضخمًا أو هائل الحجم. ويأتي هذا الإطار بقوالب أساسية تحتوي على العديد من مكونات واجهة المستخدم مثل الجداول (tables) والنماذج (forms) والأزرار (buttons) والقوائم المنسدلة (dropdowns) والكثير الكثير. ويمكنك استخدام هذه المكونات لإنشاء واجهة تعمل على العديد من المتصفحات والأجهزة والأبعاد بأفضل شكل ممكن. وصحيح أنّ إطار العمل لن يقوم بكل شيء ولكنه يوّفر مجموعة من الخيارات لتختار منها مما يساعد المطورين في التركيز على التطوير أكثر من التصميم ويساعدهم في الحصول على موقع جميل بوقت قليل. وهذا الإطار مرن بحيث يمكنك التعديل عليه من إضافة وحذف حتى يتناسب مع احتياجاتك. وصحيح أنّه كان هناك بعض القيود في الإصدارات الأولية لهذا الإطار إلا أنّه الآن أصبح أفضل ويمكن تطويعه بكل سهولة. الخطأ 2: الإعتقاد بأنك لن تحتاج إلى معرفة CSS لاستخدام هذا الإطار وبأنك لن تحتاج إلى مصمم.إذا كنت تعتقد أنّك لن تحتاج إلى معرفة CSS حتى تستخدم هذا الإطار فأنت مخطئ لا محال، فأي مطور ويب يحتاج إلى معرفة CSS وHTML5. وصحيح أنّه يوفر عليك عناء التعامل مع بعض الأمور المزعجة الخاصة بلغة CSS (مثل الـvendor prefixie) ويعطيك العديد من التنسيقات الإفتراضية إلّا أنّه يجب عليك أن تفهم لغة CSS. وقد لا تحتاج إلى معرفة كيف تعمل استعلامات الوسائط (media queries) ولكنك بالطبع سوف تحتاج إلى معرفة كيف يعمل التصميم المتجاوب بشكل عام، فأُطر العمل ليست مصممة لتعليمك CSS ولكنها قد تساعد في ذلك. قد تعتقد أنّك لن تحتاج إلى مصمم إذا ما استخدمت Bootstrap، ولكن مع ذلك يجب عليك التعامل مع أحد المصممين إذا كان ذلك ممكنًا. فإحدى أهم المشاكل الموجودة حاليًا هو أنّ الكثير من المواقع أصبحت تشبه بعضها بسبب استخدام إطار عمل Bootstrap. وقد لا يكون هذا صحيحًا فهناك الملايين من المواقع المصممة باستخدام Bootstrap، فيمكنك مثلًا الدخول إلى موقع Bootstrap Expo فهو عبارة عن معرض أعمال يحتوي على العديد من المواقع التي بُنيت باستخدام هذا الإطار. ألقِ نظرة عليها فقد تلهمك لبناء شيء خاص بك. الخطأ 3: تغيير ملف CSS الإفتراضي لهذا الإطاردعنا نجعل ذلك بسيطًا ومباشرًا: لا تقم أبدًا بتعديل ملف bootstrap.css. إذا قمت بالتعديل على ذلك الملف فالأمور سوف تصبح معقدة وسوف تقوم بتدمير التصميم عندما تقوم بتحديث ملفات Bootstrap عند صدور إصدار جديد من هذا الإطار. يمكنك استبدال التنسيقات الإفتراضية لهذا الإطار بالتنسيقات التي تريدها (مثل colors، margins، paddings) وليس هناك حاجة إلى التعديل على ملف bootstrap.css إطلاقًا. لا تعرف كيفية استخدام LESS أو SASS؟ لا مشكلة في ذلك، كل ما عليك فعله هو إنشاء ملف CSS وتضع فيه التنسيقات التي تريد استبدالها من ملف bootstrap.css الرئيسي. وكما ذكرنا سابقًا فمعرفة CSS أمر في غاية الأهمية حتى لو كنت تعتقد غير ذلك. فيمكنك إنشاء محددات أو فئات (classes) CSS جديدة وتضعها في ملف HTML خاصتك حتى تقوم باستبدال التنسيقات الافتراضية للـBootstrap (لا تنسَ أن تضع ملف CSS الخاص بك بعد ملفات CSS الافتراضية الخاصة بالـBootstrap حتى يعمل كل شيء بشكل صحيح). ما زلت تريد معرفة المزيد والغوص في هذا الإطار بشكل أعمق؟ إذاً أقترح عليك وبشدة أن تنظر إلى الكود المصدري لملفات LESS فبالتأكيد سوف يتضح لك كل شيء بشكل أفضل إذا ما قمت بذلك. الخطأ 4: استخدام كل شيء يوفره إطار Bootstrapقلنا سابقًا بأنّ هذا الإطار شامل ومتكامل ويوفر العديد من مكونات واجهة المستخدم والعديد من قوالب HTML وCSS وإضافات جافاسكربت كذلك. ولكن يجب عليك ألّا تستخدم كل ما يقدمه هذا الإطار إذا كنت لن تحتاجه في المشروع الذي تعمل عليه. وهذا الأمر صحيح خصوصًا مع إضافات الجافاسكربت، فيجب عليك أن تختار فقط الإضافات التي سوف تحتاجها ولا يجب عليك أن تستخدم كل شيء لأنه يبدو جميلًا ورائعًا، فقد يؤدي ذلك إلى إثقال موقعك وجعله بطيئًا. لذلك يجب عليك في البداية أن لا تقوم بإدراج ملف bootstrap.js وأن تقوم بإنشاء موقعك باستخدام HTML وCSS فقط وبعد ذلك تقوم بإضافة المكونات التي تحتاجها واحدة تلو الأخرى. الخطأ 5: إساءة استخدام النوافذ المنبثقة (modals)يوفّر Bootstrap مجموعة من الخيارات المرنة بأقل متطلبات تشغيل ممكنة، كما أنها تأتي بقيم افتراضية مناسبة. وصحيح أنّه من السهل استخدامها ولكن هناك بعض الأمور التي يجب وضعها في الحسبان لتجنب اساءة استخدامها. 1- إظهار أكثر من نافذة منبثقة في نفس الوقتإنّ Bootstrap لا يدعم النوافذ المتداخلة، أي أنّه يمكن إظهار نافذة واحدة فقط في نفس الوقت وإذا أردت إظهار أكثر من نافذة في نفس الوقت فيجب عليك كتابة بعض الأكواد للقيام بذلك. 2- ظهور النافذة خلف الخلفيةإذا كان حاوي النافذة أو العنصر الأب لها متموضعًا بشكل ثابت أو نسبي (fixed or relative position) فإنّ النافذة لن تظهر بشكل مناسب، ولذلك يجب عليك التأكد بأنّ حاوي النافذة لا يحتوي على خاصية position خاصة. فمن أفضل الممارسات وضع HTML الخاص بالنافذة قبل وسم الاغلاق <body/> مباشرة، أو حتى وضعها بعد وسم <body> مباشرة، فهذه هي أفضل طريقة لمنع العناصر الأخرى من التأثير عليها. 3- النوافذ المنبثقة في الأجهزة المحمولةهناك بعض التحذيرات للمطورين بأنّ يكونوا حذرين عند استخدام النوافذ في الأجهزة المحمولة التي تحتوي على لوحة مفاتيح افتراضية. وهذا صحيح بشكل خاص في الأجهزة التي تعمل بنظام iOS فهناك خطأ برمجي يمنع العناصر الثابتة من تغيير مكانها عند استدعاء لوحة المفاتيح الافتراضية، وهذا الأمر لا يمكن لإطار Bootstrap التعامل معه، لذلك فإنّه يجب على المطور التعامل مع هذه المواقف بأفضل شكل ممكن. الخطأ 6: مشكلة زر متصفح الملفاتإنّ إطار عمل Bootstrap لا يوفّر مكون محدد للحصول على زر رفع للمفات (file upload). ولكن يمكنك استخدام الشيفرات البرمجية التالية للحصول على ذلك: <span class="btn btn-default btn-file"> Browse <input type="file"> </span>.btn-file { position: relative; overflow: hidden; } .btn-file input[type=file] { position: absolute; top: 0; right: 0; min-width: 100%; min-height: 100%; font-size: 100px; text-align: right; filter: alpha(opacity=0); opacity: 0; outline: none; background: white; cursor: inherit; display: block; }هناك العديد من الأمثلة لكيفية الحصول على شيء مشابه، فالشيفرة البرمجية السابقة مأخوذة من هذه المقالة وهي توفر شرحًا وافيًا لهذه المشكلة. الخطأ 7: تعقيد الأمور باستخدام الجافاسكربت وإهمال الصفة "data-"إنّ المصممين أو المبتدئين في استخدام الجافاسكربت يمكنهم بكل سهولة إنشاء صفحات ويب باستخدام HTML، CSS وBootstrap. ولكنهم إن لم يكونوا جيدين في البرمجة فقد يقعون في فخ إساءة استخدام الجافاسكربت أو حتى تعقيد الأمور. ومن المهم ذكر أنّه يمكن استخدام إضافات الجافاسكربت باستخدام واجهة تطبيقات برمجية (API) يوفرها إطار عمل Bootstrap ومن دون الحاجة إلى كتابة سطر جافاسكربت واحد. فيمكننا على سبيل المثال أن نقوم بتفعيل نافذة منبثقة (modal dialog) من دون كتابة سطر جافاسكربت واحد وذلك عن طريق استخدام: data-toggle="modal" على عنصر مثل زر (button) أو رابط (anchor) وتمرير قيم إضافية باستخدام الصفات data-. ففي الشيفرة البرمجية الموجودة في الأسفل قمنا بتحديد عنصر له id "#myModal"، وقمنا باستخدام الخيار data-backdrop لمنع النافذة من الاختفاء إذا ما قام المستخدم بالنقر خارج النافذة، وباستخدام الخيار data-keyboard قمنا بتعطيل زر الخروج (escape) الموجود في لوحة المفاتيح الذي يقوم بإغلاق النافذة عند الضغط عليه. وكل ذلك تم باستخدام سطر HTML واحد فقط: <button type="button" data-toggle="modal" data-target="#myModal" data-backdrop="static" data-keyboard="false">Launch my modal</button>الخطأ 8: إهمال الأدوات التي تسهل عملية التطوير باستخدام Bootstrapالأخطاء تحدث وكل مطور يقع في الأخطاء بين الحين والآخر. وهذا أمر لا بد منه ولكن ما يهم هو كيفية التعامل مع الخطأ أو المشكلة. وقد لاحظ فريق تطوير هذا الإطار بأنّ بعض الأخطاء تحصل بشكل متكرر أكثر من الأخرى ولذلك حاولوا أتمتة عملية التطوير، لذلك قاموا بتطوير أداة Bootlint وهي أداة تقوم بتفحص الصفحات التي تستخدم Bootstrap للبحث عن الأخطاء الشائعة. ويمكنك استخدام الأداة في المتصفح مباشرة أو عن طريق سطر الأوامر في Node.js. لذلك يجب على كل مطور أن يستخدم هذه الأداة لتفادي الوقوع في الكثير من المشاكل الشائعة والتي تقوم بإبطاء عملية التطوير. وفي حالة أنك أردت أن تساهم في تطوير مشروع Bootstrap فأعتقد أنه من الجيد لك إلقاء نظرة على Rorschach. بحيث يقوم Rorschach بعمل بعض الفحوصات على طلبات السحب (pull requests) الجديدة وإذا فشل الفحص فإنه يترك تعليق مُفيد لتوضيح الخطأ وكيفية إصلاحه وبعدها يقوم بإغلاق الطلب. الخطأ 9: مشاكل التوافق في متصفح IE8 والمتصفحات الأقدمإنّ Bootstrap مصمم ليعمل بأفضل شكل في الاصدارات الحديثة من متصفحات سطح المكتب والهواتف، وقد تُظهر المتصفحات القديمة المكونات والعناصر بتنسيقات مختلفة ولكن كل شيء يجب أن يعمل بأفضل شكل. ويتضمن الدعم متصفحات IE8 وIE9 مع ملاحظة انّ بعض خصائص CSS3 وعناصر HTML5 ليست مدعومة بشكل كامل في هذه المتصفحات. وللحصول على دعم كامل لمتصفح Internet Explorer 8 والمتصفحات الأخرى القديمة فعليك استخدام polyfill لـCSS3 Media Queries (Respond.js، HTML5 shim) والذي يمكننا من استخدام عناصر HTML5. كما أنّه يجب عليك استخدام وسم <meta> مناسب داخل وسم <head> حتى نتأكد بأنّ متصفح IE لا يعمل في وضع التوافقية (compatibility mode). يجب أن يبدو وسم <head> كما في الأسفل: <head> ... <meta http-equiv="X-UA-Compatible" content="IE=edge"> <!--[if lt IE 9]> <script src="https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js"></script> <script src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js"></script> <![endif]--> </head>في حالة Respond.js كن حذرًا من بعض الأمور في بيئات التطوير. الخطأ 10: تجاهل أفضل الممارسات (best practices)واحد من أكثر الأسئلة شيوعًا على موقع Stack Overflow هو كيفية جعل القوائم المنسدلة (dropdown menu) تظهر عندما يقوم المستخدم بتمرير مؤشر الفأرة فوق العنصر (hover) بدلًا من النقر عليه. وصحيح أنّ حل هذا السؤال ليس بالأمر الصعب ويمكن حله باستخدام CSS فقط ولكن هذا الأمر غير محبذ، فهذه الميزة تم التخلص منها في هذا الإطار بشكل متعمد وكان قرار إزالتها قد تم من قبل فريق تطوير الإطار نفسه. وكما قلنا سابقًا فحل السؤال ليس صعبًا ولكن يجب عليك معرفة التداعيات التي تأتي معها ويجب عليك أيضًا أن تعرف بأنّ هناك ممارسات جيدة يجب عليك اتباعها خصوصًا في أُطر العمل التي تكون أولويتها التطوير للهواتف. والسبب خلف ذلك هو أنّ جعل الأشياء تعمل عندما يقوم المستخدم بوضع مؤشر الفأرة فوقها (hover) لا يساعد المستخدمين الذين يعملون على أجهزة تعمل باللمس (touch). ففي هذه الأجهزة لا يوجد شيء اسمه "hover" يوجد فقط اللمس، وبالتالي فإنّ ذلك سيؤدي إلى الإضرار بمستخدمي الأجهزة التي تعمل باللمس. خلاصةأتمنى بأن يساعدك هذا المقال على تفادي بعض المشاكل والأخطاء الشائعة وتوضيح بعض المفاهيم الخاطئة. وضع في الحسبان بأنّ إطار Bootstrap لن يكون مناسبًا لكل مطور أو حتى أي مشروع، وعندما تقوم باختيار أي إطار عمل فإنّه يجب عليك أن تقرأ التوثيق الخاص به بكل تروٍ وأن تقضي بعض الوقت في التعامل معه حتى تعلم كيف يعمل. ترجمة -وبتصرّف- للمقال The 10 Most Common Bootstrap Mistakes لصاحبته TOMISLAV BACINGER.

عند الاتصال بخادوم ويب أو تطبيق، يتم الردّ على كلّ طلب HTTP يتمّ استقباله من طرف الخادوم برمز حالة HTTP أو “HTTP status codes”. رموز حالة HTTP هي عبارة عن رموز مكوّنة من 3 أرقام يتم تصنيفها إلى 5 أصناف مختلفة. يمكن أن يتمّ التعرّف على صنف رمز الحالة بسرعة عبر الرقم الأوّل منه: 1xx: معلومة 2xx: نجاح 3xx: إعادة توجيه 4xx: خطأ من طرف جهاز العميل 5xx: خطأ من طرف الخادوميركّز هذا الدرس على استكشاف أبرز رموز أخطاء HTTP التي قد تصادفك مثل 4xx و5xx وإصلاحها. من منظور مدير النظام، هناك العديد من الحالات التي قد تجعل خادوم الويب يجيب طلبًا معيّنًا برمز خطأ معيّن، سنقوم بتغطية أكثر الأسباب الشائعة التي تؤدي إلى ذلك بالإضافة إلى حلولها. لمحة عامة عن أخطاء العميل والخادومأخطاء العميل، أو رموز حالة HTTP من 400 إلى 499، هي نتيجة لطلبات HTTP تمّ إرسالها بواسطة جهاز مستخدم (مثل متصفح ويب أو أيّ عميل HTTP آخر), صحيح أنّ هذا النوع من الأخطاء مرتبط بالعميل، إلّا أنّه سيكون من المفيد معرفة رمز الخطأ الذي يصادف المستخدم للتحقق مما إذا كان يمكن إصلاح المشكلة من إعدادات الخادوم. يتم إرجاع أخطاء الخادوم أو بالأحرى رموز حالة HTTP من 500 إلى 599 بواسطة خادوم الويب عندما يكتشف حصول مشكلة، وإلّا فإنّه لن يكون قادرًا على معالجة الطلب. نصائح عامة عن اكتشاف الأخطاء وإصلاحهاعند استخدام متصفّح ويب لاختبار خادوم ويب، قم بتحديث المتصفّح بعد تطبيق التغييرات على الخادوم.تحقق من سجلات الخادوم للمزيد من التفاصيل عن كيفية قيام الخادوم بمعالجة الطلبات. كمثال، تُنتِج خواديم الويب مثل Apache وNginx ملفّين اثنين يدعيان access.log وerror.log يمكن أن يتم فحصهما للحصول على المعلومات منهما.تذكّر أنّ تعريفات رموز حالة HTTP هي جزء من معيار مُضمَّن من قبل التطبيق الذي يخدم الطلبات. هذا يعني أنّ رمز الحالة الذي يتم إرجاعه إليك يعتمد على كيفية معالجة برنامج الخادوم لخطأ معيّن. سيفيدك هذا الدرس عمومًا لتوجيهك في المسار الصحيح بخصوص ذلك.الآن وبعد أن امتلكت فهمًا جيدًا لرموز حالة HTTP، سنلقي نظرةً على الأخطاء الشائعة التي قد تصافدك. 400 Bad Requestرمز الحالة 400، أو خطأ Bad Request، يعني أنّ طلب الـHTTP الذي تمّ إرساله إلى الخادوم كان يحوي دوالًا ومُعامِلات غير صحيحة. إليك بعض الأمثلة التي قد يطرأ فيها خطأ Bad Request والذي رقمه 400: كعكة المستخدم (Cookie) المرتبطة بالموقع تالفة، مسح خبيئة المتصفّح والكعكات قد يحلّ هذه المشكلة. طلب تالف بسبب متصفّح ويب سيء وقديم مثلًا. طلب تالف بسبب خطأٍ بشري مثل عند تشكيل طلبات HTTP بشكلٍ يدوي (مثل استعمال curl بطريقة غير صحيحة).401 Unauthorizedرمز الحالة 401، أو خطأ Unauthorized أو عدم التصريح يعني أنّ المستخدم يحاول الوصول إلى صفحة أو مادّة غير مخوّل له بالوصول إليها أو لم يتم السماح له بذلك بشكلٍ صحيح. يعني هذا أنّه يجب على المستخدم توفير بيانات الدخول ليتمكّن من رؤية البيانات والموارد المحمية. كمثال، إذا حاول مستخدم الوصول إلى صفحة محمية باستيثاق HTTP، كما في درسنا كيفية إعداد استيثاق http مع nginx على 14.04 ubuntu، ففي هذه الحالة، سيتلقّى المستخدم رمز الحالة "401" إلى أن يقوم بتوفير اسم مستخدم وكلمة مرور (تلك الموجودة في ملفّ htpasswd.) لخادوم الويب. 403 Forbiddenرمز الحالة 403، أو خطأ Forbidden أو "محظور"، يعني أنّ المستخدم قام بطلبٍ خاطئ إلّا أنّ الخادوم يرفض تنفيذه على كلّ حال بسبب عدم توفّر الصلاحيات الكافية للوصول إلى الصفحة المطلوبة. إذا كنت تواجه خطأ 403 بشكلٍ غير متوقّع، فهناك بضع أسباب يمكن أن نشرحها هنا. صلاحيات الملفاتتطرأ أخطاء 403 عادةً عندما يكون المستخدم الذي يشغّل عملية خادوم الويب لا يمتلك الصلاحيات الكافية لقراءة الملفّ الذي تمّ طلبه. لإعطاء مثال عن الكشف عن هذا الخطأ وإصلاحه، افترض حصول الوضع التالي: يحاول المستخدم الوصول إلى ملفّ الفهرس الخاصّ بالخادوم من http://example.com/index.htmlعملية تشغيل خادوم الويب مملوكة للمستخدم www-dataيوجد ملفّ الفهرس على الخادوم بالمسار usr/share/nginx/html/index.html/إذا كان المستخدم يحصل على خطأ 403، فتأكّد أنّ المستخدم www-data يمتلك الصلاحيات الكافية لقراءة ذلك الملفّ. يعني هذا عادةً أنّه يجب ضبط صلاحيات "الآخرين" أو الـ"Others" إلى السماح بالقراءة ليتم حلّ المشكلة، هناك عدّة طرق لتنفيذ هذا، ولكنّ هذا الأمر سيعمل في هذه الحالة: sudo chmod o=r /usr/share/nginx/html/index.html htaccess.سببٌ آخر قد يكون وراء خطأ 403 وغالبًا ما يحصل عن غير قصد، هو الاستخدام الخاطئ لملفّ htaccess.، يمكن أن يتمّ استخدام ملفّ htaccess. لمنع الوصول إلى صفحاتٍ أو موارد معيّنة من قبل عناوين IP محددة أو نطاقات، استخدام هذا الملفّ بشكلٍ غير صحيح قد يكون المشكلة مثلًا. إذا كان المستخدم يحصل على خطأ 403 بشكلٍ غير متوقع، فتأكّد من أنّ ملفّ الـhtaccess. الخاصّ بك ليس المسؤول عن ذلك. ملف الفهرس غير موجودإذا كان المستخدم يحاول الوصول إلى مجلّد لا يمتلك بداخله ملفّ فهرس افتراضيًا، ولم يكن خيار السماح بسرد محتويات المجلّدات مفعّلًا، فإنّ خادوم الويب سيُرجع خطأ حظر 403. كمثال، إذا كان المستخدم يحاول الوصول إلى http://example.com/emptydir ولم يكن هناك ملفّ فهرس في المجلّد emptydir على الخادوم، فإنّه سيتم إرجاع رمز حالة 403. إذا كنت تريد تفعيل خيار سرد محتويات المجلّدات في حال عدم وجود ملفّ فهرس بداخلها، فيمكنك القيام بذلك من إعدادات خادوم الويب الخاصّ بك. 404 Not Foundرمز الحالة 404، أو خطأ Not Found، يعني أنّ المستخدم كان قادرًا على التواصل مع الخادوم إلّا أنّه لم يتمكن من إيجاد الملفّ المطلوب أو الصفحة المنشودة. يمكن أن تطرأ أخطاء 404 في الكثير من الحالات. إذا كان المستخدم يتلقّى خطأ 404 بشكلٍ غير متوقّع، فإليك بعض الأسئلة التي يجب أن تسألها للمساعدة في تفحّص المشكلة وإصلاحها: هل الرابط الذي وجّهَ المستخدم إلى خادمك يحتوي على خطأ بالكتابة؟ هل قام المستخدم بكتابة العنوان الخاطئ؟ هل الملفّ موجود في المسار الحالي للخادوم؟ وهل تمّ نقله أو نقل الصفحة المطلوبة إلى مكانٍ آخر أو حذفها من الخادوم؟ هل تمّ ضبط إعدادات الخادوم إلى مسار الجذر الرئيسي المطلوب؟ هل المستخدم الذي يملك العملية المُشغّلة لخادوم الويب يمتلك الصلاحيات اللازمة للوصول إلى المسار الذي يحوي الملفّ بداخله؟ (تلميح: تتطلب المجلّدات صلاحيات القراءة والتنفيذ لتستطيع الوصول إليها). هل يتمّ الوصول إلى الملفّ أو الصفحة عبر وصلة رمزية (symbolic link)؟ إذا كان الأمر كذلك، فتحقق من أن خادوم الويب مضبوط ليتبع الوصلات الرمزية.500 Internal Server Errorرمز الحالة 500، أو 500 Internal Server Error يعني أنّ الخادوم غير قادر على معالجة الطلب لسببٍ مجهول. أحيانًا سيظهر هذا الرمز عندما تكون أخطاء 5xx أكثر عرضةً لتكون هي سبب المشكلة. عادةً ما يكون أبرز سببٍ مسبب لهذا الخطأ هو وجود مشكلة في إعدادات الخادوم (مثل ملفّ htaccess. تالف) أو حزم ناقصة (مثل محاولة تنفيذ سكربت PHP دون وجود حزمة PHP مثبّتة بشكلٍ صحيح على الخادوم). 502 Bad Gatewayرمز الحالة 502، أو 502 Bad Gateway، يعني أنّ الخادوم هو عبارة عن خادوم بوّابة أو وسيط (proxy)، وأنّه لا يتلقّى ردًا صحيحًا من خواديم الواجهة الخلفية (backend servers) التي يجب أن تقوم بمعالجة الطلب. إذا كان الخادوم المطلوب هو عبارة عن خادوم وسيط عكسي (reverse proxy server)، مثل موازِن للحِمل، فإليك بعض الأمور التي يمكنك التحقق منها: أنّ خواديم الواجهة الخلفية (حيث يتم توجيه طلبات HTTP) تعمل بشكلٍ صحيح. أنّ الخادوم العكسي مضبوط بشكلٍ صحيح، مع تحديد الخواديم الصحيحة للواجهة الخلفية. أنّ اتصال الشبكة بين خواديم الواجهة الخلفية وبين خادوم الوسيط العكسي يعمل بشكلٍ جيّد. إذا كان بإمكان الخواديم أن تتواصل عن طريق منافذ أخرى، فتأكّد أنّ الجدار الناري يسمح بمرور التدفّق (Traffic) بينها. إذا كان تطبيق الويب الخاصّ بك مضبوطًا للاستماع إلى socket، فتأكّد أنّ الـsocket موجودة في المسار الحالي وأنّها تمتلك الصلاحيات الكافية.503 Service Unavailableرمز الحالة 503، أو خطأ Service Unavailable، يعني أنّ الخادوم قد تحمّل فوق طاقته أو أنّه تحت الصيانة، يوحي هذا الخطأ أنّ الخدمة يجب أن تعود إلى العمل في وقتٍ ما من الزمن. إذا لم يكن الخادوم تحت الصيانة، يمكن لهذا أن يشير إلى أنّ الخادوم لا يملك الموارد الكافية من المعالج والذاكرة العشوائية لمعالجة جميع الطلبات الواردة، أو أنّ خادوم الويب يحتاج إلى أنّ يتم إعداده ليسمح بالمزيد من المستخدمين والعمليات. 504 Gateway Timeoutرمز الحالة 504، أو خطأ Gateway Timeout، يعني أنّ الخادوم هو عبارة عن خادوم بوّابة أو خادوم وسيط (proxy)، وأنّه لا يتلقّى ردًا من خواديم الواجهة الخلفية في فترة الوقت المسموح بها. يمكن لهذا الخطأ عادةً أن يحصل في الحالات التالية: اتصال الشبكة بين الخواديم ضعيف. خواديم الواجهة الخلفية التي تقوم بتنفيذ الطلب بطيئة جدًا، بسبب الأداء الضعيف. فترة المهلة لخادوم البوابة أو الوسيط قصيرة جدًا.الخاتمةيجب أن تكون قد صرتَ الآن مُدركًا لأبرز رموز أخطاء HTTP وأبرز الحلول المتوفّرة لهذه الأخطاء، يجب أن تمتلك أساسياتٍ جيّدة لاكتشاف الأخطاء وإصلاحها على خواديم الويب الخاصّة بك أو تطبيقاتك. ترجمة -وبتصرف- للمقال How To Troubleshoot Common HTTP Error Codes لصاحبه Mitchell Anicas.