DanLevy.net

فخ الأولويات

هل الاختيار من متعدد هو الخيار الأفضل؟

فخ القائمة المنسدلة Priority

قصة شركة ناشئة

دون فشل، سيجد مسؤولو Jira لديك حلًا: ها هي قائمة منسدلة لحقل Priority! (نصيحة احترافية لمطوري المؤسسات: ربما تُسمى Priority2 أو P-level).

الغريب أن 100% من الشركات تختار بين P1, P2, P3, P4 أو Low, Med, High, and Critical — ويبدو أنه لا توجد خيارات أخرى.

قائمة ثابتة من أربعة خيارات؟ حسنًا. لنجربها لبضعة أسابيع…

بعد يومين

في تطور لا يُفاجئ أحدًا، اكتشفت المؤسسة مهمة ذات أولوية أعلى جديدة، مما استدعى اختراقًا بسيطًا: إضافة P0، أو Critical Max+!

بعد 3 أيام أخرى

كان لمديرنا الشجاع بعض الاجتماعات والاكتشافات المثيرة في المؤتمر!

بطريقة ما، اكتشفوا أولوية أعلى من P0!

منذ ذلك الحين، انكب الفريق على البحث عن كيفية تسمية هذه الأولوية الجديدة. ربما -1؟ لا، لا. هذا مربك جدًا (P-1 مقابل P1). حسنًا، ماذا عن P0.5، لا؟

في لحظة “ملهمة”، اخترع الفريق أولوية أعلى: الصفر المزدوج!
المعروف الآن باسم أولوية P00.

قبل الطوفان

قبل أن يدرك أحد ذلك، يجد فريقك نفسه غارقًا في تذاكر P00!

كيف يمكننا تجنب هذه اللعبة السخيفة من مسرح الهندسة؟

ماذا لو لم تكن الأولوية اختيارًا من متعدد؟

كيف يمكننا تمثيل مفهوم بشري متغير وسائل مثل Priority بشكل أفضل؟

إذن، ما التالي؟

هناك عدة طرق بديلة تستحق الاستكشاف، من الجهد المنخفض إلى العالي:

ملخص

يتم وضع الكثير من التركيز على الأولوية على الرغم من معدل تدهورها السريع. تذاكر حرجة الأمس ليست على الأرجح تذاكر حرجة الربع القادم.

بمرور الوقت، تصبح التذاكر القديمة ذات الأولوية العالية مقاومة للتنظيف والصيانة. ففي النهاية، من يريد خفض أولوية شيء تم إعلانه أساسيًا؟ ناهيك عن حذف تلك التذاكر غير ذات الصلة… (يا للهول! فكر في قائمة الانتظار!)

رأيت العديد من الشركات تخلط بين الخطورة والأولوية. الخطورة تصف الإلحاح (أو حساسية الوقت.)

الأولوية ≠ الخطورة. قد يكون من المنطقي تحديد 3-5 مستويات للخطورة (غالبًا ما تُستخدم للحفاظ على اتفاقيات مستوى الخدمة.)

تساعد مستويات الإلحاح في التواصل من تأثير صفري على العميل إلى انقطاع جزئي/كلي للخدمة.

كلمة تحذير

يتطلب نشر حقل أولوية غير محدود القيمة بعض التخطيط والانضباط!

إذا كنت ملمًا بتطوير الواجهة الأمامية، فربما تكون قد واجهت حرب z-index.

ببساطة، يتيح z-index للمصممين تعيين أي عدد صحيح موجب لضمان ظهور عناصرهم ‘فوق’ المحتوى الآخر ذي z-index الأقل.

حتى تحديث بسيط لمكون ما قد يُحدث تغييرًا في z-index على <Dialog /> الخاص بهم - مما يجعله غير مرئي فجأة. قد تصبح هذه المواقف فوضوية عندما تحاول مكونات الطرف الثالث، وأعمال الميزات، ومساهمات الفريق الأخرى التفوق على بعضها البعض في z-index.

كان z-index مقيدًا سابقًا بحوالي 32,000. لكنني رأيت مؤخرًا مقتطفًا يحتوي على مليار z-index: 1000000000!

لا بد أن التضخم يضرب z-index بقوة.

نقاش

يمكننا أن نصرخ في وجه الإنترنت: “من سينظف كل هذه التذاكر P00؟”

أو يمكنك أن تكون واقعيًا بشأن قائمة مهامك المتراكمة.