שינוי אישי

היום הוא יומי האחרון בחברת אימפרבה (Imperva), בה עבדתי ב (קצת פחות מ) שנה וחצי האחרונות.

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

בתפקידי הייתי ארכיטקט (הגדרה דיי פתוחה) ורוב התפקיד עסק בהגדרת מוצר - כיצד על המוצר להתנהג. מנהל המוצר הגדיר ״צריך להבין את פרוטוקול Kerberos״ ומשם השאלה פתוחה היכן?, כיצד?, כמה עמוק להיכנס והיכן בדיוק להשתמש במידע?, כיצד להציג למשתמש את הממצאים ומה לאפשר להם לעשות איתו וכו׳.

אימפרבה הייתה דיי חידוש בשבילי: חברה קטנה - יחסית לנסיוני (כשהגעתי היו בערך 250 בעולם וכ 170 בישראל), צומחת מהר מאוד בתחום שחדש לי (אבטחה) ושמרכז העצבים שלה בישראל. דמיינתי חברה כמו בסיפורים ששומעים בכנסים: מהירה, יעילה, חכמה ומנצחת. ובכלל, לא מצאתי אותה - אלא היא מצאה אותי (בעזרת head hunting) - דבר שרק הוסיף לעניין. 

אימפרבה היא באמת חברה מרשימה, מצליחה וצומחת מהר, אך בחיים כמו בחיים, הדברים לא עובדים כמו בסיפורים (קצת מביך אותי שבגילי ונסיוני אני עוד מגלה את זה מחדש). אימפרבה שברה לי כמה מיתוסים: גיליתי שחברה קטנה (יחסית) עלולה להיות לעיתים פחות זריזה מחברה גדולה פי 100 (183 ליתר דיוק, אם אני משווה אותה לסאפ), גיליתי שהיום-יום בחברה קטנה המגדירה את עצמה "סטארט-אפ" אינו כ"כ שונה מחברת ענק - לפחות לא כפי שחשבתי, ונחשפתי לשוק אבטחת-המידע שכללי המשחק בו שונים משוק התוכנות העסקיות.

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

בסאפ היה נתק גדול מהלקוחות. כגוף הפיתוח נתקלנו רק בלקוחות הגדולים ביותר שצורכיהם היו ספציפיים וחסרי פשרות. את הלקוחות ה״קטנים״ (חברות של ככה 3000 עובדים) והדורשניים פחות לא ראינו בכלל - וכך יצרנו מוצרים המותאמים רק לחלק קטן מהלקוחות. הלקוחות הקטנים / בינוניים פשוט לא היו על הרדאר. בסאפ ישבנו פעמים רבות מול הדילמה ״מה עושים עכשיו?״ כשעל השולחן יש 'פיל לבן' שביקש לקוח ענק אחד או איזה פיל אפרפר (חצי לבן) שמתאים לאיזו אסטרטגיה שאפתנית שהתווה מנהל בכיר בחברה - וכמעט שום-דבר באמצע.

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

מצד שני, כמו כל חברה, כמובן שאימפרבה לא הייתה נקייה מבעיות: המידע הרב והקשר ההדוק עם לקוחות לא תורגם בצורה עקבית למוצרים שהתאימו יותר ללקוחות (מסיבות כאלו ואחרות). גוף הפיתוח היה דומיננטי למדי והשפיע על המוצר - גם בצורה לא מועילה, תרבות קבלת-החלטות מאוד "שיוויונית" (דבר יפה, לכאורה) שהייתה מרכזית בחברה גרמה לחוסר-החלטיות ולפיתוחים עשירים בפשרות (X - כדי לרצות את משה, Y - כדי לרצות את דודו ו Z - על מנת לרצות את שמעון), וכמה הרגלים של חברת סטארט-אפ לבנטינית קטנטנה - הצליחו לשרוד את הצמיחה המהירה ונותרו לא-מתאימים.

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

