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



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

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

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

نوع المُحتوى


التصنيفات

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

التصنيفات

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

التصنيفات

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

التصنيفات

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

التصنيفات

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

التصنيفات

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

التصنيفات

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

التصنيفات

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

أسئلة وأجوبة

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

التصنيفات

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

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

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