מפרט טכני לפיתוח אתר 1С-Bitrix
תארו לעצמכם שאתם משיקים חנות מקוונת על 1С-Bitrix. קטלוג של 15,000 מוצרים, אינטגרציה עם 1С, ארון B2B לסוחרים. המפתח שואל: 'איך מסננים לפי מלאי?' – ומתברר ששום מקום לא צוין שהמחירים צריכים להיות אישיים לכל קבוצת סוחרים. התוצאה: עיבוד מחדש של הסינון והחשבון האישי מוסיף 40% לתקציב.
לפי הסטטיסטיקה שלנו, 80% מבעיות הביצועים נובעות מתיאורים לא ברורים של בלוקי מידע, ותיקונים במהלך הפיתוח עולים פי 3-5 יותר מאשר תיקון המפרט. לכן אנחנו יוצרים מפרט טכני שלוכד את כל הדרישות לפני תחילת הפיתוח. הזמינו מפרט טכני – נכין מסמך שחוסך לכם עד 50% מהתקציב ומבטל אי-הבנות ביניכם לבין המפתח.
אילו סעיפים חייבים להיות במפרט טכני ל-Bitrix?
מפרט טכני לפרויקט Bitrix שונה ממפרט טכני לאתר גנרי. בנוסף לסעיפים סטנדרטיים (מטרות, קהל יעד, דרישות פונקציונליות), נדרשים סעיפים ספציפיים.
מהדורה ורישוי
ציינו את מהדורת Bitrix (Start, Standard, Small Business, Business, Enterprise) ואת ההצדקה. לחנות מקוונת, המינימום הוא Small Business (מודול קטלוג, SKU, מחירון אחד). אם נדרש קטלוג מורחב עם מספר סוגי מחירים, כללי הנחה (sale.discount), צבירת מלאי בין מחסנים – Business או Enterprise.
מבנה בלוקי מידע
פרטו את כל בלוקי המידע עם סוגי המאפיינים. כאן מתקבלת החלטה שלא ניתן לשנות בהמשך ללא כאב: סוג מאפיין 'String' לעומת 'Directory' (בלוק HL). עבור כל בלוק מידע, טבלה:
| מאפיין | סוג | מרובה | בשימוש בסינון |
|---|---|---|---|
| מותג | Directory (HL) | לא | כן |
| צבע | List | כן | כן |
| תיאור | HTML/text | לא | לא |
אינטגרציות
החלפה עם 1С מתוארת בנפרד: כיוון הסנכרון (דו-כיווני או ייצוא מ-1С בלבד), תדירות, מה מסונכרן (מלאי, מחירים, תמונות, מאפיינים). הטעות היא לכתוב simplement 'אינטגרציה עם 1С'. ציינו: איזו תצורת 1С, החלפה סטנדרטית דרך CommerceML או אינטגרציה מותאמת דרך API, מיפוי שדות.
ביצועים
SLA לזמן תגובת עמוד: קטע קטלוג ≤ N שניות עם M משתמשים במקביל. זו הדרך היחידה להסדיר דרישות ביצועים – ללא סעיף זה, לא ניתן להעלות תלונות על מהירות.
כיצד להימנע מטעויות בעת תכנון מפרט טכני?
מפרט טכני מובנה מפחית עיבוד מחדש פי 3-5 בהשוואה להסכמות מילוליות. מפרט טכני פורמלי יעיל יותר: עיבוד מחדש מתרחש ב-10% מהפרויקטים בלבד לעומת 70% עם הסכמות מילוליות, וחוסך 30–50% מהתקציב. אנו ממליצים לכלול תרחישי משתמש ודרישות טכניות שלעיתים קרובות מוחמצים.
תכנון תרחישי משתמש
מפרט טכני ללא תרחישים מתאר את המערכת אך לא כיצד אנשים עובדים. עבור פרויקט Bitrix, תרחישים חשובים:
- תשלום: מספר שלבים, הרשאה, שיטות משלוח/תשלום, התנהגות עגלת הקניות למשתמשים לא מאומתים.
- חשבון אישי: היסטוריית הזמנות מ-
b_sale_order, סטטוסים, יכולת הזמנה חוזרת. - תרחיש ניהולי: כיצד מנהל מוסיף מוצר, עורך מחיר, מטפל בהזמנה.
כל תרחיש מתואר ברצף עם הפניות לרכיבי Bitrix או מסומן כ'פיתוח מותאם'.
השמטות אופייניות במפרט טכני
- תפקידי משתמש והרשאות: Bitrix משתמש בקבוצות ובמערכת הרשאות עבור בלוקי מידע, קטעים, רכיבים. עבור ארון B2B או קטע סוחרים, מטריצת ההרשאות חייבת להיות במפרט הטכני.
- דרישות SEO טכניות: כתובות SEF, תגי מטא,
robots.txt,sitemap.xml– מוגדרים דרך מודול seo. ללא דרישות מפורשות, משתמשים בברירות מחדל. - ריבוי שפות: עבור מספר שפות, ציינו את מבנה אתרי השפה בליבה אחת, מיפוי תוכן, לוקאל לתאריכים ולמטבעות.
מדוע התקציב גדל ללא מפרט טכני?
מקרה: ספק סיטונאי רצה 'קטלוג עם סינון וחשבון אישי לסוחרים'. מפרט טכני בן 2 עמודים נכתב בתוך צוות הלקוח. לאחר ההשקה התברר:
- הסוחרים היו זקוקים למחירים אישיים (שלושה סוגי מחירים לכל קבוצה), אך המפתח יישם מחירון אחד.
- הסינון לא התחשב במלאי – מוצרים עם מלאי אפס הופיעו בתוצאות.
- החשבון האישי הציג רק הזמנות שבוצעו דרך האתר, אך הסוחרים ציפו להיסטוריה מ-1С.
העיבוד מחדש ארך 3 חודשים עם תקציב פיתוח מקורי של 6 שבועות. אילו הדרישות היו מפורמלות במפרט טכני לפני תחילת העבודה, ההיקף והעלות היו מוערכים נכון. מפרט טכני פורמלי יעיל פי 3-5 מהסכמות מילוליות: עיבוד מחדש מתרחש ב-10% מהפרויקטים בלבד במקום 70%.
מקרה בוחן: פורטל B2B לסוחרים
הלקוח הוא יצרן ציוד עם 200 סוחרים. המפרט הטכני כלל תרחישי רישום מפורטים, טעינת מחירים אישיים מ-1С, מטריצת זכויות גישה מורכבת. התוצאה: השקה ב-8 שבועות עם אפס תיקונים פונקציונליים.כיצד אנו יוצרים מפרט טכני: תהליך שלב אחר שלב
- ראיון לקוח: זיהוי תהליכים עסקיים, משתמשים, אינטגרציות.
- ניתוח מערכות קיימות (1С, CRM, מחסן).
- תכנון מבנה בלוקי מידע ומאפיינים.
- תיאור תרחישי משתמש לכל התפקידים.
- ניסוח דרישות פונקציונליות המקושרות לרכיבים ולמודולים של Bitrix.
- הגדרת דרישות לא-פונקציונליות: ביצועים, אבטחה, מדרגיות.
- אב-טיפוס של מסכים מרכזיים (wireframes).
- סקירה והשלמת המסמך.
היקף מפרט טכני לחנות מקוונת טיפוסית: 40–80 עמודים. זמן הכנה: משבועיים לפרויקט קטן ועד 6–8 שבועות לפורטל מורכב רב-תפקודי עם מספר אינטגרציות.
מה כלול בעבודה
| מסמך | תיאור |
|---|---|
| מפרט טכני ב-PDF/Word | מסמך מלא עם בלוקי מידע, תרחישים, דרישות טכניות |
| אב-טיפוסים של מסכים | Wireframes של עמודים מרכזיים (קטלוג, כרטיס מוצר, עגלת קניות, חשבון אישי) |
| מטריצת זכויות גישה | תפקידים והרשאות עבור בלוקי מידע וקטעים |
| תיאור אינטגרציה | מיפוי API מפורט עבור 1С, מערכות תשלום, משלוח |
| המלצות ביצועים | הגדרות מטמון, אינדקסים, המלצות אחסון |
| תמיכה לאחר | ייעוץ במהלך השקת הפיתוח |
מפרט טכני שהוכן כראוי מבטיח תקציב שקוף ותוצאות צפויות. הניסיון שלנו של 10+ שנים בפיתוח Bitrix מבטיח את איכות התיעוד. מידע נוסף ניתן למצוא במאמרים רלוונטיים ב-Wikipedia וב-Wikipedia (1С-Bitrix).
קבלו ייעוץ והזמינו מפרט טכני – נעזור להכין מפרט טכני לפרויקט שלכם ולהימנע מטעויות אופייניות.