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

إذا كنت مهتما بتعلم البرمجة، فعلى الأرجح أنك رأيت هذا الاقتباس من قبل: في الحقيقة لا أبالغ إن قلت أن البرمجة أصبحت من أهم المهارات في عصرنا الحالي، وذلك لأنها دخلت في جميع مجالات حياتنا سواءً كنا ندرك ذلك أم لا فانطلاقًا من الهواتف المحمولة ومرورًا بالمنازل والشاشات الذكية وانتهاءً بالسيارات ذاتية القيادة. كل شيء من حولنا لم نكن لنراه بهذا الشكل لولا البرمجة، فأنا على سبيل المثال أكتب وأعدل هذا الموضوع من خلال برنامج بُرمج عبر لغة برمجة وأنت تقرأه على الإنترنت باستخدام برنامج (المتصفح) وربما رأيته على مواقع التواصل الاجتماعي وكُلها برامج أيضًا. ومما لا شك فيه أن تعلم البرمجة أصبح ضرورة مُلحة في هذا العصر بل إن تعلمك لها سيزيد من فرصك بشكل كبير في الحصول على عمل. ولقد تحدثنا في مقالٍ سابق عن كيفية تعلم البرمجة والدخول إلى هذا المجال من أوسع أبوابه (إن كنت حديث عهدٍ في البرمجة أو تخطط للبدء بها، فننصحك بقراءته قبل إكمال هذا المقال) وسوف نتحدث في هذا المقال عن أكثر المهارات صعوبةً في احتراف البرمجة ألا وهي «حل المشاكل». حل المشكلات وارتباطها بالبرمجة لطالما وقفنا حائرين أمام مشكلةٍ ما ونسأل أنفسنا ماهي الطريقة الصحيحة للخروج من هذا المأزق؟ هل ستكون طريقة الحلّ التي أتبعها مشابهة للطريقة التي يتبعها المبرمجين المحترفين؟ كيف أستطيع أن أفكر مثلما يفكر المبرمجين المحترفين؟ في البداية وقبل الخوض في التفاصيل دعنا نُعرف البرمجة بحد ذاتها ولنذهب للمقال السابق ونلقي نظرة سريعة عليها: نلاحظ أن التعريف السابق صحيح ولكنه مُقْتضَب ولا يقدم لنا المعنى الكامل والدقيق للبرمجة لذا لابدّ لنا من تعريفٍ أكثر دقة وموضوعية يساعدنا في فهم هذا المقال. يعرف موقع HackerRank في تقريره عن مهارات المطورين بعام 2018: نستنتج مما سبق أن البرمجة تعتمد اعتمادًا أساسيًا على التفكير المنطقي والرياضي والقدرة على حلّ المشاكل وإن لغات البرمجة ما هي إلا وسيلة للتخاطب مع الحاسوب. إذن الأمر كله يتعلق بتطوير قدرتك في حلّ المشاكل وجعل هذه العملية سهلة وسلسة بنفس الوقت لذا فاسمح لي بأن آخذك معي برحلة صغيرة في هذا المقال نتعرف فيها على أهمية حلّ المشاكل وضرورتها في مشوارك البرمجي. دورة علوم الحاسوب دورة تدريبية متكاملة تضعك على بوابة الاحتراف في تعلم أساسيات البرمجة وعلوم الحاسوب اشترك الآن لماذا حلّ المشاكل مهم؟ تأتي أهمية حل المشاكل من كونها من أكثر المهارات المطلوبة عالميًا فوفقًا لتقرير أصدره موقع HackerRank جاء فيه: احتلت مهارة حلّ المشاكلالمرتبة الأولى بنسبة 94.9% لأكثر مهارة مطلوبة لأصحاب الشركات سواء الصغيرة منها أو الكبيرة. وعلى الصعيد العملي، إن عملية بناء أي شيء من الصفر سواء أكانت آلة معينة أو أي مُنتج جديد ستواجه الكثير من المشاكل في البداية، فعلى سبيل المثال بناء خدمات أمازون السحابية (AWS)، والّتي جاءت حلًا لمشكلة النفقات العالية للبنية التحتية لتجارتها الإلكترونية بالإضافة إلى الوقت الطويل الّتي تحتاجه في عملية البناء والذي شكل تحدي كبير في إمكانية توسع الشركة، إلى أن جاء آندي جاسي كبير مستشاري جيف بيزوس في ذلك الوقت والذي استطاع إيجاد حلّ لهذه المشكلة ولم يتوقف عند ذلك الحد وإنما أختار تحويل هذا الحلّ إلى خط أعمال جديد تحت أسم خدمات أمازون السحابية والّتي بلغت عائداتها السنوية لعام 2018 قيمة تناهز 25 مليار دولار. نجد من التجربة السابقة أنه حصلت مشكلة فأُوجِد لها حلًا وأثناء خلق حل للمشكلة ظهرت الكثير من المشاكل الأخرى لتقع في سلسلة من المشاكل لا تنتهي. وبعد حلّ جميع المشاكل سيصبح المنتج جاهزًا للعمل، أي أن دورة حياة أي منتج سواءً أكان برمجيًا أو ماديًا ستحتوي على المشاكل، وبناءً على ذلك تكون مهارة حل المشاكل اللَبِنَة الأساسية في بناء مشوارك البرمجي، والّتي يجب علينا الإهتمام بها عند الإقدام على تعلّم البرمجة. تكون طريقة تعاملنا مع المشاكل غير منظمة وعشوائية في أغلب الأحيان، فمعظمُ المبرمجين الجُدد يَبْدَؤُونَ بحلّ أي مشكلة تُواجهُهُم بالطريقة التالية: جرّب أي حلّ للمشكلة. إذا لم ينجح الحلّ الأول حاول أن تجرّب أي حلّ آخر. إذا لم يفلح الحلّ كرر الخطوة الثانية إلى أن تصل إلى الحلّ. لا يحصل هذا الأمر مع المبرمجين فقط، وإنما يحصل مع أي شخص يواجه مشكلة ولا يستعن على حلها بالتحليل والتفكير المنطقي. في الحقيقة، قد يحالفك الحظ أحيانًا ويتم حلّ المشكلة ولكن كن حذرًا! فهذه هي الطريقة الأسوأ لحلّ المشكلات بل وإنها ستهدر وقتك بشكل كبير لذا من الأفضل استخدام طريقة منظمة توصلنا للحلّ، واسمح لي بأن أشاركك طريقة شاملة توصلك إلى حلّ أي مشكلة قد تواجهك. بناء خطة حلّ شاملة إن خطة الحلّ الشاملة هي مجموعة من الخطوات الَّتي تتبعها لحلّ أي مشكلة تواجهك، حيث تكون هذه الخطة عامة وتخصص بحسب المشكلة، وهي ليست تعليمات ثابتة وإنما مبادئ ننطلق منها جميعًا، وكلٌ منا يطبقها بأسلوبه الخاص، وفي نهاية المطاف إذا انطلقنا جميعًا من نفس المبادئ، فسنصل حكمًا على نفس جودة الحلّ أيضًا. إن هذه الخطة مؤلفة من عدة أجزاء ويناقش كلّ جزء فيها جانبًا معينًا من المشكلة إلى أن نصل للحلّ، وهي على الشكل التالي: 1. فهم المشكلة إن فهمنا للمشكلة المطروحة هي الخطوة الأكثر صعوبة في طريقنا لحلّها، بل إن أكثر المشاكل تأتي صعوبتها من عدم تمكننا من فهم عميق لها. ولكن متى تعلم بأنك استطعت فهم المشكلة؟ إذا كنت قادرًا على شرحها بكلمات واضحة وسهلة بحيث يستطيع أي شخص فهمها عندها تكون بالفعل قد فهمت المشكلة. هل تذكر عندما كنت عالقًا في مشكلة وبدأت بشرحها فوجدت أخطاء منطقية كثيرة لم تكن قد انتبهت لها من قبل؟ أغلب المبرمجين قد مروا بهذه الحالة من قبل، لذلك من الأفضل دومًا أن تكتب المشكلة الَّتي تواجهك باستخدام مخططات الحالة (State diagram وهي نوع من المخططات الَّتي تستخدم لتوصيف سلوك نظام ما) أو بأن تخبر شخص آخر عن المشكلة سواءً أكان زميل لك في الشركة أو عضو في الفريق أو أي شخص أخر. شاع بين المبرمجين استخدام البطة المطاطية في شرح أجزاء المشكلة لها لفهمها وإيجاد حل لها. يعد أسلوب البطة المطاطية في تنقيح الأخطاء من أكثر الأساليب سهولة وبساطة، إذ يضع المبرمج بطةً بجوار حاسوبه، وعند مواجهته لأي مشكلة يشرع في شرح الشيفرة البرمجية للبطة وما هي النتيجة المرتقبة من الشيفرة وموازنتها مع النتيجة الحالية وغالبًا ما يجد الخطأ أثناء شرحه. وخلاصة لهذه الخطوة أنقل إليك مقولة ألبرت أينشتاين: 2. تحليل المشكلة إن تقسيم المشكلة يلعب دورًا مهمًا في طريقك لإيجاد الحلّ، لذا حاول أن تقسّمها إلى أجزاء صغيرة ثمّ حُلّ كلَّ جزء منها على حدة ويُنصح في البداية بحلّ أسهل جزء منها ومن ثمّ الأصعب فالأصعب وهكذا إلى أن يتمّ حلّ جميع أجزائها، وبعدها إجمع هذه الأجزاء مع بعضها للحصول على الحلّ النهائي للمشكلة الأصلية (الكبيرة). منذ فترة كنا بصدد برمجة إضافة لمتصفح غوغل كروم بهدف تسهيل مهمة لموقع ما، فقررنا تجربة هذه الطريقة وبدأنا بتقسّيم المهمة على أجزاء ثم عملنا على حلّ كل جزء منها، وبعدها جمعنا هذه الأجزاء مع بعضها بعضًا لبناء الإضافة، وبالفعل كان العمل بهذه الطريقة سهلًا جدًا ومريحًا كما لم نعهده من قبل. في بعض الأحيان عندما تواجه شيفرات برمجية كتبها مبرمجون لا يتبعون مبادئ SOLID (وهي مجموعة من العادات والمبادئ الَّتي يتبعها المبرمجون للحصول على شيفرة برمجية قابلة للصيانة وسهلة التعديل والتكيف مع متطلبات المشروع المتغيرة)، وغالبًا ما تكون شيفرات أولئك المبرمجين غيرمفهمومة ومتشابكة ويطلق عليها اسم Spaghetti code (تكون هذه الشيفرات ذات بنية معقدة ومتشابكة وصعبة القراءة وغير مرتبة أي تكون مثل المعكرونة ملتوية ومتشابكة) ولنفرض أنه طُلبَ منك تعديل هذه الشيفرة أو إضافة وظائف جديدة إليها،عندها حتمًا ستواجه العديد من المشاكل في عملية تقسيم المشكلة ومعرفة أي جزء من الشيفرة البرمجية المُسبب للخطأ لذا كان الحصول على شيفرات برمجية مرنة وقابلة للتعديل هي الأرضية المشتركة بين العديد من تقنيات تبسيط الشيفرات البرمجية مثل مبادئ SOLID أو مبدأ MVC والذي ينص على تقسيم الوحدات من حيث طبيعة مهمتها إلى ثلاثة أقسام (Model-View-Controller) والبرمجة كائنية التوجه OOP (Object-Oriented Programming)، إذ أن جميعهم يهدفون إلى فصل الأكواد إلى أقسام ليسهل تطويرها وتنقيحها وصيانتها. 3. إعداد خطة للحل بعد أن فهمت وحللت المشكلة، يأتي دور وضع الخطة المناسبة للحلّ بحيث تغطي كافة الجوانب والتفاصيل للمشكلة، ولا تشرع في الحلّ من دون خطة (على أمل أن تجد الحلّ بطريقة ما) لأن المفتاح الرئيسي للوصول للحلّ هي الخطة الواضحة والمنظمة والتي تضمن وصولنا للحلّ النهائي. أعط لنفسك وقتًا لتحلّيل المشكلة وربط المعلومات المدخلة إلى البرنامج ونوعها والمعلومات الَّتي ستظهر كخرج للبرنامج وفهم سياقها وللحصول على خطة جيدة يجب عليك الإجابة على السؤال التالي: إذا أُعطي للبرنامج الدخل س، ما هي الخطوات اللازمة للحصول على الخرج ع؟ إن إجابتك على هذا السؤال سوف يحدد ماهي الخطوات اللازمة لحلّ المشكلة ومن ثَمَّ تقوم بترتيبها في خطة واضحة ومنظمة من أجل الحصول على الخرج الذي تريده. 4. مواجهة حالة السكتة البرمجية ماذا لو فرضنا أنك لم تستطع حلّ أي جزء من المشكلة، ولا حتى الأجزاء السهلة منها (وهذا قد يحدث في بعض الأحيان)، إن كثير من المبرمجين يقعون في هذه الحالة فلا يستطيعون أن يُحرزوا أي تقدم يذكر في تطوير الشيفرة البرمجية وهذا أشبه ما يمكن بالسكتة الدماغية (حيث لا يستطيع المريض القيام بأي حركة)، في الحقيقة إن هذه الحالة طبيعية جدًا ومعظمنا قد تعرض لها في بداية مشواره والاختلاف الوحيد هو أن المبرمج المحترف لديه فضول أكثر حول المشكلة ومعرفة سبب حدوثها بدلًا من أن يكون منزعجًا أو غاضبًا منها. وفي هذه الحالة هنالك حلّين يمكنك تجربتهما للخروج من هذا المأزق: 1-4. تنقيح الأخطاء (Debug) ليس المقصود هنا الأخطاء الكتابية في صياغة اللغة (Syntax errors) مثل نسيان فاصلة منقوطة أو أي خطأ في استخدام المتغيرات أو الدوال أو ما شابه ذلك من أخطاء والَّتي تقوم باكتشافها أي بيئة تطوير متكاملة (IDE وهي عبارة عن محرر شيفرة برمجية مدمج مع نظام ذكي لإكمال الكود ومصحح أخطاء). وبالطبع ليست أيضًا الأخطاء الّتي تظهر أثناء التنفيذ (Runtime Errors) والّتي تكون عادة نتيجة لفشلٍ في فتح ملف ما أو محاولة القسمة على صفر أو مثل هذه الأخطاء، وإنما المقصود هنا هو أخطاء المنطق البرمجي (Logic errors) الّتي ينفِّذ فيها البرنامج أمرًا غير الَّذي بُرمج من أجله، لذا من الأفضل أن تحاول أن تفحص الشيفرة البرمجية سطرًا سطرًا لعلك تجد هذا الخطأ، أوإذا كنت تعمل على لغاتٍ مثل (C++, C) والّتي تدعم استخدام المُنقِّح Debugger (الذي يراقب عمل البرنامج ويتحكم في تنفيذه بطريقة تستطيع فيها إيقاف تنفيذ البرنامج أو حتى تغييره في أي موضع من الشيفرة وذلك من خلال مجموعة من الأدوات الّتي يقدمها المُنقِّح، مثل: GNU Debugger) فيمكنك استخدامه لإيجاد الخطأ ومن ثَمّ إصلاحه. ملاحظة : من المنهجيات البرمجية الجيدة هي كتابة تعليقات توضيحية قبل كلّ دالة (Function) أو صنف (Class) برمجي وخُصوصًا تلك الأجزاء المعقدة منها لأن ذلك سوف يساعدك كثيرًا في عملية مراجعة الشيفرة البرمجية وتنقيحها. 2-4. مراجعة وتقييم الحلّ في كثير من الأحيان عند مواجهتنا للمشاكل وخصوصًا للكبيرة منها قد نضيع في التفاصيل الصغيرة للمشكلة الَّتي نواجهها وننسى المشكلة الرئيسية ولذلك من الأفضل دومًا أن نسأل أنفسنا هل هذه هي الطريقة الأفضل للحلّ؟ هل هنالك حلًّا عموميًا أفضل من الموجود؟ هل الشيفرة البرمجية أمثلية؟ هل الحلّ يخرق معايير الجودة المطلوبة؟ ارجع خطوة إلى الوراء وحاول أن تراها من منظور مختلف، وحتمًا ستلاحظ العديد من المشاكل التي غفلت عنها أثناء انشغالك بالتفاصيل الصغيرة. ملاحظة : هنالك طريقة أخرى يتبعها بعض المبرمجين لإعادة تقييم الحلّ وهي حذف الشيفرة البرمجية الخاطئة بالكامل وإعادة كتابتها من جديد فكثير ما يأخذ ذلك وقتًا أقل من تتبع المشكلة ذاتها وحلها. 5. البحث عن حلول عبر الإنترنت إن أغلب المشاريع البرمجية تكون متشابهة بكثيرٍ من الوظائف والخصائص، ونادرًا ما نرى مشروع ذو أفكارٍ جديدة بالكامل لذا فإن أي مشكلة برمجية تواجهها قد واجهها عدد كبير من المبرمجين من قبلك وأوجدوا لها حلولًا وشاركوها مع غيرهم، وكل ما عليك فعله هو أن تتعلم كيف تبحث عن المشكلة. وبالطبع صديقنا stackoverflow والذي يعد من أشهر منصات مشاركة الحلول البرمجية الّذي يقدم لك الحلّ الَّذي أجمع عليه أغلب، المبرمجين، ويوجد العديد من المنصات الأخرى المشابهة مثل AskUbuntu وهو النسخة العربية من موقع stackoverflow والكثير غيرهم، وحتى لو أنك قد حللت المشكلة أنصحك بتصفح الحلول الموجودة لأنك سوف تتعلم طرقًا أُخرى لحلّها قد تكون أسهل وأفضل بكثير من الحلّ الَّذي وصلت اليه. إلى الآن نكون قد ناقشنا الخطوة الأولى من الطريقة الشاملة لحلّ المشاكل والآن لننتقل إلى الخطوة الثانية. التدرب على هذه الخطة إن أي مهارة جديدة تحتاج إلى تدريبٍ مُمنهجٍ ومستمرٍ حتى تتقنها. لذا لا بدّ لك من وضع خطة واضحة للتدريب وتخصيص زمن محدد وثابت تقضيه في صقل تلك المهارة.يمكنك البدء مثلًا بتخصيص ساعة للتدريب يوميًا لمدة شهر كامل، وبعدها توازن نفسك مع ما كنت عليه في السابق من سرعةٍ في تحديد المشكلة وجودةٍ الحل المطروح والوقت الإجمالي لحل المشكلة وبكل تأكيد ستلاحظ تحسنًا واضحًا في أدائك. وقد تساءل نفسك كيف يمكنني التدرب على حلّ المشاكل؟ في الحقيقة هنالك طريقة مفيدة جدًا أنصحك بها لتكوين قاعدة صلبة تنطلق منها، وهي على الشكل التالي. 1. التدرب على المسائل البرمجية تعد المسابقات البرمجية سواءً على مستوى الجامعة أو على مستوى القطر أو حتى على مستوى العالم مثل مسابقة ACM ICPC من أفضل الفرص للتدريب في مجال البرمجة وصقل هذه المهارة بل وتعتبر دفعة كبيرة لك في رحلتك كمبرمج ولمستقبلك المهني أيضًا، إذ تبادر العديد من الشركات العالمية لِضمّ أولئك المنافسين المتميزين إليها بعد أن أثبتوا بالفعل أنهم النخبة في مجالهم. فإن كنت تخطط للانضمام إلى هذه المسابقة فلا تتردد وبادر بالتحضير لها من الآن. ويقدم لنا الكاتب Steven Halim في كتابه Competitive Programming بعض الفوائد الَّتي نجنيها من التدرب على حلّ المشاكل البرمجية في المسابقات. السرعة في كتابة الشيفرة البرمجية كتابة الشيفرة البرمجية بسرعة في المسابقات يوفر لك الكثير من الوقت للتفكير في بقية المشاكل واختبارها لذلك نرى أغلب المبرمجين يتدربون على سرعة الكتابة على لوحة المفاتيح لينصب تركيزهم على حلّ المشكلة فقط، ولذلك من المنطقي أن تفضل الشركات الموظفين الَّذين سَبق إن شاركوا في المسابقات البرمجية لمعرفتها بسرعة إنتاجيتهم وقدرتهم على تطوير وإيصال منتج برمجي بسرعة عالية بِالْمُوازنة مع أقرانهم ممن لم يشاركوا في المسابقات. العصف الذهني وحصر الخوارزميات الممكنة لا بدّ من تحسين قدرتك على تحديد نوع المسألة بسرعة وأن تمتلك المعرفة الكافية بالخوارزميات لتتمكن من تطبيقها مباشرة على المسألة المطروحة، لذلك ينبغي على المبرمج الَّذي ينوي الانضمام إلى المسابقة أن يتمكن من جميع الخوارزميات الشائعة في المسائل البرمجية. العمل الجماعي وروح الفريق تعتمد المسابقة البرمجية على ترتيب الفرق بحسب عدد المسائل الَّتي أجابوا عليها، والوقت الَّذي استهلكوه لحلّ كُلَ مشكلة، وعدد الحلول الخاطئة الَّتي أُرسلت للحكم. وانطلاقًا من ذلك تكون فوائد العمل كفريق واحد متعددة منها إمكانية توزيع المسائل على كلّ عضو في الفريق بحيث يزداد العدد الكلي للمسائل المحلولة بتوزيعها بين بعضهم بعضًا، ومناقشة حلّ كلّ مسألة وبذلك ينقص عدد الحلول الخاطئة الَّتي قد تُرسل للحكم، وحُكمًا سينقص الوقت المستغرق لحلّ المسائل. وعلى الصعيد العملي أيضًا نجد أن طبيعة عمل المبرمجين سواءً في الشركات الصغيرة أو الكبيرة، يُطلب منهم العمل كفريق واحد، فعلى سبيل المثال منذ فترة طَلَبَ مني أحد العملاء بناء موقع ويب، وكنت عندها قد أنتهيت من بناء فريقي البرمجي. وبالفعل بدأنا العمل على الموقع و قسّمنا العمل على أجزاء فعكف كلُّ واحد منا على تطوير جزئه الخاص من الموقع، إذ استلمتُ جزء الواجهات الخلفية، وقام أحد أعضاء الفريق باستلام الواجهات الأمامية، والآخَر استلم بناء تطبيق للهواتف الّتي تعمل بنظام أندرويد وفي نهاية الأسبوع جمعنا كل الأجزاء مع بعضها بعضًا وأنهينا المشروع بوقتٍ قياسي لم نكن لنستطيع بلوغهُ لو أننا لم نعمل كفريقٍ واحد، ولذا فإن انضمامك إلى المسابقة البرمجية يجعلك تتدرب على العمل ضمن فريق قبل أن تواجهها في سوق العمل في حال أردت العمل مع أي شركة مستقبلًا. المرونة العصبية إن تدريبك المستمر على المسائل البرمجية سيؤدي إلى زيادة منطقة الحصين (المنطقة المسؤولة عن الذاكرة والتوجيهات) في الدماغ وهذا ما أثبتته الباحثة اليانور ماجواير من كلية لندن الجامعية عندما أجرت دراسة على سائقي الأجرة في مدينة لندن فقاموا بإجراء فحص بالرنين المغناطيسي الوظيفي fMRI لأدمغة السائقين الذين قضوا قرابة عامين من التدريب في سبيل تعلم كيفية التنقل في منعطفات المدينة وذلك من أجل الحصول على رخصة القيادة ومقارنتها بصور لأدمغة رجال أصحاء من نفس العمر ولا يعملون كسائقي أجرة فتبين أن منطقة الحصين أصبحت أكبر لدى السائقين، كما لاحظوا أنه كلما أمضى سائق الأجرة فترة أطول في التدريب، زاد حجم الحصين، وذلك استجابة إلى الخبرة الّتي يكتسبها السائق. والآن تخيل معي ما سيحدث في حال تدربك على حل المشاكل لمدة عام أو أكثر، سيصبح حلّك للمشاكل البرمجية عادة سهلة ومسلية خلاف ما كانت عليه من صعوبة وتعقيد. يوجد العديد من المواقع الَّتي تقدم المسائل البرمجية مثل HackerRank أو موقع TopCoder والكثير غيرهم. 2. التدرب باستخدام الألعاب نعم أنت لم تخطئ القراءة إنها الألعاب! تعد الألعاب أداة قوية جدًا لتنمية المهارات العقلية والقدرات الدماغية على التفكير والتذكر وربط المعلومات ببعضها بعضًا، حيث أن غالبية الألعاب تحتاج لتجميع المعلومات وتنظيمها بحيث تستطيع الاستفادة منها وجعلها مفتاحًا للحلّ، بل إن الركيزة الأساسية الَّتي تشترك بها كافة الألعاب هي حلّ المشاكل! بالتأكيد نحن لا نقصد هنا ألعاب الفيديو فقط وإنما ألعاب الذكاء أيضًا مثل : لعبة الشطرنج، والألغاز الرياضية، ولعبة سودوكو، ولعبة Go، والكثير من الألعاب الَّتي تندرج تحت هذا السياق تعد ألعاب مفيدة. فعند محاولتك حلّ الألغاز في Saw أنت فعليًا تقوم بحلّ المشاكل (ولكن بإطار مختلف). وتساعدنا أيضًا في انشاء سيناريوهات للحلّ وهذه المهارة مفيدة في عالم البرمجة في حال تعثرت في أسلوب حلّ معين فتغير سيناريو الحلّ وتبدأ من جديد. في الحقيقة إن الشيء المشترك بين جميع الناس الناجحين هي اكتسابهم لعادات يومية لحلّ المشاكل الصغيرة على سبيل المثال بيتر تيل (أحد مؤسسي شركة باي بال والمصنف كرابع أغنى شخص على مستوى العالم لعام 2014 بميزانية تفوق $2.2 بليون دولار) صرح بشكل رسمي أنه يلعب الشطرنج يوميًا بل وشارك في بطولات الشطرنج مرات عديدة، وإيلون ماسك (رائد الأعمال والرئيس التنفيذي لعدة شركات مثل: سبيس إكس لتصنيع مركبات الفضاء وتسلا لصناعة السيارات الكهربائية وغيرها)أكد بأنه يلعب ألعاب الفيديو والكثير غيرهم كرسوا جزءًا من وقتهم اليومي لتنمية مهارة حلّ المشاكل. ولكن يجب أن تكون حذرًا في إدارة وقت اللعب ويُفضل أن تختار الأوقات المناسبة للعب ووضع مدة زمنية مخصصة لها، وذلك لأن الهدف ليس إضاعة الوقت والتسلية فقط وإنما التدرب على حل المشاكل ولكي لا ينتهِ بك المطاف إلى قضاء اليوم بأكمله على الألعاب. الخلاصة اعتقد أنك قد كونت فكرة جيدة عن أهمية حلّ المشاكل وضرورتها في مشوارك البرمجي وكيفية بناء خطة حلّ شاملة انطلاقًا من فهم المشكلة وتحليلها ومرورًا بإعداد خطة مخصصة لكلّ مشكلة وتقسيم المشكلة إلى أجزاء ليسهل حلّها ومواجهة حالة السكتة البرمجية وكيفية التغلب عليها من خلال تنقيح الأخطاء أو مراجعة وتقييم الحلّ، وأهمية البحث عن حلول على الإنترنت لنفس المشكلة وانتهاءً بالأسلوب الصحيح للتدرب على حل المشاكل وما هي أفضل الوسائل لتحقيق ذلك سواءً بالانضمام إلى المسابقات البرمجية أو بالتدرب بإستخدام الألعاب. وختامًا، لا تتوقع أن تصبح مبرمجًا محترفًا في غضون أسبوعٍ أو شهر واحد فهذا ضرب من الخيال بل ستحتاج لحلّ الكثير من المشاكل لبناء قاعدة معرفية صلبة تمكنك من مواجهة أي مشكلة مهما كانت صعوبتها وعندها بالتأكيد سوف تستحق لقب مبرمج محترف. اقرأ أيضًا تعلم لغة PHP تعلم لغة بايثون

