בתשובה לאריק, 08/01/20 15:22
תגובה מהירה מאד 712503
כשאתה כותב שלדעתך תקלות תוכנה הן הרבה יותר קשות לתיקון מתקלות חומרה, "האם יש איזה טיעון הגיוני מאחורי זה שאתה לא משתף אותו, או שזו אינטואיציה, תחושת בטן?"
אני, למשל, בטוח בדיוק בהפך, שהרבה יותר קל פשוט ומהיר לפתור בעיות תכנה מאשר בעיות חומרה, וזה כל כך מובן מאליו שכל "טיעון הגיוני" במקרה זה ממש מיותר.
ואני גם חוזר על מה שכתבתי קודם, שאותה תקלה ב737 מקס אינה תקלת תכנה.
תגובה מהירה מאד 712507
אני משווה בין המקרים.
טויוטה "קרקעה" את המכוניות שלה לשבועיים. ה 737 מקס מקורקע כבר 10 חודשים.

אם זו תקלה בתכנון התוכנה מבחינתי ודאי שזו תקלת תוכנה. לדוגמה- ה MCAS לא אמור לפעול בכלל במהירויות גבוהות ושתי ההתרסקויות קרו במהירות גבוהה.

בואינג הודיעה אחרי חודשיים מהקרקוע שהיא השלימה את עדכון התוכנה. מסתבר שהיו בעיות נוספות, כמו זה שהאימון של טייסי המקס להבדלים בינו לבין הדור הקודם היה בדיחה, אבל התקלה עצמה היתה בזה שהתוכנה לא היתה טובה.
תגובה מהירה מאד 712510
ההשוואה שאתה עושה עם מקרה טויוטה היא השוואה מופרכת מכמה סיבות. אתה רואה את התקלה ב 737 מקס כמייצג של תקלת תכנה. אני לא מסכים אתך בעניין זה כפי שאמרתי מספר פעמים אבל ניחא. נניח שבנקודה זו אתה צודק, ובאמת מדובר בתקלת תכנה (קשה לי לומר זאת אפילו כהנחה, אבל מילא). אבל כשאתה משווה שני סוגי תקלות לא רק סיווג התקלה כתכנה או חומרה משחק תפקיד אלא גם גודלה. יכולה להיות תקלת חומרה ענקית ותקלת חומרה קטנה ופשוטה. ויכולה להיות תקלת תכנה ענקית (נניח מה שחשבו על באג 2000 מי שחשבו), ותקלת תכנה פשוטה. אין שום מקום להשוואה. אבל המופרכות עוד יותר בולטת בכך שאתה לוקח שני מקרים מכל סוג ומהם מסיק מסקנות. זה כמו לעשות מדגם על תוצאות בחירות לפי אדם אחד, ולקחת את המפלגה שלה אמר שיצביע ולהגיד שמפלגה זו תקבל את כל המנדטים. טעות היא להסיק מסקנות בצורה כזאת.
תגובה מהירה מאד 712512
אני מסכים עם דב, וחוץ מזה יש עוד דבר - ההבדל בין תעשיית התעופה לתעשיית הרכב מבחינת רגולציה ומהרבה בחינות אחרות לא מאפשר להשוות ביניהן. אם בכל זאת אתה מתעקש להשוות אז אתה יכול להשוות את תקלת המקס לתקלה בכריות האוויר של חברת טקאטה Takata Corporation [Wikipedia]. תחילת הקריאה לריקול של מכוניות שצוידו בכריות החברה היתה עוד ב-‏2013 ועד היום הזה היא לא הסתיימה - אפילו רשימת המכוניות שנזקקות לריקול עדיין לא סופית ורק בחודש הקודם הוספו לה עוד כמיליון וחצי מכוניות. תוך כדי התהליך החברה גם פשטה את הרגל. זה מצב מאד נדיר שבו אחד מהספקים הישירים של מודולים ליצרני הרכב (ספק Tier 1 בעגה המקצועית) מפשל כך שיש צורך לבצע ריקול למכוניותיהם של עשרות יצרנים, אבל בכל מקרה הוא מראה לך כמה קשה לטפל בתקלת חומרה רצינית.
תגובה מהירה מאד 712514
מסתבר שבינתיים מתגלים עוד ליקויים ב7371, חוץ מנושא התוכנה. בואינג בודקת קובץ כבלים שעלולים לקצר ולגרום לקטטסטרופה. הכבלים מעבירים פקודה ממחשב המטוס למנוע ששולט במייצב האחורי כדי להרים או להוריד את האף. הם גם בודקים אם בעיה דומה קיימת בדגם הקודם 737NG עם 6800 מטוסים בשרות (למקס יש הזמנות ל-‏5000 מטוסים).

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

כאן למשל אפשר לקרוא על מערכת שהצי האמריקאי התקין בספינותיו והיתה אמורה להביא למודרניזציה של השליטה בספינות. המורכבות של המערכת, הלוגיקה הלא ברורה ולא שקופה שלה וההכשרה והנסיון הלקויים של רבים מאלה שהפעילו אותה הביאו להתנגשותה של ספינת הצי ג'ון מקיין בספינת סוחר ולמותם של עשרה מלחים. אגב, זה התחקיר המפורט השני של אתר פרופובליקה על תאונות בצי; התחקיר הקודם שלהם היה על התנגשותה של הספינה פיצג'רלד בספינת סוחר, שגם היא נבעה בחלקה ממערכות מורכבות שלא תפקדו נכון ברגע האמת. שני התחקירים מפורטים ומרתקים (וגם ארוכים, מה לעשות).
תגובה מהירה מאד 712516
בקשר ליכולת לערוך בדיקות בתקציב סביר, אני אומר בזהירות (כי אני לא מומחה מיסים) שנראה שאולי לבואינג יש כסף לשכור עוד כמה מומחים לנושא. לדוגמא, בניתוח הזה החברה שילמה 8.4% מס פדרלי על כמעט $55 מליארד רווח 2008-2017 (להזכיר שאחרי זה היתה הפחתה משמעותית במס חברות).
תגובה מהירה מאד 712517
האמירה לגבי הזמן והתקציב היא אמירה כללית לגבי כל מערכת מודרנית, לא רק המקס. בדיון אחר עסקנו בחריגות הזמן והתקציב האדירות בכורים גרעיניים: זה מה שקורה כשמתעקשים על הליכי בקרת בטיחות סופר-מפורטים וסופר-דקדקניים. דוגמה אחרת לכך היא תהליכי פיתוח תרופות. בכורים גרעיניים ותרופות מובן למה זה חיוני (אם כי גם בהם יתכן שהגענו להגזמה). בתחומים אחרים נראה שהאנושות מוכנה לקבל מעט תאונות בתמורה להתקדמות טכנולוגית ומחירים כספיים נסבלים.

