בתשובה לרון בן-יעקב, 10/01/20 7:31
 |
|
 |
||
|
||||
 |
אפס פגמים בתוכנה הוא כמו אפס פגמים בחלקים אחרים של השרשרת: אותו כלל בסיסי פועל בכל מקום. כלל פארטו: אתה יכול להשיג 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 משתכר פחות מאיש פיתוח. | |
|
|
| חזרה לעמוד הראשי | המאמר המלא |
| מערכת האייל הקורא אינה אחראית לתוכן תגובות שנכתבו בידי קוראים | |
 RSS מאמרים |
כתבו למערכת |
אודות האתר |
טרם התעדכנת |
ארכיון |
חיפוש |
עזרה |
תנאי שימוש
|
© כל הזכויות שמורות |