אני יודע שתגובות ממשתמשים הן הדבר החשוב ביותר למפתח תוכנה, ועל כן הנה סיפור קטן לכל מי שכותב תוכנה למסעדות.
אתמול הלכנו, אני, החברה שלי וחבר שלה, למקס ברנר. בסוף הארוחה קיבלנו חשבון על סך 125 שקלים. החבר עשה חשבון, הגיע למסקנה שחלקו בעניין הוא 47 שקלים. המלצרית רשמה לחייב את כרטיס האשראי שלו ב-47 שקלים, ואת שלי בשאר.
כאשר מגיע הספח לחתימה, אני רואה שהספח שלי הוא על סך של 158 שקלים. לא סכום הגיוני במיוחד (להזכירכם – כלל החשבון הוא 125 שקלים). קוראים למלצרית, שמתנצלת ואומרת שהם חייבו את כרטיסי האשראי שלנו על השולחן הלא נכון בטעות. בשלב זה הסתקרנתי לראות מה יקרה. הנה האופציות האפשריות:
– לזכות את כרטיס האשראי שלי ב-80 שקלים
– לזכות את כרטיס האשראי שלי ב-158 שקלים ואז לחייב אותו ב-78 שקלים
מישהו רוצה להמר מה היתה התשובה הנכונה?
אכן, התשובה היתה לזכות את הכרטיס שלי ב-158 שקלים ולחייב אותו ב-78 שקלים, וגם לזכות את הכרטיס של החבר ב-47 שקלים ולחייב אותו באותו הסכום. שמעתם נכון.
למה? בגלל שהתוכנה שבה משתמשים מקס ברנר מבינה את המונח “חשבון לשולחן”. אין לה את היכולת להעביר חיובים משולחן לשולחן. מי שכתב את התוכנה לא חשב על האפשרות שיקלידו לא נכון את מספר השולחן. כתוצאה מכך, צריך היה לבטל את כל חיובי האשראי מהשולחן הלא נכון, כולל את אלו שחויבו בסכום הנכון.
ועל זה אני אומר, “טכנולוגיה בשירות האדם”.
לקח – הפעם הבאה שיגידו לכם ש”התוכנה לא יכולה”, תמיד תזכרו שזאת אשמת מישהו שלא חשב מספיק (או שלא היה לו מספיק משוב מהשטח) על איך ישתמשו בתוכנה. חשוב להבין שזו לא גזירה משמיים, ושזה אכן באג שימושיות בתוכנה.
ואקנח (תרתי משמע) בשאלה קיומית. אמנם מקס ברנר מביאים, בלי שאלות ובלי לעשות מהומות, פרלינים ממש טובים כפיצוי על טעויות שהם עושים, אבל למי יש מקום לאכול פרלינים בסוף ארוחה במקס ברנר?
שחר
omg
איזה פיגור !!!! #^%$#%#$
ממש טימטום
תרשו לי לסנגר על מנתח השיטות שלא הוסיף לתוכנה את האפשרות להעביר חיובים משולחן לשולחן.
קודם כל, יש לקחת בחשבון שהיתה דרך, אמנם קצת הפוכה על הפוך, אבל היתה דרך לתקן את הטעות ולהגיע בסוף בדיוק למצב הרצוי. וזה יותר טוב ממה שהיה אפשר לצפות מתוכנה טיפשה.
שנית, כידוע לכל מי שהתנסה בפיתוח תוכנה ארוכה יותר מ-1000 שורות, שהוספת פיצ’רים מעבר לצורך מסבכת את התוכנה, מוסיפה בגים, מקשה על תחזוקה, מבלבלת את המשתמשים בתוכנה (הקופאית המסכנה במסעדת מקס ברנר), ויוצרת בלגנים עוד יותר גרועים.
שלישית, אם מוסיפים פיצ’ר אז צריך לחשוב מה עושים בכל מיני מקרים פתולוגיים. למשל מה יקרה אם לא מצליחים ליצור קשר עם חברת כרטיסי האשראי אחרי ביצוע חלק מפעולות הזיכוי והחיוב, מה קורה אם כרטיס נחסם בדיוק באמצע הטרנזקציה, איך מתמודדים עם מצב שבו המסעדה חו"ח נהרסת בגלל פיגוע ע"י מחבל מתאבד בדיוק בזמן כזה, וכו’. שלא לדבר על פוטנציאל לרמאויות שונות ומשונות.
אני מצטרף למסנגרים הפעם – אני כותב עכשיו בעבודה חלק קטן מתוך שרשרת של שרתים שבסופו של דבר מעבירים מידע בין הקופסא הקטנה על השולחן במסעדה עם החריץ להעברת הכרטיס לבין השרת של הבנק שמחליט אם להסכים או לא לתנועה המבוקשת (זו העברה בנקאית לתשלום חשבונות, אפילו בלי חישובי מסגרת אשראי).
רמת דרישות הניהול ואפשרויות הפיקוח של פרוייקט כזה (למרות שמבחינה טכנית הוא טריביאלי) היא לא רגילה ויש המון גופים עם אחראויות שונות שדוחפים את מה שיש להם לאמר לתוך התערובת.
אז אני מוותר למתכנת המסכן או אפילו למי שתיכנן את מה שהמתכנת כתב, שלא רצה להוסיף תכונה שלא ברור כמה היא תהיה שימושית ולא ברור אם מחיר הסיבוך שהיא תוסיף שווה.
אני לא מסכים. אחת ממטרות התוכנה המרכזיות היא לשפר את מצב העסק, וזה כולל גם מה לקוחות חושבים על התהליך שקורה להם.
בשולחן שלנו לא היתה בעיה, בגלל שאני יודע איך מתכנתים חושבים, וצפיתי את הפעולה הזו ברגע שהמלצרים רק אמרה שהם חייבו את השולחן הלא נכון בטעות. תאר לעצמך לקוח שלא חושב על דברים כאלו:
הלקוח עכשיו גילה שביקשו מחבר שלו לשלם הרבה יותר ממה שהוא היה צריך. מה המסעדה עושה? מבקשת ממנו את כרטיס האשראי בשביל לעשות עוד שני חיובים עליו, למרות שחייבו אותו בסכום הנכון.
אני מסכים שהעברת חשבון משולחן לשולחן היא פעולה שצריכה להעשות רק ע"י מי שיודע מה הוא עושה, אבל ממילא יש תמיד רק אדם אחד שמבצע את החיובים בכרטיסי אשראי בפועל.
שחר
יש כאן קונפליקט בין שתי גישות הפוכות שכל אחת מהן משרתת את טובת הלקוח בצורה אחרת:
– פיצ’ר נוסף של העברת חיוב משולחן לשולחן יאפשר תיקון טעויות בצורה חלקה בלי שהלקוח ירגיש.
– ומאידך גיסא, הימנעות ממימוש פיצ’ר כזה גם כן משרתת את טובת הלקוח על ידי צמצום אפשרויות של בגים, רמאויות וטעויות של הקופאית שנובעות מעושר של פיצ’רים.
אליהו גולדרט בספרו "זה לא מזל" אוכל קונפליקטים כאלה לארוחת בוקר.
במקרה הנ"ל הייתי שואל:
– מהי הסבירות שסועדים יבקשו לפצל חיוב כרטיס אשראי ביניהם? (הופתעתי שיש בכלל אפשרות כזו.)
– מהי הסבירות שתיפול טעות מהסוג שקרה (חיוב שולחן לא נכון בטעות)?
– מהי הסבירות לבלבול בגלל תוכנה עם ממשק אנוש מסובך, טעויות ורמאויות אם יוסיפו אפשרות להעביר חיוב חלקי משולחן לשולחן?
– מהי העלות למוניטין של העסק בכל אחת מהאפשרויות הנ"ל?
הרגשת הבטן שלי היא, כאמור, לטובת תוכנה פשוטה יותר עם פחות אפשרויות לבגים ורמאויות.
יש פה עוד עניין שג’ואל ספולסקי מדבר עליו כאן:
http://www.joelonsoftware.com/printerFriendly/articles/fog0000000014.html
לא בטוח שזה שווה את הכסף שצריך להשקיע בתיקון הבאג הזה.
והם לא נתנו "דוגי-בג" לפרלינים?
זו כבר התאכזרות, אם לא.
זה בסדר, החבר של החברה שלי הוא בעל קיבולת בלתי מוגבלת לשוקולד. הוא אכל את רובם.
שחר
אה ובקשר לפרלינים – אם אין אצלך מקום תמיד אפשר לתת לשכן…:)
ראה תגובתי למרגי.
שחר
עכשיו זו התאכזרות לאוזי
(אמר והלך לקנות שוקולדים של מקס ברנר במחיר גבוה פי שלוש, איזה מזל שיש חנויות שלהם בעיר שלי)