לגבי המקס - ברור שיש להם כסף, כפי שגם ברור שהקרקוע של המטוסים עולה להם הרבה יותר מאשר היה עולה לשכור עוד אלף מומחים (לו היו אלף מומחים לבטיחות מטוסים שניתן לשכור אותם). אם צריך הם גם היו מוצאים כסף למרכיבים אחרים של בדיקות - סימולציות מחשב, בדיקות מעבדה בתנאים שונים וכן הלאה, כל מה שנעשה מן הסתם אבל אפשר היה לעשות יותר. אבל זמן הוא הפקטור השני, ובמקרה של המקס הוא היה פקטור קריטי. המטוס הזה יועד להקדים את איירבוס עם פתרון לשוק מסוים, ותהליך בדיקות ממושך היה מונע את זה. והאמת היא שהם כנראה כלל לא הבינו שעלולה להיות בעיה: נוציא עוד גרסה קצת יותר גדולה ל-‏737 כפי שאנחנו עושים כבר חמישים שנה, יהיו שינויים קלים אבל שום דבר דרמטי, לא צריך הסמכה חדשה לטייסים, נסמן וי ונתחיל לעשות קופה. יתכן מאד שאילו היו מקדישים טיפה יותר מחשבה למערכת הספציפית הזו זה גם היה מצליח, ובעוד עשר שנים היית רואה אלפי מקסים טסים עם רקורד בטיחות מצוין. ללמדך שרקורד בטיחות מצוין לא מהווה הוכחה לתכנון ובקרה מדוקדקים.
תגובה מהירה מאד 712518
אכן, אלא שהגבתי ספציפית לעניין המגבלות התקציביות על בקרת האיכות והאמינות. בתגובה אחרת התייחסתי גם לפקטור הזמן ותרומתו השלילית. אלא שעד כמה שאני יודע בתעשיית התעופה מדברים (ועושים) בשנים האחרונות על מושג ''אפס פגמים''.
תגובה מהירה מאד 712559
אבל אין דבר כזה אפס פגמים. לפני שנים רבות למדתי איזשהו קורס של שנה א' במדעי המחשב. המרצה הביא סטטיסטיקות לגבי באגים בתוכנה. לפי הטענה אז, בתוכנה מסחרית ממוצעת אתה יכול למצוא באג בסדר גודל של אחד למאה שורות קוד, ובתוכנה איכותית אחד לאלף; בתוכנה שנבנתה ונבדקה עבור מערכות קריטיות יש בממוצע באג אחד לעשרת אלפים שורות. בתוכנה של מעבורת החלל, כך הוערך שם, יש באג אחד למיליון שורות קוד; בהתאם לכך, התוכנה הזו גם עלתה למשלם המסים האמריקאי אלף דולר לשורה. הבעיה היא שבתוכנה של המעבורת היו עשרה מיליון שורות קוד (אגב, בסטנדרטים של היום זה מעט מאד לפרויקט גדול; אין לי ספק שעל המקס רצות הרבה יותר שורות קוד). אתה לא יכול לאפס פגמים, רק להקטין הסתברויות - ואני מנחש שעל כל אפס שתוסיף אחרי הנקודה בהסתברות אתה תוסיף אפס לפני הנקודה במחיר.
תגובה מהירה מאד 712564
תוכנה זה רק חלק קטן יותר בתשומות שכרוכות בתהליכי הפיתוח ובעיקר, תהליכי הייצור וההרכבה של מטוס. וגם, ופה כהדיוט בנושא אני מסכים עם דב שנראה שהבעיה הספציפית הייתה נעוצה בתכן ובבדיקות. זאת אומרת כנראה בממשק בין הנדסה, ידע מקצועי של טייסים, ומפתחי תוכנה.

ובכל מקרה, אם התעשייה הזו מדברת על מטרה של אפס פגמים, אפשר לצפות שהתודעה הזו תחלחל ותנחה את כל התהליכים, כולל למשל שיווק וכספים, שלא לדבר על פיתוח תוכנה, במטרה להשיג אותה או להתקרב אליה כמה שיותר.
תגובה מהירה מאד 712606
אפס פגמים בתוכנה הוא כמו אפס פגמים בחלקים אחרים של השרשרת: אותו כלל בסיסי פועל בכל מקום. כלל פארטו: אתה יכול להשיג 80% מהתוצאה ב-‏20% של המאמץ (זמן, אנשים, כסף). גם על ה-‏20% האלה חל אותו כלל וכן הלאה. לכן בסופו של דבר היחס בין המאמץ השולי שאתה משקיע למספר הפגמים שאתה עדיין יכול להצליח למצוא הופך גבוה מדי.

אפס פגמים זה בדיוק סוג המטרות שמנהלים אוהבים לדבר עליהן אבל ברגע האמת הן מתקשות לעמוד מול הלחצים העסקיים. אני בטוח שפולקסווגן כוללת בערכים שלה אמירת אמת והוגנות וגם שמירה על איכות הסביבה, אבל כשהם לא הצליחו לעמוד במבחני הפליטה הם רימו. אם בואינג יודעת שהשתהות של עוד שנה בפיתוח תעלה ב-‏300 מטוסים שאיירבוס תמכור במקומה, ובהתחשב בזה שהם לא באמת מאמינים שיש פגם מהותי בסחורה שלהם, אז הם ינסו לקצר תהליכים. כתבתי קודם שלדעתי זה לב הענין: כמו שחיל הים לא האמין ב-‏2006 שלחיזבאללה יש באמת יכולת לסכן את הספינות שלו, כך בואינג לא באמת האמינה שתהיה בעיה אמיתית עם המטוס החדש. היה לה אפילו אינטרס ישיר לא להאמין בכך: היא שאפה שכל טייס שהוסמך על גרסאות 737 קודמות יוכל לקבל הסמכה למקס ללא סימולטור. גם זה גורם משיכה משמעותי מבחינה עסקית. ברגע שאתה מאמין שאין הרבה בעיות אתה לא משקיע הרבה מאמץ בחיפוש אחרי מה שלא קיים.
תגובה מהירה מאד 712625
בתעשייה המודרנית בכלל ובתעשיית תעופה (וחלל) בפרט מדברים על אפס פגמים. למשל, במקרים מסוימים הגיעו לפגם אחד למליון חלקים (אני זוכר דוגמה מייצור מנועי סילון). ברור שהאתגרים שונים בתחומים שונים של השרשרת אבל זהו כיוון אליו שואפים, כמו שאומר למשל המנשר הזה של תוכנית הוריזון 2020 של האיחוד האירופאי.
תגובה מהירה מאד 712799
אתה יכול להסתכל למשל על רשימת הבאגים האינסופית בפרויקט כמו ה-F-35 כדי לראות שבמערכת כל-כך מורכבת אין אפשרות מעשית להגיע לאפס פגמים. אתה יכול לעשות את זה בתתי-מודולים, אבל ככל שהמערכת גדלה ונעשית מורכבת מספר האפשרויות לפגמים באינטראקציה בין הרכיבים שלה ומספר התרחישים האפשריים לפגמים מבחינת תנאי סביבה ותפעול גדל אקספוננציאלית. אפשר להוריד את ההסתברות להופעת פגמים לרמה נסבלת (ויכול להיות שמה שנגדיר "נסבל" היום הוא נמוך בסדר גודל מאשר מה שהיינו מגדירים לפני עשר או חמש-עשרה שנה), אבל אי אפשר להעלים אותם.
תגובה מהירה מאד 712800
אתה שב וחוזר לתוכנה וכבר הערתי שהתוכנה היא רק מרכיב אחד מהמערכת הכללית - מטוס במקרה הזה - ולמעשה זאת מערכת של מערכות. כפי שכתבתי מקודם, ברור שלמערכות שונות יש אתגרים וקשיים שונים כשמדובר באמינות, יציבות, ביצועים וכו'.
תגובה מהירה מאד 712803
הבעיות ב-F-35 הן לא רק בתוכנה ואני לא הזכרתי כלל את המלה תוכנה. בכל מקרה, אם המטוס הוא מערכת של מערכות אז הדבק שמחבר את כל המערכות האלה הוא התוכנה, והמקום שבו בעיות באינטראקציה בין המערכות אמורות להפתר הוא התוכנה. אבל קח לדוגמה את הסיפור של המקס: אם המערכת מקבלת מהחיישן נתונים נכונים אז היא פועלת כשורה. אם החיישן מעביר נתונים שגויים היא עלולה להפיל את המטוס. זו בעיה בחומרה שעשויה להפתר בעזרת חיישן אמין יותר, או בעיית תוכנה שעשויה להפתר בעזרת תוכנה חכמה יותר שמנתחת את תפקוד החיישן ומזהה חריגות, אבל מבחינה הנדסית טהורה היא לא זה ולא זה - היא בעיה יסודית בתכנון מערכת שיש בה נקודת כשל קריטית ללא יתירות. ככל שיש יותר מערכות תהיינה יותר נקודות כשל כאלה; לחלקן ישימו לב, אבל לא לכולן. ככל שיש יותר מערכות המספר האפשרי של אינטראקציות ביניהן גדל אקספוננציאלית והופך בדיקה יסודית של כל אינטראקציה לבלתי אפשרית.

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

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

