בית קברות לסטארטאפים: The Chasm

.lior_comment { background-color: #fff2cc; border: 1px solid #BFBFBF; margin: 4px 0; padding: 4px; }

דיסקליימר: ה Chasm מכה גם במוצרים בחברות גדולות. הכותרת היא לשם הקריאות בלבד.

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

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

כיצד ניתן להסביר סירוב שכזה?!
באים אל החוואי ונותנים לו מתנה משמיים – אך הוא מסרב?!

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

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

מחזור קבלת טכנולוגיות (Technology Adoption Lifecycle)
סדרת המחקרים הניבה תוצאות עקביות[1] וכך החוקרים הצליחו לבנות מודל שמתאר בצורה טובה את המתרחש.
המודל חילק את החוואים לחמש קבוצות של אנשים, בהיבט קבלה של טכנולוגיה חדשה:

סוגי הלקוחות בהיבט האימוץ של טכנולוגיה חדשה. מקור: \"The Diffusion Process\", Special Report No. 18 (Agriculture Extension Service, Iowa State College) pages: 56–77
באפון קלאסי, האנשים הראשונים לאמץ טכנולוגיה חדשה הם אלו שמעריכים אותה בזכות מה שהיא.

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

לרוב אלו הם החוואים עשירים, מבוססים, שכבר הוכיחו את עצמם ולא נמצאים בתחרות יום-יומית. הם מחפשים את ה\"שלב הבא\" וטכנולוגיה חדשה יכולה להיות ייתרון משמעותי לעסק או ליוקרה שלהם – גם אם התוצאה היא לא מיידית. על מנת לתמוך בחזון שהם מאמינים בו, הם מוכנים לספוג חוסר נוחות או עלויות גבוהות. מרחב הנשימה שלהם הוא ארוך.
אימוץ הטכנולוגיה מתחיל באנשים אלה, אשר ישפיעו על סביבתם ויעזרו לכם לדחוף את הטכנולוגיה קדימה.
אחד המוצרים שעבדתי עליהם, לאחר שנה וחצי של עבודה קשה, נחשף לקבוצה של 14 לקוחות פוטנציאלים. הלקוחות הביעו עניין נמוך במוצר, כפי שהוצג, והפרויקט נסגר.
כשנה מאוחר יותר, פנה אלינו ביוזמתו אחד הלקוחות שהשתתפו ב Pilot ודרש שנחזיר את המוצר לחיים: \"זו תהיה הצלחה אדירה\", הוא טען. \"איך אתה יודע?\" שאלנו, \"התגובות עד כה היו צוננות למדי\".
מסתבר שהלקוח לקח את הפרויקט שלנו והטמיע אותו אצלו בהצלחה. על מנת לבצע שינויים בקוד המפתחים שלו עשו Decompile לקוד שלנו והכניסו שינויים (הפרה של הרישיון, אך לאף אחד לא היה אכפת). סירבנו להצעה. ההנהלה הייתה משוכנעת שאין הצדקה עסקית להמשיך בפרויקט.

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

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

אחוז גדול יותר של החוואים, 10-15% מהם, נקרא מובילי שוק (Early Adopters). אלו הם לרוב החוואים משכילים, דינאמיים ופתוחים לשינויים. הוא יהיה מוכן לנסות ולאמץ את הטכנולוגיה החדשה ולראות האם היא מצליחה. הוא נהנה מהערך החברתי בלהיות חדשן ו״לפני כולם״, אבל המסירות שלו לרעיון היא פחותה משל החוואי החדשן. לרוב הוא יצפה למחיר נמוך או הטבות תמורת נכונותו ״להתגלח״ על המוצר החדש והוא יסכים לקבל מוצר לא כל-כך בשל.

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

הקבוצה הבאה היא הרוב, או הרוב המאוחר (Late Majority), גם הם כשליש החוואים  – אך הם שמרנים יותר וילכו רק על \"עסקה בטוחה\". הם יגיעו אל הטכנולוגיה \"כי לכולם כבר יש\", בשלב שיהיה ברור שהטכנולוגיה בשלה ועובדת היטב.
הם אלו שיסכימו לחכות שנה-שנתיים, עד שהטכנולוגיה תתייצב או עד שהמחירים יירדו. הם רוצים את התוצאות עם מינימום סיכון, הרפתקאות או עלויות. הם מצפים לשירות טוב, טכנולוגיה בוגרת, ובעצם כל מה שניתן לבקש.
בעולם הטכנולוגיה, זהו סוג האנשים שמחכים ל״אייפד 3״ על מנת לקנות את הטאבלט הראשון שלהם, אחרי שברור להם שהמוצר כבר בשל למדי וזו \"קנייה בטוחה\".

הנגררים (Laggards או Non adopters), הם שאר האוכלוסיה. הם פשוט לא רוצים טכנולוגיה חדשה. חלק זה של החוואים כולל אוכלוסיה מבוגרת יותר ומשכילה פחות. הם ישארו עם הטכנולוגיה ישנה עד שיכריחו אותם להחליף, ואם לא יכריחו אותם – הם ישארו עם \"הטכנולוגיה הישנה והטובה\". אנשי המכירות לומדים לזהות סוג זה של אנשים ולדלג עליהם – הם לא שווים את מאמץ-המכירה.
בעולם הטכנולוגיה, אלו הם האנשים שעדיין מסתובבים עם טלפון ישן של נקייה למרות שאין להם בעיה כלכלית להחליף לטלפון חדש יותר. הטלפון יפסיק לעבוד – ואולי הם יעברו לנוקיה דור-שני.

החלוקה לסוגי חוואים מתיישבת יפה עם גרף \"פעמון\" גאוסיאני – ולא במקרה.

רגע של עברית
אני יודע שיש כמה קוראים של הבלוג שהם דקדקנים בשפה העברית. בזמן הכתיבה תפסתי את עצמי בחוסר ידיעה: מה ההבדל בין חקלאי לחוואי? באנגלית נראה שהמלה Farmer מתייחסת לשני המקרים. עד כה כתבתי את הפוסט בעזרת \"חוואי\" מכיוון שאמרתי לעצמי \"Farmer קשור ל Farm שזו חווה –> חוואי\". הייתי מעדיף להשתמש במילה \"חקלאי\", אך החלטתי לדייק.

באינטרנט, מקור אחד ענה לשאלתה של מיכל 9929 בנושא:

חוואי הוא כזה שישלו חווה עם חיות כמו פרות ועיזות תרנגולות וכלזה…וחקלאי הוא כזה שמגדל דברים של חקלאות כגון תירס וכל זה מקווה שעזרתי ( ;

מקור אחר, גרס:

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

ההסבר נשמע לי משכיל והגיוני – ולכן אסתפק בזה.


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

על פניו נראית התפלגות הלקוחות כגאוסיאן או \"פעמון\". (אקרא להם מעתה לקוחות, ולא חוואים או משתמשים[3]). כשאתם מתחילים למכור מוצר או שירות חדש סביר שתתקלו קודם בלקוחות חדשניים, אח\"כ לקוחות \"מובילי שוק\" וכו\'. המעבר נראה רציף – אך הוא לא מתאר את המצב בפועל.

הקרדיט לתיקון מגיע לבחור בשם ג\'פרי מור שכתב את הספר עליו ביססתי את הפוסט. מור זיהה תכונה חשובה שהייתה חסרה במודל המקורי: סדקים ב\"פעמון\".
מור הבחין שה\"התקדמות\" בזרם הלקוחות של המסכימים / מבקשים לקנות את המוצר אינו רציף ואינו קורה בעצמו: בין כל קבוצה לקבוצה של לקוחות יש פער ציפיות שמקשה על המעבר לקבוצת הלקוחות הבאה.

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

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

הסדק הזה קיבל כבר שם היאה לכבודו: \"התהום\", The Chasm.

Liberty Bell – סמל אמריקאי ואולי מקור ההשראה של מור לתיאור \"הפעמון הסדוק\". מקור: http://etc.usf.edu

The Chasm
כמו שכל סטארט-אפ בימנו מכיר את חשיבות תזרים-המזומנים, שאם יעצר גם הסארט-אפ ייחדל מלפעול, חשוב לא פחות הוא \"תזרים הלקוחות\" – היכולת לפנות לעוד ועוד לקוחות ולצמוח.
אז איך זה קורה? האם יום אחד לקוחות מפסיקים להגיע? האם המכירות נופלות מ 100 ל 0 ביום שהגענו אל התהום? האם יש שלט גדול \"תהום\" שיסביר מה קרה?

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

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

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

כשאתם \"מקשיבים ללקוח\", \"יוצרים קשר עם הלקוח\", \"עושים מה שהלקוח רוצה\" או \"עושים מה שהלקוח צריך – לא מה שהוא מבקש\" – כל אלה הם דברים טובים מאוד ונכונים! בכל זאת, כדאי לתת להם הקשר חשוב: באיזה סוג של לקוח מדובר?


לקוחות \"חדשנים\" הם תמיכה הכרחית להצלחה, הם גם ישתפו פעולה נהדר – יותר מכל סוג-לקוח אחר. הם מסוג הלקוחות שיסכימו לטוס אליכם (ולא להיפך) יתעניינו מאוד בפרטים ויפרגנו. בהיבט מסוים הם מאוד נוחים! למה בכלל להתעסק עם לקוחות אחרים?!
מצד שני הם יכולים לקחת אתכם למחוזות רחוקים של חזון ולגרום לכם להתבזר. אם תבנו את המוצר שלכם, פרט לפרט ע\"פ ההמלצה שלהם – קרוב לוודאי שאתם מגבילים את עצמכם ללקוחות חדשניים בלבד – ומפספסים את כל שאר הלקוחות.
אני חושב עליהם כמעריצי אלוויס פרסלי מושבעים: יש להם הרבה אנרגיה, הרבה יכולת ורצון, אך אם תקשיבו לעיצותיהם ללא ביקורת, ותייצרו סמארטפון חדש עם פאות של \"המלך\" ונצנצים, שמגיע Built-In רק עם שירים של \"המלך\" – אתם מצמצמים את עצמכם לקהל מאוד מסוים!

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

Crossing The Chasm
בעוד קצת אינטואיציה ומזל יכולים לעזור לכם לעבור את ה\"סדקים\" האחרים, המעבר את התהום דורש טקטיקה מדויקת, תכנון והבנה. הפעם בין \"מובילי השוק\" ל\"early majority\" הוא פשוט גדול מדי מכדי שהמעבר יתרחש מעצמו.

ישנה דרך מומלצת לחציית התהום. נוסחה. קל לדבר וקשה לעשות. היא הולכת כך:
הבעיה הגדולה שלכם היא שלקוחות \"Early Majority\" ירצו references. דוגמאות ללקוחות, עדיף שדומים להם בגודל ובתעשייה בה הם עוסקים (לדוגמה כימיה, רו\"ח, חברות תעופה וכו\'), שימליצו ויספרו על ההצלחה. לקוחות ה Reference נדרשים להיות \"Early Majority\" בעצמם. כיצד ניתן לפרוץ את המעגל ולהגיע ללקוחות ה Reference הראשונים?

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

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

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

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

איש מכירות מחברת ABC (השם שמור עמי) סיפר לי את הסיפור הבא:

\"כאשר היה נדמה לנו שלקוח גדול מקשיב לנו ואנו קרובים להשיג עסקה גדולה ראשונה, הסתבר לנו שהמתחרה DEF, הגדול מאיתנו פי כמה, כבר בפנים וההחלטה ללכת איתו היא כמעט סגורה. ידענו מפעמים קודמות שהם מודעים אלינו והם יעשו כמעט הכל כדי לחסום אותנו מלהשיג עסקאות גדולות – ברור גם למה. אלו References שחסרים לנו על מנת לחדור לעסקאות השמנות. פנינו לאיש הקשר שלנו אצל הלקוח וביקשנו שיכתוב ל DEF שמעכבים בעוד שבועיים את העסקה – מכיוון שבודקים גם את הפתרון שלנו. בהתחלה הוא סירב, למה לסכן עסקה טובה? הבטחנו לו שהוא יראה הפתעה – שממנה ילמד משהו חשוב שישנה את דעתו. הוא חיבב אותנו והסכים לנסות. כשאנשי המכירות של DEF שמעו שהעסקה מעוכבת בשבוע אחד בלבד על מנת לבדוק גם את המוצר שלנו – הם הגיבו באגרסיביות רבה והניחו מייד על השולחן הצעה שלא ניתן לסרב לה: הנחה מיידית של 50%. אנחנו כבר היינו מוכנים עם הסבר משלנו לתופעה: אתם רואים? הם כל-כך מפחדים. הם יודעים שהמוצר שלנו פי-אלף יותר טוב וברגע שיש טיפה תחרות – נופלים להם המכנסיים במקום. זכינו בעסקה.\"

פלישה רצינית: נורמנדי.

תהייה אחרונה
האם אנחנו באמת יכולים להיות מתויגים לאחת מ 5 קבוצות של לקוחות בעלי התנהגות צפויה? האם זה כ\"כ פשוט? – שאלה זו ניקרה בי במשך זמן מה. ובכן, אני לא חוקר ולא נראה לי שאוכל לענות על שאלה זו בצורה מדעית ומדויקת, אולם בכל זאת שמתי לב שאני מתאים לקבוצת לקוחות אחרת בתחומים שונים.
עד לפני כמה חודשים, הסתובבתי עם טלפון נוקיה ישן. עכשיו יש לי אייפון ואני נהנה ממנו מאוד. \"שורף\" ג\'יגה ויותר בחודש. בבית יש לי טלויזית CRT, איכותית אמנם אך ישנה (אופס! לא פוליטיקלי קורקט – אל תגלו לאף אחד!) – ואין לי שום תכנית להחליף לפלסמה או LED. האם אני Laggard מושבע?

מצד שני ספרים אני קונה שבוע אחרי שהם יוצאים. היו תקופות שהייתי משוטט בחנויות ורק סורק את הספרים החדשים למצוא כאלו שנראים לי. יצא לי כבר לקרוא כמה ספרים (בעיקר מקצועיים) ב beta או MEAP ואפילו לתרום ל Errata או לדיונים בפורום. אני אוהב להמליץ לאנשים אחרים על ספרים ואני מקבל אי-החזרה ארעית כמחיר סביר להנאה זו. האם אני Innovator?

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

אני אשמח לשמוע תובנות נוספות בנושא.

———–

[1] התוצאות של חלק מהמחקרים לימדו שבזרעים החדשים היו כמה אלמנטים של Disruption (או הפרעה) במימד החברתי שהקשה על האימוץ שלה. למשל: הטכנולוגיה החדשה הייתה רגישה פחות למקצועיות החוואי עצמו – וכך החוואים מעולים לא יהיו בולטים יותר מחבריהם הפחות מוכשרים. למובילי דעת הקהל בקרב החוואים הייתה סיבה ראציונלית לחלוטין להתנגד. Disruption הוא נושא בפני עצמו בתחום אימוץ הטכנולוגיות / מוצרים טכנולוגיים.

[2] הדבר המדהים היה שעל מנת לפתור את 2 התלונות העיקריות נדרש כחודש עבודה. במקרה אחד היה צריך פשוט לבטל מנגנון מורכב שפותח במשך כמה חודשים.
הארגון בו עבדתי החליט שהוא הגיע לקץ ההשקעה האפשרית מבחינתו במוצר ולא היה מוכן להשקיע חודש אחד נוסף. אני חושב שזו הייתה נקודה המשמעותית בחיי שהבנתי עד כמה מתודולוגיות Agile יכולות לתרום לפיתוח תוכנה: שנה וחצי ישבנו בחדרי חדרים, מכונסים בעצמנו כמו תלמידים בישיבה חרדית, והגינו במוחינו מה הלקוחות \"צריכים ורוצים\". שנה וחצי לא החלפנו מילה אחת עם אף לקוח פוטנציאלי, שלא לומר אמיתי. מנהל המוצר הגיע מהתחום ולכולם היה ביטחון שהוא יודע מספיק טוב \"מה צריך לעשות\".

[3] \"המכנה המשותף לתעשיית הסמים ולתעשיית התוכנה הוא שבשניהם מכנים את הצרכן בשם \'משתמש\'\" – ציין איתמר טאייר. אהבתי!

הכר את המשתמש: איש ה-IT

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

האמהות שלנו והחברים לרוב יחשבו שהמוצר שלנו פשוט מצויין, מעולה ומג-ניב, אולם אם לא נקלע לטעם ולצרכים של אנשים אחרים – המוצר יישאר לכל היותר… כלי משפחתי.

על ליצור מוצר מצליח אנו צריכים לספק את צורכיהם ורצונתיהם של המשתמשים ו / או הלקוחות שלנו.

רגע… \"המשתמשים ו / או הלקוחות שלנו\"? מה ההבדל? האם זה לא בדיוק אותו הדבר?

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

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

המשתמשים / הלקוחות של עולם התוכנה

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

10 שנים הם לא מעט זמן…

אני יכול לומר שאני מבין שפות תכנות בצורה טובה, מבין בסיסי נתונים, מבין פרוטוקולי רשת, מבין בדפדפנים ו Web, מבין אפילו קצת בעיצוב ממשק-משתמש… אבל האם אני יכול לומר שאני באמת מבין את המשתמשים עבורם כתבתי כל-כך הרבה קוד?!

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

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

אבל מה עם אנשי IT? האם יש ספר שמתאר אותם? האם יש tutorials ופורומים שעוסקים בהם באינטרנט? – לא משהו רציני שאני מצאתי.

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

אם חלק כ\"כ חשוב בידע הנדרש להצלחת המערכות שלנו אינו מתועד וזמין – כיצד אנו אמורים להצליח? ובכן – זה לא דבר קל. כנראה שהדרך לידע החשוב הזה היא ארוכה, לא נוחה ולא-מתועדת.

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

מחלקת ה IT
Disclaimer: למרות שהמידע מוצג בצורה מובנה, הוא מבוסס על התרשמויות אישיות ולא ידע ממוסד ומוסדר.

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

  • מחלקת רשת (Networking) – אחראים לעיתים קרובות גם על הטלפוניה.
  • מחלקת שרתים (או System).
  • מחלקת DB (אותם DBA מפורסמים) – לעיתים היא חלק ממחלקת ה System.
  • מחלקת תמיכה (או Help Desk, לעיתים גם נקרא PC).
  • מחלקת הדרכה – לעיתים היא חלק ממחלקת התמיכה.
  • מחלקת אבטחת המידע (Security).
  • מחלקת הפיתוח של מחלקת ה IT – מפתחים שכותבים כלים ותוכנות עבור הארגון עצמו.
  • מחלקת תוכן (אלו שמנהלים את אתר האינטרנט, הפורטל הארגוני וכו\') – לעיתים היא חלק ממחלקת הפיתוח.
בחברת קטנה ייתכן ויש רק שני עובדי IT שכל אחד – מכסה אחריות של ארבע מהמחלקות המתוארות למעלה. בחברה בינונית כבר יהיו, נאמר, 4 אנשים ויותר וכל איש יהיה רק מחלקה או שתיים. בחברות גדולות כל מחלקה יכולה להכיל עשרות עובדים. פעם היה לנו לקוח עם מחלקת פיתוח של ה IT עם כ-100 מפתחים – כח פיתוח גדול משל הארגון שלנו. מדובר היה באחת החברות הגדולות בעולם.
למרות השוני בגודל – המבנה העקרוני דיי נשמר (עם וריאציות כאלו או אחרות).

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

בראש אירגון ה IT יושב ה CIO הרי הוא Chief Information Officer – סמנכ\"ל בחברה (או Board Member – באירגונים בהם סמנכ\"ל הוא דרג ביניים).
רגע של עברית: בישראל השם המקובל הוא מנמ\"ר – מנהל מערכות מידע ראשי. למרות שהשם נשמע כמו שם של רכב צבאי – הוא תפס והוא מקובל למדי.
ה CIO מנהל גם את המחלקות התפעוליות של ה IT – שמטפלות בשוטף (אלו שהזכרתי למעלה), אך גם יהיו תחתיו יחידות של תכנון אסטרטגי וניהול פרוייקטים חדשים. ה CIO – כך נראה, עסוק יותר בניהול הפרוייקטים הבאים מאשר מעורבות בשוטף. החלוקה דומה לחלוקה בצה\"ל בו הרמטכ\"ל עסוק בנושאים אסטרטגיים וסגן אחראי על הניהול השוטף של הצבא.

ה CIO הוא הבחור שיצטרף לישיבות פתיחה / סיכום של פרוייקטים – יגיד כמה מילים טובות ויחייך מאוזן-לאוזן. סוג של סימן \"אני בעד הפרוייקט הזה\" – אבל הוא לא יתעסק בפרטים.
הוא ייתעניין יותר בסיפורים של איש השיווק שלכם על מה שהמערכת שלכם יכולה לעשות אולי תעשה בעתיד (אם תוסיפו כמה שנות פיתוח ותתרחש פריצת דרך משמעותית בתחום הבינה המלאכותית).

את מחלקת האבטחה מנהל לרוב ה CISO הרי הוא ה Chief Information Security Office – שמדווח ישירות ל CIO. מחלקת האבטחה מדווחת ל CIO ואינה כפופה לגוף התפעולי ה IT. הקשר הזה כנראה אמור להבטיח את עצמאותה של מחלקת אבטחת המידע – עליו נדבר עוד קצת בהמשך.
גם מחלקת הפיתוח רחוקה יותר מהשוטף של ארגון ה IT וקרובה יותר לחלק של תכנון הפרוייקטים (איזור ה CIO).

מקומה של מחלקת ה IT באירגון

באירגונים מסורתיים (תעשייה, פיננסים, שירותים) מחלקת ה IT עשויה להתפס בתחילה במחלקה יוקרתית. \"היי טק\" או \"טכנולוגיה\" הן מילים גבוהות – האם \"ההייטק\" היוקרתי גורם למחלקת ה IT להיות יוקרתית יותר בתוך האירגון? הרושם שלי שבעצם ההפך הוא הנכון: מערכות מחשוב הן מורכבות ביותר – ויש בהן הרבה תקלות. דברים שנתפסים כפשוטים \"תאחדו את שני שרתי ה Exchange Server\" עלולים להיות פרוייקטים של שנים – ורק מי שנכנס לפרטים הטכניים יכול להבין מדוע.

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

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

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

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

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

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

איש סיסטם בעבודה. מקור: eqslcc.blogspot.com


מבט קרוב על כמה ממחלקות ה IT השונות

מחלקת הרשת – כוללת לרוב אנשים טכניים למדי שיש להם את הזמן, היכולת והחובה להתעמק בציוד ופרוטוקולי הרשת לפרטי פרטים. הם רגילים לעבוד בסקריפטים וכלי Command Line ללא ממשק גרפי – זה הסטדרט בכלים שהם מתעסקים בהם. הם מרוכזים בנישה שלהם ולא נוטים להראות עניין בעולם החיצון.
התקשורת איתם היא לרוב \"תן לנו את הגדרות ה-[1]QOS של שירותי הרשת שאתה צריך (בשפה שאנחנו מכירים) – ואנחנו נספק אותם (ע\"פ הדרך שאנחנו רגילים למדוד)\".
הרושם הכללי שלי הוא שאנשי רשתות אינם נוטים לנסות ולהבין את הפרוייקט הכולל – ומתמקדים בעיקר בחלק שלהם.

מחלקת השרתים / System נתפסת לעיתים כדומה למחלקת הרשת – כצד השני שמתעסק בשרתים – אך השוני הוא ניכר. בעוד אנשי הרשת נוטים לעבוד עם ציוד של ספק עיקרי אחד[2] (סיסקו?) ומגוון קטן יחסית של ציוד ממקורות אחרים, אנשי ה System צריכים להתמודד עם כמות רבה של מערכות מורכבות שלא דומות בכלל אחת לשנייה. בארגונים גדולים (בקנה מידה עולמי) קורה שאיש סיסטם יחיד יכול להתמקצע במערכת בודדת, אך ברוב המקרים איש הסיסטם יאלץ להתמודד עם מספר לא-מבוטל של מערכות של ספקים שונים.
מערכות התוכנה דורשות תחזוקה לא מעטה (הגדרת משתמשים, שינויים בהגדרות ע\"פ צרכים עסקיים, התקנות ועדכונים). כאשר כל מערכת מתנהגת בצורה שונה, מציגה מערכת מושגים שונה ועקרונות פעולה שונים – התפקיד של תחזוקה של מספק מערכות הופך למורכב למדי. התוצאה היא לחץ רב שמופעל על אנשי הסיסטם, שגורם לעיתים רבות לעבודה ב\"מוד\" של כיבוי-שריפות: אנשי הסיסטם לא יצליחו להתעמק במערכת ורק ינסו לגרום לבעיה \"להעלם\".

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

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

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

יש כמה דרכי התמודדות מקובלות עם המורכביות האלו:
1. רכישת חוזרת של תוכנה מספקים קיימים – כך שכניסה למערכות החדשות תהיה קלה יותר והתמיכה תהיה מרכזית.
2. חיבור המערכות השונות, עד כמה שניתן, למערכת ניהול מרכזית ממנה יוכל איש הסיסטם לתפעל באופי מרכזי את כל המערכות. כנראה שהתשובה לשאלה \"איזה ממשק משתמש אתה רוצה?\" תהיה \"HP Open View. אני מעדיף מרגע ההתקנה לא להתחבר למערכת שלכם יותר איי פעם\".
3. Outsourcing של ניהול המערכות הפחות קריטיות לארגון. כמה מערכות פחות להתעסק איתן הם אוויר לנשימה עבור אנשי הסיסטם העמוסים במטלות. הצלחת הענן ושירותי On-Demand הם ביטוי ישיר למגמה זו. לעיתים ארגונים ישכרו יועץ חיצוני על מנת לבצע Configuration של מערכת מורכבת – הם יעדיפו לשלם על מנת לחסוך לאנשים שלהם את הצורך ללמוד לעומק עוד מערכת נוספת.
4. אוטומציה (בעזרת Scripting או ממשקים נוסח JMX) עד כמה שאפר למערכות השונות כך שלא יהיה צורך להתעסק איתן.

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

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

מחלקת ה Security
\"אם אנשי הרשת לא מסתכלים מעבר למשבצת שלהם, ואנשי הסיסטם מנסים לעזור, אבל מצלחים בקושי – אנשי האבטחה הם שם בכדי להפריע!!\"

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

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

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

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

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

[1] Quality Of Service – הגדרות מספריות לזמינות ומהירות הרשת בפרמטרים שונים. למרות שההגדרות אמורות להיות חד-חד ערכיות – הן ניתנות לפירושים שונים (\"אני דיברתי על Latency כשאין פעילות אחרת ברשת\").

[2] בציוד רשת יש משמעות רבה לרכישה מספק אחד – הציוד עובד ביחד בצורה משמעותית טובה יותר.

בורסת הטכנולוגיה: איך מחליטים על השקעה בתחום לא מוכר?

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

כיצד אנו בוחרים ספריה/טכנולוגיה/מתודולוגיה?
אנשים טכנולוגיים נוטים להתבונן על הטכנולוגיה בפרטים:
  • איך ה Design או הארכיטקטורה של הספריה?
  • באיזו שפת תכנות היא כתובה? (חשוב!) \"מה, בBoo? כנראה שאלו חבר\'ה מביני עניין! אני כבר מחבב אותם\"
  • איך נראים ה API?
  • כמה קצר ומרשים ה tutorial שאיתו אוכל להתחיל ולהתשמש בה (טעות אנושית נפוצה היא להניח שאם אפשר להרים Hello World בפחות מדקה, אנו עתידים לשבוע נחת מהספרייה…)
  • לבדוק את ה Roadmap ופ\'יצרים עתידיים. 

    מתכנתים קצת יותר מנוסים יביטו על עוד כמה הבטים:
    • תיעוד ארכיטקטורה – כמה ברור מה קורה בפנים ואיך הספריה עובדת?
    • adoption וה community – האם נראה שהספריה תתמך עוד זמן רב או שהיא בנסיגה? כמה פעילות יש בפורומים?
    • בחינת רשימת הבאגים במערכת ניהול הבאגים (אם היא ציבורית) ולקבל מושג על רמת האיכות ואיזה סוג בעיות יש.
    • בחינת ה release notes האחרונים, כמה הם תכופים (כמה מהר נקבל עדכונים חשובים) וחיפוש אחר סימנים מעניינים. לדוגמא: ספריית client side שמדווחת על תמיכה ב windows 7 מעלה סימן שאלה על התלות ולמה רק עכשיו? דיווח על תיקון באג ב authentication ב SAML2 על Firefox יכול להיות סימן לבגרות. הכל כמובן תלוי ב context.
    מנהלים, אולי כי יש להם פחות זמן להשקיע ואולי בגלל שהם לא רוצים להכנס לפרטים, ישתמשו בכלים ניהוליים:
    • לשלוח מישהו שעליו סומכים עליו לעשות את הבדיקה (עדיף שזה יהיה אדם מנוסה)
    • שימוש בקשרים להשגת references חיים (כלומר מישהו שאפשר לתשאל אותו) – חשוב להתייחס לכל פידבק בהקשר הנכון.
    • Benchmarking – \"אתה אומר ש Haskell שפה נהדרת, אך אף אחת מהחברות בתחום שלנו לא עובדת בה. זה גם נכון לחברות בתחומים דומים\".
      \"היא שפה נהדרת\" יענה המתכנת הנבון והצעיר \"אתה יודע כמה בינוניות יש בתעשיה – זה שאחרים לא משתמשים בה לא אומר שומדבר\".
      \"לא נראה לי\" – סביר שתהיה החלטת המנהל, וכנראה בצדק [א]. הוא לא יודע כלום על Haskell, אבל מגמת התעשייה מכילה ידע שאלה האדם הבודד יכול להגיע רק לאחר חודשים ארוכים. אי הליכה בתלם משמעותה גם פחות Eco-System לעבוד איתו, כמובן (אפרט יותר בפוסט המשך).
    • חיפוש ובחינת נקודות מפתח מנחות – מה מאפיין את שפת Haskell? משולבת בעיקר באוניברסיטאות? (נאמר, אני לא יודע באמת). מה ניתן ללמוד מכך – מה מאפיין אוניברסיטאות?
    בחיינו היום-יומיים, יש נושאים שאנו מבינים בהם יותר (או יכולים להבין בהם), למשל –  קניית טלויזיה חדשה. אנו נוטים לפעול בנושאים אלו יותר כמו מפתחים. בנושאים שבהם אין לנו באמת סיכוי להבין בהם לעומק, למשל, השקעה בורסאית בחברות – אנו נוטים לפעול יותר כמו כמנהלים.
    בעיית חוסר היכולת להכנס לפרטים אינה חדשה. איזה פתרון יצר עולם ההשקעות לחוסר ההבנה של לקוחותיו? – אנליסטים! אותם מומחים שאומרים לנו \"לקנות לקנות\" או \"למכור למכור\" ואפילו קצת השתכללו עם השנים ועתה הם קובעים מחיר יעד למניה \"לאחר הכניסה לשוק הזימבבואי, על מנת לשקף את שווי השוק האמיתי, מניית נייס צריכה להגיע למחיר של 23 דולר ו 14 סנט בדיוק!\" [ב].
    אנליסטים של עולם התוכנה
    כמו שלשוק המניות יש אנליסטים שמסכמים כמות אדירה של נתונים להמלצה פשוטה, כך לשוק התוכנה יש את האנליסטים שלה. החברות המוכרות הן Gartner ו Forrester וקצת מאחור IDC ו Altimeter Group. תוצאות מחקרי השוק שלהן עולות אלפים רבים של דולרים למחקר ומכסים תחומים רבים, בעיקר ב IT. הרבה ביקורת קיימת על מחקרים אלו, אך רוב החברות בגודל בינוני-ומעלה עובדות לפחות עם אחד מהגופים הללו. אם תבדקו במחלקת ה PM רוב הסיכויים שתגלו שיש להם (או יש להם גישה) לחומר כתוב ויכולת לקבוע פגישת יעוץ עם אנליסטים מאחת מהחברות הנ\"ל.
     
    מצד שני יש את דו\"ח הטכנולוגיה של חברת ThoughtWorks שמחולק בחינם ומכסה מספר מצומצם של טכנולוגיות, אך מתוך הכרות אינטימית של מובילים טכנולוגיים שהשתמשו בטכנולוגיות אלו בפועל. דו\"ח זה נקרא Technology Radar והוא מיועד יותר למנהל הפיתוח / ארכיטקט / מנהל בכיר ופחות ל Marketing. תוכלו למצוא בדו\"ח זה סיכום על מצבן על טכנולוגיות, כלים ומתודולוגיות כגון OAuth, HAML, DevOps או ESB. הדו\"ח מדבר על מגמות ולא נכנס לפרטים. סקירת הדו\"ח יכולה להיות מקור טוב לקבלת החלטות (אם הטכנולוגיה עליה אתם חושבים מכוסה) או לעקוב אחר טכנולוגיות וטכניקות חדשות שצוברות תאוצה.

    [א] באותה לוגיקה (לכאורה) יכול מנהל להחליט לזנוח SCRUM ולעבור לפתח ב Waterfall \"כי שבעים אחוז מהתעשייה לא טועה\" או להסיק שאין סיבה לא לפתח בקובול, \"שפה מוכחת ורצופת הצלחות עסקיות\". גם Benchmarking צריך להעשות נכון, קרי – להביט על מגמות ולעשות השוואות רלוונטיות.
    [ב] האם האנליסט באמת יודע מה קורה בחברת נייס? הוא ניזון בעיקר ממסרים אופטימיים שמייצרת מחלקת יחסי הציבור של נייס. האם הוא מכיר את הלקוחות? טיפה. משוחח איתם פה ושם. וזימבבואה? הוא מצא אותה על המפה (אם הוא אנליסט טוב) וקרא כמה סקירות של… איך לא? אנליסטים אחרים שכתבו על השוק הזימבבואי. בערך2 כפול בערך3 = בערךבערך6, וככל שכמות המשתנים הלא מדוייקת גדל… כך התוצאה הסופית פחות מדוייקת.

    על המלכודת הפנימית של תעשיית ה IT ואיך נוצרים מוצרים פחות טובים (ספיישל יום כיפור)

    לאחרונה יוצא לי קצת להתעסק בהרמת הבלוג.

    אחת החוויות החיוביות והמפתיעות שהיו לי היא התקנה של הwidget של Outbrain. ה widget הוא תיבת ה \"בנוסף אולי תאהב/י את…\" שנמצא פה בבלוג בתחתית כל פוסט (הוא זקוק לעוד זמן תוכן ותעבורה כדי לעבוד כמו שצריך פה בבלוג).

    שאלתי את חברי, שלמה יונה, שעובד באאוטבריין איך להתקין. קיבלתי את התשובה הבאה:

    הממ… עסוק באמצע העבודה כדי לפרט? טיפים? אומר לעצמו \"הוא טכנולוג, הוא כבר יסתדר\"?

    לא ציפיתי לכיף חיים. הוספתי גוגל אנליטיקס ממש לפני זה ונאלצתי לחפש tutorial בגוגל, לערוך את ה HTML View של הבלוג ולשתול javascript שנתנו לי. ואז עוד עשר דקות בפורומים של גוגל להבין ש \"invalid connection\" בסוף ההתקנה הוא נורמאלי וייקח לו עד חצי שעה להתרפרש.
    גוגל אנליטיקס ובלוגר הם שני מוצרים של גוגל – חברת ענק עם גוף פיתוח שידוע באיכותו הגבוהה. ואאוטבריין? סטארט-אפ ישראלי?

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

    פתאום הייתי בבלוגר – מאשר להוסיף? מאשר.
    נגמר.

    מה???
    בדקתי כמה פעם לא מאמין – הכל עובד.

    אני לא יודע אם החוויה שלי היא המייצגת, אבל היא בהחלט הייתה טובה. הדהדו לי קולות של מנהלי מוצר שעבדתי איתם בעברי: \"המשתמש הוא administrator – הוא יסתדר גם עם להקליד regex במקום להקליק על checkbox\". \"זה משתמש טכנולוגי, אז שימחק הכל וייצר את הרשימה מחדש, הוא ימצא עזרה בגוגל\".

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

    חוויות ההתקנה של אאוטבריין אינה מייצגת את שוק ה IT: הרי ה widget מותקן באתרי ענק ושם ההתקנה יכולה לדרוש קידוד באסמבלר. כנראה שלמודל העסקי של אווטבריין חשוב שגם שכותב הבלוג הקטן יוכל להתקין.

    ישנו פרדוקס בעולם ה Enterprise: לעובד (איש IT, נאמר) יש מספיק מוטיבציה להסתדר עם המערכת (המשרה שלו) שהוא מוכן לספוג חוויות התקנה ושימוש מחפירות. השוק, שרובו בנוי על תוכניות רכש ארוכות טווח, רוצה להבטיח מראש את התאמת המוצר ולשריין את התקציב, ולכן מכין רשימת דרישות מקסימלית. כלומר – מה נראה לנו שבמקסימום נצטרך. גם לא רוצים להתקע עם מערכת שחסר לה פיצ\'ר חשוב ושזה יתגלה רק אחרי הטמעה ארוכה ויקרה.

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

    מה עושים?
    מנהל בכיר שהכרתי הציע ברגע של יאוש לשלוח מאמר בנושא ל all-customers@worldwide.com, המייל חזר.

    הייתי שמח מאוד לראות חרם צרכנים של אנשי IT: \"לא Wizard – לא קונה\". מהפכת צרכנים כמו שקרתה בעולם המערבי בשנות החמישים.*

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

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

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

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

    ויש את המציאות הקיימת שנדרש להמשיך להתמודד איתה.

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

    בקיצור, גמר חתימה טובה וצום קל.

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


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