פיתוח אפליקציה לעסק: מה להכין לפני שמתחילים

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

הגדירו את הבעיה ואת המשתמשים

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

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

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

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

בדקו איך ומתי ישתמשו בה

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

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

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

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

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

הכינו חומר לפגישת האפיון

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

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

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

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

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

בחרו מה נכנס לגרסה הראשונה

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

מיינו את הבקשות לפי סדר:

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

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

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

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

תכננו בדיקות ואחריות להמשך

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

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

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

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

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

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