שאלה שהתחילה בערוץ הסלאק של הפודקאסט ABTesting התגלגלה לפוסט בלינקדאין. בקיצור נמרץ, השאלה היא "האם תוכנה לא מוסרית יכולה להיחשב כבעלת 'איכות גבוהה'?".
השאלה הזו מתכתבת עם נושא שמציק לי כבר כמה שנים טובות: בעולם התוכנה משתמשים במילה "איכות" בצורה חסרת אחריות. אולי זה כי לחלקנו יש תפקיד שהמילה "איכות" מופיעה בהגדרה שלו, או כי כולם סביבנו מדברים ככה, אבל המשמעות של המילה "איכות" באופן בו משתמשים בה היא פחות או יותר "כל מה שטוב ושום דבר ממה שרע". השימוש הזה עושה בעיקר נזקים, ובמקרים מסויימים אפילו אפשר לומר שאנחנו יורים לעצמנו ברגל. כמה המצב חמור? בעודי כותב את השורות האלה נתקלתי בפרק של Testing peers שמנסה להגדיר את המונח הזה. זו דוגמה מושלמת לאיך שארבעה אנשי מקצוע שמשקיעים לא מעט זמן בלשפר את ההבנה המקצועית שלהם פשוט מדברים שטויות. אחרי חצי שעה של קשקשת, הם עוצרים כדי להכיר בעובדה ש"בעצם, לא ממש הגדרנו מה זה איכות". תכל'ס? זה לא מפתיע - די קשה להגדיר "איכות תוכנה". זה מושג עם הגדרה מעורפלת שפשוט לא מתיישרת עם הגדרות מתחומים אחרים. התוצאה? כשמנהל אחד אומר "יש לנו בעיית איכות" הוא לא מדבר על אותו דבר כמו מנהל המוצר שרוצה להוציא "מוצר באיכות מעולה" ושתי ההגדרות האלה בטח לא מתיישבות עם ההגדרה הנפוצה "ערך עבור מישהו שאכפ לנו ממנו" (Value to someone who matters) כמו שאמר ג'יימס באך בעקבות ג'רי ויינברג, או ההגדרות שאפשר למצוא בתקן ISO "התאמה לשימוש" או "השבעת רצון הלקוחות". אם ננסה לעבוד כשיש לנו תחושה כוזבת של הסכמה, זה רק יגרום לחיכוכים אחר כך,
כל כאב הראש הזה אומר ש"שיפור האיכות במוצר" זו הכרזה ריקה מתוכן, כזו שאי אפשר לפעול לפיה. אם אכן יש רצון לשפר את "איכות" המוצר, יש בפנינו עבודה לא בהכרח קלה של הגדרת התחומים בהם נרצה להשתפר. תוך כדי התהליך הזה נגלה שחלק מהאנשים מבינים את המושג "איכות" כהפגנת מיומנות - שימוש בטכנולוגיות העדכניות באופן אלגנטי ויעיל, אחרים יסתכלו על תוצאות עסקיות, או על חווית המשתמש או על מרווח בין תקלות. כל הדברים האלה חשובים, אבל כדי לזוז קדימה, אנחנו צריכים לדבר על אותו דבר.
אבחנה מילונית נחמדה בה נתקלתי מתישהו לאורך חיי היא שמשמעות אחת למילה "איכות" היא פשוט שם אחר ל"תכונה", זה אמנם טבעי יותר באנגלית, אבל גם בעברית האמירה "יש לו מגוון איכויות" מובנת בלי להיות העתקה בוטה מדי מאנגלית. דווקא הריבוי הזה נראה לי כמו נקודת מוצא נוחה מהתסבוכת הזו. אם במקום לדבר על "איכות" נוכל לדבר על "תכונות", או אפיל על "תכונות רצויות", נוכל לשבור את הדיכוטומיה סביב "איכות גבוהה\ירודה" ולהתחיל להתמקד במה שחשוב לנו - בלבחור את האיזון שמתאים לנו.
ואם "איכות" היא כזו מילה מגונה, במה יהיה לנו נכון יותר להשתמש? כמו שרמזתי בפסקה הקודמת, אני מעדיף לדבר על מכלול התכונות הרצויות ואלו שאינן. ככה אפשר למנוע בלבול ובאשכרה להתקדם לקראת המטרה אליה אנחנו חותרים. כמובן, זה לא כזה פשוט - רשימת התכונות הזו אינה סגורה, אבל הנה כמה תכונות שנראות לי רלוונטיות במגוון מוצרים, וכל אחד יוכל להוסיף מתוך ההקשר שלו.
- נכונות: עד כמה התוכנה עושה את מה שהיא אמורה לעשות. מחשבון מס לא מגיע לסכומים לא נכונים, משחק מגיב לפקודות מהשלט בצורה הצפויה ודברים כאלה.
- עמידות: עד כמה התוכנה יכולה לתפקד לאורך זמן בעולם האמיתי, גם לנוכח משתמשים שמנסים להתקיף אותה
- סילומיות: תכל'ס, חיפשתי באינטרנט את המילה הזו, אנשים נורמלים יקראו לזה סקיילבליות או משהו כזה. עד כמה התוכנה שלנו מסוגלת לגדול כדי להכיל את סדרי הגודל הצפויים בעתיד הקרוב והבינוני.
- ביצועים:אישית אני דוחס לכאן גם את התשובה לשאלה "כמה מהר" וגם את המשאבים שהמערכת צורכת. אם זה רלוונטי, אפשר להפריד את שני אלה כדי שנוכל לשלם באחד כדי לקבל את השני.
- פרטיות: עד כמה התוכנה מגנה על מידע אנושי שהיא נחשפת אליו.
- נוחות וקלות שימוש: כמה טוב אנשים יכולים להשיג את המטרות שלהם בעזרת המוצר שלנו.
- אטרקטיביות: כמה המוצר מוצא חן בעיני המשתמשים. ג'יימס באך משתמש במושג "כריזמה" כדי לתאר את זה.
- נהירות:עד כמה קל לנו להסביר מה התוכנה שלנו עושה ועד כמה קל לנו לצפות את ההתנהגות שלה במצבים שונים.
- נראות: עד כמה אנחנו יכולים לדעת מה קורה עם המוצר שלנו בעודו רץ? האם יש לנו מידע מהשטח שאנחנו יכולים להשתמש בו כדי לשפר את המוצר? כדי לאתר בעיות?
אפשר להרחיב או לשנות את הרשימה הזו, ויש כבר מי שעשו דברים כאלה (למשל, אדגרן, אמילסון ויאנסון הרחיבו כאן את העבודה של ג'יימס באך), אבל אני רוצה להפנות לרגע את תשומת הלב לתכונה אחת שאני לא כולל בתוך התכונות שאנשים רוצים: בדיקתיות. הסיבה לכך היא שיש מעט מאוד ערך בבדיקתיות בפני עצמה. הדרך בה אני חושב על בדיקתיות היא כעל יעד עזר: זה כנראה יהיה משהו שנרצה כדי להשיג מטרה אחרת, או שזו תהיה תוצאת לוואי של תכונה קיימת (למשל, אם שיפרנו את נהירות התוכנה, ממילא שיפרנו את היכולת שלנו לבדוק אותה, ויהיה לנו קשה מאוד לשמור על רמת נכונות טובה אם המוצר שלנו יהיה קשה מאוד לבדיקה). יש תכונות נוספות שאפשר להכניס לתוך הקטגוריה הזו - כמו תחזוקתיות או יכולת הרחבה, אבל זה לגמרי עניין של מי שמרכיב את הרשימה.
חוץ מזה, יש סוג אחר של פריטים שלא כללתי ברשימה - תכונות תהליך. דברים כמו עקביות, או צפיות (כמה אנחנו יודעים לומר מה ייקח לנו כמה זמן). זה לא שהם לא חשובים, אלא שהייתי צריך למתוח את הקו איפשהו, ולכן בחרתי להתמקד בתכונות של הקוד עצמו ולא של תהליך הפיתוח. זה גם מתיישר עם התפיסה של "מוצר איכותי" - זה לא משנה מה התהליך שהוביל ליצירת מוצר כלשהו. אם הוא טוב, אז הוא טוב.
לכן, בפעם הבאה בה מישהו שואל "איך אפשר לשפר את איכות המוצר", עצרו לרגע כדי לחשוב למה בדיוק הוא מתכוון. האם יש לנו תקלות פונקציונליות? האם יש לנו בעיות אבטחה? האם לקוחות מתלוננים בהמוצר שלנו זוחל? כמובן, אין צורך (או טעם) לריב על טרמינולוגיה ולהתחיל להסביר "אל תשתמש במילה 'איכות', היא חסרת משמעות ומבלבלת", אבל מאוד כדאי לצלול טיפה יותר לעומק ולשאול שאלות מנחות כמו "מה התסמין הכי בולט של בעיות שיש לנו כרגע?" או "האם כדאי לנו להשקיע מאמץ בניסיון למצוא טעויות לפני הלקוחות או שיש דברים בוערים יותר לעשות?" אחרי שיש לנו כמה תשובות כאלה, אפשר להתחיל לעבוד. על הדרך, בזמן רגוע יותר, אפשר להתחיל לדבר על התכונות שמרכיבות "איכות" מבחינתנו.
No comments:
Post a Comment