מלכודת העדיפויות

האם רב-ברירה היא הבחירה הטובה ביותר?

מלכודת התפריט הנפתח `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?

בעולם האמיתי, סדרי עדיפויות משתנים ומתפתחים כל הזמן בהתבסס על מידע חדש, שינויים בשוק ומטרות ארגוניות.
לעתים קרובות יש אינטראקציה מורכבת בין דחיפות, חשיבות, זמינות משאבים וניתוח עלות/סיכון שתפריט נפתח פשוט לא יכול ללכוד, במיוחד לאורך זמן. (ריקבון כרטיסים.)
לבעלי עניין שונים עשויות להיות דעות סותרות לגבי מה שנחשב לעדיפות גבוהה, מה שהופך גישה אחידה לבלתי מתאימה.

אז מה הלאה?

ישנן מספר גישות חלופיות שכדאי לבחון, ממאמץ נמוך לגבוה:

כדי לספק יותר מרחב תמרון, בחר ערך התחלתי “ניטרלי”, נניח 100 או 1,000. תמיד תוכל להגדיל או להקטין את המספר.
- או היצמד לאפס בתור התחלה, כאשר מספרים גבוהים יותר מייצגים עדיפות גבוהה יותר.
הטמע מערכת תעדוף רב-ממדית המתחשבת בגורמים כמו ערך עסקי, דחיפות ומאמץ נדרש. (צור ציון composite כדי להקל על מיון וסינון.)
אמצו שיטת תעדוף דינמית, כמו טכניקת MoSCoW (חייב, צריך, יכול, לא יהיה), המאפשרת הערכה מחודשת קבועה. (ראו גם מודל Kano.)

סיכום

כל כך הרבה מושקע בעדיפות למרות קצב ההתכלות המהיר שלה. כרטיסי CRITICAL של אתמול לא צפויים להיות כרטיסי CRITICAL של הרבעון הבא.

עם הזמן, כרטיסים ישנים בעלי עדיפות גבוהה הופכים עמידים לניקוי ותחזוקה. אחרי הכל, מי רוצה להוריד את הPriority של משהו שהוכרז פעם כחיוני? שלא לדבר על מחיקת הכרטיסים הלא רלוונטיים האלה… (התנשפות! תחשוב על הבאק-לוג!)

ראיתי חברות רבות שמבלבלות בין Severity ו-Priority. Severity מתאר דחיפות (או רגישות לזמן.)

Priority ≠ Severity. יכול להיות הגיוני להגדיר 3-5 רמות חומרה (המשמשות לעתים קרובות לשמירה על הסכמי רמת שירות.)

רמות הדחיפות עוזרות לתקשר מהשפעת אפס לקוח ועד השבתת שירות חלקית/מלאה.

מילת אזהרה

פריסת שדה עדיפות ללא גבולות דורשת קצת תכנון ומשמעת!

אם אתה מכיר פיתוח צד-לקוח, אולי חווית מלחמת z-index.

בעיקרון, z-index מאפשר למעצבים לקבוע כל מספר שלם חיובי כדי להבטיח שהווידג’טים שלהם יופיעו ‘מעל’ תוכן אחר עם z-index נמוך יותר.

אפילו עדכון קל של רכיב עלול להכניס שינוי ב-z-index של ה-<Dialog /> שלהם – ולהפוך אותו לפתע בלתי נראה. מצבים אלה עלולים להפוך למבולגנים כאשר רכיבי צד שלישי, עבודות תכונה ותרומות צוות אחרות מנסות להתחרות זה בזה ב-z-index.

Z-index היה מוגבל פעם לכ-32,000. עם זאת, לאחרונה ראיתי קטע קוד עם מיליארד z-index: 1000000000!

האינפלציה בטח מכה ב-z-index חזק.

דיון

האם זה ניסוי מחשבתי ראוי?
האם הרעיון של עדיפות הולכת וגדלה מחריד? מעורר חרדה?
האם זה בלתי נמנע שגישה זו תחרוג בסופו של דבר ממגבלות שלם 64-ביט?
האם שדות אחרים (מעבר ל-Severity או Urgency) יכולים לתרום לשיחה זו?
כמה אשמה מגיעה לג’ירה? או קרדיט?

אפשר לצרוח אל האינטרנט, ‘מי הולך לנקות את כל הכרטיסים P00 האלה?’

או, שאתה יכול להיות רציני לגבי הבק-לוג שלך.

קבל ש-90% מ-1,000 הכרטיסים שלך לעולם לא יבוצעו. זה בסדר.
ארכב כרטיסים שלא נגעו בהם במשך חודשים. כל עדיפות/דחיפות ראשונית כבר לא רלוונטית. בכל מקרה, אפשר לרוב לשחזר בעיות מאורכבות.
כשבעיה חוזרת, זה מגניב; זה פשוט העלה את העדיפות שלה.
מבחינה אנקדוטלית, לא שמתי לב לנזק כלשהו מהשלכת כרטיסים ישנים ולא שלמים.
הוספה אינסופית לבק-לוג-כמסד-נתונים מפספסת את ההזדמנות למקד את הצוות והארגון שלך במה שחשוב. (דברים שלפנינו. בעוד שבק-לוגים מסתכלים מטבעם לאחור.)
בק-לוג עמוק בסופו של דבר נראה כמו חדר גביעים ביזארי, שחוגג את הזבל שלעולם לא תשלח.