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



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

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

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

نوع المُحتوى


التصنيفات

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

التصنيفات

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

التصنيفات

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

التصنيفات

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

التصنيفات

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

التصنيفات

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

التصنيفات

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

التصنيفات

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

أسئلة وأجوبة

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

التصنيفات

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

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

  1. رغم حدوث التقييمات السنوية في الشركات مرة واحدة كل عام، إلا أن أثرها يظل باقيًا ومخيّمًا على روح الشركة وثقافتها ، فهي تولّد عقيدة عند الموظف تتحكم في الطريقة التي يؤدي بها مهامه، وتجعله يركّز على المحفز الخارجي -نتيجته في التقييم- بدلًا من المحفز الداخلي -القيم الخاصة بالشركة-، وهي عقيدة مبنية على الخوف من النتيجة السلبية، مما يؤدي إلى قتل الإبداع و النمو في الشركات والأفراد على حد سواء. لذا فقد جلسنا مع كاهينا أويردين وجوانا أواجني، الإداريتان في فريق الثقافة والتنظيم في شركة GSOFT -الشركة الأم لشركتنا Officevibe-، وقد شرحتا لنا السبب الذي جعل مؤسستنا تسير عكس التيار وتوقف التقييم السنوي من دورات النقد والتغذية الراجعة إلى الأبد. من أين يبدأ التغيير تشرح كاهينا تلك الجملة قائلة بأن هناك انتقال من الدوافع الجوهرية الداخلية لتنفيذ مهمة بعينها إلى الدوافع العرَضية، ويضيع الهدف والمعنى في هذا الانتقال، فهناك متعة تُقتطع من العملية حين تعلم أنك تعمل من أجل التقييم، وأرى أنك حينها تعمل من أجل سبب خاطئ. ذلك أن محاولة التعلم بصوره المختلفة -في المدرسة أو بيئة العمل- من أجل الدرجات والمكافآت يزيل الأصالة من الفعل نفسه ويحجّم التفكير والإبداع، وهما العنصران اللذان تنمو الشركة وتنجح بهما. ما وراء الدرجات تبيّن كل من كاهينا وجوانا أن التقييمات السنوية لم تعد طريقة يُعتمد علها في التقييم، ذلك أنها تتأثر كثيرًا بالنتائج القريبة قصيرة المدى، إضافة إلى أن الثقة في الملاحظات التي يجمعها المدراء على مدار العام طريقة غير فعّالة ومفرطة في التفاؤل. ويظهر قصور هذا الأسلوب أيضًا في تثبيط همة الموظفين إذ سيشعرون أن أداءهم صار مرتبطًا بالتقييم الذي أُعطي لهم، ويصبح الموظف حبيس تلك القيمة الرقمية التي أعطيتها له، ويتعامل معه مديره وزملاؤه بناءً على تلك القيمة. لذلك فإننا في حاجة إلى تغيير تلك التقييمات الرقمية واستبدال شيء أقل اعتمادًا على القيم الرياضية بها، لكن يجب أن يكون ذلك البديل ذا معنى ولا يحُدّ من مستوى إنتاج الموظف. لماذا تتعارض التقييمات السنوية مع أنظمة التقييم والتغذية الراجعة الأخرى تستنكر كاهينا اعتماد بعض الشركات نظام التقييم السنوي رغم استخدامها لأنظمة تقييم وتغذية راجعة مختلفة في نفس الوقت قائلة: إن الاتجاه الحالي الذي يركّز على جعل الموظفين في مركز اهتمام المؤسسات من أجل زيادة مستوى الآدمية فيها يتعارض مع أسلوب التقييمات السنوية التي تزيد من الخوف. مستقبل الإدارة في غياب التقييم السنوي يمكن القول بأننا ننتقل إلى عهد جديد في الإدارة، نميل فيه إلى الابتعاد عن الأمر والتحكم، ونجنح إلى تشجيع الفرق ذاتية التنظيم والقيادة المشتركة. إن هذا يسمح للناس بالتركيز على غايتهم من العمل بدلًا من إبهار أشخاص بعينهم من أجل التقييم الذي يتمنون الحصول عليه منهم، كما يفتح للموظف بابًا لتجربة حياة العمل بعيدًا عن عامل الخوف من التقييم، ممهدًا الطريق إلى النمو والإبداع في مسيرته المهنية، حين ينظر إلى السبب والغاية التي يعمل من أجلهما، بدلًا من النظر إلى عواقب كل فعل يقوم به. إن مستقبل العمل الذي نراه يركّز أكثر على تشجيع المخاطرة وتقبل الأخطاء التي نتجت عن الفضول والسعي للاختبار والاكتشاف بدلًا من عدّ مرات الفشل للموظف. لماذا تصر الشركات على الإبقاء على التقييم السنوي إن تغيير منظومة التغذية الراجعة التي ظلّت تلك المنظمات تستخدمها لعقود يتطلب تفكيرًا عميقًا، ذلك أن التخلي عن إحدى عادات الشركة يزداد صعوبة بزيادة حجم الشركة وتعقيدها، خاصة حين يكون لديك نظام نظيف وبسيط يجعلك تجمع السنة كلها في تقييم نهائي. حتى لو أدركت الشركة أن تلك العملية بها عيوب أو قصور فإن عملية التغيير ستكون ثقيلة عليها في تطبيقها دون إرشادات واضحة للبدائل التي تتبعها الشركة. صحيح أن التغيير قد يكون مخيفًا لكنه يستحق المحاولة، ولا يهم إن كنت شركة جديدة أو لك خمسين عامًا في السوق، فيجب أن تبدأ الآن في حركة التغيير إن كنت تريد البقاء كمنظّمة تفكر في المستقبل. ما يريده الموظفون حقًا تستطرد جوانا هنا أن الأمر مناف للمنطق أصلًا بما أن التقييم السنوي يقيّد نفسه إلى الماضي في حين أن التطور يجب أن يسير للأمام، فالتخلص من التقييم المبني على الدرجات ضروري لأي بيئة تعلم ناجح، وإن الموظفين يهتمون بفرصة التعلم والنمو أكثر من المال والمنح، وأول خطوة لتحقيق ذلك هو التواصل المستمر، وفرصة استمرار التغذية الراجعة على مدار السنة. وبما أن التعليم لا نهاية له، فإن إنهاء العام بتقييم سنوي يجعل دورة التعلم ذات بداية ونهاية مرتبطة بذلك التقييم، على عكس التقييم المستمر طيلة العام. لغة التقييم التي يجب أن نتوقف عنها نحن نحتاج إلى تغيير اللغة والمصطلحات التي نستخدمها مع تغيير نظام التقييم السنوي، فالكلمات نفسها تحتوي معاني ودلالات، لذا يجب أن تنظر المنظمة بعناية إلى المصطلحات التي تستخدمها لأنها ستغير ثقافتها وطاقتها ونبرتها، ومن ثَمّ طريقة تصرف الموظفين فيها. تشرح كل من كاهينا وجوانا أن كلمات مثل السيطرة والغلبة قد طغت على ثقافة الفِرَق بدلًا من الفوز المشترك وقوة الجماعة، وإن الكيانات التي نريد إنشاءها لن تكون أفضل بأجزائها المفردة، وإنما عن طريق مشاركة كل فرد فيها وتعاونه مع باقي فريقه. كيف تغير أسلوبك في الخطاب النقاش – التحدي. بدلًا من "أريد أن أرى مهارتك في هذا"، حاول استخدام لهجة ودودة مثل "دعنا ننظر في هذا الأمر بعمق أكبر". الإبداع المشترك – التعاون. حين تجرد كلمة التعاون من معناها، فلن يكون ضروريًا أن تعني العمل الجماعي المباشر، فالتعاون على مشروع قد يعني أن أجلس في زاوية وأؤلف كتابًا بينما تجلس في زاوية أخرى تصمم له رسومات توضيحية، ثم ندمج ما كتبته مع ما رسمته أنت، فالإبداع المشترك ينطوي على العمل معًا حقيقة على مشروع ما. التقييم – التقدير. كلمة التقييم هي أكثر كلمة قد تكون مكروهة في اللغة بالنسبة للموظفين، لذا إني أدعو إلى تغيير الطريقة التي ننظر بها إلى الأداء، فنستبدل التقدير بالتقييم، حيث أن التقدير كلمة إيجابية وقوية في نفس الوقت. الحل: ربط الأداء بالقيم وليس الأرقام أول خطوة نحو تغيير نظم تقييم الأداء في الشركة هي تحديد القيَم الأساسية لشركتك، وتوضيحها جيدًا، ثم انشرها بعد ذلك في الفِرَق في شركتك، وأكّد عليها كل حين. فالمهم هو الفريق والتحرك الجماعي نحو هدف مشترك مبني على نظام قيمي، وليس الأداء الشخصي والدرجات الفردية، فهذين لا ينتميان إلى بيئة العمل. تطبيق الحل سنقسّم القيَم إلى معايير مختلفة أطلقنا عليها "خريطة الحرارة"، والتي سنستخدمها كل ثلاثة أشهر لقياس مدى تطور الموظفين بين الاجتماعات الثنائية الشهرية، وستزودنا الاجتماعات الثنائية ببيانات نتابع بها ذلك التطور. إليك مثالًا يوضح الأمر: معيار قيمة "العائلة": الإبداع المشترك. الحساسية. المجتمع. الاهتمام بالآخرين. استخدم الألوان بدلًا عن الأرقام: أخضر – مستوى جيد، تابع ما تفعله. أصفر – مستوى متوسط، يمكن العمل على تحسينه بالتدريج. أزرق – مستوى ضعيف يحتاج إلى التحسين الفوري. لا أحد سيركز هنا على أرقام، بل بدلًا من هذا فإن الألوان ستستخدم للتعبير عن حالة تطور الموظف مقارنة بمنظومة القيم الخاصة بالشركة. ستلهم هذه الطريقة الجديدة الموظفين كي ينظروا إلى الهدف الأسمى والسبب الذي يعملون من أجله، وسيركّز على التطوير المستمر الذي يجعل الموظفين يعلمون أن هناك دومًا مساحة للنمو. الخلاصة تخصيص الدرجات لتقييم التعليم يقتل الإبداع لأنه يجعل المحفز خارجيًا وليس داخليًا. الخوف من التقييم السنوي يقتل الإبداع في بيئة العمل. التغذية الراجعة تحتاج إلى أن تكون على مدار العام، وليس مرة واحدة فقط فيه. يحتاج الموظفون إلى التواصل المستمر للتعلم والنمو. نحتاج أن ننتبه إلى مصطلحاتنا التي نستخدمها ونتجنب استخدام كلمات تحفز الردود الدفاعية لدى الموظف. ربط أداء الموظفين بأرقام يؤثر على الطريقة التي ينظرون بها إلى أنفسهم والطريقة التي ينظر بها مدراؤهم إليهم ويعاملونهم على أساسها. يجب ربط الأداء بالقيم للحفاظ على تحقيق جميع أفراد المنظمة للهدف المشترك. هل جربت مثل ذلك الأسلوب ورأيت نفعه من قبل؟ أو كنت تتمنى تطبيقه في شركتك؟ دعنا نسمع منك في التعليقات. ترجمة -بتصرّف- لمقال Why We Got Rid Of The Annual Review, For Good لصاحبته Ali Robins حقوق الصورة البارزة محفوظة لـ Freepik
  2. وأخيرا اقتنعت بفلسفة المصادر المفتوحة، أو أنك أخيرا وجدت الوقت للمُساهمة في أحدها، وربما ما دفعك إلى الأمر هو استفادتك من مشروع مفتوح المصدر وأردت أن ترد الجميل بالمساهمة فيه بدورك، لكن لا تدري كيف تقوم بذلك؟ الأمر بسيط، كل ما تحتاجه هو جهاز محلي يكون 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".