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

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

שלוש שאלות שחייבות תשובה בכתב

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

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

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

מסמך של עמוד אחד

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

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