איך עושים כסף מאפליקציה? כל הדרכים ליצירת רווח מאפליקציה

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

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

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

7 דרכים המייצרות רווח מאפליקציה

1. רכישות בתוך האפליקציה

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

באופן זה המשתמשים מקבלים ערך מהאפליקציה, מתרגלים להשתמש בה ויוצרים תלות באפשרויות שהיא מספקת להם.

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

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

2. גרסת ניסיון

במקרים מסוימים (שנגע בהם בהמשך) היינו רוצים לאפשר שימוש קבוע באפליקציה רק כאשר המשתמש משלם. מנגד, הסבירות שמשתמש ישלם על האפליקציה לפני שהוא מנסה אותה וחווה את הערך שהיא יכולה להעניק לו, נמוכה.

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

3. אפליקציה בתשלום חד פעמי

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

מכירה מסוג זה נמצאת בקטגוריה שהוזכרה בגרסת הניסיון ויש בה אתגרים של מכירה ישירה. כדי להתגבר על אתגר זה ניתן לבצע אופטימיזציות בחנות האפליקציות (סרטון, צילומי מסך, דירוג, טקסטים) ולשלב גרסת ניסיון חינמית.

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

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

4. מנויים \ רישיונות שימוש

ניתן לייצר רווח חוזר ע"י מכירת מנויים או רישיונות שימוש כך שכל לקוח ישלם על זכות השימוש באפליקציה אחת לתקופה. גם במכירה מסוג זה מומלץ לתת למשתמשים תקופת ניסיון באפליקציה לפני בקשת התשלום.

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

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

5. גביית עמלות

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

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

6. תשלום על פרסום עסקים

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

7. הצגת פרסומות מרשתות פרסום

אפשרות נוספת, המתאימה בעיקר לאפליקציות תוכן בתחילת דרכן (לפני שסגרו עסקאות פרסום ממוקדות), היא הצגת פרסומות באמצעות רשתות מודעות פרסום גלובליות (כדוגמת AdMob של גוגל או AirPush). היתרון בהן הוא קלות ופשטות העבודה, אך בטווח הרחוק יהיה קשה לממש את הרווח הפוטנציאלי הגלום באפליקציה.

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

[devleadb]

אחת ולתמיד: אפליקציה היברידית או אפליקציית Native?

רבות דובר על פיתוח אפליקציה היברידית מול פיתוח אפליקציית Native ועל היתרונות והחסרונות של כל אחת מהאפשרויות.

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

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

מהן אפליקציות היברידיות ואפליקציות Native?

לפני שנצלול לעומק הסוגיה, נתחיל בהסבר המושגים:

אפליקציה היברידית

אפליקציה היברידית היא אפליקציה הכתובה בקוד יחיד ויכולה לפעול במספר מערכות הפעולה שונות. כלומר, ניתן לכתוב קוד לאפליקציה פעם אחת ולהשתמש בו כדי להריץ את האפליקציה בAndroid ובiOS.

סוג אחד של אפליקציות היברידיות הן אפליקציות המשתמשות בטכנולוגיות אינטרנט, HTML5, Javascript, CSS ומסוגלות לפעול במכשירי Android ובמכשירי iOS.

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

אפליקציית Native

אפליקציית Native היא אפליקציה המפותחת עבור מערכת הפעלה מסוימת וברוב המקרים תוכל לפעול רק עליה. כלומר, אפליקציית Native שתפותח לiPhone לא תוכל לרוץ על Android, אלא אם פותחה לאפליקציה גרסת Android נפרדת.

מהסיבה הזו, כדי לפתח אפליקציה שתוכל לפעול במכשירי iOS וגם במכשירי Android, יהיה צורך בפיתוח 2 אפליקציות נפרדות, אחת לכל מערכת הפעלה.

דוגמה לאפליקציית Native פופולרית שפועלת רק במכשירי Android היא SwiftKey Keyboard.

למה הבחירה בין שתי האפשרויות קריטית?

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

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

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

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

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

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

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

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

אפליקציה היברידית

יתרונות

  • זמני פיתוח אפליקציה קצרים יותר. באפליקציה היברידית כותבים קוד יחיד עבור Android וiOS. כתוצאה מכך, זמני פיתוח האפליקציה מתקצרים.
  • עלויות פיתוח אפליקציה מופחתות. מאחר וזמני פיתוח האפליקציה מתקצרים, שעות העבודה שתשלמו עליהם הדרושות להשלמת העבודה קטנות, כלומר, האפליקציה תעלה פחות כסף.
  • תוכלו להשתמש ברוב יכולות המכשיר. בזכות טכנולוגיות מגשרות, ניתן להשתמש ברוב הרכיבים שהמכשיר מציע: GPS, Bluethooth, מצלמה, הודעות Push, שליחת SMSים, NFC, Accelerometer ועוד.

