הכר את המשתמש: איש ה-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] בציוד רשת יש משמעות רבה לרכישה מספק אחד - הציוד עובד ביחד בצורה משמעותית טובה יותר.