המונח אתר מורכב נשמע כמו אתר גדול, וזה לא אותו דבר. אפשר לבנות אתר עם אלף עמודי מוצר שהוא פשוט לחלוטין, ואפשר לבנות אתר בן עשרה עמודים שהוא פרויקט תוכנה לכל דבר.
מה שקובע הוא לא הכמות אלא מה קורה מאחורי הקלעים: לוגיקה שמחשבת משהו, חיבור למערכת אחרת, משתמשים שנכנסים עם סיסמה, או תהליך שממשיך גם אחרי שהמבקר עזב.
המאמר מסביר מה באמת הופך אתר למורכב, מתי נדרש כזה, איך נראה התהליך, ומה מייקר ומאריך אותו יותר מכל דבר אחר.
מה הופך אתר למורכב?
ארבעה מאפיינים. לוגיקה עסקית שמחשבת או מחליטה משהו, חיבור למערכת חיצונית, אזור אישי עם משתמשים והרשאות, ותהליכים שרצים ברקע. אתר עם אחד מהם כבר אינו אתר תדמית, ואתר עם שלושה מהם הוא מערכת שדורשת ניהול מתמשך.
| המאפיין | דוגמה | מה זה מוסיף |
|---|---|---|
| לוגיקה עסקית | מחשבון מחיר או התאמה | פיתוח ובדיקות |
| חיבור למערכת | מלאי, סליקה, CRM | תלות בצד שלישי |
| משתמשים והרשאות | אזור אישי, מנוי | אבטחה ופרטיות |
| תהליכי רקע | סנכרון, התראות, דוחות | ניטור ותחזוקה |
השורה השנייה היא זו שמייצרת את רוב ההפתעות. כל חיבור למערכת חיצונית תלוי בממשק שלה, ושינוי אצלה יכול לשבור משהו אצלכם בלי שום התראה מראש.
השורה השלישית מכניסה שיקולים חדשים לגמרי. ברגע שיש משתמשים רשומים, יש מידע אישי, ויש חובות שנובעות מכך גם מבחינת אבטחה וגם מבחינת פרטיות.
השורה הרביעית היא זו שנשכחת באפיון. תהליך שרץ בלילה ומסנכרן מלאי צריך מישהו שיודע שהוא נכשל, אחרת הכשל מתגלה רק כשלקוח מזמין מוצר שאזל.
מתי באמת צריך אתר כזה?
כשהתהליך העסקי עצמו דורש את זה. חנות עם מלאי משתנה, מערכת הזמנות, אזור לקוחות, או שירות שמחייב הרשמה וניהול. לעומת זאת, עסק שרוצה להציג שירותים ולקבל פניות לא צריך מערכת, והוא רק ישלם על מורכבות שלא תשמש אותו.
המבחן הפשוט הוא לשאול מה קורה אחרי הפנייה. כשהתשובה היא שיחת טלפון, מדובר באתר תדמית פשוט. כשהתשובה כוללת הזמנה, תשלום או ניהול חשבון, מדובר במערכת לכל דבר.
לעיתים קרובות, החלק המורכב לא צריך להיות באתר בכלל. מערכת קיימת בשוק שעושה את זה יכולה להיות זולה ובטוחה יותר מפיתוח ייעודי, ואפשר לחבר אליה.
השיקול כאן הוא לא רק עלות אלא גם אחריות. מערכת מוכרת מתוחזקת ומאובטחת על ידי מי שבנה אותה, ופיתוח ייעודי מטיל את כל האחריות הזאת עליכם ועל מי שיתחזק אותו בעוד שלוש שנים.
בפרויקטים של בניית אתרים לחברות אנחנו מתחילים בשאלה הזאת. הרבה פעמים מתברר שרק חלק קטן מהפרויקט באמת דורש פיתוח, והשאר נפתר בכלים קיימים.
איך נראה התהליך?
בשישה שלבים, והראשון שבהם הוא הארוך והחשוב ביותר. אפיון מלא, עיצוב ממשקים, פיתוח, אינטגרציות, בדיקות, והשקה מבוקרת. פרויקטים שנתקעים כמעט תמיד נתקעים בגלל אפיון חלקי, כי שינוי שמתגלה באמצע הפיתוח עולה פי כמה משינוי שנקבע במסמך מראש.
- אפיון: מה המערכת עושה, מי המשתמשים, מה כל אחד רואה
- עיצוב ממשקים: מסכים ותהליכים, לא רק עמודים
- פיתוח: בניית הלוגיקה והתשתית
- אינטגרציות: חיבור למערכות חיצוניות
- בדיקות: תרחישים, לא רק שהעמוד נטען
- השקה: העברה, גיבוי, ניטור ותוכנית לתקלות
השלב הראשון הוא זה שמפתה לקצר. אפיון לוקח שבועות ולא מייצר שום דבר שאפשר לראות, וזה בדיוק החלק שקובע אם הפרויקט יסתיים בזמן.
השלב החמישי גם הוא נדחק. בדיקה במערכת מורכבת אינה לוודא שהעמוד נטען, אלא לעבור על תרחישים: מה קורה כשהתשלום נכשל, כשהמלאי אזל, וכשהמשתמש סוגר באמצע.
השלב האחרון קובע מה קורה ביום הראשון. תוכנית לתקלות, גיבוי אוטומטי ומישהו שזמין בשעות הראשונות הם ההבדל בין תקלה קטנה לבין יום שלם של השבתה.
כדאי גם לא להשיק ביום עמוס. השקה בתחילת שבוע ובשעות שבהן יש מי שזמין לתקן עדיפה על השקה בערב שישי, כי תקלה שמתגלה כשאין אף אחד נשארת פתוחה יומיים.
מה מייקר יותר מכל דבר?
שינויים שמגיעים באמצע הדרך. כל שינוי אחרי שהפיתוח התחיל דורש לפרק ולבנות מחדש חלקים שכבר עבדו, ולעיתים לשנות גם את מה שמסביבם. אחריו מגיעות אינטגרציות שלא נבדקו מראש, ותרחישי קצה שלא הוגדרו ומתגלים רק בשלב הבדיקות.
| הגורם | למה זה יקר | איך מונעים |
|---|---|---|
| שינוי באמצע | מפרק עבודה קיימת | אפיון מלא ומאושר |
| אינטגרציה לא בדוקה | מתגלה שאין ממשק | בדיקת היתכנות מראש |
| תרחישי קצה | לא הוגדרו | לרשום מה קורה בכשל |
| העברת נתונים | מבנה ישן לא תואם | מיפוי לפני ולא אחרי |
| בעלי עניין רבים | החלטות נדחות | מגדירים מי מכריע |
השורה השנייה היא הסיכון הגדול שאפשר לנטרל בשעה. בדיקה מוקדמת אם למערכת החיצונית יש בכלל ממשק פתוח, ומה הוא מאפשר, חוסכת גילויים מאוחרים ויקרים.
השורה הרביעית מפילה פרויקטים של מעבר ממערכת קיימת. נתונים ישנים כמעט אף פעם לא בנויים כמו שהמערכת החדשה מצפה, והמיפוי הוא עבודה בפני עצמה.
השורה האחרונה היא ניהולית ולא טכנית. פרויקט שבו חמישה אנשים צריכים לאשר כל החלטה מתקדם לאט מאוד, וכדאי להגדיר מראש מי מכריע כשיש חילוקי דעות.
אותו דבר נכון ללוח הזמנים. פרויקט שמוגדר עם אבני דרך ותאריכים לאישור מתקדם, ופרויקט שמוגדר רק בתאריך סיום מגלה באמצע שכולם מחכים לכולם ואף אחד לא מודע לעיכוב שנצבר.
מה עם קידום באתר מורכב?
צריך לתכנן אותו בשלב האפיון ולא אחריו. מבנה כתובות, כותרות, אפשרות לערוך תוכן, ואיזה עמודים בכלל נגישים לגוגל הן החלטות שנקבעות בפיתוח. אתר שנבנה בלי לחשוב על זה מגיע מוכן ומתפקד, ובלי דרך מעשית לקדם אותו.
הבעיה הנפוצה ביותר היא תוכן שנטען דינמית. כשהטקסט מוזרק אחרי טעינת העמוד, סורקים מסוימים לא רואים אותו כלל, ומבחינת גוגל העמוד ריק.
בעיה שנייה היא כתובות שנוצרות אוטומטית. מערכת שמייצרת אלפי כתובות של סינון ומיון מציפה את האינדקס, ובלי חסימה מסודרת גוגל סורקת אותן במקום את מה שחשוב.
בעיה שלישית היא היעדר שליטה בטקסטים. מערכת שבה כותרת או תיאור מוגדרים בקוד ולא בממשק מחייבת פנייה למפתח בכל שינוי קטן, ובפועל זה אומר שהם לא משתנים לעולם.
בעבודת מומחה קידום אתרים על מערכת קיימת, חלק ניכר מהזמן מוקדש לעקיפת החלטות שנעשו בפיתוח. כשהוא נמצא בחדר בשלב האפיון, זה כמעט לא קורה.
מה קורה אחרי ההשקה?
מתחילה תחזוקה, וזה לא סעיף שאפשר לדלג עליו. עדכוני אבטחה שוטפים, ניטור תהליכים שרצים ברקע, טיפול בשינויים במערכות שאליהן מחוברים, וגיבוי שנבדק בפועל. אתר מורכב שלא מתוחזק נשבר בשקט, ולרוב מגלים את זה דרך לקוח שהתלונן.
הניטור הוא החלק שהכי חוסך. התראה אוטומטית כשתהליך רקע נכשל או כשעמוד מפסיק להגיב מגיעה אליכם לפני שהלקוחות מרגישים, וזה ההבדל בין תקלה לבין משבר.
ההגדרה שלו לוקחת שעה. בוחרים כמה נקודות קריטיות, מגדירים התראה למייל או להודעה, ומוודאים שהיא מגיעה למישהו שבאמת קורא, ולא לכתובת כללית שאף אחד לא נכנס אליה.
גם הגיבוי דורש בדיקה ולא רק הגדרה. גיבוי שרץ שנתיים ואף אחד לא ניסה לשחזר ממנו הוא הימור, ובדיקת שחזור אחת בשנה מגלה אם הוא באמת עובד.
וכשהמערכת חיה, כדאי שגם הפרסום ימשיך. קידום ממומן בגוגל מייצר תנועה מהיום הראשון, בזמן שהאורגני על מערכת חדשה נבנה לאורך חודשים.
מורכבות היא לא מספר העמודים אלא מספר הדברים שיכולים להישבר. כל חיבור למערכת חיצונית הוא עוד אחד כזה.
אור פלתה, מנכ״ל U Digital Studio
שאלות ותשובות
מה נחשב אתר מורכב?
אתר עם לוגיקה עסקית שמחשבת או מחליטה, חיבור למערכת חיצונית, אזור אישי עם משתמשים והרשאות, או תהליכים שרצים ברקע. מורכבות אינה גודל: אתר של אלף עמודים יכול להיות פשוט, ואתר של עשרה מורכב מאוד.
מתי עסק באמת צריך אתר מורכב?
כשהתהליך העסקי דורש זאת: חנות עם מלאי משתנה, מערכת הזמנות, אזור לקוחות או שירות עם הרשמה. המבחן הפשוט הוא מה קורה אחרי הפנייה. אם התשובה היא שיחת טלפון, מדובר באתר תדמית ולא במערכת.
מה השלב החשוב ביותר בתהליך?
האפיון. הוא לוקח שבועות ולא מייצר שום דבר שאפשר לראות, וזה בדיוק החלק שקובע אם הפרויקט יסתיים בזמן. פרויקטים שנתקעים כמעט תמיד נתקעים בגלל אפיון חלקי שהתגלה באמצע הפיתוח.
מה הכי מייקר פרויקט?
שינויים באמצע. כל שינוי שמגיע אחרי תחילת הפיתוח דורש לפרק ולבנות מחדש חלקים שכבר עבדו. אחריו מגיעות אינטגרציות שלא נבדקו מראש ותרחישי קצה שלא הוגדרו ומתגלים רק בשלב הבדיקות.
האם חייבים לפתח הכול מאפס?
לרוב לא. מערכת קיימת בשוק שעושה את מה שצריך יכולה להיות זולה ובטוחה יותר מפיתוח ייעודי, ואפשר לחבר אליה. בהרבה פרויקטים מתברר שרק חלק קטן באמת דורש פיתוח והשאר נפתר בכלים קיימים.
למה קשה לקדם אתר מורכב?
כי החלטות פיתוח משפיעות ישירות על הקידום. תוכן שנטען דינמית עלול לא להיקרא כלל, וכתובות שנוצרות אוטומטית מציפות את האינדקס. לכן כדאי לתכנן מבנה כתובות ועריכת תוכן כבר בשלב האפיון.
מה כולל התחזוקה אחרי ההשקה?
עדכוני אבטחה, ניטור תהליכים שרצים ברקע, טיפול בשינויים במערכות שאליהן מחוברים, וגיבוי שנבדק בפועל. אתר מורכב שלא מתוחזק נשבר בשקט, ולרוב מגלים את זה דרך לקוח שהתלונן ולא דרך התראה.
איך מוודאים שגיבוי באמת עובד?
מנסים לשחזר ממנו. גיבוי שרץ שנתיים ואף אחד לא ניסה לשחזר ממנו הוא הימור. בדיקת שחזור אחת בשנה, לסביבת בדיקה נפרדת, מגלה אם הקבצים תקינים ואם התהליך בכלל עובד כשצריך אותו.
