מוצר
להבין את המערכת: מה רואים בדמו ומה מוסתר
ארבע שאלות לכל פעולה ומפת תלות, כדי לדעת מה באמת קורה מאחורי המסך.
תוכן העניינים
להבין את המערכת: מה רואים בדמו ומה מוסתר מאחורי המסך?#
מסך שנראה שלם אינו מעיד על שלמות המערכת. באפליקציה טיפוסית יש כמה שכבות, שכל אחת יכולה להיכשל בנפרד:
ממשק משתמש → אימות זהות → שירותי אפליקציה וכללים עסקיים → שירות מודל/כלים חיצוניים → מסד נתונים ואחסון → ניטור ותהליכי הפעלה. זה אינו מבנה מחייב לכל מוצר, אלא מפת חשיבה. לפעמים רכיב חסר בכוונה. העיקר הוא לדעת אילו תפקידים קיימים והיכן מתבצעת האחריות.
ארבע שאלות לכל פעולה#
מי יוזם? אדם מחובר, אורח, משימה מתוזמנת, תהליך רקע או סוכן? זהות המשתמש אינה בהכרח זהות התהליך שמבצע את הפעולה.
מי מחליט? האם המודל רק מציע טקסט? האם הקוד מאמת אותו? האם יש בדיקת הרשאה והאם אדם חייב לאשר שליחה או מחיקה? הפרדה זו קריטית: גם כשהמודל "מבקש לבצע", הוא לא צריך לקבל אוטומטית סמכות לבצע.
איפה הנתונים חיים? בדפדפן, במסד נתונים, בשירות חיצוני, בקובץ, בקאש, בהיסטוריית שיחה? מידע הנמצא בזיכרון של רכיב UI יכול להיעלם ברענון. מידע שנשלח למודל אינו הופך מעצמו לרשומה קבועה. מסד נתונים פעיל אינו מבטיח שהמידע ניתן לשחזור.
איך נדע מה קרה? האם נשמרת הצלחה או כישלון? האם אפשר לשייך אירוע לבקשה ולמשתמש בלי לרשום תוכן רגיש? האם ניתן לאתר שינוי בנתון, מי ביצע אותו ומה הייתה גרסת המערכת?
מפת תלות ולא רק תרשים מסכים#
הכינו מפת רכיבים שבה לכל שירות מצוין: התפקיד, הנתונים הנקלטים, הנתונים הנפלטים, הרשאות הגישה, מיקום הסודות, ספק חיצוני אם יש, תרחיש כשל ודרך התאוששות. שרשרת ארוכה של ספקים יכולה ליצור נקודת כשל שלא נראית בשום מסך. לא כל תלות חייבת גיבוי מלא; חייבים לדעת מה יקרה כשהיא אינה זמינה.
לזה קוראים מיפוי תלויות (Dependency Mapping): להבין לא רק אילו רכיבים קיימים, אלא גם איזה רכיב תלוי באחר, איזו הרשאה דרושה ומה תהיה השפעת נפילה של תלות יחידה. אין הכרח להשתמש בכלי שרטוט מיוחד; מפת תלויות קריאה ומעודכנת מספיקה בתחילת הדרך.
ראיה מספקת בשלב הזה: אפשר לקחת כל פעולה חשובה ולתאר את מסלול הבקשה מרגע הלחיצה ועד שהתוצאה נשמרת או נשלחת, כולל מי מוסמך לבצע כל שלב. אם התשובה היא "ה-AI מטפל בזה", מיפוי המערכת עדיין לא הושלם.