החלטנו לקחת פרויקט לפיתוח, עשינו שיחות עם הלקוח ואנחנו חושבים שהבנו מה הלקוח רוצה.
זה הזמן לסכם את הפרויקט ולשים לב למספר נקודות שיהיו מוסכמות על כל הצדדים.
כשלוקחים פרויקט חדש בדרך כלל הכל נראה בסדר,
- יש עיצוב (חלקי או מלא)
- יש איפיון (חלקי או מלא) כתוב או בעל פה
- סוגרים על תאריך הגשה ועל תכולה
- לבסוף גם על העלות
מתחילים לעבוד וככול שהזמן מתקדם הבעיות מתחילות לעלות ולאט לאט (לפעמים גם מהר) הפרויקט כבר לא ורוד כל כך והצדדים יוצאים לא מרוצים.
אנחנו ננסה למנוע את זה כמה שרק אפשר, זה אף פעם לא יהיה חסין לגמרי אבל לומדים עם הנסיון – גם אם הוא רע.
המטרה
ליצור בהירות ככול האפשר לכל הצדדים על גבולות גיזרה והבנה שכל חריגה יכולה להתקל בסירוב או תוספת תשלום.
שימו לב, אתם בעלי המקצוע והלקוח מגיע עם רעיון, זה לא אומר שהוא מבין מה הקורה מאחורי כל בקשה שלו או כל עיצוב. הוא לא מבין למה משהו כל כך קטן יכול לקחת כל כך הרבה זמן ולעלות כל כך הרבה.
בנוסף לזה, בגלל חוסר הידע שלו לרוב הוא יהיה חשדן עבור התהליך ולכן כאשר עושים את ההסכם חשוב שהוא יהיה פשוט, ברור ולהיצמד אליו לטובת כל הצדדים.
במידה שאתם צוות, כאשר כל אחד עושה חלק אחר בפרויקט, יש ליצור הסכם ניפרד עבור כל אחד, במטרה היא לנתק תלות של כל אחד בשני.
כך, אם אחד מאנשי הצוות פורש או לא עושה את העבודה שלו זה לא ישפיע על ההסכמים עם שאר הצוות.
פרויקט WEB מורכב בדרך כלל מפרונט-אנד, בק-אנד, בסיס נתונים, קידום אתרים, עיצוב ואיפיון.
רשימת שאלות שיש לכלול בהסכם:
מה רצף תהליך הפרויקט?
- פיתוח, עיצוב ואיפיון במקביל
- איפיון -> עיצוב -> פיתוח
- איפיון מוכן חלקית ועל בסיסו יש לעשות עיצוב ופיתוח
- עבודה רק על מה שמוכן, בידיע שמה שמוכן סגור ולא יתבצעו בו שינויים, אבל התכולה המלאה לא ידוע.
על פי שאלה זו, אפשר לדעת מה מידת הסיכון בפרויקט.
אופציה 1 היא המסוכנת ביותר ולכן יש במקרה כזה לגדר יותר בנוקשות מה ואיך צורת התשלום מתבצעת וזמן סיום הפרויקט.
אופציה 2 היא הטובה ביותר. זה התהליך הבטוח ביותר לכל המשתתפים בתהליך
אופציות 3-4 גם הם מסוכנות ועלולות לגרור ביזבוז שעות עבודה ותסכול מצד המשתתפים ולכן גם כאן יש להגדיר באופן ברור זמנים ותשלומים עבור עבודה.
האם הפרויקט צריך להיות נגיש?
אם כן, מה רמת הנגישות? A/AA/AAA .
בישראל כמו ברוב העולם שהעביר את חוק הנגישות, רמת הנגישות שנדרשת היא AA .
לא כל האתרים צריכים נגישות אבל הרוב המוחלט צריך ואם הוא לא נגיש, הוא יכול להיות חשוף לתביעות.
במידה שצריך אתר נגיש, רצוי להוסיף להערכת השעות על הפרויקט בערך עוד 20-30 אחוז.
האם האתר צריך להיות רספונסיבי?
במידה שכן, יש לקבוע נקודות קצה (מה הרוחב הכי קטן ומה הכי גדול של מסך), האם יש נקודות שבירה ברזולוציות מסויימות או שצריך רק לדאוג שזה יסתדר על המסך בצורה טובה ללא שינוי ממשי ברכיבים.
לדוגמה:
אם במסך גדול התפריט נמצא בהמבורגר וכך גם במסך קטן אז לא מדובר על שינוי ברכיב, אבל אם במסך גדול התפריט פרוס לרוחב וברזולוציה מסויימת הוא הופך להמבורגר אז כן יש שינוי של הרכיב וזה דורש זמן נוסף של בניה.
האם לאתר יש התחברות?
אם יש, זה אומר שצריך להוסיף לוגיקות עבור הרשאות, איזה מידע משתמש מזוהה רואה ואיזה משתמש לא מזוהה רואה. מקומות שלא ניתן לגשת ללא התחברות וכו'.
האם האתר מיועד להתארח בפלטפורמה מסויימת?
יש פרויקטים שבסופו של דבר לא עוברים פריסה לאיחסון כלשהו בענן אלא עולים לפטפורמות כמו שרפויינט, אומברקו, וורדפרס וכו'.
יש לקחת בחשבון שאם מדובר בצורך כזה והוא לא מוכר, זה יכול לקחת זמן למידה ובמקרים מסויימים לאלץ פיתוח בתצורה מסויימת על מנת שהתוצר הסופי יעבוד תקין.
מה שפת הפיתוח (צד לקוח וצד שרת)?
יש שפות מסויימות שיותר קל לעשות דברים ולוקח פחות זמן לעשות אותם, באופן טבעי יש שפות שאנחנו יותר מכירים וכאלו שפחות ועל פי זה יקבע הערכה לזמן הפיתוח.
באיזה בסיס נתונים מדובר?
גם זה יכול לגרום לשינוי גדול בזמן הפיתוח
האם הבסיס נתונים קיים או שצריך להקים אותו?
יש יתרונות וחסרונות אם צריך להקים בסיס נתונים לבין אם הוא קיים. בדרך כלל, להקים אחד יקח אקסטרה זמן פיתוח.
האם דרוש SEO?
קידום אתרים יכול לקחת זמן רב, במידה שהלקוח מעוניין שיבוצע לו גם קידום אתרים, יש לסגור את זה בנפרד מהפיתוח (אורך זמן הקידום, העלות שלו לשעה ומספר השעות ליום/שבוע שיושקע בקידום)
כמה סבבי תיקונים?
יש לקבוע מראש כמה סבבי תיקונים יבוצעו על האתר לפני שהוא ימסר סופית ללקוח. בדרך כלל נהוג 2 סבבים.
בסיום הפרויקט, נותנים ללקוח לבצע בדיקת איכות כאשר בסופו הלקוח יחזיר קובץ אקסל או וורד עם תיעוד של כל הבעיות שהוא מצא.
יש להבדיל בין בעיות לשינויים ועדכונים, בעיות אלו חריגות מהעיצוב והאיפיון או שגיאות שיש לתקן. שינויים אלו דברים שאולי לא מוצאים חן בעניי הלקוח אבל הם אכן על פי האפיון והעיצוב (אלו דברים ששינוי שלהם יעלה לו כסף עבור שעות עבודה נוספות).
זה הסיבוב הראשון (יש לתחום בזמן של עד שבוע להחזרת הדו"ח תקלות), את התקלות יש לתקן בזמן שמוגדר מראש עבור כל סבב (בדרך כלל כשבועיים).
לאחר תיקון כל התקלות, נותנים ללקוח שוב את הפרויקט מתוקן לסיבוב נוסף.
במידה שנמצאו תקלות שהלקוח כבר התלונן עליהם והם לא תוקנו, אותם תקלות עדיין נחשבות לסבב ראשון.
במידה שהלקוח מצא תקלות חדשות נוספות, זה סיבוב שני, שבסופו יוגש דו"ח נוסף עם מה שנמצא.
לאחר תיקון כל התקלות ואישור של הלקוח שאכן התקלות שהוא התלונן עליהם טופלו, הפרויקט הסתיים באופן רשמי וכל טענה או בעיה אחרי זה יתומחר כעדכון/ שינוי לפרויקט גם אם הוא באג שהתפספס.
האם יש הגבלה טכנולוגית או הגבלה בשימוש בספריות צד שלישי?
יש לקחת בחשבון שלפעמים יש להוסיף ספריות של רכיבים קיימים ולא ליצור את הכל מאפס על מנת שהפיתוח יתקדם מהר ויעיל.
במידה שהלקוח לא מעוניין בזה, יש לבדוק את העיצובים ממש טוב לפני אישור, על מנת שלא תתקלו ברכיב מסובך שיגזול ממכם הרבה יותר זמן ממה שחשבתם
מה שיטת התשלום?
בדרך כלל השיטה הפופולרית ביותר היא "אבני דרך", קובעים נקודות פיתוח שכאשר מגיעים אליהם אז משלמים חלק מהסכום.
אפשר לחלק על פי רכיבים או דפים או כל דבר אחר שהוא מספיק ברור לכולם.
מאוד לא מומלץ לעשות אבני דרך על פי זמן, זה מצב בעיתי שעלול לגרום לחוסר אמון בין הלקוח לבעלי המקצוע אם הוא ירגיש שלא התקדמו מהר מספיק.
דרך נוספת היא לקבוע תאריך מסירה שבו הלקוח מצפה לקבל את הפרויקט מוכן לבדיקה ראשונה של באגים.
מה עושים במצב של אי עמידה ביעדים?
זה החלק הפחות נעים לדבר עליו, אבל הוא הכרחי 🙂 . יש לקבוע מנגנון זיכוי עבור אי עמידה בזמנים, כך שכל הצדדים ידעו מה קורה במצב של איחור.
בדרך כלל קובעים סכום שירד מהתשלום עבור הפיתוח בכל איחור של שבוע (בתחילת כל שבוע איחור).
יש לעגן את תחילת האיחור בתאריך ידוע לכולם.
שימו לב, שהזיכוי לעולם לא יעלה על התשלום הכללי שהמפתח צריך לקבל.
לדוגמה:
אם הפרוייקט הוערך ב-10,000 , לאחר אבן דרך ראשונה שולם למפתח 2,000. זה אומר שנשאר 8,000.
המפתח איחר את תאריך האבן דרך השניה ונגיד שעבור כל שבוע של איחור הוא יקנס ב-1,000 אז אחרי 9 שבועות איחור (9,000) זה לא אומר שהמפתח יוציא כסף מהכיס שלו אלא פשוט ירדו ה-8,000 שנשארו והמפתח לא יקבל יותר תשלום עבור הפיתוח שלו.
זו דוגמה קיצונית ולא הגיונית, אבל היא כאן כדאי להסביר את הרעיון.
במקרה שעובדים בצוות ויש תלות אחד בשני, יש לשים לב שאם מישהו מאחר וגורם להוזזה של כולם בזמנים אז אין לכנוס את כולם, אלא רק את זה שאיחר ולהוזיז את הלוח זמנים (גנט) בהתאם.
כמה סקיצות של עיצוב רעיוני צריך לעשות?
לפני שעושים עיצוב לפרטי פרטים, בדרך כלל יוצרים מספר עיצובים כללים שמתוכם הלקוח בוחר את הסגנון שהוא מעוניין, בדרך כלל זה בין 3 ל-5 סוגי עיצובים.
שימו לב שלא מדובר על עיצוב מפורט אלא משהוא כללי כדאי לתת תחושה ללקוח של הנראות בסוף התהליך.
לאחר בחירה של הלקוח באחד העיצובים, מתחילים להכנס לפרטים.
ככול שהלקוח רוצה יותר סגנונות לבחור מהם כך עולה הזמן עבודה ויש לקחת את זה בחשבון.
האם העיצוב נשען על הגבלות מסויימות?
עיצוב מוגבל על ידי גריד, מספר עיצובים לכל מסך על פי נקודות שבירה, פלטת צבעים ספציפית, ניגודיות צבעים שחייבת לעמוד בנגישות.
ככול שיש יותר הגבלות, כך זמן העבודה עולה.
אלו מספר נקודות שכדאי לקחת בחשבון, כמובן שתמיד אפשר להוסיף/ להוריד ולשנות את הנקודות בהתאם לצורך ואופי הפרויקט.
בהצלחה בפרויקטים החדשים 👔