עריכת חוזה מול חברת פיתוח אפליקציות – דגשים חשובים
האינטראקציה הראשונית עם הספק
בטרם תפנו לבחירת חברת פיתוח אפליקציות, מולה תרצו לעבוד ולקבל שירות מקצועי, רצוי לבחון את ההתנהלות בניכם לבינם מאחר ופעמים רבות הקשר הוא ארוך טווח ומחייב.
לדוגמה, אם התחלתם לעבוד עם בית תוכנה לפיתוח מוצר ה"בטא" שלכם, לאורך הזמן מצטבר מידע רב בבית התוכנה, כמו הארכיטקטורה של המידע וכל הרציונל שעומד מאחורי מבנה הקוד.
בהמשך הדרך, במידה ותרצו להחליף בית תוכנה, תצטרכו להשקיע משאבים רבים ב"העברת השרביט".
על כן, רצוי לשאול שאלות רבות טרם העסקת ספק חיצוני ואפילו לעשות פיילוט בעל פיצ'ר אחד בתשלום של כמה אלפי שקלים בכדי לראות את תהליך העבודה ואיכות האינטראקציה עם אותו ספק.
זכרו: המחיר הזול ביותר לא בהכרח ישתלם. מהירות העבודה, התקשרות והטעויות בדרך שווים כסף.
מי רצוי שינסח את הטיוטה הראשונית של חוזה ההתקשרות מול חברת הפיתוח?
בעולם אידאלי, עדיף שאתם תכתיבו את צורת העבודה והתנאים הראשוניים. אבל, פעמים רבות כאשר מדובר בבית תוכנה גדול הוא עובד בצורה מאוד מסוימת ויש לו סוללת עורכי דין מאחוריו שמספקים טיוטה ארוכה אשר לבסוף מכתיבה את ההצעה ותנאיה.
אין זה אומר שההצעה לא טובה, כדאי לקרוא לעומק את הסעיפים ולראות את החשיפה שלכם לסיכונים שונים.
יתרה מכך לכשתקבלו גיוס ממשקיעים יתכן והם יכתיבו את תנאי העסקה ולא יהיה הרבה מקום לתמרון ולשינוי של הסעיפים.
ננסה לסקור את חלק מהנושאים שכדאי לכסות טרם עבודה על פרויקט בסדר גודל של כמה מאות אלפי שקלים ויותר.
הכתוב אינו מהווה ייעוץ משפטי ויש לפעול על בסיס ייעוץ פרטני.
דגשים למעבר על חוזה שהספק ניסח
- ווידוי פירוט תכולת הפרויקט: שימו לב שהפיצ'רים לתכנות מצוינים בצורה ברורה כולל איורים, מוקאפים וסקיצות רלוונטיות. דמיינו כי בנאדם עם ידע בסיסי מהצד יכול להבין מה צריך לעשות, מה היכולות המצופות מהמערכת ומתי. רמת קושי להכניס סעיף לחוזה של בית תוכנה – קל
- ווידוי קיום לו"ז ברור ומפורט המכיל יעדים בצורה מפורטת ומדידה: מומלץ להגדיר milestones לפי תאריכים על פיצ'רים אשר פיתוחם סוכם. נסו לתת ביטוי הולם בלו"ז לטיפוח מוצר שכבר ב"אוויר" ובו בעת עבודה על גרסאות עתידיות, בכפוף לדרך ניהול הפרויקט שלכם. רמת קושי להכניס סעיף לחוזה של בית תוכנה – קל
- חשוב מאוד להסדיר מה קורה אם לא עומדים ביעדי הלו"ז ו/או לא עומדים בפיתוח היכולות שהוגדרו. ישנן כמה אפשרויות בעניין – אפשרות לספק לתקן ולהשלים את השירות תוך אחוז מסוים מאורך כלל הפרויקט, בד"כ יוצא בין כמה ימים לשבועות. במידה ומתבצע התיקון, כדאי לתת אפשרות להשתחרר מהחוזה תוך העברת הידע לספק חדש ו/או הפעלת קנס/פיצוי כספי.
פיגור ביעדים יכול לעלות לחברה שלכם כסף רב, לכן חשבו כמה פיגורים בזמנים עולים לחברה שלכם וכך תוכלו לדעת את הפיצוי שיש לנקוב על כל יום איחור. רמת קושי להכניס סעיף לחוזה של בית תוכנה – בינוני
- קניין רוחני: עלות פיתוח אפליקציה היא גבוהה והתקציב שלכם אינו בלתי מוגבל. אם המוצר שלכם ייחודי, מגיע לכם שהקוד יהיה הקניין שלכם ושיהיה בכל רגע נתון זמין עבורכם. במידה וקיימת ארכיטקטורה ייחודית שנעשתה במיוחד עבורכם נסו לציין באופן מפורש שהקוד הייחודי שייך רק לכם. כלומר, חלקי קוד שלמים הייחודים למוצר שלכם לא יכולים להיות ממוחזרים או מועתקים ללקוח אחר שמתחיל לעבוד עם חברת פיתוח האפליקציות.
תארו לכם סיטואציה שבעל הון אוהב את היישום של הרעיון שלכם, רואה מי בנה לכם את המערכת, פונה אליהם ישירות ומציע להם סכום כסף רב לעשות בדיוק אותו דבר בזמן שהם לא מוגבלים בעניין ועושים חלקים שלמים בצורה דומה.
ההגנה אינה מסתכמת בקוד אלא יכולה לחול גם על אפיון המערכת, עיצוב ועוד. יתרה מכך, לא כל אלמנט שהוזכר ניתן להגן עליו, זאת כיוון שההגנה לא תעמוד בהכרח במבחן בית משפט ודיני הקניין הרוחני. אך, לכל הפחות שיצוין בהסכם פיתוח האפליקציה ויהווה הרתעה מסוימת. רמת קושי להכניס סעיף לחוזה של בית תוכנה – בינוני
- רמת שירות– חשוב שיהיה כתוב בחוזה מהי רמת הזמינות ואורך הזמן למתן מענה לפתרונות. בייחוד אם אתם עובדים בפרויקט שעתי ותוך כדי פעולה עולים צרכים חדשים, כמו אפיון של פיצ'ר אשר השתנה ברגע האחרון או תיקון דחוף עקב מציאת "באג". וודאו שיש הסדר לזמן טיפול בנושא דחוף.
דגשים לחוזה אשר אתם מנסחים
- חשוב שתבנו שיטת עבודה שנוחה לכם ותפרטו עליה בחוזה. למשל, אם אתם רוצים שירוכזו כל ההערות בשני סבבי תיקונים בכדי לפשט את ממשק העבודה, תציינו זאת בגוף החוזה. זאת בכדי למנוע חילוקי דעות אם יש צורך בתוספת תשלום או לא, כיוון שיכולים לחייב אתכם על סבב תיקונים שני ויכולה להיות מחלוקת על מהו סבב תיקון במידה ואתם "מטפטפים" הערות לתיקון.
- אחריות – תשתדלו לציין ולהבהיר בחוזה מה כלול באחריות ולא יישא בצידו תוספת תשלום לנותן שירות, זאת בכדי למנוע חילוקי דעות בהמשך מתי יש להוסיף כסף לפיתוח ומתי לא. בסופו של יום אתם עובדים עם תקציב מסוים לטובת פיתוח המוצר ואתם רוצים לדעת מה תקבלו בגמר התהליך.
לעתים, יש חברות פיתוח שעובדות במחיר פיקס ושומרות על האפשרות שבמידה ולאחר גמר הפרויקט יש בעיות אז הלקוח ישלם תוספת. נסו להתעקש ולדרוש אחריות ללא עלות עבור תקלה שתהיה במערכת אשר קשורה לקוד של פיתוח האפליקציה.
בתי תוכנה לא אוהבים את הסעיף הזה כיוון שהוא חושף אותם לעבוד ב"חינם", וכאמור התעריף השעתי שלהם הוא כמה מאות שקלים וכל זמן שהם עובדים ב"חינם" הוא הפסד נקי מבחינתם. עם זאת, רוב המתכנתים עובדים בתעריף שעתי, עובדים מהר ומנסים לסיים כמה שיותר מהר את פיתוח האפליקציה.
בד"כ מסיימים עוד לפני ההערכה שציינו בתחילת הפרויקט של פיתוח האפליקציה. ההסדר ביניים הוא מחיר שעתי ולהגביל למחיר מקסימום שממנו חלק מהעבודה תושלם ללא עלות. זאת בכדי שתהיו מבוטחים בצורה מסוימת להוצאה כספית מקסימלית על הפיתוח האפליקציה. כלי למשא ומתן טוב הוא הצגת פיתוח האפליקציה כפרויקט ארוך טווח, עם מוצר חדשני ומעניין.
הרבה פעמים חברות פיתוח אוהבות לעבוד על מוצר שהן מאמינות בו ואולי תתפשרנה על חלק מהדברים. עם זאת, שימו לב כי לעתים קרובות ויש להתיישר למה שמקובל בשוק בכדי לא לאבד חברת פיתוח אפליקציות איכותית.
- תקופת אי התחרות – קשה להכניס סעיף כזה וגם לא תמיד אפשרי כיוון שהוא פוגע בחופש העיסוק. גופים אחרים יכולים בגמר הפרויקט להציע למתכנת עבודה בתחום דומה ועל כן הוא לא יכול להגביל את עצמו. אבל מה שכן ניתן לעשות הוא להגביל שימוש בארכיטקטורה שנבנתה בצורה ייחודית עבורכם והעתקת קטעי קוד שלמים ממנה. כך זמן הפיתוח על המוצר הדומה יתארך ויהיה לכם יתרון של ראשוניות בשוק.
- האפשרות לביטול ההסכם מצדכם – נסו לגרום למצב שרק אתם יכולים לבטל את ההסכם למרות שידרשו ממכם את עיקרון ההדדיות בעניין זכות ביטול ההסכם. במידה וגם לבית התוכנה יש אפשרות לביטול ההסכם, הסדירו את העברת הידע והחפיפה למחליף שלו באופן מסודר ככל שיידרש. זאת בכדי שלא תישארו עם קוד כתוב שאין אף אחד שימשיך אותו ואשר מבין אותו.
- הכפיפו את הלו"ז של הגשת הפיצ'רים המוכנים בהתאם ללו"ז של שחרור המוצר שלכם בתוספת מקדמי הגנה של כמה שבועות בהם תוכלו לעשות QA על התוצר ולהספיק לעשות סבבי תיקונים וזאת שתצאו עם מוצר כמה שיותר בשל לשוק.
ברגע שאתם מנסחים את ההסכם, המשא ומתן נפתח מהרף שאתם בחרתם ולכן הסיכוי שתקבלו בסופו של יום חוזה ששומר על האינטרסים שלכם וחושף אתכם לפחות סיכון, גבוה יותר. זכרו, אתם מכתיבי התנאים והיוזמים בכל העניין כי בסופו של יום אתם משלמים עבור השירות. נכון שיש תחרות על ספקים טובים אבל נסו לשמור על האינטרסים של המיזם שלכם לאורך זמן.
נסו לא להגיע למצב בו אתם בפרויקט פיתוח אפליקציה שנמתח ונמתח ומושקעים בו כספים ללא סוף כיוון שההסכם לא הסדיר נושאים חשובים בעבודה מול חברת הפיתוח.
הכתוב אינו מהווה ייעוץ משפטי ויש להתייעץ עם עו"ד באופן פרטני טרם קבלת החלטות לפעולה.
הכותב הוא עו"ד גבריאל בנטוב – מלווה יזמים, סטארטאפים ועסקים אינטרנטיים.
[devleadb]
