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

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

ואז מגיע המשפט: "את האפיון הכנתי עם AI".

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

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

AI יודע לכתוב אפיון. האם הוא יודע לקבל את ההחלטות שמאחוריו?

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

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

בקריאה ראשונה הכול נראה הגיוני.

עכשיו מתחילות השאלות האמיתיות.

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

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

______________

הבעיה היא דווקא כשהתוצאה נראית מצוין

אם AI היה מייצר מסמך גרוע, היה קל לזהות את הבעיה.

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

יש כותרות, טבלאות, דרישות פונקציונליות, מקרי קצה, Acceptance Criteria ומונחים מקצועיים.
אפשר אפילו לבקש מהמודל "לפעול כארכיטקט תוכנה בכיר" ולקבל המלצה על APIs, בסיס נתונים, Cloud ו-Microservices.

אבל מסמך מסודר אינו בהכרח מסמך נכון.

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

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

אפיון טוב נבנה משאלות, לא מתשובות

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

לקוח אומר: "צריך אפשרות לאשר הזמנה".

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

כמה שאלות נולדו ממשפט אחד.

וזה בדיוק ההבדל בין תיעוד דרישה לבין אפיון שלה.

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

הטעות יכולה להתגלות רק בפיתוח

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

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

עכשיו צריך לחזור לאפיון.

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

וזה כבר עולה כסף. והרבה יותר.
דמיינו שבניתם בניין ללא תוכנית הנדסית ואדריכלית מקצועית שבוצעה על ידי מהנדס שבאמת (!) מכיר את השטח.
מה תצטרכו לעשות וכמה תאלצו לשלם על מנת להרוס ולבנות מחדש את הטעויות של התכנית ההנדסית והאדריכלית?

מה עולה לכם יותר ? להשקיע בבניה עצמה או בתכנון הנדסי?
התשובה בוודאי ברורה לכם.

בפועל, העלות האמיתית של אפיון לא מדויק אינה מחיר כתיבת האפיון.
היא שעות הפיתוח שנזרקות, שינויי UX, בדיקות חוזרות, תיקוני Backend ודחייה של מועד העלייה לאוויר.

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

ומה לגבי מערכות מורכבות באמת?

ככל שהמערכת גדולה יותר, הסיכון גדל.

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

עכשיו חברו אליה מערכת ERP קיימת.

הוסיפו מערכת הזדהות ארגונית.

הוסיפו אפליקציה.

ועכשיו דרשו שהכול יעבוד גם תחת עומסים גבוהים.

אי אפשר לפתור פרויקט כזה באמצעות Prompt אחד מוצלח כעל שיהיה. אפילו לא באמצעות מאה Prompts.

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

זו הסיבה שאפיון של מערכת מורכבת הוא מקצוע ולא משימת כתיבה.

AI כן צריך להיות בחדר

מכאן קל להגיע למסקנה ההפוכה ולומר שלא כדאי להשתמש ב-AI באפיון.

זו תהיה טעות.

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

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

זה שימוש מצוין ב-AI.

ההבדל הוא מי מנהל את מי.

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

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

ומה קורה כשמכניסים AI לתוך המוצר עצמו?

כאן האפיון הופך מורכב אפילו יותר.

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

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

• מה מותר ל-AI לעשות לבד?
• מתי אדם חייב לאשר פעולה?
• מאילו מקורות מידע מותר לו לענות?
• מה עושים כאשר רמת הביטחון נמוכה?
• מה נרשם לצורכי בקרה?
• מה קורה כשהמודל פשוט טועה?
• ועוד…

בפרויקטים כאלה החיבור בין אנשי מוצר, UX, ארכיטקטורה ו-AI Engineering הופך קריטי.

כאן גם נכנסת גישת FDE – Forward Deployed AI Engineer.
במקום לפתח פתרון AI במנותק מהארגון, אנשי הטכנולוגיה עובדים קרוב לתהליך העסקי, למשתמשים ולמערכות הקיימות.

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

מסמך של 80 עמודים לא בהכרח טוב יותר ממסמך של 30

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

בעבר היה יקר לייצר הרבה טקסט. היום כמעט אין מגבלה.
אפשר לקבל בתוך דקות עשרות דרישות, מאות Acceptance Criteria ורשימה מרשימה של Edge Cases.

כמות כבר אינה מדד לאיכות.

לפעמים ההפך נכון.

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

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

איך נכון להשתמש ב-AI בתהליך האפיון?

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

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

לאחר מכן אפשר להשתמש ב-AI כדי להאיץ חלקים מהעבודה.

ואז חוזרים לאנשים.

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

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

אז האם כדאי לבצע אפיון טכנולוגי באמצעות בינה מלאכותית?

כן, אבל השאלה הנכונה היא לא האם להשתמש ב-AI.

השאלה היא באיזה תפקיד.

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

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

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

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

ובאפיון טוב, השאלות האלה הן לעיתים החלק החשוב ביותר.

 

Case Study
Qlick Store:

כשהאפיון נראה שלם, אבל המערכת לא באמת תוכננה

הרעיון

Qlick Store תוכננה כמערכת Marketplace המחברת בין מספר חנויות נוחות (׳פיצוציות׳) לבין לקוחות המעוניינים להזמין מוצרים הביתה.

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

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

בפועל, מאחורי המודל הזה מסתתרת מערכת מורכבת הרבה יותר.

כשהפרויקט התחיל מאפיון שנוצר באמצעות AI

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

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

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

וזה הבדל קריטי.

מי בעצם מוכר למי?

אחת הסוגיות המרכזיות שלא קיבלה מענה מספק הייתה מערכת היחסים בין שלושה גורמים שונים: הלקוח, החנות והיזם שמפעיל את Qlick Store.

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

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

סליקה וחלוקת הכנסות

ב-Marketplace, סליקת אשראי אינה בהכרח תהליך רגיל של "לקוח משלם ובית העסק מקבל את הכסף".

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

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

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

סנכרון בין מספר חנויות עצמאיות

אתגר נוסף היה ניהול המידע המגיע ממספר ספקים וחנויות.

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

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

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

ומה קורה כשהחנות לא יכולה לקבל את ההזמנה?

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

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

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

מערכת מבוססת מיקום מוסיפה שכבה נוספת

המיקום אינו רק Feature באפליקציה.
הוא משפיע על הלוגיקה העסקית.

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

אפיון שמתייחס רק להרשאת GPS ולמסך מפה מפספס את רוב הבעיה.

הבעיה התגלתה מאוחר מדי

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

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

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

ההחלטה – לעצור ולאפיין מחדש

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

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

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

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

המחיר האמיתי של אפיון חסר

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

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

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

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

וזו אולי התובנה החשובה ביותר מהפרויקט: AI יכול להיות כלי מצוין בתוך תהליך האפיון.
הוא לא צריך להיות תחליף לתהליך האפיון עצמו.