למרות חוסר הסיפוק האישי, למדתי המון בתקופה זו והשלב הטבעי הבא היה למצוא חברה אחרת, שונה אולי אפילו יותר - שממנה אוכל ללמוד ולראות עוד. ראיתי כמה וכמה חברות - הפעם באתי מוכן והצלחתי לבחון בצורה יותר עניינית את התפקיד המוצע. דבר שנתקלתי בו לא מעט הוא ארגונים בכלי ציפיות מופרכות, החושבים שארכיטקט הוא Silver Bullet: "יש לנו בלאגן, נביא ארכיטקט שיסדר את העניינים". יש לי רתיעה לא קטנה ממקומות בהם לא היה מעולם ארכיטקט או מעולם לא ארכיטקט שהצליח בתפקידו. פעם אחת זה היה תפקיד חדש של ארכיטקט יחיד מול 50 מפתחים, פעם אחרת ארכיטקט שיושב בארץ בעוד קבוצות הפיתוח יושבות בשלוש מדינות שונות במזרח אירופה. לומר בזהירות, אלו קונסטלציות לא-מבטיחות. לפעמים דווקא ההיפך: ארכיטקט הוא סוג של לוקסוס כמעט מיותר "יש לנו פה 8 מפתחים, 2 ראשי צוותים וראש קבוצה ואנו רוצים עוד עין לבחון את התכנונים". אני פוגש את האנשים ונראה שהכל מתקתק. ראש הקבוצה הוא טכנולוגי למדי ושולט בכל הפרטים. "למה אתם צריכים אותי?" אני שואל - ולא מקבל תשובה משכנעת.

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

טוב, אז הנה אני חוזר לדרך חדשה-ישנה. אחלו לי בהצלחה :)

הו-נתונים! (Odata)

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

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

מקור: http://everythingsdynamic.blogspot.com

בשרשרת פוסטים זו אדבר על ODATA (קיצור של Open Data) שנראה כיום התקן המבטיח להחלפת נתונים בין מערכות ברשת, המבוסס על עקרונות ה REST. התקן פשוט לשימוש פשוט, אך יש בו גם כמה מורכבויות. הוא מתאים בעיקר למצבים בהם הנתונים אותם אתם חושפים הם מורכבים ו/או יש לכם מספר צרכנים עם צרכים שונים. אם אתם זקוקים ל 3 שאילתות קבועות בין 2 מערכות - ODATA יהיה overkill בשבילכם. פשוט שלחו XML (או JSON) על גבי HTTP וטפלו בכמה שגיאות נפוצות.

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

אתחיל ב Atom Publishing Protocol (או בקיצור AtomPub, נקרא גם APP - אך זהו שם מבלבל) - תקן שנוצר עבור פרסום נתונים של בלוגים או אתרי חדשות וזכה לאימוץ ע"י מערכות מתחומים שונים לחלוטין.

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

מייקרוסופט, אחת הפטרוניות המרכזיות של תקני ה WS-* (תקני ה Web Services, אשר REST בא להחליפו) ראתה את התקנים שלה נזנחים ע"י חלקים הולכים וגוברים של התעשייה ולא רצתה להשאר מחוץ לתמונה. היא יצרה תקן בשם ODATA עליו נדבר. היא הבינה שהיא הצטרפה לחגיגה קצת מאוחר. בצעד חריג, עבור מייקרוסופט, היא פתחה את התקן ושחררה ספריות בג'אווה, ג'אווהסקריפט, PHP ועוד המאפשרות להשתמש בו. יש גם דיבורים על מסירת התקן לגוף תקינה חיצוני ובלתי תלוי - אך זה עדיין לא קרה.

כמובן שיש עוד שחקנים: יאהו מנסה לקדם תקן בשם DataRSS (ללא הצלחה רבה) וה W3C מנסה לקדם תקן בשם Linked Data המבוסס על פורמט בשם RDF - אך נכון להיום התקן שתופס הכי הרבה תאוצה הוא דווקא ODATA של מיקרוסופט והוא מאומץ גם ע"י חברות אינטרנט (נטפליקס, איביי) וגם ע"י ארגוני ענן (יבמ, סאפ).


