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