يعدُّ التحضير لأسئلة المقابلة في مجال هندسة البرمجيات عملًا بدوام كامل تقريبًا، إذ هناك مصادر لا حصر لها على الإنترنت وغالبًا ما تكون هائلة عندما تبدأ العملية، ومن الطبيعي أن تكون متوترًا وخائفًا عند التقدم لمنصبٍ ما، لأنك تواجه خطر الحكم والرفض وهذا يكفي لإثارة قلق أي شخص. ومع ذلك فإن أفضل طريقة لتهدئة أعصابك هي الاستعداد الكامل حتى تعرف أنك تعطي نفسك أفضل فرصة للحصول على وظيفتك المثالية، ستقلل الممارسة والتحضير من الإحساس بالغموض وتساعد على تحضير نفسك للنجاح. إذا كنت مهندس برمجيات متخرج وتستعدّ لمقابلات العمل الأولى لك، فإليك المجالات المختلفة التي يجب التركيز عليها. أسئلة حول المعلومات الأساسية الخاصة بك يجب أن تكون مستعدًا للإجابة على الأسئلة المتعلقة بمعلوماتك الأساسية، خبرتك، مشاريعك السابقة ومعرفتك. تكون هذه الأسئلة عادةً مفتوحة وتمنحك فرصةً جيدةً لاختيار ما الذي تريد التحدث عنه، بعض الأمثلة على هذه الأسئلة يمكن أن تكون: أخبرني عن مشروع عملت عليه، وما الذي جعلك تستمتع أو لا تستمتع؟ أخبرني ماذا تعلّمت من العمل على هذا المشروع هل يمكنك التحدّث عن بعض الصعوبات التي واجهتها؟ كيف نسّقت المهام بين أعضاء الفريق؟ إذا قمت بإعادة هذا المشروع ثانيةً، هل ستفعل شيء ما بشكلٍ مختلفٍ؟ يمكنك التحدّث عن المشاريع التي عملت عليها خلال فترات التدريب أو خلال توظيفك في خبرة عملية أو خلال العمل في مقرر جامعي اعتمادًا على خبرتك، أيّ تجربة مررت بها لها قيمتها فلا تستخف بالمعرفة التي اكتسبتها من خلالها، عند الحديث عن تلك المشاريع السابقة ستكون الإجابة رائعة عندما تتضمن وصف وأهداف المشروع وأصحاب المصلحة فيه وتأثيره أو إجابة على الأسئلة "ماذا"، "مَن"، "كيف" و"لماذا". سيساعدك هذا في إثبات أنَّ لديك فهمًا جيدًا للعملية بأكملها وليس فقط للجانب التقني للأمور. ومن الجيّد أن تُدرج مقاييس النجاح إذا كانت ذات صلة، مثلًا: "هذا ساعد الناس على القيام بالمهمة x بشكلٍ أسهل"، "قمت بأتمتة هذه العملية مما وفر مقدارًا من الوقت للفريق" وغير ذلك. هذا يُظهر مدى اهتمامك بتأثير عملك. حتى لو كان هناك شيئًا يبدو عديم الأهمية بالنسبة لك، تذكر أن الشخص الذي يقابلك لا يعرف عنك شيئًا، إنّهم يبدؤون بصفحة فارغة بالكامل ولديهم فترة زمنية قصيرة ليفهموا كيف تتفاعل مع الأشخاص، ما الذي يثيرك في عملك وكيف تهدف لتحقيق النجاح. اغتنم الفرصة للتفكير في خبراتك وتحديد مجالات النمو للحديث عنها. يدرك المقابِلون أنّ لا أحد مثالي لكنهم يقدرون عقلية النمو. هل حددت بعض العمليات التي يمكن ضبطها؟ ربما كان تواصلك كان يمكن أن يكون أفضل في حالة معينة؟ أسئلة حول الشركة سيسألك المقابِلون سؤالًا اعتياديًّا عن العوامل التي جذبتك إلى الشركة وإلى المنصب الذي تتقدم إليه، من الضروري القيام ببعض الأبحاث حول الشركة مسبقًا وتحضير إجابات للأسئلة مثل: ما الذي يثير اهتمامك في صناعتهم؟ ما الذي جعلك مهتمًا بالشركة؟ ما الذي تتوقع تحقيقه من خلال العمل هناك؟ كيف تتناسب معرفتك مع ما يقومون به؟ ما الذي جعلك تعتقد أنك ستكون مناسبًا لثقافتهم؟ المعرفة المسبقة حول المنتجات التي يبنونها يمكن أن تأخذك شوطًا طويلًا، يتضمن ذلك فهم فضاء المنتج والاطّلاع قليلًا على مجموعة التقنيات. إذ أستفيد عادةً من الاستعدادات للمقابلة كفرصة لتعلّم شيء جديد وفهم ما إذا كنت مهتمًا بالمساهمة في ذلك. بعدها أكون قادرًا على طرح المزيد من الأسئلة ذات الصلة في المقابلة، بالإضافة إلى ذلك أجد أنّه من الأسهل بكثير أن أكون ناجحًا في مجال يثير اهتمامي. لا تقلق بشأن عدم معرفة جميع التقنيات التي يستخدموها. الانفتاح حول ما لا تعرفه (حتى الآن) يبدو جيدًا لمعظم المقابِلين. إظهار الاهتمام بتعلّم مجالهم حتى قبل توفير الوظيفة يبدو أفضل. بالنسبة للأسئلة الثقافية، يتوقع المقابِل أن يرى كيف تتفاعل مع الأشخاص الآخرين. إذا كانت لديك تجربة تدريب، فقد يسألونك عن كيفية تعاونك مع زملائك. مثلًا الوصول إلى المساعدة عندما تحتاجها، قضاء بعض الوقت في مساعدة الآخرين، التغلب على التحديات وتلقي أو تقديم التغذية الراجعة هي بعض مجالات المواضيع المحتملة. أسئلة المقابلة العامة بالنسبة للجانب التقني للأشياء فإنَّ إدراك مبادئ تطوير البرمجيات مثل البرمجة كائنية التوجه والتطوير الموجه بالاختبار والتركيب المتواصل وأنماط التصميم والتحكم بالنسخة هو أمرٌ أساسيٌّ. قد تكون محتاج أيضًا لتعلّم أساسيّات الشبكات أو قواعد البيانات أو الأنظمة حسب طبيعة المنصب الذي تتقدم له. اقرأ وصف الوظيفة بدقة، وحضّر نفسك لتكون قادرًا على إعطاء التعريفات والتحدّث حول المزايا الأساسية. قد لا تملك خبرة عمليّة، ولكن من الجيد أن تكون قادرًا على شرح لماذا هذه التقنيات مهمة ومناقشة بعض اتجاهات الصناعة. ليس عليك أن تعرف كل المتطلبات الموجودة في وصف العمل. أخبرني مرشدي الأول أنّني يجب أن أتقدّم لمنصب ما بالاعتماد على ما الذي أريد أن أكون عليه، بدلًا من الذي أنا حاليًا عليه. إذا كان لديك القليل من وقت الفراغ، فإن محاولة بناء بعض المشاريع الجانبية الصغيرة لتحسين معرفتك بتقنية جيدة هي فكرة رائعة أيضًا. حل المشاكل يأتي هنا الجزء الذي يقلق معظم الأشخاص بسببه. جلسات "حل المشاكل"، التي تختبر فهمك لبنى المعطيات والخوارزميات والتعقيد. خلال مرحلة التحضير هناك مواد غير محدودة على الإنترنت تساعدك على التحضير. الكتاب التقليدي الذي يعطّل العملية ويوفر المشاكل والحلول هو كتاب Cracking the Coding Interview لـ Gayle Laakmann McDowell. المصادر على الإنترنت مثل LeetCode وHackerRank هي بدائل جيّدة. يجب عليك معرفة ما هي الأعمال الأفضل لك بينما أنت تدرس. شخصيًّا أفضّل حل المشاكل والتحديات الصغيرة، مثل code katas أو advent of code. ومع ذلك يمكن أن يكون مضيعة للوقت. لذا عندما أريد أن أتعلّم أسرع، أجد الحلول على الإنترنت وأطبّقها بنفسي لفهم الخوارزمية. هناك الكثير من مقاطع الفيديو على اليوتيوب تشرح كيفية عمل خوارزمية معينة يمكنك أن تستخدمها. عندما تطبّق حلّ ما، خذ بعض الوقت لتقوم بدفعه (push) إلى حسابك على Github. لن يكون مفيدًا فقط إذا احتجت إليه مرة أخرى لاحقًا، لكن سيساعدك أيضًا في بناء معرض أعمالك. خلال المقابلة نفسها تأكد من أنّك فهمت المشكلة بشكلٍ كامل. اطلب من الشخص الذي يقابلك توضيح الأسئلة للتأكد من أنّك تعرف المطلوب منك. لا تنتقل إلى كتابة الشيفرة بدون أن يكون لديك معلومات كافية. مثلًا، يجب أن تتأكد من أنّك تعرف من أين تقرأ الدخل، ما هو تنسيق الدخل وحجم البيانات. ابدأ مع حل "القوة العنيفة" (brute force) ولا تفكر في الأداء بعد. اتركه بسيطًا. اشرح للمقابِل طريقة تفكيرك واذكر أنّك ستجرب حل القوة العنيفة أولًا. لا تقلل من صعوبة المهمة. فحتى الاختبارات التي تبدو بسيطة مثل اختبار FizzBuzz) يمكن أن تعطي انطباعًا سريعًا عن كيفية تحليل المشكلة وفهمها. يبدأ عادةً الاختبار يبدأ بسيطًا ويتقدم تدريجيًا. اذكر أيّة افتراضات تقوم بها. إذا كنت تستخدم توابع مكتبة للغةٍ ما من اختيارك، اسأل إذا كان يجب عليك تنفيذها. مثلًا الترتيب متوفر في معظم لغات البرمجة. بينما تتابع حل المشكلة، اشرح كيف تنقل بياناتك وأين تخزّنها وكيف تعالجها. يوضح هذا أنّك تفهم جيّدًا البيانات التي تتعامل معها ولا تحاول فقط تجربة الأشياء التي رأيتها حولك. يمكنك تقسيم مشكلتك إلى دوال أصغر بأسماء واضحة ثم المضي قدمًا والبدء بتنفيذ كلّ منها. غالبًا، يتوقع منك المقابِلون تنفيذ الحل البسيط أولًا، ثم سيسألونك عن التعقيد. حاول تحديد الحلقات المضمنة، والعمليات لحساب التعقيد. أبقِ تعقيد المساحة والزمن في عقلك. ما مقدار الذاكرة التي تحتاجها لتخزين الأشياء مقارنةً بدخلك وكم عدد العمليات التي تحتاج أن تقوم بها لتحصل على النتيجة. ذكّر نفسك بدرجة تعقيد الخوارزميات القياسية مثل خوارزمية الترتيب والبحث وغيرها ثم حاول معرفة أين يمكن تحسين الأشياء. ربما يمكنك استخدام بنية معطيات مختلفة؟ المصفوفات المترابطة (HashMaps) والمجموعات والقوائم المرتبطة هي بُنى نموذجية تستخدم لتحسين التعقيد اعتمادًا على المشكلة. من الجيد أن تكون هذه البنى بين يديك لتستخدمها في المشكلة الصحيحة. إذا كنت تعرف المشكلة والحل الأكثر فعاليةً مسبقًا، تابع العمل ولكن خذ بعض الوقت لشرح سبب كونه الحل الأمثل. إذا أبدى المقابِل أي رأي فكر بها جيّدًا. في معظم الأحيان، يكون المقابل يعرف الحل مسبقًا ويريد أن يساعدك لذا فإنّ اقتراحاته تستحق التفكير. ماذا لو لم تحلّ المشكلة؟ هل يعني هذا أنّك فشلت في المقابلة؟ ليس بالضرورة. المقابِل مهتم أكثر بطريقة تفكيرك. من تجربتي يركز المقابِلون على: ماذا تفعل عندما تكون عالقًا؟ هل أنت قادر على توضيح لماذا أنت عالقٌ، هل سيثقون بك عند إعطائك مهمة ويعرفون أنّك ستطلب المساعدة عندما تحتاجها؟ هل أنت قادر على فهم عمل بنى المعطيات أو هل تستخدمهم كمربع أسود؟ مثلًا استخدام المصفوفات المترابطة بدون سبب معيّن لذلك أو بدون توضيح لماذا يحسّن استخدامها من الأداء؟ هل أنت تتواصل جيّدًا بشكلٍ عامٍ؟ هل تتقبّل التغذية الراجعة أو تتحمس لحلك فقط؟ هل أحرزت أيّ تقدّم خلال المقابلة؟ هل يمكنك أن تعمل تحت الضغط أو تتوقف نهائيًا؟ أسئلة حول المقابِلين من الجيّد أن تحضّر بعض الأسئلة للمقابِلين أيضًا. تذكّر أنّه من المهم معرفة ما إذا كانت الشركة مناسبة لك أم لا. كلّما ازدادت المعلومات التي تعرفها، كان من الأسهل عليك اتخاذ القرار. عادةً أحضّر بعض الأسئلة للمقابلة مسبقًا، مثل: كيف تُنظَّم فرق الهندسة؟ كيف توزَّع المهام على الفريق؟ كيف يمكنك اختبار منتجاتك؟ ما الفريق الذي يحتمل أن أعمل معه؟ كيف تدعمون الأشخاص أثناء التدريب؟ كم يستغرق عادةً الشخص الجديد للتدريب؟ ما الذي يمكن أن يكون مثالًا لمهمة أعمل عليها؟ ما هي التقنيات الرئيسية التي تستخدمونها لهذا المشروع؟ ما الفرص المتاحة للعمل على مشاريع مختلفة؟ كيف يمكنك إجراء مراجعات الأداء؟ كيف يبدو التقدم الوظيفي لهذا المنصب تحديدًا؟ فكّر في يوم عملك المثالي - ما الذي تريد أن تعرفه عنه؟ يقيّم الأشخاص المختلفون أشياء مختلفة في العمل. مثلًا، قد تفضّل بيئة متغيرة ديناميكية توفر مزيدًا من الحرية، أو قد تشعر بالإنتاجية في بيئة أكثر تنظيمًا. قد ترغب في العمل بطريقةٍ استقلاليةٍ أو تفضّل أن تكون جزءًا من فريق. إنّها فكرةٌ جيّدة أن تعرف البيئة التي تساعدك على أداء الأفضل وتبحث عن الشركات التي تمنحك هذه الفرصة. إذا شعرت بأن المقابِل قد غطّى معظم أسئلتك فلست مضطرًا لأن تسأل لمجرد النقاش فقط. طريقة التفكير مهمة بالطبع، تعد مهاراتك التقنية مهمة جدًا لمقابلات هندسة البرمجيات، ولكن لا تقلل من أهمية مهاراتك الشخصية. سيعمل معك الأشخاص يوميًا لذا يجب أن يشعروا بأنّك شخص لطيف للعمل معه. هناك جزء كبير من العمل لا يتعلق بكتابتك للشيفرة البرمجية، إنّما بالتعاون مع المبادئ والفرق الأخرى. جمع وفهم المتطلبات، والقدرة على التعبير عن المشكلة بطرق تقنية وطرق غير تقنية، إبلاغ أصحاب المصلحة حول التقدم والمشاكل ليست سوى جزء منها. إذا كنت تعتقد أنّ لديك مصدر قوة في شخصيتك فحاول أن تظهر ذلك خلال العملية. اهدف للتحسين المستمر لا تنسَ أن إجراء المقابلات، مثله مثل أي شيء آخر، هو مهارة تتحسن مع الخبرة. لا تقلق بشأن الفشل، ركّز على ما تعلمته والقيام بأداء أفضل في المرة القادمة. عندما تكتسب بعض الخبرة ستصبح أقل توترًا وبالتالي سيكون من الأسهل أن تنجح. إنّها عملية من التطوير المستمر، يجب أن تتحسن في كل مرة تجري فيها مقابلة، لذا استمر في التحضير وفي تحسين مهارات التواصل لديك ومهاراتك التقنية. البحث الصحيح عن المعلومات هو المفتاح للتحضير الجيّد، ومراجع مثل موقع Quora أو حتى غوغل فقط هي مصادر جيّدة لأسئلة المقابلة الشائعة للشركات. قد تكون كل هذه المعلومات هائلة، لكنك لن تُسأل كل هذه الأسئلة في كل مقابلة. حاولت أن أجمع الأشياء المختلفة التي لاحظتها حتى الآن لأعطيك بعض المجالات لتستكشفها. القليل من التحضير المركّز يقطع شوطًا طويلًا، لكن لا تبالغ فيه. من السهل أن تفكر كثيرًا في مقابلة وتربط نفسك بعقد. حظًا سعيدًا، اذهب إلى هناك وكن رائعًا! هل لديك أيّة خطوات أخرى تستخدمها أثناء التحضير؟ شاركها معنا في التعليقات. ترجمة -وبتصرف- للمقال How to prepare for software engineering interview questions‎ لصاحبته Sofia Tzima

