יותר פיצ׳רים = יותר בלגן

״רק עוד כפתור קטן״

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

הבעיה היא שכל בקשה נשקלת לבדה, ואף אחד לא שוקל את הסכום. השאלה שנשאלת היא ״כמה זמן ייקח לבנות את זה?״ — וכשהתשובה היא ״יומיים״, הבקשה מאושרת. השאלה שלא נשאלת היא ״מה זה עושה למערכת שכבר קיימת?״, ודווקא היא היקרה.

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

ארבעת המחירים של פיצ׳ר אחד

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

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

באגים. פיצ׳רים לא מתווספים — הם מכפילים. שני מתגים בלתי תלויים יוצרים ארבעה מצבים אפשריים; עשרה מתגים יוצרים יותר מאלף. אף צוות לא בודק אלף מצבים אחרי כל שינוי, ולכן ככל שיש יותר יכולות, כך גדל הסיכוי ששינוי בפינה אחת שובר משהו בפינה אחרת. זו הסיבה שבמערכות ותיקות ״כל תיקון גורר תיקון״.

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

הבלגן לא יושב בקוד — הוא יושב אצל המשתמש

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

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

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

איך מחליטים מה לא נכנס

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

שואלים כמה פעמים בחודש. פעולה יומיומית ראויה למקום מרכזי. פעולה חודשית ראויה למקום שצריך לחפש. פעולה שנתית לא ראויה לתוכנה בכלל — עדיף לעשות אותה ידנית פעם בשנה מאשר לתחזק לשמה מסך לנצח.

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

מודדים לפני שמרחיבים. אם המערכת כבר חיה, אפשר לדעת ולא לנחש: מה נפתח, מה לא נפתח, ואיפה אנשים נתקעים. הרחבה שנשענת על מדידה כמעט תמיד קטנה יותר מהרחבה שנשענת על ישיבה.

ומה עושים עם מערכת שכבר התנפחה

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

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

התוצאה מפתיעה לרוב: אותה מערכת בדיוק, אותן יכולות, ופתאום אנשים מסתדרים בלי הדרכה. לא נוסף שום דבר — פשוט הפסיק להסתיר את עצמו.

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