על המלכודת הפנימית של תעשיית ה IT ואיך נוצרים מוצרים פחות טובים (ספיישל יום כיפור)

לאחרונה יוצא לי קצת להתעסק בהרמת הבלוג.

אחת החוויות החיוביות והמפתיעות שהיו לי היא התקנה של הwidget של Outbrain. ה widget הוא תיבת ה \"בנוסף אולי תאהב/י את…\" שנמצא פה בבלוג בתחתית כל פוסט (הוא זקוק לעוד זמן תוכן ותעבורה כדי לעבוד כמו שצריך פה בבלוג).

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

הממ… עסוק באמצע העבודה כדי לפרט? טיפים? אומר לעצמו \"הוא טכנולוג, הוא כבר יסתדר\"?

לא ציפיתי לכיף חיים. הוספתי גוגל אנליטיקס ממש לפני זה ונאלצתי לחפש tutorial בגוגל, לערוך את ה HTML View של הבלוג ולשתול javascript שנתנו לי. ואז עוד עשר דקות בפורומים של גוגל להבין ש \"invalid connection\" בסוף ההתקנה הוא נורמאלי וייקח לו עד חצי שעה להתרפרש.
גוגל אנליטיקס ובלוגר הם שני מוצרים של גוגל – חברת ענק עם גוף פיתוח שידוע באיכותו הגבוהה. ואאוטבריין? סטארט-אפ ישראלי?

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

פתאום הייתי בבלוגר – מאשר להוסיף? מאשר.
נגמר.

מה???
בדקתי כמה פעם לא מאמין – הכל עובד.

אני לא יודע אם החוויה שלי היא המייצגת, אבל היא בהחלט הייתה טובה. הדהדו לי קולות של מנהלי מוצר שעבדתי איתם בעברי: \"המשתמש הוא administrator – הוא יסתדר גם עם להקליד regex במקום להקליק על checkbox\". \"זה משתמש טכנולוגי, אז שימחק הכל וייצר את הרשימה מחדש, הוא ימצא עזרה בגוגל\".

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

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

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

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

מה עושים?
מנהל בכיר שהכרתי הציע ברגע של יאוש לשלוח מאמר בנושא ל all-customers@worldwide.com, המייל חזר.

הייתי שמח מאוד לראות חרם צרכנים של אנשי IT: \"לא Wizard – לא קונה\". מהפכת צרכנים כמו שקרתה בעולם המערבי בשנות החמישים.*

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

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

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

יש תקווה של אבולוציה, כיוון שהשוק מתבגר לאט לאט (לאט) – ודורש עלות תפעול משפורת.

ויש את המציאות הקיימת שנדרש להמשיך להתמודד איתה.

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

בקיצור, גמר חתימה טובה וצום קל.

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


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

איך לגרום לאנשים להקשיב לכם יותר?

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

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

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

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

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

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

טיפ מס\' 2
את הטריק הבא למדתי בסדנא של סער פאר המצוין:

\"יודעים מה ההבדל בין מנהל מו\"מ טוב למצוין?\" הוא שאל. אני תמיד רוצה ללמוד מהמצוינים*, אז הקשבתי בסקרנות. \"באוניברסיטת Whatever עשו מחקר גדול ועקבו על מנהלי מו\"מ\". חילקו אותם לטובים ומצוינים\". \"עקבו אחרי מספר פרמטרים ומצאו אחד, קטן לכאורה שהסביר את ההבדל. יודעים מהו?\". נו ?? – הסתקרנתי. \"כשהצד השני התחיל לומר דברים עליהם לא הייתה הסכמה הטובים אמרו… \'אני לא מסכים איתך, 1 2 3\' ואילו המצוינים אמרו \' 1 2 3  ולכן אני לא מסכים איתך\'\".

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

אין לי מדד אובייקטיבי, אך ההרגשה שלי היא שהטיפ עובד.

נסו ושתפו כיצד זה עובד לכם.

ליאור

