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

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

المحتوى عن 'فرق التطوير'.

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

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

نوع المحتوى


التصنيفات

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

التصنيفات

  • مقالات برمجة عامة
  • مقالات برمجة متقدمة
  • 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. أنت كمصمم, إذا قمت يومًا ما بتسليم أعجوبتك المرئية لمطور فأنت تعرف تمامًا مدى الجدل الذي ينتج عن ذلك. هل ما تخيلته قابل للعمل عند النظر إليه من المنظور التطويري؟ هل يعلم المطور ما الآلية التي كانت تدور في عقلك؟ هل يقوم مطوّرك حقًا بالتطوير؟ القائمة تطول وتطول ولكن دائمًا ما يكون هنالك طرفين للقصة. وماذا عن المطور الذي ينتظر تصميمك؟ وللإجابة على هذا السؤال وعلى أسئلة أخرى قمنا بمقابلة فريقنا الخاص في KlientBoost للخروج بهذه الست نصائح لتعاون أفضل بين المطور والمصمم. كل هذا يبدأ بالتركيز على المستخدم يجب على كل من المطورين والمصممين أن يعملوا دائمًا وأن يُبقوا المستخدم في الحسبان. إن لم تكن التجربة أفضل للمستخدم فلا فائدة من تصميم او حتى بناء أي شيء أي أن جهودك المبذولة لن تكون متماثلة مع أهداف العمل. فإما إن كنت تصمم موقعًا جديدًا أو تطور خصائص جديدة للمنتج فيجب من البداية على فِرق التصميم والتطوير أن يكون لديها هدفًا مشتركًا لتطوير تجربة المستخدم. ولكن كيف بالإمكان أن نعرف ما هو أفضل للمستخدم؟ بالاختبار. وحسب "تن كادويك" من وكالة Five, فإن تجربة المستخدم واختبار المنتج يبدآن بمجرد بدء الأسبوع الأول من المشروع. والاختبار لتحسين تجربة المستخدم لا يتوقف أبداً خلال فترة حياة المشروع. تعطينا مجموعة Nielsen Norman قائمةً يجب على كل من المصممين والمطورين أن يتبعوها عندما يتعلق الأمر باختبار قابلية الاستخدام. وبمجرد اكتمال مرحلة ما قبل الاختبار, فإن فرق التصميم والتطوير تتقارب أكثر وتعلم بالضبط ما يجب التركيز عليه. كلما كان مبكرًا، كان أفضل لن تعلم فِرق التطوير أي شيء عادةً عن المشروع حتى تصلهم ملفات التصميم. وإذا كانت هذه الملفات من الصعب جدًا تنفيذها, فإن هذا يعني بأن المصمم أهدر وقته وأن عليه الآن العودة منذ البداية. ولتجنب حدوث هذا, فإن المصممين والمطورين يحتاجون للعمل سوياً منذ البداية. والانخراط منذ المراحل الأولى يضمن بأن تبقى كل الأطراف متوافقة سوياً ولديها نفس التركيز طوال الوقت. وجدت دراسة في قسم الهندسة الصناعية والإدارة في جامعة "أولو" بفنلندا بأن التعاون المبكر في مشروع ما بين جميع الأطراف يؤدي إلى: فرصة ضئيلة في تطوير تصاميم ركيكة. رضى أكبر بكثير عن عمل المنتج واستخدامه من قبل المستخدم. خلق مساحة للحلول الإبداعية والتبادل المكثف للأفكار قبل فوات الأوان. ولا يختلف المصممون والمطورون في هذا الشأن. أنظمة أقوى تعني عمليات أفضل. عندما تمتلك كل الفرق الأدوات والمعرفة المطلوبتين لإنجاز شيء ما فهي عادةً ما تنجح في انجازه. ولكن أحد الأخطاء الشائعة التي ستجدها بين المصممين والمطورين هي أحياناً أشياء بسيطة مثل: معايير التسمية. الأحجام. الهوامش. الحشوات. الشبكات. ولكن وجود ترتيب موحد من العمليات وطريقة معينة للتعامل معها يساعد على تسريع الأمور, وذلك لأنه لن يتم اهدار الوقت في الإجابة على أسئلة من السهل الإجابة عليها. وهذا يساعد على الوصول لهدف موحد لكل من المصممين والمطورين والذين لن يتعثروا بالمشاكل اللوجستية. وعندما يتعلق الأمر بالأنظمة والعمليات, فإنه هنا تحديداً يجب عليك الحصول على قائمة مفصلة يتّبعها كل فريق من الفرق قبل الانتقال للمرحلة التالية من المشروع. مما يؤدي إلى... ما قبل التسليم بتتبعك لكل نصائحنا حتى هذه النقطة فإنك بالتأكيد تدرك مدى أهمية تسليم مشروعك جاهزًا وبدون أي نقص للتحرك للمرحلة التالية. وبينما يقترب المصممون من إكمال أعمالهم, فإنه من المهم أن تعرج على الأهداف الرئيسية للمشروع للتأكد من اجتيازه للفحص. أسئلة مثل المذكورة بالأسفل ستساعدك على أن تجد تحديثات يجب أن تحدث قبل تمرير المشروع لفريق التطوير: هل جودة التصميم عالية وهل أنت راضٍ عنها؟ هل يحسّن التصميم تجربة المستخدم؟ هل تم اختبار التصميم من قِبل الزبائن الواقعيين؟ بالإجابة بنعم على كل الأسئلة السابقة, فإنك تقلل من فرصة عمل أي إعادة تصميم أو إعادة عمل. سيكون من الصعب عليك أن تجري أي تعديلات على التصميم بمجرد وصوله لأيدي المطور. كيف تسير الأمور؟ 10 مرات بإمكانك قراءة نبرة صوت أحد أو لغة جسده عندما تقابله, ولكن هل هذا كله يختفي عند قراءتك لنص أو لبريد إلكتروني؟ هذا هو نفس الشيء الذي يحدث مع المصممين والمطورين. بمجرد مرور المشروع من مرحلة ما لأخرى, فإن هنالك فرصة كبيرة بأن ترجمة المشروع سوف تختلف من عضو فريق لآخر. هل قصدت أن تعمل هذا لتصميمك أم ذاك؟ وبالفحص المتكرر بين المصممين والمطورين, يمكن للمشروع أن يستمر بالتحرك وذلك بفضل إزالة مشاكل التواصل والتفسير. التواصل الواقعي كلما عمل المصممون والمطورون سويًا على مشاريعك, زادت فرص التوتر. ومع فرقنا في KlientBoost, وجدنا بأنه من سرعان ما نسينا بأننا نعمل كفريق واحد للوصول لنفس الهدف. أما بوجود الوعي الذاتي والإيثار عند التواصل مع أعضاء الفريق الآخرين ستكون قادرًا على إيجاد حل منطقي لأي مشكلة قد تحدث وبسرعة. وباتّباع ال5 نصائح السابقة, بإمكانك وضع أساسات صلبة للتواصل تمنع المشاكل من التصاعد في المقام الأول. والآن حان دورك الفرق التي تتواصل بشكل منفتح وبشكل متكرر تبني منتجات أفضل. جرب هذه النصائح الستة في مؤسستك ونؤمن بأنك ستجد المشاريع أكثر سلاسة وسرعة وسيحظى الناس بالمزيد من المرح أيضًا. ترجمة -بتصرف- للمقال ‎6 tasty ways for designers and developers to collaborate better لصاحبه Johnathan Dane
×
×
  • أضف...