مهما تكن جودة منتجك، ستواجه صعوبة في جذب انتباه الناس إليه عند طرحه في السوق ما لم يكن لديك القدرة على خلق قصة مترابطة ومثيرة للإعجاب عن هذا المنتج. تَعرِف شركة أمازون ومثيلاتها من الشركات هذا الأمر جيدًا، كما تشتهر بفلسفة "الطريقة العكسية في العمل" (أي الاهتمام باحتياجات الزبائن قبل كل شيء) والتي يتم من خلالها البدء بكتابة نشرة إعلامية للحديث عن النظرة التي ستتكوَّن لدى الناس بخصوص المنتج ثمّ العمل بطريقة عكسية حتى الوصول لمرحلة تحديد مجموعة المتطلبات التقنية اللازمة لتحقيق الأهداف المرجوَّة من هذا المنتج. طريقتنا في صياغة القصة تبدأ بسؤال "لماذا؟"؛ لماذا ترغب في بناء هذا المنتج، وما أهميته؟ في العادة، لا يشتري الناس منتجك بناءً على مزاياه فحسب؛ بل يشترونه لأنّه يقدِّم حلًا لإحدى المشكلات التي تواجههم ويحقّق لهم قيمة، لذلك من المهم جدًا قبل البدء في أي شيء أن تفكِّر في قصة متكاملة تخبرها للزبائن لكي تجذب انتباههم وتدفعهم إلى الشراء. «لا ينظر الناس إلى ما تفعل، بل ينظرون إلى غايتك ممّا تفعل.» – سيمون سينك على مرِّ عدة عقود كانت البرمجيات تُباع عن طريق تسويق المزايا التي تقدِّمها؛ أي أنّ الشركات كانت تعرض المنتج الذي تريد بيعه ومن ثمّ تُبيٍّن للناس الحاجة التي تدفعهم إلى شرائه. لكنَّ ظهور نموذج البرمجيات كخدمة (SaaS) قد قلب الموازين، إذ أصبح من السهل بناء منتج ما، وهذا يعني أنّ المنافسة السوقية في ازدياد. نتيجةً لذلك، أصبح من الصعب عليك أن تتميّز عن الآخرين معتمدًا على المنتج وحده، ولكي تتمكّن من النجاح فأنت بحاجة إلى أن تعكس عملية التسويق. اسأل نفسك "لماذا" لماذا أنشأت شركتك -بعيدًا عن الأسباب المتعلقة بكسب المال؟ لا يعرف الكثير من الناس الإجابة على هذا السؤال بإيجاز، وهذا يشكِّل عائقًا أمام عملية التسويق. أنت بحاجة إلى أن يكون لديك فكرة شديدة الوضوح عمّا تمثِّله شركتك حتى تتمكّن من إخبار الزبائن بقصة مثيرة للإعجاب بخصوص المنتج الذي تقدِّمه. على سبيل المثال: سبب إنشاء شركة Intercom هو جعل تجربة الشركات التي تتواصل مع زبائنها عبر الإنترنت تجربة خاصّة. تبدأ عملية كتابة القصة منذ اللحظة التي تُقرِّر فيها إنشاء شركة وقبل فترة طويلة من البدء في تصميم أو برمجة أي شيء. تعدُّ هذه القصة بمثابة العرض المختصر الذي تقدِّمه للمستثمرين، أو الطلب الذي ترسله إلى شركة Y Combinator المختصة بتمويل الشركات الناشئة، أو الحكاية التي تخبرها للشخص الذي يجلس بجانبك. أول ما قمتُ به عند انضمامي إلى شركة Intercom هو الجلوس مع مؤسِّسي الشركة ومحاولة فهم رسالتها ورؤيتها المتعلقة بمنتجاتها، وما أقصده بذلك هو: لماذا قاموا بإنشاء شركة Intercom؟ ما المشكلة التي كانوا يحاولون حلّها؟ ما سبب وجود تلك المشكلة؟ إنَّ التسويق لا يرتبط برسالة الشركة فقط؛ بل يرتبط أيضًا بفهم الأسباب التي تدفع الزبائن إلى إيلاء الاهتمام بتلك الرسالة، ومن ثمّ خلق قصة تحثُّهم على البدء في تجربة المنتج والقيام بعملية شراء في نهاية المطاف. اسأل نفسك "كيف" يقول أستاذ التسويق في كلية هارفارد للأعمال ثيودور ليفيت (Theodore Levitt): «ليست غاية الناس شراء آلة ثَقب ذات سُمك ربع بوصة؛ بل غايتهم إحداث ثقب سُمكه ربع بوصة.» موضع اهتمام الناس هو أنفسهم ومشكلاتهم، وليس أنت. القصة الجيّدة هي التي تعزف على الوتر الحسّاس للزبائن، فيكون لها صدىً في نفوسهم، كما تعلق في أذهانهم. يجب أن يكون لديك في البداية تصوُّر واضح عن فئة الزبائن التي تستهدفها، ثمّ انطلاقًا من ذلك تحدِّد المشكلات التي باستطاعتك أن تحلّها لهم. يجب أن تكون هذه المشكلات مشكلاتٍ حقيقية يبحث الزبائن عن حلول لها، وينبغي عليك أن تكون قادرًا على التعبير بوضوح عن عالمٍ يخلو من تلك المشكلات بعد استخدام منتجاتك أو خدماتك المميزة عن غيرها. من الأمثلة المشهورة هو أسلوب التسويق الذي اتخذته شركة أبل عندما أطلقت جهاز iPod في الوقت الذي كانت فيه مُشغِّلات MP3 متوفرة بكثرة، إذ كان الجميع يسوّقون منتجاتهم بناءً على مميزاتها ويصفونها بقولهم: «مشغِّل MP3 ذو سعة تخزين تصل إلى 1 جيجابايت»، ولكن ما من أحدٍ كان يتحدَّث عن كيف سيجعل المنتج حياة الزبائن أفضل. تفوّقت شركة أبل على الجميع وانصبَّ تركيزها على مصلحة الزبائن، فكان شعار منتجها: «1000 أغنية في جيبك». لقد جنّبت أبل الناس الاضطرار إلى التساؤل عمّا يُقصد بكلمة جيجابايت عن طريق تفادي الحديث عن المواصفات التقنية (سعة التخزين). استطاع الزبائن -من خلال شعار iPod- أن يروا بوضوح المزايا التي يقدِّمها هذا المنتج في الوقت الذي كانت تتنافس فيه مشغِّلات MP3 مع مشغِّلات الأقراص المدمجة وكانت إمكانية وجود 1000 أغنية على الجهاز أمرًا جديدًا. اسأل نفسك "ماذا" بعد أن يُصبح لديك قصة تثير اهتمام الزبائن وتوضِّح لهم كيف سيقدِّم منتجك الحل للمشكلة التي تواجههم، ينبغي عليك أن تدعم هذه القصة بتأكيدات قوية تدلُّ على مدى فاعلية منتجك في حل مشكلاتهم حتى تزيد من سرعة اتخاذهم لقرار الشراء. لنأخذ مثال شراء سيارة: قد تتفهّم احتياجك إلى شراء سيارة واسعة وآمنة لعائلتك، ولكن عندما تجد نفسك أمام خياراتٍ متعددة، فقد تختار شراء السيارة ذات المقاعد الجلدية الحرارية أو السيارة التي تقطع مسافة 100 ميل لكل جالون. غالبًا ما تشكِّل هذه المزايا الصورة الكاملة وتزيد من ترابط القصة من خلال أسلوبين مهميْن هما: الإقناع: في نموذج البرمجيات كخدمة (SaaS)، عليك أن تُبرز النتائج الجوهرية التي يمكن تحقيقها باستخدام مزايا المنتج الذي من خلاله ستحل مشكلة معينة. ستحصل على فرصة ممتازة إذا استطعت أن تبيِّن للزبون أنّه سيُشار إليه بالبنان لأنّ منتجك سيوفِّر على شركته $120,000 في السنة وسيساعده على تحقيق نتائج أفضل. لذا، أطلِع الناس على نماذج لزبائن حقّقوا مثل تلك النتائج عن طريق استخدام المنتج الذي تقدِّمه. التميُّز: يمكن للمزايا التي تقدِّمها أن تُميِّزك عن منافسينك في السوق الذي يزدحم بالمنتجات. دعنا نتحدث عن ميزة تقييم المحادثات التي توفِّرها شركة Intercom للشركات التي ترغب في معرفة مقدار رضا زبائنها: ليس أكثر ما يجذب المشترين لمنتج شركة Intercom هو كيفية قياس رضا الزبائن؛ بل كيفية اتخاذ إجراءات معينة بناءً على المعلومات التي يحصلون عليها من خلاله، إذ يمكنهم أن يحدِّدوا رسائلًا جديدة تُبعث للزبائن بناءً على مدى رضاهم، أو أن يقرِّروا التعامل مع الزبائن غير الراضين قبل أي شيء آخر. إنّ المزايا التي تقدِّمها تعزِّز قصتك بطريقة جاذبة للانتباه لا يستطيع المنافسون محاكاتها. المنتَج وعملية التسويق وجهان لعملة واحدة، فمثلًا: من غير المعقول لمن يقدِّم خدمة توصيل البيتزا ويَعِد الناس بالحصول عليها خلال أقل من 30 دقيقة أن يدعهم ينتظرون لمدة ساعة حتى تصلهم، ومن غير المعقول للمصرف الذي يدَّعي اهتمامه بزبائنه أن يترك 20 شخصًا ينتظرون دورهم ولا يوجد سوى صرّافيْن لخدمتهم. إذا لم تكن قصتك تحاكي المنتج الذي تقدِّمه، ستكون المحصِّلة تخييب آمال الزبائن الذين قد اهتموا به في بداية الأمر. حافظ على التناغم بين عملية التسويق والمنتج، وسوف تظفر بمكانة لا يمكن لأحد أن ينتزعها منك. ترجمة -وبتصرف- للمقال Start your marketing with why: Getting your story right لصاحبه Matt Hodges

