למה מערכות שבונים עם AI
מתחילות מצוין ואז מסתבכות?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בשכבת העיצוב זה נראה כמעט תמיד אותו דבר:

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

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

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

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

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

מה שכן צריך להיות ידוע בכל רגע נתון הוא ארבעה דברים:

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

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

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

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

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

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

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

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

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

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

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

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