חסרונות

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

אפליקציית Native

יתרונות

  • ביצועים מצוינים. מאחר והאפליקציה כתובה בשפת תכנות המתאימה למכשיר, היא מדברת עם המכשיר בשפה הטבעית (Native) עבורו. לכן, ביצועי האפליקציה יוכלו להגיע לרמה המקסימלית האפשרית.
  • חדשנות. אפליקציית Native יכולה להשתמש בטכנולוגיות החדשות ביותר שיוצאות לשוק. לדוגמה, כאשר אפל השיקה את מסך המגע שרגיש ללחיצות חזקות, אפליקציית Native יכלה להשתמש בו באופן מיידי.

חסרונות

  • זמני פיתוח ארוכים. כפי שראינו מקודם, כדי שהאפליקציה שלנו תהיה אפליקציית Native שתפעל בAndroid ובiOS, יהיה עלינו לפתח 2 גרסאות שונות לאפליקציה. פיתוח 2 אפליקציות שונות הוא ארוך וממושך יותר מפיתוח אפליקציה אחת, ולכן, זמני הפיתוח יהיו ארוכים יותר.
  • עלויות גבוהות. זמני פיתוח האפליקציה ארוכים משמעותם עלויות פיתוח גבוהות. בנוסף לעלות הפיתוח הראשוני, שעות העבודה על תחזוקת האפליקציה גבוהות יותר ולכן גם לתחזוקת אפליקציית Native עבור מספר מערכות הפעלה תהיה עלות גבוהה.

כך תבחרו את שיטת העבודה עבור האפליקציה שלך

כדי שתוכלו לקבל את ההחלטה הנכונה עבור האפליקציה שלכם, שאלו את השאלות הבאות:

  • האם התקציב שלכם מספיק לפיתוח Native?
  • האם האפליקציה דורשת עיבודים כבדים? משחק, אנימציות, עיבוד מידע וכדומה.
  • מהי רמת דחיפות יציאת האפליקציה לשוק?

[devleadb]

האם לפתח אפליקציה במיקור חוץ או להקים צוות פיתוח?

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

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

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

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

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

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

פיתוח אפליקציה במיקור חוץ Vs פיתוח אפליקציה עם צוות פיתוח

Time To Market

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

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

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

כאשר ישנו צורך ביציאה מהירה לשוק, לרוב העדיפות תהיה פיתוח בבית תוכנה חיצוני.

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

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

האם המוצר טכנולוגי?

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

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

מהעבר השני – אפליקציה כמו Waze אשר דורשת עבודה של מפתחים רבים לכל אורך הדרך, ככל הנראה תצריך פיתוח in-house.

כאשר המוצר הוא טכנולוגי ומצריך פיתוחים נוספים – בסופו של דבר ההמלצה היא לעבור לפיתוח in-house, אך האם זה אומר שכדאי להתחיל את הפיתוח בתוך החברה כבר מהיום הראשון? לא בטוח.

מהות הפיתוח הנוכחי

דבר נוסף שכדאי לקחת בחשבון הוא מטרת הפיתוח הנוכחי – האם מדובר בפיתוח האפליקציה השלמה, האם מדובר ב-MVP, או שאולי אנו מפתחים אפליקציית דמו לגיוס משקיעים.

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

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

במידה ואנו נמצאים לאחר בניית ה-MVP וכבר רוצים לצאת לפיתוח המוצר הגדול, בהנחה ומדובר במוצר טכנולוגי אשר ידרוש פיתוחים רבים בהמשך – עדיף לפנות לאפיק של פיתוח in-house.

שימור הידע

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

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

במצב זה, ההמלצה תהיה להתחיל את הפיתוח in-house ולא לפנות לחברת פיתוח חיצונית.

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

כיוון שסופן של אפליקציות כאלה הוא לעבור לפיתוח in-house, יש לוודא מלכתחילה שקיימת האפשרות לעשות זאת בעתיד בצורה חלקה.

תקציב

נושא התקציב יכול לבלבל, כיוון שפיתוח in-house יכול להיות זול יותר במקרים מסוימים, ובמקרים אחרים יקר יותר מעלות פיתוח בחברה חיצונית.

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

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

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

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

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

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

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

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

[devleadb]

ספרים ליזמים: 9 ספרים שכל יזם חייב לקרוא

מה הייתם מוכנים לתת תמורת פגישה עם לארי פייג' או שיחת טלפון עם אילון מאסק? ככל הנראה הרבה.

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

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

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