לאחרונה חיה"א קיבל את הדגם החדש J של ההרקולס, גם ה-F15 עבר שדרוג, אאז"נ B52, וישנן התאמות של מטוסים למשימות ספציפיות כמו הסבה למטוסי תדלוק או רדאר, SUPER GUPPY של נאס"א, ובטח יש עוד.

אולי דב יודע יותר.
תגובה מהירה מאד 712991
ודאי, מטוסים כל הזמן מקבלים שדרוגים. בחלק מהמקרים זה אפילו מוגדר מראש - ב-F-35 למשל מוגדר אילו מטוסים יהיו Block 3 ואילו יהיו Block 4 שיבואו עם יותר יכולות (כאשר בהמשך לפי התכנון ישודרגו המטוסים מהבלוק הקודם). במקרה הזה מדובר בעיקר על עדכוני תוכנה אבל בהחלט לא רק. אחרי הכל מטוס לא מתכננים כמו מכונית, עבור אורך חיי דגם של שמונה שנים עם "מתיחת פנים" באמצע, אלא לעשרות שנים, והשדרוג זה חלק מהענין. אבל זה לא אומר שההרקולס J או המטוסים המוסבים נבנים במתודולוגיה של אפס פגמים. כפי שהערת בצדק בתגובה 712910 כדי לעבוד בגישה של אפס פגמים צריך לתכנן לכך מהבסיס, לא בהטלאה (אגב, זה נכון גם בתוכנה). לכן כתבתי שאילו המטרה היתה אפס פגמים לא היו בונים מטוס על בסיס פלטפורמה שהיא מראש מלאה בפגמים ובאילוצים.
תגובה מהירה מאד 712884
אני חושב שאתה מקצין את זה.
לא חייבים גישה של אפס פגמים כדי להקשיב למנהל קו ייצור שאומר שיש לו חששות כבדים לגבי הבטיחות של המטוסים שהוא מוציא תחת ידו.

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

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

הבאגים של ה-‏737 היו יכולים להתגלות בכמה שלבים, מבדיקות תוכנה קפדניות ועד ניסויי טיסה קפדניים, כמו גם באגים אחרים.
שחרור קיטור חצי קשור 712898
המוטו של פיתוח התוכנה בחברה שאני עובד בה: תניח שמי שבודק את הקוד שלך אחריך, זה הלקוח.
זה לא שאין סוג של QA, זה שאין להם מספיק כוח אדם, משאבים פיזיים וזמן לבדוק את מה שאנחנו מפתחים לפני שזה מגיע ללקוח.
יש גם אידאולוגיה מאחורי זה: Agile, כלומר לתת ללקוח גרסה חדשה כל שבועיים או כל חודש, ברגע שיש משהו להראות, ולא משנה אם זה באמת מוכן או לא.
שחרור קיטור חצי קשור 712899
אז המוטו מטומטם, וגם האידיאולוגיה שמאחוריו.
אם אין לך כח אדם ותקציב להוציא מוצר טוב ויציב, אתה מוזמן לבחור מקצוע אחר ולא לפתוח חברת תוכנה.
את שאר טענותיי על הAgile הקדוש אשמור לדיון אחר.

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

וברור אגב לחלוטין, בהקשר של הדיון, שמטוס נוסעים הוא לא משהו שיוצא עם עדכון תוכנה כל שבועיים, והמסקנה בהתאם.
שחרור קיטור חצי קשור 712903
המוצר שלנו הוא חומרה, לא תוכנה.
אנשים בכירים ממני (ואולי גם חכמים ממני) הגיעו למסקנה שהלקוח מעדיף לקבל מוצר עם פונקציונליות חלקית כבר היום ועדכונים בכל חודש מאשר לקבל מוצר מוגמר בעוד שנה.
כמובן שאין שום דרך שמחלקת QA תהיה מסוגלת לבדוק גרסת תוכנה חדשה כל שבועיים ואפילו לא כל חודש, בעיקר כאשר התוכנה רצה על עשרות גרסאות חומרה שונות, כאשר במעבדות הבדיקה יש אולי 10% מהן.
וכמובן, שאנחנו לא מייצרים מטוסי נוסעים או אפילו מכוניות אוטונומיות, אבל בפעם הבאה ששיחת טלפון מתנתקת בפתאומיות, שהסרט שאתה רואה מקרטע, או המשחק שלך לא מצליח להתחבר לשרת המרכזי, תקלל אותנו (לא אותי אישית, למיטב ידיעתי אין לנו לקוחות בארץ).
שחרור קיטור חצי קשור 712906
האידאולוגיה אולי מטומטמת, אבל מצליחה. אני צריך להגיד מיקרוסופט ומסך המוות הכחול?
שחרור קיטור חצי קשור 712934
כמו שאולי נרמז בתגובה שלי, בחברות שאני הכרתי ומכיר - שהמוצרים שלהם יותר דומים עקרונית למטוס מאשר לתוכנה גרידא, גם אם פחות מסובכים - האידיאולוגיה הזו הובילה לפגיעה ממשית בתוצאות החברה, ללקוחות מעוצבנים שנותנים לך על הראש ולתוצאות עסקיות כושלות.

אולי ככה זה כשהלקוחות שלך משלמים הרבה כסף על כל מוצר.

אין לי ספק שמייקרוסופט עושים המון בדיקות איכות.
https://www.youtube.com/watch?v=heCrp9EYJw4 712911
אנקדוטה:

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

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

התוצאות: התעלמות מוחלטת. אפילו לא תשובה שלילית (שזאת, אם תשאלו אותי, סתם נבזות. מה הבעיה לשלוח אימייל מוכן מראש עם "אנחנו מצטערים אבל..."?‏2). אני משער שרוב המכתבים נזרקו לפח הוירטואלי כבר באיזו חברת כ"א שביצעה את הסינון הראשוני בהתאם לקריטריונים קשוחים שאסור לקרוא להם בשמם, אבל תרשה לי לפקפק בכך שיש מצוקה אמיתית של כ"א בתחום.

