איך מאפיינים פרויקט תוכנה צעד אחר צעד

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

מתחילים בבעיה, לא ברשימת מסכים

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

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

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

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

מזהים משתמשים ומגדירים מה כל אחד צריך

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

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

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

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

מתארים את התהליך, כולל מה שמשתבש

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

1. כתבו מהו האירוע שמתחיל את התהליך.
2. רשמו את הפעולות לפי הסדר, ואת האדם שאחראי לכל אחת.
3. ציינו איזה מידע נדרש כדי להתקדם לשלב הבא.
4. הגדירו כיצד יודעים שהתהליך הושלם.
5. הוסיפו מצבים שבהם התהליך נעצר, משתנה או חוזר לשלב קודם.

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

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

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

מגדירים מידע, מסכים וחיבורים

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

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

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

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

מחליטים מה נבנה קודם ואיך בודקים שסיימתם

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

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

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

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

הצעד הבא הוא לבחור תהליך אחד בעסק ולכתוב עבורו מטרה, משתמשים, שלבים ומקרים חריגים. אם אתם שוקלים מערכת לעסק, תוכלו לקרוא על מערכות מותאמות; ספרו לרבוזה על הפרויקט בצור קשר או בוואטסאפ 051-544-9553.