פיתוח מוצר תוכנה לארגונים: מה חייבים להוכיח בגרסה הראשונה?

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

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

התחילו מהמשימה שהלקוח צריך לסיים

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

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

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

דמו יפה וגרסה לשימוש בודקים דברים שונים

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

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

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

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

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

הוכחה שנייה: כל משתמש פועל בתוך גבולות ברורים

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

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

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

הוכחה שלישית: שינוי מצב משאיר מערכת עקבית

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

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

הוכחה רביעית: מודדים השלמת משימה, ולא רק כניסות

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

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

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

הוכחה חמישית: יודעים להפעיל ולתמוך בגרסה

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

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

דף החלטות קצר לשיחת האפיון

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

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

למי PWM מתאימה לפיתוח הגרסה הראשונה?

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

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

שאלות נפוצות על גרסה ראשונה למוצר תוכנה

האם צריך אפליקציה נפרדת לנייד כבר בגרסה הראשונה?

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

האם אפשר לדחות הרשאות עד שיהיו יותר לקוחות?

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

מה כדאי להביא ל-PWM לפני שמבקשים הצעת פיתוח?

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