לפחות בתצוגה המקדימה הכותרת אינה קישור. אם אתם מספיק סקרנים תתאמצו קצת :-)
__________
1- אגב, גם כתיבה טכנית. הוא די גאה במדריך טכני שכתב פעם ובו שילב, תחזיקו חזק, קצת הומור; המוטו המוביל היה מה שהוא כינה "החוק הראשון של כתיבה טכנית" לפיו גם המדריך הטוב ביותר לא שווה הרבה אם לא קוראים אותו.
2-וכן, הוא מודה שכשהוא היה בצד השני של הטרנזקציה מעולם לא התעניין במשרד כ"א איתו עבד אם הם טורחים לעשות זאת, כך שמוסרית הוא לא יכול להתלונן יותר מדי. אני מקווה שאתם אנשים טובים יותר, או לפחות שתהיו כאלה להבא.
https://www.youtube.com/watch?v=heCrp9EYJw4 712917
אני לא טוען שיש מצוקת כוח אדם בתחום, אני טוען שיש מצוקת כוח אדם אצלנו, בין השאר, כי רק החודש פיטרו כשליש מאנשי הבדיקות. Agile, אתה יודע. למה צריך אנשי בדיקות אם במילא הם בקושי יכולים לבדוק משהו, כשהם מקבלים את הגרסה החדשה ביחד עם הלקוח?
שחרור קיטור חצי קשור 712910
כמו שהערתי לתשע נשמות, נראה שעולם הייחוס שלכם הוא עולם התוכנה, ומה שנקרא בהכללה היי-טק. בעולמות הפיתוח והייצור - שכוללים כמובן גם תוכנה - נושא האמינות מקבל מימדים שונים מאד. למשל, בעולם הסטארטאפיסטי/תוכנה מקובלת, בנוסף לפיתוח agile, גם תפיסה של פיתוח mvp. בנוסף לזה שהוא מכוון פיתוח מהיר בסבבים מהירים של פונקצונליות חלקית, הוא יכול להיות גם מוכוון, במודע, לפיתוח פונקציונליות שגויה או שתזרק לפח. כשאתה מייצר מכונות, תרופות, צעצועים, משחות שיניים וכיוב', תפיסת העבודה שונה. QA מגיע מאוחר מדי, קצת לפני דלת היציאה. המטרה היא להבטיח (בניגוד לאבטחה) איכות ואמינות עוד בשלבי התכנון והפיתוח.
שחרור קיטור חצי קשור 712919
אם לקוח מוכן לשלם פחות כסף תמורת מוצר איכותי פחות, למה זה "רעה חולה"‏1? בנוסף לאיכות במוצרים שונים יש חשיבות שונה, יש הבדל - למשל - בין מערכת שיווי המשקל למערכת בידור באותו מטוס. אם מערכת ההפעלה של הטלפון הנייד שלי תתקע, אני אאתחל אותו, אם מערכת ההפעלה של חברת החשמל תתקע, לא יהיה חשמל למאות אלפי אנשים. כל זמן שהלקוחות מודעים לעובדה שהחיסכון נובע מהחיסכון בבדיקת האיכות והחיסכון בבדיקת האיכות לא מתבטא בסיכון בבריאות או בחיים, זה נשמע לי בהחלט לגיטימי ולפעמים אפילו מבורך.

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

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

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

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

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

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

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

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

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

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

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

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

777X הוא שידרוג של ה-‏777 ושילוב טכנולוגיות מתקדמות מה-‏787.
שחרור קיטור חצי קשור 713004
אם הלקוחות לא מודעים להורדה באיכות והחיסכון לא מתבטא בהוזלה במחיר אלא רק בהגדלת הרווחים זאת כבר רמאות לשמה. אני לא מכיר את התופעה הזאת (לא אומר שהיא לא קיימת).

ברור שמפתח לא יכול לבדוק את המוצר שהוא פיתח, הטענה היא שצוות שכולל מפתחים ובודקים יכול לפעול בצורה טובה יותר מאשר שני צוותים נפרדים. מנסיוני, לפעמים זה באמת עובד, לפעמים לא, זה תלוי במוצר, בתרבות הארגונית, בעובדים ובהנהלה.
שחרור קיטור חצי קשור 713010
אנחנו לגמרי מסכימים לגבי הפסקה האחרונה, היא רק לא דומה לתהליכים שראיתי שקורים במציאות, שבהם מקצצים באנשי הבדיקות ולא סתם מעבירים אותם מקום ישיבה, מהסיבות שציינתי.
שחרור קיטור חצי קשור 713018
לא רק בצורה טובה יותר אלא גם בעלות מופחתת; איש QA משתכר פחות מאיש פיתוח.
תגובה מהירה מאד 712527
ייתכן שזה באמת היה הלך הרוח, אבל בדיעבד תמוה מאד שכאשר הגירסה החדשה מחייבת העתקת המנועים לפנים, ולכן שינויים של מרכז המסה מרכז העילוי, עדיין מתייחסים אליה כאל "עוד גרסה קצת יותר גדולה ל-‏737 כפי שאנחנו עושים כבר חמישים שנה". לדעתי הם קנו את התכנון החדש בעלי אקספרס.
תגובה מהירה מאד 712530
אני מפנה בפעם השניה תוך שבוע לפסקה השניה ב תגובה 712177
תגובה מהירה מאד 712536
אני מתפלא על התאגיד עצמו שלקח סיכון עצום, בלי קשר לרגולטור. הייתי בודק אם כמה ממקבלי ההחלטות לא היו ב short על החברה :-)
תגובה מהירה מאד 712539
איזה סיכון? מישהו נכנס לכלא?
אחרי שנה של ניהול כושל של המשבר הדירקטוריון החליט ש"צריך שינוי בהנהגה" והמנכ"ל הלך הביתה לפני שבועיים.
תגובה מהירה מאד 712541
סיכון של כמה עשרות מיליארד דולר, לא?
תגובה מהירה מאד 712542
לא לנושאי המשרה.
המנכ''לים מסכנים את הטווח הארוך של החברות שלהם תמורת מחיר המניה בטווח הקצר, שנוגע ישירות לכיס שלהם.
תגובה מהירה מאד 712560
קנו את התכנון בעלי אקספרס, השאלה באיזה מטוס הטיסו אותו משם.
בשעתו אחרי אסון המכביה אמר מישהו ''לא יודע למה אומרים שחיפפנו. דווקא עשינו תכנון מפורט של כל האלמנטים של מבנה הגשר עם שרטוטים מדויקים, ואז תלינו את השרטוטים מצד לצד של הירקון''.
תוכנן ע''י ליצנים, נוהל ע''י קופים 712583
מסמכים של תכתובות פנימיות שבואינג העבירה לקונגרס מגלים עובדי חברה שהביעו אי אמון במקס עוד בזמן פיתוח הסימולטורים ב 2017-18 ואפילו מוקדם יותר ב-‏2013. "האם תעלה את המשפחה שלך על מקס שהטייסים עברו אימון בסימולטור שלו? לא אני".
תוכנן ע''י ליצנים, נוהל ע''י קופים 712607
מעניין, בפרט בהתחשב בכך שכפי שכתבתי אחת המטרות העסקיות היתה להגיע להסמכה ללא סימולטור כלל עבור טייסים שכבר הוסמכו ל-‏737. שעת סימולטור היא עסק יקר מאד וחברה שצריכה להסמיך עשרות ואף מאות טייסים באמצעות סימולטור תשלם מיליונים רבים של דולרים. הטייסים בתאונות הקטלניות לא עברו כל הסמכה על סימולטור לדגם הזה.
תוכנן ע''י ליצנים, נוהל ע''י קופים 712608
למה אגב שעת סימולטור היא כל כך יקרה?
מרגע שהוא נבנה, הוא לא חורף דלק או משאבים כמו מטוס, אז מה הבעייה?
תוכנן ע''י ליצנים, נוהל ע''י קופים 712609
שאלה טובה. חיפוש קצר לא העלה תשובה איכותית. אמנם בניה של סימולטור היא עסק יקר (נדמה לי שהוזכרו עלויות של כמה עשרות מיליוני דולרים עבור מרכז הסימולציה החדש שחיל האוויר התחיל להפעיל לא מזמן) אבל לכאורה התחזוקה של המכניקה והתוכנה והעלויות של צוות ההדרכה לא צריכות להיות יקרות מאד. למרות זאת, לפי הערכת אנליסטים ארוע המקס יעלה לבואינג חמישה מיליארד דולר נוספים אם היא תחייב הסמכה על סימולטור לכל הטייסים. חלק מהסכום הוא גם פיצוי על כך שההכשרה תדחה את חזרת המטוסים לשרות. בארה"ב כולה יש כתריסר סימולטורים של המקס, מהם שישה בבואינג עצמה והיתר אצל לקוחותיה.
תוכנן ע''י ליצנים, נוהל ע''י קופים 712610
אני חושב שהעלות לא מתמקדת רק בשעת הסימולטור, אלא בכך שטייסים שצריכים לעבור הכשרה מלאה למטוס חדש מקבלים שכר בזמן שהם בקורס של כמה ימים, והחברה צריכה לשלם על הקורס הספציפי- מתקנים, אש''ל, מדריכים וכו', או לקבלן משנה שיעביר אותו.
תוכנן ע''י ליצנים, נוהל ע''י קופים 712616
הם מקבלים שכר כל הזמן, אני מניח, אז לא ברור למה ימי הקורס צריכים להתווסף כשכר נוסף.
תוכנן ע''י ליצנים, נוהל ע''י קופים 712619
כן, אבל בימים של ההדרכה הם לא מטיסים אז צוותים אחרים צריכים להטיס במקומם.
אם אתה רוצה, מתברר שיש כמה מקומות שבהם אתה יכול להטיס בסימולטור ברמה של חברות תעופה.
תוכנן ע''י ליצנים, נוהל ע''י קופים 712623
עד כמה שאני יודע, טייסים לא עובדים חמישה ימים בשבוע. אז בחלק מהימים שהם לא טסים הם יכולים על אותו שכר גלובלי ללכת לימי סימולטור, בלי לפגוע בלוח הטיסות.
תוכנן ע''י ליצנים, נוהל ע''י קופים 712801
אני לא יודע מה מבנה השכר של טייסים בחברה אמריקאית, אבל לדעתי טייסים בטיסות פנים עובדים סדר גודל של חמש משמרות בשבוע וטייסים בטיסות בינ''ל נהנים מימי מנוחה בין הטיסות שמוגדרים היטב בחוזים של האיגודים המקצועיים שלהם ואולי מעוגנים בתקנות. אין להם איזה מין ''תפקיד בטייסת'' כמו שיש לטייסים בחיל האוויר. העבודה שלהם היא לטוס, כל דבר אחר לא מכניס כסף לחברה. לדעתי גם הסמכה כזו היא לא ענין של לעשות ימי סימולטור פה ושם. כאמור, יש מספר קטן מאד של סימולטורים. לחברה כמו יונייטד יש סימולטור אחד. אז זה אומר שהטייס מגיע לשם נגיד לשבוע או שבועיים, נמצא במלון ועובר הדרכה ובחינה רציפה עד להסמכה. תכפיל בכמה מאות טייסים וזה לא מעט כסף.

