בתשובה לתשע נשמות, 08/01/20 20:49
 |
|
 |
||
|
||||
 |
מסתבר שבינתיים מתגלים עוד ליקויים ב7371, חוץ מנושא התוכנה. בואינג בודקת קובץ כבלים שעלולים לקצר ולגרום לקטטסטרופה. הכבלים מעבירים פקודה ממחשב המטוס למנוע ששולט במייצב האחורי כדי להרים או להוריד את האף. הם גם בודקים אם בעיה דומה קיימת בדגם הקודם 737NG עם 6800 מטוסים בשרות (למקס יש הזמנות ל-5000 מטוסים). 1 בכתבה במובייל יש יותר פרטים |
 |
 |
 |
|
|
|
||
|
||||
|
אני מנחש שבכמעט כל מטוס שהיה נבדק ברמת הדקדקנות שבה המקס נבדק עכשיו היו מתגלים ליקויים. מערכות מודרניות - מטוסים, מכוניות, ספינות, כמעט כל דבר שאפשר לדמיין - הן כל-כך מורכבות שאין למעשה יכולת לעלות על כל הבעיות שעלולות להיות קריטיות, או לפחות אין יכולת לעשות זאת בזמן ותקציב סבירים. כאן למשל אפשר לקרוא על מערכת שהצי האמריקאי התקין בספינותיו והיתה אמורה להביא למודרניזציה של השליטה בספינות. המורכבות של המערכת, הלוגיקה הלא ברורה ולא שקופה שלה וההכשרה והנסיון הלקויים של רבים מאלה שהפעילו אותה הביאו להתנגשותה של ספינת הצי ג'ון מקיין בספינת סוחר ולמותם של עשרה מלחים. אגב, זה התחקיר המפורט השני של אתר פרופובליקה על תאונות בצי; התחקיר הקודם שלהם היה על התנגשותה של הספינה פיצג'רלד בספינת סוחר, שגם היא נבעה בחלקה ממערכות מורכבות שלא תפקדו נכון ברגע האמת. שני התחקירים מפורטים ומרתקים (וגם ארוכים, מה לעשות). |
|
|
|
|
|
|
||
|
||||
|
בקשר ליכולת לערוך בדיקות בתקציב סביר, אני אומר בזהירות (כי אני לא מומחה מיסים) שנראה שאולי לבואינג יש כסף לשכור עוד כמה מומחים לנושא. לדוגמא, בניתוח הזה החברה שילמה 8.4% מס פדרלי על כמעט $55 מליארד רווח 2008-2017 (להזכיר שאחרי זה היתה הפחתה משמעותית במס חברות). | |
|
|
|
|
|
||
|
||||
|
האמירה לגבי הזמן והתקציב היא אמירה כללית לגבי כל מערכת מודרנית, לא רק המקס. בדיון אחר עסקנו בחריגות הזמן והתקציב האדירות בכורים גרעיניים: זה מה שקורה כשמתעקשים על הליכי בקרת בטיחות סופר-מפורטים וסופר-דקדקניים. דוגמה אחרת לכך היא תהליכי פיתוח תרופות. בכורים גרעיניים ותרופות מובן למה זה חיוני (אם כי גם בהם יתכן שהגענו להגזמה). בתחומים אחרים נראה שהאנושות מוכנה לקבל מעט תאונות בתמורה להתקדמות טכנולוגית ומחירים כספיים נסבלים. לגבי המקס - ברור שיש להם כסף, כפי שגם ברור שהקרקוע של המטוסים עולה להם הרבה יותר מאשר היה עולה לשכור עוד אלף מומחים (לו היו אלף מומחים לבטיחות מטוסים שניתן לשכור אותם). אם צריך הם גם היו מוצאים כסף למרכיבים אחרים של בדיקות - סימולציות מחשב, בדיקות מעבדה בתנאים שונים וכן הלאה, כל מה שנעשה מן הסתם אבל אפשר היה לעשות יותר. אבל זמן הוא הפקטור השני, ובמקרה של המקס הוא היה פקטור קריטי. המטוס הזה יועד להקדים את איירבוס עם פתרון לשוק מסוים, ותהליך בדיקות ממושך היה מונע את זה. והאמת היא שהם כנראה כלל לא הבינו שעלולה להיות בעיה: נוציא עוד גרסה קצת יותר גדולה ל-737 כפי שאנחנו עושים כבר חמישים שנה, יהיו שינויים קלים אבל שום דבר דרמטי, לא צריך הסמכה חדשה לטייסים, נסמן וי ונתחיל לעשות קופה. יתכן מאד שאילו היו מקדישים טיפה יותר מחשבה למערכת הספציפית הזו זה גם היה מצליח, ובעוד עשר שנים היית רואה אלפי מקסים טסים עם רקורד בטיחות מצוין. ללמדך שרקורד בטיחות מצוין לא מהווה הוכחה לתכנון ובקרה מדוקדקים. |
|
|
|
|
|
|
||
|
||||
|
אכן, אלא שהגבתי ספציפית לעניין המגבלות התקציביות על בקרת האיכות והאמינות. בתגובה אחרת התייחסתי גם לפקטור הזמן ותרומתו השלילית. אלא שעד כמה שאני יודע בתעשיית התעופה מדברים (ועושים) בשנים האחרונות על מושג ''אפס פגמים''. | |
|
|
|
|
|
||
|
||||
|
אבל אין דבר כזה אפס פגמים. לפני שנים רבות למדתי איזשהו קורס של שנה א' במדעי המחשב. המרצה הביא סטטיסטיקות לגבי באגים בתוכנה. לפי הטענה אז, בתוכנה מסחרית ממוצעת אתה יכול למצוא באג בסדר גודל של אחד למאה שורות קוד, ובתוכנה איכותית אחד לאלף; בתוכנה שנבנתה ונבדקה עבור מערכות קריטיות יש בממוצע באג אחד לעשרת אלפים שורות. בתוכנה של מעבורת החלל, כך הוערך שם, יש באג אחד למיליון שורות קוד; בהתאם לכך, התוכנה הזו גם עלתה למשלם המסים האמריקאי אלף דולר לשורה. הבעיה היא שבתוכנה של המעבורת היו עשרה מיליון שורות קוד (אגב, בסטנדרטים של היום זה מעט מאד לפרויקט גדול; אין לי ספק שעל המקס רצות הרבה יותר שורות קוד). אתה לא יכול לאפס פגמים, רק להקטין הסתברויות - ואני מנחש שעל כל אפס שתוסיף אחרי הנקודה בהסתברות אתה תוסיף אפס לפני הנקודה במחיר. | |
|
|
|
|
|
||
|
||||
|
תוכנה זה רק חלק קטן יותר בתשומות שכרוכות בתהליכי הפיתוח ובעיקר, תהליכי הייצור וההרכבה של מטוס. וגם, ופה כהדיוט בנושא אני מסכים עם דב שנראה שהבעיה הספציפית הייתה נעוצה בתכן ובבדיקות. זאת אומרת כנראה בממשק בין הנדסה, ידע מקצועי של טייסים, ומפתחי תוכנה. ובכל מקרה, אם התעשייה הזו מדברת על מטרה של אפס פגמים, אפשר לצפות שהתודעה הזו תחלחל ותנחה את כל התהליכים, כולל למשל שיווק וכספים, שלא לדבר על פיתוח תוכנה, במטרה להשיג אותה או להתקרב אליה כמה שיותר. |
|
|
|
|
|
|
||
|
||||
|
אפס פגמים בתוכנה הוא כמו אפס פגמים בחלקים אחרים של השרשרת: אותו כלל בסיסי פועל בכל מקום. כלל פארטו: אתה יכול להשיג 80% מהתוצאה ב-20% של המאמץ (זמן, אנשים, כסף). גם על ה-20% האלה חל אותו כלל וכן הלאה. לכן בסופו של דבר היחס בין המאמץ השולי שאתה משקיע למספר הפגמים שאתה עדיין יכול להצליח למצוא הופך גבוה מדי. אפס פגמים זה בדיוק סוג המטרות שמנהלים אוהבים לדבר עליהן אבל ברגע האמת הן מתקשות לעמוד מול הלחצים העסקיים. אני בטוח שפולקסווגן כוללת בערכים שלה אמירת אמת והוגנות וגם שמירה על איכות הסביבה, אבל כשהם לא הצליחו לעמוד במבחני הפליטה הם רימו. אם בואינג יודעת שהשתהות של עוד שנה בפיתוח תעלה ב-300 מטוסים שאיירבוס תמכור במקומה, ובהתחשב בזה שהם לא באמת מאמינים שיש פגם מהותי בסחורה שלהם, אז הם ינסו לקצר תהליכים. כתבתי קודם שלדעתי זה לב הענין: כמו שחיל הים לא האמין ב-2006 שלחיזבאללה יש באמת יכולת לסכן את הספינות שלו, כך בואינג לא באמת האמינה שתהיה בעיה אמיתית עם המטוס החדש. היה לה אפילו אינטרס ישיר לא להאמין בכך: היא שאפה שכל טייס שהוסמך על גרסאות 737 קודמות יוכל לקבל הסמכה למקס ללא סימולטור. גם זה גורם משיכה משמעותי מבחינה עסקית. ברגע שאתה מאמין שאין הרבה בעיות אתה לא משקיע הרבה מאמץ בחיפוש אחרי מה שלא קיים. |
|
|
|
|
|
|
||
|
||||
|
בתעשייה המודרנית בכלל ובתעשיית תעופה (וחלל) בפרט מדברים על אפס פגמים. למשל, במקרים מסוימים הגיעו לפגם אחד למליון חלקים (אני זוכר דוגמה מייצור מנועי סילון). ברור שהאתגרים שונים בתחומים שונים של השרשרת אבל זהו כיוון אליו שואפים, כמו שאומר למשל המנשר הזה של תוכנית הוריזון 2020 של האיחוד האירופאי. | |
|
|
|
|
|
||
|
||||
|
אתה יכול להסתכל למשל על רשימת הבאגים האינסופית בפרויקט כמו ה-F-35 כדי לראות שבמערכת כל-כך מורכבת אין אפשרות מעשית להגיע לאפס פגמים. אתה יכול לעשות את זה בתתי-מודולים, אבל ככל שהמערכת גדלה ונעשית מורכבת מספר האפשרויות לפגמים באינטראקציה בין הרכיבים שלה ומספר התרחישים האפשריים לפגמים מבחינת תנאי סביבה ותפעול גדל אקספוננציאלית. אפשר להוריד את ההסתברות להופעת פגמים לרמה נסבלת (ויכול להיות שמה שנגדיר "נסבל" היום הוא נמוך בסדר גודל מאשר מה שהיינו מגדירים לפני עשר או חמש-עשרה שנה), אבל אי אפשר להעלים אותם. | |
|
|
|
|
|
||
|
||||
|
אתה שב וחוזר לתוכנה וכבר הערתי שהתוכנה היא רק מרכיב אחד מהמערכת הכללית - מטוס במקרה הזה - ולמעשה זאת מערכת של מערכות. כפי שכתבתי מקודם, ברור שלמערכות שונות יש אתגרים וקשיים שונים כשמדובר באמינות, יציבות, ביצועים וכו'. | |
|
|
|
|
|
||
|
||||
|
הבעיות ב-F-35 הן לא רק בתוכנה ואני לא הזכרתי כלל את המלה תוכנה. בכל מקרה, אם המטוס הוא מערכת של מערכות אז הדבק שמחבר את כל המערכות האלה הוא התוכנה, והמקום שבו בעיות באינטראקציה בין המערכות אמורות להפתר הוא התוכנה. אבל קח לדוגמה את הסיפור של המקס: אם המערכת מקבלת מהחיישן נתונים נכונים אז היא פועלת כשורה. אם החיישן מעביר נתונים שגויים היא עלולה להפיל את המטוס. זו בעיה בחומרה שעשויה להפתר בעזרת חיישן אמין יותר, או בעיית תוכנה שעשויה להפתר בעזרת תוכנה חכמה יותר שמנתחת את תפקוד החיישן ומזהה חריגות, אבל מבחינה הנדסית טהורה היא לא זה ולא זה - היא בעיה יסודית בתכנון מערכת שיש בה נקודת כשל קריטית ללא יתירות. ככל שיש יותר מערכות תהיינה יותר נקודות כשל כאלה; לחלקן ישימו לב, אבל לא לכולן. ככל שיש יותר מערכות המספר האפשרי של אינטראקציות ביניהן גדל אקספוננציאלית והופך בדיקה יסודית של כל אינטראקציה לבלתי אפשרית. אתן לך דוגמה מתחום אחר לגמרי: יש לנו ידע אמיתי על האינטראקציה בין מספר קטן מאד של תרופות - הנפוצות ביותר, באופן טבעי - וגם שם, הידע הוא בעיקר על אינטראקציות בין זוגות של תרופות כאילו בחלל ריק. אם אתה אדם מבוגר שבולע מדי יום כדורים מחמישה סוגים שונים אז קודם כל, יש סכוי לא זניח שאתה האדם היחיד בעולם עם הקומבינציה הספציפית הזו, אבל גם אם לא - לא הרופא או הרוקח שלך ולא אף אחד אחר יודע להגיד לך איך התרופות האלה מגיבות לקומבינציה הזו. הם יוצאים מהנחה שאין ביניהן אינטראקציה וזהו. ברור שקיימות אינטראקציות שאיש אינו מודע להן, וחלקן מסוכנות - ובכל זאת לא מעשי לבדוק הכל. |
|
|
|
|
|
|
||
|
||||
|
שזה לא ישמע חלילה מעליב, אבל הפירוט שהבאת לא באמת מחדש. מה שאני ניסיתי לספר זה על המאמצים שמושקעים בקידום תפיסה ומתודולוגיות של אפס-פגמים. זה לא אותו דבר כמו אפס תקלות. בהקשר של המקס קראנו שזה נגע לתהליכי התכנון, פיתוח, טסטים, ובקרת איכות שבלשון המעטה נפלו בהם פגמים. כפי שכתבת, אלו לא פגמים מסוג הלא-ידוע-שלא-ידוע בתחם המקצועי (כל התחומים שמעורבים בפרוייקט), אלא פגמים שמקורם כנראה בהחלטות ניהוליות-עסקיות. אם יש קידום של תודעת אפס-פגמים לא היית מצפה שתהליכ הניהול גם יהיו מוכוונים לזה? |
|
|
|
|
|
|
||
|
||||
|
בדיוק. בואינג האיצה את הפיתוח והייצור תוך שהיא מתעלמת מאזהרות עובדים מסיבות עסקיות. יש למטוס שני חיישנים מהסוג שכשל, אבל המערכת השתמשה רק באחד בכל טיסה, וזה למרות שיש לחיישנים האלה היסטוריה בעייתית. תיקון התוכנה שבואינג עשתה אחרי התאונה השניה מפעיל את ה MCAS רק אם הקלט משני החיישנים מתאים, אבל המנכ"ל (שכבר פוטר) אמר שזו לא הודאה באיזה כשל או פגם תכנוני. פחחח. |
|
|
|
|
|
|
||
|
||||
|
בנסיון שלי עם חברות מסחריות לא ראיתי שתהליכי ניהול מכפיפים את עצמם למתודולוגיות שמעמידות מטרה כמו אפס פגמים מעל כל שיקול עסקי. במקרה של המקס, סביר להניח שאם היה רצון אמיתי להגיע לאפס פגמים לא היו מתכננים את המטוס הזה מלכתחילה. הרי יש לנו בסיס שתוכנן בשנות הששים (כשמטוסים התבססו על הידראוליקה ושליטה ידנית בכל פרט ולא על חשמל ושליטה ממוחשבת) כמטוס הרבה יותר קטן, שהוגדל כמה וכמה פעמים. ההגדלה הנוכחית חייבה מנועים גדולים יותר, הם מצדם שינו את מרכז הכובד והביאו לפגיעה באיזון האירודינמי, וכדי לפצות על כך נוצרה מערכת ה-MCAS. אז יש לנו טלאי על גבי טלאי על גבי טלאי על גבי טלאי - ברור מאליו שצורת עבודה כזו לא יכולה להסתדר עם חשיבה של אפס פגמים. אם אתה רוצה לתכנן משהו עם אפס פגמים אתה יכול לעשות את זה על פלטפורמה חדשה, אבל לא על פלטפורמה עתיקה. גישת אפס פגמים אמיתית מחייבת תכנון מלכתחילה למטרה הזו. | |
|
|
|
|
|
||
|
||||
|
אני לא ממוחה לתעופה אבל אני יכול לחשוב על מטוסים אחרים שיש להם דגמים משודרגים שתוכננו מחדש. לאחרונה חיה"א קיבל את הדגם החדש J של ההרקולס, גם ה-F15 עבר שדרוג, אאז"נ B52, וישנן התאמות של מטוסים למשימות ספציפיות כמו הסבה למטוסי תדלוק או רדאר, SUPER GUPPY של נאס"א, ובטח יש עוד. אולי דב יודע יותר. |
|
|
|
|
|
|
||
|
||||
|
ודאי, מטוסים כל הזמן מקבלים שדרוגים. בחלק מהמקרים זה אפילו מוגדר מראש - ב-F-35 למשל מוגדר אילו מטוסים יהיו Block 3 ואילו יהיו Block 4 שיבואו עם יותר יכולות (כאשר בהמשך לפי התכנון ישודרגו המטוסים מהבלוק הקודם). במקרה הזה מדובר בעיקר על עדכוני תוכנה אבל בהחלט לא רק. אחרי הכל מטוס לא מתכננים כמו מכונית, עבור אורך חיי דגם של שמונה שנים עם "מתיחת פנים" באמצע, אלא לעשרות שנים, והשדרוג זה חלק מהענין. אבל זה לא אומר שההרקולס J או המטוסים המוסבים נבנים במתודולוגיה של אפס פגמים. כפי שהערת בצדק בתגובה 712910 כדי לעבוד בגישה של אפס פגמים צריך לתכנן לכך מהבסיס, לא בהטלאה (אגב, זה נכון גם בתוכנה). לכן כתבתי שאילו המטרה היתה אפס פגמים לא היו בונים מטוס על בסיס פלטפורמה שהיא מראש מלאה בפגמים ובאילוצים. | |
|
|
|
|
|
||
|
||||
|
אני חושב שאתה מקצין את זה. לא חייבים גישה של אפס פגמים כדי להקשיב למנהל קו ייצור שאומר שיש לו חששות כבדים לגבי הבטיחות של המטוסים שהוא מוציא תחת ידו. אני מניח שיתירות במערכות קריטיות היא אלף בית של תעופה אזרחית. לכן השימוש של ה MCAS בחיישן אחד בכל פעם נראה לי או כתוצאה עקיפה של הנסיון להשחיל את המקס כשינוי פעוט מדגמים קודמים כדי לזכות בהקלות רגולטוריות, או תוצאה ישירה של רשלנות פושעת, וכנראה שילוב של שניהם. |
|
|
|
|
|
|
||
|
||||
|
אחת הרעות החולות של תעשיית ההיטק שאני חווה בשנים האחרונות - ואולי היא גם חלקן של תעשיות אחרות - היא התייחסות ל-QA כאל סרח עודף וחצי מיותר, שמביא לקיצוץ אכזרי בכמותו, איכותו ומשאביו בכל מצב שצריך לחסוך תקציבים. המגמה הזו כל כך מובהקת, שאני נתקל אפילו במתודולוגיות שחורטות אותה על דגלן, בטענה ש'כל מפתח צריך להיות אחראי לעצמו ולתקינות המוצר שלו ולא לסמוך על רשת הבטיחות של בדיקות האיכות'. הבאגים של ה-737 היו יכולים להתגלות בכמה שלבים, מבדיקות תוכנה קפדניות ועד ניסויי טיסה קפדניים, כמו גם באגים אחרים. |
|
|
|
|
|
|
||
|
||||
|
המוטו של פיתוח התוכנה בחברה שאני עובד בה: תניח שמי שבודק את הקוד שלך אחריך, זה הלקוח. זה לא שאין סוג של QA, זה שאין להם מספיק כוח אדם, משאבים פיזיים וזמן לבדוק את מה שאנחנו מפתחים לפני שזה מגיע ללקוח. יש גם אידאולוגיה מאחורי זה: Agile, כלומר לתת ללקוח גרסה חדשה כל שבועיים או כל חודש, ברגע שיש משהו להראות, ולא משנה אם זה באמת מוכן או לא. |
|
|
|
|
|
|
||
|
||||
|
אז המוטו מטומטם, וגם האידיאולוגיה שמאחוריו. אם אין לך כח אדם ותקציב להוציא מוצר טוב ויציב, אתה מוזמן לבחור מקצוע אחר ולא לפתוח חברת תוכנה. את שאר טענותיי על הAgile הקדוש אשמור לדיון אחר. אגב, מנסיוני בעשרים האחרונים גם ראיתי בעין איך האידיאולוגיה הזו מביאה לכשלונות גדולים, פגיעה באמון הלקוחות ופגיעה מהותית במוצרים וגם בשוק. וברור אגב לחלוטין, בהקשר של הדיון, שמטוס נוסעים הוא לא משהו שיוצא עם עדכון תוכנה כל שבועיים, והמסקנה בהתאם. |
|
|
|
|
|
|
||
|
||||
|
המוצר שלנו הוא חומרה, לא תוכנה. אנשים בכירים ממני (ואולי גם חכמים ממני) הגיעו למסקנה שהלקוח מעדיף לקבל מוצר עם פונקציונליות חלקית כבר היום ועדכונים בכל חודש מאשר לקבל מוצר מוגמר בעוד שנה. כמובן שאין שום דרך שמחלקת QA תהיה מסוגלת לבדוק גרסת תוכנה חדשה כל שבועיים ואפילו לא כל חודש, בעיקר כאשר התוכנה רצה על עשרות גרסאות חומרה שונות, כאשר במעבדות הבדיקה יש אולי 10% מהן. וכמובן, שאנחנו לא מייצרים מטוסי נוסעים או אפילו מכוניות אוטונומיות, אבל בפעם הבאה ששיחת טלפון מתנתקת בפתאומיות, שהסרט שאתה רואה מקרטע, או המשחק שלך לא מצליח להתחבר לשרת המרכזי, תקלל אותנו (לא אותי אישית, למיטב ידיעתי אין לנו לקוחות בארץ). |
|
|
|
|
|
|
||
|
||||
|
האידאולוגיה אולי מטומטמת, אבל מצליחה. אני צריך להגיד מיקרוסופט ומסך המוות הכחול? | |
|
|
|
|
|
||
|
||||
|
כמו שאולי נרמז בתגובה שלי, בחברות שאני הכרתי ומכיר - שהמוצרים שלהם יותר דומים עקרונית למטוס מאשר לתוכנה גרידא, גם אם פחות מסובכים - האידיאולוגיה הזו הובילה לפגיעה ממשית בתוצאות החברה, ללקוחות מעוצבנים שנותנים לך על הראש ולתוצאות עסקיות כושלות. אולי ככה זה כשהלקוחות שלך משלמים הרבה כסף על כל מוצר. אין לי ספק שמייקרוסופט עושים המון בדיקות איכות. |
|
|
|
|
|
|
||
|
||||
|
אנקדוטה: אני מכיר מישהו עם נסיון רב שנים בפיתוח תוכנה וניהול פרוייקטים, שלעת זיקנה יחסית עבד כבודק תוכנה בחברת הזנק שנסגרה לאחר כשנתיים, חברה אליה הגיע כתוצאה מקשרים אישיים עם הבעלים. לאחר הסגירה הוא רצה להמשיך לעבוד בתחום, ושלח קורות חיים לעשרים או שלושים מקומות עבודה פוטנציאליים אליהם הגיע בעיקר דרך alljobs, בהם ציין במפורש שהוא מוכן לעבוד בכל רמה שתידרש, החל מבדיקות תוכנה פרופר בהתאם למפרט מוגדר ע"י המפתחים (לא שזאת פרקטיקה מומלצת, אבל כידוע היא נפוצה למדי) וכלה בנטילת חלק פעיל בתכנון הבדיקות בהתבסס על ניסיונו העשיר. יתר על כן, הבחור, שהוא בעל מיומנות מסוימת בכתיבה1, ניסה סגנונות שונים, כולל כאלה שגרמו לו לזוז באי נוחות מסויימת על הכסא בנוסח "אתם ודאי מחפשים סטודנט צעיר למדעי המחשב, אבל אני מציע לכם לחשוב מחוץ לקופסה בעניין זה בדיוק כפי שאתם מנסים לעשות בפיתוח המוצרים שלכם..." בלה-בלה-בלה. "גם אם אתם סקפטים" כתב בחלק אחר מהמכתבים "אם תזמינו אותי לראיון אתם מסכנים רק כמה דקות מזמנכם, בעוד התועלת האפשרית ממהלך כזה יכולה להתבטא בשנים של תרומה לחברה". לאחר שראיון עבודה אחד אליו הגיע דרך קשרים אישיים נגמר בלא כלום בגלל החשש מ"כישורי יתר", הוא התייחס לזה והסביר לכמה מקומות עבודה שאם הם חוששים מכך חששם אינו מוצדק, שכן המניע העיקרי שלו אינו כלכלי כך שהוא לא יהיה חשוף לפיתויים, ולראיה השנתיים בהן עבד בתפקיד זה. פניות אחרות היו ענייניות לחלוטין בלי שום נימה אישית או חריגה מפורמליות. התוצאות: התעלמות מוחלטת. אפילו לא תשובה שלילית (שזאת, אם תשאלו אותי, סתם נבזות. מה הבעיה לשלוח אימייל מוכן מראש עם "אנחנו מצטערים אבל..."?2). אני משער שרוב המכתבים נזרקו לפח הוירטואלי כבר באיזו חברת כ"א שביצעה את הסינון הראשוני בהתאם לקריטריונים קשוחים שאסור לקרוא להם בשמם, אבל תרשה לי לפקפק בכך שיש מצוקה אמיתית של כ"א בתחום. לפחות בתצוגה המקדימה הכותרת אינה קישור. אם אתם מספיק סקרנים תתאמצו קצת :-) __________ 1- אגב, גם כתיבה טכנית. הוא די גאה במדריך טכני שכתב פעם ובו שילב, תחזיקו חזק, קצת הומור; המוטו המוביל היה מה שהוא כינה "החוק הראשון של כתיבה טכנית" לפיו גם המדריך הטוב ביותר לא שווה הרבה אם לא קוראים אותו. 2-וכן, הוא מודה שכשהוא היה בצד השני של הטרנזקציה מעולם לא התעניין במשרד כ"א איתו עבד אם הם טורחים לעשות זאת, כך שמוסרית הוא לא יכול להתלונן יותר מדי. אני מקווה שאתם אנשים טובים יותר, או לפחות שתהיו כאלה להבא. |
|
|
|
|
|
|
||
|
||||
|
אני לא טוען שיש מצוקת כוח אדם בתחום, אני טוען שיש מצוקת כוח אדם אצלנו, בין השאר, כי רק החודש פיטרו כשליש מאנשי הבדיקות. Agile, אתה יודע. למה צריך אנשי בדיקות אם במילא הם בקושי יכולים לבדוק משהו, כשהם מקבלים את הגרסה החדשה ביחד עם הלקוח? | |
|
|
|
|
|
||
|
||||
|
כמו שהערתי לתשע נשמות, נראה שעולם הייחוס שלכם הוא עולם התוכנה, ומה שנקרא בהכללה היי-טק. בעולמות הפיתוח והייצור - שכוללים כמובן גם תוכנה - נושא האמינות מקבל מימדים שונים מאד. למשל, בעולם הסטארטאפיסטי/תוכנה מקובלת, בנוסף לפיתוח agile, גם תפיסה של פיתוח mvp. בנוסף לזה שהוא מכוון פיתוח מהיר בסבבים מהירים של פונקצונליות חלקית, הוא יכול להיות גם מוכוון, במודע, לפיתוח פונקציונליות שגויה או שתזרק לפח. כשאתה מייצר מכונות, תרופות, צעצועים, משחות שיניים וכיוב', תפיסת העבודה שונה. QA מגיע מאוחר מדי, קצת לפני דלת היציאה. המטרה היא להבטיח (בניגוד לאבטחה) איכות ואמינות עוד בשלבי התכנון והפיתוח. | |
|
|
|
|
|
||
|
||||
|
אם לקוח מוכן לשלם פחות כסף תמורת מוצר איכותי פחות, למה זה "רעה חולה"1? בנוסף לאיכות במוצרים שונים יש חשיבות שונה, יש הבדל - למשל - בין מערכת שיווי המשקל למערכת בידור באותו מטוס. אם מערכת ההפעלה של הטלפון הנייד שלי תתקע, אני אאתחל אותו, אם מערכת ההפעלה של חברת החשמל תתקע, לא יהיה חשמל למאות אלפי אנשים. כל זמן שהלקוחות מודעים לעובדה שהחיסכון נובע מהחיסכון בבדיקת האיכות והחיסכון בבדיקת האיכות לא מתבטא בסיכון בבריאות או בחיים, זה נשמע לי בהחלט לגיטימי ולפעמים אפילו מבורך. המתודולוגיה שגורסת שכל מפתח (למעשה, צוות של מפתחים) צריך להיות אחראי לשירותים שהוא מספק לא באמת שייכת. ז"א גם מי שמשתמש במתודולגיה הזאת יכול לדרוש במקביל בדיקת איכות גבוהה (או נמוכה), רק שמדובר בצוות אחד שעושה את הכל במקום שני צוותים שונים. במקומות בהם ראיתי את זה מתממש העבירו אנשים מבקרת האיכות לצוותי הפיתוח ולא פיטרו אותם. 1 מלבד לרעה הברורה שבאובדן העבודה למי שהתמחה בבקרת איכות. |
|
|
|
|
|
|
||
|
||||
|
יש תחומים שבהם זה "למה לא". הטלפונים הסלולאריים של נוקיה היו עמידים באופן לא רגיל. היתה שאלה פילוסופית כמו השאלה אם אלוהים יכול לברוא עצם שהוא לא יוכל להזיז- האם צ'אק נוריס יכול לשבור נוקיה? עכשיו העולם התרגל שאם מחליק לך הטלפון מהיד על הרצפה תגיד לו שלום. בתמורה המחיר של הניידים הסינים די מצחיק, ואם אתה בכל זאת רוצה לשמור על המכשיר שלך אתה קונה לו הגנות. למה לא? יש איזו סינוסואידה של התכנסות לאופטימום כלשהו בכל מיני מכשירים- בהתחלה המוצרים בנויים לתלפיות, אחר כך בתהליך מזורז הם הופכים לזבל מתפרק, ואז חוזרים לאיכות סבירה. כתבתי פעם על מכונות כביסה, סוללות וכו' בתגובה 645919 אבל מטוס נוסעים? סליחה? מישהו חסר משאלת מוות יטוס במטוס שידוע שהוא זבל מתפרק? |
|
|
|
|
|
|
||
|
||||
|
מטוס נוסעים זה מערכת מאד מורכבת. אם מישהו יציע לי הנחה של 40% בכרטיס הטיסה בידיעה שהאיכות של מערכת הבידור לא נבדקה עד הסוף ואולי אאלץ לאתחל אותה מידי פעם או חס ושלום לקרוא ספר, הייתי הולך על זה בלי להסס. אם זה יהיה במערכת חיונית, לא רק שלא הייתי הולך על זה, אלא הייתי דורש להעמיד את יצרני המטוס לדין. נראה לי שאנחנו מסכימים. | |
|
|
|
|
|
||
|
||||
|
|
|
|
|
|
|
||
|
||||
|
הלקוחות שאני מדבר עליהם לא היו מוכנים למוצר טוב פחות. ולכל בעיה שהם גילו היו השלכות משמעותיות, כולל רכבות אויריות של מהנדסים ומפתחים לאתר הלקוח שעולות הון זמן וכסף. חגבי הפסקה האחרונה - הסיבה שמפתח לא יכול לבדוק לחלוטין את המוצר שהוא פיתח. החל מזה שאף אחד לא רואה את הדבשת שלו, ועד לזה שמפתח הוא לא משתמש, והוא רואה את החלק שלו ולא מכיר הרבה פעמים אפילו את כל המןצר הסופי, ומעטפת השימוש שלו. קל וחומר כשמדובר במערכת מולטידיסציפלינרית, שבסוף הפיזיקה והמכמיקה והתוכנה והחומרה שלהן תלויות הדדית. כמו שטייס לא יכול להכיר את כל הקוד במטוס שלו, כותב תוכנה לא יכול להכיר את כל התרחישים בזמן טיסה. זה בדיוק התפקיד של בקרת האיכות. |
|
|
|
|
|
|
||
|
||||
|
בדיוק. ולכן התוכנה לא כללה את הדבר הפשוט ביותר- ניתוק של המערכת (שמטרתה למנוע הזדקרות, כן?) מעל מהירות מסויימת. | |
|
|
|
|
|
||
|
||||
|
ומאיפה ההנחה שבבקרת איכות היו חושבים על הדבר הזה שנראה לך עכשיו כל כך מתבקש בדיעבד? | |
|
|
|
|
|
||
|
||||
|
המטרה של בקרת איכות היא בדיוק זו - בניית סט תרחישים, מהרגילים ועד אלו שבקצה מעטפת הטיסה, כולל תאונות, תקלות, תקלות חיישנים ושאר ירקות. עם ההסתייגות הטריויאלית שתמיד יהיה תרחיש חריג ומוזר שיימלט מעיני מישהו. ולכן גם ההכשרה הנדרשת מאנשי בקרת איכות - וניסןיי טיסה במקרה הזה - היא לגמרי אחרת משל מהנדסי התוכנה. מהרבה. בחינות, אנשי בקרת האיכות צריכים להיות קרובים יותר לטייסים (המשתמשים באופן כללי יותר), ולידיעת אופני השימוש של המערכת, מאשר למהנדסי התוכנה שצריכים להתמצא במערכות הפעלה, שפות תכנות, לוגיקה חישובית ושאר ירקות. ככאלה - מציאת תרחישי קצה היא בלב הדרישות מאיש בקרת איכות, וודאי במערכות קריטיות כמו מטוסים, ציוד רפואי, מערכות חלל, וכמובן מכוניות בואכה אוטונומיות. אי אז בתחילת ימי הג'יפיאס, הייתי שותף לבחינת המערכות המבצעיות הראשונות במסוקים. בין השאר, לא היססנו להגדיר תצורות טיסה קיצוניות, כולל טיסה הפוכה ותמרונים שממש לא אופייניים למסוקים, כדי לבחון מתי מתנתקת הקליטה של המערכת. איש בקרת איכות/ניסויי טיסה שהחמיץ תרחיש, שקול לאיש תוכנה שאיפשר גלישת זכרון וקריסה של האפליקציה שלו. המקצועיות של שניהם נשפטת בדיוק על פי סיכולם של מקרים כאלה. מי שמצפה מאיש תוכנה למלא את תפקידו של איש בקרת איכות, שרוי באותה פנטזיה כמו מי שמצפה ממהנדס ניסויי טיסה להיות אחראי לשחרור פוינטר ביציאה מפונקציה. |
|
|
|
|
|
|
||
|
||||
|
לא. אבל מה המניעה שאנשי בקרת איכות יהיו באותו הצוות שמפתח? בכל מקרה, זו דרך פיתוח ששימושית במצבים מסוימים, אבל דווקא בואינג לא השתמשה בה. לכן גם אם בדרך הפיתוח של בואינג היו בעיות, זו לא הייתה בעיה בדרך הפיתוח שלהם. לכן לא מועיל לערבב בין הנושאים. |
|
|
|
|
|
|
||
|
||||
|
מה המניעה שאנשי חומרה יהיו בצוות תוכנה ולהיפך? כי אלה למדו הנדסת חשמל, ואלה למדו הנדסת תוכנה. זה שאתה סתם שם את הקו במקום אחר זו פיקציה. הטענה המקורית היתה שמבטלים את מחלקות הqa, ומנסחים אידיאולוגיה לפיה אנשי התוכנה יבדקו את עצמם, לא שמעבירים את אנשי הבדיקות תחת שם אחר למחלקת פיתוח התוכנה. והרי התמרוץ העיקרי של מנהל לצמצום מחלקות הqa הוא שהוא מפטר אנשים וחוסך כסף - את זה רואים ישר בדוחו'ת הרבעוניים - לא שהוא מעביר אנשים ממקום למקום. על זה הוא לא יקבל שום תגמול. |
|
|
|
|
|
|
||
|
||||
|
מה המניעה שבאותו הצוות יהיה גם איש חומרה אחד? אם הצוות צריך לפתח חומרה, יהיה שם גם מפתח חומרה אחד. בכל מקרה, כמו שצוין, מה שמנסים להשיג כאן הוא האצה של תהליכי הפיתוח, ומקבול שלהם. |
|
|
|
|
|
|
||
|
||||
|
נראה לי שאתה מפספס את כל הטיעון שלי, לא יודע איך לענות לך. ברור שמנסים להאיץ את הפיתוח, הטענה שלי היא שזה על חשבון האיכות, ומנהל שאומר אחרת מרמה את החברה ואולי את עצמו. |
|
|
|
|
|
|
||
|
||||
|
יש בשיטה הזאת הרבה בעיות - אבל פגיעה באיכות? למה? | |
|
|
|
|
|
||
|
||||
|
אני מתקשה לרדת לעומק הדיון בינך לבין הפונז, אבל אני חושב שהפרטים הם לא העיקר. העיקר הוא סדר העדיפויות, בעצם התרבות התאגידית של החברה. כאשר הרווח הרבעוני בראש סדר העדיפויות מעגלים פינות כדי להעביר את המטוס מה שיותר מהר דרך הרגולציה, וכדי למנוע הוצ. "מיותרות" של הכשרת הטייסים. כנראה שגם לא עושים את ה QA כמו שצריך. במקרה קיצון, כמו פולקסווגן, פשוט מרמים. כאשר המוניטין והגאווה המקצועית של החברה הם בראש סדר העדיפויות, לא תהיה שום פשרה בנושאי בטיחות של מטוסים. סולם הערכים והתרבות התאגידית הנגזרת ממנו של בואינג היו שונים בעבר. אותם מהנדסים ומנהלי ייצור שהתריעו על הבעיות מחזיקים עדיין בתרבות התאגידית הישנה של בואינג. אחד מהם עזב את החברה, מה שמוכיח את השינוי בסולם הערכים של החברה. |
|
|
|
|
|
|
||
|
||||
|
ובינתיים, טיסה ראשונה של בואינג 777X, שנכנס "לשלב הבא בתהליך הבדיקות הקפדניות". 777X הוא שידרוג של ה-777 ושילוב טכנולוגיות מתקדמות מה-787. |
|
|
|
|
|
|
||
|
||||
|
אם הלקוחות לא מודעים להורדה באיכות והחיסכון לא מתבטא בהוזלה במחיר אלא רק בהגדלת הרווחים זאת כבר רמאות לשמה. אני לא מכיר את התופעה הזאת (לא אומר שהיא לא קיימת). ברור שמפתח לא יכול לבדוק את המוצר שהוא פיתח, הטענה היא שצוות שכולל מפתחים ובודקים יכול לפעול בצורה טובה יותר מאשר שני צוותים נפרדים. מנסיוני, לפעמים זה באמת עובד, לפעמים לא, זה תלוי במוצר, בתרבות הארגונית, בעובדים ובהנהלה. |
|
|
|
|
|
|
||
|
||||
|
אנחנו לגמרי מסכימים לגבי הפסקה האחרונה, היא רק לא דומה לתהליכים שראיתי שקורים במציאות, שבהם מקצצים באנשי הבדיקות ולא סתם מעבירים אותם מקום ישיבה, מהסיבות שציינתי. | |
|
|
|
|
|
||
|
||||
|
לא רק בצורה טובה יותר אלא גם בעלות מופחתת; איש QA משתכר פחות מאיש פיתוח. | |
|
|
|
|
|
||
|
||||
|
ייתכן שזה באמת היה הלך הרוח, אבל בדיעבד תמוה מאד שכאשר הגירסה החדשה מחייבת העתקת המנועים לפנים, ולכן שינויים של מרכז המסה מרכז העילוי, עדיין מתייחסים אליה כאל "עוד גרסה קצת יותר גדולה ל-737 כפי שאנחנו עושים כבר חמישים שנה". לדעתי הם קנו את התכנון החדש בעלי אקספרס. | |
|
|
|
|
|
||
|
||||
|
אני מפנה בפעם השניה תוך שבוע לפסקה השניה ב תגובה 712177 | |
|
|
|
|
|
||
|
||||
|
אני מתפלא על התאגיד עצמו שלקח סיכון עצום, בלי קשר לרגולטור. הייתי בודק אם כמה ממקבלי ההחלטות לא היו ב short על החברה :-) | |
|
|
|
|
|
||
|
||||
|
איזה סיכון? מישהו נכנס לכלא? אחרי שנה של ניהול כושל של המשבר הדירקטוריון החליט ש"צריך שינוי בהנהגה" והמנכ"ל הלך הביתה לפני שבועיים. |
|
|
|
|
|
|
||
|
||||
|
סיכון של כמה עשרות מיליארד דולר, לא? | |
|
|
|
|
|
||
|
||||
|
לא לנושאי המשרה. המנכ''לים מסכנים את הטווח הארוך של החברות שלהם תמורת מחיר המניה בטווח הקצר, שנוגע ישירות לכיס שלהם. |
|
|
|
|
|
|
||
|
||||
|
קנו את התכנון בעלי אקספרס, השאלה באיזה מטוס הטיסו אותו משם. בשעתו אחרי אסון המכביה אמר מישהו ''לא יודע למה אומרים שחיפפנו. דווקא עשינו תכנון מפורט של כל האלמנטים של מבנה הגשר עם שרטוטים מדויקים, ואז תלינו את השרטוטים מצד לצד של הירקון''. |
|
|
|
|
|
|
||
|
||||
|
מסמכים של תכתובות פנימיות שבואינג העבירה לקונגרס מגלים עובדי חברה שהביעו אי אמון במקס עוד בזמן פיתוח הסימולטורים ב 2017-18 ואפילו מוקדם יותר ב-2013. "האם תעלה את המשפחה שלך על מקס שהטייסים עברו אימון בסימולטור שלו? לא אני". | |
|
|
|
|
|
||
|
||||
|
מעניין, בפרט בהתחשב בכך שכפי שכתבתי אחת המטרות העסקיות היתה להגיע להסמכה ללא סימולטור כלל עבור טייסים שכבר הוסמכו ל-737. שעת סימולטור היא עסק יקר מאד וחברה שצריכה להסמיך עשרות ואף מאות טייסים באמצעות סימולטור תשלם מיליונים רבים של דולרים. הטייסים בתאונות הקטלניות לא עברו כל הסמכה על סימולטור לדגם הזה. | |
|
|
|
|
|
||
|
||||
|
למה אגב שעת סימולטור היא כל כך יקרה? מרגע שהוא נבנה, הוא לא חורף דלק או משאבים כמו מטוס, אז מה הבעייה? |
|
|
|
|
|
|
||
|
||||
|
שאלה טובה. חיפוש קצר לא העלה תשובה איכותית. אמנם בניה של סימולטור היא עסק יקר (נדמה לי שהוזכרו עלויות של כמה עשרות מיליוני דולרים עבור מרכז הסימולציה החדש שחיל האוויר התחיל להפעיל לא מזמן) אבל לכאורה התחזוקה של המכניקה והתוכנה והעלויות של צוות ההדרכה לא צריכות להיות יקרות מאד. למרות זאת, לפי הערכת אנליסטים ארוע המקס יעלה לבואינג חמישה מיליארד דולר נוספים אם היא תחייב הסמכה על סימולטור לכל הטייסים. חלק מהסכום הוא גם פיצוי על כך שההכשרה תדחה את חזרת המטוסים לשרות. בארה"ב כולה יש כתריסר סימולטורים של המקס, מהם שישה בבואינג עצמה והיתר אצל לקוחותיה. | |
|
|
|
|
|
||
|
||||
|
אני חושב שהעלות לא מתמקדת רק בשעת הסימולטור, אלא בכך שטייסים שצריכים לעבור הכשרה מלאה למטוס חדש מקבלים שכר בזמן שהם בקורס של כמה ימים, והחברה צריכה לשלם על הקורס הספציפי- מתקנים, אש''ל, מדריכים וכו', או לקבלן משנה שיעביר אותו. | |
|
|
|
|
|
||
|
||||
|
הם מקבלים שכר כל הזמן, אני מניח, אז לא ברור למה ימי הקורס צריכים להתווסף כשכר נוסף. | |
|
|
|
|
|
||
|
||||
|
כן, אבל בימים של ההדרכה הם לא מטיסים אז צוותים אחרים צריכים להטיס במקומם. אם אתה רוצה, מתברר שיש כמה מקומות שבהם אתה יכול להטיס בסימולטור ברמה של חברות תעופה. |
|
|
|
|
|
|
||
|
||||
|
עד כמה שאני יודע, טייסים לא עובדים חמישה ימים בשבוע. אז בחלק מהימים שהם לא טסים הם יכולים על אותו שכר גלובלי ללכת לימי סימולטור, בלי לפגוע בלוח הטיסות. | |
|
|
|
|
|
||
|
||||
|
אני לא יודע מה מבנה השכר של טייסים בחברה אמריקאית, אבל לדעתי טייסים בטיסות פנים עובדים סדר גודל של חמש משמרות בשבוע וטייסים בטיסות בינ''ל נהנים מימי מנוחה בין הטיסות שמוגדרים היטב בחוזים של האיגודים המקצועיים שלהם ואולי מעוגנים בתקנות. אין להם איזה מין ''תפקיד בטייסת'' כמו שיש לטייסים בחיל האוויר. העבודה שלהם היא לטוס, כל דבר אחר לא מכניס כסף לחברה. לדעתי גם הסמכה כזו היא לא ענין של לעשות ימי סימולטור פה ושם. כאמור, יש מספר קטן מאד של סימולטורים. לחברה כמו יונייטד יש סימולטור אחד. אז זה אומר שהטייס מגיע לשם נגיד לשבוע או שבועיים, נמצא במלון ועובר הדרכה ובחינה רציפה עד להסמכה. תכפיל בכמה מאות טייסים וזה לא מעט כסף. אגב, גם לצוות התפעול של הסימולטורים יש מן הסתם עלות לא פעוטה. אני מניח, למשל, שבצוות כזה, מעבר לתפעול הטכני, יש שניים-שלושה טייסים מנוסים ומיומנים שמכירים היטב את המטוס המסומלץ. האנשים האלה אחראים על בניית התרחישים, על התדרוך והתחקור של הטייסים לפני ואחרי סימולציה ועל בלת''מים שהם מכניסים תוך כדי ההטסה. אנשים כאלה עולים הרבה כסף. |
|
|
|
|
|
|
||
|
||||
|
כמה כסף כבר עולים שניים-שלושה מפעילי סימולטורים? מיליון דולר בשנה? זה בוטנים. והם גם עולים למפעילת הסימולטור, לא לחברות התעופה. והם בונים פעם אחת את חבילת התרחישים, וחוזרים עליה שוב ושוב מאות פעמים מול המתאמנים. זה לא שעל כל טייס הם מתחילים הכל מחדש. |
|
|
|
|
|
|
||
|
||||
|
אגב רקורד בטיחות, ה 787 לא הרג אף נוסע ב 10 השנים בהן הוא בשירות. כך גם ה 747-8 (הגרסה האחרונה של 747, 8 שנים), 717 (פיתוח של ה DC-9 הידוע לשמצה, בשירות 20 שנה), וכן אירבאס A340 (בשירות 17 שנים) A380 (בשירות 12 שנים) A350 (חמש שנים) A220 (שלוש שנים), כל משפחת A320neo (ארבע שנים: A319neo, A320neo ו A321neo), ובמפתיע גם משפחת Embraer ERJ הברזילאי Embraer ERJ family [Wikipedia] שבשירות כבר 22 שנה ומ 2003 מיוצרת גם בסין. מסתבר שהמטוסים הפופולריים ביותר הם גם מהבטוחים ביותר: גם משפחת ה A320 (שכוללת את A318 A319 A320 ו A321, בשירות 31 שנים, טסה יותר מ 100 מיליון טיסות, יותר מ 9000 נבנו), היא בטוחה ביותר, וגם משפחת ה 737NG (שכוללת את 737-600/700/800/900, בשירות 22 שנים, טסה יותר מ 100 מיליון טיסות, יותר מ 7000 נבנו). בשתי המשפחות הנפוצות הללו בערך 1 ל 10 מיליון טיסות הרגו נוסעים, וצריך לקחת בחשבון שחלקן היו מטעויות אנוש פרופר. הדגמים הישנים יותר 747-100/200/300 , 737-100/200, 727, איירבוס A300 ו A310, פחות בטוחים בשני סדרי גודל. סדר גודל אחד בכמות התאונות הקטלניות, וסדר גודל נוסף במספר ההרוגים פר תאונה. כולם כבר לא מיוצרים אבל עדיין בשירות. הנתונים מאתר Airsafe ומויקיפדיה. |
|
|
|
|
|
|
||
|
||||
|
מה שאתה בעצם אומר הוא שבעשורים האחרונים ענף התעופה הרבה יותר בטוח. כמו בכבישים, חלק מהשיפור אפשר לייחס לכלי וחלק לשיפורים בהכשרה, בתחזוקה, בפיקוח האווירי, בסביבה הרגולטורית וכדומה. אני מנחש שאם תבדוק היטב תגלה שגם התאונות של הדגמים הישנים התרחשו ברובן בעשורים שקדמו לשנות האלפיים. יש גם נקודה אחרת שנוגעת למחזור החיים של מטוס. חברה לאומית במערב קונה מטוסים חדשים והטייסים שלה בדרך כלל זכו להכשרה טובה, היא גם מתחזקת את המטוסים היטב וכו'. לעומת זאת, מטוסים ותיקים מוטסים על ידי חברות קטנות יותר בדרך כלל, פחות מקצועיות ולעתים קרובות במדינות שבהן הרגולציה חלשה מאד. הם כבר עם הרבה מיילים על הספידומטר והם עשויים לעבור הסבה לתצורה של יותר מושבים לטובת טיסות צ'ארטר ולואו-קוסט או אולי לתצורת מטען, זה לא מוסיף להם בריאות - בקיצור, יש את כל הסיבות לכך שהמטוסים הישנים האלה יפלו גם אם התכנון הבסיסי שלהם היה מוצלח. כמובן, אין גם ספק שמטוס שתוכנן בשיטות של שנות הששים יהיה בעל ''תקרת בטיחות'' נמוכה יותר ממטוס שתוכנן בשנים האחרונות - העולם למד על בטיחות לא מעט בעשורים האלה, וכלי התכנון והבדיקה השתפרו לאין ערוך. |
|
|
|
|
|
|
||
|
||||
|
מסכים עם הכל, עם מספר הסתייגויות. - נראה לי שהדגם יותר חשוב מאשר הגיל של המטוס. למשל- ה A320 תוכנן היטב לנחיתה על המים, מה שתרם להעדר אבידות בנפש בנחיתה המפורסמת על ההדסון. אותו מטוס היה בן 10 ועם 16,000 המראות באמתחתו. במכוניות, בהן אני מבין יותר מאשר במטוסים, לדגם חשיבות בטיחותית הרבה יותר גדולה מאשר לגיל. אישוש חלקי לכך אני מוצא בכך שבדגמים הגרועים גם כמות ההרוגים פר תאונה גדולה בסדר גודל שלם מאשר בדגמים המוצלחים. - לאור התכנון ההרבה יותר בטיחותי של הדגמים החדשים, ה 737 מקס מזדקר עוד יותר לרעה. - אין ספק שהתחזוקה, איכות הטייסים, איכות בקרי הטיסה וכו' כולם גורמים תורמים, ובכל תאונה אחד מהם יכול להיות הגורם המכריע. בדרך כלל תאונה מורכבת מכמה תקלות מצטברות- גם טכניות וגם אנושיות. טייס מנוסה ואיכותי יכול להתגבר לפעמים על תקלות טכניות קשות1, וצוות אנושי גרוע יהפוך תקלה מינורית להתרסקות פטאלית2 ________ 1 סאלי על ההדסון. אחרי שקראתי על התרסקות טיסת אתיופיאן (ההתרסקות השניה של ה 737 מקס) קיבלתי את הרושם שלו סאלנברגר היה שם על ההגאים יש סיכוי טוב שהמטוס היה נוחת בשלום. 2 לדוגמה Pakistan International Airlines Flight 268 [Wikipedia] שהיתה יכולה להמנע בקלות גם על ידי צוות הטיסה וגם על ידי בקרי הטיסה. |
|
|
|
|
|
|
||
|
||||
|
לפי התיאור שלך ב תגובה 712456 של מה שקרה שם גם סאלי לא היה מועיל. מה שעשה על ההדסון היה מעשה ממש מתבקש, ואני חושב שרוב הטייסים שצברו הרבה שעות ניסיון זה בדיוק מה שהיו עושים. לעומת זה לפי התיאור של האירוע באתיופיאן לא הייתה שום דרך לשלוט במטוס. אני חושב שגם קורס מיוחד למקרה כזה אם יקרה לא היה מועיל. אם אחרי שאתה מנתק את המערכת שכשלה אתה מגיע למצב שבו אי אפשר להזיז את הגה הגובה מה תעשה? תפקוד על כל הנוסעים לרוץ לזנב המטוס? (מדגדג לי באצבעות להכניס כאן שוב את הציטוט מדבריך אלי, שנראה לי כאן דווקא מאד מתאים, אבל אני מניח שמיציתי את העניין הזה, ואתגבר הפעם ומכאן ואילך על הדחף הזה.) | |
|
|
|
|
|
||
|
||||
|
לפי תיאור התאונה בויקי Ethiopian Airlines Flight 302 [Wikipedia] הטייסים השאירו בלי כוונה את המנועים בכוח מלא של המראה, מה שהגביר את הכוחות האווירודינמיים על מייצב הגובה אשר מנעו מהם לסובב את הגלגל. לו היה שם איזה סאלנברגר אני מנחש שהוא היה מוצא איזה פתרון. אני לא טייס ואולי אני מדבר שטויות, אבל אולי אפשר היה להוריד כח מנוע ולהוציא מחדש מדפים? | |
|
|
|
|
|
||
|
||||
|
אנחנו נכנסים כאן לשאלות שאיני יודע את התשובה להם. אמרת שאי האפשרות לנתק את הגה הגובה מהמערכת האוטומטית מתרחש עם העלאת המדפים, אבל האם הורדתם גורמת להחזרה של האפשרות הזאת? האם המידע הזה אמור להיות ידוע לטייסים? המנועים פועלים בכוח מלא (או כמעט מלא) מההמראה ולכל אורך הטיפוס עד שהמטוס מגיע לגובה השיוט. האם הסילון שלהם פונה לכיוון הגה הגובה ומגביר את הכוחות שמקשים על הזזתו ממצב שווי המשקל? ואם כן, האם די במצב שבו אין הם פועלים כדי לתת אפשרות להזיזו? במצב רגיל של טיסה כאשר רוצים להגביה את אף המטוס מוסיפים כוח למנוע. אולי במקרה הזה כאשר התברר לטייסים שבגלל חוסר אפשרות לשלוט בהגה הגובה האף מתעקש לא לעלות, היו צריכים להוריד את כוח המנוע וגם להוריד מדפים אפילו ללא קשר לשאלה אם זה יעזור להם לחזור ולשלוט בהגה הגובה, ואולי אפילו להפעיל את מעצורי האוויר כדי להקטין את מהירות הצלילה. איני יודע את התשובות לשאלות האלה, ולכן אולי נחפזתי באמירתי שגם טייס מקצועי יותר לא היה מועיל. המטוס הזה, לפי התיאור, תוכנן להתנהג בצורה מוזרה ביותר, אך איני מכיר את כל פרטי המוזריות שלו. | |
|
|
|
|
|
||
|
||||
|
האם יש לך מידע לפיו ה A320 תוכנן היטב לנחיתה על המים, או שאתה מסיק זאת מתוצאות האירוע הספציפי? | |
|
|
|
|
|
||
|
||||
|
מתוך water landing [Wikipedia] Some aircraft are designed with the possibility of a water landing in mind. Airbus aircraft, for example, feature a "ditching button" which, if pressed, closes valves and openings underneath the aircraft, including the outflow valve, the air inlet for the emergency RAT, the avionics inlet, the extract valve, and the flow control valve. It is meant to slow flooding in a water landing.
|
|
|
|
|
|
|
||
|
||||
|
כתבתי באיזו שהיא תגובה שהעובדה שבתוך המטוס ישנו ציוד הצלה של חגורות הצלה ודוברות מתנפחות מצביע בפרוש על כך שהמתכננים מביאים בחשבון אפשרות שהוא יגיע למים, והציוד הזה יעזור להציל חיים. המידע שהבאת עכשיו מוסיף עוד חיזוק לטענה הזאת. התכנון נעשה תוך מחשבה להגדיל את הסיכוי לשרידות המטוס אם ייאלץ לנחות על המים. הטייס אמור להכיר את תכונות המטוס וייתכן שסאלי היה מודע למידע הזה. אני בכל זאת רוצה לחזור לדבריך הראשונים לפיהם הטייס פעל בניגוד לנוהל. שאלתי בתגובה קודמת מה היה על הטייס לעשות לו המטוס היה בגובה 100 מטר ואמרת שהוא לא היה בגובה כזה. אבל נניח שכן היה. האם נחיתה על המים במקרה כזה היא "בניגוד לנוהל"? קשה לי להאמין שתענה שלפי הנוהל הוא צריך לעשות איזה משהו אחר. ונניח היה בגובה 200 מטר? כמדומני גובה המטוס במקרה שלנו היה 600 מטר והטייס העריך על סמך ניסיונו שהסיכוי להגיע לשדה תעופה קרוב לא קיים. אם הטיס מעריך כך את הסיכוי, הוא צריך לבחור מקום אחר לנחות בו. לו היה איזה כביש רחב וישר קרוב אליו, אולי הוא היה צריך לנחות עליו, וכבר היו דברים מעולם, אם כי ככל היודע לי לא עם מטוס גדול. אבל מה שיש שם זה רק שכונות מגורים. המקום הכי נוח לחיתה הוא על המים ועובדה (שהתחזקה עתה) היא שמתכנני המטוס נתנו את דעתם למקרה של נחיתה על המים. לכן הנחיתה על המים הייתה במקרה זה בדיוק הנוהל. |
|
|
|
|
|
|
||
|
||||
|
לשאלתך על כביש רחב, יש שני כבישים מהירים ורחבים מערבית להדסון שעוברים סמוך לשדה התעופה (הקטן) טיטרבורו. כביש 80 מזרח-מערב, וכביש 95 (NJ Turnpike שמופיע בפתיח של פרקי הסופראנוס) צפון-דרום. משניהם אני חושב ש-95 הוא הכי ישר באזור אבל זה כביש עמוס ביותר, עם המון משאיות. | |
|
|
|
|
|
||
|
||||
|
מה יעזור כביש רחב כשיש לך שתי דקות שלא מספיקות לפנות אותו ממאות מכוניות? כדי לסכן עוד מאות אם לא אלפי אנשים בהתרסקות של מטוס מלא דלק על הראש שלהם? |
|
|
|
|
|
|
||
|
||||
|
אז הלכתי לדו"ח התאונה של ה NTSB ראשית עניינו אותי תוצאות הסימולציה (עמ' 49-50): הסימולציות בוצעו בין 14-16 באפריל, שלשה חדשים אחרי התאונה, ולא כפי שתואר בסרט, במרכז האימונים של איירבאס בצרפת. הסימולטורים תוכנתו לחקות במדויק את תנאי הטיסה הספציפית. הטייסים תודרכו מראש לגבי התמרון שיצטרכו לבצע טרם כניסתם לסימולטור. בזמן הסימולציה הטייסים ביצעו את הצ'קליסט של אבדן שני מנועים אחרי שאיבדו דחף, והסתמכו על הכשרתם וניסיונם כדי להשלים את המבחן. בוצעו שלשה תסריטים: 1. נחיתה רגילה על מסלול 4 בלה גרדיה שמתחילה מגובה 1000 ו 1500 רגל. 2. ניסיון נחיתה בלה גרדיה או טיטרבורו אחרי פגיעת הצפורים, גם כשהסימולציה מתחילה מכל תהליך ההמראה ממסלול 4 בלה גרדיה, וגם כאשר הסימולציה מתחילה מנקודה קצת לפני פגיעת הצפורים. 3. נסיונות נחיתה על ההדסון כשהסימולציה מתחילה מגובה 1500 רגל במהירות 200 קשר1. בתסריט הראשון כל הטייסים הצליחו להנחית את המטוס. בתסריט השני בוצעו 20 ניסיונות מהנקודה קצת לפני פגיעת הצפורים, מהם חמישה נזרקו בגלל נתונים לא טובים או תקלות בסימולטור. מ 15 הנסיונות שנותרו ב 6 הטייס ניסה לנחות על מסלול 22 בלה גרדיה- מתוכם רק 2 הצליחו. ב 7 הטייס ניסה לנחות על מסלול 13 בלה גרדיה- מתוכם 5 הצליחו. ב 2 הטייס ניסה לנחות על מסלול 19 בטיטרבורו- מתוכם אחד הצליח. בנסיונות האלה הפניה המיידית שביצעו הטייסים לא שיקפה את את תנאי העולם האמיתי, בהם נדרש זמן כדי להכיר בהיקף אבדן הדחף ולהחליט על כיוון פעולה. ניסיון אחד בוצע לנחות על מסלול 13 בלה גרדיה עם השהיה של 35 שניות מרגע פגיעת הצפורים, כדי להתאים לתנאי העולם האמיתי, והנחיתה לא היתה מוצלחת. 14 נסיונות בוצעו בתסריט השלישי, מהם 2 נזרקו בגלל נתונים גרועים. 12 הנסיונות הנותרים בוצעו שווה בשווה בשלוש קונפיגורציות מדפים שונות, כולל זו שסאלי בחר. ב 11 מתוכם זוית מסלול הטיסה בזמן הנחיתה היתה בין 1.5%- ל 3.6%- (של סאלי היתה 3.4%-), גדולה מהזווית המוצעת של 0.5%- בנוהל הנחיתה במים. רק באחת, שבוצעה ע"י טייס המבחן של איירבאס, ובה הוא השתמש בטכניקה מיוחדת של איזון המטוס בגובה מטר או שניים מעל המים וניצול אפקט הקרקע להורדת מהירות, היתה זווית של 0.2%- בלבד. המסקנות שלי: - אם טייסים שתודרכו מראש ופנו מייד עם פגיעת הצפורים הצליחו לנחות בשלום רק במחצית המקרים, נראה שהנסיון הבודד עם השהיה של 35 שניות היה רק לצורך סימון וי, כי אם ללא השהיה רק מחצית הנסיונות הצליחו ברור שאחרי ההשהיה אין סיכוי להגיע בשלום לאחד ממסלולי הנחיתה. - לאור הגבוליות של המקרה, אני חושב שטייס פחות מנוסה, ובלי נסיון בדאיה, היה יכול בקלות להעריך שהוא יכול לחזור, ולהתרסק. - לאור תוצאות הסימולציה נראה לי שיש סיכויים גבוהים שגם אותו טייס אוטונומי מתגובה קודמת שלך לא היה מצליח להנחית את המטוס בשלום על אחד המסלולים. לגבי הצ'קליסט (הנוהל) של אבדן שני מנועים (עמוד 52): איירבוס אמרה שהיא תכננה את הנוהל לאבדן שני מנועים לגובה של 20 אלף רגל, ולא תכננה צ'קליסט לאיבוד מנועים בגובה נמוך (הפגיעה במנועים היתה בגובה 2818 רגל). הצ'קליסט כולל שלשה חלקים. בגלל הגובה הנמוך וקוצר הזמן הטייסים של טיסה 1549 הצליחו להשלים רק את רוב שלבי החלק הראשון. המסקנה שלי: אתה צודק. ההחלטה לנחות על ההדסון לא היתה בניגוד לנוהל, וההחלטה לנטוש את הנוהל ולהתמקד בנחיתה היתה טבעית. למרות שלא הגיע לשלב הזה בנוהל, הקפטן הצליח לשמור על מהירות קרובה למהירות הגלישה האופטימלית, ולקבל החלטות נכונות נוספות (להפעיל גנרטור, מדפים שלב 2, מהירות מתאימה אחרי הורדת מדפים) לגבי הציוד של המטוס לנחיתה על המים: המטוס הספציפי היה מצויד באמצעי נטישה על המים (רפסודות הצלה וחגורות הצלה) שלא היה מחוייב בהם לפי התקנות כי נתיב הטיסה שלו לא היה ברובו מעל מים. עם זאת מתוך 150 הנוסעים רק 5 נוסעים לקחו איתם את חגורות ההצלה שמתחת המושב שלהם, עוד 5 לקחו חגורות הצלה ממושבים אחרים, ועוד 21 קיבלו חגורת הצלה מהמטוס אחרי הנטישה. לגבי ההחלטה של הטייס לא לחזור ללה גארדיה: בראיון בפני ה NTSB הטייס אמר שעל בסיס הנתונים של מצב המטוס הוא החליט שלא ניתן לחזור ללה גרדיה. כן הוא ציין שהחלטה לחזור ללה גרדיה היא בלתי הפיכה, ואם היה מנסה לחזור ללה גרדיה ולא מצליח לא היו לו אפשרויות נחיתה אחרות. הוא לא היה יכול להרשות לעצמות לקבל החלטה שגויה, והיה לו בטחון שהוא יוכל להנחית את המטוס בהצלחה על המים. לגבי טיטרבורו הקפטן אמר שהם היו "רחוקים מדי, נמוכים מדי ואטיים מדי". ___________________ 1 מטרת הנסיונות האלה היתה לבחון האם טייסים מצליחים להנחית את המטוס על ההדסון לפי הנחיות הנחיתה על המים, שהיו אמורות לשמור על גוף המטוס שלם. בפועל עקב זווית גדולה יותר, נפגע החלק האחורי של המטוס וקיבל מים, ולא ניתן היה לפתוח ולהשתמש במגלשות האחוריות. |
|
|
|
|
|
|
||
|
||||
|
אני חושב שבמידע שהבאת הפרט הכי חשוב הוא אותה אי הפיכיות שעליה דיבר הטיס בראיון, שעליה גם כתבתי באחת מתגובותיי בנושא. עליו לקבל החלטה מידית. הוא לא יכול לעשות סימולציות, ואין לו מחשב שקובע במהירות את הסיכוי להגיע לאחד המסלולים. הוא צריך להעריך את הסיכוי על סמך ניסיונו ותחושותיו. אם יחליט לחזור והתברר שאי אפשר, אין לו מקום מתאים לנחיתה. לכן החלטתו הייתה נכונה. נראה לי שבסרט ניסו לעשות דרמה כדי להפוך אותו למעניין, בכך שבנקודת זמן מסוימת בחקירה הובע פקפוק בהחלטתו. קשה לי להאמין שכך באמת היה, והקטע הזה בסרט, כפי שכבר כתבתי, די הרגיז אותי. אגב, בגווגל ארת' יש פליית סימולטור וניסיתי לראות אם אני מצליח לנחות ללא מנוע לאחר המראה ממסלול 4 ופנייה שמאלית עד גובה 3000, בערך מהמקום שבו דווח על פגיעת הציפורים. אפשר בסימולטור הזה לבחור אחד משני מטוסים, האחד מטוס קל והשני f161 שבו בחרתי. במהירות 300 קשר2 אני מצליח לנחות הן במסלול 223 הן במסלול 13 והן בטטרבורו או במסלול 19. מסתבר ש 35 שניות הן בסימולציה הזאת כמו נצח. אם המטוס ממשיך בפנייה המתונה שמאלה כמתוכנן אי שום סיכוי להגיע חזרה ללגרדיה. לעומת זה בטטרבורו זה לא משנה כי ממילא מדובר באותו כיוון, והזמן הזה לא משנה שום דבר בניגוד למה שמוצג בסרט. 1 יצא לי פעם "לטוס" בפליית סימולטור של f16 של חיל האוויר, וממש לא מדובר באותן תכונות כמו בסימולטור הזה. 2 זו מהירות הרבה יותר גבוהה מהמהירות שבה היה אותו מטוס במקרה שלנו, אבל מדובר במטוס עם תכונות אחרות וזה אולי מסביר. 3 זה בעצם אותו מסלול ממנו המריא המטוס (4) אבל בכיוון הפוך. |
|
|
|
|
|
|
||
|
||||
|
את ציוד ההצלה במטוס הזכרתי לא כדי לבדוק עד כמה עזר במקרה שלנו אלא כדי להראות שמביאים בחשבון אפשרות שהמטוס ימצא בסופו של דבר את מקומו במים. | |
|
|
| חזרה לעמוד הראשי |  |
| מערכת האייל הקורא אינה אחראית לתוכן תגובות שנכתבו בידי קוראים | |
 RSS מאמרים |
כתבו למערכת |
אודות האתר |
טרם התעדכנת |
ארכיון |
חיפוש |
עזרה |
תנאי שימוש
|
© כל הזכויות שמורות |