* אפרופו השאוות בין טובים ומצוינים ומה ניתן ללמוד מהן: ישנה קלאסיקה ניהולית קולסאלית בשם \"מטוב למצוין\" Good to Great שמשווה בין מנהלים טובים ומנהלים מצוינים ומצליחה לפספס בגדול מאוד: בפועל המחקר השווה בין מנהלים שמרנים לבין מהמרים גדולים – וכיוון שרק מהמרים שהימורם צלח נכנסו למדגם – המסקנה הייתה שמנהלים טובים הם מהמרים שהולכים על הקצה.
את הניתוח המלא ועוד כמה דוגמאות טובות לאיך אנשים נבונים יכולים לטעות בגדול ניתן למצוא בספר המעולה (של מחבר אחר) בשם \"אפקט ההילה\" (The Halo Effect). הספר ממולץ בחום!

איכות תוכנה – ארגז כלים (3)

המשך ל פוסט 2: איכות תוכנה – ארגז כלים

מחפשים כיצד לשפר את איכות התוכנה ומחפשים אחר ה Best Practices בתעשייה?

בטבלה למטה ריכזתי את הטכניקות העיקריות שעברו את מבחן ההוכחה בתעשייה. ציינתי גם התייחסות כמה אתם יכולים לצפות לשיפור באיכות הפנימית (IQ – Internal Quality) או החיצונית (EQ – External Quality). אנשים לדוגמה מופתעים ש Unit Tests לא תופס הרבה באגים – אבל זו עובדה מוכרת. לעומת זאת טכניקות כמו Code Inspection ו TDD פחות מוכרות ברחבי התעשייה – אבל מניסיוני הן אפקטיביות ביותר. שימו לב שהטכניקות הקלות יותר להטמעה הן אלו שנפוצות בקרב האירגונים – זה דבר טבעי.

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

בתחתית הטבלה ציינתי עוד כמה נקודות חשובות.

טכניקה
השפעה על איכות חיצונית EQ
השפעה על איכות פנימית IQ
כמות השקעה
קושי הטמעה
הערות
תהליכים – לרוב קורים לפני או בזמן הפיתוח. לא מסכנים את הקוד. יעילים בצורה מפתיעה.
לא רלוונטי
בינונית
נמוכה
נמוך
הרצת בדיקה ואינטגרציה בצורה אוטומטית מיד אחרי כל שינוי קוד ולא בסוף גרסת הפיתוח. נקודת פתיחה טובה ובסיס לבדיקות רגרסיה.
Bug Tracking
גבוהה
נמוכה
נמוכה (לארגון)
נמוך
מעקב יסודי אחר כמות הבאגים וקצב הפתיחה / סגירה.עם המדידה באים הלחצים והרעיונות לשיפור. הכרחי!
 Requirements Inspection & verification
גבוהה
עקיפה בלבד
בינונית
בינוני
לעתים קרובות לא נעשה או נעשה בצורה חפיפה. הכוונה להשקעה יסודית בבחינת ואימות הדרישות.
 Formal Design Inspection
נמוכה
גבוהה
בינונית
גבוה
לעתים קרובות לא נעשה או נעשה בצורה חפיפה. בחינת אלטרנטיבות אמיתיות וסיבות על כל שינוי מהותי במערכת שנבע אפילו מתיקן באג – לא אותם מסמכים שמתארים את המובן מאליו מתובל ב interfaces וקוד!
גבוהה
גבוהה
בינונית
בינוני עד גבוה
קריאה אינטנסיבית של קוד ללא מחשב + דיון. זהו לא ה  freestyle Code Review שעושים לעתים בארגונים.
Peer Review
נמוכה
בינונית
נמוכה
נמוך עד בינוני
ישיבה עם מתכנת או ראש צוות עד רבע שעה לפני check-in 
בדיקות רגרסיה – מגבירים את הביטחון והיכולת לבצע refactoring בבטחה. כיסוי גבוה נדרש להשגת האפקט.
Unit-Tests
נמוכה
בינונית
גבוהה
גבוה
לכל class בקוד – בדיקה. נכתב ע\"י המפתח. קשה מאוד להטמעה בקוד שנכתב ללא unit tests
Integration / Component Tests
בינונית
נמוכה
בינונית
בינוני
בדיקה ל flow בקוד שכולל מספר classes. נכתב ע\"י המפתח.
Acceptance Tests
בינונית
זניחה
בינונית
בינוני עד גבוה
בדיקת black box למערכת עצמה, הזרקה של input ובדיקת התוצאות. נבדק לעתים קרובות ע\"י \"צוות אינטגרציה\"
GUI Tests
בינונית
זניחה
גבוהה
בינוני
בדיקת ה UI ע\"י כלים שמדמים browser (כמו Selenium). בדיקות קשות לתחזוקה אך הדרך האוטומטית לבדיקת GUI.
TDD
זניחה
גבוהה
בינונית
בינוני
טכניקה משופרת לכתיבת unit-test, משפר את המודולריות בקוד, יעילות כתיבת הבדיקות וכתיבת בדיקות יציבות יותר. כיף חיים!
אחרים
גבוהה
זניחה
גבוהה
נמוך
צוות QA שעובד בצורה נבונה ומתמקד בבדיקת הפונקציות החשובות והמורכבות של המערכת
Testing Tools
נמוכה
זניחה
בינונית
נמוך
השקעה בכלי עזר שיעזרו למפתחים ו QA לבדוק מהר יותר וטוב יותר. מאפשר למפתחים לבדוק יותר ולהתעייף פחות.
נמוכה
זניחה
בינונית
גבוה
העמדת המערכת בעומס גבוה לראות מה נשבר ראשון. לרוב מגלה מספר מצומצם של בעיות, אך בעיות שהיו קורים אצל לקוחות.
Alpha / Beta Test
בינונית
זניחה
נמוכה
גבוה (מחוץ לפיתוח)
להגיע ללקוח מהר עם מוצר לא גמור ולבדוק את המוצר אצלו ובעזרתו. מסייע לאימות Requirements שיכול להיות קריטי להצלחת המוצר!
Static Code Analysis
בינונית
נמוכה
נמוכה
נמוך
כלים אוטומטים שמנתחים את הקוד למצוא בעיות. PMD, Find bugs ו CheckStyle הם המפורסמים בג\'אווה, כאשר יש כלים כמו Sonar או פלאג-אינים כמו QA Plug שמרכזים את כולם ביחד.

