איך כותבים אפיון שמפתחים באמת מבינים

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

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

התחילו מהבעיה, לא מהפתרון

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

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

תארו התנהגות, לא מסכים

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

לכל פעולה מרכזית כדאי לכתוב ארבע שורות:

• מה המשתמש עושה ומה הוא רואה בתגובה.
• מה המערכת שומרת, איפה ומתי.
• מה קורה כשהפעולה נכשלת, ומה המשתמש רואה.
• מי מורשה לבצע אותה ומי לא.

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

קריטריוני קבלה שאפשר לבדוק

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

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

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

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

כתבו במפורש מה לא נכלל

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

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

דוגמה קטנה: אותה דרישה, לפני ואחרי

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

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

טעויות שחוזרות באפיונים

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

מה לשים באפיון ומה להשאיר בחוץ

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

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

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

הבדיקה לפני שמוסרים

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

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

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

אפיון הוא מסמך חי

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

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

השורה התחתונה

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

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