ODATA
OData הוא קיצור ל Open Data Protocol. אם מחפשים עליו חומר כדאי לשים לב ש Open Data הוא מושג רעיוני של שיתוף מידע באינטרנט. חפשו ODATA או Open+Data+Protocol כדי לקבל תוצאות טובות יותר.

OData פועל על גבי HTTP ומבוסס על עקרונות ה REST. בעצם הוא מבוסס על AtomPub שמבוסס גם על Atom וגם על REST. מבולבלים? הנה לנוחיותכם דיאגרמת Venn שתסביר את העניין:

• POX הוא הרעיון של העברת נתונים על גבי HTTP בפורמט XML (כלשהו).
• REST היא ארכיטקטורה מבוססת Resources המבוססת על POX, אך מציבה חוקים נוספים => כלומר, מקרה פרטי של POX. הסתייגות קטנה היא ש REST לא מחייב XML.
• Atom הוא פורמט מבוסס XML לתיאור Web Feed - רשימת פריטי חדשות, פוסטים בבלוג וכו'. הפורמט המקביל והמוכר קצת יותר הוא RSS.
• AtomPub הוא מימוש REST המבוסס על פורמט ה Atom שמאפשר לא רק לקרוא Web Feeds אלא גם להוסיף / לעדכן ולמחוק אותם. הוא מוסיף גילוי ועוד כמה יכולות. 
• ODATA (כמו GDATA) מבוסס על AtomPub (ומכאן גם על Atom) ומספק סט כלים עשיר יותר של כלים.

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

ODATA לוקח את הדברים צעד אחד הלאה:

• מרחיב מעט את המודל של אטום ומגדיר טיפוסים (דבר שמסייע לתקשורת עם צד השרת)
• מאפשר להשתמש ב JSON במקום XML (פורמט רזה יותר) 
• מאפשר לבצע שאילתות מורכבות על הנתונים
• מגדיר מודל אבטחה ו Authentication
• עוזר לטפל במקביליות

אציין שפרוטוקול GDATA חופף ל ODATA בהבטים רבים - אך הוא נראה פחות מגובש ומובנה.

דמיינו בנפשכם שיש לכם מספר אפליקציות ווב (או מובייל) שזקוקות לשלוף נתונים מהשרת. האם עבור כל אפליקציה תמציאו התנהגות שונה של התקשורת? מודל סנכרון או אבטחה? קונבנציה לשאילתות על הנתונים?
הרבה יותר פשוט הוא לעבוד עם קונבנציה אחידה לכל האפליקציות, כאשר כל אפליקציה, כמובן, חושפת את האובייקטים שלה והפעולות האפשריות עליהם. בדרך זו תחסכו זמן פיתוח, איתור בעיות תכנוניות, זמן למידה של התנהגות של כל אפליקציה או סתם context-switch מבלבל בין מערכת חוקים אחת לשנייה. זהו התמורה העקרית של פרוטוקולים אלו ובעיקר ODATA (מכיוון שהוא שלם יותר וסביר פחות שתזדקקו להרחיב ולהמציא מסביבו פתרונות).

באופן דיי מפתיע אין כמעט חומר על אף אחד מהפרוטוקולים האלו מלבד התיעוד הרשמי וכמה מצגות באינטרנט. לא מצאתי ספרים או תיעוד לימודי מסודר על אף אחד מהפרוטוקולים, מלבד ODATA שיש לו תיעוד לכל-היותר סביר. ייתכן ואני אספק פה מידע דיי יחודי ;-)

בפוסט ההמשך אדבר על AtomPub וכיצד אפשר להשתמש בו למימושי REST פשוטים

"זה נראה כמו סיפור הצלחה"

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

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

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

נושאים טכנולוגים (במיוחד חדשים) הם הרבה פחות מוכרים ואינטואטיביים: למשל Big Data. אם הייתי מספר לכם שיש לי אפליקציה שולחנית עם המון נתונים (אולי איזה 10GB!!) ואני רוצה להיכנס לעולם ה Big Data - ייתכן וזה היה נשמע יותר הגיוני. "למה לא?" הייתם עונים "זה תחום חם היום." - "פשוט מגניב!".

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

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