להוסיף (חשוב!): Eat your own dogfood

עוד כמה הערות:

Formal code / design / requirement inspection – כמו שניסיתי לציין בטבלה יש הרבה ארגונים שעושים חלק מזה, אבל בצורה לא יסודית ולא יעילה. ראיתי המון מסמכי designs בחיים שחבל שנכתבו. הרבה ישיבות design או requirements review שהיו ריקות מתוכן כי לאלו שאמורים לעשות את הביקורת לא היה ידע מספק \"לעשות את העבודה\". לסיכום: קל ליפול בטכניקות הללו לביצוע בינוני בלי לשים לב.

בדיקות רגרסיה
הסוגים השונים של הבדיקות הן לא כ\"כ אלטרנטיבות אחת לשנייה, אלא יותר משלימות. רגרסיה טובה כוללת הרבה unit-tests, מספר לא מבוטל של integration ו acceptance tests ומעט GUI Tests (פרמידת הבדיקות). פוסט טוב שמסביר קצת יותר ניתן למצוא כאן.

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

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

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

בהצלחה!

איכות תוכנה – סוגי איכות (2)

המשך לפוסט ראשון בסידרה: איכות תוכנה – היכן מתחילים?

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

(External Quality (EQ – איכות חיצונית, כל מה שמפריע ללקוח / משתמש. ניתן למדוד ע\"י מספר קריאות ה \"?!WTF\" בשנה שבוקעות מגרונם של לקוחות או משתמשים ברחבי העולם. לרוב הליקויים האלו יתבטאו בבאגים (דבר שהמוצר הבטיח אבל לא קיים) או שימושיות (usability).

(Internal Quality (IQ – איכות פנימית, איך המוצר נראה מבפנים למי שעובד עליו, מפתח אותו ומתחזק אותו. ניתן למדוד אותו ע\"פ מספר קריאות ה \"!?WTF\" של מפתחים ומנהלים בגוף הפיתוח, לרוב אנשים חדשים בארגון שעדיין לא הסתגלו למצב הקיים. מדובר בארכיטקטורה לא טובה, קוד מכוער ומסובך, פיצ\'פוצ\'ים רעים בקוד ובמועקה נפשית אמיתית בשעת ביצוע debug למערכת.

למרות שיש קשר בין EQ ו IQ, ייתכן EQ גבוה בעוד ה IQ אינו טוב.

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

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

מדוע איכות משתלמת
אפשר למצוא חומר רב בנושא, לכן אקצר:

  • איכות חיצונית רעה מרחיקה לקוחות, מקשה על מכירה חוזרת לאותו לקוח (לרוב אלו מכירות מאוד משתלמות) ומעסיקה את ה support.
  • איכות פנימית – עד רמה מסויימת מקצרת את זמני הפיתוח, התחזוקה, time to market ועוד. כלומר סה\"כ היא משתלמת כלכלית.
  • איכות פנימית מעל רמה מסויימת כבר אינה חוסכת אלא עולה יותר, אבל מאפשרת גמישות פיתוחית רבה התומכת בהשגת איכות חיצונית גבוהה. עבור מוצרים מסוימים או פונקציות מסוימות איכות ברמה כזו היא לא כלכלית.

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

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

איכות תוכנה – היכן מתחילים? (1)

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

הקדמה

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

יום אחד נופל האסימון. לא שהיא חדשה, היא תמיד הייתה שם, אבל יש רגע שזה קורה. האיכות בק-ר-ש-י-ם.
  •     כמעט חצי מהזמן הפיתוח ברוטו הולך לתיקוני באגים, ותיקון באגים שנוצרו בזמן תיקון הבאגים.
  •     ישנם \"מקומות קדושים\" בקוד שבהם לא נוגעים, ואם ממש חייבים אז זה תוך כדי תפילה.
  •      \"אי אפשר\" או הערכת זמן פיתוח ארוכה בצורה מגוחכת הופכים לתשובה תדירה יותר ויותר לשאלה: \"כמה זמן יקח לפתח X?\".
אני אציין כאן שיש הבדל בין מערכות on-premise (שמתקינים אצל לקוח) ומערכות on-demand (שירות). מערכת האילוצים בפרוייקט on-demand מוביל לאיכות מובנה מוקדמת יותר. סיבה טובה להעדיף פיתוח on-demand, אפשר לומר.

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

[הסיפור יכול לתאר לפחות שתי חברות שהכרתי ואני מניח שבהתאמה כזו או אחרת יכול להתאים לחברה שלכם (בשלב מסוים בחייה)]

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

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


הנושא היה יכול להיסגר אלמלא מנהלי הקבוצות של הארגון עצרו, העלו מחסומים ושאלות: תוך כמה זמן נראה תוצאות? האם משתמש הקצה ירגיש בשיפור האיכות? – כי זה מה שמטריד אותנו כרגע. כמה זמן אתם הולכים להשקיע? … כ\"כ הרבה?? אולי אפשר לשפר את הארכיטקטורה הבעייתית בכזו השקעה – לטפל בבעיה מהשורש? מה זה הרי יעזור שיהיו tests ויהיה refactoring וכמה פונקציות יהיו כתובות יפה יותר?! אנחנו צריכים למכור!


עכשיו התחילה הדילמה האמיתית: לפתוח בצעד מסובך של הטמעת Unit-Tests בחברה עם תמיכה רופפת של ההנהלה? מהם סיכויי ההצלחה?

Seeing what\'s next


בראיה ביקורתית לאחור ניתן לזהות שתי נושאים לשיפור, מנקודה זו:

  • יעדי האיכות כפי ההוגדרו בפועל לא תאמו לצורכיהם של המנהלים.
  • איך נבחרו דווקא Unit Tests ככלי העבודה המעודף? האם זה הכלי היעיל והנכון לחברה? ליעדים? לאנשים? למצב?

הבהרה: אני באופו אישי אוהב מאוד unit-tests ומאמין, לאחר שעבדתי תקופה ב TDD, שזוהי אחת מההתפתחויות המרשימות בעולם התוכנה בשנים האחרונות. 
לאחר שראיתי את התנגדות המנהלים, ורק אז, התחלתי לשאול את עצמי שאלות: unit tests אינו כלי יעיל לשיפור (EQ (external Quality. מה כן? מה יכול לעבוד במסגרת הנתונה ולהתאים למפתחים ולמנהלים כדי כן לנצל את המומנטום ולשפר את האיכות אבל בצורה שתהיה פחות התנגדות?
בפוסטים הבאים ארצה להמשיך ולדבר על:

    • איכות פנימית (IQ) ואיכות חיצונית (EQ), מה ההבדל ולמה בעצם שווה לשלם עליהם? (חוץ מהעובדה החשובה שמתכנתים טובים ומקצועיים (כמונו) אוהבים אותם)
    • כלי העבודה – ברגע שהחלטנו שאיכות חשובה, אילו כלי עבודה מעשיים עומדים לרשותנו בביצוע העבודה?

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