اذهب إلى المحتوى

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

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

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

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

نوع المحتوى


التصنيفات

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

التصنيفات

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

التصنيفات

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

التصنيفات

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

التصنيفات

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

التصنيفات

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

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
    • بريستاشوب
    • أوبن كارت
    • دروبال
  • الترجمة بمساعدة الحاسوب
    • omegaT
    • memoQ
    • Trados
    • Memsource
  • برامج تخطيط موارد المؤسسات ERP
    • تطبيقات أودو odoo
  • أنظمة تشغيل الحواسيب والهواتف
    • ويندوز
    • لينكس
  • مقالات عامة

التصنيفات

  • آخر التحديثات

أسئلة وأجوبة

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

التصنيفات

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

ابحث في

ابحث عن


تاريخ الإنشاء

  • بداية

    نهاية


آخر تحديث

  • بداية

    نهاية


رشح النتائج حسب

تاريخ الانضمام

  • بداية

    نهاية


المجموعة


النبذة الشخصية

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

  1. إذا كنت مهتما بتعلم البرمجة، فعلى الأرجح أنك رأيت هذا الاقتباس من قبل: في الحقيقة لا أبالغ إن قلت أن البرمجة أصبحت من أهم المهارات في عصرنا الحالي، وذلك لأنها دخلت في جميع مجالات حياتنا سواءً كنا ندرك ذلك أم لا فانطلاقًا من الهواتف المحمولة ومرورًا بالمنازل والشاشات الذكية وانتهاءً بالسيارات ذاتية القيادة. كل شيء من حولنا لم نكن لنراه بهذا الشكل لولا البرمجة، فأنا على سبيل المثال أكتب وأعدل هذا الموضوع من خلال برنامج بُرمج عبر لغة برمجة وأنت تقرأه على الإنترنت باستخدام برنامج (المتصفح) وربما رأيته على مواقع التواصل الاجتماعي وكُلها برامج أيضًا. ومما لا شك فيه أن تعلم البرمجة أصبح ضرورة مُلحة في هذا العصر بل إن تعلمك لها سيزيد من فرصك بشكل كبير في الحصول على عمل. ولقد تحدثنا في مقالٍ سابق عن كيفية تعلم البرمجة والدخول إلى هذا المجال من أوسع أبوابه (إن كنت حديث عهدٍ في البرمجة أو تخطط للبدء بها، فننصحك بقراءته قبل إكمال هذا المقال) وسوف نتحدث في هذا المقال عن أكثر المهارات صعوبةً في احتراف البرمجة ألا وهي «حل المشاكل». حل المشكلات وارتباطها بالبرمجة لطالما وقفنا حائرين أمام مشكلةٍ ما ونسأل أنفسنا ماهي الطريقة الصحيحة للخروج من هذا المأزق؟ هل ستكون طريقة الحلّ التي أتبعها مشابهة للطريقة التي يتبعها المبرمجين المحترفين؟ كيف أستطيع أن أفكر مثلما يفكر المبرمجين المحترفين؟ في البداية وقبل الخوض في التفاصيل دعنا نُعرف البرمجة بحد ذاتها ولنذهب للمقال السابق ونلقي نظرة سريعة عليها: نلاحظ أن التعريف السابق صحيح ولكنه مُقْتضَب ولا يقدم لنا المعنى الكامل والدقيق للبرمجة لذا لابدّ لنا من تعريفٍ أكثر دقة وموضوعية يساعدنا في فهم هذا المقال. يعرف موقع 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 تعلم لغة بايثون
  2. القسم الأول: أهلًا بالمدير الجديد! قبل أن نبدأ إليك لمحة عمّا سنتحدّث عنه. بدأت للتو أحد أهم الأدوار في قطاع القوى العاملة، وتملك الآن أهم تأثير مباشر على الموظّفين، أساس كل مؤسسة. وسيتأثر نجاحهم وتطوّرهم بقيادتك، ولا شك أنّ ذلك قد يشكّل ضغطًا كبيرًا عليك. نميل في معظم الأحيان إلى التحدث عمّا يحتاجه الموظّفون من مدرائهم ليتألقّوا، وليس ما يحتاجه المدراء لمساعدتهم على تحقيق ذلك. لذلك أعددنا هذا الدليل الشامل للمدراء الجدد مثلك. لتتعلّم كيفية التحضير لدورك كبطل ولتكون القائد الذي حلمت دائمًا أن تكون مثله. أمامك فرصة مذهلة والكثير لتفعله، لكن كل ما عليك فعله الآن هو الاسترخاء وقراءة هذا الدليل. نظرة سريعة على القوى العاملة اليوم أثناء تحضيرك للدخول إلى قطاع القوى العاملة من منظور جديد، نود أن نطلعك قليلًا على وضعها الحالي. رغم تزايد عدد الشركات التي تبذل المزيد من الجهود لتحسين بيئة مكان العمل، كشفت شركة الاستشارات الإدارية والبحوث الإحصائية Gallup أنّ فقط 33% من الموظفين مندمجين في عملهم ومتحمسين لأداءه، مما يعني أنّ 67% من الموظفين غير مندمجين بحياتهم العملية اليومية. وفقًا لـ Gallup، فإنّ إدماج الموظفين خلال ال 16 سنة الماضية زاد بنسبة 7% فقط. وهي مشكلة كبيرة، لكن الخبر الجيد هو أنّ هناك طريقة لإصلاحها. ويبدأ ذلك بك. كما قالت ليندا هيل في كتابها Becoming The Boss: "يوجد عدد كبير من الكتب التي تتحدّث عن القادة الفعّالين والناجحين، لكن يشير عدد قليل منها إلى التحديّات التي تعيق تعلّم كيفية القيادة، خاصة بالنسبة للمدراء الجدد". لدينا نظرية ثؤثّر القيادة بشكل مباشر على مدى شعور الإندماج والإلتزام الذي يمتلكه الموظّف اتجّاه مؤسسته، سواء إيجابيًا أو سلبيًا. وفي الواقع يستقيل 75% من الموظفين بسبب مدرائهم. إذًا لماذا لا يولى اهتمام كافي بهذه الفترة الحرجة التي يبني فيها المدراء أساس مهاراتهم القياديّة؟ نؤمن بأنّ نقص الاهتمام بإعداد الموظفين لدورهم الجديد كمدير هو أحد أسباب ارتفاع مستويات المشاركة والاندماج بهذه الوتيرة البطيئة للغاية. الجانب الإيجابي من ذلك، هو أنّنا نعتقد أنّه إن قامت المؤسسات بتوفير الأدوات والدعم والموارد التي يحتاجها الموظفون للانتقال، فإنّنا يمكننا تغيير هذه النتائج. ويجب أن يبدأ التدريب على القيادة قبل البدء بالدور حتى. كيف أصبحت مديرًا؟ يوجد أكثر من طريقة لتصبح مديرًا، سواء تمت ترقيتك داخل شركتك أو عُيّنت مديرًا جديدًا في شركة جديدة، الأساس المشترك هو انّك في الحالتين في دقيقة كنت موظفًا عاديًا وفي الدقيقة التالية أصبحت مديرًا مع مجموعة من المسؤوليات والتحديات المختلفة تمامًا. فلنتعرّف معًا على شخص ما يدعي مريم، وهي كذلك مديرة جديدة مثلك تمامًا. كانت مريم مؤخّرًا الموظف النجم ضمن فريق التسويق في شركتها، وخلال السنتين الماضيتين أظهرت مجموعة قوية من المهارات والخبرة في مجالها ميّزتها عن باقي زملائها. خلال المراجعة السنويّة الثانية لمريم تمت ترقيتها لتصبح مديرة قسم التسويق في شركتها، ولسعادتها بالدور وبزيادة الأجر المصاحبة له قبلت به، وتستعد حاليًا للبدء بدورها الجديد. لماذا تمت ترقية مريم؟ يثق أصحاب الشركة بقدرة مريم على النجاح كمديرة لأنّها كانت موظّفة متميّزة. يبدو بعد سنتين من العمل الاستثنائي، أن الخطوة المنطقية التالية هي ترقيتها إلى مديرة. لكن يوجد خلل في ذلك يمكنك أن تصبح قائدًا عظيمًا فقط في حال بذلت جهدك لتحقيق ذلك: اسأل جميع الأسئلة التي تحتاجها فيما يتعلّق بطبيعة ومتطلّبات دورك. طوّر مهاراتك الاجتماعية وذكائك العاطفي. تأكد من أنّ هذه أفضل ترقية مناسبة لك. تأكد من أنّك ترغب بأن تقود فريقًا. المشكلة في الترقية الإدارة هي بحد ذاتها مهنة، وتتطلّب التحضير والتدريب والوقت لتُؤدّى بشكل صحيح. لمجرّد أنّ مريم كانت خبيرة في مجالها، هذا لا يعني أنها جاهزة لتصبح مديرة. يتطلّب أن تكون قائدًا مجموعة فريدة من المهارات، ولا يصلح ذلك للجميع خاصة لمن لا يملك الإرادة لتعلّم كيفية القيادة. مع ذلك وبسهولة عُرضت على مريم الترقيّة، مع زيادة في الراتب ومكتب وفريق. لكنّها أدركت بسرعة أنّها لا تعلم بشكل مؤكد ما الذي سيحدث لاحقًا. لديها فريق كامل يعتمد عليها لكن دون أي دليل عمّا يجب عليها فعله! مع خجلها من أن تطلب مساعدة أو توضيح، أصبحت مريم عالقة في حفرة. "هل تعلم كم من الصعب أن تكون أنت المدير عندما تكون خارجًا عن نطاق السيطرة! من الصعب التعبير عن ذلك. هو شعور مفاجئ… يشبه شعورك عندما يصبح لديك طفل. في يوم ما ليس لديك أي طفل، وفجأة في اليوم التالي أصبحت أمًّا أو أبًا، وعليك فجأة معرفة كيفية القيام بكل ما يتعلق بتربية هذا الطفل". مريم هي ليست الشخص الوحيد الذي يراوده هذا الشعور، وكذلك أنت. في استطلاعٍ قمنا بإجراءه وجدنا أنّ 53% من المدراء قالوا بأنّهم لم يراودهم الشعور بأنّ لديهم رؤية دقيقة عمّا يعنيه أن يكونوا مدراءً عندما بدأوا دورهم. لكن ليس على الأمر أن يكون بهذه الطريقة. سنقدّم إليك كل ما تحتاجه لتحضّر نفسك للنجاح منذ البداية. القسم الثاني: التحضير الآن بما أنّنا غطّينا الأساسيات، فلنبدأ بالتعّمق أكثر. 1. ما الذي يقوم به المدير؟ وفق معجم أوكسفورد المدير هو "شخص مسؤول عن التحكم أو إدارة مؤسسة أو مجموعة من الموظفين". لنكن صريحين، هذا التعريف لا يقدّم توضيحًا كافيًا. أن تكون مديرًا هو أمر معقّد، ومنصب يعتمد على العلاقات، وأيّ دور مرتبط بالطبيعة الإنسانيّة لا يمكن أن يتم اختصاره إلى تعريف واحد بسيط. الأمر الثابت على جميع الأصعدة هو أنّ دور المدير بشكل أساسي هو دعم وقيادة الأشخاص ليكونوا أفضل ما يمكن. لا يتعلّق الأمر بالسلطة أو التحكّم أو القوة، في الواقع إذا كنت في هذا المنصب من أجل المجد أو اللقب فإنّك لن تنجح في ذلك. "أن تكون مديرًا يعني أن تُخرج أفضل ما في الأشخاص، وهذا هو الأساس. هو دور غير أناني، ويضع الأشخاص أولًا ويحرّكه القلب، وهو يستحق كل ثانية من هذا التعقيد إذا كنت فيه من أجل الأسباب الصحيحة". لكلّ شركة توقّعات مختلفة، ولكلّ فريق مجموعة مختلفة من التحديّات، لكنّنا سنزوّدك ببعض من مسؤوليات المدير الرئيسيّة. "وفقًا لدراستنا، لم يتلقّ 40% من المدراء قائمة واضحة بالمسؤوليات عندما بدأوا". مسؤوليات المدير الرئيسيّة: تطوير ودعم وإرشاد وتشجيع ومكافأة الموظفين. التخطيط المستقبلي وتقييم المشاريع والمهام. تحديد الأدوار والمسؤوليات بوضوح (بالمشاركة مع الموظفين). وضع الأهداف ومعايير الأداء. خلق بيئة عمل صحيّة من خلال تطبيق وصيانة أنظمة وسياسات العمل. التشبيك والعمل كحلقة وصل بين الموظفين والإدارة العليا. 2. الانتقال بسلاسة من موظف إلى مدير أهم ما عليك فهمه عن دورك هو أنّه تغيّر. هو ليس استمرار لدورك كموظف مستقل، ولا يعني "القيام بدورك الحالي بشكل أفضل". أن تكون مديرًا هو عمل جديد مختلف تمامًا. "أدركت فجأة أنّه يوجد الكثير من الأشياء التي لا أعرفها "، هي شكوى شائعة كما يقول مايكل واتكينس (Michael Watkins). سيكون لديك الكثير لتتعلّمه، لكن ذلك يجب أن يُقدّر نظرًا للفرصة العظيمة المتاحة أمامك. إنّ الانتقال من موظف مميّز إلى مدير يعني الانتقال: من متخصّص ومنفّذ. كانت مريم كموظفة مستقلّة غارقة في التفاصيل الدقيقة للعمل وخطوات إنتاجه المفصّلة. إلى عام وقائد أوركسترا أصبحت مريم كمديرة خارج عملية الإنتاج، وينصب تركيزها الآن نحو الصورة الأكبر بينما ترشد الموظفين للوصول إلى أهدافهم المهنيّة والشخصيّة. نصيحة سريعة: كيف تتخلّى عن التفاصيل: ركّز على "ما" يجب القيام به، و"متى" يجب الانتهاء منه، واترك تفاصيل "كيف" سيتم ذلك لكل شخص. أحد التحديّات التي قد تواجهها خلال هذا الانتقال هو وضع حد صارم لعاداتك القديمة كموظّف منفرد. قد تكون غريزتك الأولى هي القفز إلى العمل مع فريقك وإصلاح أو حتى إعادة ما قاموا به للوصول إلى النتائج المرجوّة، لكنّك ستدرك سريعًا أنّ ذلك غير مستدام. ما يعنيه أن تكون مديرًا هو أن ترشد فريقك للوصول إلى الأهداف ليتمكّنوا هم من القيام بذلك بشكل مستقل. يقول لويس بريدجمان مدير قسم تطوير البرمجيات في SAP:"أكبر فكرة خاطئة تلقّيتها عن دوري الجديد كانت من توصيف عملي. كنت سرعان ما اقترح نفسي كحل لكل مشكلة اعترضت طريقي. هل يواجه أحد ما صعوبة في تعلّم تقنية جديدة؟ يمكنني أنا تعليمه ذلك، هل تجاوز نطاق المشروع قدرة الفريق؟ يمكنني أنا الانضمام إليهم وموازنة المعادلة. لكنّني الآن يمكنني أن أقول أنّ عملي لم يعد تصحيح الأشياء، بل إرشادها وإدارتها". 3. انتقل إلى عقلية المدير يتطلّب الانتقال من "متخصّص" إلى "عام" تحوّلًا كبيرًا في تفكيرك وعقليتك. كان تركيزك كموظف منفرد ينصب على أدائك ونجاحك الفردي، أن تكون قائدًا هو دور يتطلّب منك أن تضع احتياجات وتطوّر الآخرين قبل احتياجاتك وتطوّرك. لم يعد الأمر يتعلّق بك، لكن ذلك هو جمال هذا العمل. مشاهدة نمو وتعلّم ونجاح الآخرين كنتيجة لقيادتك سيعطيك إحساسًا قويًّا بالنجاح أكبر من أي إحساس راودك كموظف منفرد. وسيقاس نجاحك الشخصي الآن بمقدار نجاح فريقك وتطوّر أفراده مهنيًا. **اعتنِ بنفسك: فعندما ينطلق جهاز الإنذار في الطائرة، تضع قناع الأوكسجين عليك أولًا قبل أن تبدأ بمساعدة الأشخاص المجاورين لك. يمكن للتأمّل مساعدتك على تخفيف التوتر وخلق المزيد من الوضوح داخلك.** عقليات المدير table { width: 100%; } thead { vertical-align: middle; text-align: center; } td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } عقلية المدير الخدمي عقلية النمو عقلية الإنسان ركّز على احتياجات الآخرين قبل احتياجاتك الخاصة وتقبّل أنّ نجاحك هو نجاح الفريق. وهي مقاربة تبدأ من الأسفل إلى الأعلى، بدلًا من الطريقة التقليدية (من الأعلى إلى الأسفل). وفكّر بتقديم الإرشاد الداعم والمفيد عوضًا عن الأوامر. شجّع فريقك ليكون فضوليًا وليتعلّم باستمرار وليتجاوز حدوده. سيساعدهم ذلك على البقاء مندمجين ومبدعين وعلى تحقيق نتائج رائعة. أن تكون مديرًا لا يعني أن تكون إنسانٍا خارقًا، بل إنّه واحد من أكثر الأدوار التي تعتمد على كونك إنسانًا طبيعيًا. كن صادقًا مع فريقك واسمح لنفسك أن تكون هشًا أمامهم، فكلّما كنت حقيقيًا معهم، كانوا كذلك حقيقين أكثر معك. احتضن الاختلافات: تجنّب موازنة نقاط ضعف موظّفيك ونقاط قوتهم بنقاط ضعفك وقوتك الشخصيّة. لا تتدخّل: حدّد مواعيد تسليم واضحة، لكن اترك كيفية القيام بذلك لفريقك. اسألهم، لا تخبرهم: اطرح أسئلة أكثر من تقديم أجوبة لتساعد الموظفين على التعلّم. فكّر إلى الأمام: توقّع التحديّات والحواجز القادمة. اصغِ إلى حدثك: غرائزك غالبًا صحيحة. كن صبورًا مع نفسك: أنت جديد على هذا، لا تكن قاسيًا مع نفسك وحاول أن تستمتع. 4. لا تخجل واطلب المساعدة تُرقّي العديد من الشركات الموظفين إلى دور قيادي للأسف معتقدين أنّهم سيكتشفون ما عليهم فعله تلقائيًا لأنهم ببساطة كانوا رائعين في تأدية جميع المهام الأخرى، إنّ ذلك كالاعتقاد بأنّك لمجرّد قدرتك على قيادة دراجة هوائيّة لن تواجه مشكلة في قيادة دراجة ناريّة. نعم، يوجد القليل من الاستمراريّة لكن الأساس مختلف تمامًا ما بينهما. لذا ضع أي غرور أو خوف داخلك جانبًا وأطلب التوضّيحات والموارد التي تحتاجها لتبدأ بالشكل الصحيح. فكلّما فهمت وحضّرت لدورك بشكل أفضل وسلّحت نفسك بالمعدّات التي تحتاجها للانطلاق بسلاسة، زاد احتمال نجاحك ونجاح فريقك. ستشكر نفسك في المستقبل على ذلك. قائمة التحقق لتحضير المدراء الجدد قال 66% من المدراء في استطلاعنا أنّهم لم يتلقّوا أي تدريب أو إرشاد قبل البدء بدورهم كمدراء. اطلب مدرّب قيادة: لا تصبح قائدًا ناجحًا بشكل تلقائي دائمًا، فذلك يتطلّب عملًا. إذا أردت أن تدرّب فريقك بشكل صحيح، تحتاج أنت أيضًا إلى مدرب. جد موجّهًا من داخل الشركة: ابحث عن مدير آخر يمكنك الاستعانة به لمناقشة دورك وما عليك توقّعه وكيف ستتعامل مع التحديّات التي ستواجهك، فامتلاك شبكة داعمة هو مفتاح نجاحك. اطلب قائمة واضحة بالأدوار والمهام: استخدم هذا القالب واملأه مع مديرك والموارد البشرية ليصبح لديك توجّهًا واضحًا، ثم استعد لتقوم بذات الأمر مع كل فرد في فريقك. تعرّف على الوضع الحالي للفريق الذي ستديره: اعقد اجتماعات فرديّة مع موظفيك الجدد لتتعرف على التحديات التي يواجهها الجميع وأسلوب عملهم قبل أن تبدأ عملك فعليًا. إنّ استخدام أسلوب قيادة مختلف مع كل موظف بما يناسبه هو طريقة رائعة كذلك. القسم الثالث: الكشف عن الخرافات في الإدارة انسَ كل ما تعتقد أن تعرفه عن منصبك، سنوضّح لك أشيع المفاهيم الخاطئة عن الإدارة، حتى لا تبقى أي مفاجآت كبيرة أمامك. الخرافة الأولى: الاستقلالية مقابل الترابط كان لدى مريم اعتقاد خاطئ بأنّها كونها أصبحت مديرة سيعني ذلك امتلاك حرية واستقلالية ذاتية أكبر لتفعل ما تشعر بأنّه الأفضل للشركة. كان تركيزها منصبًّا على الامتيازات والسلطة التي تأتي مع اللقب، معتقدة أنّها وأخيرًا لن تصبح بعد الآن مجبرة على تنفيذ أوامر الآخرين الغير منطقية. أن تكون مديرًا يعني في الواقع أنّه أصبح لديك استقلالية ذاتية أقل مما كان لديك عندما كنت موظفًا منفردًا، لأنّ الآن لديك فريقًا ومديرًا أعلى منك كذلك، وهو ما يدعى ب "الساندويش". لم تعد مهمتك الآن القيام بعملك باستقلالية، إنّما مساعدة فريقك بالكامل على الوصول إلى أهدافهم، مع تحقيق توقّعات الإدارة العليا. فعليك أن تدير على كلا المستويين الآن، الأعلى والأدنى. هو عمل يتطلّب من مريم ارتداء قبعات عديدة، فهي لم تعد بعد الآن "تابعة"، بل أصبحت "تابعة ومساوية ومتفوّقة"، وما زال لديها مديرًا أعلى منها، وهي كذلك الآن مديرة. هو عمل يتطلّب الموازنة ما بين ثلاث "قبّعات" ويستغرق وقتًا لفهمه، لكن أول خطوة للتمكّن منه هو توقّعه وفهم أنّ طبيعة هذا العمل ليست فقط إعطاء الكلمة الأخيرة والموافقة فقط. وإيجاد الوقت للموازنة بين هذه المهام سيأتي مع الوقت والخبرة. الخرافة الثانية: التحكّم مقابل الالتزام الآن وبما أنّك فهمت أنّ أساس عملك هو إدارة وموازنة العلاقات، ستطّلع الآن على كيفية القيام بذلك بنجاح. كان لدى مريم مفهوم خاطئ أنّها الآن ستتحكم بموظفيها ببساطة لأنّها الآن المديرة. لكن الاعتقاد أنّ الموظفين سيستمعون لها لأنّ عليهم ذلك هو خرافة، وكذلك الاعتقاد أنّ نجاحها في هذا الدور يعني المحافظة على هذا التحكّم. النجاح هو ليس قيام موظفيك بما طُلب منهم لأنّ عليهم القيام ذلك، النجاح هو التزام موظفيك بمسار عمل لأنّهم يؤمنون بك، وأنّهم مقتنعون تمامًا برؤيتك وقدرتك كقائد. خلاصة القول هو أنّ النجاح يأتي من التواصل وليس من الأوامر، ومصداقيتك كقائد لها علاقة ضئيلة للغاية مع السلطة الرسمية المعطاة لك. 10 طرق لكسب احترام وثقة فريقك كن شفافًا مع الدوافع والأهداف. اظهر شخصيتك ونيتك للقيام بالأمر الصحيح لفريقك. ضع احتياجات الفريق قبل احتياجاتك الخاصة. ساعد الموظفين على النمو بالسماح لهم بالتجربة والتعلم والفشل دون خوف. ثق بموظفيك تلقائيًا، ولا تجعلهم يشعرون بأنّ عليهم كسب ثقتك. اسمح لنفسك أن تكون هشًّا أمامهم واعترف بأخطائك. استخدم كلمات شمولية مثل "نحن" لتظهر أنّك جزء من الفريق، وليس أعلى منه. اطلب الحصول على تعليقات وملاحظات، واعمل بسرعة على تغيير ما يلزم. كن على طبيعتك، يستجيب الأشخاص بشكل أفضل مع المصداقية. كن منفتحًا على التعلّم من فريقك، يمتلك كل شخص شيء ما لتتعّلمه منه. تدوم الانطباعات الأولى طويلًا، هدّأ فريقك بتواضع من خلال "سؤالهم" وليس ب"إخبارهم"، تعرّف على موظفيك واسمح لهم بالتعرف عليك، ووضّح لهم أنّك موجود لتكون جزء من الفريق وليس من أجلك. الخرافة الثالثة: المهارات التقنيّة مقابل المهارات الاجتماعيّة مريم متأكدة أنّ الأشخاص سيثقون بتوجيهاتها بسبب خبرتها، لأنّ المهارات والقدرات التقنيّة هي التي ستساعدها على إيجاد النجاح في دورها الجديد. إنّ مهاراتك الصلبة ستأتي الآن في المرتبة الثانية بعد مهاراتك اللينة. ما يهم أكثر هو قدرتك على مساعدة فريقك على بناء خبراتهم الشخصيّة وليس القيام بالعمل عنهم. يريد الموظفون التعلّم والنمو، لا أن يتم الحفاظ عليهم كما هم. بل إنّ التدخل واستخدام مهاراتك سيعده بعض الموظفون في الواقع نوع من الإدارة المصغرّة. بما أنّ أساس دورك الجديد يعتمد على العلاقات، فإنّ المهارات المطلوبة لتنجح كمدير هي مهارات تعتمد على الإنسان. لتكون فعّالًا عليك أن تكون منفتحًا على تعلّم المزيد عن نفسك ونقاط القوة والضعف العاطفية لديك. يتطلّب الأمر انضباطًا والتزامًا. إذا التزمت بالتعلّم الذاتي وتغذية ذكائك العاطفي، ستبني القدرة على مساعدة الآخرين على النجاح. حاول بناء قدرتك على التعاطف من خلال التمرن عبر المواقف اليوميّة. على سبيل المثال، فكّر بوجهة نظر مختلفة عن وجهة نظرك وتوصّل إلى دليل قوي يدعمها، حتى وإن لم تغيّر وجهة نظرك، فإنّ ذلك تدريب قيّم على التفكير النقدي. مجالات الذكاء العاطفي الخمسة وفق دانييل غولمان: الوعي الذاتي: معرفة وفهم مشاعرك. التنظيم الذاتي: إدارة عواطفك والقدرة على التفكير قبل التصرف. التحفيز الداخلي: وضع أهداف وتشجيع نفسك على تحقيقها. التعاطف: إدراك وفهم مشاعر الآخرين. المهارات الاجتماعية: بناء العلاقات والتعامل معها، والتعاون وإدارة النزاعات. الخرافة الرابعة: مركز المسرح مقابل ما وراء الكواليس اعتقدت مريم أنّها ستبقى في مركز الساحة تحت الأضواء، بل حتى بشكل أكبر كونها أصبحت المديرة، وتطلّعت لتتلقى تقديرًا أكثر من أي وقت سبق! النجاح الحقيقي للمدير هو في الخروج من تحت الأضواء والانتقال إلى خلف الكواليس! يعني ذلك إرشاد الفريق من المرتبة الأقل إلى الأعلى وتحويل التقدير الذي اعتاد على تلقيّه إلى الآخرين. ويسعد القائد العظيم بالسماح للآخرين بالتألّق ويدرك أنّ نجاحه هو انعكاس لإنجازات الفريق. نصيحة سريعة: كيف تظهر التقدير لموظّفيك: اظهر تقديرك عبر مشاريع أو حوافز محدّدة. اظهر تقديرك لهم علنًا لتبني جوًا إيجابيًا داخل الفريق. شجّع موظفيك على تقدير جهود بعضهم البعض لبناء العلاقات فيما بينهم. قدّم مدحك في أقرب وقت ممكن بعد الحدث الذي جعلهم يستحقّون هذا التقدير. كيف تقيس نجاح ما خلف الكواليس قد يكون غير ملموسًا في بعض الأحيان، لكنّه دائمًا سيكون عظيمًا. عامل الفضول: يقيس المدرّس نجاحه من خلال جودة أداء طلابه، ومن خلال الأسئلة التي يطرحونها في الصف ورغبتهم بتعلّم المزيد. وفي مكان العمل، رؤية موظّفيك يقومون بتجربة مبادرات جديدة وتحدّي الأفكار وطرح أسئلة من خارج الصندوق، هي علامة رائعة لنجاحك! فهذا يعني أنّك أزلت الخوف من مهامهم اليوميّة. ويزدهر الفضول والإبداع بشكل أفضل في البيئات التي يشعر فيها الأشخاص بالأمان ليحلموا أحلامًا كبيرة وليفشلوا دون خجل. روح التعاون: يقيس مدرب الرقص نجاحه بمدى تماسك أداء فريقه ككل وليس كأفراد. القوة الذهنية هي دائمًا أقوى عندما تكون جماعية، لذلك فإنّ الفريق الذي يدعم بعضه البعض ويعمل معًا بتناغم هو أكثر قدرة على تحقيق نتائج أفضل من الفريق الذي يعمل بانفراد. مساعدة الموظفين على خلق روابط فيما بينهم من خلال إنشاء ثقافة من الثقة والاحترام والشفافيّة سيضمن تحقيق النجاح. حاول عقد اجتماعات شهرية يمكن للموظفين خلالها مشاركة مشاعرهم عمّا تم تنفيذه بشكل جيد وعمّا يمكن تحسينه. أحسنت تمكّنت من إنهاء الدليل! يمكنك دائمًا العودة إليه متى ما احتجت ذلك، سنكون دائمًا هنا لمساعدتك. ترجمة -وبتصرف- للمقال: New Managers: The Complete Guide لصاحبته Alison Robins.
  3. حين تُستخدم كلمة مرن (Agile) في مجال الرياضة فإنها تشير إلى الحيوية، والطاقة والمرونة، ويوصف بها الرياضيون وأبطال الأولمبيات الذين تميزوا في ألعابهم، كما يمكن استخدامها لوصف العمليات العقلية التي تتسم بالسرعة والمرونة والحدّة. أما في عالم تصميم تجربة المستخدم فإنها تشير إلى عدد العمليات التي تبدأ بميزانية قليلة، وتجمع فرقًا من المساهمين من أجل إنهاء سلسلة مهام معينة. ويركّز المنظور المرن على التفاعلات والأفراد، ومساهمات المستخدمين، والاستجابة السريعة للتغيير. منهجية التدافع (Scrum Methodology) بدأ استخدام نمط العمل المرن المبني على نموذج التدافع (Scrum Model) لأول مرة في تصميم البرمجيات، ويبدأ عادة بفريق يخطط لاجتماع يقسّم الأعضاء فيه العمليات إلى أجزاء صغيرة ويقررون أي المهام ستوكل إلى كل عضو، ثم ينشئون قائمة بالمهام التي يمكن إنهاؤها في إطار زمني محدد، ويكون عادة بين الأسبوعين والشهر. ويقوم فريق التدافع (Scrum Team) بكتابة الشيفرة البرمجية واختبار أداء المزايا خلال المرحلة الأولى التي تُسمّى "First Agile Sprint”، وهي إطار زمني قصير من العمل المكثّف. ويحضر أعضاء هذا الفريق اجتماعات قصيرة يومية ينظمّها شخص تكون مهمته أشبه بالمدرّب، ويطلق عليه عادة "Scrum Master”، ويشارك الأعضاء في هذه الاجتماعات ما أنجزوه ويفكرون في حلول للمشاكل، وتحافظ هذه الاجتماعات اليومية على إبقاء جميع الأعضاء مدركين لما فعله كل واحد منهم خلال تلك المرحلة. الصورة عبر الموقع prosoftnearshore.com. ثم يعرضوا ما أنجزوه في نهاية المرحلة على المالكين (حملة الأسهم [stakeholders]) ليتلقّوا منهم النقد والملاحظات، فيخططوا للمرحلة التالية من التطوير وما سيتغير فيها أو يُراجَع على ضوء هذه المراجعات. ويساعد نمط العمل المرن الفرَق على إنهاء المشاريع أسرع، لهذا تبنّت مجالات مثل القانون والتسويق منهجيات مشابهة، ذلك أن نمط العمل المرن في تجربة المستخدم هو المسؤول عن رسم الخطوات من أول البحث وتجميع بيانات المستخدمين من خلال اختبار قابلية الاستخدام، وذلك قبل التطوير مباشرة. ويُقدّر من يستخدمون نمط العمل المرن لتجربة المستخدم بنحو 69% من العاملية في مجال تجربة الاستخدام، ولدى جوجل منهجية تيسّرالانتقال من التصميم إلى الاختبار في وقت لا يتجاوز أسبوعًا، لكن لا شك أن كل منظّمة تستطيع أن تعدّل مراحل تلك المنهجية لتناسب أفضل الإطارات الزمنية لمشاريعها. الانتقال إلى أنماط عمل تجربة المستخدم المرنة يسرّع العمل الجماعي من عملية التحول إلى مخططات العمل المرنة إذ ينشئ المصممون والمطورون والمدراء فرقًا مشتركة تتداخل وظائفها ليعمل الجميع على أوجه مختلفة من المشكلة في نفس الوقت. وتركز كل فئة -كمجموعة و كأفراد- على أنشطة المستخدم واحتياجاته وتفاعلاته، وتنظر إلى كل ناحية من خلال تلك العدسة. وتكون العملية بهذا الشكل سلسلة من المراحل أو الأجزاء، ويمكن أن يرجع التطوير من أجل تصحيح خطأ أو فكرة غير صحيحة، أو يتقدّم للأمام إلى المرحلة التالية. تصميم تجربة المستخدم القِطَعية للتخطيط المرن (Chunk UX Design) قد يكون من المغري أن ينقل الفريق تركيزه من تلبية احتياجات المستخدم إلى إنهاء المهام التي بين يديه حين يتحرك بسرعة ليرى المشروع من البداية إلى النهاية في فترة موجزة للغاية. وإن المنتج النهائي لن يكون له قيمة إن لم يحقق الأهداف التي صُمم من أجلها. ويأتي دور التصميم القِطَعي (Chunk design) هنا في أنه يقسّم العمل إلى مهام أصغر كي تعيد تركيزك إلى البحث المرتكز حول المستخدم، فتحدد أولًا هدفك ثم تخطط أنشطة تجربة الاستخدام التي تدعم هذا الهدف، ثم بعد ذلك تقسّم تلك الأنشطة إلى مهام أصغر، وتستخدم بعدها برنامج يعتمد النظام المرن-agile أو بطاقات لاصقة لإنشاء قصص المستخدم- user stories. ويجب أن تقرر الترتيب المناسب لإنجاز تلك المهام ومن سيكون مسؤولًا عن كل واحدة، ويجب أن يكون كل قرار مرتبطًا بإحدى قصص المستخدم- user story. العمل مثل جوجل تتبع عمليات التصميم القوية خطة نظامية، لكن تمهّل قليلًا إن خرجت فكرة عما هو مخطط لها إذ هناك دومًا مساحة للتنفيذ مرة أخرى، وأعد النظر فيها مرة أخرى قبل التقدّم لما بعدها. ويتضمن أسلوب العمل في جوجل خمس مراحل، يحق للمصممين أن يتنقلوا بينها ذهابًا وإيابًا في أي وقت. ودعنا نلق نظرة على كل واحدة من تلك الخطوات التي صممت لتستغرق كل منها يومًا واحدًا، وتستطيع الشركات التي لا تتبع الخط الزمني لجوجل أن تستخدم نفس التسلسل لكي تتحول إلى نمط عمل مرن هي الأخرى. تفصيل المشروع (Unpack the Project) تبدأ مرحلة التصميم في جوجل باجتماع يشمل كل الأفراد الذين لهم علاقة بالمشروع من مختلف أقسام المؤسسة، من المصممين إلى مسؤولي المبيعات إلى ممثلي خدمة العملاء وحتى المدراء، إذ يجب أن يدلي كل هؤلاء بآرائهم من البداية. وبسبب هذا الجمع من الأشخاص ومستويات المسؤولية، فمن من المفيد هنا دعوة شخص تكون مهمته إبقاء الحديث داخل نطاق المشروع. إليك بعض الأمور التي يجب أن تناقشها في خطوة تفصيل المشروع: قدّم تصورًا عامًا عن الكيفية التي ستنتفع بها الشركة من الحل الذي لديك. اعرض مقارنات لما لدى المنافسين لك. استعرض المشكلة والحلول الجزئية الحالية التي تحاول معالجتها. جهّز شخصيات المستخدمين التي تستهدفها، وكذلك نتائج التحليلات التي قمت بها. لخّص الحل الذي تقترحه. استعرض مقاييس تجارية تدعم نجاح الحل الذي تقدّمه. إن نمط العمل المرن يبدأ بتوضيح رؤيتك من البداية، حتى لو لم تتبع أو تستخدم تسلسل جوجل في مشاريعها، فيقدّم المصممون رؤيتهم المبدئية للفريق، سواء عبر رسومات سريعة "Sketches” أو عبر تخطيط لرحلة المستخدم "cutomer journey mapping” داخل الموقع أو المنتج بشكل عام. صياغة مسوّدات للحلول (Sketching Solutions) يتفرق كل من حضر اجتماع تفصيل المشروع لينشئ رسومات بسيطة باستخدام قلم وورقة للحلول المحتملة، وللمشاركين أن يقسّموا الحلول إلى أجزاء صغيرة، ويوضّحوا الترتيب الذي يرونه لتلك الأجزاء. وبشكل عام، ابدأ بإطار عمل بسيط، وستتضح التفاصيل مع الوقت في كل مرة تكرره فيها. اتخاذ القرارات (Making decisions) اسرد العوامل المهمة لك، مثل ميزانيتك، والعوائق التقنية، ومدخلات المستخدمين، ثم راجع الحلول المحتملة لتقلل هذه الحلول إلى عدد محدود وفقًا لما تقتضيه العوامل التي لديك. أيضًا، أنشئ لوحات قصصية "Storyboards” لأفضل الحلول التي جمعتها، واستخدم حائط تصميم "Design Wall” -حائط أو لوحة تعلق عليها الحلول- لتعرض الحلول التي لديك، ثم أعد تقييمها من حيث تركيز كل منها على المستخدم. إنشاء نماذج أولية (Creating Prototypes) تأخذ كل مجموعة أحد الحلول وتبدأ في العمل، تقترح جوجل هنا بناء نماذج أولية بسرعة باستخدام قوالب Keynote أو أي أداة أخرى تسمح بتطوير النماذج في فترة يوم. لا تنس أن تطور عملية اختبار لهذه النماذج لاستخدامها في اليوم التالي أو المرحلة التالية، ويحبّذ كذلك أن تدعو حمَلة الأسهم للمشاركة في كل خطوة. اختبار التصاميم (Testing Designs) اطلب من المستخدمين أن يتفاعلوا مع نموذجك الأولي، وسجّل أنت ملاحظاتك عن تفاعلهم بينما يستخدموه لترى ما الذي لم يحدث كما خططت له، فإن تجربة المستخدم هي التي ستقود المرحلة التالية. يمكن هنا أن يسجّل المصممون المشاكل في تجربة الاستخدام من أخطاء التصميم أو مشاكل الأداء الخلفي (Back End Performance). قد تحتاج المؤسسات في البداية إلى وقت أطول من المتوقع لإنهاء بعض المراحل، تمامًا مثلما يتطور الرياضيون مع التمرين المستمر، لذا فإن فرق التصميم ستنجز أسرع مع التدرب المستمر والمتكرر، وسواء كنت ستجعل نمط العمل المرن الخاص بك مثل نموذج جوجل أو ستطور واحدًا مختلفًا لمؤسستك، فإن إدارة الوقت ستكون جزءًا مما يجعل العملية المرنة ذات كفاءة إنتاج عالية. تعقّب الوقت وضبطه (Time Tracking and Time Boxing) يتوقع أسلوب العمل المرن تقدّم العمل ويتابعه على مدار الوقت تمامًا كما يتوقّع العدّاء الوقت اللازم لإنهاء مسافة ما ويستخدم نقاطًا على طول تلك المسافة ليتابع إنجازه. وتساعد هذه التوقعات الفِرَق على توقع الوقت اللازم لتسليم منتج ما، وقد يكون حساب وقت كل مرحلة صعبًا في البداية، لكن ستجد أن العمل يسير على نمط يمكن توقعه مع الوقت، فيمكنك معه توقع الوقت اللازم لإنهاء مهام فردية خلال المرحلة. أما ضبط الوقت فيتضمن وضع وقت محدد يمكن لنشاط أن ينتهي فيه، فضع إطارًا زمنيًا لبحث تجربة المستخدم وراجع الاجتماعات والمراحل كي تقف على أسباب زيادة الكفاءة، هذا الأسلوب سيدفع كل عضو أن يرفض الأفكار التي لا تصلح مباشرة، ويركز على تلك التي تبدو واعدة. العمل الجماعي هو الذي يوجه مخطط العمل كما أن مرحلة التصميم لها أجزاء واضحة تتجانس معًا، فإن كل عضو في الفريق له دور داخل حلقة تتكرر، فالمصممون يتصورون الصفحات بشكل عام، ويناقشون مهام التصميم على أنها ضرورة لإنشاء الصورة الكاملة، لكن ذلك قد يعني أنهم يعملون بشكل مستقل عن بقية الفريق. ولتلافي ذلك، اكتب مهامًا -مثل قصة المستخدم user story- ، وأشرك الفريق في إنشاء محتوى موجه لأهداف منفردة صغيرة، واسمح للصورة الكاملة أن تتطور من مدخلات الفريق. وإن للمصممين أغلب المدخلات في المزايا التقنية الضرورية للمشروع "Backlog#Product_backlog)"، وكذلك التحليل والتطوير والاختبار، ويكون الوقت مناسبًا لمساهمة المصممين حين يبدأ مطوِّر في العمل على التفاصيل، ويمكن استخدام أدوات إدارة مشاريع مثل basecamp ومنصات التصميم مثل UXPin وتطبيق invision لتسهيل عملية التواصل بين المصممين والمطورين. إن دورة التصميم التكراري هذه تشمل التصميم من أجل القصص الفردية، وتخوض كل منظمة عملية فريدة حين تنتقل إلى مخطط عمل مرن لتجربة المستخدم، فكن مستعدًا للتغيير إلى أن يتطور فريقك ومنتجك إلى شيء أكبر مما كنت تتصور في البداية. ترجمة -بتصرف- لمقال How to Create an Agile UX Workflow لصاحبه Stephen Moyers
  4. رغم حدوث التقييمات السنوية في الشركات مرة واحدة كل عام، إلا أن أثرها يظل باقيًا ومخيّمًا على روح الشركة وثقافتها ، فهي تولّد عقيدة عند الموظف تتحكم في الطريقة التي يؤدي بها مهامه، وتجعله يركّز على المحفز الخارجي -نتيجته في التقييم- بدلًا من المحفز الداخلي -القيم الخاصة بالشركة-، وهي عقيدة مبنية على الخوف من النتيجة السلبية، مما يؤدي إلى قتل الإبداع و النمو في الشركات والأفراد على حد سواء. لذا فقد جلسنا مع كاهينا أويردين وجوانا أواجني، الإداريتان في فريق الثقافة والتنظيم في شركة GSOFT -الشركة الأم لشركتنا Officevibe-، وقد شرحتا لنا السبب الذي جعل مؤسستنا تسير عكس التيار وتوقف التقييم السنوي من دورات النقد والتغذية الراجعة إلى الأبد. من أين يبدأ التغيير تشرح كاهينا تلك الجملة قائلة بأن هناك انتقال من الدوافع الجوهرية الداخلية لتنفيذ مهمة بعينها إلى الدوافع العرَضية، ويضيع الهدف والمعنى في هذا الانتقال، فهناك متعة تُقتطع من العملية حين تعلم أنك تعمل من أجل التقييم، وأرى أنك حينها تعمل من أجل سبب خاطئ. ذلك أن محاولة التعلم بصوره المختلفة -في المدرسة أو بيئة العمل- من أجل الدرجات والمكافآت يزيل الأصالة من الفعل نفسه ويحجّم التفكير والإبداع، وهما العنصران اللذان تنمو الشركة وتنجح بهما. ما وراء الدرجات تبيّن كل من كاهينا وجوانا أن التقييمات السنوية لم تعد طريقة يُعتمد علها في التقييم، ذلك أنها تتأثر كثيرًا بالنتائج القريبة قصيرة المدى، إضافة إلى أن الثقة في الملاحظات التي يجمعها المدراء على مدار العام طريقة غير فعّالة ومفرطة في التفاؤل. ويظهر قصور هذا الأسلوب أيضًا في تثبيط همة الموظفين إذ سيشعرون أن أداءهم صار مرتبطًا بالتقييم الذي أُعطي لهم، ويصبح الموظف حبيس تلك القيمة الرقمية التي أعطيتها له، ويتعامل معه مديره وزملاؤه بناءً على تلك القيمة. لذلك فإننا في حاجة إلى تغيير تلك التقييمات الرقمية واستبدال شيء أقل اعتمادًا على القيم الرياضية بها، لكن يجب أن يكون ذلك البديل ذا معنى ولا يحُدّ من مستوى إنتاج الموظف. لماذا تتعارض التقييمات السنوية مع أنظمة التقييم والتغذية الراجعة الأخرى تستنكر كاهينا اعتماد بعض الشركات نظام التقييم السنوي رغم استخدامها لأنظمة تقييم وتغذية راجعة مختلفة في نفس الوقت قائلة: إن الاتجاه الحالي الذي يركّز على جعل الموظفين في مركز اهتمام المؤسسات من أجل زيادة مستوى الآدمية فيها يتعارض مع أسلوب التقييمات السنوية التي تزيد من الخوف. مستقبل الإدارة في غياب التقييم السنوي يمكن القول بأننا ننتقل إلى عهد جديد في الإدارة، نميل فيه إلى الابتعاد عن الأمر والتحكم، ونجنح إلى تشجيع الفرق ذاتية التنظيم والقيادة المشتركة. إن هذا يسمح للناس بالتركيز على غايتهم من العمل بدلًا من إبهار أشخاص بعينهم من أجل التقييم الذي يتمنون الحصول عليه منهم، كما يفتح للموظف بابًا لتجربة حياة العمل بعيدًا عن عامل الخوف من التقييم، ممهدًا الطريق إلى النمو والإبداع في مسيرته المهنية، حين ينظر إلى السبب والغاية التي يعمل من أجلهما، بدلًا من النظر إلى عواقب كل فعل يقوم به. إن مستقبل العمل الذي نراه يركّز أكثر على تشجيع المخاطرة وتقبل الأخطاء التي نتجت عن الفضول والسعي للاختبار والاكتشاف بدلًا من عدّ مرات الفشل للموظف. لماذا تصر الشركات على الإبقاء على التقييم السنوي إن تغيير منظومة التغذية الراجعة التي ظلّت تلك المنظمات تستخدمها لعقود يتطلب تفكيرًا عميقًا، ذلك أن التخلي عن إحدى عادات الشركة يزداد صعوبة بزيادة حجم الشركة وتعقيدها، خاصة حين يكون لديك نظام نظيف وبسيط يجعلك تجمع السنة كلها في تقييم نهائي. حتى لو أدركت الشركة أن تلك العملية بها عيوب أو قصور فإن عملية التغيير ستكون ثقيلة عليها في تطبيقها دون إرشادات واضحة للبدائل التي تتبعها الشركة. صحيح أن التغيير قد يكون مخيفًا لكنه يستحق المحاولة، ولا يهم إن كنت شركة جديدة أو لك خمسين عامًا في السوق، فيجب أن تبدأ الآن في حركة التغيير إن كنت تريد البقاء كمنظّمة تفكر في المستقبل. ما يريده الموظفون حقًا تستطرد جوانا هنا أن الأمر مناف للمنطق أصلًا بما أن التقييم السنوي يقيّد نفسه إلى الماضي في حين أن التطور يجب أن يسير للأمام، فالتخلص من التقييم المبني على الدرجات ضروري لأي بيئة تعلم ناجح، وإن الموظفين يهتمون بفرصة التعلم والنمو أكثر من المال والمنح، وأول خطوة لتحقيق ذلك هو التواصل المستمر، وفرصة استمرار التغذية الراجعة على مدار السنة. وبما أن التعليم لا نهاية له، فإن إنهاء العام بتقييم سنوي يجعل دورة التعلم ذات بداية ونهاية مرتبطة بذلك التقييم، على عكس التقييم المستمر طيلة العام. لغة التقييم التي يجب أن نتوقف عنها نحن نحتاج إلى تغيير اللغة والمصطلحات التي نستخدمها مع تغيير نظام التقييم السنوي، فالكلمات نفسها تحتوي معاني ودلالات، لذا يجب أن تنظر المنظمة بعناية إلى المصطلحات التي تستخدمها لأنها ستغير ثقافتها وطاقتها ونبرتها، ومن ثَمّ طريقة تصرف الموظفين فيها. تشرح كل من كاهينا وجوانا أن كلمات مثل السيطرة والغلبة قد طغت على ثقافة الفِرَق بدلًا من الفوز المشترك وقوة الجماعة، وإن الكيانات التي نريد إنشاءها لن تكون أفضل بأجزائها المفردة، وإنما عن طريق مشاركة كل فرد فيها وتعاونه مع باقي فريقه. كيف تغير أسلوبك في الخطاب النقاش – التحدي. بدلًا من "أريد أن أرى مهارتك في هذا"، حاول استخدام لهجة ودودة مثل "دعنا ننظر في هذا الأمر بعمق أكبر". الإبداع المشترك – التعاون. حين تجرد كلمة التعاون من معناها، فلن يكون ضروريًا أن تعني العمل الجماعي المباشر، فالتعاون على مشروع قد يعني أن أجلس في زاوية وأؤلف كتابًا بينما تجلس في زاوية أخرى تصمم له رسومات توضيحية، ثم ندمج ما كتبته مع ما رسمته أنت، فالإبداع المشترك ينطوي على العمل معًا حقيقة على مشروع ما. التقييم – التقدير. كلمة التقييم هي أكثر كلمة قد تكون مكروهة في اللغة بالنسبة للموظفين، لذا إني أدعو إلى تغيير الطريقة التي ننظر بها إلى الأداء، فنستبدل التقدير بالتقييم، حيث أن التقدير كلمة إيجابية وقوية في نفس الوقت. الحل: ربط الأداء بالقيم وليس الأرقام أول خطوة نحو تغيير نظم تقييم الأداء في الشركة هي تحديد القيَم الأساسية لشركتك، وتوضيحها جيدًا، ثم انشرها بعد ذلك في الفِرَق في شركتك، وأكّد عليها كل حين. فالمهم هو الفريق والتحرك الجماعي نحو هدف مشترك مبني على نظام قيمي، وليس الأداء الشخصي والدرجات الفردية، فهذين لا ينتميان إلى بيئة العمل. تطبيق الحل سنقسّم القيَم إلى معايير مختلفة أطلقنا عليها "خريطة الحرارة"، والتي سنستخدمها كل ثلاثة أشهر لقياس مدى تطور الموظفين بين الاجتماعات الثنائية الشهرية، وستزودنا الاجتماعات الثنائية ببيانات نتابع بها ذلك التطور. إليك مثالًا يوضح الأمر: معيار قيمة "العائلة": الإبداع المشترك. الحساسية. المجتمع. الاهتمام بالآخرين. استخدم الألوان بدلًا عن الأرقام: أخضر – مستوى جيد، تابع ما تفعله. أصفر – مستوى متوسط، يمكن العمل على تحسينه بالتدريج. أزرق – مستوى ضعيف يحتاج إلى التحسين الفوري. لا أحد سيركز هنا على أرقام، بل بدلًا من هذا فإن الألوان ستستخدم للتعبير عن حالة تطور الموظف مقارنة بمنظومة القيم الخاصة بالشركة. ستلهم هذه الطريقة الجديدة الموظفين كي ينظروا إلى الهدف الأسمى والسبب الذي يعملون من أجله، وسيركّز على التطوير المستمر الذي يجعل الموظفين يعلمون أن هناك دومًا مساحة للنمو. الخلاصة تخصيص الدرجات لتقييم التعليم يقتل الإبداع لأنه يجعل المحفز خارجيًا وليس داخليًا. الخوف من التقييم السنوي يقتل الإبداع في بيئة العمل. التغذية الراجعة تحتاج إلى أن تكون على مدار العام، وليس مرة واحدة فقط فيه. يحتاج الموظفون إلى التواصل المستمر للتعلم والنمو. نحتاج أن ننتبه إلى مصطلحاتنا التي نستخدمها ونتجنب استخدام كلمات تحفز الردود الدفاعية لدى الموظف. ربط أداء الموظفين بأرقام يؤثر على الطريقة التي ينظرون بها إلى أنفسهم والطريقة التي ينظر بها مدراؤهم إليهم ويعاملونهم على أساسها. يجب ربط الأداء بالقيم للحفاظ على تحقيق جميع أفراد المنظمة للهدف المشترك. هل جربت مثل ذلك الأسلوب ورأيت نفعه من قبل؟ أو كنت تتمنى تطبيقه في شركتك؟ دعنا نسمع منك في التعليقات. ترجمة -بتصرّف- لمقال Why We Got Rid Of The Annual Review, For Good لصاحبته Ali Robins حقوق الصورة البارزة محفوظة لـ Freepik
  5. وأخيرا اقتنعت بفلسفة المصادر المفتوحة، أو أنك أخيرا وجدت الوقت للمُساهمة في أحدها، وربما ما دفعك إلى الأمر هو استفادتك من مشروع مفتوح المصدر وأردت أن ترد الجميل بالمساهمة فيه بدورك، لكن لا تدري كيف تقوم بذلك؟ الأمر بسيط، كل ما تحتاجه هو جهاز محلي يكون Git مُنصبا عليه، حساب على Github وبعض الوقت، ومن ثم اتباع بضع خُطوات بسيطة. تجدر الإشارة إلى أنك لا تحتاج إلى أن تكون مُبرمجا للمُساهمة في المشاريع مفتوحة المصدر، يُمكنك المُساهمة في إنشاء أو تحسين توثيق المشروع، حيث يُعتبر التوثيق الجيد أحد أهم عوامل نجاح المشاريع مفتوحة المصدر، وانتشار بعضها على حساب الآخر. لنفرض أن المشروع الذي تود المُساهمة فيه هو "git – الدّليل البسيط". 1. قم باستنساخ المشروع إلى حسابك الخاص وذلك بالنقر على زر Fork الموجود في الزاوية العُلوية اليُمنى لصفحة المشروع. هذه العملية من شأنها أن تُنشئ نُسخة مُطابقة للمُستودع الأصلي على حسابك على Github. 2. بعد ذلك قم باستنساخ هذا المُستودع الجديد على جهازك المحلي. ادخل إلى المجلد الذي تود استنساخ المُجلد فيه (cd path/to/folder) وقم بتنفيذ الأمر git clone متبوعا بعُنوان المُستودع. ستجد العُنوان أسفل القائمة اليُمنى في صفحة المُستودع. بالنسبة لي سيكون الأمر على النحو التالي: git clone https://github.com/djug/simple-guide.git 3. الآن وبعد أن حصلت على هذه النُسخة، قم بإدخال التعديلات التي ترغب فيها واحفظ تلك التعديلات. قبل أن نقوم بإيداع تلك التعديلات، يُنصح دائما التحقق من حالة المُستودع، وإن تم أخذ التعديلات بالحسبان أو إن قمنا بتعديل ملف لم نكن نرغب في تعديله، حيث يكفي أن ننفذ الأمر git status لمعرفة حالة المُستودع (النسخة المحلية): git status On branch master Your branch is up-to-date with 'origin/master'. Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: index.ar.html4. تبدو الأمور طبيعية. لنقم بإرسال التغييرات إلى منطقة الإدراج: git add .ومن ثم إيداعها (commit): git commit -m "Your commit Message Here"بطبيعة الحال ستحتاج إلى وضع وصف مُناسب للتغييرات التي قمت بها. بإمكانك أيضا تنفيذ الأمر commit لوحده من دون أية رسائل: git commitوسيقوم git بفتح مُحرر النصوص المُفضل لديك لكتابة الوصف (في حال ما إذا قمت بتحديد اسم هذا المُحرر في إعدادات git). سنحتاج الآن إلى إرسال هذه التغييرات إلى المُستودع (الشخصي وليس مُستودع المشروع الذي نشارك فيه) على Github عبر تنفيذ الأمر: git push origin masterسيطلب منك Git اسم المُستخدم الخاص بك على Github وكلمة السر، وبمُجرد أن يتم التحقق منهما سيتم دفع التغييرات إلى مُستودعك الخاص. 5. الآن لو عدنا إلى صفحة المُستودع الشخصي على Github سيظهر لنا تاريخ آخر تحديث للملفات المُعدلة ووصف له. وكل ما نحتاج إلى فعله الآن هو إرسال "طلب سحب" pull request -أي سحب التغيرات- إلى المُستودع الأصلي للمشروع وذلك بالنقر على الزر الأخضر الذي يظهر في الزاوية العُلوية اليُمنى للمُستودع ستظهر لك صفحة لتلخص من جديد التغييرات التي تمت 6. الخطوة الأخيرة هي النقر على زر Create Pull request، إضافة أية تعليقات ترغب فيها على الطلب، ومن ثم النقر على زر Send pull request: ستصل صاحب المشروع رسالة بخصوص التغييرات التي قمت بها، وفي حال قبولها سيصلك إشعار بها وستظهر تغييراتك على المستودع الأصلي: هذا كل ما في الأمر. أنت الآن بطريق… أقصد مُشارك في مشاريع مفتوحة المصدر بشكل رسمي. نصائح عامة لدى المساهمة في المشاريعاجعل نص الإيداع commit معبّرا أو ملخصا للتغيرات التي قمت بها، لا تجعله مبهما أو عاما.افصل طلبات السحب "pull request" حسب الغرض، أو اجعل لكل تغير تقترحه في branch لوحده حسب الغرض، مثال: لا ترسل طلب سحب يحتوي تغيرات مرئية في الـ html و css وفيه أيضا ترجمة النصوص إلى العربية، هكذا تصعب المهمة على من يقوم بعملية الدمج في حال كان يريد قبول الترجمة لكنه غير راض عن التغيرات التي طرأت في الـ html/css. في هذه الحالة سيكون من الأنسب:طلب سحب للتغيرات المرئية لوحده.طلب سحب آخر للملفات الترجمة إلى العربية.في حال كانت مساهمتك تحل علة ما تم التبليغ عنها في قسم الـ issues في مستودع المشروع على github، أو لها علاقة به، فإنه يمكنك الإشارة إلى تلك العلة في نص الإيداع فقط بوضع رقم العلة مسبوقا بعلامة #، مثال:git commit -m "fix for some bug (issue #23)"ستلاحظ عند زيارة واجهة Github أن الرقم 23# في نص الإيداع، قد أصبح رابطا يحول مباشرة إلى صفحة تلك العلة. في حال قمت بعمل Fork وساهمت في المشروع، وأردت مرة أخرى أن تساهم في ذاك المشروع مجددا، فلا تنس أن تجعل مستودعك الشخصي من ذاك المشروع محدّثا، يعني اجلب التغيرات الجديدة التي طرأت على المستودع الأصلي، قبل المساهمة مجددا وعمل أي commit أو pull request، هذا يخفض من نسبة التعارض conflicts، ويسهّل عليك وعلى القائمين على المشروع عمليات الدمج، قد تكون التغيرات التي قمت بها، قد قام بها آخر، أو ربما تم حذف الملف الذي تعمل عليه أصلا من المشروع الأصلي، فيضيع جهدك هباءا منثورا.من المحبذ أيضا، استعمال صيغة الأمر في نص الإيداع، مثال، استعمل "add something to file x" عوض "adding|added something to file x".
×
×
  • أضف...