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