בניית אתרים – מאיפה מתחילים?!

בתמונה מפת אתר של אחד הפרויקטים שלנו –

הסבר בהמשך מתי משתמשים בזה….

יוצא לי לראות בכל מיני קבוצות פוסטים בסגנון:

“צריך אתר מכירות, 10 מוצרים, כולל התחברות לסליקה תקציב 200 שקל מי לוקח?”

יש מצב שחיים בקרבנו הרבה טרולים

כי יש לא מעט פוסטים כאלה

שלא כ”כ ברור לי מה המטרה שלהם

לא מכיר אף אחד שבונה אתר איקומרס ב-200 שקל

גם לא בשביל תיק עבודות

אז מאיפה מתחילים…?

מלכתוב את כל הבקשות והחלומות שלנו

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

מסמך הדרישות הזה יהפוך בהמשך הדרך לאפיון פונקציונאלי מפורט

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

1. רקע על המותג, על הפעילות שלו, על לאן הוא רוצה להגיע באמצעות הקמת האתר

2. בעלות על הקניין הרוחבי שיהיה בבעלות המותג ולא בבעלות חברת הפיתוח לרבות קוד המקור

3. הגדרה של הפעילויות בסביבת פיתוח \ סביבת אמת

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

5. התייחסות למובייל – גישה עיצוב ופיתוח של מובייל פירסט

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

6. הגדרה של הדפדפנים אליהם הפרויקט צריך להיות מותאם

7. הגדרה של מה יכולות ה-CMS שנדרשות בפרויקט

תתפלאו שגם בפרויקטים של ווקומרס \ שופיפיי – עדיין צריך להגדיר על מה רוצים שליטה ומה יהיה בהכרח בקור

8. סוגי הרשאות לסוגי יוזרים שונים

9. תאימות SEO – צ’ק ליסט של כל הדברים הבסיסיים שאנחנו צריכים בפרויקט

לאחר מכן יצטרפו למסמך דרישות מפורטות של חברת ה-SEO שמלווה את הפרויקט

בד”כ הצ’ק ליסט שלנו מספק למעלה מ-90% מהדרישות

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

11. הגדרה של ציון מהירות האתר ושל זמן טעינת האתר ובאיזה כלים נשתמש על מנת לבדוק זאת.

זה שני דברים שהם לכאורה דומים אבל בפועל שונים האחד מהשני

12. הגדרה של השפות שהאתר יתמוך בהן –

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

13. הגדרה של התוספים \ רישיונות לתוספים שנדרשים – שאנחנו יודעים מראש. כמובן שיכולים להיות עוד תוספים שיתווספו לאורך הדרך.

14. הגדרה ייעודית של הטמעת מערכת האימייל מרקטינג

15. סעיף סופר קריטי!! הגדרה ייעודית של מערכות הצד ג’ שאליהן נרצה להתממשק ובאיזה אופן.

16. הגדרה של תוסף \ התאמת הנגישות הנדרשת בפרויקט

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

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

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

זה אחד החלקים הכיפיים כי זה מאפשר מעבר על אתרים דומים \ מתחרים ולהפעיל את הגלגלים

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

אני משתף את הרשימה הזו לשימוש הן של מותגים שנמצאים לפני הקמת אתר

והן עבור חברות פיתוח וספקים בתחום כדי שיעתיקו (אין לי בעיה עם זה) וישתפו עם הלקוחות שלהם,

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

“למעשים יש השלכות”

אמרו לנו כשהיינו קטנים

גם היום אני עושה שימוש במשפט הזה להסביר לילדים שלי

שלכל פעולה שלהם יש השלכה

טובה או רעה

אבל יש השלכה

לפני שממשיכים

כמה אנקדוטות שקשורות בבחירות ובבנייית אתרי איקומרס

סיפור 1

לקוח שהגיע אליי לייעוץ

קיבל הצעה לניהול פרויקט מלא

בחר שלא לקחת את התהליך של ניהול פרויקט

ולהישאר רק עם שעות ייעוץ

עשה עיצובים לבד

בחר בפיתוח של חבר’ה הודים ולא מערביים

המחיר של ההודים היה מצחיק

אבל הזמן והעצבים – שיערות לבנות

לבחירה הזו היה מחיר

זה עלה לו לדעתי בכחצי שנה של עיכוב בעלייה לאוויר

האם זה שווה את המחיר שלהם?!

ממש לא בטוח

סיפור 2

תהליך עיצוב ובניית קונספט שארך 5 סבבים במקום 2 כפי שהוסכם מראש

כי הלקוח לא היה מרוצה מהקונספט (לדעתי לא בצדק)

ורמת הדיוק שרצו להגיע שם הייתה בלב אחר

מכל פרויקט אחר שהייתי מעורב בו

בתוצאה הסופית זה ממש לא ניכר לעין (לדעתי)

