איך כותבים אפיון למערכת: מדריך לבעלי עסקים
ספק ביקש מכם "אפיון" ולא ברור מה בדיוק הוא רוצה. זה מסמך פשוט יותר ממה שזה נשמע, ורק אתם יכולים לכתוב את הגרסה הראשונה שלו. הנה מה צריך להיות בו, וכמה מפורט.
אפיון הוא המסמך שמתאר מה המערכת צריכה לעשות, עבור מי ובאילו תנאים - לפני שנכתבת שורת קוד אחת. הוא לא עיצוב, לא תוכנית טכנית ולא חוזה, אלא התיאור המשותף שממנו נגזרים שלושתם. במדריך הזה נעבור על מה אפיון כולל, כמה מפורט הוא צריך להיות, איפה בעלי עסקים נוטים להיתקע, ואיך המסמך הזה הופך אצל המפתח להצעת מחיר. בסוף יש רשימת מילוי שאפשר לעבור עליה לפני הפגישה הראשונה.
מה זה אפיון, ומה הוא לא
כשספק תוכנה מבקש מכם "אפיון", הוא בדרך כלל מבקש דבר פשוט יותר ממה שזה נשמע: תיאור מסודר של הבעיה ושל הפתרון הרצוי, במילים שלכם. מי משתמש במערכת, מה כל אחד עושה בה, איזה מידע היא מחזיקה, ולמה מה שיש היום לא מספיק. זה המסמך שמאפשר לשני הצדדים לדבר על אותו דבר.
בלי אפיון, הצעת המחיר נכתבת על סמך שיחת טלפון ותחושת בטן, ולרוב מתגלה באמצע הפרויקט שהצדדים דמיינו מערכות שונות. זה לא נובע מרשלנות של מישהו. פשוט אין דרך לתמחר מה שלא הוגדר.
מה אפיון לא
אפיון הוא לא מסמך עיצוב. הוא לא צריך לקבוע צבעים, פונטים או איך ייראה הכפתור. הוא גם לא מסמך טכני: אתם לא צריכים לבחור שפת תכנות, מסד נתונים או ספק אחסון. את שני אלה המפתח גוזר מהאפיון, לא להפך.
והוא לא חוזה. אפיון טוב משאיר מקום לשינויים, כי חלק מהדרישות מתבררות רק כשרואים גרסה ראשונה עובדת. מה שהוא כן קובע הוא את ההיקף - מה בפנים ומה בחוץ - וזה מה שמאפשר לתמחר אותו.
כמה מונחים שתפגשו בדרך
- דרישה פונקציונלית - מה המערכת עושה. למשל: "מנהל יכול לייצא את רשימת הלקוחות לאקסל".
- דרישה לא-פונקציונלית - איך היא עושה את זה: מהירות, אבטחה, זמינות, נגישות.
- ישות (Entity) - סוג מידע שהמערכת מחזיקה: לקוח, הזמנה, משימה. לכל ישות יש שדות.
- תפקיד (Role) - קבוצת משתמשים עם אותן הרשאות: מנהל, נציג שירות, לקוח.
- אינטגרציה - חיבור למערכת חיצונית דרך ממשק תכנות (API), למשל למערכת החשבוניות.
- גרסה ראשונה (MVP) - המינימום שמאפשר להתחיל לעבוד עם המערכת, לפני כל השאר.
מי צריך לכתוב אותו
את הגרסה הראשונה - אתם. לא כי זה תפקידכם לכתוב מסמכי תוכנה, אלא כי רק אתם יודעים איך העסק עובד בפועל, איפה נשרף זמן ומה באמת מפריע. המפתח יכול לשאול שאלות טובות, אבל הוא לא יכול לנחש שבסוף כל חודש מישהי מעתיקה ידנית שלושים שורות מאקסל לתוכנת הנהלת החשבונות.
בשלב השני, ספק רציני ייקח את מה שכתבתם, ישאל עליו שאלות ויתרגם אותו לאפיון טכני. ככה אנחנו עובדים ב-VOOPS בפרויקטים של מערכות ניהול לעסק: המסמך שלכם הוא נקודת המוצא לשיחת האפיון, לא תוצר סופי. אם ספק דורש מכם אפיון מוכן ומפורט לפני שהוא מוכן לדבר איתכם בכלל - זה סימן שאלה.
תבנית אפיון מעשית: מה צריך להיות במסמך
אין תבנית אחת נכונה, אבל תשעת הסעיפים הבאים מכסים את מה שכל מפתח יצטרך לדעת כדי לתמחר. כתבו אותם בסדר הזה, בשפה רגילה, בלי לנסות להישמע טכניים. משפט ברור עדיף על טבלה מרשימה.
1. מטרות - למה בונים את זה
שניים או שלושה משפטים על הבעיה שהמערכת פותרת, ועל איך תדעו שהיא הצליחה. "להפסיק לאבד לידים שמגיעים בוואטספ" הוא יעד שאפשר לבנות סביבו. "לשפר את היעילות" - לא. אם יש מספר שאתם רוצים לשנות, כמו זמן הטיפול בפנייה או כמות הטעויות בהזמנות, כתבו אותו.
2. משתמשים ותפקידים
מי ייכנס למערכת, וכמה כאלה יש. פרטו לפי תפקיד: מנהל, נציג, איש שטח, לקוח קצה. לכל תפקיד כתבו במשפט מה הוא צריך להשיג במערכת ומאיפה הוא ייכנס אליה - משרד, נייד בשטח, לפעמים בלי קליטה. הפרט האחרון משנה את המבנה של המערכת יותר ממה שנדמה.
3. התהליך כפי שהוא היום
זה הסעיף שהכי חשוב והכי מזניחים. תארו את התהליך הקיים צעד אחר צעד, כולל האקסלים, קבוצות הוואטספ והפתקים. איפה מידע נכנס, מי מעביר אותו למי, ואיפה הוא הולך לאיבוד. אל תתארו את התהליך הרצוי - את זה נעשה יחד. תארו את מה שקורה בפועל, כולל החלקים הפחות מחמיאים.
4. מסכים ומודולים
רשימה של החלקים העיקריים במערכת, כפי שאתם רואים אותם: מסך לקוחות, מסך הזמנות, לוח בקרה, הגדרות. לכל אחד - מה רואים בו ומה אפשר לעשות ממנו. לא צריך לצייר. אם בכל זאת קל לכם לשרבט על דף ולצלם, זה עוזר. על עיצוב הממשק עצמו מדברים אחרי שההיקף סגור.
5. נתונים
איזה מידע המערכת מחזיקה, ומה יש בכל פריט. לקוח: שם, טלפון, עיר, מקור הגעה, סטטוס. הזמנה: לקוח, מוצרים, סכום, תאריך אספקה. ציינו גם מה קיים היום שצריך לעבור למערכת החדשה - היסטוריה של שנים באקסל היא לא אותו דבר כמו להתחיל מאפס.
6. אינטגרציות
כל מערכת חיצונית שהמערכת החדשה צריכה לדבר איתה: חשבוניות, סליקה, וואטספ, יומן גוגל, מערכת דיוור. לכל אחת כתבו מה צריך לעבור ולאיזה כיוון: "כל הזמנה שנסגרת מפיקה חשבונית", "כל ליד חדש נשלח כהודעת וואטספ למנהל". אם לא ברור לכם אם למערכת מסוימת יש ממשק פתוח, כתבו את שמה ואת זה נברר. הסברנו מה זה API ולמה זה משנה לעסק במאמר נפרד, ואת הצד המעשי של החיבורים אפשר לראות בעמוד API ואינטגרציות.
7. הרשאות
מי רואה מה ומי יכול לשנות מה. נציג רואה רק את הלקוחות שלו או את כולם? מי מוחק? מי מאשר הנחה? זה סעיף קצר לכתיבה ויקר לתיקון בדיעבד, כי הרשאות מחלחלות לכל מסך במערכת.
8. דוחות
אילו שאלות אתם רוצים שהמערכת תענה עליהן בלחיצה: כמה לידים נכנסו החודש לפי מקור, אילו הזמנות מתעכבות, מה ההכנסה לפי לקוח. דוח שלא הוגדר באפיון הוא לרוב הבקשה הראשונה אחרי העלייה לאוויר, אז עדיף להגדיר לפחות את שלושת החשובים.
9. דרישות לא-פונקציונליות
כאן נכנסים הדברים שלא רואים, אבל משלמים עליהם כשהם חסרים. אבטחת מידע: מה רגיש במידע שלכם, והאם חלות עליכם דרישות מתקנות הגנת הפרטיות. גיבויים: כל כמה זמן, ולכמה זמן אחורה צריך להיות אפשר לחזור. נגישות: אם המערכת פונה ללקוחות, בישראל זו דרישת חוק לפי תקן ישראלי 5568. זמינות: מה קורה אם המערכת נופלת לשעה ביום רביעי בצהריים. אם אתם לא יודעים מה לדרוש, ריכזנו עשר דרישות אבטחה שכדאי להציב לכל מפתח.
דוגמה: אפיון למערכת לידים של חברת שירות
נניח חברה שמספקת שירותי התקנה, עם שלושה נציגי מכירות ושני מתקינים. לידים מגיעים מטופס באתר, משיחות טלפון ומקמפיין בפייסבוק, ונרשמים היום בגיליון אקסל משותף. פעם בשבוע מישהו עובר על הגיליון ומחפש לידים שלא חזרו אליהם. חלקם כבר סגרו עם מתחרה.
אפיון של עמוד אחד לעסק כזה נראה בערך כך. מטרה: כל ליד מקבל חזרה תוך יום עבודה, ואפשר לראות בכל רגע כמה לידים פתוחים יש לכל נציג. משתמשים: מנהלת (אחת), נציגים (שלושה, בעיקר מהנייד), מתקינים (שניים, צפייה בלבד בלוח ההתקנות). התהליך היום: הטופס באתר שולח מייל, מישהו מעתיק אותו לאקסל, מסמן נציג, והנציג מעדכן סטטוס כשהוא זוכר.
מסכים: רשימת לידים עם סינון לפי סטטוס ונציג, כרטיס ליד עם היסטוריית שיחות, לוח בקרה למנהלת, יומן התקנות. נתונים: ליד (שם, טלפון, עיר, מקור, סטטוס, נציג אחראי, תאריך פנייה, הערות), התקנה (ליד, מתקין, תאריך, סטטוס). אינטגרציות: טופס האתר נכנס ישירות למערכת, ליד חדש שולח הודעת וואטספ לנציג, פנייה מפייסבוק נכנסת אוטומטית. הרשאות: נציג רואה את הלידים שלו בלבד, מנהלת רואה הכל ומעבירה לידים בין נציגים. דוחות: לידים לפי מקור בחודש, זמן תגובה ממוצע לנציג, אחוז סגירה. לא-פונקציונלי: גיבוי יומי, כניסה עם סיסמה ונעילה אחרי כמה ניסיונות כושלים, עבודה נוחה מהנייד.
זה כל מה שצריך כדי שמפתח יוכל לתת הצעת מחיר אחראית. שימו לב שאין כאן מילה על טכנולוגיה. מערכת דומה במבנה שלה בנינו עבור GLOBAL JOBS, חברת כוח אדם לעובדים זרים: אתר לידים יחד עם מערכת ניהול שמפלחת לידים לפי ענף, מקור וסטטוס, מייצאת לאקסל ומאפשרת לערוך את תוכן האתר מהדפדפן. בודק זכאות באתר מסנן פניות לא רלוונטיות עוד לפני שהן הופכות לליד - דרישה שנולדה בדיוק מתיאור כנה של התהליך הקיים.
כמה מפורט זה צריך להיות
יותר מדי פירוט מזיק כמעט כמו מעט מדי. אפיון של ארבעים עמודים שנכתב לפני שראיתם מסך אחד עובד יכלול הרבה דרישות שתשנו ברגע שתראו אותן. הכלל שעובד לנו: מספיק מפורט כדי שאפשר לתמחר, ולא יותר. ברוב המערכות לעסק קטן או בינוני זה בין שניים לשישה עמודים.
| רמת פירוט | מה יש בה | מה המפתח יכול לתת | מתאים ל |
|---|---|---|---|
| שיחה או מייל של פסקה | הבעיה במשפט, בלי משתמשים ובלי תהליך | טווח רחב מאוד, לרוב פי שניים או שלושה בין הקצה התחתון לעליון | שיחת היכרות ראשונה |
| אפיון עסקי (2-6 עמודים) | תשעת הסעיפים שלמעלה, בשפה רגילה | הצעת מחיר עם היקף מוגדר, אבני דרך ורשימת מה לא נכלל | רוב המערכות לעסק |
| אפיון טכני מפורט (עשרות עמודים) | מסכים מפורטים, מודל נתונים, תרשימי זרימה, מקרי קצה | מחיר קבוע ולוח זמנים מחייב | מכרזים, מערכות תחת רגולציה, פרויקטים גדולים |
את הרמה השלישית בדרך כלל כותב המפתח, לא אתם, וברוב הפרויקטים היא נכתבת בהדרגה - סעיף לכל גרסה - ולא כמסמך אחד גדול מראש. אם ספק דורש מכם להגיע איתה מוכנה, סבירות גבוהה שהוא מתמחר לפי מסמך ולא לפי הבנה של העסק.
מתי לא כדאי לכתוב אפיון מפורט
יש שלושה מקרים שבהם השקעה באפיון היא בזבוז. הראשון: כשתוכנה קיימת פותרת את רוב הבעיה. אם מערכת ניהול לקוחות מדף מכסה 80% ממה שכתבתם בסעיף המסכים - קנו אותה, וכתבו אפיון רק לחלק שנשאר. השווינו את השיקולים במאמר על פיתוח בהתאמה אישית מול תוכנה מדף.
השני: כשאתם עדיין לא יודעים אם יש ביקוש. מוצר חדש לשוק לא צריך אפיון של המערכת המלאה, אלא הגדרה צרה של גרסה ראשונה שבודקת את ההנחה המרכזית. השלישי: כשהצורך קטן וברור - טופס שמתחבר לוואטספ, דף נחיתה, אוטומציה של פעולה אחת. שם פסקה אחת ושיחה קצרה עושות את העבודה, ומסמך רק יעכב.
שש טעויות שחוזרות באפיונים
לתאר את הפתרון במקום את הבעיה
"צריך כפתור שמייצא לאקסל" הוא פתרון. הבעיה מאחוריו היא כנראה "רואת החשבון צריכה את נתוני החודש", ולבעיה הזו יש לפעמים פתרון טוב יותר - שליחה אוטומטית, או חיבור ישיר לתוכנת הנהלת החשבונות. כתבו את הבעיה, ותנו למפתח להציע.
לתאר את התהליך האידיאלי במקום את הקיים
בעלי עסקים נוטים לכתוב איך התהליך אמור לעבוד, לא איך הוא עובד. אבל המערכת צריכה להתמודד עם המציאות: הלקוח שמתקשר במקום למלא טופס, ההזמנה שמשתנה אחרי שנסגרה, המתקין שמדווח בסוף היום ולא בזמן אמת. תהליך שלא תואר - לא יטופל.
לשכוח את מקרי הקצה
מה קורה כשלקוח מבטל? כשמוצר נגמר במלאי באמצע הזמנה? כשעובד עוזב ויש לו שלושים לידים פתוחים? מקרי הקצה הם לרוב חלק ניכר מזמן הפיתוח, ובאפיונים הם כמעט תמיד חסרים. לא צריך לכסות את כולם. צריך לכתוב את אלה שקורים לכם בפועל אחת לחודש.
לדלג על ההרשאות
"כולם רואים הכל" נשמע פשוט בהתחלה. זה מפסיק להיות פשוט ברגע שיש עובד חדש בתקופת ניסיון, ספק חיצוני שצריך גישה חלקית, או לקוח שרוצה לראות את הסטטוס שלו. הרשאות שנוספות בדיעבד עולות בדרך כלל הרבה יותר מהרשאות שתוכננו מההתחלה.
להתעלם מהמידע הקיים
ההיסטוריה שלכם - לקוחות, הזמנות, מסמכים - נמצאת איפשהו, ולרוב היא לא מסודרת. הסבת נתונים (Data migration) היא סעיף עבודה בפני עצמו, ומי שלא כתב אותו באפיון יגלה אותו כתוספת להצעה.
לכתוב "כמו במערכת X" בלי להסביר
"שיהיה כמו במערכת שראיתי אצל המתחרה" לא אומר למפתח כלום, כי המערכת ההיא עושה הרבה דברים. אם יש מערכת שאתם אוהבים, כתבו מה בדיוק בה: איזה מסך, איזו פעולה, למה זה עובד לכם. זה מידע מועיל. הפניה כללית - לא.
איך האפיון הופך להצעת מחיר
כשמסמך כזה מגיע אלינו, השלב הראשון הוא שיחת אפיון: עוברים על הסעיפים, שואלים על מה שחסר, ומזהים איפה יש דרישה שנשמעת קטנה ובפועל יקרה - למשל "התראה בזמן אמת" או "עבודה בלי אינטרנט". אחרי השיחה מפרקים את המערכת למודולים, ולכל מודול מוערך זמן פיתוח ובדיקות.
מהפירוק הזה נולדת ההצעה, ובה שני דברים שאפשר לדרוש מכל ספק. ראשון: חלוקה לגרסאות, כך שהגרסה הראשונה כוללת את מה שהכרחי כדי להתחיל לעבוד, והשאר מגיע אחרי שהמערכת כבר בשימוש. שני: רשימה מפורשת של מה לא נכלל. הסעיף השני חשוב יותר מהראשון, כי כמעט כל מחלוקת בפרויקט תוכנה מתחילה בדרישה שאף אחד לא כתב שהיא בחוץ.
מה משנה את המחיר יותר מכל? בדרך כלל לא כמות המסכים, אלא כמות האינטגרציות, מורכבות ההרשאות והצורך בהסבת נתונים. שני עסקים עם אותה רשימת מסכים יכולים לקבל הצעות שונות מאוד בגלל שלושת אלה. פירטנו את מרכיבי המחיר במדריך כמה עולה לפתח מערכת בישראל, ועל התהליך המלא מהאפיון ועד ההטמעה אפשר לקרוא בעמוד פיתוח תוכנה בהתאמה אישית.
אפיון הוא לא התחייבות שלכם לא לשנות דעה. הוא ההסכמה על מה מתמחרים עכשיו. שינויים אחרי ההצעה הם לגיטימיים וצפויים - הם רק צריכים לעבור דרך אותו מסמך, כדי שגם המחיר וגם לוח הזמנים יתעדכנו יחד איתם.
רשימת מילוי לפני הפגישה עם המפתח
עברו על הרשימה וכתבו תשובה קצרה לכל שורה. מה שאין לכם תשובה עליו - כתבו "לא יודעים". גם זו תשובה שימושית, כי היא אומרת למפתח איפה לשאול.
- מה הבעיה במשפט אחד, ואיך נדע שהיא נפתרה?
- מי המשתמשים, כמה מכל תפקיד, ומאיפה הם עובדים - משרד, נייד, שטח?
- איך התהליך עובד היום, צעד אחר צעד, כולל הכלים הלא רשמיים?
- איפה בתהליך נשרף זמן או הולך לאיבוד מידע?
- מה המסכים או המודולים העיקריים, ומה עושים בכל אחד?
- אילו סוגי מידע המערכת מחזיקה, ומה השדות של כל אחד?
- איזה מידע קיים היום צריך לעבור למערכת החדשה, ובאיזה פורמט הוא נמצא?
- לאילו מערכות חיצוניות צריך להתחבר, ומה עובר לכל כיוון?
- מי רואה מה, מי משנה מה, ומי מוחק?
- אילו שלושה דוחות תרצו לראות בלחיצה?
- איזה מידע רגיש יש במערכת, ומה קורה אם הוא דולף?
- כל כמה זמן צריך גיבוי, וכמה זמן אחורה צריך להיות אפשר לחזור?
- המערכת פונה ללקוחות? אם כן, נגישות היא דרישה ולא תוספת.
- מה חייב להיות בגרסה הראשונה, ומה יכול לחכות?
- מה בפירוש לא נכלל בפרויקט הזה?
- מה התקציב ומסגרת הזמן שאתם עובדים בתוכם?
שני הסעיפים האחרונים גורמים לחלק מבעלי העסקים אי-נוחות, אבל הם חוסכים זמן לכולם. ספק שמכיר את המסגרת יכול להציע מה נכנס אליה, במקום להגיש הצעה שתידחה בלי הסבר.
שורה תחתונה
אפיון טוב הוא לא מסמך טכני ולא מסמך ארוך. הוא תיאור כנה של איך העסק עובד היום, מי צריך מה מהמערכת, ומה חייב לקרות בגרסה הראשונה. את זה רק אתם יכולים לכתוב. כל השאר - טכנולוגיה, עיצוב, פירוק למודולים - זו העבודה של המפתח.
אם כתבתם תשובות לרשימה שלמעלה, יש לכם כבר בסיס טוב לשיחה. דברו איתנו - שיחת האפיון הראשונה היא ללא עלות, ובמקרים לא מעטים היא מסתיימת בהמלצה על פתרון קטן יותר ממה שחשבתם שצריך.
שאלות נפוצות
כמה זמן לוקח לכתוב אפיון?
הגרסה הראשונה שאתם כותבים דורשת כמה שעות עבודה מרוכזות, בדרך כלל אחר צהריים אחד. שיחת האפיון עם המפתח נמשכת לרוב שעה עד שעתיים, ואפיון טכני מפורט למערכת בינונית לוקח לספק בין כמה ימים לשבועיים. הזמן הזה חוזר פי כמה בפיתוח, כי דרישה שמתבררת תוך כדי כתיבת הקוד יקרה יותר מדרישה שנכתבה מראש.
האם צריך לשלם על האפיון?
תלוי ברמה. שיחת אפיון ראשונית היא בדרך כלל ללא עלות, כי היא משרתת גם את הספק. אפיון טכני מפורט הוא עבודה של ממש, ובפרויקטים גדולים מקובל לתמחר אותו כשלב נפרד, כך שאתם מקבלים מסמך שאפשר להגיש איתו גם לספקים אחרים. בפרויקטים קטנים ובינוניים הוא לרוב נכלל במחיר הפרויקט.
מה אם אני לא יודע מה אני צריך?
זה מצב נפוץ ולא בעיה. במקום לתאר פתרון, תארו את הבעיה: איפה נשרף זמן, איפה מידע הולך לאיבוד, איזו טעות חוזרת על עצמה. תיאור טוב של התהליך הקיים מספיק לספק טוב כדי להציע כיוון, ולפעמים הכיוון יהיה תוכנה קיימת ולא פיתוח.
האפיון מחייב את הספק לתת מחיר קבוע?
אפיון עסקי מאפשר הצעה עם היקף מוגדר, אבני דרך ורשימה של מה לא נכלל. מחיר קבוע לחלוטין דורש בדרך כלל אפיון טכני מפורט, ורוב הספקים יכללו בו מרווח לאי-ודאות. הגישה שעובדת ברוב המקרים היא מחיר לגרסה ראשונה מוגדרת היטב, ותמחור נפרד להרחבות אחרי שהמערכת כבר בשימוש.
אפשר להשתמש באפיון כדי לקבל הצעות מכמה ספקים?
כן, וזו אחת הסיבות הטובות לכתוב אותו. כשכל הספקים מקבלים את אותו מסמך, אפשר להשוות הצעות לפי מה שכלול בהן ולא לפי הסכום בלבד. אם הצעה אחת נמוכה משמעותית מהאחרות, לרוב היא פירשה חלק מהדרישות אחרת, ושווה לשאול איזה חלק.
שירות קשור
מערכות ניהול עסקיות בהתאמה אישית
ברוב העסקים הקטנים המידע החשוב מפוזר בין אקסל, קבוצת וואטספ ומחברת. מערכת ניהול עסקית מרכזת לידים, הזמנות, מלאי וצוות במקום אחד, ומראה לכם בכל רגע מה באמת קורה בעסק.
