אפיון מערכת: מה זה, מה כולל מסמך אפיון ולמה הוא חוסך כסף

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

מה זה אפיון מערכת ולמה הוא מגיע לפני הצעת מחיר סופית

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

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

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

אפיון עסקי, אפיון UX ואפיון טכני

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

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

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

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

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

מה כולל מסמך אפיון: דוגמה מקוצרת

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

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

2. משתמשים והרשאות.

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

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

4. כללים. ביטול עד 3 שעות לפני התור. שירות של 45 דקות לא נכנס לחלון של 30 דקות. לקוח שלא הגיע פעמיים מסומן לבדיקה.

5. מסכים. רשימת המסכים לכל סוג משתמש, עם סקיצה לכל מסך.

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

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

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

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

לא צריך להגיע עם מסמך. צריך להגיע עם חומר גלם:

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

כמה זמן לוקח אפיון ואיך מתמחרים אותו

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

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

איך אפיון מוביל למחיר סגור וללוח זמנים אמין

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

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

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

טעויות באפיון שעולות כסף בהמשך

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

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