אגב, גם לצוות התפעול של הסימולטורים יש מן הסתם עלות לא פעוטה. אני מניח, למשל, שבצוות כזה, מעבר לתפעול הטכני, יש שניים-שלושה טייסים מנוסים ומיומנים שמכירים היטב את המטוס המסומלץ. האנשים האלה אחראים על בניית התרחישים, על התדרוך והתחקור של הטייסים לפני ואחרי סימולציה ועל בלת''מים שהם מכניסים תוך כדי ההטסה. אנשים כאלה עולים הרבה כסף.
תוכנן ע''י ליצנים, נוהל ע''י קופים 712809
כמה כסף כבר עולים שניים-שלושה מפעילי סימולטורים? מיליון דולר בשנה? זה בוטנים. והם גם עולים למפעילת הסימולטור, לא לחברות התעופה.
והם בונים פעם אחת את חבילת התרחישים, וחוזרים עליה שוב ושוב מאות פעמים מול המתאמנים. זה לא שעל כל טייס הם מתחילים הכל מחדש.
תגובה מהירה מאד 712529
אגב רקורד בטיחות, ה 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 ומויקיפדיה.
תגובה מהירה מאד 712561
מה שאתה בעצם אומר הוא שבעשורים האחרונים ענף התעופה הרבה יותר בטוח. כמו בכבישים, חלק מהשיפור אפשר לייחס לכלי וחלק לשיפורים בהכשרה, בתחזוקה, בפיקוח האווירי, בסביבה הרגולטורית וכדומה. אני מנחש שאם תבדוק היטב תגלה שגם התאונות של הדגמים הישנים התרחשו ברובן בעשורים שקדמו לשנות האלפיים.

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

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

- נראה לי שהדגם יותר חשוב מאשר הגיל של המטוס. למשל- ה A320 תוכנן היטב לנחיתה על המים, מה שתרם להעדר אבידות בנפש בנחיתה המפורסמת על ההדסון. אותו מטוס היה בן 10 ועם 16,000 המראות באמתחתו. במכוניות, בהן אני מבין יותר מאשר במטוסים, לדגם חשיבות בטיחותית הרבה יותר גדולה מאשר לגיל. אישוש חלקי לכך אני מוצא בכך שבדגמים הגרועים גם כמות ההרוגים פר תאונה גדולה בסדר גודל שלם מאשר בדגמים המוצלחים.
- לאור התכנון ההרבה יותר בטיחותי של הדגמים החדשים, ה 737 מקס מזדקר עוד יותר לרעה.
- אין ספק שהתחזוקה, איכות הטייסים, איכות בקרי הטיסה וכו' כולם גורמים תורמים, ובכל תאונה אחד מהם יכול להיות הגורם המכריע. בדרך כלל תאונה מורכבת מכמה תקלות מצטברות- גם טכניות וגם אנושיות. טייס מנוסה ואיכותי יכול להתגבר לפעמים על תקלות טכניות קשות‏1, וצוות אנושי גרוע יהפוך תקלה מינורית להתרסקות פטאלית‏2

