ערב עם קבוצת המשתמשים עם Juval Lowy על תפקיד הארכיטקט

25 באוקטובר 2010

2 תגובות

בדרך כלל יוצא לי לטוס בלילה לארה"ב. הפעם המראתי על ה 007 של אלעל ב 9:40 בבוקר לניויורק. זה שינוי מרענן לישון בלילה כמו בן אדם, לקום בבוקר, וללכת ליום עבודה, מול המחשב האישי, כאשר אתה יושב על מושב במטוס, במקום במשרד. יש יתרונות לטוס ביום. אז ישבתי וניתחתי Dump – ים ובאיזה שהוא שלב פתחתי את ה Live Writer לכתוב פוסט לבלוג, וגיליתי שם פוסט ישן, על ארוע קבוצת המשתמשים עם  Juval על תפקידו של הארכיטקט, שחיכה להעלאת השקפים לאתר של מיקרוסופט, על מנת שאפרסם אותו.

אני יודע שעבר מאז מפגש קבוצת המשתמשים ב 30/6/2010 כמה חודשים, אבל החומר עדיין רלונטי ומוטב מאוחר מאשר אף פעם. כדאי לציין בהזדמנות זו שאני נוהג להודיע מספק זמן מראש על ארועים שקשורים Juval, הן בבלוג שלי וגם ב LinkedIn, וב FaceBook. כך שמי שמפספס מבצעים וארועים של Juval, שלא יבוא בטענות אלי. אז הנה מה שכתבתי בסוף יוני (עם תוספת בסוף).

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

002 003

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

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

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

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

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

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

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

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

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

After Before

לכל מי שרוצה לבחור בקריירה של ארכיטקט, יש לי בשורה משמחת. Juval מבקר אותנו שוב בסוף דצמבר כדי להעביר את סדנת ה Architect’s Master Class היחודית שלו. שההרצאה שהוא העביר בקבוצת המשתמשים היא חלק קטן מהחומר שאותו הוא מעביר בסדנה. מי שמעוניין להשתתף בסדנא, מוזמן לשלוח דואל לסיגל מייד. יש לנו כבר חצי כיתה מלאה שחלק ממנה ניצל את התעריפים המיוחדים של ה Early Bird, כדי לקבל מחיר הנחה מיוחד. מאחר ויש עוד כמה ימים עד לגמר ה Earl-Bird, מי שיזדרז, עוד יוכל להספיק. זו גם הזדמנות לבקש מסיגל להצטרף לרשימת התפוצה שלנו, כדי שלא תפספסו את הארוע המעניין הבא.

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

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

2 תגובות

  1. ארנון25 באוקטובר 2010 ב 16:52

    אני לא מסכים שארכיטקט לא חייב לקודד

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

    כאשר הצוות קטן (או שיש מספיק ארכיטקטים) כדאי שהארכיטקט יקח חלקים מהפרויקט

    ארנון

    הגב
  2. GadiM31 באוקטובר 2010 ב 12:06

    הי ארנון,

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

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

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

    הגב