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

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

المحتوى عن 'الكفاءة'.

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

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

نوع المحتوى


التصنيفات

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

التصنيفات

  • مقالات برمجة عامة
  • مقالات برمجة متقدمة
  • 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

ابحث في

ابحث عن


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

  • بداية

    نهاية


آخر تحديث

  • بداية

    نهاية


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

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

  • بداية

    نهاية


المجموعة


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

تم العثور على 1 نتيجة

  1. أنا مهندس الواجهة الأماميّة، ولكن معروف أيضًا كقائد تقنيّ، خبير في الموضوع، والعديد من الأشياء الأخرى. جئت إلى وكالتي الحاليّة ولديّ خمس سنوات من الخبرة في التصميم وإدارة التنمية. ولكن عندما حان الوقت لاختيار مسار لمسيرتي مع الشركة، اخترت المسار التقنيّ. لا بدّ لي من الاعتراف بأنّه لم يكن لديّ أدنى فكرةٍ عمّا يفعله القائد التقنيّ حقًا. في النهاية، اكتشفت ذلك. والخبراء التقنيّون ليسوا بالضرورة قادة تقنيّين. كلاهما لديه مهارات تقنيّة ممتازة. والفرق هو في كيفيّة تعامل الآخرين معك. هل أنت شخصٌ يريد الآخرون متابعته؟ هذا هو السؤال المهمّ حقًّا. وهنا بعض من المهارات البسيطة التي تعيّن القائد التقنيّ، بصرف النظر عن الخبير التقني. ساعد وكأنّه عملك الخاصّ فعاليّتك في منصب القيادة التقنيّة—أو أيّ منصب قياديّ—ستنشأ من ما يمكنك القيام به للأشخاص الآخرين أو من أجلهم. الفعاليّة السليمة هنا تنبع من كونك معروفًا كحلّالٍ موثوقٍ ودقيقٍ للمشاكل لدى الجميع. والهدف من ذلك هو أن يقصدك الناس الآخرين، وليس أن تلاحق الناس لمراجعة التعليمات البرمجيّة. ولكي يحدث ذلك، فإنّ الذكاء والمهارات ليسا كافيين —فأنت بحاجةٍ إلى أن توضّح النقطة التي تجعلك مُجدٍ. بالنسبة للقائد التقنيّ، إنْ كنت مشغولًا جدًّا إلى حدّ يمنعك من المساعدة، فأنت لا تقوم بعملك —وأنا لا أعني مساعدة أحدهم عندما يأتي لطلب المساعدة فحسب. قد تضطرّ إلى تضع في الحسبان لدى مراقبيك، بأنّ مساعدة الآخرين هو جزء حيويّ من وظيفة القائد التقنيّ. لكن خمّن ما الأمر؟ قد يكون وقت الحساب —المراجعة مع رئيسك في العمل. حتى لو لم يكن كذلك، حاول تقدير الوقت الذي يوفّره زملاؤك في العمل. الأرقام تتحدث. المقياس الحقيقي لمدى فائدتك هو الخبرة التقنيّة للفريق بأكمله. إذا كنت ممتازًا في مجالك، ولكنّ فريقك لا يستطيع إنتاج عمل ممتاز، فأنت لست قائدًا تقنيًّا —بل مطوّرًا رفيع المستوى. هناك فرق. كلّ ثنائيّةٍ من التعليمات البرمجيّة التي تكتبها، كلّ جزءٍ من الوثائق التي تجمعها يجب أنْ تكون مناسبةً لاستخدامها كتوجيهٍ للآخرين في فريقك. عند اتخاذ قرار حول كيفيّة حلّ مشكلة أو ما هي التقنيّات المستخدمة، فكّر في الأمور التي ستساعد المطوّرين المستقبليين. وظيفتي كمهندس الواجهة الأمامية غالبًا ما تقتضي مني ليس كتابة تعليمات برمجيّة مرتّبة فحسب، ولكن ترتيب التعليمات البرمجيّة للآخرين للمساعدة في إعادة استخدامها وفهمها من قبل المطوّرين الآخرين. هذه المجموعة الكبيرة من الوظائف قد تعمل بشكل أفضل ككائن، وربّما يكون الأمر متروكًا لك لتحقيق ذلك، سواء من خلال توجيهاتك أو من خلال تنفيذك لها. في الحديث عن التوجيهات، فهناك ضرورةٌ في أنْ تكون شغفًا. فقد كانت الخبرة والكفاءة في التوجيه من أكبر العوامل التي ساعدتني على أنْ أحتلّ منصب مهندس الواجهة الأماميّة. القدرة على المخاطبة أمرٌ لا بدّ منه. ومن المرجّح أنْ تكون كتابة الوثائق على عاتقك. وينبغي عليك النظر إلى كلّ مشكلة تقنيّة تعرض عليك كفرصةٍ لتدريب الشخص الذي أتاك بها. إنّ مساعدة الآخرين، سواء كانوا مطوّرين آخرين، أو مديريّ مشاريع، أو عملاء، يجب أنْ تصبح شغفًا لك إذا كنت قائدًا تقنيًّا طموحًا. قد يأخذ هذا الأمر الكثير من الأشكال، ولكن يجب أنْ يتغلغل في كلّ شيءٍ تنفذه. لهذا السبب، هذه هي القاعدة الأولى. لا ترمي فِراشًا في مسبح حيلةٌ سافرةٌ يمكن أنْ تعلّمنا شيئًا عن كون أحدنا قائدًا تقنيًّا. من السهل علينا أنْ نضع مفارشًا في مسبح. ولكن بمجرد أن تصبح هناك، يصبح من المستحيل تقريبًا إخراجها. لقت أجريت عمليةً حسابيةً على ذلك بالفعل: فِراشٌ بحجمٍ كبيرٍ، حالما تغمره المياه، سوف يزن أكثر من 2000 رطل. وهناك الكثير من الأشياء يَسْهُل أنْ تعمل داخل قاعدة الشِفرة: القوالب، وفلسفات التعليمات البرمجيّة الأساسيّة، وحتى الخيارات على أيّة تقنيّةٍ مستخدمةٍ. ولكن بمجرّد أنْ يتمّ بناء قاعدة الشِفرة على أساسٍ ما، يصبح من المستحيل تقريبًا استخلاص هذا الأساس من دون إعادة بناء قاعدة الشِفرة بأكملها. يبدو أنّ قالب شايني الجديد فكرةٌ رائعةٌ جدًّا؟ ستتمنّى أنْ يستطيع الجميع في فريق عملك معرفة كيفيّة استخدام هذا القالب، وأنّ هذا القالب مستمرٌّ لمدّة لستّة أشهر. ليس لديك الوقت الكافي للعودة وترتيب ذلك الكائن الذي قمت بكتابته لمعالجة جميع وظائف أجاكس؟ لا تكن متفاجئًا عندما يبدأ الناس بكتابة تلك الحلول غير الضروريّة لأنّهم لا يفهمون تعليماتك البرمجية. هل تركت تعليماتك البرمجيّة في حالةٍ تصعب قراءتها وتعديلها؟ أريد منك أنْ تتخيّل أنّ هناك فراشًا يُلقى في مسبح... عجزك عن الاهتمام بهذا الأمر غالبًا ما يؤدّي إلى كونك الشخص الوحيد الذي يمكنه العمل على مشروعٍ معينٍ. وستكون في حالةٍ لا تحسد عليها. وهذا هو الفرق الكبير بين الخبير التقنيّ والقائد التقنيّ: حيث يمكن للخبير التقنيّ أنْ يتجاهل هذا الاعتبار بسهولة. أما القائد التقنيّ فسيقوم باتّخاذ خطواتٍ لضمان عدم حدوث ذلك مطلقًا. كخبير تقني، أنت لاعب رئيسيّ، والخبرة مطلوبة منك في كلّ مكان. وكقائد تقنيّ، فعملك يكمن في إمكانيّة توريد هذه الخبرة، ما إذا كان ذلك يعني تدريب المطوّرين الآخرين، وكتابة وتوثيق التعليمات البرمجيّة لتسريع عمل المطوّرين الآخرين، بغرض اختيار القوالب والمنهجيات التي يكون فريقك على درايةٍ فعليّةٍ بها. وقال جيري واينبرغ، في علم النفس لبرمجة الكمبيوتر، "حتّى لو لم يكن هناك غنىً عن المبرمج، تخلّص منه في أسرع وقتٍ ممكن!" إذا كنت في وضع لا يمكن فيه الاستغناء عنك من أجل مشروع طويل الأمد، يجب أنْ تكون تسوية هذا الأمر أولوّيةً قصوى. لا يجب أنْ تكون مقيدًا بمشروعٍ واحدٍ، لأنّ فريقك بحاجةٍ إلى خبرتك. قبل إنشاء قاعدة الشِفرة لأيّ شيء، اسأل نفسك عمّا يحدث عندما تنتهي من العمل على المشروع. إذا كان الجواب هو أنّه يجب عليهم توظيف شخصٍ أذكى منك أو أن ينهار المشروع، لا تدرجها ضمن مشروعك. وكقائد، يجب أنْ تراقب الآخرين للتأكّد من أنّهم لا يرتكبون الخطأ ذاته. تذكر، القرارات التقنية عادةً ما تقع على عاتق القائد التقنيّ، بغضّ النظر عمّن اتخذها. أنت لست الخبير الوحيد في المكان "لأن البرنامج الجديد مكتوب لنظام التشغيل OS 8 ويمكن أن يعمل أسرع بمرّتين. هل هذا سببٌ كافٍ، يا نانسي درو؟ " هكذا افتتح "نيك بيرنز" فقرة "فتى شركة الكمبيوتر الخاص بك"، في مشهد هزلي ضمن البرنامج التلفزيوني "ساترداي نايت لايف" بنفس الاسم. إنّه خبيرٌ تقنيٌّ يظهر على التلفاز، يسيء لك لفظيًا، ويصلح كمبيوترك، ثم يهينك أكثر قبل أن يصرخ، "أه، مرحبًا بك!" إنّه أحد الأشياء المضحكة لكونها حقيقيّة. الصورة النمطيّة للخبير التقنيّ الذي يعامل الجميع على أنّهم أدنى منزلة سائدةٌ جدًا، حتّى أنّها شقّت طريقها نحو المسرحيّات الهزليّة، والبرامج التلفزيونيّة، والمحادثات اليوميّة في الشركات في جميع أنحاء البلاد. لقد تعاملت مع ذلك الشاب (أو الفتاة). كلّنا فعلنا ذلك. الشابّ الذي لا يعترف بخطائه، الذي يتحوّل إلى شخصيّة دفاعيّة للغاية عندما يقترح الآخرون أفكارهم الخاصّة، الذين يرى دومًا أنّه متفوّقٌ بذكائه على الآخرين ويخبرهم بذلك. في الواقع، كلّ الذين يعملون مع المطوّرين قد تعاملوا مع شخصٍ كهذا في مرحلةٍ من المراحل. يتطلّب الأمر منّي الكثير من الشجاعة والوعي بالذات للاعتراف بأنّني كنت هذا الشخص في أكثر من مناسبة. كشخصٍ ذكيٍ، لقد بنيت احترامي لذاتي على هذا الفكر. لذلك عندما يتمّ تحدي أفكاري، وعندما يكون فكري في موضع السؤال، فإنني أشعر وكأنّ هناك هجومٌ مباشرٌ على احترامي لذاتي. بل والأسوأ من ذلك عندما يكون الشخص أقلّ درايةً مني. كيف يجرؤ على التشكيك بمعرفتي! ألا يعلم أنّني خبير تقنيّ؟ بدلًا من النظر إلى زملائك على أنّهم أشخاصٌ يعرفون أقلّ منك، حاول أنْ تنظر إليهم كأشخاصٍ يعرفون أكثر ممّا كنت تعرفه في مراحل مختلفة. تعامل مع الآخرين على أنّهم خبراءٌ في المجالات الأخرى التي يمكنك أنْ تتعلّم منها. قد لا تعرف مديرة المشروع الكثير عن نهجك الموجّه نحو الحلّ، ولكنّها قد تكون خبيرةً في كيفيّة سير المشروع وكيف يشعر العميل حيال الأشياء. مرّة أخرى، في علم النفس لبرمجة الكمبيوتر، قال واينبرغ، "تعامل مع الناس الذين يعرفون أنّهم أقلّ مرتبةً منك بالاحترام، والمراعاة، والصبر". اخطِ خطوةً أخرى إلى الأمام. لا تتعامل معهم بهذه الطريقة فقط —بل فكّر بهم بهذه الطريقة أيضًا. ستكون مذهولًا بأنّ التعامل مع أناسٍ بنفس المستوى أسهل بكثيرٍ من التعامل مع أتباعٍ أدنى فكريًا —قد يكون التغيير في طريقة التفكير هو كلّ ما يستلزمه إحداث هذا الفرق. الذكاء يتطلّب الوضوح قد تكون حماية خبراتنا من خلال جعل الأمور تبدو أكثر تعقيدًا ممّا هي عليه أمرًا رائعًا. ولكن في الواقع، الأمر لا يتطلّب الكثير من الذكاء لجعل شيءٍ أكثر تعقيدًا ممّا يجب أنْ يكون عليه. ومع ذلك، فالأمر يتطلّب منك قدرًا كبيرًا من الذكاء لأخذ شيءٍ معقّدٍ وجعله أكثر سهولةً. إذا كان المطوّرون الآخرون، والأشخاص غير التقنيين، لا يستطيعون فهم حلّك عند شرحه مستخدمًا المصطلحات الأساسية، فهذا يعني أنّك وقعت في مشكلة. من فضلك، لا تأخذ الفكرة على أنّ "جميع الحلول الجيّدة يجب أنْ تكون بسيطة" ، لأنّ هذا ليس هو الحال على الإطلاق —بل يجب أنْ تكون تفسيراتك بسيطةً. اكتشف طريقة تفكير الأشخاص غير التقنيين كي تستطيع شرح الأمور بمصطلحاتهم. وهذا سيجعلك ذو قيمةٍ أكبر كقائدٍ تقنيّ. من غير الصحيح أنْ تتوقّع بأنّك ستكون حاضرًا لشرح حلولك. في بعض الأحيان، لن تكون قادرًا على رؤية الشخص الذي ينفّذ حلولك، ولكن ذلك البريد الإلكترونيّ الذي أرسلته قبل ثلاثة أسابيع سيكون حاضرًا لشرحها. اعمل على تطوير مهاراتك الكتابية. احصل على نسخةٍ من كتاب "ستيفن بينكر" -"ذي سينس أوف ستايل" و اقرأ عن نمط الكتابة الإقناعية. أنشئ مدونةً واكتب بعض المقالات التعريفيّة حول فلسفات الترميز الخاصّة بك. وتنطبق القاعدة نفسها على تعليماتك البرمجيّة. إذا كانت قراءة التعليمات البرمجية صعبةً، فهذه ليست علامة على أنّ شخصًا ذكيًّا قام بكتابتها؛ بل في الواقع، عادةً ما تعني عكس ذلك. وقال مدير ومهندس البرمجيّات "مارتن فاولر" ذات مرّة، "يمكن لأيّ أحمق أنْ يكتب تعليمات برمجيّة مفهومة للكمبيوتر. والمبرمجون الرائعون هم الذين يكتبون تعليماتٍ برمجيّةٍ مفهومةٍ للبشر. ". تذكّر: الوضوح هو المفتاح. قدرتك على فهم تفكيرك ستحدّد واقع خبرتك في العمل، شئت أم أبيت. أنت من يحدد الأسلوب تخيّل أنّك ذاهب إلى الطبيب لشرح بعض الأعراض الغريبة التي تواجهها. ستجلس على سرير الفحص، وأنت متوترٌ ومرتبكٌ بعض الشيء، بخصوص حقيقة ما يحدث. بينما تشرح حالتك، سيكون الطبيب مصغيًا، وعيونه محدّقةٌ، ويديه متشابكتان. وكلما استطردت في الشرح، ازداد الأمر سوءًا. بينما يرتعش هذا الطبيب. وعندما تنتهي من الشرح أخيرًا، سيتلعثم الطبيب قائلًا، "لا أعرف كيفيّة التعامل مع ذلك!". كيف سيكون شعورك؟ ماذا ستفعل؟ إنْ كنت مكانك، كنت سأقوم بتوديع أحبائي، لأنّ هذه العلامات سيّئة جدًّا. سأكون في حالة ذعرٍ تامٍ بناءً على ردّ فعل الطبيب هذا. الآن، تخيل أن يأتي إليك مدير مشروعٍ ويبدأ بالشرح عن وظيفةٍ غريبةٍ لازمةٍ لمشروعٍ صعبٍ للغاية. بينما تصغي، يصبح واضحًا أنّ هذه الناحية جديدةٌ عليك كليًّا، وكذلك الأمر بالنسبة لشركتك. لست متأكدًا حتّى إذا كان ما يطلبونه ممكنًا. كيف تردّ؟ هل ستكون الطبيب المعتوه المذكور أعلاه؟ إذا كنت كذلك، يمكنني أنْ أؤكّد لك أن مديرة المشروع سوف تكون خائفةًّ كما كنت خائفًا في مثال الطبيب، إنْ لم يكن أكثر من ذلك. لا أقصد أنّك يجب أنْ تكذب وتختلق الأشياء من خيالك، لأنّ هذا التصرف أسوأ. ولكنّني أقصد أنْ تجاوب ب "لا أعرف" دون أدنى تلميح للذّعر في صوتك، هو نوعٌ من الفنّ في الخطاب الذي من شأنه أن يطمئن فرق عملك، والعملاء، والمشرفين، وأي شخصٍ آخر مشاركٍ في المشروع. (تلميح: يقتضي هذا الأمر أنْ يُتبع بالعبارة "ولكن سأقوم بدراسته."). كقائد تقنيّ، سيتبع الناس حسك القياديّ، وكذلك تقنياتك القياديّة. سيتطلّعون إليك ليس فقط من أجل الأجوبة، بل أيضًا من أجل مستوى الاهتمام الذي تقدمه. إذا غادر الناس الاجتماعات معك وهم أكثر قلقًا من ذي قبل، فمن المحتمل أنْ يكون الوقت قد حان لإلقاء نظرةٍ على مدى تأثير ردود أفعالك عليهم. القيادة التقنيّة الحقيقيّة القيادة التقنيّة هي محطّ تركيز الناس مثلها كمثل باقي أنواع القيادة، ومعرفة كيفيّة تأثير إجراءاتك على الآخرين يمكن أن تكون نقطةً فارقةً في الانتقال من خبير تقنيّ إلى قائد تقنيّ. تذكّر: قد يكون جعْلُ الناس يتّبعون خطاك القياديّة أكثر أهميّةً من معرفة كيفيّة حلّ المشاكل التقنيّة. تجاهل الناس يمكن أنْ يكون انتحارًا وظيفيًّا للقائد التقنيّ —والتأثير فيهم هو الجانب الفَتّان من عملك كقائد تقنيّ. ترجمة -وبتصرّف- للمقال The Foundation of Technical Leadership لصاحبه Brandon Gregory حقوق الصورة البارزة محفوظة لـ Freepik
×
×
  • أضف...