לבחור מה לא לשפר
לבחור מה לא לשפר
במערכת קיימת, הבעיה האמיתית אינה מחסור ברעיונות לשיפור - אלא עודף.
תמיד יש מה לייעל. תמיד יש מה לנקות. ותמיד יש משהו ש”ברור שצריך לטפל בו”.
אבל אין מערכת שמאפשרת לטפל בהכול.
האשליה: אם נשפר מספיק, הכול יסתדר
קל להאמין ש:
- עוד אופטימיזציה קטנה תוריד עומס
- עוד Refactor ישפר יציבות
- ועוד שיפור ביצועים יפתור תלונות משתמשים
אבל בפועל, שיפורים לא מצטברים בקו ישר.
חלקם:
- מבטלים זה את זה
- מזיזים את הבעיה למקום אחר
- או יוצרים מורכבות חדשה לגמרי
מערכת לא משתפרת מכל שיפור - היא משתפרת משיפורים נכונים.
איך מזהים את צוואר הבקבוק האמיתי
צוואר בקבוק אמיתי אינו בהכרח המקום הכי איטי, או הקוד הכי מכוער.
לעיתים הוא המקום שבו:
- שינוי קטן גורר הכי הרבה dependencies
- החלטה אחת משפיעה על הרבה רכיבים
- או שבו מתקבלות הכי הרבה החלטות תחת לחץ
זה המקום שבו שיפור אחד יכול לשנות דפוס התנהגות שלם.
למה שיפורים מקומיים מבלבלים
שיפור מקומי נראה מפתה:
- הוא מדיד
- הוא בשליטת צוות אחד
- והוא נותן תחושת התקדמות
אבל מערכת חיה היא מערכת מקושרת.
שיפור באזור אחד יכול:
- להגדיל עומס באזור אחר
- לשנות קצבים
- או להפעיל מנגנונים שלא תוכננו לפעול יחד
ואז, למרות שהכול “יותר מהיר” - המערכת פחות יציבה.
מתי להשאיר בעיה לא אופטימלית בכוונה
יש בעיות שעדיף לא לפתור עכשיו.
לא כי הן לא חשובות - אלא כי המחיר שלהן ידוע, והמחיר של שינוי אינו.
לדוגמה:
- קוד לא יפה אבל יציב
- מנגנון איטי אך צפוי
- פתרון עוקף שכל הצוות מכיר
במצבים כאלה, השארת בעיה לא אופטימלית היא החלטה מודעת - לא הזנחה.
השורה התחתונה
הנדסה יציבה אינה שואלת: “מה עוד אפשר לשפר?”
אלא: “באיזו בעיה לא נטפל עכשיו - ולמה?”
הבחירה הזו קשה, כי היא דורשת ויתור.
אבל ויתור נכון הוא אחד הכלים החזקים ביותר במערכת שאין לה נקודת התחלה.
מבט קדימה
קשה לבחור מה לא לשפר - אבל קשה עוד יותר להשפיע כשאין סמכות רשמית.
בפוסט הבא נעסוק בשאלה: איך מהנדסים מובילים שינוי גם בלי טייטל.