________
1 סאלי על ההדסון. אחרי שקראתי על התרסקות טיסת אתיופיאן (ההתרסקות השניה של ה 737 מקס) קיבלתי את הרושם שלו סאלנברגר היה שם על ההגאים יש סיכוי טוב שהמטוס היה נוחת בשלום.
2 לדוגמה Pakistan International Airlines Flight 268 [Wikipedia] שהיתה יכולה להמנע בקלות גם על ידי צוות הטיסה וגם על ידי בקרי הטיסה.
תגובה מהירה מאד 712581
לפי התיאור שלך ב תגובה 712456 של מה שקרה שם גם סאלי לא היה מועיל. מה שעשה על ההדסון היה מעשה ממש מתבקש, ואני חושב שרוב הטייסים שצברו הרבה שעות ניסיון זה בדיוק מה שהיו עושים. לעומת זה לפי התיאור של האירוע באתיופיאן לא הייתה שום דרך לשלוט במטוס. אני חושב שגם קורס מיוחד למקרה כזה אם יקרה לא היה מועיל. אם אחרי שאתה מנתק את המערכת שכשלה אתה מגיע למצב שבו אי אפשר להזיז את הגה הגובה מה תעשה? תפקוד על כל הנוסעים לרוץ לזנב המטוס? (מדגדג לי באצבעות להכניס כאן שוב את הציטוט מדבריך אלי, שנראה לי כאן דווקא מאד מתאים, אבל אני מניח שמיציתי את העניין הזה, ואתגבר הפעם ומכאן ואילך על הדחף הזה.)
תגובה מהירה מאד 712585
לפי תיאור התאונה בויקי Ethiopian Airlines Flight 302 [Wikipedia] הטייסים השאירו בלי כוונה את המנועים בכוח מלא של המראה, מה שהגביר את הכוחות האווירודינמיים על מייצב הגובה אשר מנעו מהם לסובב את הגלגל. לו היה שם איזה סאלנברגר אני מנחש שהוא היה מוצא איזה פתרון. אני לא טייס ואולי אני מדבר שטויות, אבל אולי אפשר היה להוריד כח מנוע ולהוציא מחדש מדפים?
תגובה מהירה מאד 712586
אנחנו נכנסים כאן לשאלות שאיני יודע את התשובה להם. אמרת שאי האפשרות לנתק את הגה הגובה מהמערכת האוטומטית מתרחש עם העלאת המדפים, אבל האם הורדתם גורמת להחזרה של האפשרות הזאת? האם המידע הזה אמור להיות ידוע לטייסים? המנועים פועלים בכוח מלא (או כמעט מלא) מההמראה ולכל אורך הטיפוס עד שהמטוס מגיע לגובה השיוט. האם הסילון שלהם פונה לכיוון הגה הגובה ומגביר את הכוחות שמקשים על הזזתו ממצב שווי המשקל? ואם כן, האם די במצב שבו אין הם פועלים כדי לתת אפשרות להזיזו? במצב רגיל של טיסה כאשר רוצים להגביה את אף המטוס מוסיפים כוח למנוע. אולי במקרה הזה כאשר התברר לטייסים שבגלל חוסר אפשרות לשלוט בהגה הגובה האף מתעקש לא לעלות, היו צריכים להוריד את כוח המנוע וגם להוריד מדפים אפילו ללא קשר לשאלה אם זה יעזור להם לחזור ולשלוט בהגה הגובה, ואולי אפילו להפעיל את מעצורי האוויר כדי להקטין את מהירות הצלילה. איני יודע את התשובות לשאלות האלה, ולכן אולי נחפזתי באמירתי שגם טייס מקצועי יותר לא היה מועיל. המטוס הזה, לפי התיאור, תוכנן להתנהג בצורה מוזרה ביותר, אך איני מכיר את כל פרטי המוזריות שלו.
תגובה מהירה מאד 712582
האם יש לך מידע לפיו ה A320 תוכנן היטב לנחיתה על המים, או שאתה מסיק זאת מתוצאות האירוע הספציפי?
תגובה מהירה מאד 712584
מתוך 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.
תגובה מהירה מאד 712587
כתבתי באיזו שהיא תגובה שהעובדה שבתוך המטוס ישנו ציוד הצלה של חגורות הצלה ודוברות מתנפחות מצביע בפרוש על כך שהמתכננים מביאים בחשבון אפשרות שהוא יגיע למים, והציוד הזה יעזור להציל חיים. המידע שהבאת עכשיו מוסיף עוד חיזוק לטענה הזאת. התכנון נעשה תוך מחשבה להגדיל את הסיכוי לשרידות המטוס אם ייאלץ לנחות על המים. הטייס אמור להכיר את תכונות המטוס וייתכן שסאלי היה מודע למידע הזה.
אני בכל זאת רוצה לחזור לדבריך הראשונים לפיהם הטייס פעל בניגוד לנוהל. שאלתי בתגובה קודמת מה היה על הטייס לעשות לו המטוס היה בגובה 100 מטר ואמרת שהוא לא היה בגובה כזה. אבל נניח שכן היה. האם נחיתה על המים במקרה כזה היא "בניגוד לנוהל"? קשה לי להאמין שתענה שלפי הנוהל הוא צריך לעשות איזה משהו אחר. ונניח היה בגובה 200 מטר? כמדומני גובה המטוס במקרה שלנו היה 600 מטר והטייס העריך על סמך ניסיונו שהסיכוי להגיע לשדה תעופה קרוב לא קיים. אם הטיס מעריך כך את הסיכוי, הוא צריך לבחור מקום אחר לנחות בו. לו היה איזה כביש רחב וישר קרוב אליו, אולי הוא היה צריך לנחות עליו, וכבר היו דברים מעולם, אם כי ככל היודע לי לא עם מטוס גדול. אבל מה שיש שם זה רק שכונות מגורים. המקום הכי נוח לחיתה הוא על המים ועובדה (שהתחזקה עתה) היא שמתכנני המטוס נתנו את דעתם למקרה של נחיתה על המים. לכן הנחיתה על המים הייתה במקרה זה בדיוק הנוהל.
תגובה מהירה מאד 712591
לשאלתך על כביש רחב, יש שני כבישים מהירים ורחבים מערבית להדסון שעוברים סמוך לשדה התעופה (הקטן) טיטרבורו. כביש 80 מזרח-מערב, וכביש 95 (NJ Turnpike שמופיע בפתיח של פרקי הסופראנוס) צפון-דרום. משניהם אני חושב ש-‏95 הוא הכי ישר באזור אבל זה כביש עמוס ביותר, עם המון משאיות.
תגובה מהירה מאד 712593
מה יעזור כביש רחב כשיש לך שתי דקות שלא מספיקות לפנות אותו ממאות מכוניות?
כדי לסכן עוד מאות אם לא אלפי אנשים בהתרסקות של מטוס מלא דלק על הראש שלהם?
תגובה מהירה מאד 712595
אז הלכתי לדו"ח התאונה של ה 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 מטרת הנסיונות האלה היתה לבחון האם טייסים מצליחים להנחית את המטוס על ההדסון לפי הנחיות הנחיתה על המים, שהיו אמורות לשמור על גוף המטוס שלם. בפועל עקב זווית גדולה יותר, נפגע החלק האחורי של המטוס וקיבל מים, ולא ניתן היה לפתוח ולהשתמש במגלשות האחוריות.
תגובה מהירה מאד 712596
אני חושב שבמידע שהבאת הפרט הכי חשוב הוא אותה אי הפיכיות שעליה דיבר הטיס בראיון, שעליה גם כתבתי באחת מתגובותיי בנושא. עליו לקבל החלטה מידית. הוא לא יכול לעשות סימולציות, ואין לו מחשב שקובע במהירות את הסיכוי להגיע לאחד המסלולים. הוא צריך להעריך את הסיכוי על סמך ניסיונו ותחושותיו. אם יחליט לחזור והתברר שאי אפשר, אין לו מקום מתאים לנחיתה. לכן החלטתו הייתה נכונה. נראה לי שבסרט ניסו לעשות דרמה כדי להפוך אותו למעניין, בכך שבנקודת זמן מסוימת בחקירה הובע פקפוק בהחלטתו. קשה לי להאמין שכך באמת היה, והקטע הזה בסרט, כפי שכבר כתבתי, די הרגיז אותי.
אגב, בגווגל ארת' יש פליית סימולטור וניסיתי לראות אם אני מצליח לנחות ללא מנוע לאחר המראה ממסלול 4 ופנייה שמאלית עד גובה 3000, בערך מהמקום שבו דווח על פגיעת הציפורים. אפשר בסימולטור הזה לבחור אחד משני מטוסים, האחד מטוס קל והשני f16‏1 שבו בחרתי. במהירות 300 קשר‏2 אני מצליח לנחות הן במסלול 22‏3 הן במסלול 13 והן בטטרבורו או במסלול 19. מסתבר ש 35 שניות הן בסימולציה הזאת כמו נצח. אם המטוס ממשיך בפנייה המתונה שמאלה כמתוכנן אי שום סיכוי להגיע חזרה ללגרדיה. לעומת זה בטטרבורו זה לא משנה כי ממילא מדובר באותו כיוון, והזמן הזה לא משנה שום דבר בניגוד למה שמוצג בסרט.