קרוב לוודאי שזה נשמע מצחיק (השתדלתי), אבל התיאור אינו שונה כ"כ ממאמצי אימוץ שונים שנתקלתי בהם: SCRUM, Object-Oriented ו test-automation - ואלו הן רק כמה דוגמאות ("to name the few").

איך אפשר להשתפר
קודם כל אני חושב שקצת הומור עצמי לא מזיק (= כלומר מודעות עצמית שאינה ביקורתית מדי).

הדגשים העיקריים מניסיוני הם אלו:

התמקדו בתוצאות - והזהרו מהתמקדות ב"חזות המקצוען"
ב SCRUM צוותים ממהרים להציג לוחות Burn-down Charts ולעשות Stand up meeting.
אם אח"כ, בישיבת ה Retrospective, רק ה Scrum Master מדבר ומחלק ציונים לכל האחרים - כנראה שמשהו התפספס (סיפור אמיתי). אם יש לכם שני ספרינטים של Design ואז שני ספרינטים של "מימוש" ואולי עוד ספירנט "בדיקות ו Stabilization" - כנראה שמשהו התפספס (המשך של אותו הסיפור).

פעם ראיתי ראש צוות שלמד Object-Oriented באמצע הקריירה (הוא בא מ Kernel C). הוא יצר מחלקה "פונקציות", מחלקה "קבועים" ומחלקה "משתנים" (והמשיך לפתח פרוצדורלית, כמובן). "הבנתי את הסיפור" הוא הכריז. "נחמד, קצת עושה סדר - אבל אני לא מבין למה עשו מ OO כזה רעש..."

אנו רוצים "להראות" כמו המקצועניים ו"להרגיש" כמו המקצוענים - ומהר, אבל בעצם יותר חשוב שנראה שיפור מדיד (ע"פ מדדים אובייקטיבים) ולבסוף נגיע לתוצאות טובות יותר מאשר השיטה הישנה. האם לחלק את הפונקציה ל class נפרד משפר את הקוד? אם לא - חשוב לשפר סגנון או לזנוח את ה OO. עדיף Waterfall מוצלח (אם יש דבר כזה...) על SCRUM רע ועדיף תכנות פרוצדורלי מסודר על פני תכנות OO מגוחך.

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

אל תלמדו מהטובים ביותר
ללמוד "מהטובים ביותר", נשמע אינטואטיבית רעיון מוצלח.
כאן כדאי להכניס למשוואה את מודל דרייפוס (שאינו קשור לאלפרד דרייפוס - הקצין היהודי שהורשע על לא עוול בכפו). מודל דרייפוס מחלק את רמת המומחיות ל5 דרגות: חסר-ניסיון עד מקצוען. הוא מבחין בכך שחסר-ניסיון ילמד טוב ביותר על ידי הנחיות טכניות צעד-צעד (למשל tutorial) בעוד בעל ניסיון ילמד טוב יותר ע"י חקר הסיבתיות לעומק ובחינת האקסיומות. יתרה מכך הוא מספר על "קללת המומחיות" - מין קללה שרובצת על כל מי שעבר כברת דרך מקצועית ואינו יכול עוד להבין מדוע וכיצד קשה לחסרי-ניסיון בתחום להבין דברים מסוימים: מדוע הם הולכים לאיבוד אם מדברים לרגע על X או בוחנים לרגע את Y. זו קללה כמעט-בלתי ניתנת להסרה.
לכן, בתור מתחילים בתחום, עדיף לכם ללמוד ממישהו בעל ניסיון מסוים מאשר ישירות מה"מאסטר".

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

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

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

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

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

הניחו לצורך בהצלחה סובייקטיבית להתמלא ולחלוף - ושמרו כוחותיכם להצלחה האובייקטיבית הנדרשת הבאה.