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

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

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

מאת ענת גרניט

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

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

הבנייה עצמה הופכת לכלי חשיבה

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

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

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

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

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

מתי טשטוש הגבולות בין תפקידים עלול ליצור בעיות?

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

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

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

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

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

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

יכולת משותפת ≠ מומחיות זהה

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

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

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

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

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

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

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

לעצור בלי ליצור חיכוכים

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

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

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

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

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

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