אפיון מערכות מידע

רשימת דרישות מול אפיון

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

הבדיקה שעולה שעה

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

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

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

תהליך לפני מערכת

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

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

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

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

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

אפיון של מערכת AI: שני סעיפים נוספים

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

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

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

כמה זמן, ומה סימני האזהרה

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

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

איך אני עובד על זה

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

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