"מפתח אפליקציות" הוא כמה מקצועות
יזם שמחפש מי יפתח את האפליקציה שלו מגלה במהרה שההצעות שהוא מקבל שונות זו מזו פי כמה במחיר. לרוב זה לא בגלל פערי איכות אלא בגלל היקף: הצעה אחת מכסה קידוד בלבד, אחרת כוללת אפיון, עיצוב, שרת ובדיקות. הבנת התפקידים מאפשרת להשוות הצעות באמת, ולדעת מה חסר.
התפקידים בפרויקט אפליקציה
- מאפיין (אנליסט מוצר): הופך רעיון לרשימת מסכים, פעולות ותרחישים. זה התפקיד שמונע את הבעיה היקרה מכולן – פיתוח של מה שלא צריך. ראו אפיון אפליקציה.
- מעצב חוויית משתמש (UX): קובע את זרימת השימוש – מה קורה קודם, איפה המשתמש נתקע, כמה מסכים עד המטרה. עובד על שרטוטי מסכים, לא על צבעים.
- מעצב ממשק (UI): הופך את הזרימה למסכים ממשיים – טיפוגרפיה, צבע, אייקונים, מצבי כפתור. שני התפקידים האחרונים לעיתים באדם אחד, אך אלו יכולות שונות.
- מפתח צד לקוח: בונה את האפליקציה עצמה במכשיר. כאן מתפצל לאנדרואיד, ל-iOS או לפיתוח חוצה-פלטפורמות – החלטה שמשפיעה על עלות ועל ביצועים.
- מפתח צד שרת: נדרש בכל אפליקציה שיש בה חשבונות משתמש, סנכרון בין מכשירים, היסטוריה או תשלומים. אפליקציה מקומית לחלוטין יכולה להסתדר בלעדיו.
- בודק תוכנה: מוצר שנבדק רק על ידי מי שכתב אותו יוצא עם באגים. גם בדיקה חלקית ומסודרת שווה יותר מאין.
- מוביל פרויקט: אחראי על התמונה הכוללת, על סדר העבודה ועל התאמת ההיקף לתקציב.
הסדר שבו הם נכנסים
- אפיון – לפני הכול. שינוי במסמך אפיון עולה שעה; אותו שינוי בקוד עולה שבוע.
- חוויית משתמש – זרימה ומסכים סכמטיים, שאפשר להראות לאנשים ולתקן בזול.
- עיצוב ממשק – רק לאחר שהזרימה מוסכמת. עיצוב יפה על זרימה שגויה הוא בזבוז.
- פיתוח – צד שרת וצד לקוח, לרוב במקביל.
- בדיקות – במהלך הפיתוח ולא רק בסופו.
היפוך הסדר – להתחיל מהקידוד ולאפיין תוך כדי – הוא הסיבה הנפוצה ביותר לחריגות תקציב בפרויקטי אפליקציה, וגם אחת מהטעויות של ממציאי אפליקציות.
מה באמת נדרש בגרסה הראשונה
לא כל התפקידים נחוצים מיד. בפרויקט קטן ומעשי:
- הכרחי: אפיון, חוויית משתמש בסיסית, מפתח צד לקוח.
- נדרש אם יש חשבונות או סנכרון: מפתח צד שרת.
- ניתן לדחות: עיצוב ממשק מלוטש, בדיקות אוטומטיות, אנליטיקה מורחבת.
- אין לדחות: אפיון. זו ההשקעה שמחזירה את עצמה תמיד.
איך משווים בין הצעות
כדי להשוות תפוחים לתפוחים, בקשו מכל נותן הצעה לפרט שלושה דברים: מה כלול מבין התפקידים שלמעלה, מהם התוצרים (קוד מקור? חשבון בחנות? מסמכים?), ומה כולל ליווי לאחר ההשקה. בלי שלושת אלה, השוואת מחירים חסרת משמעות. הרחבנו על מבנה העלויות בעלויות פיתוח אפליקציית מובייל.
כשהאפליקציה מחוברת למוצר פיזי
במקרה הזה מצטרפים שני תפקידים נוספים: מפתח קושחה, שאחראי על הצד של המוצר, ומהנדס שמחזיק את הממשק בין השניים. פרויקט כזה אינו פרויקט אפליקציה עם תוספת – הוא פרויקט מערכת. פירטנו את השיקולים בפיתוח אפליקציה עבור המוצר שלי.
עצמאיים או חברה
פרויקט אפליקציה פשוט – מסכים, נתונים מקומיים, ללא שרת – מתאים היטב למפתח תוכנה עצמאי. ברגע שיש שרת, שתי פלטפורמות ותשלומים, מספר הממשקים עולה וכך גם הצורך בגוף אחד שמחזיק את השלם. ראו חברת פיתוח תוכנה.
לסיכום
פרויקט אפליקציה מורכב משבעה תפקידים, אך גרסה ראשונה מעשית דורשת שלושה – ובראשם אפיון. הכרת הרשימה מאפשרת ליזם לדעת מה נכלל בהצעה שקיבל, מה חסר בה, ומה ניתן לדחות לגרסה הבאה בלי לפגוע במוצר. בפרוג'קטס האוס בע"מ אנו מלווים פרויקטים שמשלבים אפליקציה ומוצר פיזי, ובפגישת ייעוץ ראשונה נעזור לכם למפות מה הפרויקט שלכם דורש בפועל.
רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.