חוסר השביעות רצון הזה והעבודה שוב ושוב ושוב על הקונספט

גרמה לעיכוב של 4-5 חודשים לפחות

באתר שעושה יותר ממיליון בחודש

סיפור 3

לקוחה שרצתה לבנות אתר חדש כי הישן שלה נראה מימי אנו -בנו

באה לתהליך מלא וחלק ממנו בניית אתר

שחררה בתהליך העבודה את המושכות

לא התעקבה על קטנות

זרמה עם בחירת הספקים שלנו

היינו באוויר תוך 3 חודשים מהתנעת הפרויקט ועד לעלייה

כמו שפתחתי את הפוסט הזה

למעשים יש השלכות

לבחירות שלנו יש תוצאות

לבחור להתעכב > יש תוצאה

לבחור לשחרר > יש תוצאה

שלא ישתמע שאני אומר שלשחרר תמיד זו הבחירה הנכונה, ממש לא!

אני אומר שהשיכולים צריכים להיות מול העיניים

ולהבין את ההשלכה של הבחירה שלנו

לכו לבחור!

בחירת הפלטפורמה

מה יותר טוב?

שופיפיי או ווקומרס

מג’נטו או קאסטום

קונימבו או אישופ

אולי בכלל וויקס?

האמת היא

שאין אמת מוחלטת

צרכים שונים > פלטפורמות שונות

מותג מתחיל יכול לקחת שופיפיי בכמה עשרת דולרים בחודש

לראות שהוא משיק מותג תוך ימים בודדים ולהתחיל לרוץ

לעומת מותג גדול שצריך אינטגרציות מורכבות

שיכול להיות שייבחר במג’נטו או ווקומרס

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

להרוויח כסף ≠ על איזה פלטפורמה האתר יושב

להלן ההסבר שלי לנושא.

ב-6 השנים האחרונות שבי דיגיטל קיימת

יצא לנו לעבוד עם כל המינים והסוגים

1. פלטפורמות קסטום שהותאמו ללקוח

2. מערכות אומברקו

3. מערכות מג’נטו

4. מערכות שופיפיי רגיל וגם שופיפיי פלוס

5. אתרי וורדפרס עם ווקומרס

6. ואפילו אתר קונימבו אחד ומיוחד

בנינו וליווינו אתרים של 15K ש”ח לאתר

וליווינו וניהלנו פרויקטים של 1 מיליון ש”ח לאתר

באמת שראיתי הכל!

על כל פלטפורמה אתם יכולים למצוא

את אלה שימליצו עליה בעיניים עצומות

ואת אלה שיגידו לכם לא להתקרב!

מה שהרבה בעלי עסקים ומותגים לא יודעים ולא מבינים

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

לא אמרתי לא קיימת

אמרתי נמוכה

מה יותר חשוב?

– מוצר מעניין שיש לו קהל מספיק גדול בשוק שאתם עובדים בו שרוצה לקנות *באונליין*

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

השוק שלו זה חו”ל ולא ישראל

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

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

יהיה מאוד קשה לייצר מחנות כזו מכירות אונליין בארץ

ולכן השוק שלו הוא ארה”ב שם הגודל מאפשר לחנות כזו לפעול ולייצר מכירות של כמה מאות אלפי דולרים בחודש

בארץ אותה חנות הייתה מייצרת 2 מכירות בחודש והחנות הייתה נסגרת מזמן.

– תמחור אטרקטיבי

לאו דווקא הכי זול

אבל שהמחיר לצרכן יהיה סביר ביחס לתחרות

שהמחיר ייראה לצד השני “שווה את זה” – שהוא יגיד לעצמו שיש פה עסקה שהיא value for money

– בידול

אלמנט מאוד טריקי, למה לקנות ממכם ולא מהמתחרה?

יכולים לקרוא על זה עוד אצל יאן יאנקו, אליאב אללוף, קרן רייטלר

– הצעת ערך

איזה מוצר לקנות ולמה דווקא עכשיו?

– קהילה

לאו דווקא קבוצת פייסבוק סגורה

אלה אוסף של לקוחות פוטנציאליים שמאמינים בכם ומוכנים להקשיב לכם

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

קהילה זה אלמנט שעוזר לייצר מומנטום במותגים

אז לפני שאתם ניגשים לשבור את הראש

לגבי איזו פלטפורמה מתאימה לכם

כדאי מאוד שתשברו את הראש

על כל אחד מהסעיפים פה ותוודאו שיש לכם תשובה טובה

לבחור פלטפורמה

ולהקים את האתר

מה הקשר בין תנ”ך לבין בניית אתרים?

למעלה כתבתי על החלק של אפיון הצרכים

ונתתי את הרשימה שלי למה כולל מסמך דרישות מלא ומפורט

עכשיו אני רוצה להמשיך ולכתוב על הנושא של האפיון

