זהו יום הבוחר

בכלכלה יש טענה שמצב שבו יש בחירה בין שתי אפשרויות תמיד עדיף (בצורה חלשה) ממצב בו רק אחת האפשרויות זמינה.

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

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

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

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

השלמה עם חוסר הודאות

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

בספר "ממבט ראשון" מתואר כיצד בבית חולים מסוים התחילו לאבחן התקפי לב על פי 3 נתונים בלבד, במקום נתונים רבים שנהגו לבדוק לפני כן, וכתוצאה מכך שיעור הדיוק באבחנות עלה!. אני טוען שבאופן דומה בדיקה של חצי שעה בגוגל עשויה לתת תוצאות טובות יותר מבדיקה של יום שלם (בגלל ההסתמכות על חכמת ההמונים שתבליט את העיקר על פני הטפל).

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

לשאול את השאלות הנכונות

האם אנחנו בוחרים טכנולוגיה מוכחת, שנמצאת בשימוש נרחב, או בפתרון איזוטרי?

האם ניתן למצוא בתיעוד/בפורומים פתרון לבעיות? האם יש פיתוח פעיל ותהליך שיפור מתמיד?

האם הכישורים הדרושים קיימים אצלנו, או תואמים מה שניתן לגייס בשוק?

שאלות אלה יותר חשובות מהמאפיינים הטכניים שלכאורה עושים רושם יותר "מקצועי".

להפחית סיכון ולמקסם תועלת

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

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

לגדר את הסיכונים

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

באופן דומה, שימוש בGrails או JROR מאפשר תמיד לכתוב קטעי קוד JAVA במקרה שמתגלית בעיית ביצועים בקטע מסוים, לעומת הימור על פלטפורמה חדשה לחלוטין.

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

לא לעשות שטויות

האם קראתם את http://www.paulgraham.com/avg.html והשתכנעתם שפיתוח אפליקציות בשפת lisp הוא הנשק הסודי שייתן לכם יתרון על פני כל השוק שעובד בשיטות סטנדרטיות? בינתיים תנו לאחרים לבדוק אם זה נכון או לא, וכשתראו עליה בביקוש למפתחי lisp תתחילו לחשוב על זה ברצינות.

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

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

ללכת על בטוח? מסוכן מדי!

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

גם ללכת עם הקונסנזוס לא תמיד מבטיח הצלחה. בשנת  2000 יכלתם למצוא הרבה אנשי מקצוע שיגידו שphp זה פלטפורמת צעצוע לילדים, ולא מתאימה לשימושים רציניים שדורשים שימוש בטכנולוגיות מקצועיות כמו EJB2 (איקון של סרקזם).

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

מחשבה אחת על “זהו יום הבוחר

  1. פינגבק: לקראת מפגש Groovy & Grails Israel | אותיות ומספרים

כתיבת תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת / לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת / לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת / לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת / לשנות )

מתחבר ל-%s