لا محالةَ من حصول محادثاتٍ صعبةٍ في العمل كما يحصل في حياتنا الشخصية، وفي الحقيقة أنّها يمكن أن تتسبَّب في إزعاجنا، ولكنَّها أيضًا يمكن أن تكون فُرصًا رائعة للتعلم؛ فقد تكون المكاسب من إجراء هذه المحادثات الصعبة أكبر بكثير من التنصُّل منها، كما قد تُمكِّننا من العمل معًا بطريقة أفضل وفهم وجهات النظر المختلفة والتعاطف مع بعضنا بعضًا والتطوُّر الشخصي. رغم أنَّ جميع المحادثات الصعبة تختلف عن بعضها، فهذا لا يعني عدم إمكانية الاستعداد لها؛ وهناك طريقة واضحة مكوَّنة من 5 خطوات (تختصر إلى P.A.R.E.S) تساعد على ترتيب الأفكار والتعامل مع أية محادثة صعبة. نستعرض فيما يلي الخمس خطوات الأساسية لإجادة التعامل مع المحادثات الصعبة: الاستعداد (Prepare) طرح الأسئلة (Ask) التفهُّم (Recognize) إبداء الرأي (Express) التوصُّل للحل (Solve) لنفترض حدوث السيناريو التالي في العمل: أدَّى تعليق أحد الزملاء على أمرٍ ما إلى انزعاجك -وربما إلى انزعاج فريق العمل الذي تعمل معه-. يظنُّ هذا الزميل أنَّ ما قاله مسلٍّ، ولكن -في الواقع- تعليقه غير مناسب البتَّة. من الجلِّي أنَّ التصرف غير اللائق الذي قام به ذلك الموظف قد ينشأ عنه بيئة عمل سلبية، وقد تتساءل عن كيفية مناقشة هذا الموضوع معه. من المهمِّ في مثل هذه المواقف أن نتذكر أنَّه من المرجح عدم وجود نيَّة لدى الشخص بالإساءة إلى غيره أو بجرح مشاعر الآخرين رغم أنَّ تصرُّفاته قد تكون غير ملائمة؛ فجميعنا لدينا وجهات نظر مختلفة ممّا يُصعِّب علينا في بعض الأحيان تصوُّر الطريقة التي قد تُفسَّر بها أحد التعليقات أو الأفعال، والحل هو التريُّث لفهم الأسباب التي دفعت أحدهم إلى القيام بتصرُّفٍ ما، ومساعدته -في الوقت نفسه- على رؤية تأثير تصرُّفه على الآخرين لتفادي حدوثه في المستقبل. دعونا نُطبِّق الخمس خطوات على السيناريو السابق. 1. الاستعداد: هيَّئ الأجواء إنَّ أول خطوة في التعامل مع أية محادثة صعبة هي تجميع الأفكار وإعلام الطرف الآخر بهدوء وبلطافة عن رغبتك في مناقشة ما حدث. في هذه المرحلة يتم التحضير للمحادثة وتهيئة الأجواء المناسبة، إذ سيُقلل الاستعداد الجيِّد من رهبة هذه المحادثات وسيزيد من فاعليتها، كما سيدلُّ على أنَّك قد كرَّستَ وقتًا للتفكير مليِّاً حيال مشاعرك ومشاعر موظفيك. اتِّبع الخطوات التالية لكي تستعد جيِّدًا: حضِّر جملة افتتاحية، وكن مستعدًا للإشارة إلى نقطة الخلاف، وقدِّم مثالًا أو أكثر لتبيِّن التصرف الذي ترغب في تغييره. كن مستعدًا للتعبير عن مشاعرك المتعلقة بنقطة الخلاف وتوضيح الأثر الذي تركته لديك ولدى الفريق. حدِّد مُسبقًا موعدًا لمقابلة فردية، ولا تفاجئ الأشخاص بهذه المحادثات الصعبة على حين غرَّة لأنَّهم سيميلون حينها إلى التصرُّف بطريقةٍ دفاعية. اقترح إجراء هذه المناقشة بنبرةٍ إيجابية؛ فليس هدفنا أن نُشعر الطرف الآخر بأنًّه في مأزق. احرص على إبداء التزامك تجاه تسوية نقطة الخلاف وإيجاد حل مناسب للطرفين. من إحدى الطرق لاقتراح إجراء المحادثة في السيناريو السابق: "من فضلك، هل يمكننا أن نحدِّد موعدًا خلال هذا الأسبوع لكي نتحدث بخصوص الأمر الفلاني الذي قلتَه؟ لقد جعلني أشعر بالانزعاج، وأودُّ أن أوضِّح لك السبب في ذلك، كما أودُّ أن أعرف وجهة نظرك حول هذه المسألة لأنّني حريصٌ على أن يشعر الجميع بالارتياح في عملهم، بما فيهم أنت." 2. طرح الأسئلة: أصغِ كما لو أنَّ الفهم هو وظيفتك الوحيدة مهمتك في هذه المرحلة هي إتاحة المجال للطرف الآخر لكي يُعبِّر عن نفسه، كما عليك التأكُّد من أنَّك بالفعل تفهم وجهة نظره؛ ولتحقيق ذلك، سيتوجَّب عليك الإنصات بإيجابية حتى تستطيع بعدئذٍ طرح الأسئلة المناسبة. اتِّبع الخطوات التالية لتتأكد من أنَّك تصغي جيِّدًا: اشكر الطرف الآخر على منحك بعضًا من وقته، واذكر مجددًا سبب إجراء المحادثة. اسأل الطرف الآخر عن وجهة نظره، وابذل جهدًا لرؤية المسألة من منظوره. ستضطر في هذه الحالة إلى زيادة قدرتك على التعاطف. كن متفتِّح الذهن ومتطِّلعًا لمعرفة آراء الآخرين؛ فكلُّنا مررنا بتجارب حياتية مختلفة، ولذلك لا يفكِّر الجميع بالطريقة نفسها. اطرح أسئلة مفتوحة (لماذا، ماذا، كيف) لضمان سير المناقشة نحو الأمام ولكي لا تبدو المحادثة كأنَّها استجواب. فيما يلي إحدى الطرق لتطبيق الخطوة الثانية على السيناريو السابق: "أشكرك على منحي بعضًا من وقتك للحديث بهذا الشأن، وإنّني أقدِّر هذا حقّــًا. كما أخبرتك، لقد شعرت بالانزعاج حين قلت الأمر الفلاني، وأودُّ أن أفهم السبب الذي دفعك إلى قول ذلك." 3. التفهُّم: اعرف وجهة النظر الأخرى تُظهِرُ في هذه المرحلة أنَّك قد أصغيت بالفعل للطرف الآخر، وليس بالضرورة أن تُبيِّن أنَّك متفقٌ معه. يرغب معظم الأشخاص في أن يكون صوتهم مسموعًا، وتضمن هذه الخطوة أن يدرك الطرف الآخر التزامك تجاه تسوية نقطة الخلاف. اتِّبع الخطوات التالية لتتأكد من تفهُّمك لوجهة نظر الطرف الآخر على النحو الصحيح: افترض حُسن نية الطرف الآخر، ولا تظن أنَّه قد تصرَّف بنية إيذاء أي أحد. تجنَّب وضع افتراضات خاصة بشأن ما حصل لأنَّ ذلك غالبًا ما يؤدي إلى حدوث سوء تفاهم. أظهِر أنَّك تُنصت بإيجابية من خلال التحقق من مشاعر الطرف الآخر وإعادة صياغة حججهم؛ فهذا يساعد على تفادي حدوث أي سوء تفاهم. كن واعيًا بذاتك، وكن على معرفة بما قمت به في ذلك الموقف، واسأل نفسك عمَّا إذا كنت قد تصرَّفت بطريقة مماثلة في الماضي، إذ من الجيِّد دائمًا أن نراقب سلوكنا الشخصي. تذكَّر أنَّ التفهُّم لا يعني القبول، إذ يمكنك أن تتفهَّم وجهة نظر مختلفة دون أن تتفق معها. إذا أساء الطرف الآخر فهم إعادة صياغتك لوجهة نظره، بيِّن له بوضوح أنَّك -في هذه المرحلة- تحاول فقط أن تفهم الطريقة التي خاض بها ذلك الموقف. فيما يلي مثالًا يوضِّح الطريقة الملائمة لتفهُّم وجهة نظر الآخرين دون القبول بها: "أشكرك على منحي بعضًا من وقتك لإطلاعي على وجهة نظرك وتفسيرها لي. هذا ما فهمته بخصوص ما كنتَ تشعر به في ذلك الموقف: (كرِّر ما قاله الطرف الآخر لتبيِّن أنَّك أصغيت لحديثه). أليس هذا صحيحًا؟" ملاحظة: إن كانت تعليقات الطرف الآخر مؤذية أو لم تكن فُكاهية -كما يدَّعي- فليس عليك القبول بها، إذ يمكنك التعبير عن التفهُّم دون إبداء القبول، ولكنّك إذا لم تعطِ الطرف الآخر الملاحظات التي هو بحاجةٍ لها -حتى لو كانت قاسية- فلن يكون ذلك في مصلحته على المدى الطويل. 4. إبداء الرأي: وضِّح وجهة نظرك تضمن هذه الخطوة أن يكون صوتك مسموعًا أيضًا، إذ عليك أن تبِّين تصوّرك عمّا حدث بوضوح ودون تبريرات. قد يبدو الأمر قاسيًا، ولكنَّ «التعاطف المدمر» كما يُسمِّيه كيم سكوت (Kim Scott) لن يساعد الطرف الآخر على النمو والتطوُّر، وما عليك فعله بصفتك مديرًا هو تعلُّم «الصراحة الجذرية» التي يمكنك من خلالها إظهار الاهتمام على المستوى الشخصي مع إبداء الاعتراض بطريقة مباشرة في الوقت نفسه. وضِّح الموقف من وجهة نظرك، ولكن لا تحتقر الطريقة التي ينظر بها الآخرون للأمور. اشرح القصة من منظورك دون أن تتَّهم الطرف الآخر بفهمه الخطأ للموقف. كن جازمًا فيما يتعلق بالأمور التي تهمّك، ولا تقبل برأي الطرف الآخر لمجرد رغبتك في إنهاء المحادثة؛ فبصفتك قائدًا، يقع على عاتقك وقاية بقية أعضاء الفريق من المرور بمثل هذا الموقف مرةً أخرى. لا تُخفِ مشاعرك بسبب خوفك من الظهور بمظهر الضعيف؛ فلن تُحلَّ المسألة إذا فعلت ذلك، كما أنَّك لو عبَّرت عن مشاعرك، قد تُلهم الآخرين لفعل الشيء نفسه ممّا يؤدي إلى محادثة يسودها الصدق والصراحة. ادمج وجهة نظر الآخرين ودوافعهم (ولكن بالمقدار الذي تتفق معها فقط) مع تفسيراتك، إذ يمكنك من خلال هذه الصورة الكاملة تحديد ما إذا كان هناك أي سوء فهم. يمكن توضيح وجهة النظر المتعلقة بالسيناريو السابق كالآتي: "أفهمُ أنَّك كنت تقصد أن تقول كذا، وهو أمرٌ معقول. لكنَّ ما قلتَه لم يكن ملائمًا لأنَّه لا يتماشى مع قيم الشركة، ويجعلني أشعرُ أنَّك لا تفكر بأنّنا جميعًا فريقٌ واحد." 5. التوصُّل للحل: حان وقت حل المسألة! إنهاء المحادثة الصعبة دون وضع خطة للعمل يُشبه إعداد قطع البسكويت دون وضعها في الفرن! تسعى أنت خلال هذه المرحلة مع الطرف الآخر لإيجاد حلٍّ دائمٍ طويل الأمد قائم على أساس التفاهم والثقة. إنَّ وجود خطة واضحة للعمل يضمن الخضوع للمساءلة، ويمثِّل مرجعًا يمكن الرجوع إليه إذا تكرّر ما حدث مرةً أخرى. عُد لخطوة طرح الأسئلة إذا كانت لا تزال هناك بعض النقاط غير الواضحة لأيٍّ من الطرفين؛ فالمحادثات الصعبة نادرًا ما تسير في خطٍ مستقيم، وعليك ألّا تتعجل في الوصول إلى الحل حتى تتأكد من استعراض ومناقشة وجهتي النظر كلتيهما. اسأل الطرف الآخر عن الحل الذي يظنّه مناسبًا، ثمَّ قوما بإجراء العصف الذهني معًا؛ فهذا سيسهِّل التوصُّل إلى حلٍ مناسب، ويضع الطرفين في موضع المسؤولية. كن متفاعلًا وإيجابيًا من خلال الاعتماد على ما لدى الآخرين من أفكار (بمقدار ما هي مفيدة). اشكر الطرف الآخر على ما خصّصه من وقتٍ وعلى صراحته، ثمّ احرص على وضع خطوات واضحة، إذ من المهم وضع خطة للعمل من أجل إحداث التغييرات المنشودة. بالرجوع إلى السيناريو السابق، هذه بعض النقاط الأساسية التي يمكن من خلالها تطبيق الخطوة الأخيرة: "للمضيّ قدمًا، كيف يمكننا جميعًا تجنُّب تكرار مثل هذا الموقف؟" "أقترح أن نجد طريقةً لمشاركة هذا الالتزام مع بقية أعضاء الفريق قبل نهاية الأسبوع." "أشكرك مجددًا على استعدادك لتقبُّل الآراء الجديدة والمساهمة في تحسين بيئة عملنا." المحادثات الصعبة شأنّها شأن أي شيءٍ في الحياة، إذ كلّما تعاملنا معها بإيجابية وكان هدفنا إيجاد الحلول، أصبحنا متمرِّسين فيها وقلّ شعورنا بصعوبتها. إضافةً إلى ذلك، سيساهم التعامل مع هذه المحادثات في خلق بيئة عملٍ أكثر صحَّةً وانفتاحًا. حان دورك الآن لمشاركة تجربتك؛ أخبرنا في التعليقات عن أصعب المحادثات التي أجريتَها في العمل والخطوات التي طبقّتها للتعامل معها. ترجمة -وبتصرف- للمقال A 5-Step Framework for Mastering Difficult Conversations at Work لصاحبه فريق Juniper حقوق الصور التوضيحية محفوظة لمصمّمها Simon Lavallée-Fortier