לאפיון יש עוד 2 זוויות נוספות מעבר לאפיון הדרישות

הראשונה – אפיון חווית המשתמש והמסכים

השניה – אפיון פונקציונאלי – טכנולוגי

שני סוגי האפיון חשובים לפרויקט מוצלח

השני חשוב יותר (לדעתי) ואסביר זאת

האפיון של חווית המשתמש והמסכים

חשוב מאוד לתהליך של הפרויקט

זה מפקס את כל המעורבים לגבי המבנה של האתר

המודולים השונים וההירככיה ביניהם

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

לאנשים פחות טכנולוגיים

זו אחת הדרכים הכי טובות

לתאר תהליך גלישה ורכישה

מבלי להשקיע המון זמן וכסף בעיצוב.

האפיון הפונקציונאלי – טכנולוגי

שכמו שכתבתי כבר חשוב יותר לדעתי

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

אבל הפעם האלמנטים השונים מקבלים עוד 2 מימדים

לא רק תיאור שטוח של מה האלמנט

אלה גם תיאור של התנהגות האלמנט בצד הגולש

ותיאור של התנהגות האלמנט בצד מנהל האתר

על מה נרצה שליטה ואיך.

כמובן דוגמא רלוונטית:

בצד של האתר נרצה מודול באנרים בעמוד הבית

בצד של הגולש – הבאנרים יכולים לזוז ימינה או שמאלה בהתאם לכיוון הסקרול של הגולש

בצד של מנהל האתר

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

תמונה + לינק

ואפשר לקחת את זה למשהו קצת יותר מורכב

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

ניהול של:

תמונה לדסקטופ

תמונה למובייל

לינק

הגדרה אם הלינק ייפתח בחלון חדש או באותו חלון

הגדרה של תזמון התחלת התצוגה של הבאנר לפי תאריך ושעה

הגדרה של תזמון סגירת התצוגה של הבאנר לפי תאריך ושעה

הדוגמא פה מאוד פשטנית

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

המחשבה על הפרטים הקטנים האלה

היא זו שתהפוך את מלאכת ניהול האתר לקלה פשוטה ונעימה

או למסע מפרך של תסכול עבור מנהל האתר.

אז מה הקשר בין תנ”ך לבין בניית אתרים?

האפיון הטכנולוגי הוא התנ”ך של הפרויקט

אליו חוזרים ובודקים מה רצינו ומה תכננו

לכל מודול ולכל עמוד

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

והוא שומר גם על צוות הפיתוח וגם על הלקוח.

מה שלא כתוב – לא יפותח או יתומחר בנוסף.

בלי “אבל התכוונתי ל…”

בשביל זה עושים תהליך של כתיבת מסמך טכני

שמפורט ברמות של שדה בודד ומה צריך להיות בשדה הבודד הזה

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

בעל הסיכון הגבוהה ביותר

בחלק שבו נוצרים הכי הרבה “פיצוצים” בפרויקט.

החלק הזה הוא מסירת הפרויקט לבדיקות קבלה של הלקוח והזנת התוכן

לכאורה זה שני חלקים נפרדים

אבל מהניסיון שלי זה חלקים שהולכים יד ביד

אי-אפשר לעשות בדיקות קבלה לאתר

מבלי לעבוד על מערכת הניהול והזנת התוכן

כל פעם שמזינים משהו חדש

מגלים בעיות ובאגים שלא היו יכולים להיתגלות בלי החלק של הזנת התוכן

לסבר את האוזן,

בפרויקט בסדר גודל בינוני יפתחו מאות בודדות (כן, מאות!) של באגים

איך עוברים את השלב הזה בשלום?

– מתאמים ציפיות בין הלקוח לספק הפיתוח

– משקפים ללקוח שהשלב הזה יכלול באגים ושזה חלק טבעי בתהליך

– לשקף ללקוח שחלק ממה שהוא יבקש הולך להיות בקשות שינוי ולא בהכרח באגים

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

– לרכז את כל הבקשות במקום אחד – עדיף תוכנית ניהול משימות ובשום פנים ואופן *לא!* קובץ גוגל שיט

– כשמרכזים את הבעיות – לתעדף אותן לפי סדר עדיפות \ סדר דחיפות

– לשים צילומי מסך + קישורים לעמוד שבוא קרתה הבעיה

מה לגבי התוכן?

בחלק של התוכן יש להפריד 2 סוגי תכנים

תכנים שעוברים איתנו מהאתר הישן לאתר החדש

צריכים לבצע העברה מדוייקת של התוכן – בדגש על שמירה על מיקומי ה-SEO

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

במקביל ננהל טבלת הפניות 301 שתתעד לנו את הלינקים הישנים לעומת הלינקים החדשים

במטרה להצביע לגוגל על הלינקים החדשים ושגולשים לא יגיעו לעמודי שגיאה למיניהם.