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

21 באוקטובר 2014

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

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

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

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

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

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

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

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

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

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

למי שלא יודע, Juval Lowy מגיע לארצנו ב 21/12/14 להעביר את ה Architect's Master Class, שזו הסדנה היחידה בעולם שמלמדת מה צריך ארכיטקט לדעת כדי להיות ארכיטקט מקצועי ואיך ניתן לתכנן ארכיטקטורה בכלים הנדסיים (ולא אומנותיים) . פרטים נוספים בקישור הבא.

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

כתיבת תגובה

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

2 תגובות

  1. שי25 באוקטובר 2014 ב 19:36

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

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

    הגב
    1. Gad J. Meir
      Gad J. Meir25 באוקטובר 2014 ב 22:09

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

      הגב