גמישות בתוכנה
בהרבה תחומים, אולי אפילו ברובם, אנשי התוכנה נמצאים ממש בראש התור, מסתכלים לקדמה בלבן של העיניים ולא מפחדים. הרבה תחומים יכולים ללמוד מתחום התוכנה הרבה אכן עושים זאת. אבל יש גם תחומים שהמצב הפוך לגמרי. תחומים שבהם הפיגור של תעשיית התוכנה מאחורי תחומים אחרים הוא גדול עד מביך. הדוגמה הקלילה ביותר היא העמידה בזמנים, אבל דווקא בתחום הזה יש שיפור ניכר בשנים האחרונות עם התפתחות ה-Agile והכניסה שלו גם לארגונים השמרניים ביותר.
התחום שבו אנחנו רואים הרבה פחות התקדמות הוא הגמישות של תוכנות.
איפשהו באבולוציה של מוח המתכנת הוא קיבל קצת יותר מדי תסמיני דיקטטורה. לפחות 80% מהמתכנתים מוכנים מחר להוסיף את המשפט הבא למסך הפתיחה של התוכנה שלהם: “התוכנה שלי, ואתה כמשתמש תעשה מה שאני אומר לך!”. דוגמה טובה לנושא הזה היא למשל שדות החובה בטפסים או החובה להירשם כדי לבצע פעולה, או החובה ללחוץ על כפתור מסוים לסגור חלון ולא על ה-X בפינה של החלון. זה מן מצב מנטאלי שכזה, שהמתכנת מרגיש בנוח לומר למשתמש מה לעשות, איך לעשות ומתי לעשות, ואם יש לו בעיה שילך לחפש…
אבל דווקא מקום אחר של חוסר גמישות בתוכנה הוא שמעניין אותי, וזה הגמישות של תוכנה מבחינת הפיצ’רים שלה. כמעט כל התוכנות בשוק הן תוכנות שמגיעות as-is ולא יודעות להתאים עצמן לסיטואציה. ישנם 2 מצבים יחידים שאיתם רוב התוכנות ידעו להתמודד: הרשאות ורישוי. כלומר התוכנה תתנהג בהתאם לקיום או מחסור של רישיון ותראה מסכים על פי הרשאות המשתמש.
דברים שאיתם רוב התוכנות לא יודעות לעבוד:
כיבוי והפעלה של יכולות מסוימות (לכלל המשתמשים או חלקם)
פייסבוק עושה את זה כל הזמן, אבל בני התמותה שבינינו לא באמת בונים את המערכות שלנו כך שנוכל להדליק ולכבוד יכולות בקלות. מה עושים כששת”פ עם שירות מפסיק ביום בהיר? איך מתמודדים עם שינוי ב-API בהפתעה ששובר לנו יכולת? איך מתמודדים עם מחשב שאין לא רשת? מה עושים אם רוצים לבטל יכולת שהפכה ל-legacy?
רוב האפליקציות היום נכתבות כך שמה שנמצא בשרת נמצא בשליטה אבל מה שב-“client” נשאר חסר שינוי עד עדכון הגרסה. זה לא חייב להיות ככה.
עדכון חלקי
הרבה מאוד תוכנות חיות מעדכון לעדכון. כלומר יש גרסאות לאפליקציה ומעדכנים אותה מדי פעם ואז נכנסים כל השינויים. אם אני משווה את זה לדירה שלי, המצב הזה דומה לזה שאני אחכה לשיפוץ כדי להחליף את המיקרו. אפליקציה דינאמית צריכה להיות מסוגלת לעדכן חלקים בתוכה בלי להפריע למשתמש. לשפר את התפקוד שלה בלי לדרוש פעולה אקטיבית.
למה אני צריך להוריד גרסה חדשה של Angry Birds כדי לקבל שלבים חדשים? זה אבסורד. אין שום סיבה שהשלבים לא יגיעו למכשיר לי דרך האינטרנט בלי שאצטרך להוריד את כל האפליקציה…
תצוגה שונה בהתאם למצב ולא רק להרשאות
כולנו רגילים להראות או לא להראות מסכים וכפתורים בהתאם להרשאות של המשתמש, זה סטנדרטי. אבל מה לגבי שינוי תצוגה בהתאם לכמות מסכים? שינוי תפקוד ממשי בין מצב עם ובלי רשת? תמיכה בריבוי משתמשים בו זמנית.
הסתגלות למשתמש
משתמשים שונים מתנהגים שונה ואין סיבה שאפליקציות לא יתחילו להבין את זה.
למשל, אפליקציית אנדרואיד שמבינה שהמשתמש הורג כל הזמן תהליכים שנמצאים תוך כדי ריצה צריכה להבין שעדיף לה לא לבצע דברים בזמן שהמכשיר דלוק אלא בזמן “מת”. אפליקציה במכשיר עם הרבה תוכנות בקרת חבילת גלישה צריכה אוטומטית לרוץ רק על Wifi.
תשומת לב לדפוסי ההתנהגות הספציפיים של המשתמש יכולה לתת לתוכנה תחושה של “מישהו שמבין אותי”. דברים שפועלים כמו שהייתי רוצה ולא כמו שזה תמיד במחשבים.
סף הכניסה כיום בעבודה מול תוכנות מחשב נוטה להיות גבוה מדי בדיוק בגלל הסיבות האלה. יותר מדי תוכנות דורשות מאתנו להיות “משתמשים מתקדמים” עוד לפני שהתחלנו להשתמש וחבל, כי אנחנו מפספסים פה הרבה משתמשים שמתייאשים מאתנו.
תחשבו על זה, קצת גמישות לא הזיקה לאף אחד.
6 תגובות
to “גמישות בתוכנה”
2 Trackback(s)
- ספט' 1, 2011: Blog Day 2011
- ספט' 2, 2011: בלוגיק – נבחרי השבוע מהבלוגספירה הישראלית [02-09-11] | Newsgeek
מתכנת, מנהל, טכנולוג, גיק, סקרן, דעתן, ציניקן, שוער, סנובורדיסט, צולל ומסתבר שגם בלוגר.
many can talk the talk….
אני לא מסכים עם הרבה מאוד ממה שכתבת…
לדוגמה – מה ההשלכות של יכולת לכבות יכולות בקלייט? מה קורה אם הקליינט בכלל לא מחובר לרשת, או אולי יש לו תקשורת חלקית בלבד, ועם הרבה ניתוקים.. האם משתמש זדוני יכול לנצל יכולת כזו לטובתו? וכו'
כשמעלים את כל הדברים שיכולת כזו צריכה להתחשב בהם – מגלים פתאום שמאוד יקר לפתח אותה, ובעולם (לא רק עולם התוכנה), אם יכולת מסויימת לא משתלמת לי כלכלית – לא כדאי לי לפתח אותה (ובמילים אחרות, כדי לא להפסיד אתה תצטרך להפיל את הוצאת הפיתוח הנוספת על הלקוח – והאם יכולת כזו כ"כ חשובה ללקוח שהוא ירצה לשלם עליה כ"כ הרבה כסף? אני לא חושב)
כנ"ל לגבי תוכנות שמסתגלות למשתמש – שוב, עלות הפיתוח תהיה גבוהה משמעותית, ולא בטוח בכלל שללקוח אכפת עד כדי כך… קח בחשבון גם מה ההשלכות של יכולת כזו… מה אם במקרים מסויימים היא תתגלה כמבצעת משהו לא צפוי ומעצבן? או – עד שהמשתמש התרגל לבצע פעולה מסויימת, פתאום התוכנה תתחיל לעשות זאת אוטומטית, ובסופו של דבר תפתיעה את המשתמש בפעולה לא צפויה (דווקא משום שהמשתמש חרג ממנהגו בפעם מסויימת עקב צורך מסויים – ולמרות שהוא מצפה מהתוכנה להתנהג באופן מסויים – היא לא…) ביטחון (בזה שאתה יודע מה התוכנה עושה כשאתה עושה פעולה מסויימת) יותר חשוב מגמישות כזו (וכל הבלת"מים שהיא תגרום בהכרח… או שהתוכנה תשאל מיליון שאלות שיהפכו אותה ליותר מעצבנת מתוכנת CLI משנות ה-80)
עדכון חלקי הוא הפיצ'ר היחידי שאני יכול להסכים איתו – באופן חלקי… גם כאן נדרשת הוצאה נוספת כדי לספק יכולת כזו ללא בעיות (ושוב, כמה עדכונים חלקיים אחורה אתה תומך? כמו FF שאם אתה לא בגרסה הלפני אחרונה אתה תקבל עדכון מלא? או אולי משהו כמו cumulative update של IE שהולך ותופח מחודש לחודש… איך תמנע התנגשויות?), אבל כאן העלות היא נמוכה יחסית… השאלה היא שוב – עד כמה אתה באמת צריך את זה? האם למפתחים של angry birds זה אמור להיות חשוב כ"כ?
אז נכון, שלהוריד 20 מגה בשביל כמה שלבים חדשים זה קצת overkill – אבל זה כ"כ נורא בעידן שבו יש אינטרנט אלחוטי מהיר תחת כל עץ רענן? לא כ"כ (היום בבוקר עדכנתי שני משחקי angry birds, ושרדתי כדי לספר על זה)…
בקיצור – גמישות עולה הרבה כסף (להערכתי), ולא בטוח שכמשתמש בכלל שווה לי לשלם אותו
שלומי תודה על התגובה.
בוא נסכים שלא להסכים.
סתם, בוא נחפור יותר עמוק
נתחיל בנקודות הספציפיות לכל "דרישה" שלי.
היכולת לכבות פיצ'רים, לא חייבות להיות לה "השלכות" זה יכול להיות משהו פשוט כמו "אם יש רשת, תביא קובץ בגודל 2 קילובייט שמכיל אינדיקציה האם לאפשר או לא לאפשר את היכולת". ואם אתה מפחד על אבטחת מידע אז הקובץ נשמק בצורה מוצפנת על השרת שלי.
לגבי ההסתגלות למשתמש, אתה מניח מימוש גרוע, אזל בוא נניח רגע מימוש איכותי וזה בהחלט אפשרי. נגיד באפליקציית חדשות. אני לא אשאל את היוזר שום דבר ולא אשנה לו את סדר החדשות, אבל במידה ואשים לב שיש לו תבנית שתמיד הוא קודם כל מתעניין בחדשות כלכלה ואז בשאר, ברגע שיפתח את האפליקציה מיד אביא ברקע את חדשות הכלכלה, לפני הבידור. ברגע שילחץ על הכפתור אביא אותם מהזכרון ולא מהשרת המרוחק.
עדכון חלקי דורש ממני עיצוב חכם, אבל לא יותר מזה. אנחנו כבר רגילים לעשות עדכון חלקי, פשוט זה בדר"כ שמור לחלקים בשרת ולא בקליינט. כמה פעמים אתה חושב שגוגל שינו את אלגוריתם החיפוש שלהם בלי השבתה של השירות? למה שלא נעשה דברים דומים גם באפליקציה? יש לנו את היכולת להביא דברים מהשרת בלי להפריע למשתמש, למה לא להשתמש בה על מנת לשפר את החוויה שלו. אני לא מסכים איתך שזה בסדר שאתה מוריד 20 מגה בשביל כמה שלבים (מצד שני, אני די בטוח שהם מוסיפים לך שם עוד תיקונים שונים וזאת הסיבה שהם משאירים את זה ככה).
עכשיו לטענה הכללית, גמישות עולה כסף – אמת.
אם תנסה לשכנע משתמש בודד לשלם לך בגלל תוספת גמישות הוא כנראה לא יאהב את זה. הוא גם לא ירצה לשלם לך על הרבה דברים באבטחה, יציבות, שרידות, מודולריות, עיצוב נכון, ממשק יפה ועוד הרבה דברים. בצורה הזאת תסיים עם מערכת בשחור לבן שמבקשת ממנו להזין SQLים.
אבל אותו המשתמש יבחר במערכת היפה יותר, המהירה יותר, המאובטחת יותר וכו' כשהוא מוריד אותה מהמרקט.
אנחנו כל הזמן מנסים לכתוב תוכנה טובה יותר מהמתחרים אחרת נשאר מאחור. אם אתה כתבת קורא חדשות רגיל שפשוט שולף את מה שלוחצים עליו המערכת שלך תהיה א-י-ט-ית. שלי תהיה מהירה ולכן המשתמשים יבחרו אותי על פניך.
אני מאמין שמערכות גמישות הולכות לדחוק את המערכות הקשיחות החוצה ואנחנו התוכניתנים נאלץ לספק את הסחורה, או שמישהו אחר יעשה את זה.
אני מסכים (שלא להסכים)
לראייתי העולם עובד לפי העיקרון הפשוט של עלותתועלת – וזו בדיוק הסיבה שאתה לא רואה תוכנות עם פיצ'רים כאלו (או לא מספיק מוצרים – לדוגמה, לא חסרות תוכנות שכן מתעדכנות בחלקים)…
לצערי, הרבה יותר קל להשקיע ב-eye candy שתמשוך את הקונה (ולאחר הקניה הקונה "תקוע" כבר, ולא יחזיר את המוצר), מאשר בפיצ'ר שאולי יוסיף לחווית השימוש של הלקוח בצורה כזו או אחרת, אבל לא יגדיל את המכירות (לפחות לא בהתחלה)
יש גם את הסיכון שאתה תפשל – ואז בכלל אכלת אותה (בזבזת כסף, ואין לך כלום – אבל ממש כלום ביד)…
לא חסרות תוכנות שהגיעו עם פיצ'רים לעייפה, והשאירו את הלקוחות מתוסבכים עם ממשק סבוך, או כדוגמה אחרת (לממשק לומד שפישל), office xp הגיע עם תכונה שנועדה לשפר את חווית המעבר של המשתמש על התפריטים העמוסים מאוד שלו.
בלחיצה על התפריט מוצרים רק האפשרויות שהמשתמש משתמש בהם הכי הרבה, ואילו השהייה של העכבר על החלק התחתון של התפריט פותחת את שאר האפשרויות…
בפועל – המשתמש היה צריך בכל פעם לחפש את האפשרות שהוא מעוניין בה, משום שהוא לא יכל להסתמך על מיקום קבוע שלהם, דבר מתסכל בהרבה מלעבור על התפריט הארוך, אך הקבוע…
עכשיו, אני לא טוען שתוכנות כאלו לא יופיעו בסופו של דבר (ומן הסתם ידחקו תוכנות "מקובעות" הצידה ברוב הנישות) – אבל לא בקרוב… (לא יודע… נראה לי שזה יתחיל עם איזה תוכנת נסיון, מעיין proof of concept – ואח"כ יפתחו את זה לתוך מוצר קיים…. הייתי מהמר על מערכת הפעלה לפלאפון, או משהו פונדמנטלי, כמו launcher של אנרואיד… )
הסיבה שאני חושב שזה ייקח זמן, היא שזה סיכון גבוהה, דרוש רעיון ממש טוב ליישום (וקשה לי לראות שדוחפים רשתות נוירונים, או סוג של AI אחר לתוך תוכנה פשוטה.. אפילו לתוך אופיס זו טיפה הגזמה), ודרוש פה מחקר רציני (עוד כסף).. בקיצור, start up… אולי לחבר'ה של קינקט משעמם והם עובדים בדיוק על זה
יש גישה חדשה ברשת: "The Software is Wrong, not the People". ראה את הפוסט על הנושא כאן: http://joeflood.com/2011/07/13/the-software-is-wrong-not-the-people/#.Th2i-IZlYcE.tweet
אגב, לא רק בתוכנה אנחנו לא יכולים להחליט על דברים. מישהו שעל אותך איפה אתה רוצה את הכפתורים של התנור שלך? או של המיקרוגל? ההבדל הוא שתוכנה יותר גמישה, אך זה גם גורם ליותר בעיות בהמשך כי כולם רוצים לשנות אותה לטעמם.