מתודולוגיית Audit מעשית

מתודולוגיית Audit מעשית — איך הופכים את הקריאה לעבודה#

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

מעבר ראשון: להבין, לא לתקן#

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

מעבר שני: בדיקות לפי שכבות#

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

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

מעבר שלישי: תכנון תיקון ובדיקת חזרה#

לכל פער הגדירו תיקון מינימלי שמטפל בסיבה ולא רק בסימפטום. תיקון הרשאה מחייב בדיקה חוזרת של הרשאות; תיקון prompt מחייב Eval רגרסיה; תיקון שמירה מחייב תרחיש התאוששות; תיקון של ספק חיצוני מחייב בדיקה של הגבלת זמן, עלויות ונסיגה. לאחר תיקון, תעדו ראיה חדשה. העובדה ש-PR מוזג או שסוכן כתב "Fixed" אינה ראיה שהתקלה נעלמה.

להגדיר מתי באמת סיימנו: DoD לעומת תנאי השקה#

לזה קוראים Definition of Done (DoD) — הגדרת השלמה. בהקשר המקובל ב־Scrum, זו הגדרה משותפת של אמות המידה לאיכות שתוספת למוצר חייבת לעמוד בהן כדי להיחשב גמורה. למשל: שינויים נבדקו, אינם פוגעים בהרשאות, נכללו בדיקות רגרסיה רלוונטיות, והמידע הנדרש לתפעול עודכן. DoD אינו הבטחה שכל המוצר מוכן לכל קהל ולכל שימוש.

Acceptance Criteria מתייחסים למה שנדרש מתרחיש או מפריט עבודה מסוים; DoD מתייחס לרף השלמות והאיכות המשותף; Release Criteria / Go–No-Go עוסקים בהחלטה אם לחשוף גרסה וקבוצת יכולות לקהל מוגדר בתנאי סיכון מסוימים. שחרור אחראי מחייב לא לבלבל ביניהם. למקור הראשוני — Scrum Guide.

ששת מסמכי התוצר שבאמת צריך#

1. הבטחת מוצר וגבולות שימוש — למי, עבור מה, ומה הוא לא מבצע.
2. מפת רכיבים וזרימת נתונים — גם פעולות צד שלישי וסמכויות.
3. מטריצת הרשאות ובעלות מידע — מי יכול לקרוא, לשנות ולפעול.
4. חבילת בדיקות ו-Evals — קלט, ציפייה, תוצאות והיסטוריית גרסאות.
5. רשימת סיכונים ותוכנית תיקונים — חומרה, עדיפות, אחראי, ראיות ותנאי סיום.
6. החלטת שחרור ונוהל הפעלה — תנאי Go, ניטור, תגובה, עצירה ושחזור.

לכל אחד מהתוצרים כדאי לקבוע בעל אחריות ותנאי קבלה, ולא רק סימון שקיים קובץ. רשימת בדיקה (Checklist) אינה תחליף לביצוע הבדיקה עצמה.

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