טעות ראשונה: לתאר את היעד ביחידות הלא נכונות
רוב הסבבים המבוזבזים בצ'אט הבנייה נובעים מכוונה לגובה הלא נכון, וזה קורה בשני כיוונים מנוגדים. חלק מהאנשים מבקשים פחות ממה שהם מתכוונים - "תשפר את העיצוב", "תעשה את זה יותר טוב", "זה לא מרגיש נכון". כל אחד מהם הוא אבחנה בלי מטרה, כך שהגרסה הבאה היא ניחוש: היא עשויה להכהות את הכותרת, להחליף את הגופן, לסדר מחדש את הניווט, ולא תדע מדוע עד שתתבונן בתוצאה ותנסה להבין מה קרה. אנשים אחרים מתקנים יותר מהנדרש ומבקשים יותר ממה שצריך - הם נוקבים בשם עוגיות סשן, או CSS grid, או רכיב skeleton לטעינה, כי הם יודעים קצת ורוצים לעזור. הכשל הזה שקט יותר אבל עולה לא פחות. ברגע שאתה מגדיר את אופן היישום, בדרך כלל הגדרת אותו לא נכון, ולכל הפחות צמצמת את מרחב הפתרונות לכל מה שאתה עצמך מכיר כבר - שזה, אלא אם אתה מפתח עובד בתחום, צר יותר ממה שהבנאי היה מנסה בעצמו. ואם הספרייה או התבנית שנקבת בה מתגלה כבחירה שגויה, זה הופך לבאג שאתה הכנסת, באג שהבנאי לא היה יוצר כשפועל מתוך התוצאה הרצויה.
התיקון נמצא בין שני מצבי הכשל הללו: תן שם לדבר שאתה מתבונן בו ולשינוי שאתה רוצה לראות, לא למנגנון שמייצר אותו. "מבקרים צריכים להיות מסוגלים להזמין בלי ליצור חשבון" עולה על פסקה שלמה על עוגיות סשן, כי מה שאתה באמת רוצה הוא שהחיכוך יתבטל, וכנראה יש שלוש דרכים להגיע לשם שלא חשבת עליהן. "טבלת התמחור מבלבלת" זה עדיין דליל מדי בפני עצמו - מבלבלת איך? - אבל "אנשים לא מבינים שהתוכנית השנתית חוסכת כסף, שים את ההנחה לצד המחיר במקום לקבור אותה באותיות הקטנות" נותן לבנאי משהו קונקרטי לפעול לפיו. אם אינך יודע איך התיקון צריך להיראות, זה גם בסדר - תגיד מה לא בסדר ותן לו להציע את הצורה. מה שלא עובד הוא חוסר שביעות רצון מעורפל בלי נקודת עיגון, כי זה הופך כל גרסה עוקבת למשחק ניחושים.
| במקום... | אמור... |
|---|---|
| "תשפר את זה" | "קשה לקרוא את טקסט ה-hero על גבי התמונה - תן לו ניגודיות" |
| "תקן את חווית המשחק" | "הקפיצה מרחפת זמן רב מדי; תעשה אותה יותר חדה" |
| "תוסיף אימות משתמשים איכשהו" | "השחקנים צריכים חשבונות כדי שהניקוד יישמר" |
| "תעשה את זה יותר מהיר" | "לדף הגלריה לוקח רגע לטעון תמונות - הצג מציין מקום במקום לבן ריק" |
| "הקטע הזה לא טוב" | "ההמלצות נראות כמו מחשבה שלאחר מעשה - תן להן את אותו משקל כמו לקטע התמחור" |
טעות שנייה: להגיב לתקציר של גרסה במקום להתבונן בה
הדרך השנייה שבה אנשים נתקלים היא לענות לתקציר הצ'אט של שינוי במקום לשינוי עצמו. מישהו קורא "הועבר לוח הזמנים לדף משלו והכהה את הכותרת", מגבש תמונה מנטלית, וכותב משוב מול התמונה הזו במקום מול האתר בפועל. רוב התלונות מהסוג של "זה פגע בזה באופן שגוי" מתגלות כ"לא פתחתי את התצוגה המקדימה" - התוצאה הייתה בסדר, או קרובה לבסדר, וההתנגדות הייתה בעצם נגד הנחה מסוימת. זה עולה בערך שלושים שניות ללחוץ ולהעיף מבט לפני הכתיבה, ודילוג על הצעד הזה הוא מקור הסבבים המספר אחד שלא היו צריכים להתקיים. אפילו כשסוקרים מהטלפון בפגישה, הסתכל על התצוגה המקדימה ראשית - משוב על תיאור של תיאור מגדיל שגיאות במהירות.
הטעות הקשורה היא איחוד בקשות לא קשורות זו לזו להודעה אחת ואיבוד היכולת לדעת מה גרם למה. אפשר בהחלט לצבור כמה בקשות ולקבל את כולן בגרסה חדשה אחת - בנייה שמתקנת את הכותרת, מעבירה את לוח הזמנים, ומדקדקת את ניווט הנייד במעבר אחד קלה יותר לבדיקה משלוש מהדורות (diffs) שונות, כי אתה שופט מצב אחד מלוכד של האתר ולא שלושה דלתאות מול מטרה נעה. הבעיה מתחילה כשהבקשות אינן קשורות. תאחד שיפוץ של דף לוח הזמנים עם שינוי צבע גלובלי, ואם משהו בתוצאה מרגיש לא נכון, באמת לא תוכל לדעת איזה שינוי גרם לזה - האם הדף היה קשה לקריאה בשל הפריסה החדשה, או בשל הפלטה החדשה? לפענח את זה עולה הודעת מעקב וסבב שלם נוסף רק כדי לבודד את המשתנה. השאר את "הכל בנוגע לדף לוח הזמנים" בהודעה אחת ו"כיוון הצבעים" בהודעה הבאה, אפילו שאין שום דבר שמונע ממך לאחד אותן; כל גרסה נשארת השוואה נקייה, ואתה יכול לבטל או לכוונן את הדבר היחיד שצריך תיקון במקום לוותר על גרסה טובה בכללותה רק בשל חלק אחד שהחמיץ.
טעות שלישית: להתייחס לכל גרסה כחד-פעמית
הטעות השלישית היא לשכוח שכרטיס גרסה אינו קבלה - הוא אובייקט עבודה - ולדלג על מה שהוא בעצם מציע. כל סבב שהושלם מייצר כרטיס עם תצוגה מקדימה חיה - מופע רץ ממשי, לא צילום מסך, כך שלחיצה על כפתור בתוכו עושה את מה שלחיצה עליו עושה בסביבת הפרודקשן. יש לשונית קוד לעיון בכל קובץ שהשתנה, וזה משנה אם אתה טכני מספיק כדי לבדוק דבר מסוים (האם הטופס הזה אכן שולח לנקודת הקצה הנכונה?) בלי לחכות לתשובת צ'אט שתאשר את זה. הורדה מעניקה לך את הקבצים הגולמיים. ותפריט הפעולות הוא המקום שבו גרסה חדלה להיות טיוטה: לפרסם אותה בסביבת חיה, לבנות מתקינים מקוריים אם זו אפליקציה, לשלוח אותה לחנות, לשמור את כל הדבר כתבנית לבניות עתידיות, או לפרוס אותה בעצמאות.
אנשים שמדלגים על כל זה מגלים את עצמם מנסים לזכור אם הכפתור היה כחול בגרסה הישנה במקום פשוט לפתוח את הגרסה הישנה ולהתבונן - כי תוצאת הלוואי של התייחסות לכרטיסים כחד-פעמיים היא בדיוק זו: הסתמכות על זיכרון לגבי משהו שנמצא עדיין במרחק לחיצה אחת. גרסה 4 לא מתארכבת או מוקפאת כשגרסה 7 מושקת. התצוגה המקדימה שלה עדיין רצה, לשונית הקוד שלה עדיין נגישה לעיון, תפריט הפעולות שלה עדיין עובד, לתמיד. השוואת שתי גרסאות אינה תרגיל של קריאת diff, זו פתיחת שתי תצוגות מקדימות זו לצד זו ולחיצה בתוכן. הכרטיס נושא גם את רשומת האימות של הבנייה - הבדיקה האוטומטית שמאשרת שהיא בפועל עובדת לפני שהיא מועברת אליך כגמורה - ממוקדת לגרסה הספציפית הזו, וזו עוד סיבה שלמה שהכרטיסים הישנים נשארים פעילים חשובה: אם גרסה 6 עברה אימות נקי וגרסה 7 לא, יש לך את שתיהן להשוות במקום הודעת צ'אט שאומרת "תיקנתי את זה" שעליך לקבל על אמונה.
אותו אינסטינקט - להתייחס לתהליך העבודה כמשהו שניתן לדלג עליו לעיון מרפרף במקום להשתמש בו - מתבטא גם בהתעלמות מהצעות המעקב שהצ'אט מציע אחרי כל בנייה. הן אינן מילוי גנרי; הן נשאבות מהבנייה עצמה, כך שהן נוטות לתפוס דברים שייתכן שתפספס במעבר שלך: מצב ריק שאף אחד לא עיצב, טופס שלא מאשר הגשה, דף שנראה טוב בדסקטופ וצפוף בנייד. אין חיוב לקחת אותן, אבל לעיין בהן בריפרוף לא עולה כלום, והן תחליף סביר למעבר בקרת איכות אם אין לך זמן ללחוץ בעצמך בכל דף.