ריכזתי עבורכם ספר אחד מומלץ לכל נושא בו תהיה לכם נגיעה.

ספר על הצגת רעיון והעברת מסרים

Pitch Anything: An Innovative Method for Presenting, Persuading, and Winning the Deal

כבעלים של רעיון חדשני עליכם לדעת להעביר אותו באופן חד וברור ולרתום אנשים לדרך שלכם. מחבר הספר, אורן קלאף, גייס בשנותיו כיזם מעל 400 מליון דולר ומלמד את המתכון המנצח להצגת רעיון עסקי.

ספר על גיוס כספים

Venture Deals: Be Smarter Than Your Lawyer and Venture Capitalist

רוב החברות אשר צומחות בקצב מהיר גייסו כספי השקעות. מחברי הספר, בראד פלד וג'ייסון מנדלסון, היו מעורבים במאות עסקאות של השקעות במשך 20 שנה.

בספר הם מסבירים על מסמך תנאי העסקה (Term Sheet) מבחינה כלכלית ומבחינת שליטה בחברה, מציעים אסטרטגיות להשגת עסקה הוגנת ומציגים את הקשיים שעלולים לצוץ.

ספר על שיווק

Traction: How Any Startup Can Achieve Explosive Customer Growth

גבריאל ויינברג וג'סטין מיירס מציגים בתחילת הספר את הגישה הרזה (Lean) לשיווק מוצר – Bullseye (פגיעה ישירה), המתיישרת עם שיטת הסטארט-אפ רזה (Lean Startup) לפיתוח מוצרים.

בחלקו השני של הספר הם מציגים 19 ערוצי שיווק שונים, מסבירים אותם ונותנים דוגמאות מחברות מוצלחות שהשתמשו בערוץ אחד או יותר והשיגו גדילה.

ספר על ניהול מוצר

Running Lean: Iterate from Plan A to a Plan That Works

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

האסטרטגיה המוצגת מלמדת כיצד להגיע ל Product / Market Fit באמצעות שיטת הסטארט-אפ הרזה (Lean Startup), פיתוח לקוחות (Customer Development) והתחלת מיזם ללא השקעה חיצונית.

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

ספר על מכירות

80/20 Sales and Marketing: The Definitive Guide to Working Less and Making More

ספר זה מציג גישה בה תוכלו לחסוך 80% מהזמן ומהכסף שתשקיעו בשיווק ומכירות באמצעות התמקדות ב20% משוק היעד של העסק שלכם.

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

ספר על ניהול חברה

Scaling Up: How a Few Companies Make It…and Why the Rest Don't

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

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

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

ספר על משא ומתן

Negotiation Genius: How to Overcome Obstacles and Achieve Brilliant Results at the Bargaining Table and Beyond

כיזמים, תקחו חלק בתהליכי משא ומתן רבים מול משקיעים, לקוחות B2B, שותפים וספקים.

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

ספר על ניהול מוצר

Hooked: How to Build Habit-Forming Products

מהי הסיבה שחלק מהמוצרים מצליחים להניע אותנו ומושכים את תשומת הלב שלנו? ניר אייל עונה על השאלה ומסביר את מודל הלכידה (Hook Model) – תהליך בן 4 שלבים שחברות מוצלחות מיישמות כדי להניע את המשתמשים למעורבות, ליצור אצלם הרגלי שימוש במוצר ולאהוב אותו.

ספר על קבלת החלטות

Thinking, Fast and Slow

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

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

[devleadb]

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

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

האינטראקציה הראשונית עם הספק

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

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

בהמשך הדרך, במידה ותרצו להחליף בית תוכנה, תצטרכו להשקיע משאבים רבים ב"העברת השרביט".

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

זכרו: המחיר הזול ביותר לא בהכרח ישתלם. מהירות העבודה, התקשרות והטעויות בדרך שווים כסף.

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

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

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

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

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

הכתוב אינו מהווה ייעוץ משפטי ויש לפעול על בסיס ייעוץ פרטני.

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

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

    פיגור ביעדים יכול לעלות לחברה שלכם כסף רב, לכן חשבו כמה פיגורים בזמנים עולים לחברה שלכם וכך תוכלו לדעת את הפיצוי שיש לנקוב על כל יום איחור. רמת קושי להכניס סעיף לחוזה של בית תוכנה – בינוני

  • קניין רוחני: עלות פיתוח אפליקציה היא גבוהה והתקציב שלכם אינו בלתי מוגבל. אם המוצר שלכם ייחודי, מגיע לכם שהקוד יהיה הקניין שלכם ושיהיה בכל רגע נתון זמין עבורכם. במידה וקיימת ארכיטקטורה ייחודית שנעשתה במיוחד עבורכם נסו לציין באופן מפורש שהקוד הייחודי שייך רק לכם. כלומר, חלקי קוד שלמים הייחודים למוצר שלכם לא יכולים להיות ממוחזרים או מועתקים ללקוח אחר שמתחיל לעבוד עם חברת פיתוח האפליקציות.

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

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

  • רמת שירות– חשוב שיהיה כתוב בחוזה מהי רמת הזמינות ואורך הזמן למתן מענה לפתרונות. בייחוד אם אתם עובדים בפרויקט שעתי ותוך כדי פעולה עולים צרכים חדשים, כמו אפיון של פיצ'ר אשר השתנה ברגע האחרון או תיקון דחוף עקב מציאת "באג". וודאו שיש הסדר לזמן טיפול בנושא דחוף.

