שלמה (כבוד הרב דוט נט) יצר עימי קשר לפני כמה שבועות, וביקש ממני לבוא ולהרצות בערב שבו נפגשים חברי פורום NET. של תפוז. לומר את האמת הפורום הזה חמק מתחת למסך המכ"מ שלי בשנים האחרונות. הלכתי להציץ מה קורה שם, וגיליתי קהילת משתמשים וירטואלית פעילה. גיליתי גם באותה הזדמנות שאני חבר ותיק (ומאד לא פעיל) בפורום הזה.
הרעיון של המפגש, הוא להפגיש מדי פעם את כל החברים הוירטואליים, בעולם הפיזי, כדי לאפשר להם לרגע לצאת מהמטריקס ולראות מי הפרצופים והגופות שמסתתרים מאחורי הכינויים. ואם באותה הזדמנות, ניתן לתת גם כמה הרצאות טכניות להעשרת הידע, מה טוב.
אז המפגש היה אמש. מכללת סלע תרמה את המקום ואת הפיצות (ומגיע לה מילה טובה על זה). למפגש הגיעו כמה עשרות משתתפים פיזיים, והוא שודר במקביל בשידור חי לכל מי שלא יכול היה להגיע, וגם הוקלט (אני אצרף את הקישור להקלטה כשאקבל אותו).
הערב נפתח על ידי אסף סינגל כנציג נותנת החסות, שאמר כמה מילים על סלע (מה לעשות, הם נתנו את המקום ואת הפיצות, אז מגיע להם) ואחר כך, עם המון טקט וצניעות, נעלם מהשטח.
את מקומו תפס כבוד הרב, כנציג הגוף המארגן, שאמר כמה מילים חמות וקצרות על הפורום ועל המפגש.
משם עברנו לחלק המקצועי, ופתח אותו עידו פלטו שהאיר את עיני כולם בנושא Fiddler. הרצאה מבוא (וקצת יותר ממבוא) מעולה, לכל מי שרוצה להכיר את הכלי ולהתחיל להשתמש בו מהר. אני מזמין את כולם לצפות בהקלטה לכשתהיה זמינה.
ואז כולם יצאו להפסקה קצרה לאכול עוגיות ולשתות משהו. אחר כך אני דיברתי קצת על הנושא האהוב עלי Production Debugging.
ואז הגיעו הפיצות. לאחר שכולם השמינו כדבעי, עלה לקידמת הבמה רון קליין ודיבר על ההבדלים בין כתיבת קוד פרוצדורלי לכתיבת קוד מונחה עצמים.
היה כיף, היו שתי הרצאות שחידשו לי דברים (ואחת שלא כל כך), אני לא יודע מתי יהיה המפגש הבא, אבל אני אשתדל להגיע אליו.
אם הגעת לפוסט הזה מבלי לקרוא את הפוסט הקודם אנא עצור כאן ולך לפוסט הקודם, אחרת אתה מפספס את כל הכף.
אל תתעצל, לך לפוסט הקודם.
נו…..
טוב, שלא תגיד שלא הזהרתי אותך.
----------------------------------------------------------
אז להלן רמז נוסף לשאלה למה ה Reflector פישל.
לך בבקשה ל Explorer ופתח אותו באיזה תיקיה שאתה רוצה, לאחר מכן לחץ על עכבר ימין ובקש New Folder. תן בבקשה לפולדר הזה את השם aux, האם הצלחת ? לא, לא הצלחת.
נסה prn ? יש כאן איזה שהוא Pattern ? מצלצל פעמון באיזה שהוא מקום ?
נסה lpt1, מעניין ? מה עם Com1 ? אני מניח שכבר תפסתם את הפרנציף.
אי אפשר לייצר קובץ או תיקיה שהשם שלהן הוא אחד מהשמות שמופיעים ב Global Namespace כשם של Dos Device. למה ? ככה !. מאחר והרפלקטור פותח תיקיה לכל חלק ב NameSpace, אז אם כללת ב Namespace חלק ששמו כאחד מהשמות השמורים ב NameSpace (למשל aux בדוגמא שנתתי), אי אפשר לייצר את התיקיה הזו. מה שאומר שלא תצליח לעשות Export ל NameSpace הזה מה Reflector.
מה שמוליך לשתי שאלות שלא קשורות אחת לשניה. שאלה ראשונה היא למה לעזזל מיקרוסופט עושה את זה ? והשאלה היותר מעניינת, היא למה החברים ב Red-Gate לא בודקים את ה Return code של Create folder ולא מדוחים על הבעיה כמו שצריך, אלא פשוט מדווחים שהכל הצליח בשעה שזה לא הצליח. ואני חותם לכם שהם קיבלו Return Code רע על הבעיה הזו. כי לאחר שהבנתי מה הבעיה, סתם מתוך סקרנות, הרצתי Process Monitor על ה Reflector בזמן הביצוע של ה Export, והוא דיווח לי שהיישום קיבל Failour בנקודה הזו. ואם הוא דיווח את זה לי, הוא דיווח את זה גם להם.
למי שסקרן לדעת מה עשיתי כדי לפתור את הבעיה, אז אני מתבייש להודות שהשתמשתי ב Brute force. שעשיתי Roun trip ל DLL תוך שימוש ב ILDasm ו ILAsm, כאשר בדרך עשיתי Edit ידני על הקבצים, ושיניתי כל הופעה של aux ל aux1 (עשיתי את זה עם Replace all אחד). כן זה לא אלגנטי במיוחד, ואפילו מגעיל, אבל מדובר היה רק ב DLL אחד, ולא היה לי כוח להתקשקש עם זה באלגנטיות.
אני די בטוח שכשהתחלתי את הסיפור הבלשי, לא ציפיתם שהוא יסתיים בשרידים הארכיאולוגיים של עולם ה DOS. אבל אין מה לעשות, Real Programmers use DOS, ושלא יספרו לכם ש DOS מת, הוא איתנו לנצח.
אני תמיד מסביר למי שמוכן להקשיב לי, שמציאה של Bug בסביבת הייצור אינה החלק החשוב בתהליך. מי שעוצר ב Bug, יגלה שיש לו בפרויקט עוד המון Bug – ים שכולם יופיעו בשלב זה או אחר בסביבת הייצור או אצל הלקוח. השאלה החשובה באמת היא איך ה Bug הגיע בכלל למערכת. הרי ה Bug לא היה בספציפיקציות של המוצר, אז מאיפה הוא הגיע למוצר הסופי ?
הטעות הכי גדולה שיכולה לעשות מערכת פיתוח/ייצור, היא לעצור במציאת ה Bug, לתקן אותו, ולסמן V. הדבר הנכון הוא לא לעצור ב Bug, אלא לנתח לעומק, את כל השרשרת של הטעויות, שהביאו לכך שה Bug נמצא במוצר הסופי, ולהגיע לשורש הבעיה (The Root Cause of failour). התוצר של התהליך הזה, הוא שלא "רק" פותרים את ה Bug, אלא מגלים בדרך הרבה אחים ואחיות חורגים של אותו Bug, וכתוצאה מזה מקבלים שתי ציפורים ביריה אחת. גם מתקנים את כל משפחת ה Bug - ים, וגם מונעים את החזרה של כל ה Bug – ים מאותה משפחה למוצר.
הבעיה שאני מספר עליה כאן, התחילה משאלה נורא פשוטה, שנתקלתי בה אצל לקוח. איך אני משווה שני DLL – ים כתובים ב NET. ומוודא שהם זהים. השאלה הראשונה שהתעוררה אצלי בנקודה הזו, היא למה לעזזל שמישהו יצטרך לעשות דבר כזה ? שיוציא מה Source Control את הגירסה הישנה, וישווה אותה אל מול החדשה, ויגמור עניין. לאחר חקירה בכיוון הזה, שבה נתקבלו כמה תשובות נבוכות, נסתברו העובדות הבאות: א. יש Source Control, ב. קוראים לו Source Safe, ג. לא היה ניתן להוציא ממנו את הגירסה הקודמת, כי לא שמרו אליו גירסאות תוך שימוש נכון ב Labels (או כל אמצעי סימון אחר). ד. ה Source safe שימש יותר כמערכת Backup ופחות כ Source control. כל זה הוליך לבעיה, שלאחר שה Source שוחזר ידנית, למצב שבו חשבו, שמצב הקוד הוא בדיוק כמו הגירסה שנמסרה ללקוח. נוצר הצורך החשוב, לבדוק שההנחה הזו באמת נכונה. לכן היה צורך להשוות בין ה DLL – ים שמוציא הקומפילר, לאלה שנמצאים בפועל אצל הלקוח בסביבת הייצור.
אז ככה.
שימוש ב Source safe כיום הוא אנכרוניסטי, למה להשתמש במערכת כל כך ישנה ומוגבלת כאשר יש TFS. ולא שהיתה כאן בעיה של רשיון או כסף. ללקוח היה כבר MSDN, כך שהמעבר מ Source Safe ל TFS לא היה יותר מאשר החלטה טכנית מנהלתית, וכמה דקות של Convert. ולהזכירכם, ל TFS יש Brance ו Shelf וקישור אוטומטי ל Work Item בזמן ה Check In, שאלה כלי עבודה שימושיים מאד, שאין ל Source safe.
דרך אגב, לא סתם אני אומר שהמעבר יקח כמה דקוות. כי אם אתה מעביר את הפרויקט כמו שהוא, זה כמה דקות. אבל אם אתה מנצל את ההזדמנות "לעשות סדר" בפרויקט, ואם אתה מחליט באותה הזדמנות גם להמיר אחורה את כל ההיסטוריה (כדי שניתן יהיה לדעת איזה שינוי נעשה בקוד בשנת 1954), ועוד כמה שטויות כאלה, זה בהחלט יכול להפוך לפרויקט רב שנתי.
אני בעד הגישה של, או להשתמש ב Converter המובנה של TFS, או פשוט לשאוב גירסה אחרונה מה Source Safe, ולהכניס אותה כפי שהיא ל TFS, ולהמשיך משם. אין לי בעיה ששתי המערכות יחיו Side By Side, עד אשר ה Source Safe ימות לבד מבדידות וחוסר שימוש. אבל כמובן, אני אשמח לשמוע דעות אחרות בנקודה הזו (ולכסח אותן באלימות).
אבל זה לא נעצר כאן. השאלה היותר מעניינת היא למה לא ניתן היה להוציא ב Soure Safe את הגירסא הנכונה ? כאן אנחנו נכנסים לתחום ה Process Plumber שלי דהינו בעיה בתהליך. כמה ש Source Safe נחשב לתוכנה דפוקה בימינו, הוא עדיין מערכת, שאם משתמשים בה נכון, יודעת לעשות את העבודה. הבעיה נוצרה מזה שפשוט לא השתמשו נכון במוצר. וכאן מקור הבעיה הוא פער ידע. הצוותים, ומה שיותר חשוב ראשי הצוותים, פשוט לא ידעו איך עובדים עם Labels, ומתי פותחים פרויקט חדש בעץ (שזה שווה הערך המאד לא טוב ולא דומה ל Brance), אלא השתמשו ב Source Safe כמעין מערכת Backup, מבלי להבין שללא תיוג מתאים של פעולות השמירה, המערכת מאבדת את רוב (אם לא את כל) יכולות ניהול הקוד שלה. ומכאן בעצם התחילה הבעיה.
אז ככה.
אם המערכת תעבור ל TFS, מבלי שראשי הצוותים יקבלו הדרכה מלאה על מערכת ה Source Control של ה TFS, הדרכה שכוללת רקע תיאורטי על איך צריך לנהל Source ב TFS ולא רק את התפריטים. המפתחים כבר ימצאו דרך לעשות Abuse גם ל Source control של ה TFS, והבעיה תחזור באיזה שהוא שלב בצורה זו או אחרת. לא משנה לצורך העניין, כמה ה TFS טוב יותר מ Source Safe. כי המערכת הכי חכמה, לא תעמוד בפני המתכנת חסר הידע. השאלות התיאורטיות של מתי נכון לפתוח Brance, איך נכון לארגן את הפרויקט ב TFS, השימוש הנכון ב Shelf, או לחילופין, מהם שדות החובה שעל מפתח למלא בטופס בזמן ה Check In, הם שאלות שצריכות להיות ברורות, לא רק לראשי הצוותים, אלא גם לכל אחד מהמפתחים שמשתמשים בכלי. אז תוסיפו בבקשה לכמה דקות של ההמרה, גם כמה שעות של הדרכה לכל הצוות. ואני מקווה שברור לכם שאם היתה מתבצעת הדרכה דומה, למפתחים וראשי הצוותים, על ה Source Safe, הבעיה שנתבקשתי לפתור לא היתה נוצרת בכלל וההגעה למצב נתון של הקוד לא היתה דורשת התערבות ידנית.
ובאותה הזדמנות.
אני נוהג כל פעם שאני נוגע בקוד, להוסיף בקוד שורה אחת של הערה, עם השם שלי, התאריך, מה שיניתי ובעיקר למה. אחרי 10 שנים, אתה לא זוכר בדיוק מה עשיתה ולמה, וכאשר אתה צריך לרדת מרזולוציה של Check In לרזולוציה של שורות בקוד, ההערות האלה חוסכות לך זמן יקר. כן, זה מנפח את הקבצים, אבל מצד שני, שטח דיסק זול יותר משעות עבודה, וזה בטח מקטין את רמות הסיכון של שינויים בהמשך. אם הנוהל הפשוט הזה היה מתבצע בפרויקט הנ"ל, העבודה הידנית של "החזרה לאחור" היתה קלה יותר.
טוב אז בואו ונמשיך הלאב בסיפור הבלשי. הרעיון הראשון שלי היה להשתמש ב IlDasm כדי לפרק את שני ה DLL – ים לגורמים ואז פשוט לעשות Diff בין הקבצים. רעיון מבריק אבל זה לא עבד, כי IlDasem באמת מפרק את הכל, אבל לא באותו סדר, ואז ה Diff מאבד באיזה שהוא שלב את הצפון.
השלב הבא היה לעבור ל Reflector או למשהו דומה, אבל מאחר וה Reflector עולה כסף חיפשתי בשלב הראשון פתרון חינמי אחר, וניסיתי את Just Compile של Telerik. זה לא עבד, יותר מדי Errors של הכלי. לא היה לי כוח לחפש עוד כלים (ואני אשמח לקבל משוב בנקודה הזו מכל מי שמכיר מנסיון כלי שיכול לעזור בסיטואציה הזו). אז התקנתי את גירסת הנסיון של ה Reflector על אחד ממחשבי הפיתוח במעבדה שלנו, והתחלתי לעבוד.
התהליך היה להכניס את זוג ה DLL – ים שדורש השוואה ל Reflector (אחד אחד בנפרד). ולשמור את ה Source של ה DLL באמצעות Export Assembly Source Code, ולהשוות בין התוצאות עם Diff.
כמובן שה Diff יצעק על ה Guid שמתחלף בין קומפילציות, אבל זה רק שתי שורות ב Diff, שקל לראות שאין להן קשר לקוד. ומאחר ודובר על כמות סופית וקטנה של Dll – ים להשוואה, לא חיפשתי פתרונות נוספים, אלא עברתי על ה DLL – ים ידנית.
הכל הלך כשורה עד שהגעתי ל DLL אחד שסירב בכל תוקף לבצע Export. לא היתה הודעת שגיאה ! פשוט לא קיבלתי קובץ Source.
חשוב לציין שהבעיה לא היתה ביכולת לעבור על הפונקציות ברפלקטור דרך ה UI, אלא רק ביכולת לעשות ל DLL הזה Export. ומאחר ובשאר ה DLL – ים לא נתקלתי בבעיה הזו, היה ברור שיש משהו ב DLL הזה שדופק את הרפלקטור.
אז להלן גירסת הקוד של ה DLL המינימלי שמשחזר את הבעיה, ונראה אם מישהו מכם מצליח לאתר את מקור הבעיה.
למי שרוצה לעשות בשלב הזה Copy Paste לקוד והזה על מנת לבדוק בעצמו, בבקשה
namespace kuku.aux.kiki
{
public class aaa
{
public int bbb()
{
return 2;
}
}
}
לא יכול להיות קוד פשוט יותר. רק שכדי שתידלק לך מנורה אדומה (כמו שנדלקה לי), בשלב הזה, אתה צריך להיות מספיק זקן (וזה רמז).
אז אני עוצר כאן את הפוסט, ומבטיח לכם, שבפוסט הבא אני אגלה לכם את התשובה (שבטח תפתיע את כל הצעירים). אל תציצו בתשובה, תנסו להבין למה בצורה שבה עובד הרפלקטור, קוד כזה איננו ניתן ל Export. ולא צריך בשביל התשובה לזה כלי Debug מיוחדים.
יצחק בן לוי הוא שועל פרויקטים ותיק. הוא גם מומחה ב Lean, שזה, אם אתם לא יודעים, הלהיט התורן בניהול פרויקטי תכנה. אבל יצחק לא בא מתחום פרויקטי התכנה, הוא בא מתחום הפרויקטים של מערכות שכוללות מרכיבים רבים, כמו מיכל דלק של מטוס או פריסה לוגיסטית של מערכת נשק. נקודה זו, שלא באשמתו, היתה בעכוריו. כי לא כל המשתתפים היו מסוגלים לראות, את הקשר הישיר בין מה שהוא דיבר לבין ניהול פרויקטי תכנה, וחבל.
יצחק הציג את המתודה שלו עם הרבה סיפורים מהשטח. מנהלי הפרויקטים הותיקים בקהל הצליחו להתחבר יפה אל השיטה ואל הדוגמאות. למנהלי הפרויקטים הצעירים בקהל, היה הרבה יותר קשה לעשות את זה, וחלק מהם פשוט פיספסו את התובנות, בגלל חוסר נסיון מספיק בפרויקטים שנכשלו.
אני ישבתי בסוף והיה לי קשה שלא לצחוק ו/או לבכות, כי כל משפט שני של יצחק, הזכיר לי דוגמא מעשית, מאחד הפרויקטים שנקראתי לטפל בהם. אני מזכיר למי שלא יודע, שכאשר קוראים לי לפרויקט, זה בדרך כלל פרויקט תכנה שמתעופף, מסיבה זו או אחרת, אצל הלקוח או ברצפת הייצור. מי שקורא לי, לא עושה את זה רק כדי שאפתור את הבעיה הנקודתית, אלא גם כדי שאאתר את ה Root Cause of Failour, שזה משהו הרבה יותר עמוק מאשר ה Bug הספציפי והנקודתי שהעיף את המערכת. וכאשר אתה מחפש את ה Root Cause of failour, אתה כמעט תמיד מגיע לשלב ה Design של הפרויקט, ולכל ה Process שלו. ומכאן ההזדהות העמוקה שלי, עם המון מהתובנות שהציג יצחק.
אני לא הולך לשחזר כאן את ההרצאה, אני מניח שפנינה תעשה את זה בבלוג שלה (קדימה פנינה), אני רק אעלה כאן כמה נקודות ותובנות, שקפצו לי לראש בזמן ההרצאה. מדהים דרך אגב, כמה הדברים שהעלה יצחק, מתקשרים בצורה ישירה, לעקרונות ה MSF. אותו MSF, שפעם היה מתודה שלמה, שנלמדה בקורסים וסדנאות, והיום התנוון לכדי שבלונה ב TFS, שמעטים מאלה שמשתמשים בה, מודעים לרקע התיאורטי הנרחב שעומד מאחוריה.
השקף הזה מייצג בצורה די ברורה, למה חלק מהצעירים בקהל איבדו את יצחק, ברגע שהוא הציג אותו. עם יד על הלב, כמה מכם היו מעורבים בפרויקט, שכלל כל כך הרבה גופים מעורבים ? תתפלאו לשמוע, אבל אני טוען, שכל מי שהיה מעורב בפרויקט תכנה, שהיו בו יותר מעשרה מפתחים, או בפרויקט שהתבסס על שילוב של קוד מכמה מקורות שונים, היה כבר בפרויקט כזה. רק תחליפו כל מחלקה ב Feature Team, או ב Out Sourcer, ותקבלו את אותו דבר.
הבעיה שהוצגה היא שמאחר וכל אחד נמצא בפינה שלו, ורואה רק את קצה האף שלו, תקלות באינטגרציה מתגלות (אם בכלל) בשלב מאוחר מדי בפרויקט, עם נזקים משמעותיים. השיטה שהוצגה, היא להביא את כולם למקום אחד. לדחוף להם בכוח את התמונה הכללית, ולסחוט תוך שימוש בלחץ פיזי מתון, מכל אחד מהמשתתפים, את המחויבות שלו, לפינה הקטנה שלו בפרויקט, מתוך ראיה כוללת של ההשתלבות, של החלק שלו בכלל המערכת.
הקטע הבא, נועד לשבור את כל משוגעי הטכנולוגיה, שבטוחים שתכנת Project היא הפתרון האולטימטיבי, לקבלת התמונה הכללית של התהליכים והמשימות בפרויקט. היא לא. בשלב הארגון הראשוני (וגם בהמשך) אין משהו שנותן מיפוי טוב יותר של המצב בשטח מאשר פתקים שמודבקים על הקיר. כן, כן, אני לא צוחק, Wall Design שם בכיס הקטן, כל נסיון לעשות את זה, כאשר משתתף אחד בלבד מחזיק את ה Keyboard, ומציג את הכל, על מסך. זה פשוט לא אותו דבר. אין דבר שמשתווה לעבודה הקבוצתית, שבה כל אחד מזיז את הפתק שלו לנקודה הנכונה בתהליך, כתוצאה מאילוץ או מגבלה, שנתגלתה תוך כדי הדיון המשותף.
השימוש בקיר מוביל לכמה תובנות מענינות (ומשעשעות) על מגבלות התהליך. כמו למשל שגובה הקיר קובע את מספר המחלקות/יחידות שיכולות להשתתף בפגישה (22 ערוצים אם זה כל כך חשוב לכם). רוחב הקיר קובע את ציר הזמן (צריך מסדרון ארוך או חדר ישיבות גדול). פרויקטים שיש להם תאריך יעד קשיח מסתימים בפינה (כי שם נגמר הקיר) בעוד שפרויקטים שציר הזמן שלהם גמיש, מסתימים באיזה שהוא מקום באמצע הקיר. לא יאומן כמה הויזואליזציה, של ההתקרבות לסוף הקיר, מדגישה את אילוצי הזמן של הפרויקט לכל המעורבים.
הנכון הוא להשאיר את הכל על הקיר במסדרון ולהיפגש שם כל כמה זמן (יום, יומיים, שבוע, תלוי בפרויקט) ולקיים ישיבת סינכרון בעמידה, אל מול נקודת הזמן שבה נמצא הפרויקט בפועל, כאשר מעדנים את התכנון לטווח הקצר בהתאם לאילוצים. ומזיזים את הפעילויות (פתקים) מנקודה לנקודה, בהתאם למה שקורה בשטח.
שימו לב לציר הזמן בצילום הזה. הציר הוא לוגריתמי. יש לך "אופק תכנון" שבו אתה יכול להגיע לרזולוציה גבוהה. חודש, חודשיים, אולי שלושה. מעבר לזה אין טעם לתכנן ברזולוציה גבוהה, כי ממילא הרבה דברים ישתנו עד שתגיע לאותה נקודת זמן. רבעונים כבר מתכננים ברזולוציה בינונית ואת הטווח הרחוק עושים ברזולוציה גסה. כל מנהל פרויקט יודע את זה, אבל אני עדיין מוצא תכנונים ב Project, שטוענים שהם יודעים, מה יקרה בעוד שנתיים, ברזולוציה של חצי שעה. שימו לב לדמיון הרב של כל זה עם Agile ו XP.
הנקודה הבאה שרציתי להתיחס אליה היא מה שנקרא Unknown – Unknown. הנושא שצריך להדיר שינה מעיניו של מנהל פרויקט טוב, הוא השאלה" מה אני לא יודע שאני לא יודע". זה נשמע משחק מילים, אבל זה אולי הגורם הכי קריטי למניעת הפתעות יקרות בפרויקט. את מה שאתה יודע שאתה לא יודע, אתה יכול לרשום ברשימת ה Todo של הפרויקט, לבצע עליו ניתוח, ולהפוך אותו ל Action Items ו/או ל Risk Statements עם Mitigation ועם Contingency מוכנים. אבל מה שאתה לא יודע שאתה לא יודע, ממתין באפלה, לרגע הכי לא מתאים, ואז מכניס לך את זה בסיבוב. הטכניקה שהציג יצחק, מציפה למעלה המון Unknown – Unknown, והיא גם מאפשרת לקיים דיון מעשי, על תהליכים של קיצור לוחות זמנים ודרכים אחרות לחסכון כספי בפרויקט.
הנקודה האחרונה שרציתי להתיחס אליה, היא התיחסות ריאלית לדרישות של הלקוח. לא תמיד הלקוח מודע למשמעויות של כל דרישה. לפעמים לדרישה שנראית פשוטה ללקוח, יש תג מחיר גבוה. לפעמים דרישה עם עלות גבוהה, אינה באמת חשובה ללקוח. היו לי המון פרוקטים שנתקעו, בכלל דרישות לא הגיוניות של הלקוח, שבסופו של דבר הסתבר שהלקוח בכלל לא היה צריך אותם ו/או שהוא בכלל התכוון למשהו אחר, או שיש לו דרישה תחליפית, שטובה לו באותה מידה, רק שהעלות שלה משמעותית קטנה יותר.
יש לי עוד הרבה תובנות מהמפגש הזה, אבל גם ככה זה יצא ארוך מדי. אז אני אמשיך בהזדמנות אחרת איל"ז.
היום שלפני סדנת ה Zen Of Architecture עם Juval Lowy היה יום עבודה מלא, Juval ואני הסתובבנו בין לקוחות, שהזמינו את Juval למפגשי יעוץ נקודתיים.
השרות הזה של מפגשי יעוץ נקודתיים, הינו שרות שאני בניתי, ביחד עם Juval, במיוחד למדינת ישראל. הרעיון היה לתת לגופים בארץ, אפשרות לקבל יעוץ נקודתי ו/או חוות דעת שניה, על נושאים שמטרידים את הארגון, בעלות אטרקטיבית.
בדרך כלל Juval לא מבצע מפגשים נקודתיים אלא בא ללקוח לשבוע עבודה, על מנת לבנות ביחד עם הצוות של הלקוח, ארכיטקטורה לפרויקט. כאשר בסוף השבוע הלקוח יוצא עם תשתית ארכיטקטונית מלאה, שכל מה שנשאר ללקוח לעשות, זה למלא בתשתית הזו את ה Business Logic. אבל בארץ יותר זול לעשות טעויות יקרות מאשר להשקיע יותר בתכנון (וזה נכון לא רק לארכיטקטורה אלא גם ובעיקר לתחום איתור התקלות והכנת המוצר לסביבת הייצור, תחום שבו אני מתמחה)
זו לא פעם ראשונה שאני מסתובב ככה עם Juval בארץ, למעשה כל פעם שהוא מבקר בארצנו, יש לנו כמה לקוחות כאלה, והמספר רק הולך וגדל משנה לשנה. השנה, בעיקר בגלל מגבלות הזמן של Juval, נפגשנו רק עם שלושה לקוחות, כל לקוח, בתחום אחר לגמרי.
אני נוהג לסכם לעצמי את המפגשים האלה, כאשר השורה התחתונה היא ההערכה שלי (בדרך כלל תוך התיעצות בלקוח), כמה כסף חסכנו לאותו לקוח באמצעות היעוץ. השנה, אני מעריך שחסכנו ללקוחות כ 750,000 דולר (בחישוב שמרני). ולמי שחושב שאני מגזים, שיחשוב לרגע, כמה עולה שנת אדם של מפתח, וכמה עולה לחברה, אם צוות שלם של מפתחים, מבצע פרויקט, שהארכיטקטורה שלו נועדה מראש לכשלון. אני מתכוון לאותם 30 אחוז של פרויקטים, שידרשו ממילא Rewrite ו Redesign, עוד שנה או שנתיים, לאחר שיזלגו בזמנם ובתקציבים. לחלופין, תנסו לכמת כספית, מה המשמעות, לארגון, אם הוא בוחר אסטרטגית בטכנולוגיה, שהולכת למות בשנים הקרובות (וזה נכון לא רק למיקרוסופט).
אבל לא על זה רציתי לספר לכם. רציתי לספר לכם דווקא על הסיום של היום. חברת Code Value הזמינה את Juval לארוחת ערב עם כל צוות העובדים שלה (וגם הזמינה לארוע כמה לקוחות נבחרים, וידידים), כאשר הארוע המרכזי לאחר הארוחה, היה הרצאה של מעל שעתיים, של Juval, על כמה נושאים, שנבחרו על ידי קהל המשתתפים (וכן, למי שקופצים לו רעיונות לראש, Code Value שילמה על הזמן של Juval).
למי שלא מכיר את Code Value זו חברה צעירה עם צוות ששוה להכיר. מי שמנהל אותה מהבחינה הטכנית, הוא לא אחר מאשר אלון פלייס, ויש בה צוות מרשים של אנשים טכניים. אלון, אני לא צריך לספר לכם, הוא מקצוען מהשורה הראשונה. הוא גם גייק בדם. אין חפיץ (Gadget) שהוא לא בודק ומכיר היטב, והבית החכם שלו, שווה הרצאה בפני עצמו. אלון יודע בדיוק מה מעניין אנשי מקצוע כמוהו. וברור היה לו, שרק ארוחת ערב, זה דבר טוב, אבל ארוחת ערב, עם הרצאה מקצועית ממומחה עולמי, זה משהו שיתרום הרבה יותר לצוות שלו מאשר הערך הקלורי.
אז קודם כל הארוחה היתה מעולה, ותודה לצוות המנהלה של Code Value שאירגן את הארוע. בזמן הארוחה ישב לידינו בשולחן פאבל והוא Juval (ואני) דנו בכמה נושאים טכניים מעניינים. לאחר מכן התכנסנו כולנו בחדר ההרצאות, ו Juval דיבר על כל מה שעניין את המשתתפים, כולל הפסקה קצרה לסופגניוות. היו בארוע מעל 70 איש. אני בדרך כלל מודד הצלחה של מרצה, על ידי ספירה של כמה משתתפים נשארים לחלק השני של ההרצאה יחסית לחלק הראשון. כמצופה, Juval לא איכזב, ולא היתה נשירה.
גם השנה, במה שהפך כבר למסורת, הוזמנתי להרצות על הנושא האהוב עלי Production time Debugging, בכנס ביצועים, שנערך כל שנה, אי שם. עצם העובדה שמרכזים פעם בשנה, קבוצה גדולה של אנשי שטח, לדון בנושא שיפור ביצועים, הינה דבר מבורך. כי במערכות גדולות, כל שניה שאתה חוסך, יכולה להיות מוכפלת בקלות, בפקטורים של עשרות אלפים (והיו כמה דוגמאות כאלה בכנס).
היום התחיל עם שיחת פתיחה, על נושא ביצועים בעולם ה IT. נושא הביצועים חותך את כל הרכיבים בארגון, ולכן צריך להתיחס לזה בתפיסה הוליסטית וכוללת. ומכאן הסיבה לכך שהוקם גוף יעודי למטרה הזו. מאחר וניתוח בעיות כאלה במערכות גדולות דורש מומחים (בדיוק כפי שיש רופא מומחה), יכולת להבין ולנתח הרבה מאד פרמטרים וכלי איסוף ברמת הארגון. ביומו של גוף מרכזי מאפשר לעשות את זה יותר יעיל, בטח בארגון שהתחלופה בו גבוהה. גוף כזה מתמקד באופן הגיוני בתהליך נכון (Process Plumber) ובכלים ושיטות (Bug Extermination).
הוצכרה גם השאלה הנצחית, מתי ובאיזה שלב של הפרויקט יש לעשות את זה עם התשובה הברורה מאליה (לפחות לחלק מאיתנו) שזה לא משהו שצריך לעשות בסוף, אלא כמה שיותר מוקדם, וצריך גם לזכור, שגם כשהמערכת כבר בשטח, צריך לערוך לה Tuning תקופתי. נושא הביצועים קושר כבדרך אגב, לעולם מלחמות הסיבר, שכן אחד מוקטורי התקיפה, זה העמסת תהליכים קימים. רציתי להעיר בנושא הזה, שבהרבה מהמערכות שטיפלתי בהן בתוקף תפקידי כמשמיד חקרים ושרברב של תהליכים, לא היה צריך תוקף חיצוני, הארכיטקטים והמפתחים שהקימו את המערכת, עשו את זה מספיק טוב.
בשלב הבא עלה על הבמה יאיר הורוויץ מ HP והציג את ה Performance Center 11 של HP. ה Performance Center זה גירסת ה Enterprise של Load Runner. אחת התוספות החזקות של הגירסה החדשה היא הקישור ל ALM, מה שמשלב את המערכת בצורה מלאה בכל תהליך הפיתוח. דבר חשוב נוסף הוא מעבר מהסתכלות פרטנית, להסתכלות מערכתית, של בעיות הביצועים. שילוב דרישות הביצועים ברמת הארגון ולא ברמת הפרויקט. בנוסף כל הצעצועים הצפויים, כמו תיזמון בדיקות בשעות שאין משתמשים, חלוקת משאבי בדיקות בין הבדיקות השונות וכו.
לאחר מכן עבר יאיר לדבר על ה Sire Scope, שהוא כלי לאיסוף רציף של מידע וניטור מערכות. החוזקה שלו היא שהוא מכיר את כל המערכות ולא רק את עולם המיקרוסופט, כך שאם יש לך מערכת הטרוגנית, ויש לך כמה ספקים, ומערכות כמו WebSpare של IBM ו מערכות Enterprise של Oracle בארגון. אתה מקבל את היכולת לנטר את כולם בנקודה אחת. וכמובן הוזכרו גם SLA, Tranding, Analysys ו Diagnostics ואפילו BSM.
הפנינה שתרם לי יאיר, היא הסיפור של השימוש בפיצה לבדיקת עומסים. פעם כדי לעשות בדיקות ביצועים, היו מרכזים את כל העובדים עם המחשבים שלהם בחדר אחד. קונים לכולם פיצה, על מנת להבטיח שכולם יגיעו. ואז מבקשים מהם שכולם ביחד, באותו רגע, ילחצו על ה Enter. כדי לייצר עומס על המערכת. ה Load Runner הוא סך הכל שיפור של התהליך, בזה שהחליף את המשתמש הפיזי במשתמש וירטואלי. ובכך חסך את תקציב הפיצה הארגוני. כמובן ש Load Runner נותן היום הרבה יותר ממשתמש וירטואלי, ויאיר לא שכח להזכיר את הפרוטוקולים החדשים שנוספו, כמו למשל תמיכה מלאה ב AJAX, הסתכלות ברמת ה UI באמצעות TruClient ולא רק ברמת ה Web Transport והקורולציות (דורש בשלב זה Fire Fox).
משם הכיתות התפצלו, אנשי ה DB הלכו לכיתה אחרת כדי לשמוע על שיפורי ביצועים ב SQL ממאיר דודאי ממיקרוסופט ישראל. אני דווקא נשארתי לשמוע תאור מרתק של תהליך שיפור ביצועים באחת המערכות שבה הושג שיפור תהליכים מ 4 שעות לעומת 4 שניות. הבעיה שהוצגה היא מערכת שעבדה שנים בלי בעיות ביצועים (כאילו). כשהשימוש במערכת עלה, ולאחר המעבר לדיווח יומי, לילה שלם כבר לא הספיק, כדי להוציא את כל הדוחות שנתבקשו. מה שגרם כמובן לכך, שביצועים הופך להיות נושא שדורש טיפול.
היחס בין 4 שעות ל 4 שניות הוא לא יחס קטן. וזה מעורר כמובן את השאלה, איך זה קורה, שקוד כזה דפוק יושב שנים במערכת, ופוגע בביצועים שלה מבפנים. ואף אחד לא עלה על זה, בשלב הפיתוח של המערכת. התשובה היתה שהנושא של Performance לא היה בראש של צוות הפיתוח מלכתחילה, ולא היתה אליו מודעות. וזה לא התבטא רק במודעות לביצועים, היו בקוד אזורים עם גושים ענקיים של קוד, שכל הכלים מצביעים על זה ששם יש בעיה, ועכשיו לך ותתקן משהו, בתוך כל הספגטי הזה.
אז להלן רשימה של כללים (עשרת הדברות) שהוצגו: עובד לאט, לא עובד – ברמת הפרט, לא עובד מהר לא עושים לקוד Check In. לא ניגשים ל DB בלולאה. לפני הפיתוח לתקף הנחות יסוד וארכיטקטורה, ואם צריך תייצר לצורך זה אבטיפוס. תימנע מ Join – ים רבים, גם אם זה אומר שצריך לעשות Denormalization ל DB. כל מה ששואלים עליו בכמויות גדולות, תדאג שיאונדקס. אל תשתמש ב PL/SQL כלוגיקה עיסקית ואל תכתוב שם קוד. אם אתה כותב קוד PL זה כנראה דבר רע. עדיף לשאול שאלה שמביאה Raw Data ואת העיבוד של הלוגיקה העיסקית לעשות בזכרון של המחשב, עם קוד בשפה נורמאלית שניתנת ל Debug ולניהול. עבודה עם ORM ועם אוביקטים, תמיד תהיה יותר קלה לכתיבה מאשר שימוש ב SQL עם שאילתות מורכבות וכתיבת לוגיקה תכנותית בשפה שאינה פרוצדורלית. לעבוד במנות גדולות יותר טוב מעבודה ברמת רשומה בודדת, גם אם הנצילות לא מלאה.
הוזכר גם נושא של מניעת נעילות ונעילה חכמה כגורם שמפריע למיקבול, וגם פיזור של תורים בין ספקים למשתמשים כאמצעי למנוע בעיית נעילה על התור. והודגש שצריך המון מחשבה על מה לנעול ומתי, כי זה גורם מגביל מספר אחד ליכולת המיקבול של המערכת.
כמובן שאת כל ההמלצות יש לקחת עם קורטוב של מלח, כי זה התאים לפרויקט הספציפי הזה, והכל תלוי גם בגודל ובביצועים הנדרשים. לקחתי משם כמה פנינים. האחד זה המונח "רוחב פס של קשית". והשני הוא הסיפור על המפתח שיושב על מכונה חזקה, והמשתמש בשטח יושב על גרוטאה, ומה שלוקח למפתח שניה על המחשב בשטח יכול להתבטא בדקות.
עוד דבר שאהבתי היה הנושא של תראו כמה ירוק יש כאן יחסית לכאן. ירוק הכוונה היא כמה הערות נכתבו כדי להסביר את הקוד, בשני המקרים (לפני התקון ואחרי התיקון). איזו תמימות נעורים יש במשפט הזה. כמה מפתחים באמת מתעדים נכון את מה שהם כותבים, אם לא יושב להם ראש צוות קשוח מעל הראש ומכריח אותם לעשות את זה. וכמה זה רחוק עדיין, מזה שהקוד אמור לתעד את עצמו.
בשלב הזה כולם הלכו לאכול ארוחת צהריים. אני בדרך כלל לא אוכל בצהריים אז התחברתי לרשת ועבדתי קצת.
לאחר ארוחת הצהריים היה פיצול נוסף ואנשי ה Java נפרדו מאנשי ה NET. והלכו לשמוע משי כהן מאורקל ישראל, מה מציעה אורקל בתחום. כאשר באותו זמן, אנשי ה DB, שמעו על ניתוחי ביצועים בזמן אמת, מליאור סבג מאורקל ישראל. לומר את האמת, אם הייתי פנוי, הייתי הולך לשמוע את שי, אבל מה לעשות, וזה היה חריץ הזמן שבו אני הרצתי על הנושא האהוב עלי Production Dbugging.
ההרצאה שלי היתה אותה הרצאה שהעברתי בארוע הזה לפני שנתיים, אבל מה לעשות, בכל שנה יש דור חדש שצריך לחנך אותו, על הדקויות של סביבת הייצור, ואיך לאסוף שם מידע. הקהל היה אקטיבי, היו המון שאלות והמון נקודות עניין, בקיצור כף.
לאח הפסקה קצרה עברתי לשמוע על מקרה נוסף של שיפור ביצועים בשטח, כאשר אני מוותר על מוטי באני ממיקרוסופט, שדיבר על הכלים של Sys Internals (שאותם אני כבר מכיר) ועל הרצאה על אופטימיזציות חדשות של אורקל 11g, שהעבירה גליה קוקה מאורקל ישראל.
הסתבר שהמערכת המדוברת מתבססת המון על Java Script, ואני חייב לומר מראש, ש Java Script זה לא היה אף פעם My Cup of tee. אבל מעניין אותי תמיד לשמוע על תקלות, בעיות, ובעיקר איך עלו עליהם, ואיך פתרו אותם. בהרצאה הוצגו הכלים FireBug ו IEDevTools שהם ספציפיים לדפדפן, ומאפשרים צפיה ב DOM, ביצוע Debug של Java Script, שינוי דינמי של Poperties וכו'. בהרצאה הוצגה דוגמא ספציפית איך שימוש בכלים הללו עזר לפתור בעיה. אחר כך הוצג Fiddler, עם בעיה אחרת ברמת התקשורת בין הדפדפן לשרת, שהוא סיע לפתור. ולסיום הוצג DynaTrace AJAX, עם דוגמאות לבעיות שנפתרו בעזרתו.
אם קודם סלדתי מכל שימוש ב Java Script, התחושה שלי רק התחזקה לאחר ההרצאה הזו. הבעיה היא, שכמו שזה נראה, כולנו נצטרך לסבול הרבה בעתיד מ Java Script, ככל שנתקדם יותר לכיוון של HTML5, ואני ממש לא אוהב את זה.
לסיום ויתרתי על הרצאתו של ולאד אזרקין ממיקרוסופט בנושא כלי תכנות מקבילי של NET. (מתנצל ולאד, בטח היה מעניין אבל זה נושא שאני כבר מכיר. ועל הרצאה נוספת שעסקב ב DB והצטרפתח להרצאה של ארכיטקט מערכת על ביצועים של מנועי חיפוש. הוצגו בהרצאה גם ההיסטוריה וגם האלגוריתמיקות השונות של מנועי חיפוש כולל המון שיקולי Scalability וטיפול בכמויות ענק של מחשבים והחיבור ביניהם. נקודת כניסה טובה למי שרוצה לחקור יותר היא מנוע החיפוש solr.
נכון שהמפגש היה לפני קרוב לשבוע, אבל מצד אחד היה לי על הראש את Juval, ומצד שני היו לי כמה פרויקטים להשלים, וחשבתי כבר לשכוח מכל העניין, אילולא טרח אורי ושם את ההקלטה של הארוע ברשת למי שמעוניין לשמוע.
אז לפני שאני מתחיל לשלוח אש וגופרית (ויש לי הרבה אש וגופרית), בואו ונתחיל עם הדברים החיוביים. קודם כל קבוצת ה Software Craftsmanship. היא אחת מהקבוצות החביבות והמוערכות ביותר אצלי ברשימת קבוצות המשתמשים שאני מבקר בהן (ומי שמכיר אותי, יודע, שאני משתדל לבוא למפגשים של כמעט כל קבוצת משתמשים שרק קיימת, כך שיש לי פרופורציות).
הסיבה שאני כל כך מעריך את הקבוצה הזו, היא שבקבוצה הזו, גם לפי שמה, וגם לפי חלק גדול מהנושאים שעולים במפגשים שלה, עוסקים בגורם מספר אחד, שאני נתקל בו, כאשר אני מנתח טעויות בקוד, במערכות מתמוטטות, והוא חוסר מקצוענות של המפתחים (וגם קצת למעלה מזה בשרשרת המזון).
חשוב לציין בנקודה הזו, שחוסר מקצוענות בכתיבת הקוד, לא מתחיל בדרך כלל מהמפתחים. זה מתחיל בראשי הצוותים, במנהלים של ראשי הצוותים, ובדרך כלל השרשרת ממשיכה עד ה CTO. כי אם מפתח רשם Try Catch ריק בקוד (סתם דוגמא), וראש הצוות לא גילה את זה, ו/או גילה את זה, אבל לא התיחס לזה בחריפות. והדרג שמעל ראש הצוות, לא גילה ועצר את התופעה בעודה באיבה, וכן הלאה. המפתח אשם, אבל האחריות היא גם (ואולי בעיקר) בדרג שמעליו. במערכת שמחפפת, המפתח לעולם לא ילמד לכתוב קוד נכון. לעומת זאת במערכת שמתפקדת נכון, אחרי הפעם הראשונה שהמפתח כתב Try Catch ריק, מובטח שהוא לא יחזור על הטעות הזו שוב.
ודרך אגב, מפתח שגילה Try Catch ריק בקוד, שלא הוא כתב, או שראה אותו, בזמן שהוא סרק קוד היסטורי, שקיבל לתחזוקה (או בספריה של Open Source), ולא הפך את זה מייד ל Item ברשימת ה Todo של הפרויקט, לא נקי מאשמה, בדיוק כמו זה שכתב את ה Try Catch הריק. ואם ראש הצוות שלו, ברגע שראה את זה ברשימת ה Todo של הפרויקט, לא הורה לו לתקן את זה בעדיפות ראשונה, ולא הגדיר מייד מטלה לכל המפתחים בצוות, לסרוק את הקוד, ולחפש עוד מקרים כאלה, ולטפל בהם מייד. לא צריך להתפלא, אם באותו פרויקט, קוראים לי מדי פעם, לטפל במערכת המתמוטטת, בכל פעם שהיא סוטה מנקודת הייציבות (הזמנית) שלה.
יש הרבה מה לומר על כתיבת קוד נכון, ואני חושב שזה נושא מספיק גדול ומכובד, שניתן לעסוק בו רבות. אורי חושב בגדול כמוני, אבל הוא לא רוצה להתמקד בקבוצה שלו רק בתחום ה"צר" הזה (שימו לב למרכאות), והוא מרחיב את תחומי העניין של הקבוצה לנושאים נוספים. אין לי בעיה עם זה, אבל ככל שהקבוצה מתרחקת מהנושא העיקרי (לטעמי האישי) של "מקצוענות המפתח" ו "מקצוענות כתיבת הקוד", אני תוהה ביני לבין עצמי, אם אין כאן איזה שהוא פיספוס.
אני מסתובב המון בארגונים שיש בהם מערכות מתמוטטות (לא סתם אני Bug Exterminator). אני נתקל שם בהרבה מפתחים שעושים טעויות ברמת הקוד הבסיסי. יש הרבה שלא מבינים אלף בית של ניהול זכרון בקוד מנוהל. יש הרבה שמשתמשים בפונקציות הלא נכונות, להשגת המטרות הלא נכונות (שימוש לא נכון ב API). אני כל פעם מורט מחדש את השערות (שאין לי), כשאני רואה קטעי קוד, שמתאימים לתיכוניסט שלמד זה עתה תכנות, ולא למפתח מקצועי, שאמור להתיחס לכתיבת קוד כ "תורתו אומנות", ושיש לו גאווה מקצועית, לא לעשות Check In, לקוד, שהוא יודע שיש בו בעיות.
אז מה היה לנו במפגש הנוכחי (מספר 9 לספירה הקבוצתית) ? היה לנו פנל שבו השתתפו רן תבורי, אלעד סופר וליאור שכטר. כל אחד מהם כבודו במקומו מונח, והם נושאים בתפקידים רמי מעלה, והמקצוענות שלהם אינה מוטלת לרגע בספק. ומי שחושב לרגע אחד שאני מתלוצץ או ציני בנקודה הזו, שיעקוב בבקשה אחר הקישורים מאחורי השמות, ויתרשם בעצמו, שאין כאן אפילו טיפה אחת של ציניות (בניגוד להרגלי).
אז איפה כל האש והגופרית ? לומר את האמת, האש והגופרית מכוונת כל פעם לנושא אחר, ולדובר אחר. כי כמו בכל פנל, היו דברים מענינים יותר, והיו דברים מענינים פחות (אותי). והיו דברים שהסכמתי איתם, והיו דברים שהעלו לי את הסעיף, ועליהם בעיקר אני הולך לכתוב כאן. אז נא לקחת את הכל בפרופורציות, כי אני מאד נזהר שלא לשפוך את התינוק ביחד עם המיים, ולכן גם כל ההקדמה הארוכה.
הנושא הראשון שעלה לי העצבים, היה בדיון על מה זה ארכיטקטורה, ומה עושים עם הייצור הזה, שנקרא ארכיטקט. ואני אומר כאן את הדעה הקטגורית שלי, שכל מערכת שאמורה להיפרס על מספר שרתים ו/או להיטמע ביותר מכמה תחנות קצה ו/או מכילה בתוכה יותר מכמה קומפוננטות שמדברות ביניהם (דהינו כל מערכת שאינה טרויאלית) זקוקה לארכיטקטורה, וזקוקה לארכיטקט. הארכיטקט צריך ללוות את הפרויקט במשרה חלקית או מלאה (או בכמה משרות, תלוי בגודל הפרויקט) לאורך כל חיי הפרויקט. כי הארכיטקט, הינו הגורם היחידי, שמסוגל לבצע את ה Decomposition של המערכת, ולהביא אותה לתחום, שבו האנרגיה לפתח ולתחזק אותה, היא המינימאלית.
יש הרבה ארכיטקטים רעים בשוק (ועל מנת להסיר ספק, אף אחד מחברי הפנל לא נמצא בקטגוריה הזו), יש הרבה ארכיטקטים שהיו מפתחים מעולים, וראשי צוותים נהדרים, ויש להם המון נסיון וידע. אבל הם חסרים או את ההדרכה, או את הידע, של מה זה בדיוק ארכיטקטורה, ומה בדיוק תפקידו של הארכיטקט בפרויקט. חלקם נמצאים כל כך למטה בקוד, שהם מפספסים את רמת האבסטרקציה הנדרשת מארכיטקט. הבעיה נובעת גם מזה שאין "בית ספר" ללימוד ארכיטקטורה, ולימוד מנסיון הוא תהליך איטי וכואב. מעטים הארכיטקטים שעברו הכשרה כשוליה אצל אומני ארכיטקטורה, עד שהבשילו להיות ארכיטקטים (והנושא של איך נוצר נגר אומן בימי הביניים, דווקא כן עלה בדיון).
זה שהיה למישהו נסיון רע עם ארכיטקטים לא מקצועיים (ושוב אנחנו חוזרים לנושא של מקצוענות), לא משנה את העובדה, שהארכיטקט והארכיטקטורה קריטיים להצלחת הפרויקט. ואני לא מקבל את הטיעון שהארכיטקט מבזבז את זמנם של המפתחים בזמן שהוא עושה את הארכיטקטורה. אני בדעה שלפני שלוקחים שישים מפתחים, ומתחילים לכתוב קוד של מוצר, במוד של Free Running (או Agile או Scrum), רצוי מאד שמישהו יראה את התמונה הכללית, יעבור על ה Use cases, יעשה את ה Decomposition, ויבנה ארכיטקטורה שתעמוד בפני כל שינוי שהמערכת אמורה לעבור בשנים הקרובות. כי אם לא תעשה את זה, תקבל מערכת, שעלויות הייצור והתחזוקה שלה, הן הרבה מעבר למתוכנן ולצפוי. וכן, עדיף שצוות של 60 מתכנתים ישב שלושה חודשים, ולא יעשה כלום בקוד של הפרויקט, אלא יקדיש את הזמן ללימוד של טכנולוגיות, וכלים, ו Coding Standards, בזמן שהארכיטקט יושב ועושה את ה Decomposition. במקום לרוץ לשום כיוון, ולקבל מהר הרבה קוד, שהדבר הנכון היחידי שצריך לעשות איתו, הוא לזרוק אותו לפח.
בהקשר הזה יודע כל מקצוען שמשחק בבורסה זה שעדיף למכור מניה בהפסד קטן מאשר להחזיק אותה ולהיגרר להפסד גדול. לעומת זאת הרבה פרויקטים יודעים היטב בעמקי הלב שאם היו נותנים להם להתחיל היום, הם היו עושים את זה יותר טוב ויותר מהר מאשר לנסות להוסיף Patch על Patch בתכנה הקיימת. ושלא יבין מישהו מזה שאני בדעה של לכתוב הכל מחדש כל פעם. אני בדעה שלא לכתוב קוד בכלל, אם אתה לא יודע בוודאות מה אתה צריך לכתוב, ובשביל זה צריך ארכיטקט.
לא, אני לא מסכים שהתכנה מובלת על ידי הקוד ואני לא מסכים שהארכיטקטורה היא נעלם בפרויקט כמו כל נעלם אחר. הרעיון של Proof of Concept מתגלגל, הוא משהו שאני לא מוכן לקבל באף פרויקט. כתיבת הקוד של התכנה צריכה להיות מובלת על ידי הארכיטקט. וכן, ברגע שיש ארכיטקטורה צריך לתעד אותה, בשפה שמובנת למפתחים, וצריך להצמד אליה, ולא לשנות אותה כל שבוע. כי אם אתה משנה אותה כל שבוע, זה סימן שלא בנית ארכיטקטורה שעמידה מספיק לשינויים בדרישות. ושלא נעשתה עבודת ארכיטקטורה נכונה בפרויקט.
למי שאולי מופתע לשמוע, יש כללים ל "מה זה ארכיטקטורה טובה", ו "מה זה ארכיטקטורה רעה", ואם עובדים נכון, ניתן לתקף ארכיטקטורה מול ה Use Cases ולמצוא בה טעיות ותקלות, עוד לפני שמוציאים אותה לאויר העולם. חשוב שהמפתחים יבינו את שפת הסימונים של הארכיטקט ויציתו לה. וחשוב שהארכיטקט יללוה את הפרויקט, ויוודא שמתכנתים חסרי נסיון לא יבזו את הארכיטקטורה שלו. ולא, תפקידו של הארכיטקט זה לא לשמור על השלמות הקונספטואלית של המוצר. התפקיד שלו זה לבצע Decomposition נכון, שיביא את המערכת לנקודת מינימום האנרגיה של הכתיבה והעמידות לשינויים. יש בארכיטקטורה המון נקודות של הנדסה, זה לא עניין לרגש ולתחושות וזה לא רק עניין של אומנות וטעם אישי.
טוב, הוצאתי מספיק אש וגופרית על הנושא הזה, ובואו נעבור לנושא הבא. הדיון על Scrum וכל שאר נושאי ה Agile למיניהם לא עניין אותי יותר מדי, כל טכניקה שתגרום למפתחים לכתוב קוד מקצועי ונכון טובה בעיני. שכל ישר תמיד חשוב. וכמו שאמר אחד המשתתפים (שהידע שלו ב Scrum רב משלי), ניתן להסביר מה זה Scrum בכמה שעות, ולא צריך הסמכה ו Certification בשביל להיות מומחה ומיישם של עקרונות של "שכל ישר". מה שחשוב זה התוצאה הסופית. קוד שעונה למפרט, ונכתב לפי כללי הארכיטקטורה שקבע הארכיטקט. כשאני למדתי "שכל ישר" בפרויקטים, קראו לזה (בעולם המיקרוסופט) MSF. היום כולם מכירים את זה כשבלונה של פרויקט ב TFS, שאף אחד לא יודע בדיוק איך משתמשים בה. אהבתי את הקטע של ה Least Capable Manager בתור מנהל האיטרציה, יש בזה הרבה חכמת חיים.
הנושא הבא שהעלה לי את הסעיף, היה הדיון באיך מוצאים מפתח טוב. מסתבר שלפחות לפי דעת חלק מהצוות, מפתח טוב צריך לדעת אלגוריתמיקה ברמה של איתור שורשי רקורסיה בקוד. להכיר לעומק חישובי סיבוכיות מתקדמים. ולא לשכוח שהוא חייב להיות ברמה של קוף, שיודע את כל סוגי האלגוריתמים לריצה על עצים, מכל צד לכל צד של העץ עם או בלי איסוף של פירות בדרך. וכמובן, שאם נותנים לו בעיה, הוא צריך לכתוב קוד פונקצינאלי עובד תוך שעה. והקוד שלו צריך להיות אלגנטי, יפה ועם פרוק פונקציונאלי נכון כי זה מה שחשוב. וכמעט שכחתי ידע בפרמוטציות ובקומבינטוריקה ועוד כמה דברים כאלה. לעומת זאת ידע ספציפי ב API, קיבל יחס של זילזול קל, לעומת הוד רממותה של מדע מבני הנתונים והרקורסיה.
בזמן שהנושא נידון העפתי מבט סביב וראיתי חלק מידידי הבוגרים יותר, עם פה פעור. מדובר באנשים שהם מפתחים מקצועיים, והקוד שלהם לא יבייש את שמה של קבוצת המשתמשים, אבל רובם לא יוכלו לשלוף לך מהשרוול את הסיבוכיות של כל אחד מהאלגוריתמים. ולמה שיעמיסו את זה על הראש שלהם ? בשביל מה יש Knuth ? אני לא מתבייש להודות, שגם אני הייתי נכשל בבחינה כזו של תכנות תיאורטי. אני בא לראיון לעבודה, לא לראיון למשרת דוקטור באקדמיה. אמנם רן ניסה להחזיר קצת דברים לפרופורציה, אבל הוא לא שבר מספיק חזק לטעמי.
אני אגיד לכם מה אני כן מחפש במתכנת טוב. קודם כל שיהיה בן אדם. תאמינו לי שבסולם הדרישות, זה אולי הדרישה החשובה ביותר. אחר כך, אני רוצה שיהיה איש צוות טוב, יקשיב לאחרים, יעזור לאחרים, יתפקד כחלק מהצוות ויתרום את חלקו למאמץ הצוותי. לגבי הכישורים המקצועיים שלו, התכונה שהכי חשובה לי, היא היכולת והרצון שלו ללמוד. אני מספיק זקן כדי לדעת, שאין כזה דבר מישהו שיודע הכל. וזה גם דרישה חסרת טעם כי טכנולוגיות הולכות ובאות וחוזרות כל כמה שנים. אם מפתח אומר לי, בראיון עבודה, כתשובה לשאלה ממוקדת, שהוא לא יודע נושא מסויים, אבל אם אני אתן לו מספיק זמן, הוא ילמד אותו וידע אותו על בוריו, אני מסמן לו פלוס. מכמה סיבות: א. בגלל שהוא לא מתבייש לומר שיש משהו שהוא לא יודע (ועוד בראיון עבודה), מה שאומר שאם אטיל עליו משימה שהוא לא מכיר, הוא ישאל שאלות, ויברר פרטים, ולא יעשה פרצוף שהוא יודע הכל, ואחר כך תגלה שהוא בכלל לא ידע על מה אתה מדבר ועשה שטויות. ו ב. הוא מוכן ללמוד מה שצריך, על מנת להצטרף לצוות. הדבר החשוב הבא שהייתי שואל את המועמד, זה איך הוא מתעדכן בתחום המקצועי שלו. איזה ספרים טכניים מעניינים קרא בשנה האחרונה, איזה מאמרים טכניים, איזה טכנולוגיות חדשות הוא למד. מפתח טוב (כמו רופא טוב) צריך להתעדכן כל הזמן (וזה גם נאמר על ידי אחד המשתתפים בפנל, רק בטון שקט מדי לטעמי).
הדבר האחרון שאני מחפש במתכנת זה שיהיה גאון משוגע, שהוא המקצוען הכי טוב שקיים בתחום, אבל אי אפשר לעבוד איתו בצוות, והוא הופך להיות צוואר הבקבוק בכל בעיה. וברגע שדורס אותו אוטובוס (או שהוא עוזב למקום אחר שבו יותר קל לו להתעלל בכולם) הפרויקט כולו נתקע לכמה חודשים, כי אף אחד לא מסוגל להבין את הגאוניות של הקוד שהוא כתב. וכן, מפתח שדוחה מראש את הרעיון שאחד מתפקידיו הוא לתחזק קוד קיים, לעשות לו Refactoring ולשפר אותו, ולא רואה בזה עבודה "מכובדת", יעוף גם אצלי מהראיון, עם הערה על "חוסר בגרות". כי כפי שאמר אחד מהמשתתפים בפנל, אין כזה דבר קוד חדש, או שאתה עושה Copy Paste, או שאתה משתמשי בספריה שמישהו אחר כתב, לא ממציאים היום את הגלגל מחדש, זה יקר מדי.
כתיבת קוד אלגנטי וידע תיאורטי, כל איש טכני טוב, עם מספיק ידע במדעים הריאליים, יוכל להשלים במידת הצורך. להיות בן אדם, זה תהליך הרבה יותר מורכב, שלא תמיד ניתן לבצע אותו אצל המועמד, כי זה דורש בדרך כלל ענווה, צניעות, ומה שאולי יותר חשוב, הכרה בבורות שלך. אני מצפה שלמועמד תהיה הכרות טובה של ה API הרלוונטי למערכת שאותה אני מפתח. והכרות טובה עם ה Caveats וה Pit Falls של כל אחד מקריאות ה API (ואם לא ב API שבו אני מפתח, אז אני בודק אותו בכל API שהוא מכיר, כי גם את הפער ידע הזה, ניתן לתקן). כל זה, לטעמי, הרבה יותר חשוב, ממבני נתונים או שורשי רקורסיה. ואם כבר מזכירים רקורסיה, כפי שהתבטא אחד המשתתפים בפנל, רקורסיה כמעט תמיד, זה דבר רע, בפרויקטים מהעולם האמיתי (הוא היה יותר חריף, והשתמש בביטוי לערוף את הראש של המפתח שמציע את זה), אז למה לבחון את הבנאדם במשהו, שיש סיכוי טוב שהוא לעולם לא יצטרך לממש בפרויקט ?
לאתר מתכנתים טובים מאד קשה גם ככה, אז למה לפספס הרבה אנשים טובים שרק דורשים קצת לימוד ? אני חושב שהגרלה אקראית של קורות החיים, כבר נותנת תוצאות טובות יותר. ולא, אני לא מסכים שלהסתכל על הקוד, יותר חשוב מקורות חיים. קורות חיים יותר חשובים בהרבה, כי מקורות חיים אני יכול להתקשר למנהל הקודם של אותו מועמד, ואם הוא מישהו שאני מכיר, תוך שניה יש לי תשובה אם לקחת אותו או לא. ואם אני לא מכיר את אותו מנהל ספציפי, אני כבר מספיק זקן כדי להבין בין המילים שהוא יאמר לי, מה הוא בעצם רוצה לומר.
בעניין ה Unit Tests וכו', הקשבתי לדיון התיאורטי, וקפץ לי לראש אחד הלקוחות שלי, שנאבק נואשות בהנהלה שלו, על מנת שיקצו לו עוד איש QA אחד טוב (יש לו רק אחד בצוות של חמישה מתכנתים). אותו ראש צוות, קיטר בפני, שהרבה יותר קל לו מול ההנהלה לקבל מתכנת נוסף לצוות, ולא איש QA, כי איש QA הוא תקורה על הפרויקט. לך תסביר להנהלה המטומטמת, שאיש QA טוב, חוסך המון זמן (וכסף) לצוות הפרויקט, ועוד יותר המון זמן (וכסף) ללקוחות בשטח, בגלל ה "תקורה" שלו. ולך ותסביר להם, שבפרויקט, לקראת שלבי ההגשה שלו, המספר הנכון הוא לפחות שני אנשי QA, על כל מפתח (וגם זה לא תמיד עוזר).
בשביל לבדוק תכנה כפי שצריך, אתה צריך מישהו שהמומחיות שלו זה בדיקות תכנה ולא פיתוח. כי בודק תכנה טוב, חושב אחרת ממפתח. בודק תכנה טוב, יודע לתכנת הרבה יותר טוב ממפתח ממוצע, אבל הפוקוס שלו שונה., הוא נהנה לבדוק את מגבלות המערכת, ואיפה הוא יכול להעיף את הקוד, ופחות מעניין אותו, איך הוא יכול לממש את ה Feature הספציפי שכתוב במפרט. כמוובן שבודק תכנה טוב, יעשה כל מה שביכולתו, על מנת שהבדיקות יהיו אוטומטיות ולא ידניות. זה כל כך ברור שככה צריך לעבוד, שאני לא מבין איך אני עדיין צריך להסביר למנהלי פרויקטי פיתוח, שזו הדרך היחידה לעבוד. וכן, כל פעם שמוצאים Bug יש להכין Script שמשחזר אותו, ולהוסיף אותו לבדיקות האוטומטיות של המערכת, ולו רק כדי להבטיח, שאם אחד התיקונים הבאים יחזיר את ה Bug הזה, הוא ימצא ב Build היומי, ולא אצל הלקוח בשטח (ואני כמובן לא מדבר פה על מקרה ספציפי, שקרה לי ממש בשבוע האחרון, אצל לקוח).
הקטע האחרון שהעלה לי את הסעיף, היה הקיטורים על זה ששימוש ב Agile ו Scrum וכל שאר הזימזומילים האלה, גורם לכך, שקשה למפתח לקבל קרדיטים על העבודה שלו, ולהתפתח בארגון, כי הכל הופך לעבודה קבוצתית, כולל ההחלטה אם הוא רוצה ללמוד לפתח את עצמו מקצועית.
אז לתשומת לך כל המקטרים. האחריות על ההתפתחות המקצועית שלכם היא רק עליכם, ולא על אף אחד אחר. אני מרחם על כל המפתחים, שעוברים ממקום למקום, בגלל תוספת של 1000 ש"ח לברוטו. אתה צריך לעבור ממקום למקום, אך ורק לפי הקריטריון של איך זה מקדם את הידע המקצועי שלך, ואת הקריירה המקצועית שלך. כי אחרת, תגלה מהר מאד, שבמקום להנות מהמקצוע שלך, אתה נשחק ממנו, והדרך משם לאשרם בהודו, או לתיקון שלטי רחוב, קצרה הרבה יותר ממה שאתה חושב. סיפוק מקצועי לטווח רחוק, משמעותית הרבה יותר תורם לאיכות החיים שלך, מאשר עוד 1000 ש"ח במשכורת. אבל צריך קצת נסיון חיים כדי להבין את זה, וזה חסר להרבה מפתחים צעירים שיוצאים מהאקדמיה, או מהיחידה המקצועית המובחרת בצבא, ורואים רק את קצה האף של ההזנק הבא שלהם, ולפעמים אפילו לא רואים ממטר, את ההזנק הנוכחי שלהם.
מה עוד אהבתי, את המשפט "היום הייתי מאד יעיל, מחקתי 1000 שורות קוד מיותר" (בהקשר של איתור שיכפול קוד מיותר ובכלל). את הדיון על זה ש Performance זה לא באמת דבר כל כך חשוב (ויש לי הרבה מה לומר על הפיקסציה של כולם לשיפורי Performance מיותרים), וגם אהבתי את ההערה הסופר צינית (וכמה היא נכונה) שככל שאתה בחברה יותר גדולה, ככה אתה כותב פחות שורות קוד ליום.
מרתק כמה דברים שקשורים לתהליך עלו במפגש הזה בלי להרגיש. הרבה מהנפילות וההתמוטטויות שאני מטפל בהן מקושרות ישירות לטעויות בתהליך. והסיבה שאני מדגיש את זה בא כדי להבהיר שיש קשר ישיר בין נפילות מערכת לטעויות ב Process ומזה בדיוק בא החלק השני של תחום הפעילות שלי שרשום בכרטיס הביקור, Process Plumber (ולא כפי שטועים רבים לחשוב, שזה קשור ל Process & Threads).
משוב יתקבל בברכה, גם מחברי הפנל, גם ממי שהיה שם, וגם מכל אחד אחר שיש לו מה לומר בנושא הזה. טל"ח.
שאלו אותי כמה מבוגרי סדנת ה Architect's Master Class של Juval, אם יש טעם לבוא ליום העיון הזה. התגובה הראשונה שלי היתה כמובן שאין טעם. אבל ליתר בטחון התיעצתי בנושא עם Juval. והתגובה שלו היתה שאכן החצי הראשון של היום מוכר כבר למי שהשתתף בסדנה. אבל החלק השני הוא ניתוח בזמן אמת, על פי הטכניקה, של מערכות שיוצגו לו על ידי המשתתפים. הקטע הזה אומר Juval, יכול לעניין את בוגרי סדנת הארכיטקטים, כי זה עוד הזדמנות לתרגל מחשבתית את השיטה. אז אם מישהו מבוגרי סדנת הארכיטקטים מעוניין לבוא רק לחצי השני של היום, אנא שלחו אלי דואל ישירות, כדי שאבדוק אם ניתן להצטרף (אנחנו מתקרבים כבר לגבול הקיבולת של הארוע).
נקודה חשובה נוספת היא שההרשמה המוקדמת הוארכה עד יום חמישי הקרוב. וכמו תמיד, המחיר של ההרשמה המוקדמת משמעותית יותר זול משאר האפשרויות. אז אל תפספסו את ההרשמה המוקדמת.
שאר הפרטים למי שרוצה להרשם ליום עיון, או לארגן מפגש יעוץ עם Juval, נמצאים בפוסט הקודם שלי על יום העיון.
ניצלתי את ההזדמנות ש Juval Lowy מחברת IDesign Inc מבקר באירופה, והצלחתי לגרור אותו לארצנו הקטנה, כדי שיעביר יום עיון, על הנושא החזק שלו, ארכיטקטורה. היום נקרא The Zen of Archirecture ואת כל הפרטים על יום העיון המיוחד הזה תוכלו למצוא בקישור הבא.
יום העיון הינו בחסות של ג'ון ברייס מכללת הי-טק, ולאות תודה והערכה אני מצרף כאן את הלוגו שלהם.
הדרך המהירה ביותר לקבל את כל הפרטים על יום העיון היא לשלוח דואל לסיגל שלנו, ומאחר ומספר המקומות הפעם באמת מוגבל, כל מי שמקדים זוכה.
בנוסף, מי שרוצה לשמוע Second Opinion או סתם לארגן מפגש יעוץ עם Juval, ולו רק כדי לוודא שלא פספס משהו בתכנון שלו, או סתם כדי לישון טוב בלילה. נשארו ל Juval שני חריצי זמן ליעוץ בביקור הזה. אז מי שרוצה להתיעץ עם Juval, שימהר לפני שגם זה ייתפס.
כל מי שמכיר מי זה Juval ו/או השתתף בסדנאות של Juval, מוזמן להפיץ את המידע לאנשים הרלונטיים בארגון שלו, ולמי שלא מכיר את Juval, אז תקציר עליו מופיע כאן. מי שרוצה לקבל עדכונים מוקדמים מתי Juval חוצה את ארצנו מוזמן להצטרף לדף ה Facebook או לקבוצת ה LinkedIn שבה אני מדווח על זה.
למי שלא מכיר את קהילת מנהלי פרויקטים בניהולה של פנינה זינגר נא לרשום לעצמו משימה להכיר את הקהילה הזו ולהצטרף למפגשים של הקבוצה. גם אם אתה לא מנהל צוות או קבוצה או פרויקט או מנכ"ל. אני מניח שבאיזה שהוא שלב בקריירה שלך, את/ה מתכנן להתקדם לכיוון ניהולי. ולהזכירכם, גם ראש צוות של שלושה מפתחים צריך לדעת לנהל. פנינה דואגת להביא לא רק הרצאות טכניות על כלי ניהול, אלא בעיקר מרצים לתחום שנקרא Soft Skills. מאחר ואנחנו עוסקים באנשים, פרויקט יכול לפול או לחיות על החלק האנושי הרבה יותר מאשר על החלק הטכני.
הפעם המפגש היה עם עופר רשף שנתן לנו בשעה וחצי תקציר על איך לשכנע מחזיקי אומצות (Stake Holders) או בתרגומו העברי "בעלי עניין", לעזור לך במקום להפריע לך לנהל את הפרויקט, למטרות שהגדרת לו. ומי שחושב שהצלחה של פרויקט תלויה רק בעמידה בזמנים, בתקציב ובדרישות הטכניות שימשיך לחלום. דווקא האנשים שאין להם בהכרח שום תפקיד פורמאלי בפרויקט, ואינם נמצאים בכלל בהירארכיה הארגונית מעליך או מתחתיך. הם אלה שיכולים לגרום לך הכי הרבה נזק, אם לא תטפל בהם כמו שצריך.
עופר הסביר את הבעיות, נתן כלים להגדרת "מה אתה רוצה להשיג", הראה איך צריך לעשות מיפוי של בעלי עניין, הסביר איך להבין מה הצרכים שלהם, נתן כלים איך לשכנע אותם לעזור לך, ואפילו הספיק לדבר קצת על טיפול בהתנגדויות. הכל נעשה במהירות מטורפת, אבל בצורה מאד בהירה ומאד יעילה, ועם המון התיחסות לתגובות מהקהל וגם עם המון דוגמאות מהשטח. מה לעשות, מקצוען. היה ברור שעופר מדבר מנסיון, כל קונספט תיאורטי לווה בסיפורים מהחיים האמיתיים, שרבים מאיתנו נתקלו בדומים להם. מי שלא היה, הפסיד, ומי שרוצה יותר, יצטרך כבר לעשות את זה באחת מהסדנאות של עופר. עופר משתמש הרבה בוידאו. הוא נוהג להקליט את ההרצאות שלו בוידאו, ולשחרר קטעים נבחרים באתר שלו. גם ההרצאה הזו הוקלטה, ואני מניח שקטעים ממנה יופיעו בשלב זה או אחר באתר שלו.
פנינה הבטיחה שהמפגש הבא יעסוק בתחום הטכני, באיך לחבר את Project ל TFS. זה נושא שאמור לעניין מאד את כל מי שאמור לנהל פרויקט שיש בו מתכנתים. למי שלא יודע מה זה TFS לעולם פיתוח התכנה ו/או מה זה Project לעולם ניהול הפרויקטים הנושא ישמע אולי פשטני מדי. אבל החיבור בין שני הכלים החשובים הללו (כל אחד בתחומו) לא היה פשוט בעבר, ובמפגש יראו איך לעשות את זה נכון ומה העצמה שזה נותן לניהול הפרויקט.
הארוע של ה Community RoadShow SMBMVB, שהתרחש ביום חמישי שעבר, לאורך כל היום, באולם דקל, במשרדי מיקרוסופט ברעננה, היה מעניין מהרבה בחינות, ולא רק מהבחינה המקצועית (ששם הוא היה ממש משהו מיוחד). בואו ונתחיל מזה שהיוזמה לארוע לא באה ממיקרוסופט, אלא מקהילת ה MVP של SBS. היוזמה היא של Jeff Middleton שהוא MVP של SBS בניו אורליאנס, וגם המייסד של חברת SBS Migration, שתחום המחיה העיקרי שלה הוא המרות מגירסה לגירסה של SBS (כולל מעברלהתקנות נפרדות, לחברות שגדלו מעבר לתחום הכידאיות של SBS).
למי שלא יודע מה זה SBS אז להלן הסבר קצר. יש למיקרוסופט חבילה שנועדה לעסקים "קטנים" שנקראת SBS, או בתרגום Small Business Server. החבילה הזו בקומבינציות שונות, נועדה לעסקים שיש להם עד 75 עובדים, והוא כוללת בתוכה את כל מה שעסק עד גודל כזה צריך בחבילה אחת. דהינו שרת קבצים, שרת דואר, SharePoint אתר Web, גישה מרחוק וכו'. היתרון של החבילה הזו, מעבר לקומפקטיות שלה (פחות שרתים כי זה All in one כזה) הוא כמובן במחיר. שהוא משמעותית יותר זול, מאשר לרכוש את כל הקומפוננטות והשרתים בנפרד.
ברור שככל שיש לך יותר עובדים, כך האטרקטיביות של החבילה יורדת. וכדי לשים דברים בפרופורציות, חשוב לציין, שלמרות שהמספר המקסימלי של משתמשים בחבילה יכול להגיע ל 75, בפועל, סטטיסטית, בממוצע כלל עולמי, מספר ה Clients לחבילה כזו הוא 11. בארץ, 50 עובדים נחשב לעסק גדול, אבל בלי לפגוע באף אחד, 50 עובדים זה לא Enterprise והמונחים העולמיים לתאר את זה, זה Small. אני לא הולך למכור לכם את SBS, זה הג'וב של מיקרוסופט ולא שלי. אני רק מסביר מה זה SBS. אבל חשוב לציין, שאם אתה עסק של 3-20 עובדים, אתה יכול, בעלות נמוכה מאד, להפוך לעסק עם תשתית המיחשוב המודרנית ביותר שמיקרוסופט יכולה לתת, ואתה לא צריך בשביל זה להוסיף ל Pay Role שלך עשרה אנשי IT.
לצורך המפגש הזה הגיעו מחו"ל Jeff Middleton מניו אורליאנס בארה"ב, Marina Ross מהולנד ו Oliver Sommer מגרמניה, כולם MVP של SBS. מצד הגיע Greg Starks מיוסטון (גם כן בארה"ב). את הזוית הישראלית נתן יזהר הורוביץ שיש לו מקום של כבוד בקהילת ה SBS. את המימון לנסיעה נתנו הספונסרים מיקרוסופט ו HP ואת השיווק לארוע נתנה קהילת קבוצת משתמשי ה SBS של סטיבן וחיים. זה שהמפגש אורגן בעצם על ידי הקהילה (העולמית) ולא על ידי מיקרוסופט, גרם לכך שהמפגש היה ממוקד יותר בנושאים שמעניינים את הקהילה, ופחות בנושאים שיווקיים (פרט אולי להרצאה של נציג HP).
היום התחיל בהכרות עם מוצר שנקרא MultiPoint 2010. הבעיה שהכלי הזה בא לפתור היא הקטנת כמות המחשבים בארגון. למי שלא יודע, מאחורי כל מחשב מסתתרת תקורה, שעולה הרבה יותר ממחיר המחשב, בתחזוקה שוטפת של המערכת (ראה המחקר המקורי על TCO). אם אני יכול לשים בחדר אחד, שבו יושבים, לדוגמא, ארבעה עובדים, עם אותם דרישות מיחשוב. במקום ארבעה מחשבים רק מחשב אחד. ולתת לכל אחד מהעובדים רק לוח מקשים, עכבר ומסך, שמחוברים לאותו מחשב. חסכתי תחזוקה של שלושה מחשבים. או למשל, אם יש Call Center או כיתת לימוד, ואני רוצה לראות מה כל אחד מהעובדים / תלמידים עושה כרגע, וגם להשתלט אם צריך זה גם חסכון. בקיצור, מוצר, שיכול בהרבה תרחישים לחסוך עלויות.
לאחר מכן קיבלנו סקירה על הצעצועים של HP, בעיקר מוצר ה Proliant Micro Server שגודלו חצי ממחשב רגיל, בעלות זולה מאד של פחות מ 1,300 ש"ח (אנחנו מדברים על Server ולא על תחנת עבודה) שמסוגל להרים שרת SBS שלם בארגון קטן עד בינוני. ועל עוד מוצרים דומים שנועדו לשוק ה SBS ולשוק ה MultiPoint.
משם הלכנו לארוחת צהריים יוקרתית של סנדויצים וקולה. לאחר מכן היתה הרצאה טכנית, ממבט של אנשי שטח, על סדרת מוצרי ה SBS. אני לא נכנס כאן לפרוט רב מדי על התוכן, מפני שממילא ההרצאה שימשה רק בסיס ל Session שלם של Q & A מעמיק. שנערך בין משתתפי יום העיון אנשי קבוצת המשתמשים של SBS, שלהזכירכם, מכירים כבר את המוצר בעל פה ועובדים איתו שנים. לבין המרצים, שהנסיון חיים שלהם במוצר, גם כן לא התחיל אתמול. היה דיון טכני מעמיק, ברמה שחרגה הרבה מעבר לרמת 400, שחרגה לכשצריך גם לנושאים שיווקיים, שרות ללקוח, בעיות טכניות נדירות, ומי יודע מה לא. בקיצור, כמות המידע הממוקד שזרמה שם, היתה ענקית, ורק בשביל זה היה שווה כל היום.
אבל זה לא נגמר בזה. הנושא הבא היה נושא השדרוג בין גירסאות. שהוא להזכירכם הביבי של ג'ף. ג'ף הציג מתודה שלמה איך לעשות את זה "נכון", המבוססת על הנסיון העצום שיש לו ולחברה שלו בתחום. מאחר ורוב המשתתפים עשו כבר שדרוגים, ויותר מפעם אחת, גם פה הדיון היה סוער, וגלש לפרטים שבדרך כלל לא מגיעים אליהם בהרצאה רגילה. גם בשביל ההרצאה הזו, היה שווה כל היום. דרך אגב. מי שרוצה לקנות את כל נסיון החיים של ג'ף, בשדרוגים של שרתי SBS הלוך וחזור, מוזמן לרכוש אותו במחיר המגוחך של 200, דולר כולל תמיכה מלאה לאורך כל הדרך.
ההרצאה האחרונה היתה הרצאה של יזהר, ברמה טכנית מאד גבוהה, על קינפוג של מוצר Storage של HP שברמה הנמוכה שלו יכול לעניין את שוק ה SBS. יזהר אינו איש HP, והוא דבר מהשטח ולא מעמדה של PR, מה שהפך את ההרצאה למאד יעילה ופרקטית.
לסיום עלה שוב ג'ף לפודיום ודיבר על חשיבות קבוצות המשתמשים, ועל כיצד נולדה היוזמה, והודה לכל המשתתפים. בשלב הזה המתנו עד שהמרצים גמרו לארוז את המערכות, והם ורוב המשתתפים הלכו לשתות בירה בדרך לבית המלון. אני נאלצתי לוותר על הבירה ולחזור הביתה להשכיב את הילדים לישון. שימו לב כמה אנשים נשארו עד הסוף. אני חושב שאין הוכחה טובה יותר, לכך שהיום הזה תרם רבות למשתתפים שלו. ואני מזכיר לכם, שמי שהשתתף ביום הזה, לא היו אנשים שהמוצר היה חדש להם, אלא כאלה שמכירים את המוצר הזה על בוריו, ועובדים איתו ברמה יומית. כך שאין ספק שהיום הזה היה טוב ומוצלח לכולם וחבל שאין הרבה יוזמות כאלה שבאות מהשטח.
תהליך פיתוח ה Device drivers עובר מהפכה עם ההכרזה על חלונות 8. הכלים עברו שידרוגים, יש סביבת פיתוח חדשה Visual Studio 2011, יש פרוטוקולים חדשים לחיבור Kernel Debugger למערכת ההפעלה, יש הנחיות חדשות לגבי תאימות לתכנית ה Logo, יש כלי Debug ו Testing משופרים, ויש כלי אנליזה ואיתור בעיות חדשים ומשופרים, שמאפשרים לאתר בעיות ותקלות בתחום ה Device Drivers מהר יותר.
החלטתי להרים את הכפפה וביחד עם ג'ון ברייס מכללת הי-טק, אני מרים יום הדרכה שלם, שמוקדש לכל מה שחדש ב Windows 8, מנקודת מבט של תשתית ה Drivers של מערכת ההפעלה. אני יודע שכולם (כולל אני) מתלהבים מממשק המשתמש החדש Metro UI. אבל כל התמיכה של מערכת ההפעלה החדשה ב Sensors וב Touch, מבוססים בסופו של דבר על היכולת של מערכת ההפעלה לתמוך בחמרה שמספקת את המידע הזה. ויש המון חידושים מעניינים בתחום הזה ב Windows 8.
מה יהיה לנו ביום העיון ? מה לא !
נדבר על עולם החמרה החדש והשינוי שהוא יוצר בתחום ה Device Drivers. על שינויים אסטרטגיים במדיניות של מיקרוסופט בתחום ה Device drivers ועל השפעת השינוים האלה על מפתחי Device Driversומפתחי יישומים לחפיצים. נדגים ונסביר סביבת הפיתוח החדשה ל Device Drivers, התוספים החדשים, ותמיכה אחורה. תהליך ה Build החדש, כלי הבדיקה החדשים והישנים שעברו שדרוג. כלי ה Debug החדשים/ישנים, יכולות התממשקות חדשות ל Kernel וכמובן ה Setup האוטומטי של הכלים. נדון גם בהרחבת השימוש ב User Mode Deice Divers ומדוע מיקרוסופט דוחפת את התחום הזה. איך הכל משתלב עם VS Test, יכולות שיווק ומכירה של היישומים בחנות המקוונת החדשה ועוד נושאים מעניינים נוספים שקשורים לנשא הזה.
מי שמעוניין בפרטים נוספים מוזמן לפנות לקישור הבא.
פעם לפני לא הרבה זמן (אתמול), יצא לי לבלות קרוב לשעה (למען הדיוק 49 דקות ועשרים שנית מרגע הכניסה לבניין ועד היציאה עם השלל), בבית מרקחת של השב"כ. שב"כ, למי שלא יודע, זה שרותי בריאות כללית, או בשמו הישן והלא אופנתי "קופת חולים".
השב"כ עבר מהפכה טכנולוגית בשנים האחרונות. הכל מתנהל שם בצורה ממוחשבת ואוטומטית. אתה מגיע למרפאה, מעביר את הכרטיס בכניסה, מקבל פיתקית עם מספר, על הפתקית רשום לך לאיזה חדר ללכת, במקביל הרופא מקבל דיווח שהגעת. כאשר מגיע תורך, רמקולים מנומסים ושילוט אלקטרוני (שכולל פרסומות ממוקדות), מדווחים לך שהגיע זמנך. אתה נכנס לרופא, והתיק הרפואי האלקטרוני שלך כבר על המחשב שלו. מהלך ומסקנות הביקור מוכנסים ישר למחשב, עם מערך קיצורים, שמאפשר לרופא לכתוב משפטים ארוכים בלטינית לא מובנת לקורבן (אני), בלי להתאמץ. אתה יוצא (אם צריך) עם רצפט מודפס. ואם זו בדיקת דם, למשל, אתה יוצא בלי כלום. זה כבר מועבר אוטומטית לאחות שמוצצת לך את הדם ללא מגע יד אדם. ממש שיר הלל לטכנולוגיה.
גם בית המרקחת שודרג, במקום סדרן, או מתקן פתקיות, יש לך עמדה, שאתה מעביר בה את הכרטיס, והיא מוציאה לך פתק עם מספרך בתור. אתה יושב בסבלנות, ומחכה שהרמקול יגיד לך שתורך הגיע, ולאיזה עמדת שרות עליך לגשת, על מנת לקבל את התרופה. ממש המאה העשרים ואחת.
אז מה עושה מומחה לכשל של מערכות, שיושב (לפי ההוראות) על מושב בבית המרקחת, וממתין שהמחשב יאמר לו לגשת לאשנב ? יושב וצופה איך המערכת הטכנולוגית המושלמת, החלום הרטוב של כל טכנולוג, נכשלת פעם אחר פעם, כאשר היא נפגשת עם בן האנוש הממוצע.
בואו ונתחיל בתאור העמדה,
שימו לב למסך (שכולל אפשרות אנגלית ורוסית), שימו לב לאנימציה, שמראה איך להעביר את הכרטיס בקורא. שימו לב להסבר הפשוט והברור "אנא העבר את הכרטיס המגנטי לקבלת פיתקית תור", שימו לב שלכללית מלאו 100 שנים (מזל טוב ליום ההולדת) ואפילו יש שם גם ברוכים הבאים (לגיהנום הטכנולוגי).
שימו לב למדבקות הברורות עם ההוראות בכל צד. זה פשוט כמו אחת שתיים שלוש. לקוח/ה יקר/ה,(פוליטיקלי קורקט, למרות שמבחינת האקדמיה לקוח יקר היה מספיק). 1. אנא העבר כרטיס מגנטי. 2. לאחר העברת הכרטיס תונפק פיתקית עם מספרך בתור. 3. הנך מוזמן לשבת בהמתנה ומספרך יופיע על הצג וגם יוכרז. תודה צוות בית המרקחת. פשוט, ברור, קליט, קריא. כל אידיוט יכול להבין את זה.
הנה תמונה של המסך שמדווח על ההתקדמות של התור (ברשותכם חתכתי ממנו את הפרסומות). רציתי גם להוסיף הקלטה של הכריזה אבל הבנם כבר את הרעיון.
בקיצור מערכת שהיא Idiot Proof. מערכת שלא יכולה להיכשל, נוחה, פשוטה לשימוש, מימשק משתמש ברור, כל מתכנת וכל מנתח מערכת היה חותם על המערכת הזו בעיניים עצומות.
האם אתם מצליחים למצוא את נקודת הכשל ?
אז קודם כל יש המון נקודות כשל, שקשורות להבנת התהליך. המערכת לא יודעת לטפל למשל במי ששכח את הכרטיס בבית. היא גם לא יודעת לתת עדיפות לאמא עם ילדים, שזכאית לפי כללי קופת חולים להכנס לראש התור על מנת להקטין את החשיפה של הילדים לחידקים עמידים. גם אין טיפול במי שהתור שלו דולג, בגלל שהרוקחת היתה זריזה מדי בלחיצה על כפתור הקידום. אבל כל אלה בעיות שקשורות לניתוח המערכת והגדרת התהליכים.
הבעיה העיקרית נובעת דווקא מאי הבנה בסיסית של הטכנולוגיה העיקרית שבה משתמשים במערכת הזו, והבנת והגישה של המשתמש הפשוט לטכנולוגיה הזו. זו בעיה של הבנה לעומק של מימשק המשתמש עם המכונה. ואני לא מתכוון כאן לתכנון המסכים, אלא למשהו הרבה יותר בסיסי. משהו שהיה בולט מייד לעיין אם היו עושים למערכת הזו Usability test בסיסי ו/או אם היו משתמשים באיש מקצוע שבאמת מבין איך להגדיר פרופילו משתמש ואיך להבין את המשמעות של פרופילי המשתמש, על מימשק האדם מכונה.
דרך אגב, אני מוכן להתערב על חבילה מסטיק (שזה המקסימום שאני מוכן להתערב עליו בחיים), שאין בכלל למערכת הזו הגדרה של פרופילי משתמש. אבל בואו נעזוב את הקיטורים שלי על מקצוענות, וגישה אינג'ינרית לתכנה, לפוסט אחר.
הכשל שאני מדבר עליו הוא בקורא הכרטיסים. קורא הכרטיסים הוא נקודת הכניסה (היחידה) למערכת לגבי כל המשתמשים. ועד כמה שזה מפתיע, המשתמש הממוצע לא מכיר את השפה של קורא הכרטיסים. ומה שיותר גרוע, גם התכנה שמשרתת את המשתמש לא מכירה את השפה של קורא הכרטיסים. וגם מי שהגדיר את התרחישים וגם מי שתכנן את המערכת, לא יודעים כלום על השפה הזו. ולכן התקשורת של המערכת עם הקורא (וכמובן עם המשתמש) היא תקשורת של חרשים.
אז למי שלא יודע מה השפה של קורא הכרטיסים להלן מילון בסיסי של מילים ומונחים.
אלמנט שפה ראשון – מנורת Led. יש על הקורא מנורה, שהיא ירוקה כדי להראות שיש חשמל. המנורה הזו מהבהבת בירוק פעם אחד, כדי לדווח על קריאה מוצלחת של כרטיס, והיא הופכת לאדומה לפרק זמן קצר עם הקריאה של הכרטיס אינה מוצלחת.
אלמנט שפה שני, זמזם. יש לקורא צפצפה פנימית שמצפצפת פעם אחת עם הקריאה היתה מוצלחת, ושלוש פעמים עם הקריאה נכשלה.
הערה חשובה, שני אלמנטי השפה הזו לא פועלים אם הכרטיס מוכנס הפוך (פס מגנטי בצד הלא נכון) או אם הכרטיס מוכנס בצורה שלא מתחיל אפילו תהליך קריאה מגנטי. זה גם אלמנט של השפה, כי חוסר תגובה אמור לסמן למשתמש שמשהו לא בסדר.
כמה מהמשתמשים שדגמתי (קרוב לחמישים) ידעו את השפה הזו ? אחד (אני). ואני לא שייך לפרופיל המשתמש הנפוץ של המערכת.
אף אחד מאלמנטי השפה האלה, שהם קריטיים לכל אינטראקציה עם קורא כרטיסים מהסוג הזה, לא שולב כמובן במימשק המשתמש (למרות שלא היה קשה מדי לעשות את זה). ומאחר והמסך הוא מרכז תשומת הלב של המשתמש, גם בזמן שהמשתמש מעביר את הכרטיס. המשתמש לא רואה את המנורה של הקורא, לא מודע למשמעות של הצפצופים, ולא מקבל שום חיווי שמשהו לא בסדר על המסך. יופי נחמה.
אז להלן שלל מקרים, שבכולם התנהגות הלקוח זהה, בהיה במכשיר הטכנולוגי המתוחכם (האויב) שנועד להקל עליו את החיים, בהמתנה סיזיפית לפתקית שלא תגיע. העברת הכרטיס שוב ושוב ביאוש הולך וגדל. פניה לסביבה בבקשת עזרה נואשת (באמת נואשת במקרה של אשה מבוגרת, שמשתמשת בהליכון, ולקח לה כמה דקות טובות למצוא את הכרטיס בארנק).
זה לא יאומן בכמה דרכים לא נכונות ניתן להכניס את הכרטיס לקורא. למי שיש גישה טכנולוגית, זה מראה מייאש (וגם מלמד). ניתן להכניס הפוך (להזכירכם יש שישה צירי תנועה וסימטריה שונים, שבהן ניתן להכניס את הכרטיס הפוך, ואת כולם כמעט ראיתי בפחות משעה). ניתן להכניס מאמצע הקורא. להעביר בקצב מהיר מדי, בקצב איטי מדי, בקצב לא יציב (למי שיש סימנים ראשונים של פרקינגסון, שזה פרופיל חוקי לחלוטין סוג האוכלוסיה של המתקן). ניתן להעביר את כרטיס האשראי או את כרטיס ההנחה של הסופר. דרך אגב, למי שלא יודע, רצוי לא להחזיק בארנק, בצמוד לכרטיס המגנטי, את המדבקה המגנטית שקיבלת מהאינסטלטור לשים על המקרר.
לכל התקלות האלה אין משוב ברור למשתמש. ואני יושב לי בוהה בחלל, מקשיב לצעקות היאוש של קורא הכרטיסים ולתיסכול שלו שאף אחד לא מבין אותו. ומתוך צער בעלי מכונה, אני מתרגם אותו מדי פעם למי שנתקע ומבקש עזרה.
באיזה שהוא שלב התחילו אנשים מסביב להסתכל עלי במבט מוזר ולהתלחש ביניהם (איך לעזזל הוא יודע מה הבעיה, הוא אפילו לה הסתכל איך הוא הכניס את הכרטיס) והאלטרואיסטים דבהם גם הציעו לי עבודה בתור מעביר כרטיסים. למזלי בשלב הזה הגיע תורי לגשת לדלפק. לקחתי את השלל וברחתי משם כל עוד נפשי בי, כשבמוחי עולות מחשבות אלימות במיוחד כלפי מי שאחראי על התכנון והביצוע של המערכת הזו.
למען ההגינות חייבים לציין, שקרוב ל 60 אחוז מהמשתמשים, באו, העבירו, לקחו פתקית והתישבו. אני כמובן התמקדתי רק ב 40 אחוז הנותרים (שזה ארבעים אחוז יותר מדי, בכל קנה מידה).
וכמובן, לסיום, לא יכול להיות שאני אהיה בסביבה של מערכת, ולא תהיה בה התעופפות. אז להלן התעופפות אחת בקטנה.
למה אני מספר לכם את כל זה, כי זה מעצבן אותי, תראו כמה כסף וכמה מאמץ הושקעו כדי לבנות מערכת מיחשוב, שכל תפקידה לשרת את הלקוח (של הקופה). ובסופו של דבר, הלקוח רואה את המערכת הממוחשבת ככשלון, כגורם מפריע, ויוצא עם חווית משתמש רעה. פשוט כואב הלב.
אני די בטוח שמבחינת מנהל הפרויקט ו/או המפתחים ו/או הארכיטקט ו/או הנהלת הקופה, התמונה היא התמונה האידילית שתוארה בשלושת הפיסקאות הראשונות של הפוסט. וחשבתי שאולי נכון לספר להם, שזה בניגוד מוחלט לתמונה שאותה רואה המשתמש הפשוט, שמשתמש במערכת.
יש לי עוד הרבה תובנות ומסקנות על המערכת הזו (ולא רק על זו), אבל גם ככה עברתי את מכסת המילים שלי לפוסט. אם מישהו בשב"כ, שמבין בכלל על מה אני מדבר, קורא את זה, הוא מוזמן להגיב. אם יש לכם חבר בשב"כ, שהנושא בתחום אחריותו, אשמח אם תשלחו לו קישור לפוסט הזה. ואם יצא מזה משהו טוב, אז עשיתי את המעשה הטוב שלי לשנה זו.
למי ששואל מה לי ול IBM, אז התשובה היא הרבה. אני נתקל בהם אצל כל מיני לקוחות. ולמרות הדעה הרווחת, לא רק במערכות מיקרוסופט יש תקלות שדורשות התערבות של שרברב מקצועי לפתרון הבעיות. על אחת כמה וכמה נכון הדבר, כאשר מחברים מערכות מיקרוסופט למערכות IBM כי ראו בדמו איך זה עובד חלק. בקיצור, עולם ה IBM אינו זר לי וההיסטוריה שלי מגיעה אפילו עד התקופה בה התקינו VSE אם זה חשוב למישהו. אז שקיבלתי הזמנה להשתתף בארוע, הסתכלתי על המיקום, ונאנחתי.
יש לי הרבה דברים טובים לומר על Avenu בקריית שדה התעופה (מערך אולמות גמיש מאד, ארגון) אבל הדבר הכי גרוע אצלם זה המיקום. להגיע אליהם בבוקר זה ממש סיוט, כבישים צרים, תחבורה עמוסה, והמון בזבוז זמן בדרך לשם. מארגני הארוע ב IBM נהגו בחכמה רבה שקבעו את התחלת הארוע (התכנסות הרשמה ותערוכת שותפים) ל 8:45 ואת הרצאת המליאה ל 9:45.
החניה גם כן זה נושא מעצבן, אתה משלם 15 ש"ח על חניה בשדה ענק של חול מאחורי המתקן. ומהנסיון שלי בארועי מיקרוסופט, בסוף שהארוע נגמר, אי שם ב 17:00, אין אף אחד שיבדוק ביציאה אם באמת שילמת, ואתה מרגיש פראייר. מצד שני, שעת הסיום של הארוע הנוכחי היא 13:30, אז לך תדע.
אז הפעם, בהשפעת מחאת האוהלים, החלטתי לתרום את התרומה הקטנה שלי למהפכה, ולנקום בבעלי ההון. עקפתי את התור, פניתי בכיכר שמאלה, המשכתי עוד שתי כיכרות ופניתי שוב שמאלה, ומשם למגרש החול החינמי שליד מירס. ובהרגשה שעשיתי משהו למען המהפכה, חציתי את מרכז הקניות שנולד שם, ונכנסתי בשערי הארוע, כשאני מעיף מבט נצחון פירוז על הדוכן לתשלום על החניה. הראיתי להם לבעלי ההון, יחי המהפכה.
בכניסה לארוע היתה תערוכת תדמית על ההיסטוריה של IBM.
מי שלמד את החומר היה יכול לנסות לשחק במשחק טריויה על ההיסטוריה של IBM, שהפרס הוא משהו. ניסיתי את מזלי, ופיספסתי שתי שאלות (משהו שקשור להיסטוריה של הברקוד, ומשהו שקשור ל"במה בדיוק עסק העסק המשפחתי של משפחת ווטסון (CTR) לפני שנהיה רציני והפך ל IBM". למרות זאת הגעתי למקום שביעי (התוצאות נכונות למוקדם בבוקר, ואני לא אחראי להמשך), ואני סקרן לדעת מי זה לעזזל "טסט" שנמצא במקום השלישי, ולמה הוא לא הכניס את שם המשפחה שלו.
בפועל התחילו לקרוא לקהל פנימה ב 10:10 והרצאת המליאה התחילה בסופו של דבר ב 10:25 כי (כמו תמיד) היו פקקים, והרבה לא הספיקו להגיע בזמן. זה איפשר לי לעשות סיבוב מהיר בין הדוכנים כדי לנסות לחפש מכרים.
כשאתה מחפש מה המסרים שמנסים להעביר לך באירוע מהסוג הזה, קודם כל תסתכל על מה המארח (IBM) מציג בדוכנים שלו.
להלן המסרים החשובים, כולם תחת הכותרת Smarter (נחזור לנושא הזה בהרצאת המליאה).
מערכות
כלים
ועוד 23 ספקים שונים (אם לא פיספסתי מישהו) שמספקים שרותים.
הארוע התחיל כמקובל במקומותינו בזמן האחרון בחזיון אורקולי, שהציג את ההיסטוריה של חברת IBM מאז הקמתה. אתם מתבקשים לתת כבוד, אין הרבה חברות בעולם שיכולות לחגוג יום הולדת 100. מבחינה ארגונית ומוסדית, IBM הינה הארגון שנמצא במקום השני בעולם מבחינת אורך חיי הארגון (במקום הראשון נמצאת הכנסיה הקתולית).
מעניין שעם כל הבינלאומיות והגלובאליות, IBM הינה עדיין חברה עם נשמה אמריקאית ומנטליות אמריקאית, והמופע, בהתאמה, היה מאד "אמריקאי".
לאחר המופע עלה לבמה מנחה הארוע הלא הוא מיודעינו נמרוד הראל. תפקידו העיקרי היה לעשות לקהל כל מיני סוגים של בדיקות עירנות ולהראות לנו כלמיני תרגילי טלפטיה ושתילת מחשבות, שמשאירים אותך עם תחושה מדאיגה, שאולי באמת יש אנשים שמסוגלים להחדיר לך לראש כל מיני דברים ושה Metrix ו Inception, הם בעצם לא יותר מתאור עובדתי של המציאות.
לאחר שכולם הפסיקו להאמין במציאות, הזמין נמרוד לבמה את מאיר ניסנזון מנכל י.ב.מ. ישראל לפתוח רשמית את הארוע.
זו לא פעם ראשונה שאני שומע את מאיר מדבר בארועים כאלה, יש לו חוש הומור, שנשמע יבש בשמיעה ראשונה, אבל מסתיר מאחוריו המון חכמת חיים, מהסוג שגורם לפעמים לילדים לפספס את העוקץ. בכלל מעניין לציין בהקשר הזה, שקובצת הגיל והאוכלוסיה בכנסים של IBM, די מובחנת ושונה, מסוג האוכלוסיה וקבוצת הגיל של הכנסים של מיקרוסופט.
בהרצאה שלו דיבר מאיר על 40 השנה שבהם IBM פעילה בארץ (תחשבו על זה, IBM נמצאת בארץ הרבה לפני שזה הפך להיות לטרנד אופנתי בעולם). הוא חילק את התקופה ל 20 השנים הראשונות שבהם התרכזה IBM במכירת ברזלים ול 20 השנים שבאו אחריהם, שבהם שינתה IBM את המודל העיסקי שלה, והפכה מחברה של ברזלים, לחברה של פתרונות (כן, גם ברזלים, אבל גם ובעיקר כל השאר), שכיום 50% מההכנסות שלה באות לא מהברזלים. המהפך הזה, שהחל להתרחש לפני עשרים שנה, המהפך, שבו IBM המציאה את עצמה מחדש, והפכה לחברה ממוקדת פתרונות לקוח, הינה הסיבה העיקרית לכך ש IBM לא נכחדה מהעולם לפני 20, שנה, כשהעולם עבר מקונספט ה MainFrame, לסוג המיחשוב הנפוץ כיום.
כמה מהלקחים שמאיר הזכיר ממה שלמד בגן משך 40 שנה שווים ציטוט: במקום הראשון, הלקוח וצרכי הלקוח במרכז, מי שלא מבין את זה לא ישרוד לאורך זמן. הערת אגב, אתה לא יכול לעשות הכל לבד, שותפים עיסקיים זה חשוב. ומה שאולי התובנה הכי חשובה, בארגון כזה גדול, אין מקום לקבלת החלטות אסטרטגיות, על סמך תחושות בטן. אתה חייב לקחת החלטות מבוססות מידע אמיתי על מה שקורה בשטח. וכדי להיות מסוגל לקחת החלטות כאלה, אתה צריך לחקור, לאסוף מודיעין, ובקיצור לדעת על מה אתה מדבר, ומה הנתונים בשטח, לפני שאתה מקבל את ההחלטה האסטרטגית.
את הלקח הזה, שהחלטות אסטרטגיות בארגון גדול לא לוקחים על סמך תחושות בטן, עוד לא הטמיעו במדינה שלנו. ואנחנו כל פעם מתפלאים מחדש, למה אף אחד לא יודע לאן המדינה שלנו זזה. במחשבה שניה, זה די מדכא, שעוד לא הפנימו אצלנו קברניטי המדינה, שעברנו את תקופת החלוציות, ובממלכה, החלטות אסטרטגיות (בניגוד לטקטיות), צריכות להתבסס על מידע, מודיעין, ונתונים, ועל המצב האמיתי בשטח. אבל יש תקווה, המדינה שלנו רק בת שישים ומשהו.
בשלב הזה מאיר הזמין לבמה את Craig Hayman שנושא בתפקיד המכובד של GM Industry Solutions כדי להרצות לנו על Smarter Commerce.
המסר העיקרי של ההרצאה, היה ש IBM השקיע בשנתיים האחרונות הון כסף (מיליארדים של דולארים), על מנת לחקור וללמוד לעומק את נושא המסחר. כולל קניית כל חברה שיש לה מוצר תכנה, שמתאים לכלים וליכולות הנדרשים ונובעים מתוצאות המחקר הנ"ל. וכיום IBM בנויה לתת לך פלטפורמה מלאה וכוללת לכל מה שאתה צריך, על מנת לעשות Commerce כמו שצריך. בקיצור, קרייג מכר לנו את הפלטפורמה של IBM למכירות, והסביר לנו איך צריך למכור בעולם מודרני. היה שם הכל, מהלקוח במרכז, דרך הלקוח של הלקוח במרכז, שרשרת האספקה, ניהול המוצר, BI על המוצר, בקיצור הכל. כמובן היו כמה סיפורי לקוח בינלאומיים, עם כמה כסף (במיליונים ובמיליארדים) חסך כל אחד מהם, ואפילו כמה מילים בסוף על ישראל.
בשלב הבא עלה לבמה לכמה דקות סיני ברקת מאינטל על מנת לברך את IBM לרגל חגיגות ה 100. הסיבה העיקרית היא שאינטל נתנה חסות לארוע וזה נתן לה הצדקה מלאה להעביר כמה מסרים במליאה. היה קצר, לא היו שקפים, וחבל.
המרצה הבא היה Mark Frazier שהוא לא פחות ולא יותר מאשר ה Chief Architect של AFMC בחיל האויר האמריקאי (USAF). מי שלא יודע מה זה AFMC (ולמה שתדעו) זה Air Force Materiel Command, או בעברית, מנהלת החומרים של חיל האויר האמריקאי, שהמוטו שלה הוא: War-Winning Capabilities …On Time, On Cost. שימו לב שזה לא On Time, On Target, שזה הג'וב של הכוחות הלוחמים, אלא On Time, On Cost, שזה הגוב של מחלקת הלוגיסטיקה, שמספקת את הכלים ללוחמים (כולל תכנון ופיתוח אם צריך).
ההרצאה של מרק התמקדה ב Enterprise Architecture (שזה נושא שמעניין מאד ארגונים מעל סדר גודל מסויים). ובפרויקט שהם עשו ב AFCM על מנת ל הגדיר את ה EA של הארגון שלהם ועל התוצרים והתובנות של הפרויקט הזה. היתה הרצאה מרתקת, לכל מי שיודע מה זה EA. הנושא הזה הינו נושא שיש לו משמעות קריטית, לניהול נכון של תשתית עיבוד הנתונים של ארגונים (מעבר לסדר גודל מסויים). והתעלמות ממנו גורמת לנזקים כספיים ניכרים. הפרויקט מיפה, בין השאר, את כל התהליכים, וכל המימשקים לתהליכים, של הארגון. וכפי שניתן לראות בשקף, מדובר פה על מערך כמעט בלתי ניתן לניהול, של מדיניות, תהליכים, ונוהלים. העבודה שנעשתה איפשרה לכל משתמש רלונטי (וכיום יש עשרות אלפים כאלה במימשל ומחוצה לו), לראות את התלויות בין התהליכים השונים, לאתר כפילויות, ולדעת במדויק מי יושפע כתוצאה משינוי מדיניות מסויים, או תהליך מסויים. מדהים ומרשים מבחינת EA ולא רק.
בפשטות אמריקאית בלתי ניתנת להבנה בארצנו, מסביר מרק, שהמוטיבציה לפרויקט היתה: לחסוך כסף למשלם המיסים (האמריקאי). זה היה השלב שבו נכנסתי ממש לדכאון. מתי בפעם האחרונה, ראיתם גוף ממשלתי אצלנו, שעושה פרויקט התיעלות אסטרטגי רב שנתי, שכל מטרתו היא לחסוך כסף למשלם המיסים ? שימו לב כמה מילים בלתי אפשריות, ולא מוכרות, במימשל שלנו, יש כאן: תכנון אסטרטגי לטווח רחוק, התייעלות, פרויקט רב שנתי, ושיא השיאים "לחסוך כסף למשלם המיסים". לארצות הברית יש מסורת דמוקרטית של מאתיים ומשהו שנים, אנחנו פה רק שישים ומשהו שנים, אולי יש תקווה.
בשלב הזה לאחר עוד כמה תרגילי ערנות של נמרוד הראל (ששולבו גם בין ההרצאות) יצאנו להפסקת קפה, שבה זרקו את כולנו מהאולם של המליאה, ותוך פרק זמן קצר, הפכו אותו לשלושה אולמות נפרדים, שכל אחד מהם נועד למסלול אחר.
כמובן שלוח הזמנים בשלב הזה כבר זז קדימה בצורה משמעותית, ובמקום ב 12:00, הוזזו התחלת הרצאות המסלולים ל 13:10.
מכל המסלולים בחרתי דווקא במסלול של ה Infrastructure. מה לעשות ונושא ה Big Data וגם נושא ה ALM היו לי גם מוכרים, וגם פחות מעניינים. לעומת זאת תחום התשתיות, משך אותי יותר.
המסלול נוהל על ידי דודי כרמי מנהל יחידת השרותים הטכנולוגיים ב IBM.
ההרצאה הראשונה הוגשה על ידי אילן הוכמן, מנהל פיתוח עיסקי באינטל ישראל, שדיבר בעיקר על יכולות מובנות של מערכות אינטל בתחום הוירטואליזציה. הוא דיבר על שיפורים משמעותיים באבטחה בשלב ה BOOT של המחשב הוירטואלי (TXT) , על האבסטרקציה של ה CPU עבור מערכות הפעלה וירטואליות שונות, ועל שיפורים בתחום כרטיסי הרשת, שמאפשרים תת חלוקה של כרטיסי 10GB, בין מכונות וירטואליות, ללא הפסד בביצועים. וכמובן (איך לא) הוא הזכיר את ה Cloud Inovation Center שהוקם במשותף עם IBM, למי שרוצה לחקור את הנושא בואריאנט ה IBM – י שלו.
לאחר מכן עלה לבמה עופר קריצ'מן מישראכרט, שהציג את ההקמה ואת המעבר לפעילות מבצעית, של פרויקט אתר הגיבוי החדש שלהם. זו ההרצאה שהייתי שם במקום השני מבחינת עניין וחשיבות, מיד לאחר ההרצאה של הבחור מחיל האויר האמריקאי. עופר הציג את כל תהליך ה BPM שעמד מאחורי תהליך ה BCP, ואת כל עבודת ה EA שהתבצעה במקביל. השורה התחתונה היתה, שלאחר עבודת הכנה מקיפה (שלקחה את הזמן שלה), בוצע המעבר כולו, תוך פחות מיום עבודה אחד, ובהצלחה. ובתור מומחה לאיתור תקלות במערכות ובתהליכים, אני חייב לתת פה ח"ח (חיזוק חיובי) לצוות ומה שיותר חשוב למנהלים הבכירים יותר בישראכרט, שנתנו לעופר לעשות את זה כמו שצריך באמת לעשות פרויקט כזה.
אחר כל עלה לבמה Bertrand Raillard, שהוא ארכיטקט ענן של IBM. ברטרנד הוא זה שהיה גם הארכיטקט וגם זה שליוה את המעבר של בנק ING בכל התהליך של הקמת הענן הפרטי שלהם. ההרצאה היתה באנגלית עם מבטא צרפתי, אבל החומר היה מעניין מאד, והציג מגוון מרשים של בעיות ארכיטקטוניות, הנובעות בין השאר מכך שהבנק ביצע כמה מיזוגים בימי חייו, ולכן היו בו כמה וכמה איים של טכנולוגיות שונות, של יצרנים שונים ואיים רבים של תהליכים שונים.
ההרצאה האחרונה היתה של עדי גלוון מנהל קבוצת האיחסון של IBM. לעדי היה ברור שהוא במצב בלתי אפשרי, גם לו"ז באיחור עצום, גם חבורת אנשים שכל מה שבראש שלה זה ארוחת הצהריים, שבאה מיד אחרי שהוא גומר את ההרצאה. הוא תקף את זה בכך, שהציג שקף ממחקר שנערך בארה"ב, והראה ששופטים נוטים להחמיר את פסקי הדין שלהם, ככל שמתקרבת שעת ארוחת הצהריים (לתשומת לב עוכרי דין). לאחר מכן, במהירות האור, אבל מבלי להחסיר אף שקף, הציג את מוצרי האיכסון של IBM, כולל סקירה היסטורית (שעליה לדעתי האישית ניתן היה לדלג בלחץ הזמן, תמורת הרחבה נוספת על המוצרים החדשים).
משם יצאו כולם לאוכל, אין לי משהו מעניין לספר לכם על האוכל, ארוחה בסגנון מזנון. אחר כך יצאתי אל האוטו ונכנסתי לפקק הארוך של כל היוצאים מהארוע לכיוון הבית. היה מעניין כמובן, אחרת לא הייתי כותב על זה.
כן, אני יודע שזה נראה מוזר לכל מי שעוסק בתחום ה Device Drivers, אבל סביבת הפיתוח החדשה לפיתוח Device Drivers, היא לא פחות ולא יותר מאשר Visual Studio 2011. להלן כמה פנינים.
Device Drivers לסוגיהן הם סוג פרויקט מוכר ב Visual Studio 2011.
אתה יכול ללחוץ על F5 ולהתחיל לדבג את ה Target או סתם לעשות Attach debuuger ל Kernel.
וכך נראה מסך של KD כחלק אינטגרלי של VS, שכולל אפילו IntelliSense לפקודות של ה Debugger.
ועוד לא אמרתי כלום על Deployment אוטומטי, ועוד המון חידושים שעושים את החיים של מפתח Device Drivers לקלים הרבה יותר. מה אני אגיד לכם, לוקח קצת זמן להתרגל, אבל זה ממכר ברמות.
More Posts
Next page »