אופן תעדוף משימות קצרות אך לא דחופות

Eitanyom1

New member
אופן תעדוף משימות קצרות אך לא דחופות

שלום,

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

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

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

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


אשמח לקבל את עזרתכם בנושא.

תודה!
 

choo

Active member
אל תיצור context-switch אצל המפתחים בכח

&nbsp
בעקרון, עדיף לאדם לסיים משימה אחת ואז להתחיל משימה שניה, מבחינת הפניית קשב וזכרון לטווח קצר. מה עושים עם המשימות הקצרות והלא-דחופות? מחליטים כמה אחוז מהזמן הכולל מוכנים להשקיע בהן, ומשלבים אותן בין משימות אחרות לפי האחוזים הללו. כן - זה אומר שמישהו שביקש משהו קצר עשוי לחכות יומיים, כי המפתח שיטפל בדבר הקצר הזה נמצא באמצע משימה אחרת בחומיים קרובים, אבל זה מה שיש. אתה יכול לאמר לאותו מפתח שאם הוא מעוניין בהפסקה קלה במשימה הנוכחית שלו - הוא יכול להקדים את המשימה הלא-דחופה הבאה שלו - אבל זו צריכה להיות החלטה שלו.
&nbsp
כמובן שיש גם שיטות אחרות לבצע את התיעדופים הללו (מה שהצגתי נותן עדיפות לתפוקה על פני מהירות אספקת ערך [או זמן תגובה - latency]. יש אירגונים שבהם זה לא המצב, גם בגרנולריות של ימים בודדים)
 

liron50

New member
תחלק את המשימות לפי גרסאות ולפי כמות השעות הזמינות

גם אם לא עובדים בפועל עם גרסאות. אתה יכול להקצות עבודה למשך שבוע.
אם 4 מפתחים שנניח לכל אחד 40 שעות בשבוע. אז זה 160 שעות פיתוח. תקצה להם משימות שאת כולן הם אמורים לסיים במהלך השבוע הקרוב. מתוך המשימות שאתה מקצה לשבוע אפשר לחליט ש-10% מהן יהיו פחות חשובות.
במידה ונכנס משהו דחוף, אז צריך להעביר משימה אחרת מהמפתח לשבוע אחר.
&nbsp
וכן, זה אומר שלפעמים משימות פחות חשובות מתעכבות.
 

selalerer

New member
מה זאת אומרת "מי שדורש אותן לא מוכן לחכות יומיים"?

אם זו לא משימה דחופה, אז אף אחד לא שואל אותו.
אם אין ברירה וצריך לרצות אותו אז זו משימה דחופה.
 

Eitanyom1

New member
מי שביקש את אותה משימה קצרה לא ירצה לחכות כ"כ הרבה זמן

(היומיים הייתה דוגמא) מכיוון שעד אז המשימה לא תהיה רלוונטית...
 

Lhuna1

New member
מה זה "לא ירצה"?

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

vinney

Well-known member
זה שהמשימה לא דחופה לא אומר שצריך לחכות שנים איתה

יש מלא משימות "לא דחופות" שצריך לעשות, ועם הגישה הזאת אתה תמיד תהיה עסוק בלכבות שריפות כי אתה רק מתעסק עם מה שהכי דחוף. זה לא טוב.
 

selalerer

New member
השאלה פה היא אם לעשות context switch למפתח עבור המשימה הזו

המפתח נמצא עכשיו במשימה שתיקח לו עוד יומיים, אם זו משימה חשובה יותר, להעביר אותו עכשיו למשימה הקצרה והלא חשובה כי מי שביקש אותה לא מוכן לחכות יומיים?
 

vinney

Well-known member
אני מניח שזה תלוי באיך רש״צ מנהל את המשימות.

למשל - ֿהמפתח קם לקפה כל שעתיים - אז כל יום שעתיים בין הפסקות קפה של 2 ו4 הוא יעשה משימות קצרות.
&nbsp
תעדוף משימות וניהול זמן של הצוות אלה בעיות לא קלות, וזה בדיוק איפה שהמנהלים וראשי צוותים באים לידי ביטוי. וכן, משימות ״לא חשובות״ הן עדיין משימות, עדיין צריך לעשות אותן, ורצוי לעשות אותן לפני שמתחילות האסקלציות והמריבות והפיצוצים כי זה שלא מוכן לחכות יומיים כבר חיכה חודשיים לדבר הזה.
 

Lhuna1

New member
אני אגיד לך איך זה קורה בגדול אצלנו

ובאופן דומה היה במקומות אחרים שעבדתי בהם:

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

בתוך החלוקה הזאת יש חופש למתכנת לבחור לעצמו את המשימה הבאה, כאשר ההבנה היא שבאופן כללי עושים קודם משימות "קריטיות" ורק אחרי שהן נגמרות עוברים ל"חשובות" וכו' - אבל - בתוך זה יש גם מקום גם לטיפול ב- low hanging fruits - משימות שהן קטנות ומהירות, גם אם עדיפותן נמוכה יותר.
מתי המתכנת יבחר לקחת משימה כזאת? זה לשיקול דעתו.
אולי בין שתי משימות גדולות או קשות הוא יעדיף לעשות הפסקה ולפתור משהו קטן וקל.
אולי הוא תקוע על איזו בעיה יותר מידי זמן וצריך קצת לנקות ממנה את הראש ולעשות משהו אחר.
אולי הוא רואה שהצטברו 10 משימות קטנות כאלו והגיע הזמן "לנקות קצת" לפני שמתחיל את המשימה הבאה.
בכל מקרה ברור שהוא לא אמור להתעכב מעבר לזמן קצר על משימות כאלו כשיש דחופות יותר.

ספציפית בדוגמה שאתה נתת אני מסכימה עם הכותבים מעלי שלא ברורה הגדרת הדחיפות/נחיצות האמיתית שלה וזו בעיה מסוג אחר.
 
למעלה