דגשים לחוזה אשר אתם מנסחים

  • חשוב שתבנו שיטת עבודה שנוחה לכם ותפרטו עליה בחוזה. למשל, אם אתם רוצים שירוכזו כל ההערות בשני סבבי תיקונים בכדי לפשט את ממשק העבודה, תציינו זאת בגוף החוזה. זאת בכדי למנוע חילוקי דעות אם יש צורך בתוספת תשלום או לא, כיוון שיכולים לחייב אתכם על סבב תיקונים שני ויכולה להיות מחלוקת על מהו סבב תיקון במידה ואתם "מטפטפים" הערות לתיקון.
  • אחריות – תשתדלו לציין ולהבהיר בחוזה מה כלול באחריות ולא יישא בצידו תוספת תשלום לנותן שירות, זאת בכדי למנוע חילוקי דעות בהמשך מתי יש להוסיף כסף לפיתוח ומתי לא. בסופו של יום אתם עובדים עם תקציב מסוים לטובת פיתוח המוצר ואתם רוצים לדעת מה תקבלו בגמר התהליך.

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

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

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

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

  • תקופת אי התחרות – קשה להכניס סעיף כזה וגם לא תמיד אפשרי כיוון שהוא פוגע בחופש העיסוק. גופים אחרים יכולים בגמר הפרויקט להציע למתכנת עבודה בתחום דומה ועל כן הוא לא יכול להגביל את עצמו. אבל מה שכן ניתן לעשות הוא להגביל שימוש בארכיטקטורה שנבנתה בצורה ייחודית עבורכם והעתקת קטעי קוד שלמים ממנה. כך זמן הפיתוח על המוצר הדומה יתארך ויהיה לכם יתרון של ראשוניות בשוק.
  • האפשרות לביטול ההסכם מצדכם – נסו לגרום למצב שרק אתם יכולים לבטל את ההסכם למרות שידרשו ממכם את עיקרון ההדדיות בעניין זכות ביטול ההסכם. במידה וגם לבית התוכנה יש אפשרות לביטול ההסכם, הסדירו את העברת הידע והחפיפה למחליף שלו באופן מסודר ככל שיידרש. זאת בכדי שלא תישארו עם קוד כתוב שאין אף אחד שימשיך אותו ואשר מבין אותו.
  • הכפיפו את הלו"ז של הגשת הפיצ'רים המוכנים בהתאם ללו"ז של שחרור המוצר שלכם בתוספת מקדמי הגנה של כמה שבועות בהם תוכלו לעשות QA על התוצר ולהספיק לעשות סבבי תיקונים וזאת שתצאו עם מוצר כמה שיותר בשל לשוק.

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

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

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

הכותב הוא עו"ד גבריאל בנטוב – מלווה יזמים, סטארטאפים ועסקים אינטרנטיים.

[devleadb]

 

מהו תהליך אפיון אפליקציה ולמה הוא חלק בלתי נפרד מתהליך פיתוח האפליקציה?

אתחיל בשאלה: מה משותף לפיתוח אפליקציה ולבניית גורד שחקים?

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

בתחום פיתוח האפליקציות אנחנו קוראים לזה – אפיון.

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

מסמך האפיון מכיל שני חלקים עיקריים:

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

בגמר האפיון, תוכלו לדעת באופן יחסית מדויק כמה עבודה (ועלות) תידרש כדי לפתח את האפליקציה.

חשיבות האפיון לתהליך פיתוח האפליקציה

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

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

