הטעות הכי יקרה בפרויקט תוכנה היא הפער בין מה שהעסק ביקש למה שהמפתח הבין. בדרך כלל מגלים אותה כשרואים את המערכת בפעם הראשונה, אחרי שכבר נבנתה ושולם עליה.
אפשר לגלות אותה הרבה קודם, עם מסמך קצר שבעל העסק כותב בעצמו. אין בו שום דבר טכני. הוא מתאר מה צריך לקרות, במילים שאתם משתמשים בהן כל יום.
מה יש בו
1. מילון
שתי עמודות: מילה, ומה היא אומרת אצלכם. “עבודה”, “הצעה”, “לקוח”, “סגור”. זה נראה מיותר עד הרגע שמתברר שאצלכם “סגור” אומר שהלקוח שילם, ואצל המפתח זה אומר שהעבודה הסתיימה. כמעט בכל עסק יש לפחות מילה אחת כזאת.
2. תהליך אחד מההתחלה ועד הסוף
מה שיצא מהמיפוי, בשלבים ממוספרים, כולל העקיפות. אם שלב קורה בוואטסאפ, כתבו שהוא קורה בוואטסאפ. אם תתארו את הגרסה המסודרת, תקבלו מערכת שמתאימה לגרסה המסודרת, ואף אחד אצלכם לא עובד ככה.
3. החריגים
החלק שהכי משתלם לכתוב, ושהכי קל לדלג עליו. לכל שלב: מה קורה כשזה לא הולך כרגיל. ביטול, החזר כספי, לקוח שמשנה את ההזמנה באמצע, עבודה דחופה שנכנסת לפני כולם. חריג שמתגלה אחרי שהמסלול הרגיל כבר נבנה עולה פי כמה מחריג שהיה כתוב מההתחלה.
4. מי רואה ומי מאשר
התשובות מהחלק הקודם, כמו שהן.
5. איך תדעו שזה הצליח
משפט אחד, ועדיף עם מספר. “הצעת מחיר יוצאת תוך יום במקום שלושה.” “הדוח החודשי לוקח שעה במקום יום.” בלי משפט כזה אי אפשר לדעת בסוף אם הכסף הוצא טוב, וכל צד יגיד מה שנוח לו.
מה לא לכתוב בו
- שמות של תוכנות. ברגע שכתבתם “צריך את זה בתוכנה הזאת”, בחרתם פתרון לפני שמישהו בדק אם יש טוב יותר.
- ציורים של מסכים. מסך מצויר נראה כמו דרישה, ומי שבונה יבנה אותו כמו שהוא. במקום זה, כתבו מה האדם מול המסך צריך לדעת ולהחליט באותו רגע.
- “וגם יהיה נחמד אם...”. בקשה שלא עלתה מהמיפוי עולה כסף, ואין דרך לדעת מה היא תחזיר. רשמו אותה ברשימה נפרדת של “אחר כך”. רוב מה שבה יישאר שם.
כמה ארוך
לתהליך אחד, שלושה עד שישה עמודים. מסמך של ארבעים עמודים אף אחד לא קורא עד הסוף, גם לא מי שכתב אותו, והפרטים החשובים נבלעים בין השאר.
ואם עוד לא מיפיתם את התהליך, התחילו שם. כשהמיפוי מוכן, המסמך הזה נכתב בערב אחד.
בסדרה למפות את העסק
- איך למפות את מה שבאמת קורה בעסק
- איפה העבודה נתקעת, ואיך רואים את זה במספרים
- מי רואה מה: הרשאות הן החלטה עסקית
- מה בעצם מוסרים למפתח (אתם כאן)