בתשובה להפונז, 24/01/20 13:57
 |
|
 |
||
|
||||
 |
אם לקוח מוכן לשלם פחות כסף תמורת מוצר איכותי פחות, למה זה "רעה חולה"1? בנוסף לאיכות במוצרים שונים יש חשיבות שונה, יש הבדל - למשל - בין מערכת שיווי המשקל למערכת בידור באותו מטוס. אם מערכת ההפעלה של הטלפון הנייד שלי תתקע, אני אאתחל אותו, אם מערכת ההפעלה של חברת החשמל תתקע, לא יהיה חשמל למאות אלפי אנשים. כל זמן שהלקוחות מודעים לעובדה שהחיסכון נובע מהחיסכון בבדיקת האיכות והחיסכון בבדיקת האיכות לא מתבטא בסיכון בבריאות או בחיים, זה נשמע לי בהחלט לגיטימי ולפעמים אפילו מבורך. המתודולוגיה שגורסת שכל מפתח (למעשה, צוות של מפתחים) צריך להיות אחראי לשירותים שהוא מספק לא באמת שייכת. ז"א גם מי שמשתמש במתודולגיה הזאת יכול לדרוש במקביל בדיקת איכות גבוהה (או נמוכה), רק שמדובר בצוות אחד שעושה את הכל במקום שני צוותים שונים. במקומות בהם ראיתי את זה מתממש העבירו אנשים מבקרת האיכות לצוותי הפיתוח ולא פיטרו אותם. 1 מלבד לרעה הברורה שבאובדן העבודה למי שהתמחה בבקרת איכות. |
 |
 |
 |