התחומים בהם האפיון נוגע והשפעתם על הפרויקט:

  • השפעה על המודל העסקי: תכנון הדרך בה האפליקציה תייצר רווח. ברוב האפליקציות, בחירה בדרך יצירת רווח אחת או אחרת משנה או מוסיפה רכיבים לאפליקציה. כך לדוגמה, אם תבחרו לייצר רווח באמצעות גביית עמלות, יהיה צורך בפיתוח ממשק שיאפשר לעקוב אחרי העמלות הנצברות לפי העסקאות שנעשו, או לחלופין, לעבוד עם מערכת אוטומטית. לעומת זאת, אם תבחרו לייצר רווח דרך מכירת מנויים למערכת, יהיה צורך בפיתוח או בהתממשקות למנגנון המאפשר זאת.
  • השפעה על העיצוב: בתהליך האפיון מגדירים את הרכיבים הגרפיים השונים באפליקציה (כפתורים, תפריטים, טפסים) ומשרטטים את המסכים שלה. על בסיס שרטוטי המסכים והאופן שבו הם מתקשרים, יוצרים בשלב מאוחר יותר את עיצוב האפליקציה.
  • השפעה על איכות האפליקציה: בפיתוח אפליקציות, כמו ברוב תהליכי פיתוח תכנה, קיים אזור האחראי על אבטחת איכות האפליקציה, QA – Quality Assurance. אנשי הQA משתמשים באפיון כדי להכין מסמכי בדיקות ובשלב מאוחר יותר של תהליך הפיתוח הם משתמשים במסמכים אלו כדי לוודא שהאפליקציה נקייה מתקלות.
  • בדיקת ההתכנות הטכנולוגית: מבצעים מחקרים ובדיקות כדי לוודא שניתן לבצע את כלל הדרישות של האפליקציה. אמחיש את הסיכון באי ביצוע בדיקת התכנות טכנולוגית: תחשבו על סיטואציה בה הייתם מבצעים אפיון, מתחילים לבנות אפליקציה, ובאמצע הפיתוח אחרי שהשקעתם משאבים רבים, חברת פיתוח האפליקציות הייתה מבשרת לכם שיש קושי או מגבלה טכנולוגית לפיתוח רכיב מסוים באפליקציה. במקרה הטוב, אם עלה קושי שלא נצפה מראש בגלל אי-עשיית מחקר טכנולוגי, חברת הפיתוח עשויה לדרוש תשלום נוסף ולפגוע בתכנון התקציב שלכם. במקרה הפחות טוב, בו מדובר על מגבלה טכנולוגית לפיתוח רכיב מרכזי באפליקציה, הפרויקט כולו עשוי להיכשל אחרי שהושקעו בו מאמצים ומשאבים רבים, שיכלו להיחסך במידה והיו מתבצעים מחקרים מקיפים בשלב מוקדם.
  • השפעה על תשתיות הפיתוח: מלמידת דרישות האפליקציה ניתן לתכנן בצורה נכונה את תשתיות הפיתוח. תכנון תשתיתי מסודר יוכל למנוע תקלות, לעזור לאפליקציה לעבוד מהר יותר ולתמוך בגידול כמות המשתמשים.

עלות האפיון

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

טווח העלויות של ביצוע אפיון יכול לנוע בין 14,000 – 8,000 ש"ח עבור אפליקציה קטנה, 14,000 – 20,000 ש"ח עבור אפליקציה בגודל בינוני, ועבור אפליקציה גדולה העלות יכולה לנוע בין 20,000 ש"ח ל30,000 ש"ח ולעתים יותר, תלוי בגודל ובמורכבות האפליקציה.

סיכום יתרונות אפיון האפליקציה

כעת נסכם את היתרונות בביצוע אפיון לאפליקציה:

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

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

מוזמנים להוריד מסמך אפיון אפליקציה לדוגמה שהכנו.

[devleadb]

מילון המונחים ליזם האפליקציות

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

MVP – Minimal Viable Product

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

אפיון אפליקציה 

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

Quality Assurance :QA

תהליכים וכלים אשר מטרתם היא הבטחת איכות המוצר המוגמר, במקרה שלנו – האפליקציה שאנחנו מפתחים. בתוכנה, תהליך הQA נועד כדי לבדוק שהמוצר נקי מתקלות בצד השרת ובצד הלקוח.

אפליקציית Native

אפליקציית Native היא אפליקציה המפותחת עבור מערכת הפעלה מסוימת וברוב המקרים תוכל לפעול רק בה. כלומר, אפליקציית Native שתפותח לiPhone לא תוכל לרוץ על Android, אלא אם פותחה לאפליקציה גרסת Android נפרדת.

אפליקציית Hybrid

אפליקציה הכתובה בקוד יחיד ויכולה לפעול במספר מערכות הפעולה שונות. כלומר, ניתן לכתוב קוד לאפליקציה פעם אחת ולהשתמש בו כדי להריץ את האפליקציה בAndroid ובiOS.

צד לקוח – Client Side

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

צד שרת – Server Side

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

Application Programming Interface :API (בין צד שרת ולקוח)

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