1 יצא לי פעם "לטוס" בפליית סימולטור של f16 של חיל האוויר, וממש לא מדובר באותן תכונות כמו בסימולטור הזה.
2 זו מהירות הרבה יותר גבוהה מהמהירות שבה היה אותו מטוס במקרה שלנו, אבל מדובר במטוס עם תכונות אחרות וזה אולי מסביר.
3 זה בעצם אותו מסלול ממנו המריא המטוס (4) אבל בכיוון הפוך.
תגובה מהירה מאד 712597
את ציוד ההצלה במטוס הזכרתי לא כדי לבדוק עד כמה עזר במקרה שלנו אלא כדי להראות שמביאים בחשבון אפשרות שהמטוס ימצא בסופו של דבר את מקומו במים.
תגובה מהירה מאד 721021
החזרת אותי לפתיל הזה ואני לא יודע אם אנחנו לא מסכימים על העובדות או רק על התיוג שלהן.
הנה הסיפור כפי שאני מכיר אותו:
איירבאס השיקה את פרויקט הדור החדש של משפחת 320 - ה 320neo - בדצמבר 2010. המיקוד של הדגם החדש היה על חסכון בדלק ועלויות אחזקה לעומת הדגם הקודם (ואכן בפועל הראה שיפור משמעותי של 15% בצריכת הדלק ובעלויות האחזקה), בעיקר על ידי שימוש במנועים חדשים.
ביוני 2011 קיבל הדגם החדש כבר יותר מ 1000 הזמנות, מספר שיא למטוס מסחרי חדש.
בואינג נכנסה לעמדת נחיתות בתחרות מול איירבאס והכריזה על השקת פרויקט מקביל עבור ה 737 באוגוסט 2011. תכנון של מטוס חדש מדף חלק, שנשקל ונדחה במשך כמה שנים, נזנח.
כיוון שהחלה באיחור מול המתחרה, בואינג שאפה לקצר ככל האפשר את זמני הפיתוח והאישור על ידי הרשויות. בתהליך האישור המטרה העיקרית של בואינג היתה שהמקס יקבל את אותו Type rating [Wikipedia] של הדגמים הקודמים של 737. Type rating חדש היה דורש אימון ארוך של כל הטייסים שמיועדים להטיס את הדגם החדש, והיה מייקר את העלות שלו באופן שהופך אותו ללא תחרותי.
המנועים הגדולים יותר של המקס מותקנים גבוה יותר וקדימה יותר מאשר בדגם הקודם. זה גרם להתנהגות האוירודינמית של הדגם החדש להיות שונה, מה שהיה מחייב Type rating חדש. על מנת שהדגם יקבל את אותו Type rating בואינג התקינו תוכנה שתגרום לו לחקות את ההתנהגות האווירודינמית של הדגם הקודם‏1. זוהי ה MCAS [Wikipedia] הידועה לשמצה. בואינג התייחסו ל MCAS כחלק ממערכת בקרת הטיסה והשמיטו אותה מה manual של המטוס ומחומרי ההדרכה, שוב על מנת שטייסים לא יצטרכו לעבור אימון מיוחד.
בתהליך היישום והאישור של ה MCAS למקס היו מספר כשלים, שבמצטבר הפכו את ה MCAS לגורם סיכון גדול וחבוי במטוס, בלי שהטייסים שמטיסים אותו יידעו על קיומו.
1. בניגוד לגרסה המוקדמת, שקיבלה את אישור ה FAA, ה MCAS על המקס נכנסה לפעולה גם בכוחות G נמוכים.
2. התוכנה קיבלה מידע מחיישן זווית התקפה בודד בכל טיסה, מהשניים שמותקנים במטוס. תקלה בחיישן גרמה להפעלת ה MCAS באופן שגוי ולהתרסקויות.
3. התוכנה לקחה את השליטה מהטייס מבלי לאפשר ניתוק פשוט שלה, גם זה בניגוד לגרסה המקורית של המערכת שהותקנה במטוס קודם (KC-46, מטוס תדלוק של חיל האוויר)

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

__________
1 במקום הפתרון של שינוי אוירודינמי במטוס, שהעדיף טייס המבחן של בואינג. פתרון שאולי היה ארוך ויקר יותר לבואינג ואולי גם מסוכן לה מבחינת ה Type rating.
תגובה מהירה מאד 721026
הוויכוח בפתיל היה על שני עניינים.
הראשון הוא האם אכן אפשר להגדיר את הכשל ב737 מקס ככשל בתוכנה כפי שטענת.
העניין השני הוא האם באופן כללי תקלות תכנה קשות יותר לתיקון מתקלות חומרה כפי שטענת.
התגובה האחרונה שלי עסקה בעניין השני, בהנחה (שאיני מסכים לה) שאתה צודק בעניין הראשון. אמרתי שגם אם אתה צודק בעניין הראשון זה לא גורר את זה שאתה צודק בעניין השני, כפי שניסית להסביר, וזאת גם בגלל שטעות היא להסיק מסקנות על סמך מקרים ספורים.
איני מבין מדוע מצאת לנכון לספר את כל הסיפור מהתחלה.
תגובה מהירה מאד 721031
אתה צודק. ההשוואה עם טויוטה לא היתה במקומה, וקשה ללמוד מהמקרה הספציפי על הכלל.
כשסיפרתי את הסיפור מחדש התחוור לי שהתקלות בתכנון התוכנה, שהן מה שריסק בפועל את המטוסים, לא עמדו בפני עצמן אלא היו תוצאה של הבעיה העיקרית. הבעיה העיקרית היתה שהמטרה העליונה של בואינג היתה להכניס את התכנון של המקס לסד של "שמירת הדגם" הרגולטורית, וכל שאר השיקולים הפכו למשניים.
בואינג לא ניסתה לעשות את המטוס הכי טוב שהיא יכולה, אלא את המטוס הכי טוב שהיא יכולה בלי לחרוג ממסגרת ה type rating של ה 737 הקודמים, וממסגרת הזמן. התוצאה היתה קטלנית.
אז לקרוא לבעיות של המקס "תקלת תוכנה" כנראה נכון טכנית, אבל מגמד את האחריות של התאגיד לתהליך הפיתוח והאישור הרשלני שהביא לכשל.
תגובה מהירה מאד 721032
לגזור ולשמור לפעם הבאה שמבקשים מכם תאימות באגים (bug to bug compatibility).
תגובה מהירה מאד 721038
לעניות דעתי "תקלת תוכנה" נשמעת כמו באג. אבל באג הוא רק סוג אחד של תקלות תוכנה - כשהתוכנה *לא* מבצעת את מה שהיתה אמורה לבצע.
מהמעט שקראתי כאן בפתיל, נראה שהכשל המדובר הוא לא מהסוג הזה - התוכנה ביצעה את מה שהיתה אמורה לבצע, אבל תכנון התוכנה והגדרת הדרישות שלה לקו בחסר.

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

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