|
|
|
||
|
||||
|
יש תחומים שבהם זה "למה לא". הטלפונים הסלולאריים של נוקיה היו עמידים באופן לא רגיל. היתה שאלה פילוסופית כמו השאלה אם אלוהים יכול לברוא עצם שהוא לא יוכל להזיז- האם צ'אק נוריס יכול לשבור נוקיה? עכשיו העולם התרגל שאם מחליק לך הטלפון מהיד על הרצפה תגיד לו שלום. בתמורה המחיר של הניידים הסינים די מצחיק, ואם אתה בכל זאת רוצה לשמור על המכשיר שלך אתה קונה לו הגנות. למה לא? יש איזו סינוסואידה של התכנסות לאופטימום כלשהו בכל מיני מכשירים- בהתחלה המוצרים בנויים לתלפיות, אחר כך בתהליך מזורז הם הופכים לזבל מתפרק, ואז חוזרים לאיכות סבירה. כתבתי פעם על מכונות כביסה, סוללות וכו' בתגובה 645919 אבל מטוס נוסעים? סליחה? מישהו חסר משאלת מוות יטוס במטוס שידוע שהוא זבל מתפרק? |
|
|
|
|
|
|
||
|
||||
|
מטוס נוסעים זה מערכת מאד מורכבת. אם מישהו יציע לי הנחה של 40% בכרטיס הטיסה בידיעה שהאיכות של מערכת הבידור לא נבדקה עד הסוף ואולי אאלץ לאתחל אותה מידי פעם או חס ושלום לקרוא ספר, הייתי הולך על זה בלי להסס. אם זה יהיה במערכת חיונית, לא רק שלא הייתי הולך על זה, אלא הייתי דורש להעמיד את יצרני המטוס לדין. נראה לי שאנחנו מסכימים. | |
|
|
|
|
|
||
|
||||
|
|
|
|
|
|
|
||
|
||||
|
הלקוחות שאני מדבר עליהם לא היו מוכנים למוצר טוב פחות. ולכל בעיה שהם גילו היו השלכות משמעותיות, כולל רכבות אויריות של מהנדסים ומפתחים לאתר הלקוח שעולות הון זמן וכסף. חגבי הפסקה האחרונה - הסיבה שמפתח לא יכול לבדוק לחלוטין את המוצר שהוא פיתח. החל מזה שאף אחד לא רואה את הדבשת שלו, ועד לזה שמפתח הוא לא משתמש, והוא רואה את החלק שלו ולא מכיר הרבה פעמים אפילו את כל המןצר הסופי, ומעטפת השימוש שלו. קל וחומר כשמדובר במערכת מולטידיסציפלינרית, שבסוף הפיזיקה והמכמיקה והתוכנה והחומרה שלהן תלויות הדדית. כמו שטייס לא יכול להכיר את כל הקוד במטוס שלו, כותב תוכנה לא יכול להכיר את כל התרחישים בזמן טיסה. זה בדיוק התפקיד של בקרת האיכות. |
|
|
|
|
|
|
||
|
||||
|
בדיוק. ולכן התוכנה לא כללה את הדבר הפשוט ביותר- ניתוק של המערכת (שמטרתה למנוע הזדקרות, כן?) מעל מהירות מסויימת. | |
|
|
|
|
|
||
|
||||
|
ומאיפה ההנחה שבבקרת איכות היו חושבים על הדבר הזה שנראה לך עכשיו כל כך מתבקש בדיעבד? | |
|
|
|
|
|
||
|
||||
|
המטרה של בקרת איכות היא בדיוק זו - בניית סט תרחישים, מהרגילים ועד אלו שבקצה מעטפת הטיסה, כולל תאונות, תקלות, תקלות חיישנים ושאר ירקות. עם ההסתייגות הטריויאלית שתמיד יהיה תרחיש חריג ומוזר שיימלט מעיני מישהו. ולכן גם ההכשרה הנדרשת מאנשי בקרת איכות - וניסןיי טיסה במקרה הזה - היא לגמרי אחרת משל מהנדסי התוכנה. מהרבה. בחינות, אנשי בקרת האיכות צריכים להיות קרובים יותר לטייסים (המשתמשים באופן כללי יותר), ולידיעת אופני השימוש של המערכת, מאשר למהנדסי התוכנה שצריכים להתמצא במערכות הפעלה, שפות תכנות, לוגיקה חישובית ושאר ירקות. ככאלה - מציאת תרחישי קצה היא בלב הדרישות מאיש בקרת איכות, וודאי במערכות קריטיות כמו מטוסים, ציוד רפואי, מערכות חלל, וכמובן מכוניות בואכה אוטונומיות. אי אז בתחילת ימי הג'יפיאס, הייתי שותף לבחינת המערכות המבצעיות הראשונות במסוקים. בין השאר, לא היססנו להגדיר תצורות טיסה קיצוניות, כולל טיסה הפוכה ותמרונים שממש לא אופייניים למסוקים, כדי לבחון מתי מתנתקת הקליטה של המערכת. איש בקרת איכות/ניסויי טיסה שהחמיץ תרחיש, שקול לאיש תוכנה שאיפשר גלישת זכרון וקריסה של האפליקציה שלו. המקצועיות של שניהם נשפטת בדיוק על פי סיכולם של מקרים כאלה. מי שמצפה מאיש תוכנה למלא את תפקידו של איש בקרת איכות, שרוי באותה פנטזיה כמו מי שמצפה ממהנדס ניסויי טיסה להיות אחראי לשחרור פוינטר ביציאה מפונקציה. |
|
|
|
|
|
|
||
|
||||
|
לא. אבל מה המניעה שאנשי בקרת איכות יהיו באותו הצוות שמפתח? בכל מקרה, זו דרך פיתוח ששימושית במצבים מסוימים, אבל דווקא בואינג לא השתמשה בה. לכן גם אם בדרך הפיתוח של בואינג היו בעיות, זו לא הייתה בעיה בדרך הפיתוח שלהם. לכן לא מועיל לערבב בין הנושאים. |
|
|
|
|
|
|
||
|
||||
|
מה המניעה שאנשי חומרה יהיו בצוות תוכנה ולהיפך? כי אלה למדו הנדסת חשמל, ואלה למדו הנדסת תוכנה. זה שאתה סתם שם את הקו במקום אחר זו פיקציה. הטענה המקורית היתה שמבטלים את מחלקות הqa, ומנסחים אידיאולוגיה לפיה אנשי התוכנה יבדקו את עצמם, לא שמעבירים את אנשי הבדיקות תחת שם אחר למחלקת פיתוח התוכנה. והרי התמרוץ העיקרי של מנהל לצמצום מחלקות הqa הוא שהוא מפטר אנשים וחוסך כסף - את זה רואים ישר בדוחו'ת הרבעוניים - לא שהוא מעביר אנשים ממקום למקום. על זה הוא לא יקבל שום תגמול. |
|
|
|
|
|
|
||
|
||||
|
מה המניעה שבאותו הצוות יהיה גם איש חומרה אחד? אם הצוות צריך לפתח חומרה, יהיה שם גם מפתח חומרה אחד. בכל מקרה, כמו שצוין, מה שמנסים להשיג כאן הוא האצה של תהליכי הפיתוח, ומקבול שלהם. |
|
|
|
|
|
|
||
|
||||
|
נראה לי שאתה מפספס את כל הטיעון שלי, לא יודע איך לענות לך. ברור שמנסים להאיץ את הפיתוח, הטענה שלי היא שזה על חשבון האיכות, ומנהל שאומר אחרת מרמה את החברה ואולי את עצמו. |
|
|
|
|
|
|
||
|
||||
|
יש בשיטה הזאת הרבה בעיות - אבל פגיעה באיכות? למה? | |
|
|
|
|
|
||
|
||||
|
אני מתקשה לרדת לעומק הדיון בינך לבין הפונז, אבל אני חושב שהפרטים הם לא העיקר. העיקר הוא סדר העדיפויות, בעצם התרבות התאגידית של החברה. כאשר הרווח הרבעוני בראש סדר העדיפויות מעגלים פינות כדי להעביר את המטוס מה שיותר מהר דרך הרגולציה, וכדי למנוע הוצ. "מיותרות" של הכשרת הטייסים. כנראה שגם לא עושים את ה QA כמו שצריך. במקרה קיצון, כמו פולקסווגן, פשוט מרמים. כאשר המוניטין והגאווה המקצועית של החברה הם בראש סדר העדיפויות, לא תהיה שום פשרה בנושאי בטיחות של מטוסים. סולם הערכים והתרבות התאגידית הנגזרת ממנו של בואינג היו שונים בעבר. אותם מהנדסים ומנהלי ייצור שהתריעו על הבעיות מחזיקים עדיין בתרבות התאגידית הישנה של בואינג. אחד מהם עזב את החברה, מה שמוכיח את השינוי בסולם הערכים של החברה. |
|
|
|
|
|
|
||
|
||||
|
ובינתיים, טיסה ראשונה של בואינג 777X, שנכנס "לשלב הבא בתהליך הבדיקות הקפדניות". 777X הוא שידרוג של ה-777 ושילוב טכנולוגיות מתקדמות מה-787. |
|
|
|
|
|
|
||
|
||||
|
אם הלקוחות לא מודעים להורדה באיכות והחיסכון לא מתבטא בהוזלה במחיר אלא רק בהגדלת הרווחים זאת כבר רמאות לשמה. אני לא מכיר את התופעה הזאת (לא אומר שהיא לא קיימת). ברור שמפתח לא יכול לבדוק את המוצר שהוא פיתח, הטענה היא שצוות שכולל מפתחים ובודקים יכול לפעול בצורה טובה יותר מאשר שני צוותים נפרדים. מנסיוני, לפעמים זה באמת עובד, לפעמים לא, זה תלוי במוצר, בתרבות הארגונית, בעובדים ובהנהלה. |
|
|
|
|
|
|
||
|
||||
|
אנחנו לגמרי מסכימים לגבי הפסקה האחרונה, היא רק לא דומה לתהליכים שראיתי שקורים במציאות, שבהם מקצצים באנשי הבדיקות ולא סתם מעבירים אותם מקום ישיבה, מהסיבות שציינתי. | |
|
|
|
|
|
||
|
||||
|
לא רק בצורה טובה יותר אלא גם בעלות מופחתת; איש QA משתכר פחות מאיש פיתוח. | |
|
|
| חזרה לעמוד הראשי | המאמר המלא |
| מערכת האייל הקורא אינה אחראית לתוכן תגובות שנכתבו בידי קוראים | |
 RSS מאמרים |
כתבו למערכת |
אודות האתר |
טרם התעדכנת |
ארכיון |
חיפוש |
עזרה |
תנאי שימוש
|
© כל הזכויות שמורות |