User Experience :UX – חוויית משתמש

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

User Interface :UI – ממשק משתמש

החלק בו המשתמש מתקשר עם המערכת. במערכות ממוחשבות (אפליקציות, תוכנות ואתרים) בדרך כלל מדובר בחלק הויזואלי של המערכת. תהליך עיצוב ממשק משתמש נועד כדי לתכנן דרך שתאפשר למשתמשים לבצע את הפעולות במערכת בנוחות ובפשטות.

Wireframe

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

Mock-up

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

Database / DB

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

Integrated Development Environment :IDE

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

למדתם את מילון המונחים ליזם הנמצא בתהליך פיתוח אפליקציה.

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

[devleadb]

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

אם הנך יזם הנמצא בתחילת דרכו לפיתוח אפליקציה, ככל הנראה עלתה לך השאלה: "כמה עולה לפתח אפליקציה?", ונתקלת בקושי לענות עליה.

במאמר הקרוב אענה על השאלה, ונבין איך חברות פיתוח אפליקציות מחשבות את עלות האפליקציה, מאחורי הקלעים.

עלות פיתוח אפליקציה

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

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

מהן ההשלכות של הערכת שעות פיתוח לא מדויקות?

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

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

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

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

  • ניהול פרויקט: תפקיד מנהל הפרויקט הוא לגרום להצלחת הפרויקט. הוא אחראי על עמידה בלוח הזמנים ועל התוצר הסופי. מנהל פרויקט טוב יצור תהליך פיתוח יעיל ואפקטיבי וידע לסדר את כלל החלקים בתהליך הפיתוח לכדי הצלחה. עבודה הרמונית של כלל האזורים בתהליך תאפשר לאפליקציה להגיע לרמת איכות מקסימלית ותוכל לחסוך מכם עבודת פיקוח צמודה, דאגה מאיחור בזמנים או מתוצר לא איכותי.
  • עיצוב וחוויית משתמש: עיצוב מושך וחוויית משתמש נוחה וברורה ישפרו את אחוז שמירת המשתמשים ואת רמת החזרה שלהם לאפליקציה. ככל שהם ישתמשו יותר באפליקציה, גדל הסיכוי שהם יבצעו את הפעולות שאתם מכוונים אליהן, כמו רכישת מנוי, גרסת Premium, רכישת מוצרים, צפייה בפרסומות, חיזוק מותג או כל פעולה אחרת היוצרת לכם רווח, כלכלי או לא.
  • בדיקות איכות: אנשי בדיקות התכנה \ QA, מלווים את הפרויקט משלב האפיון ועד לאחר גמר הפיתוח ומוודאים בכל שלב שאין תקלות. בשלב אפיון האפליקציה הם כותבים מסמך בדיקות ובשלבים מאוחרים יותר הם מבצעים בדיקות על מגוון מכשירים כדי לוודא שהאפליקציה נקייה מתקלות.
  • פיתוח: מפתחי האפליקציה לומדים את האפיון ורושמים את הקוד הדרוש כדי שהאפליקציה תעמוד בדרישות. הם מקימים את מסד הנתונים (מאגר המידע של האפליקציה), מפתחים את צד השרת וכותבים את צד הלקוח של האפליקציה לפי האפיון והעיצוב (צד הלקוח היא האפליקציה הנמצאת במכשיר של המשתמש וצד השרת הוא הקוד שיושב בענן ומבצע פעולות לפי בקשות המגיעות מהאפליקציה). אם יש תקלות או אי התאמות לדרישות, המפתחים עובדים ביחד עם מנהל הפרויקט ואנשי הQA כדי להבין מה הם התיקונים הדרושים ומבצעים אותם.

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

  • מנהל פרויקט: 200-350 ש"ח לשעה, מהווה כ- 10%-15% מזמן העבודה.
  • מעצב ומאפיין חוויית משתמש: 150-300 ש"ח לשעה, מהווה כ- 10%-20% מזמן העבודה.
  • בודק תכנה: 150-250 ש"ח לשעה, מהווה כ- 15%-25% מזמן העבודה.
  • מפתח אפליקציות: 200-450 ש"ח לשעה, מהווה כ- 45%-65% מזמן העבודה.

אז כמה עולה לפתח אפליקציה? – שיטות התמחור

לאחר שהכרנו את הבסיס לחישוב עלות פיתוח אפליקציה והבנו את המרכיבים השונים בתהליך הפיתוח, אציג את החלק בו (בדרך כלל) יש לנו בחירה בין 2 מסלולים – שיטת התמחור.

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

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

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

  1. מחיר קבוע – Fixed Price.
  2. תשלום לפי שעות עבודה שהתבצעו בפועל.

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

