מה מפריע לעובדים? מחקר להבנת המחשבות והתחושות של העובדים בקבוצה

הקדמה

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

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

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

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

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

למרות זאת, בנקודה שעליה מדובר, מסיבות שונות העניינים לא עבדו בצורה כה חלקה:

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

 

המנהלים הבינו שיש דברים שמציקים לבודקים; אבל כיוון שלא כולם דיברו, או שלא כל המנהלים שיתפו, בגדול הם לא ידעו בדיוק מה מפריע לבודקים, למשל: מה דעתם של הבודקים על מקום עבודתם? מה כן טוב וצריך לשמר? מה ניתן לשפר?

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

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

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

התהליך

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

כך ראיתי את התהליך:

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

 

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

השאלות

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

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

המשתתפים

23 מתוך 30 בעלי הסכימו להשתתף.

הראיונות

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

כל מי שהסכים שיתף אותי במה שמפריע לו.

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

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

Photo by mentatdgt from Pexels

מה היו חלק מהנושאים שעליהם דובר

• ניהול אנשים;
• פיתוח אישי;
• נושאים כלליים (כמו שיתוף-פעילה עם קבוצות אחרות;
• גיבוש הקבוצה;
• העברת יידע לחדשים וגם לאלה שלא.

ניתוח הממצאים

כל מה שנאמר נרשם על notepad. כשהעברתי את המידע לאקסל, אף שרק אני קראתי אותו והוא נשמר עם סיסמה, כבר לא רשמתי עם שמות. בנוסף מחקתי כל דבר שיכול היה לזהות את הדובר

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

• חלוקת הנאמר לפי נושאים שלא נקבעו מראש;
• ציון כמות אנשים שהעלו את הנושא;
• תמצות של מה שהם אמרו.

התוצאות

את התוצאות סידרתי לפי האחוז של האנשים שהעלו אותם.

בכל נושא השקף הראשון היה: כמה אנשים העלו את העניין.

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

 

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

ההצגה

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

קבלה והמשך

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

הדיון היה פורה, ואף קבענו וישבנו בישיבות המשך.

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

 

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

מסקנה אחרת

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

מיגרציה מ-Quality Center ל-Jira חלק ראשון: אסטרטגיה

הגיע היום גם אצלנו לעבור מה-Quality Center, להלן QC, שהיה בעבר של מרקיורי, אח"כ של HP וכיום של מיקרופוקוס, לג'ירה.

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

בנוסף, ה-QC מיושן גם בראיית העולם שלו (הארגיון שלי עבר לאג'ייל לא מזמן) וגם בניראות שלו. ולבסוף, ממילא צריך לקנות רישיונות לכולם בג'ירה, אז למה לבזבז רישיונות גם ל-QC?

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

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

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

חלק ראשון: אסטרטגיה

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

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

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

ה-QC נמצא אצלנו בשימוש שנים רבות שבמהלכם ערכנו שינויים רבים למערכת, כמו שינויי קוד, שימוש במאות רשימות חלקן מקושרות וכד'.

אז כמו שלא נעביר את כל הבאגים לא נעביר את כל השדות.

ריכזתי ב-Confluence את כל סוגי ה-defects שיש לנו, את כל הפרוצדורות וה-workflows שאנו משתמשים בהם.

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

בחלק הבא נעסוק בחלק היותר טכני של המעבר.

עצות לבודק שעובר לאג'ייל (או שכבר שם) - ראיון עם בוריס יוזבינסקי

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

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

הנה כמה אפשרויות פחות טובות:

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

- הבודק האוטרקי: בודק זה בא לעבוד וחשוב לו לעשות עבודה טובה, אבל הרבה יותר חשוב לו להיות המומחה הבלתי מעורער בבדיקות. אין צורך להתייעץ, אין צורך לשתף אף אחד.

הבודק האינרצי: אג'ייל שמג'ייל, אני ממשיך לבדוק כמו שתמיד בדקתי, כמו בימים הטובים של תסריטי בדיקות מפלצתיים ובדיקות ידניות.

הבודק השקט: זה שאני יושב עם הפיתוח בחדר לא אומר שאני צריך לדבר איתם!

הבודק הסקריפטופוב: לא לא! רק לא אוטומציה!

  

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

  

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

--------------------------------------------------------------------------------------------------------------------

הראיון

בוריס, ספר לי קצת על עצמך:

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

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

נטו OJT.

  

ולבדיקות נטו איך הגעת?

בתפקידי השני ב"פוליקום" במשרת סטודנט. עסקנו בתקשורת בפתרונות Tailormade לחברות גדולות כמו IBM. ואח"כ הגעתי ל-AVG.

מה מעניין אותך במקצוע הבדיקות?

ההכרה של המוצר בשלמותו, אבל גם את כל הרבדים. אתה הש"ג. אתה אומר מה המצב ואם אפשר לצאת קדימה. כל השאר בתהליך הוא חותמת גומי. אתה חותמת אמתית, אתה באמת מוודא שהמוצר טוב.

איך קיבלת את הבשורה על המעבר לאג'ייל, לפני שזה קרה?

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

ואיך זה היה בפועל?

בהתחלה כן, עד שלמדתי איך לעבוד בתוך הצוות ומשם התפתחתי.

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

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

כשהיית בצוות הבדיקות לא יכולת ללמוד את הדברים האלה

יכולתי אבל זה לא היה אותו דבר. השגת המידע היה קשה יותר בתור מישהו חיצוני לצוות.

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

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

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

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

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

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

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

האם ריבוי המשימות שלך לא מסיט אותך מהבדיקות עצמן?

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

מהי העצה שלך לבודק שעובד היום לאג'ייל?

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

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

אתה רוצה לעשות שינוי בקריירה לכיוון ניהול מוצר. למה לעזוב את הבדיקות?

גם קצת מיציתי אחרי 4 שנים. הבנתי שאני לא רוצה להיות מפתח. יותר מעננן אותי כרגע  הצד של הביזניז. יש כאן ראייה רחבה יותר מאשר הבדיקות ושם אני רואה את עצמי גם בעוד 10 שנים. יש לי גם Passion לזה.

--------------------------------------------------------------------------------------------------------------------

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

השאלה היא:

Are you up to it?

תעלומת החולצה הכחולה

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

  

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

  

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

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

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

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

תעלומת החולצה הכחולהתעלומת החולצה הכחולה

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

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

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

  

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

מבנה קבוצת הבדיקות בחברת AVG ישראל

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

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

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

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

3. כתיבה מתודולוגית של ה-STD כולל את תהליכי הריוויו הפנימיים והחיצונים וכד'. העברה של הפרוגרסיה לרגרסיה וכד'.

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

5. ניטור של הבדיקות: התקדמות, באגים, תוצאות הבדיקות וכד'.

6. ייצוג בישיבות.

7. פוקל פוינט של המוצר.

8. עזרה בדיבאג של בעיות וניתוח שלהן.

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

10. ניהול מאגר הידע (וויקי).


הגדרת תפקיד הבודקים:

1. כאמור למעלה הבנת המוצר "מוצרית" וטכנית. זה עוזר מאוד ובא לידי ביטוי בבאגים איכותיים.

2. הרצה מדוייקת. של ה-STD.

3. תפוקה מסויימת.

4. פתיחה טובה של באגים.

5. יכולת מעבר דינמית בין משימות.

כשאני מספר את האמור לעיל, כאמור להרבה אנשים זה נשמע מוזר. אולי בגלל שאנליסטים (כמעט) ואינם מריצים את הבדיקות. אולי סתם כיוון שהם אינם רגילים לסידור כזה, ואולי הם רוצים לומר ש:
1. בין רגרסיה לרגרסיה, אפשר להנות גם מהרצה ופתירת בעיות טכניות. צודקים!
2. אנליסטים עלולים לאבד את ה"טאצ'" הטכני.
3. אנליסטים עלולים לאבד את החיבור הטכני למוצר.

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

הצעת עבודה

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

יתרון משמעותי יהיה לבעל/ת ידע רב באינטרנט (קונוונציות, התמודדות עם בעיות, ווב 2.0 וכד') ובמערכות הפעלה, בעיקר Windows, ובעל/ת רצון עז להשתלב בתחום.

להלן ההגדרות המדוייקות.

1. Full time position.
2. Design tests: Understand system behavior, Cover new requirements and affected features
3. Execute tests: Run pre-defined test cases.
4. Open, analyze, track and retest defects. Identify failures, Define failures impact & severity
5. Provide status and progress reports, Summarize test results and Report testing status.

Skills
1. Independent learning ability
2. Multitasking
3. Good interpersonal relations
4. Cope with pressure conditions
5. An organized and responsible personality
6. Technical approach
7. Personal Integrity and Dedication to the profession.
8. Ability to analyze/use technical documents (Specifications, project specific documents)
9. Deep understanding of system architecture (hardware and software).
10. Intercommunication skills – ability to interact with and receive full cooperation of project members (without formal authority).
11. Both Team working and independence capabilities

Pre-Requisite
1. Internet understanding and knowledge – Mandatory.
2. Excellent Hebrew and English (Writing, Speaking) – Mandatory.
3. Experience with Windows operating systems– Mandatory.
4. Academic Degree (Science / Computers) – Advantage.
5. Experience in Software Development - Advantage.

ניתן לשלוח קו"ח למייל זה:
doronb@blogtv.com

מקרים מהחיים: חשיבותן של מדידות

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

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

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

קומברס

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

1. ניפטר מהטריוויאלי: כיוון שאת לא רוצה עוד אלפי מחפשי עבודה.
2. כיוון שמרבית האנשים בחברה היו מקצועיים לעילא ועילא, בעלי ראש גדול ואיכפתיות. ואני אומר את זה לא בקלות, כי אני לא אוהב משפטים כלליים מהסוג הזה. מה שאומר שהבעייה בקומברס היא בראש. לא פלא שאנשים טובים כמו זאבי ברגמן וירון צואלה לא שם. לא עבדה שם שיטת ה"יהיה בסדר" - דברים תוכננו מראש, סיכונים נלקחו בחשבון. כל כך נדיר במקומותינו. חבל על האנשים הטובים האלו. אבל אני מאמין שהם ימצאו עבודה בקלות, וראי סעיף 1.
3. כיוון שזה היה בי"ס לכל מי שעבד שם. גם המקצוענות של העמיתים שלך, גם התהליכים המסודרים, שיטות העבודה החדישות, המונחים שלמדת. אם יש משהו שאני יודע על ניהול, למדתי אותו בקומברס, בעיקר מאנשים כמו רונית ליניק, קרן עידן.
4. כיוון שבקומברס אם היית בא עם רעיון לשיפור, אפילו לא פשוט, היו מתייחסים לזה בראש פתוח, ולא מייללים שאין זמן ליישם את זה. למעשה, דברים הבאת דברים כאלו היו קרש קפיצה בקריירה.
5. כי האתגר המקצועי היה אדיר.
6. כיוון שבזמנים הטובים זו הייתה גאווה להיות חלק ממכונה משומנת וענקית זו.
7. כי היה הרבה action והרבה אחריות.

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

האם הווב מת והאינטרנט הוא מחליפו?

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

הבעיה של בדיקה רק לפי תסריט

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

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

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

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

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

אגב, זו אחריות שעלי לקחת על עצמי ללא ספק.

בסופו של דבר, אלו הנתונים:

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

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

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

באג ה-32, או: איך לבודד באג

בתפקידי הראשון בתחום, ולמעשה בשבוע הראשון, בדקתי אפליקציה אשר מתממשקת ל-Outlook, כלומר אתה פותח את האאוטלוק ומוצא מודולים נוספים שאנחנו הכנסנו בתחום של CTI, שזה Computer Telephony Integration.

בבדיקות הבחנתי בתופעה הבאה: אחרי שימוש ארוך של כמה שעות המודול שלנו באאוטלוק היה נתקע.

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

לקח: האם בפועל זה יעבוד?

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

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

מנהלי קומפוננטה

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

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

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

למשל: מי ייצור מפת תלויות של כל הקומפוננטות בגרסה? מי יתאם לוחות זמנים?

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

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

הוא קבע ישיבה עם כל הגורמים הרלוונטיים.

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

כמו כן אנשים שעד בה עבדו בשיטת הסמוך קשה להם לקבל מרות.

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

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

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

וכך היה גם כאן.

מקרים מהחיים: אחריות במערכת מורכבת

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

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

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

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

המורכבות של הפשטות

חזור לרשימת הרשומות