בתשובה לדב אנשלוביץ, 05/01/20 15:39
 |
|
 |
||
|
||||
 |
היה נוהל לאובדן מנוע. הנוהל הזה לא התאים לסיטואציה. סאלי התחיל אותו, ונטש אותו ברגע שהבין שאין טעם להמשיך אותו. בוא נגיד שמטוס אוטונומי היה ממשיך עם הנוהל שלא התאים לסיטואציה ומתרסק, וזה, אגב, כנראה מה שקרה בתאונות ה 737 מקס. >> עכשיו אתה אומר שאחת המסקנות מהמקרה היא לעשות נוהל לגובה נמוך זה שהנוהל הקודם לא היה טוב ומשפרים אותו לא אומר שלא היה נוהל. |
 |
 |
 |
|
|
|
||
|
||||
|
אני חושב שאם הסימולציות שראינו בסרט אכן היו במציאות, מטוס אוטונומי היה נוחת בשלום או בלה גרדיה או בטטרבורו. לו היה מעל אמצע האוקיאנוס האטלנטי (או השקט. לא משנה.) הוא היה נוחת על המים. ולו היה במצב שבמקרה שלנו אבל במהירות יותר נמוכה או בגובה יותר נמוך כך שהמחשב היה מגלה שאי אפשר להגיע לשדה תעופה קרוב הוא היה נוחת על ההדסון. מה שהיה ב 737 מקס הוא איבוד שליטה על המטוס, בגלל תכנון לקוי של המטוס, מקרה שונה לחלוטין. | |
|
|
|
|
|
||
|
||||
|
>> מטוס אוטונומי היה נוחת בשלום או בלה גרדיה או בטטרבורו. אני לא מסכים. הוא היה מצליח לעשות את זה רק אם היה כתוב לו הנוהל הנכון, ולא היה. >> מה שהיה ב 737 מקס הוא איבוד שליטה על המטוס, בגלל תכנון לקוי של המטוס כנראה בעיקר בגלל תכנון לקוי של התוכנה של המטוס, שהמשיכה להוריד את האף ולא אפשרה לטייס לקחת שליטה ידנית ולמשוך למעלה. הכנה לפשלות שנראה מכלי רכב אוטונומיים בעתיד? |
|
|
|
|
|
|
||
|
||||
|
אתה יכול לשגע פילים עם הנוהל שלך. מה צריך לעשות כשהשעון ברכב מראה שיש מעט דלק? לנסוע לתחנת הדלק נכון? אבל נניח שיש לך שעון מדויק ואתה מגלה לפתע פתאום שבעוד 200 מטר ייגמר לך הדלק לחלוטין? תעצור באמצע הכביש בגלל שאין נוהל? ומה היה עושה רכב אוטונומי, אם שעון הדלק שלו היה מושבת זמנית, ולפתע היה מסתדר ומורה שעוד 200 מטר ייגמר הדלק לחלוטין? לא ממש אותו דבר? איפה כתוב שמתכנני כלי רכב אוטונומיים חייבים להיות מטומטמים? | |
|
|
|
|
|
||
|
||||
|
אם זה מה שיצא לגאונים שתכננו את ה 737 מקס, קשה לי להיות אופטימי. מעניין כמה שורות קוד צריך לכתוב כדי שמכונית אוטונומית תצליח להתמודד כהלכה עם פנצ'ר על הכביש המהיר 405 בלוס אנג'לס בשעות העומס. |
|
|
|
|
|
|
||
|
||||
|
אני הבנתי שהתוכנה נועדה לפצות על בעיה הנדסית של מיקום חדש של המנועים שנועד לספק צורך שיווקי של מטוס עם צריכת הדלק טובה משל האיירבס המתחרה וקיצור זמן הספקה. | |
|
|
|
|
|
||
|
||||
|
בכל מקרה, היא לא כל כך הצליחה. | |
|
|
|
|
|
||
|
||||
|
לדעתי מכונית אוטונומית לחלוטין תפעל תמיד עם תקשורת מול מוקד כלשהו שבמקרה הצורך יוכל לקחת את הפיקוד. אם מתעורר מצב שדורש פתרון ברמה של שניות היא תעשה מה שנהג יעשה: תנסה כמיטב יכולתה לבלום ולהגיע לעצירה בשטח שאינו נתיב נסיעה, ומשם תקרא לחילוץ. אני מניח גם שתהיה לה אפשרות לתקשר ישירות גם מול שרותי החירום. | |
|
|
|
|
|
||
|
||||
|
גם אני חושב שזה מה שהיא תעשה. אני רק לא יודע אם הקוד שיגיד לה לעשות את זה יהיה מספיק טוב. לא חשבתי שיכול להיות מצב שבו התוכנה של מטוס נוסעים יכולה למנוע מהטייס לשלוט בסטיק, גם כשהמטוס עומד להתרסק כתוצאה מכך. עובדה, קרה פעמיים. |
|
|
|
|
|
|
||
|
||||
|
לא נראה לי שבמקרי התאונה המדוברים לא היה ניתן לנתק את הטייס האוטומטי. יש לך מקור שמאשש את הטענה הזאת? | |
|
|
|
|
|
||
|
||||
|
מערכת MCAS1 שגרמה לתאונות לוקחת מהטיס את השליטה במייצב הגובה. ניתוק המערכת מתבצע רק על ידי שני kill switch שמכבים את החשמל לכל מערכת מייצב הגובה וכך מבטלים גם את השליטה בלשונית הקיזוז (trim tab) שנמצאת על הסטיק. עדיין אפשר לשלוט ידנית במייצב הגובה דרך גלגל הקיזוז (trim wheel) שנמצא ליד ברכו של הטייס. בהתרסקות של אתיופיאן איירליינס (ההתרסקות השניה של 737 מקס) החיישן של זווית ההתקפה (AOA) בחרטום התקלקל, כנראה נפגע מציפור מיד בהמראה. MCAS לא נכנסה מיד לפעולה, כי היא מתוכננת לא לפעול בזמן המראה, אבל ברגע שהטייסים הרימו מדפים MCAS נכנסה לפעולה, קיבלה נתונים שגויים מהחיישן והורידה את החרטום. הטייסים משכו בכח בסטיק, אבל לא הצליחו להרים את האף בעזרת הגה הגובה בלבד. הם ניתקו את ה kill switch, אבל ככל שהתאמצו לא הצליחו פיזית לסובב את גלגל הקיזוז בגלל הכוחות האווירודינמיים החזקים על מייצב הגובה. אחרי מספר דקות הם התעייפו מאוד מלמשוך את הסטיק וניסו להחזיר לרגע את החשמל כדי לאפס את מייצב הגובה, MCAS שוב השתלטה על המערכת והורידה את החרטום לאדמה. המטוס צלל ופגע באדמה במהירות של יותר מאלף קמ"ש. ________ |
|
|
|
|
|
|
||
|
||||
|
זה נשמע תכנון ממש לקוי. למה שאי אפשר יהיה לחזור למצב שבו אותו MCAS לא שולט כפי שזה בהמראה? מן הסתם המתכנן לא חשב שיש צורך בכך, ואולי חשש משטויות שייעשו הטייסים בהטסת המטוס בעל המבנה המיוחד. | |
|
|
|
|
|
||
|
||||
|
נכון, תכנון לקוי מאוד. MCAS גם אמורה לפעול רק במהירויות נמוכות, כשיש סכנת הזדקרות. המטוס של אתיופיאן היה במהירות המקסימלית שלו ומהנדסי התוכנה לא חשבו שזה משנה. | |
|
|
|
|
|
||
|
||||
|
אני לא חושב שמדובר כאן בתוכנה ובמהנדסי תוכנה. יש כנראה צוות שמחליט איך המטוס צריך להתנהג, והוא זה שפישל. המתכנתים בסך הכל בצעו את הדרישה של הצוות הזה. ''באג'' לא היה כאן. | |
|
|
|
|
|
||
|
||||
|
מסכים עם דב, התנהגות אלגוריתם כזה מוכתבת על ידי הדרישות ממהנדסי המערכת ומהנדסי המוצר, המתכנתים עוקבים אחרי הדרישות ולא מחליטים בעצמם, או לפחות כך זה אמור להיות בנוהל פיתוח תקין, וודאי כזה שמערב מכונות מסובכות שמסכנות חיי אדם. חוליה נוספת בשרשרת הפיתוח שסביר שכשלה כאן היא בקרת האיכות ומהנדסי ניסויי הטיסה - זו שתפקידה להריץ תרחישים אפשריים ולבדוק שהמערכת לא כושלת בהם. |
|
|
|
|
|
|
||
|
||||
|
ואם בחברה כל כך מכובדת כמו בואינג זה לא הצליח, עם כל הבקרות של רשויות הטיסה, למה שזה יצליח עם מכונית אוטונומית מתוצרת סין? | |
|
|
|
|
|
||
|
||||
|
האמת, זו דוגמה נהדרת ל-ai המהוללת ומגבלותיה. | |
|
|
|
|
|
||
|
||||
|
האם השתמשו בכלל בלמידה עמוקה? לפי הניתוחים שאני קורא נראה לי שמדובר בתכנות פונקציונלי סטנדרטי ("אם זוית ההתקפה ואם הגובה... אז..."). | |
|
|
|
|
|
||
|
||||
|
די ברור שלא היתה כאן למידה עמוקה (כנראה שום שמוש בלמידת מכונה בכלל). אני לא בטוח שלמידה עמוקה זה מה שנדרש במערכת כזו, אבל בכל מקרה לא זו היתה הבעיה. עד כמה שאני מבין, הלוגיקה הפנימית של המערכת היתה בסדר, אבל הטעות החמורה היתה בקריאת הנתונים ממד זווית התקפה אחד (במקום שניים או שלושה), שגם מועד להתקרחות או היסתמות וגם עלול סתם להיות תקול. במצב שבו הזווית המועברת לא נכונה, לוגיקה תיתן תשובה לא נכונה - אלא אם כן יש ללוגיקה דרך לנתח את הנתונים שהיא מקבלת ולקבוע שאין לסמוך עליהם. Garbage in, garbage out. היו עוד הרבה כשלים בתהליך; למשל, בשלב של בקורת הבטיחות על תכנון המטוס המערכת נועדה להוריד את אף המטוס בחצי מעלה בלבד. בשלב מאוחר יותר החליט מי שהחליט להגדיל את תחום הפעילות שלה ולאפשר לה להוריד את האף בעד שתי מעלות. בשלב הזה אף אחד לא חשב שזה שינוי שמחייב בקורת בטיחות חדשה. אפשר לכתוב על הדברים שקרו שם ספר שלם - ואין לי ספק שספר כזה אכן ייכתב (ואולי כמה, סביר להניח שכבר היום הם בשלבי כתיבה מתקדמים). | |
|
|
|
|
|
||
|
||||
|
למרות כל הלחצים לזרז ולהוזיל את הפיתוח, ממש מדהים שאפשרו single point of failure כזה. ולנו יש את החוצפה להתלונן על גשר המכביה או תקרת פלקל. | |
|
|
|
|
|
||
|
||||
|
אכן. מה גם שאפשר לבדוק גם נתונים שמגיעים מחיישן אחד. אפשר קודם-כל לראות האם הם עקיבים ללא קפיצות והתנהגויות מוזרות. סביר להניח שהפלט של חיישן כזה הוא בכל מקרה רועש למדי (אם יצא לך פעם לראות את הפלט הלא מפולטר של החיישנים בטלפון שלך אז אתה יודע על מה מדובר) ותמיד צריך לנקות אותו, אבל אחרי הניקוי אתה מצפה להתנהגות סבירה. זה יכול לכסות שגיאות אקראיות, אבל לא שיטתיות. גם את השגיאות השיטתיות אפשר היה, לדעתי, לזהות. זווית ההתקפה חייבת להיות בקורלציה הדוקה עם הזווית הכללית של גוף המטוס (pitch, עִלְרוּד בעברית תקנית). הזווית הזו ידועה - אני מניח שהיא נמדדת גם על ידי חיישנים שמבצעים דגימה רגעית וגם בעזרת מערכת אינרציאלית (ג'ירוסקופים). אז אפשר בעזרתה לבדוק האם הנתונים של זווית ההתקפה מהחיישן סבירים. אם ממש רוצים אז סביר להניח שאפשר להסיק את זווית ההתקפה מהמידע על תנועת המטוס - אם יש לך מודל של התנהגות המטוס ואתה פותר את המשוואות כך שבמקום שזווית ההתקפה תהיה חלק מהקלט היא הופכת להיות הפלט. אני משער שחלק מתיקון התוכנה המדובר כולל אלמנטים הדברים האלה. ולגבי החוצפה - בכל זאת, כמי שהמציאו את החוצפה יש לנו זכות להשתמש בה כרצוננו. |
|
|
|
|
|
|
||
|
||||
|
מה לא הצליח? המקרה המצער הזה הוא הדבר היחיד שקרה בבואינג? אתה זוכר את הגג באולמות ורסאי? אז בגלל זה אסור לנו לסמוך על שום גג? האם בגלל אסון אולמות ורסאי אתה נמצא כל הזמן בחרדה שהתקרה בביתך תקרוס עליך או שתעוף יחד עם הרצפה בביתך אל השכנים שמתחתך? ואת הגשר להולכי רגל על הירקון שקרס יחד עם ספורטאי המכבייה אתה זוכר? אז זה אומר שיש בעיה בגשרים בארץ? היו אסונות בגלל תכנונים לקויים. אבל צריך לראות את התמונה הרחבה. | |
|
|
|
|
|
||
|
||||
|
לפי מה שאני זוכר שקראתי, הבעיות בבואינג יותר עמוקות ורחבות, ולא רק ב-737. היה גם מהנדס בטיחות שהתריע וגם חשף התנהלות רשלנית בחברה, וגם העיד בקונגרס. אאז"נ, וצריך לחפש לינקים מתאימים. בנוסף לבעיות התכנוניות והבטחת האיכות של ה-737, היה גם לחץ לזרז את הייצור שגרם לכל מיני קיצורי דרך ורשלנות בייצור. גם במטוס ה-787 שי בעיות שקשורות לזה שבואינג הקימה מהר מפעל חדש בדרום קרולינה ששם אין עובדים מיומנים בתעשייה וכוח האדם שגויס לא היה מיומן ובעל נסיון בעבודה בסביבה של ייצור מטוסים. על זה התווסף לחץ הנהלה לזרז את הייצור שגם פה הביא למקרים של רשלנות מדעת או מחוסר דעת, קיצורי דרך ועיגול פינות גם בסרטיפיקציה של המטוסים שיוצרו בדרום קרולינה. עד כמה שאני זוכר, המהנדס סיפר על כלים שהושארו בתוך חללי המטוס, כולל סולם שהושאר בתוך הגה הזנב, חתימה על טפסי בקרת איכות בלי ביצוע בקרה, השארת פסולת מהעבודה במטוס ועוד. אני זוכר שבסוף הוא אמר שהוא לעולם לא יעלה על 787 שיוצר בדרום קרולינה. | |
|
|
|
|
|
||
|
||||
|
אני לא אפסיק לטוס בגלל התרסקויות ה 737 מקס, אבל כנראה אעדיף איירבס בשביל השקט הנפשי שלי. היום צנח עוד 737, לא מקס כמובן, אבל יש הרגשה שהם נופלים כמו זבובים. הבעיה עם בואינג היא שאחרי ההתרסקות הראשונה היה ברור שה MCAS בעייתי. בואינג העבירה אותו את הרגולציה עם מניפולציה כלשהי שגרמה לו להיחשב לשינוי פחות קריטי ממה שהוא, וגם לא הכניסה אותו ל Manual של המטוס כמו שצריך, אבל אחרי ההתרסקות הראשונה דגל האזהרה כנראה לא התנופף מספיק חזק אצלם, והם העדיפו לא לשנות את ה MCAS, אלא רק לחדד נהלים (וכך הצוות של אתיופיאן כבר ידע לסגור מהר את ה Kill switches, והצליחו לשמור שליטה כלשהי במטוס לזמן מה) |
|
|
|
|
|
|
||
|
||||
|
אני נוטה לנחש בזהירות שה 737 800 לא התרסק בגלל בעיה טכנית. אולי בגלל טעות אנוש ואולי אפילו בגלל איזה טיל טועה שפגע בו. יצא לי לטוס בדגם הזה באל על הרבה פעמים, ועובדה היא שעד כה אני לגמרי שלם. | |
|
|
|
|
|
||
|
||||
|
מעיון חולף בידיעות על המטוס האוקראיני גיליתי שהאיראנים מסרבים למסור את הקופסאות השחורות שלו, וכן שהאוקראינים לא גורסים עוד שמדובר בתקלת מנוע. יש כאן רמזים בכיוון שניחשתי. | |
|
|
|
|
|
||
|
||||
|
נראה שצדקתי. 'כשאתה אומר "הם נופלים כמו זבובים" האם יש איזה טיעון הגיוני מאחורי זה שאתה לא משתף אותו, או שזו אינטואיציה, תחושת בטן?' ה 737 800 ו 900 הם מטוסים מרבי התפוצה בתעופה האזרחית והם מאד אמינים. אני מניח שעוד יצא לי לטוס בהם, ואיני חושש. |
|
|
|
|
|
|
||
|
||||
|
אני לא כתבתי: "הם נופלים כמו זבובים". אני כתבתי: "יש הרגשה שהם נופלים כמו זבובים." עכשיו כשאנחנו יודעים מה כתבתי אני חושב שיהיה לך קל לנחש לבד- יש איזה טיעון הגיוני מאחורי זה שאני לא משתף אותו, או שזו אינטואיציה, תחושת בטן, הרגשה? |
|
|
|
|
|
|
||
|
||||
|
לגבי המטוס האוקראיני שהתרסק באירן. יש כמה עיתונאים שמתחילים לבדוק למה האצבע האירנית על הדק סוללת הטילים היתה עצבנית. הם מתבססים על התוכנית של שון האניטי בפוקס ניוז ששודרה בסביבות הזמן שהמטוס נפל. שון האניטי הוא יועץ של טראמפ והם מדברים כמעט כל יום, וטראמפ ידוע כמי שמגלה סודות לכל מיני אנשים (למשל, האורחים באתר הגולף שלו ידעו על ההתנקשות) ומשתמש ברטוריקה של הפחדה והתרברבות. האניטי כבר קרא בתוכנית שלו לטראמפ להשתמש בכל הכוח. בתוכנית ששודרה בזמן ההתרסקות הוא אמר בשפה של דיווח עיתונאי על 3 מתקני זיקוק שעומדים לעלות באש, שמתקנים גרעיניים עומדים להיות מושמדים, שמטוסים אמריקאים יתקפו הלילה, F35 הוזנקו לתקיפה, B52 בדרך, ושכדאי למנהיגים האירנים להתחבא בבונקר. הם שואלים את עצמם אם זה לא סביר שהאירנים, שגם מכירים את מערכת היחסים ההדוקה בין טראמפ להאניטי, מקשיבים לתוכנית שלו ושדבריו העלו אצלם את רמת העצבנות? מעניין יהיה לראות מה יעלה התחקיר הזה, ואיך הארועים ימופו על ציר הזמן. |
|
|
|
|
|
|
||
|
||||
|
דיווחים דומים מהתוכנית שלו התממשו בסבירות מספיק גבוהה? כלומר: האם למודיעין האיראני היה טעם להקשיב לאיומים שנאמרו בתוכנית שלו? | |
|
|
|
|
|
||
|
||||
|
כלומר אתה נותן הנחות לא רק לארז אלא גם לעצמך. אני חש מקופח ומוותר על המחמאה. | |
|
|
|
|
|
||
|
||||
|
ואם מישהו פקפק גם האיראנים מודים עכשיו בטעותם. | |
|
|
|
|
|
||
|
||||
|
יהיו כשלים וגם תאונות גם במכוניות אוטונומיות, בוודאי בשנים הראשונות. אבל אגלה לך מה שרבים בתעשיה יודעים: גם במכוניות לא אוטונומיות יש כשלים ותאונות, ותוכנת הנהיגה שלהן גם היא לא מושלמת. יש יסוד להניח שכאשר האוטונומיות תשוחררנה לשימוש כללי הן כבר תהיינה בטוחות יותר מהרגילות בצורה מובהקת. אגב, נקודה שפחות מזכירים אותה היא שהפיתוח של האוטונומיות גורר אתו מערכות בטיחות שרבות מהן מוצאות ותמצאנה את דרכן למכוניות הרגילות (ע"ע מובילאיי). באופן הזה כבר היום המכוניות האלה משפרות את הבטיחות של כולנו. סביר להניח שבשנים שתחלופנה עד שנראה אוטונומיות על הכביש נושא הבטיחות כבר יהפוך לקצת פחות מדאיג. |
|
|
|
|
|
|
||
|
||||
|
מסכים בעקרון. אני רק מצביע על מה שנראה לי כמו בעיה, שתקלות תוכנה הן הרבה יותר קשות לתיקון מתקלות חומרה. כשלטויוטה התגלתה בעיית דוושת התאוצה היא פתרה את הבעיה תוך שבועות, עשתה ריקול למיליוני מכוניות ותוך מספר שבועות המשיכה למכור את דגמיה כרגיל. |
|
|
|
|
|
|
||
|
||||
|
כשאתה כותב שלדעתך תקלות תוכנה הן הרבה יותר קשות לתיקון מתקלות חומרה, "האם יש איזה טיעון הגיוני מאחורי זה שאתה לא משתף אותו, או שזו אינטואיציה, תחושת בטן?" אני, למשל, בטוח בדיוק בהפך, שהרבה יותר קל פשוט ומהיר לפתור בעיות תכנה מאשר בעיות חומרה, וזה כל כך מובן מאליו שכל "טיעון הגיוני" במקרה זה ממש מיותר. ואני גם חוזר על מה שכתבתי קודם, שאותה תקלה ב737 מקס אינה תקלת תכנה. |
|
|
|
|
|
|
||
|
||||
|
אני משווה בין המקרים. טויוטה "קרקעה" את המכוניות שלה לשבועיים. ה 737 מקס מקורקע כבר 10 חודשים. אם זו תקלה בתכנון התוכנה מבחינתי ודאי שזו תקלת תוכנה. לדוגמה- ה MCAS לא אמור לפעול בכלל במהירויות גבוהות ושתי ההתרסקויות קרו במהירות גבוהה. בואינג הודיעה אחרי חודשיים מהקרקוע שהיא השלימה את עדכון התוכנה. מסתבר שהיו בעיות נוספות, כמו זה שהאימון של טייסי המקס להבדלים בינו לבין הדור הקודם היה בדיחה, אבל התקלה עצמה היתה בזה שהתוכנה לא היתה טובה. |
|
|
|
|
|
|
||
|
||||
|
ההשוואה שאתה עושה עם מקרה טויוטה היא השוואה מופרכת מכמה סיבות. אתה רואה את התקלה ב 737 מקס כמייצג של תקלת תכנה. אני לא מסכים אתך בעניין זה כפי שאמרתי מספר פעמים אבל ניחא. נניח שבנקודה זו אתה צודק, ובאמת מדובר בתקלת תכנה (קשה לי לומר זאת אפילו כהנחה, אבל מילא). אבל כשאתה משווה שני סוגי תקלות לא רק סיווג התקלה כתכנה או חומרה משחק תפקיד אלא גם גודלה. יכולה להיות תקלת חומרה ענקית ותקלת חומרה קטנה ופשוטה. ויכולה להיות תקלת תכנה ענקית (נניח מה שחשבו על באג 2000 מי שחשבו), ותקלת תכנה פשוטה. אין שום מקום להשוואה. אבל המופרכות עוד יותר בולטת בכך שאתה לוקח שני מקרים מכל סוג ומהם מסיק מסקנות. זה כמו לעשות מדגם על תוצאות בחירות לפי אדם אחד, ולקחת את המפלגה שלה אמר שיצביע ולהגיד שמפלגה זו תקבל את כל המנדטים. טעות היא להסיק מסקנות בצורה כזאת. | |
|
|
|
|
|
||
|
||||
|
אני מסכים עם דב, וחוץ מזה יש עוד דבר - ההבדל בין תעשיית התעופה לתעשיית הרכב מבחינת רגולציה ומהרבה בחינות אחרות לא מאפשר להשוות ביניהן. אם בכל זאת אתה מתעקש להשוות אז אתה יכול להשוות את תקלת המקס לתקלה בכריות האוויר של חברת טקאטה Takata Corporation [Wikipedia]. תחילת הקריאה לריקול של מכוניות שצוידו בכריות החברה היתה עוד ב-2013 ועד היום הזה היא לא הסתיימה - אפילו רשימת המכוניות שנזקקות לריקול עדיין לא סופית ורק בחודש הקודם הוספו לה עוד כמיליון וחצי מכוניות. תוך כדי התהליך החברה גם פשטה את הרגל. זה מצב מאד נדיר שבו אחד מהספקים הישירים של מודולים ליצרני הרכב (ספק Tier 1 בעגה המקצועית) מפשל כך שיש צורך לבצע ריקול למכוניותיהם של עשרות יצרנים, אבל בכל מקרה הוא מראה לך כמה קשה לטפל בתקלת חומרה רצינית. | |
|
|
|
|
|
||
|
||||
|
מסתבר שבינתיים מתגלים עוד ליקויים ב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. שעת סימולטור היא עסק יקר מאד וחברה שצריכה להסמיך עשרות ואף מאות טייסים באמצעות סימולטור תשלם מיליונים רבים של דולרים. הטייסים בתאונות הקטלניות לא עברו כל הסמכה על סימולטור לדגם הזה. | |
|
|
|
|
|
||
|
||||
|
למה אגב שעת סימולטור היא כל כך יקרה? מרגע שהוא נבנה, הוא לא חורף דלק או משאבים כמו מטוס, אז מה הבעייה? |
|
|
|
|
|
|
||
|
||||
|
שאלה טובה. חיפוש קצר לא העלה תשובה איכותית. אמנם בניה של סימולטור היא עסק יקר (נדמה לי שהוזכרו עלויות של כמה עשרות מיליוני דולרים עבור מרכז הסימולציה החדש שחיל האוויר התחיל להפעיל לא מזמן) אבל לכאורה התחזוקה של המכניקה והתוכנה והעלויות של צוות ההדרכה לא צריכות להיות יקרות מאד. למרות זאת, לפי הערכת אנליסטים ארוע המקס יעלה לבואינג חמישה מיליארד דולר נוספים אם היא תחייב הסמכה על סימולטור לכל הטייסים. חלק מהסכום הוא גם פיצוי על כך שההכשרה תדחה את חזרת המטוסים לשרות. בארה"ב כולה יש כתריסר סימולטורים של המקס, מהם שישה בבואינג עצמה והיתר אצל לקוחותיה. | |
|
|
|
|
|
||
|
||||
|
אני חושב שהעלות לא מתמקדת רק בשעת הסימולטור, אלא בכך שטייסים שצריכים לעבור הכשרה מלאה למטוס חדש מקבלים שכר בזמן שהם בקורס של כמה ימים, והחברה צריכה לשלם על הקורס הספציפי- מתקנים, אש''ל, מדריכים וכו', או לקבלן משנה שיעביר אותו. | |
|
|
|
|
|
||
|
||||
|
הם מקבלים שכר כל הזמן, אני מניח, אז לא ברור למה ימי הקורס צריכים להתווסף כשכר נוסף. | |
|
|
|
|
|
||
|
||||
|
כן, אבל בימים של ההדרכה הם לא מטיסים אז צוותים אחרים צריכים להטיס במקומם. אם אתה רוצה, מתברר שיש כמה מקומות שבהם אתה יכול להטיס בסימולטור ברמה של חברות תעופה. |
|
|
|
|
|
|
||
|
||||
|
עד כמה שאני יודע, טייסים לא עובדים חמישה ימים בשבוע. אז בחלק מהימים שהם לא טסים הם יכולים על אותו שכר גלובלי ללכת לימי סימולטור, בלי לפגוע בלוח הטיסות. | |
|
|
|
|
|
||
|
||||
|
אני לא יודע מה מבנה השכר של טייסים בחברה אמריקאית, אבל לדעתי טייסים בטיסות פנים עובדים סדר גודל של חמש משמרות בשבוע וטייסים בטיסות בינ''ל נהנים מימי מנוחה בין הטיסות שמוגדרים היטב בחוזים של האיגודים המקצועיים שלהם ואולי מעוגנים בתקנות. אין להם איזה מין ''תפקיד בטייסת'' כמו שיש לטייסים בחיל האוויר. העבודה שלהם היא לטוס, כל דבר אחר לא מכניס כסף לחברה. לדעתי גם הסמכה כזו היא לא ענין של לעשות ימי סימולטור פה ושם. כאמור, יש מספר קטן מאד של סימולטורים. לחברה כמו יונייטד יש סימולטור אחד. אז זה אומר שהטייס מגיע לשם נגיד לשבוע או שבועיים, נמצא במלון ועובר הדרכה ובחינה רציפה עד להסמכה. תכפיל בכמה מאות טייסים וזה לא מעט כסף. אגב, גם לצוות התפעול של הסימולטורים יש מן הסתם עלות לא פעוטה. אני מניח, למשל, שבצוות כזה, מעבר לתפעול הטכני, יש שניים-שלושה טייסים מנוסים ומיומנים שמכירים היטב את המטוס המסומלץ. האנשים האלה אחראים על בניית התרחישים, על התדרוך והתחקור של הטייסים לפני ואחרי סימולציה ועל בלת''מים שהם מכניסים תוך כדי ההטסה. אנשים כאלה עולים הרבה כסף. |
|
|
|
|
|
|
||
|
||||
|
כמה כסף כבר עולים שניים-שלושה מפעילי סימולטורים? מיליון דולר בשנה? זה בוטנים. והם גם עולים למפעילת הסימולטור, לא לחברות התעופה. והם בונים פעם אחת את חבילת התרחישים, וחוזרים עליה שוב ושוב מאות פעמים מול המתאמנים. זה לא שעל כל טייס הם מתחילים הכל מחדש. |
|
|
|
| חזרה לעמוד הראשי |  |
| מערכת האייל הקורא אינה אחראית לתוכן תגובות שנכתבו בידי קוראים | |
 RSS מאמרים |
כתבו למערכת |
אודות האתר |
טרם התעדכנת |
ארכיון |
חיפוש |
עזרה |
תנאי שימוש
|
© כל הזכויות שמורות |