מפרט טכני לפיתוח: מה חייב להיות בו לפני שפונים לספק

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

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

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

מה ההבדל בין מפרט טכני לאפיון?

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

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

מה חייב להיות במפרט טכני לפני שפונים לספק?

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

העסק והמשתמשים

1. המטרה העסקית ומדד ההצלחה

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

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

2. מי המשתמשים, ומה כל אחד מהם רשאי לעשות

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

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

3. התהליכים המרכזיים, מתחילתם ועד סופם

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

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

מערכות ונתונים

4. מערכות קיימות שצריך להתחבר אליהן

כתוב מספיק: שם כל מערכת, למשל ERP, CRM, סליקה או דיוור. מה עובר ביניהן ולאיזה כיוון, האם יש למערכת ממשק חיבור (API) מתועד, ומי אחראי עליה אצלכם או אצל הספק שלה.

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

5. הנתונים: מה נשמר, ומה עובר מהמערכת הישנה

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

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

איכות ואבטחה

6. ביצועים ועומסים

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

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

7. אבטחה ופרטיות

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

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

8. נגישות, שפות ומכשירים

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

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

גבולות והיום שאחרי

9. מה לא כלול, ומה עוד לא ידוע

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

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

10. מה קורה אחרי ההשקה

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

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

כמה מפורט צריך להיות מפרט טכני?

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

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

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

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

מי צריך לכתוב את המפרט הטכני?

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

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

מתי המדריך הזה לא מתאים לכם

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

איך זה עובד אצלנו

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

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

תבנית מפרט טכני להורדה

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

להורדת תבנית המפרט (PDF)