لم أُصدّق ما كانت تسمعه أُذناي خلال مكالمة هاتفية مع أحد العملاء. اكتشفتْ العميلة أنّه إذا قامت بتقليص حجم متصّفح سطح المكتب إلى حجم الهاتف المحمول، وأظهرت نموذج الهاتف المحمول وأخفته، ومن ثم قامت بتكبير المتصفح إلى حجم سطح المكتب، فإنّ نموذج سطح المكتب الذي كان مرئيًا سابقًا سيختفي. سألتُها: “هل نتوقع أنّ كثير من الناس يفعلون ذلك؟”. أجابت قائلة: “حسنًا، لا يمكن أن تجزم أبدًا”. قمتُ بكتم الهاتف وتنهدّتُ بعمق. الحقيقة هي أنّ العميلة كانت قلقة بشأن مشكلتها واحتاجت إلى إصلاحها. كنتُ أعلم ذلك، لكنّني لم أفهم السبب. اللاعقلانية هي إحدى الشكاوى الأكثر شيوعًا للمصمّمين والمطوّرين الذين يتعاملون مع العملاء. فهم غالبًا ما يردّدون “العملاء لا يفهمون ذلك”. وأنا، بل وجميع من يتعامل مع العملاء لا بدّ من أنّه مرّ بمثل هذه المواقف. لكنّ زملائنا في العمل ليسوا أفضل بكثير. لدينا مثلًا مدير المشروع ذاك الذي يعتقد أن الحلّ الوحيد للمشروع المتأخر عن موعده النهائي هو المزيد من اجتماعات الحالة. ولدينا مدير خدمة العملاء الذي يعتقد بوجوب توضيح جميع التفاصيل، حتّى التافهة منها، وتأكيدها إلى درجة الإفراط. كما لدينا ذلك المشرف الذي يشعر بالحاجة إلى مراقبتك الدقيقة في كلّ حركة تتخذها. ما الأمر مع هؤلاء الناس؟ ألم يُصبح الأمر مفهومًا الآن؟ أليست اللاعقلانية هي الأسوأ؟ مشكلة القلق بعد بضعة أسابيع من المحادثة التي ذكرتها أعلاه، وردتني مكالمة أخرى من العميلة نفسها، ولكن في هذه المرّة كان مديرها أيضًا على الخط. لقد كانت محادثة مختلفة كثيرًا، فقد قام مدير العميلة بتوبيخنا جميعًا، بما فينا العميلة نفسها، ولمدة ساعة كاملة. تبيّن أنّ العميلة تجاوزت أهداف الميزانية للربعين الأخيرين، ووقعت الملامة مباشرةً على فريق التسويق، سواءً كان مستحقًّا أم لا. لقد كانت عميلتنا تتعرّض لضغط هائل، لذا حتّى الإخفاق الضئيل، إذا لاحظت، يمكن أن يؤدي إلى نتائج كارثية. أدركتُ لاحقًا أنّ المشكلة لم تكن في اللاعقلانية، ففي الواقع نادرًا ما تكون كذلك. كانت المشكلة في هذا الموقف هي القلق. هل أنت جاهز لبعض العمليات الرياضية التي سنُجريها على عواطفنا؟ إليك الصيغة: نعم، صحيح؛ عندما يتولّد القلق بسبب اقتراب ميعاد نهائي، فسيتفاقم ويؤدي إلى الاضطراب. وعندما يكتنف المشروع الاضطراب، سيشعر الجميع به. كثيرًا ما أسمع الناس يقولون: “أنا لا أضطرب”. وهذا يعني أساسًا أنّهم لا يتعاملون مع المشاكل العاطفية للناس المحيطين بهم. والمفارقة هي أنّ فعلهم هذا سيؤدي إلى إحاطتهم بالاضطراب في كلّ مكان يذهبون إليه. هل سمعتَ مطورًا يقول: “أنا لا أصلح الأخطاء البرمجية”، أو مصممًا يقول: “أنا لا أعدّل التصاميم”. وبالمثل، إذا كنت تعمل مع الناس، فإنّها وظيفتك كمحترف ويب أن تتولّى أمر الاضطراب في مكان العمل. يعني تولّي الاضطراب تعلّم كيفية تمييز جذور القلق والتعامل معها. يتولّد القلق من مناطق مختلفة، لكنّه يتوسّط عددًا من المشاكل في مكان العمل، وفهمه هو المفتاح لإخماد الكثير من تلك المشاكل. القوة والمسؤولية سنطبّق المزيد من الرياضيات على عواطفنا، والصيغة التالية هي صيغة القلق: كلّما زاد الضغط الذي يتعرّض له أحدهم، زادت المسؤولية. وبالتالي نرى أنّ عميلتنا (بالإضافة إلى فِرق خدمة العملاء ومدراء المشاريع) تفتقر إلى السلطة اللازمة لإصلاح المشكلات، وهذا هو التكوين التقليدي للقلق. كحلّالين للمشاكل، قد يكون هذا المفهوم غير مألوف لدينا في مكان العمل. ففي النهاية نحن أناس يلجأ الآخرون إليهم لحلّ مشاكلهم، لكنّنا نادرًا ما نلجأ إليهم لحلّ مشاكلنا. هل تتذكّر الزملاء اللاعقلانيين الذين ذكرتهم أعلاه؟ لقد عانوا من القلق في مكان العمل بسبب المسؤولية التي تنقصها السلطة. لقد حُمّلوا مسؤوليةَ أمرٍ لم تكن لديهم السلطة للقيام به مباشرة. قد لا يُصرّحون بذلك أو حتّى لا يدركونه. لكن القلق هو روتين الأشخاص الذين تعمل لديهم. يعاني العملاء أيضًا من هذا القلق. ففي الواقع، مجرّد لجوء العميل إليك يعني أنّه أدرك أنّه ليس باستطاعته حلّ مشكلته الخاصّة، بالرغم من كونه مسؤولًا عن النتيجة. نستنتج من ذلك أن كل علاقة مع عميل ما تكون مبنية على أساسٍ من القلق. إذا تولّد القلق عن تحمّل مسؤولية شيء دون امتلاك السلطة لإصلاحه، بإمكاننا تخفيفه إما من خلال تحمّل بعض المسؤولية، أو بالتخلي عن بعض السلطة لإصلاحه. “ليست مشكلتي” هي مشكلة في مرحلة مبكرة من عملي في الشركة الحالية، لاحظتُ بعض التوتّر بين فريقي التطوير والإبداع على استخدام العناصر الإبداعية المضمّنة مسبقًا في إطار عمل الواجهات الأمامية front-end framework المفضّل لدينا. كان المصمّمون يصمّمون العناصر من الصفر، مما يعني إهدار العديد من الوحدات المضمّنة في إطار عمل الواجهات الأمامية. يعني هذا أن على فريق التطوير قضاء وقتٍ إضافي لبناء هذه العناصر المخصّصة، وهذا ليس في صالح فريق التطوير ولا العميل. كان المطوّرون يشكُون من هذا الأمر، ولم تكن لدى المصمّمين أدنى فكرة عمّا يحدث. عوضًا عن التذمّر أكثر، قمتُ بإنشاء عرضٍ تقديمي متعمّق يشرح لقسم الإبداع القدرات الإبداعية لإطار عمل الواجهات الأمامية الخاص بنا. عندما عرضتُه على مديري، قال: “هذا ما كنّا نحتاجه بالضبط”. كانت المشكلة تتفاقم إلى أن تولّيتُ أمرها بنفسي. عندما يشكو الناس من شيء ما فإنّهم يعترفون بأنّه ينبغي القيام بشيء ما، لكنّهم يرفضون تحمّل مسؤوليته بأنفسهم. وهم بعبارة أخرى يقولون: “أنّها ليست مشكلتي”، مع أنّ ذلك لا ينمّ دائمًا عن الإهمال بالضرورة. في إحدى التجارب وضِعَ المشاركون في غرف منفصلة مع مكبّرات صوت، وجُعِلوا يتناوبون الحديث عن المشاكل التي كانت تواجههم وما الذي كانوا يفعلونه لحلّها. تم ربط المشارك الأول مع 1 - 5 أشخاص آخرين، وكان على أحد المشاركين أن يبدأ بنوبة صرع خلال التجربة. الحيلة كانت أنّه كان هناك مشتركًا واحدًا حقيقيًا، بينما كانت بقية الأصوات، سواء واحدًا أو أكثر، عبارة عن تسجيلات، من ضمنها الشخص الذي يُصاب بالنوبة. هل تريد تخمين كم كان عدد المشاركين الحقيقين الذين لجأوا إلى المُختبرين لطلب المساعدة؟ كم بتقديرك 100%؟ 75%؟ هل تصدّق أن 31% فقط من المشاركين ذهبوا لطلب المساعدة للمشارك الآخر (الوهمي) الذي كان يواجه مصيبة؟ والأدهى أنّه كلمّا زاد عدد المشاركين الآخرين الذين يعتقد المشاركون الحقيقيون بوجودهم، قلّت احتمالية مبادرتهم إلى فعل شيء ما. لماذا حدث ذلك؟ درس الباحثون سلوك الحشود المحيطة بالحالات الطارئة. إذا حلّت بك طارئة في مكان عام وطلبت من الحشود المساعدة، ربّما لن تحصل عليها بسبب ما يُعرف بتأثير المارّة أو تأثير المتفرّج . وقد تبيّن أنّه كلّما زاد عدد الغرباء الحاضرين في الموقف الطارئ، قلت احتمالية مبادرة أحدهم للمساعدة وللعديد من الأسباب (من ضمنها الاعتقاد بإنّ أحدهم أكثر تأهيلًا سيتدخّل، والقلق حول عواقب التدخّل). وطريقة الحصول على المساعدة في الحالات الطارئة بوجود العديد من الناس هي أن تختار أحد الأفراد المتفرّجين وتطلب منه القيام بشيء محدد، كاستدعاء سيارة الإسعاف أو المساعدة بالإسعافات الأولية. إنّ عدم اكتراث المتفرّجين أمر حقيقي، وفهمه يمكن أن يساعدك في التعامل مع الحالات الطارئة، والمصائب الكبيرة، وحتّى مواقف العمل. ربّما لا يعرف الأشخاص المتذمرون على من تقع مسؤولية إصلاح المشكلة، هم يعرفون فقط أنّها ليست مسؤوليتهم. وهنا تسنح لك الفرصة لتصبح فردًا مفيدًا بدلًا من متفرّج غير مكترث. ابحث عن الاحتياجات التي غُفِل عنها والمشاريع التي تُركت مشاكلها لتتفاقم لفترة طويلة، وحاول أن تتولّاها بنفسك. لكن احذر، فهناك حدٌّ رفيع جدًّا بين المبادرة، وبين التجاوز على مسؤوليات الآخرين. إذا كنت ستُبادر، والمشكلة التي ستهتم بها تقع تحت المسؤولية المباشرة لأحد ما، يجب أن تحصل على موافقته أولًا، وخصوصًا إذا كان الشخص المعني أعلى منك منصبًا. وإذا كانت المبادرة ستضرّ بأحدهم، فهذه إشارة واضحة إلى أنّه يجب أن تركّز جهودك في مكان آخر. ولكي تُحسِن في مبادرتك، تحمّل مسؤولية المنتج النهائي، وليس الجزء الخاص بك فقط. أنا أعمل في فريق التطوير، لكنّني معروف بتقديم التغذية الراجعة feedback الإبداعية في الموضع المناسب، بالإضافة إلى المساعدة في التفكير في أي جانب من جوانب مشروع العميل. أصبحتُ الآن أُدعى إلى الاجتماعات ليس لمشاركة خبرتي في التطوير فحسب، بل لمساعدة الفِرق الأخرى في دراسة مشاكلهم. لا ينبغي لك أن تتجاوز حدودك، ولكن يحسُن بك الاهتمام بالمنتج النهائي ومعرفة كيفية إنجاز كل خطوة، وهذا ببساطة ما يتمحور حوله تقاسم المسؤولية. السُلطة مُلكُك عندما يمرُّ طفلي بمواقف يفقد فيها السيطرة والسلطة، يتولّد لديه القلق ويشعر بالذعر. وأسرع طريقة لحلّ تلك المشكلة هي أن أعطيه بعض الخيارات لفعلها ضمن حدود موقفه: هل ترغب في الذهاب لتناول الغداء هنا أم هناك؟ هل تريد ارتداء القميص الأحمر أم الأخضر؟ أيّة عقوبة تريد؟ الكِبار أكثر تطورًا قليلًا في هذا الأمر، لكنّنا لا نكبر أبدًا على حاجة الإنسان الأساسية لفرض السيطرة على مواقفنا. فبقدرِ معيّن من السيطرة يمكننا أن نحافظ على هدوئنا ورباطة جأشنا، بينما نصبح قلقين ولاعقلانيين عندما تقلّ سيطرتنا. أضف إلى ذلك أنّ الناس عندما يفقدون السلطة في مجال معيّن من حياتهم، فإنّهم يقومون بتعويضها عن طريق الاستحواذ على السلطة من مجالات أخرى. وإذا ما شعر أحدهم بأنّ الموقف يفلت من متناول يديه، غالبًا ما سيبذل جهدًا أكبر لممارسة السلطة على المناطق التي يشعر بأنه ما زال يتمتع ببعض السيطرة عليها. كان أولئك الزملاء اللاعقلانيين الذين ذكرتهم في بداية المقال يتصرّفون جميعًا على ذلك النحو لتعويض فقدان السيطرة على عمل المشروع نفسه. وبالمثل، كان اهتمام العميلة الشديد بتطوير الموقع كرد فعل لأنّهم لم يكونوا قادرين على إبقاء الميزانية ضمن الحدود المتوقعة. يمكن لفقدان السلطة أن يتخذ الكثير من الأشكال المختلفة. فعدم معرفة النتيجة المطلوبة منك يمكن أن يجعل القوة بلا معنى. كما في حالة العميلة المذكورة في بداية المقال. فلأنّها لم تكن متأكّدة من كيفية تأثير الخطأ البرمجي الثانوي على نتيجة الموقع، لم يكن باستطاعتها قياس مستوى الخطر من ترك الخطأ دون إصلاحه. عدم امتلاك المعلومات الصحيحة هو سيناريو آخر لفقدان السلطة. وهذا ما يعلّل لجوء العملاء إلينا في المقام الأول. وبالطبع لدينا فقدان السلطة الكامل قديم الطراز الذي يحدث نتيجة للافتقار إلى المهارات المطلوبة لحلّ المشكلة. أنت، كحالّ للمشاكل، تتمتّع بالكثير من السلطة التي يعتمد عليها الأشخاص الآخرين لحلّ مشاكلهم. ومشاركة سلطة صنع القرار هذه هي طريقة مؤكّدة لتهدئة الناس المعنيين في مشروع معيّن. نحن نتّخذ عددًا لا يُحصى من القرارات عند حل المشكلة: كيف نحلّها؟ ما مقدار شمولية الحلّ؟ كيف ندمج الحل مع المنتج الحالي؟ وأحيانًا، هل نحلّ المشكلة أساسًا؟ يعني إعطاء السلطة مشاركة الآخرين بصنع القرار. فعادةً ما يقدّر الناس المسؤولين عن النتيجة كونهم جزءًا من عملية الحلّ. عندما قمتُ بإدارة فريق من المصمّمين والمطورين، كنتُ كثيرًا ما أواجه هذا النوع من السيناريوهات: أحد موظفي خدمة العملاء يأتي إليّ مذعورًا ويطلب مني تعديلًا طارئًا على موقع ما بناءً على التغذية الراجعة للعميل. في هذه الحالة لم تُعهد إليّ مشكلة، وإنّما تم إعطائي الحل. وقد استطعنا الوصول إلى المشكلة بقليل من الهندسة العكسية، مما سهّل علينا معرفة ما كان العميل يحاول القيام به. كان في متناولنا حلّ أفضل في هذه الحالة. قمتُ بتوضيح الخيارات لموظف خدمة العملاء ذاك، وإيجابيات وسلبيات كل خيار، ثم اتفقنا على الحلّ الذي اقترحته. بعد ذلك قمتُ بطباعة بريد إلكتروني لمساعدة موظف خدمة العملاء في شرح الحلّ للعميل. وفي النهاية كان الكلّ سعيدًا لأنّني قضيتُ بعض الوقت لمشاركة بعضٍ من سلطتي في صنع القرار مع فريق خدمة العملاء والعميل. بالنسبة لمهندس في فريق تطوير الواجهات الأمامية، غالبًا ما يعني تقاسم سلطة صنع القرار شرح الخيارات من حيث الوقت والميزانية. اللغة مختلفة، لكنّ المبدأ واحد؛ وهو تثقيف الأطراف المعنيّة الأساسية وتمكينها. وسوف تتفاجأ بمدى سرعة رفض بعض التعديلات التي تبدو غير عقلانية بعد مناقشة الخيارات، والكُلف أيضًا. الوصول إلى قلب المشكلة تكمن أسباب القلق عميقًا في طبيعة البشر، لكنّ معرفة كيفية تهدئته يمكن أن يساعد بدرجة كبيرة في تجنّب اضطراب مكان العمل. تذكّر: اللاعقلانية ليست المشكلة. فالناس معقّدون أكثر بكثير مما نحكم عليهم، ومشاكلهم أكثر أيضًا. لذا فالتعامل معهم معقّد، ولكنه أمر بالغ الأهمية للمضي قدمًا في مكان العمل. ترجمة-وبتصرّف-للمقال Defeating Workplace Drama with Emotional Intelligence لصاحبه: Brandon Gregory حقوق الصورة البارزة محفوظة لـ Freepik