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