יש לנו את הנטיה הזו, להגזים. זה נכון כאשר אנחנו רוצים להעביר מסר לילדים, לחברים, ליריבים, למפקדים, לפקודים, בעצם, למי לא?
ההגזמה נועדה כדי להדגיש משהו שאלמלא הגזמנו, היינו חשים כנראה שהוא לא מספיק מדבר בפני עצמו. אלא מה? ישנו קו מפריד, דק מאוד, כמעט בלתי נראה, שאם חוצים אותו, ההגזמה הופכת לשקר, טעות או סתם דבר-מה בלתי אפשרי. כמו להגיד משפט מסוים מיליון פעמים…
ביטוי מוגזם
זה נכון לא רק להגזמה, אלא גם לשימוש שגוי בביטויי הקצנה – כדוגמא חיובית ניקח את "שחור משחור" שמציין משהו מאוד חשוך, או "הטוב שבטובים" שמדגיש כמה טוב הוא האדם עליו מדברים, גם "ספק קל שבקלים" מיועד להראות כמה קל ועדין הוא הספק שמצאו (או לא מצאו). מנגד, קיים גם השימוש השגוי ב"צל צלו של ספק" – הבה נעשה ניסוי קטן – נעמוד בין מנורת שולחן לדלת מזכוכית אטומה למחצה ("זכוכית חלבית") – הצל שלנו יפול על הדלת, כעת נוסיף עוד מנורה שתאיר על הדלת (וגם על הצל שלנו, מבלי להעלים אותו…) – האם הצל שלנו מטיל צל נוסף מצידה השני של הדלת? האם קיים "הצל של הצל של…" (או בעברית יפה "צל צלו של…")
ביטוי שגוי נוסף הוא "רוב רובו של העם".
למה שגוי?
מתמטיקה פשוטה – אם כל העם זה 100%, רוב העם הוא כל ערך שגדול בחלקיק, קטן כרצוננו, מ-50%. ולכן במקרה כזה, "רוב רובו של העם" יהיה הרוב מאותו 50% וקצת, ואם מדובר רק על הרוב מאותם 50% וקצת, שהם לא כולם, אלא רק חלק, מאוד ייתכן שמדובר בעצם על פחות מ-50%, וזה כבר לא רוב העם!
תרחיש קיצון
שמעתי פעם הרצאה על נזק שעלול להגרם בעקבות הגזמה – דובר שם על הערכות מודיענית לתרחיש הגרוע ביותר. איני זוכר את שמו של המרצה, שאמר – התרחיש הגרוע ביותר לא יקרה לעולם. צריך להתכונן לתרחיש הגרוע ביותר האפשרי! וכדוגמא פשוטה הוא נתן את המקרה הבא – ישראל, חודש יולי, חום של 42 מעלות, החיילים צריכים להתארגן לתצפית בשטח. הם מצויידים היטב, מזון, כמות גדולה של מים, יריעות הצללה, כל הציוד הנדרש לתצפית, נשק ותחמושת. נכון שאין שום סיבה להצטייד בחליפות סערה ונעלי שלג? הצטיידות בפריטים שאין בהם צורך עלולה לפגוע ביכולת הנשיאה של פריטים חיוניים שיש בהם צורך לתרחיש האפשרי.
כולם, כולל כולם
באותה נשימה ניתן להזכיר גם את הטעות הנפוצה שאנו עושים כאשר אנו עושים הכללה (וזה כנראה קורה לנו יותר ויותר כשאנו הופכים להורים), כי אם מנסים לעשות הכללה, ויש חריג אחד, או יותר, שלא מתאימים להכללה, הצד השני יקפוץ בשמחה על ההזדמנות ויפיל לנו את כל התאוריה שבנינו, כאילו הזה זה מגדל קלפים (ואני לא מגזים…). משפט כמו "כבר שלושים פעם דיברתי עם כל המורים שלך" לא יחזיק מים יותר מכמה שניות, במיוחד אם מדובר בתחילת שנת הלימודים. באותה מידה כשהבן שלכם איבד ספר, צעצוע או עפרון, אין טעם לשאול אותו "האם חיפשת בכל מקום?" כי במקום שבו החפץ האבוד מונח כרגע, הוא עדיין לא חיפש.
אם הגעתם עד כאן ולא שאלתם את עצמכם "איך זה קשור למערכות מידע?", אז אני עונה מבלי שנשאלתי.
מערכות מידע, קטנות וגדולות, מתחילות בניתוח ואפיון, עוברות פיתוח, בדיקות והטמעה. בשתי נקודות שבעיקר בהן אני עוסק, ניתן להכשל בגלל הכללה והגזמה – האפיון והבדיקות.
בשלב האפיון – אם יש הבדלים קטנים בין תהליכים, הנטיה הטבעית היא לחשוב עליהם בצורה זהה, וכך לחסוך "כאב ראש" ולתת לשניהם את אותו פתרון. זה נכון לטפסים, למסכים, לקבצים, לטבלאות ובעצם כמעט לכל יישות שיש במערכת. צריך לדעת להבחין בין דומים שניתן לאחד ובכך לשפר תהליכים, לבין "דומים" שבעצם הם שונים ואם נאחד – נגרום נזק.
בשלב הבדיקות – הדבר הטוב ביותר – לבדוק את כל המצבים האפשריים – כמובן שזה בלתי אפשרי, ולכן צריך לתכנן בדיקות עבור כמה שיותר מקרים סבירים שיכסו את מרבית השימוש הנפוץ במערכת.
כדי לוודא שהבדיקות של שדה "מספר טלפון" הן תקינות, מספיק לבדוק שהוא לא מקבל אותיות בצירוף כלשהו – אין צורך לבדוק את כל הצירופים האפשרים של האותיות, מצד שני כן צריך לבדוק שהשדה "רחוב" יקבל את כל התוים המותרים בשם של רחוב – אבל לא את כל הצירופים האפשרים שלהם.
אם אנחנו מעסיקים מנתחי מערכות, מאפיינים או בודקים, ואנחנו שואלים אותם "האם כיסיתם את כל המקרים" או "האם בדקתם את כל האפשרויות": – כדאי שנתכונן מראש לתשובה "לא", כי כל תשובה אחרת תהיה לא אמיתית, ולכן עדיף לנסח את השאלה אחרת.
נהנתם לקרוא? לחצני השיתוף מתחת לטקסט הזה ממתינים ללחיצה שלכם.
3 מחשבות על “מיליון פעם אמרתי לך לא להגזים…”
אני לא לגמרי מסכים לגבי תכנון הבדיקות. אוסיף ואומר שלדעתי תכנון הבדיקות הוא המהותי ביותר באפיון ולמעשה מגדיר ממש את דרישות המערכת – כל בדיקה מייצגת דרישה שהמערכת צפויה לעמוד בה, מה שלא נבדק – אין דרישה שהמערכת תעמוד בו – אולי כן ואולי לא, אבל אין התחייבות. אפשר לומר שמפרט הבדיקות של מערכת הוא הקרוב הטוב ביותר לחוזה שבין המאפיין לבין המשתמש, עוד יותר מהאפיון עצמו.
ולכן, למה לא ממש מסכים – כי הצעת תרחישי בדיקות מופרכים היא דרך מצוינת לחדד את הגדרת הדרישות. כמובן, בסופו של דבר אין צורך להשאיר את כל התרחישים במפרט, אבל להעלות כאלו ולשקול אותם כדאי, וכמה שיותר – יותר טוב.
אני מקבל את התיקון, אלא שבמציאות נתקלתי לצערי בכמה מקרים שהאפיון בוצע ע"י גורם א', הפיתוח ע"י גורם ב', תכנון הבדיקות ע"י גורם ג' וביצוע הבדיקות…
לא פלא שהתוצאה היתה לפעמים ז'.