התוכנה קיבלה מידע רק מחיישן אחד בכל פעם.
היתה מערכת שבואינג מכרה כאופציה, שרק מתריעה אם יש חוסר הסכמה בין החיישנים (כוסות רוח למת).
While it has defended its design, Boeing is working on an update for the 737 Max that will make the MCAS software less intrusive and will take a reading from more than one sensor...
a Boeing spokesperson defended the decision to use a single sensor to CNN: "Single sources of data are considered acceptable in such cases by our industry."
תגובה מהירה מאד 721041
אצלנו אומרים: “באג בדיזיין, זיין בדיבאג”.
תגובה מהירה מאד 721046
כל הוויכוח --- סמנטיקה.
תגובה מהירה מאד 713228
אני תוהה אם התפרקות המטוס עקב נחיתה קשה לא מרמזת על תכנון מכני לקוי. אבל גם אם לא היה כאן תכנון מכני לקוי והמטוס בכוונה לא תוכנן לעמוד בעומסים כפי שהיו בתאונה הזאת הבה נניח שגוף המטוס כן היה אמור לעמוד בעומסים כאלה, ורק אירוע התאונה הוכיח למתכננים שקיים ליקוי כזה במטוס. האם אפשר להעלות על הדעת שיימצא פתרון לבעיה ותוך זמן קצר "יימצא מזור" לכל המטוסים מאותו דגם? הרי לא מדובר בבעיית תוכנה. . .
תגובה מהירה מאד 713229
וואו, ה-‏737 מתחיל להזכיר את קללת הDC-10 משנות השמונים (כמדומני).
תגובה מהירה מאד 713238
יש מעט מאד פרטים מה בדיוק קרה, והמעטים סותרים זה את זה. במקום אחד ראיתי שהמטוס ''החטיא את המסלול'', ובמקום אחר שהחליק, וגם הידיעה שהיו שם רוחות גביות לא כל כך ברורה, כי במקרה כזה הפקח צריך להפנות את המטוס לאותו מסלול בכיוון ההפוך ואז הכל בסדר. כך או אחרת התמונה של המטוס ללא חלקו הקדמי ועם שבר ענק ליד הזנב מאד מרשימה. נראה שזה בדיוק סוג המטוס שגם אל על משתמשת בו ואני מרבה לטוס בו בטיסות לאירופה. אני מקווה מטעמים אנוכיים שלא מדובר בכשל במבנה המטוס.
תגובה מהירה מאד 713240
בבחירת טיסה בטוחה צריך לקחת בחשבון כמובן את דגם המטוס, אבל גם את איכות חברת התעופה. זו מתבטאת בשלשה פקטורים- גיל המטוסים, רמת התחזוקה ואיכות הטייסים. השניים האחרונים נראים לי הרבה יותר משמעותיים מהראשון. אנקדוטלית- כנראה שבתחזוקה טובה יותר טיסת אתיופיאן לא היתה מתרסקת, ולעומת זאת הנחיתה על ההדסון התבצעה במטוס זקן, אבל עם צוות מיומן.
תגובה מהירה מאד 713246
טיסת אתיופיאן לא הייתה מתרסקת לו הייתה שם תחזוקה טובה יותר? עד כמה שהבנתי סיבת ההתרסקות הייתה קשורה בתכנון המטוס ולא בתחזוקה, אבל אולי ישנם פרטים שפורסמו שלא ידועים לי.
לעניין ההשוואה שאתה עושה עם הנחיתה על ההדסון, כל פעם שאתה עושה זאת זה מפריע לי מחדש. כלל לא ברור אם באמת סאלי היה מצליח למנוע את ההתרסקות באתיופיאן לו היה שם, וכלל לא ברור אם הצוות באתיופיאן לא היה מנחית את המטוס על ההדסון בשלום לו היה שם. בניגוד לך אני חושב שההחלטה של סאלי לנחות על ההדסון התבקשה מאליה ורוב הטייסים המנוסים כך היו עושים, וגם מצליחים לבצע את הנחיתה עצמה באותה הצלחה.
תגובה מהירה מאד 713249
אני לא בטוח אם זה היה באתיופיאן או בליון (המקס השני שהתרסק), אבל בהחלט היו כשלים בתחזוקה של המטוס בכלל והחיישנים הבעייתיים בפרט.
לעניין ההשוואה שעשיתי עם הנחיתה על ההדסון- הפעם לא עשיתי שום השוואה כזו. רק אמרתי שהנחיתה על ההדסון היתה עם מטוס זקן אבל צוות מיומן, מה שמעלה בעיני את חשיבותו של פרמטר הצוות ומוריד בעיני את חשיבותו של פרמטר הגיל של המטוס.

אני לא יודע אם סאלי היה מצליח להנחית את הטיסה של אתיופיאן, אבל אני מאמין שכן. הצוות של הנחיתה על ההדסון היה מנוסה, קר רוח, וקיבל החלטות מהירות ונכונות תחת לחץ. לטייס המשנה של סאלי היו יותר מ 20 אלף שעות טיסה ולטייס המשנה של אתיופיאן היו רק שלוש מאות.
תגובה מהירה מאד 713239
זה היה 737-800 שהוא אחד הדגמים הבטוחים יותר, תאונה קטלנית אחת ל 10 מיליון טיסות תגובה 712529. קשה לי לקרוא לזה תכנון לקוי. ייתכן שדגם ישן יותר ופחות בטוח היה גורם ליותר הרוגים בתנאים דומים.
לבטח תכנון דגמים חדשים יותר צריכים לקחת בחשבון תאונות קודמות ולהיות בטוחים יותר. יש דגמים שלא עשו תאונות קטלניות בכלל, כולם חוץ מאחד חדשים יחסית.
תגובה מהירה מאד 713245
לא אמרתי שזה ליקוי כי איני יודע. לא ברור כלל ממה שפורסם מה בדיוק קרה, והסברתי זאת. ברור לכל שאם מטוס פוגע בקרקע במהירות אנכית גדולה (כמו במטוס האתיופי) גוף המטוס לא יעמוד בעומסים. מה משמעותה של אותה "נחיתה קשה"? עד כמה הייתה רחוקה מנחיתה חלקה לכיוון ההתרסקות? ללא הפרטים האלה אי אפשר להכריע בשאלה הזאת. כתבתי שאני מקווה שאין ליקוי, כלומר שהנחיתה הייתה כה קשה, שאיש לא התכוון לתכנן גוף מטוס שיעמוד בנחיתה כזאת.
תגובה מהירה מאד 713247
אגב תגובה 713228 שבה פתחתי את הפתיל כוונה להתייחס לתזה שלך לפיה תקלות תוכנה קשות למציאת פתרון ולתיקון ואילו תקלות אחרות קלות ומהירות יותר לתיקון. דווקא לנושא שבגללו כתבתי את התגובה הזאת לא התייחסת.

חזרה לעמוד הראשי

מערכת האייל הקורא אינה אחראית לתוכן תגובות שנכתבו בידי קוראים