עלות פיתוח אפליקציה  – עבודה לפי מחיר קבוע

חברת הפיתוח מגישה הצעת מחיר כוללת לפיתוח המוצר (על בסיס אפיון האפליקציה) ומתחייבת לפתח אותו בעלות המוצעת.

מה קורה בפועל? החברה מעריכה את שעות העבודה ומוסיפה עליהן מרווח ביטחון של 20%-40%. לדוגמה: פיתוח אפליקציה מסוימת מוערך ב 500 שעות, חברת הפיתוח גובה 350 ₪ לשעה והגדירה מרווח בטיחות של 30% לפרויקט (לשם הפשטות, אני מתעלם מעלויות ניהול הפרויקט, עיצוב ובדיקות התכנה).

בחישוב מהיר, נגיע לעלות אפליקציה של 227,500 ₪.

יתרונות

  • מזעור סיכונים: בתור בעלים של חברה צעירה, אחד מהתפקידים שלכם הוא למזער סיכונים. בעבודה לפי מחיר קבוע, תוכלו להשיג זאת מאחר והסיכון שהפרויקט יחרוג מהתקציב הוא על חברת הפיתוח.
  • יעילות ועמידה בזמנים: כאשר יש לחברת הפיתוח מסגרת תקציבית מוגדרת כדי להגיע לתוצר, היא תייעל תהליכים פנימיים כדי להגיע למוצר איכותי מוגמר בזמן ומבלי לחרוג מהתקציב. עם זאת, לעתים דבר זה יכול לגרום לחברה "לחסוך" בחלקים שלא צריך לחסוך בהם ולגרור פגיעה במוצר. כדי למנוע את המצב הזה, או לפחות למזער אותו, אני ממליץ לכם לבקש בגמר תהליך האפיון (לפני תחילת הפיתוח) מסמך בדיקות שנכתב ע"י בודק תכנה מקצועי אשר יהווה מסמך אליו החברה מתחייבת. כלומר, החברה תתחייב שתהליך הפיתוח יגמר אך ורק אם כלל הבדיקות במסמך עובדות כהלכה.

חסרונות

  • פחות גמישות במהלך הפיתוח: במידה ותבקשו לבצע שינויים במהלך הפיתוח או לאחריו, תהליך הביצוע שלהם יהיה קשה מאחר ועל כל שינוי החברה תגיש הצעת מחיר ויתנהל משא ומתן. כאשר אני לוקח בחשבון שחברת סטארט-אפ חייבת להיות גמישה כדי לא להיסגר בטרם עת, עבודה לפי מחיר קבוע עלולה לגרום לתהליך פיתוח האפליקציה להוות צוואר בקבוק במיזם.
  • קבלת מוצר פחות טוב: במידה ותוך כדי פיתוח עולים למפתחים רעיונות או פיצ'רים מעניינים למוצר, בדרך כלל הם לא יציעו אותם, כי כל שינוי עשוי לשבש את הפרויקט. משמע, החברה תעדיף "לא להגדיל ראש".
  • עלות הביטחון: חברת פיתוח האפליקציות היא עסק, ועסקים נוטים למזער סיכונים. במחיר הקבוע מגולמים מרווחי הבטיחות שחברת הפיתוח לוקחת, בדרך כלל בין 20% ל40%. לכן, לקבלת הביטחון שמחיר האפליקציה לא יחרוג מהתקציב יש עלות.

מחיר פיתוח אפליקציה ייקבע על בסיס עבודה לפי שעה

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

התשלום על הפיתוח מחושב לפי כמות השעות שהושקעה בפועל.

מאחר ואין החייבות לעלות הכוללת של המוצר, יש בשיטה זו קושי בתכנון תקציבי. כדי לבצע היערכות תקציבית טובה יותר, אני ממליץ לשמור כ30% מהערכת עלות פיתוח האפליקציה בצד למקרה ויהיו חריגות.

בדרך זו תוכלו למזער את הסיכון שיהיו הפתעות תקציביות.

יתרונות

  • שקיפות: עבודה לפי שעה מצביעה על רמת השקיפות ביניכם ובין חברת הפיתוח. כשעובדים לפי שעה, בדרך כלל החברה תעדיף לעבוד עם עדכונים תכופים יותר כדי להראות ללקוח שיש התקדמות בעבודה ושהשעות שהושקעו בפיתוח מנוצלות היטב.
  • מעורבות: עבודה בדרך זו מאפשרת ומעודדת מעורבות שלכם, הלקוחות, בכלל שלבי הפיתוח.
  • גמישות: מאחר והעבודה היא על בסיס שעתי, לא יהיה צורך במשא ומתן, הצעת מחיר או חתימה על חוזים כאשר תרצו לבצע שינויים או להוסיף רכיבים. בכך, מתאפשרת עבודה גמישה וקולחת שמביאה לתוצר טוב יותר ומתאימה לרמת הגמישות של החברה שלך.
  • שותפים, לא ספקים: כאשר עובדים לפי שעה, לחברה אין אינטרסים להימנע משינויים או מתוספות, דבר אשר משנה את דרך השיח וצורת ההתקשרות. חברת הפיתוח יכולה לשתף את הלקוח ברעיונות לפיצ'רים מעניינים או שינויים חשובים שכדאי לבצע ובכך לשפר את המוצר. עם זאת, אתם צריכים להיות בבקרה ולבחון את רלוונטיות ההצעות שיגיעו מחברת הפיתוח, כדי לוודא שהן מיושרות עם האסטרטגיה של החברה שלכם.
  • משלמים על מה שמקבלים: במידה והמחיר לשעה תואם את איכות, קצב ורמת העבודה של כלל הגורמים המעורבים בתהליך, אתם תקבלו תמורה הוגנת עבור שעות העבודה, ולא תשלמו על מרווחי ביטחון.

חסרונות

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

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

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

מהו תהליך פיתוח אפליקציה נכון וכיצד תדאגו שהוא יצליח?

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

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

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

מחזור חיי האפליקציה

נפריד את תהליך פיתוח האפליקציה (המורכב יחסית) למספר שלבים היוצרים את מחזור חיי האפליקציה: אפיון, עיצוב, פיתוח, בדיקות איכות ושחרור גרסה.

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

בין אם אתם נמצאים בתחילת פיתוח האפליקציה ובין אם שחררתם מספר גרסאות, תוכלו ליישם את מחזור חיי האפליקציה.

אפיון האפליקציה בתוך התהליך

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

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

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

עיצוב

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

חשוב להתאים את קווי העיצוב של האפליקציה אל המשתמשים שלה. כך, לדוגמה, יש הבדל בין משתמשים בגילאי 15-20 באפליקציה חברתית לבין לקוחות עסקיים המשתמשים באפליקציה לניהול פיננסי.

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

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

פיתוח האפליקציה

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

לאחר לימוד החומרים, הם יתחילו בתהליך הפיתוח: יקימו את תשתיות האפליקציה ויכתבו את הקוד הדרוש.

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

בדיקות איכות

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

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

שחרור גרסה

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

מאחר ולהעלאת האפליקציה למשתמש של חברה אחרת יש השלכות מיתוגיות שליליות, אני ממליץ לפתוח משתמשים תחת שם החברה שלכם.

העלות הסמלית, 25$ חד פעמיים לחנות הAndroid – Google Play, ו100$ שנתיים לApple – App Store, משתלמת.

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

טיפ פיתוח אפליקציה: מאחר ולApple לוקח זמן לאשר אפליקציות בחנות, העלו את האפליקציה לApp Store כשבועיים לפני זמן ההעלאה המתוכנן ל Google Play.

בונוס: 5 טיפים לניהול תהליך פיתוח אפליקציה נכון

כדי שתצליחו בפיתוח האפליקציה, הוספתי בונוס מיוחד ושימושי:

  1. דברו עם משתמשים פוטנציאליים. לכל אורך מחזור החיים של האפליקציה, הציגו למשתמשים פוטנציאליים את הרעיון ונסו להבין מהו הצורך האמתי שלהם. כאשרו תבינו אותו, תוכלו לפתח להם אפליקציה שתתן פתרון טוב יותר.
  2. תפתחו מוצר ראשוני קטן. אין צורך בפיתוח כלל הרכיבים והיכולות האפשריות בגרסה הראשונית של האפליקציה. אחרת, היא תצא לשוק באיחור ובעלות גבוהה.
  3. הקפידו על מחזור חיי האפליקציה. אל תתחילו פיתוח לפני שהאפיון נסגר, התחילו את כתיבת הבדיקות מיד לאחר שלב האפיון, ואל תשחררו גרסה לפני שהאפליקציה נבדקה אל מול מסמך הבדיקות.
  4. בשלב פיתוח אפליקציה, התעדכנו פעם בשבוע על התקדמות הפרויקט מול המפתחים ועל העמידה בלוחות הזמנים. במידה ואתם מנהלי הפיתוח, ההתעדכנות צריכה להיות על בסיס יומי.
  5. אל תתכננו את השקת האפליקציה בסמוך ליעד סיום הפיתוח. שמרו על מרווח של כ20-30% מזמן הערכת הפיתוח, רוב הפרויקטים מאחרים את לוח הזמנים.

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

[devleadb]