החלק השני בסדרת פיתוח המוצרים העצמאיים שלי
המאמר הקודם תיאר, מנקודת מבט של מפתח iOS, משאבים להגדרת צורך, לפיתוח אפליקציה עצמאית ולהשקתה. בשל משאבים מוגבלים יכולתי להשלים רק אפליקציות כלי שפורסמו ב-App Store של Apple.
המאמר הזה עוסק בפיתוח מוצר מלא חוצה פלטפורמות, בבעיות שבדרך ובפתרונותיהן. אשתף כיצד בניתי בהדרגה מערכת מוצר שלמה הכוללת חשבון WeChat רשמי, תוכנית זעירה ואפליקציה.
1. יעדי המוצר
במובן הרחב, יעד מוצר הוא הערך שהמוצר מספק. גם כשיש תרחיש שימוש, למוצר חסר ערך, שאינו מרוויח ויש לו מעט מאוד משתמשים, אין סיבה רבה להתקיים.
אפשר להתחיל אפילו רחב יותר, בחזון המוצר…
עצרו. אל תחשבו עדיין על הכול, אחרת המוצר עלול לא לצאת לעולם מן הדמיון האינסופי.
כאשר המשאבים, האנשים וההשקעה מוגבלים, היעד ברור: אילו בעיות המוצר צריך לפתור, או אילו יכולות עליו לספק?
למשל, כשבניתי את File Manager, ל-MVP היה יעד ברור: להעביר קבצים בין טלפון למחשב.
השלמת ה-MVP הולידה דרישות נוספות. חלקן באו מתוכניות המוצר שלי, אך רובן ממשוב משתמשים:
- 1.0.0 העברת קבצים בין הטלפון למחשב
- 1.1.0 תצוגה מקדימה או הפעלה של תמונות, סרטונים ושמע
- 1.2.0 קיבוץ, העברה, מחיקה, דחיסה ושיתוף של קבצים
- 1.3.0 שיפור הנגן
- 1.4.0 אימות אבטחה: קוד מחווה וביומטריה
- 2.0.0 רכישות בתוך האפליקציה
- 2.1.0 סריקת מסמכים
- …
בחרו יעד. הוא לא חייב להיות גדול, אך עליו להיות מעשי. התמקדו בדבר אחד והמשיכו גם אם הוא נראה שגוי—איך תדעו בלי לסיים ◔ ‸◔? סיימו ואז בחנו מחדש.
2. אבות טיפוס למוצר
במאמר הקודם הזכרתי שניסיתי כלי אב-טיפוס רבים והגעתי למסקנה כי בזמן שלקח לעצב אב-טיפוס יכולתי לבנות את המסכים ב-xib.
הרשו לי לסתור את עצמי ,,Ծ‸Ծ,,
מובן לחשוב כך כשבונים כלי אישי ללא תוכנית המשך, ורוצים רק לסיים ולפרסם אותו.
ככל שהמוצר מתפתח, התקדמות בלי אב-טיפוס או תוכנית תגרום בעיות קשות בעתיד. עיצוב אב-טיפוס הוא למעשה ארגון ההיגיון של המוצר.
הנה כמה כלי אב-טיפוס. הכלי שבו אני משתמש כיום יותר מכול הוא MockingBot.
3. ניהול פרויקט
אחרי שפיתחתי ופרסמתי אפליקציית iOS בעצמי, הבחנתי בבעיה רצינית: לא היה לי מושג בניהול פרויקטים. עבדתי כשנזכרתי או כשהיה זמן, ולא עשיתי דבר כשהתעצלתי.
זה היה מוצר שלי, שתכננתי ופיתחתי לבד. כנראה לא היו ל-MVP משתמשים משלמים, ולכן לא חשתי אחריות כלפיהם.
זה מאט מאוד את הפרויקט. עבודה ממושכת בלי תוכנית יכולה אפילו להרוג אותו.
אחרי שנים של ניהול גרסאות בעבודה גיליתי שכלי ניהול פרויקטים מתאימים גם לפרויקטים אישיים. כשיש יעד ברור ואב-טיפוס עקבי, פירוק העבודה למשימות נעשה טבעי.
אני משתמש ב-coding.net לניהול הפרויקט; הוא יכול גם לאחסן קוד מקור.
פרקו משימות ליחידות של שעות. כך קל יותר לנהל אותן ולכתוב מקרי בדיקה. ההרגל שלי הוא להשלים את מקרי הבדיקה לפני הקוד. זה חיוני.
אב-טיפוס מארגן את היגיון המוצר; מקרי בדיקה מארגנים את פרטי המימוש. מקרי בדיקה מלאים מובילים להיגיון עסקי נכון ✅ ומונעים שגיאות עסקיות רבות ❌.
4. בחירת טכנולוגיה
עד כה רק התכוננו; טרם התחלנו לפתח. הקושי הוא שאני המפתח היחיד, אך רוצה לבנות מערכת שלמה של חשבון WeChat רשמי, תוכנית זעירה ואפליקציה.
נדרשות מיומנויות בתוכניות זעירות, iOS ו-Android. לימוד שפה אינו קשה במיוחד, אבל מימוש אותו היגיון עסקי שלוש פעמים עולה פי שלושה. זה בבירור לא מציאותי.
בדרך כלל אפשר להשתמש ברשת לכמה פלטפורמות, או לוותר על האפליקציה ולהתמקד בחשבון רשמי ובתוכנית זעירה. בשלב מוקדם, כשנדרש אימות מהיר, זו גישה סבירה.
חיפוש קצר מגלה טכנולוגיות חוצות פלטפורמות. לבניית אפליקציה ותוכנית זעירה מבסיס קוד אחד בשלוש פלטפורמות אפשר להשתמש ב-Uni-App. היא משתמשת במסגרת Vue.js, ותומכת ב-iOS וב-Android דרך Weex.
זה מספיק למוצרים אישיים או מסחריים קטנים.
5. ניהול נתונים
לאחר בחירת גישת התוכנית והאפליקציה נותרה שאלה מכרעת: איפה יישמרו הנתונים?
לכלי, אחסון מקומי מספיק. אבל מה אם היעד הוא פלטפורמת מידע עם מערכת משתמשים מלאה, או קהילת תוכן משתמשים מורכבת?
Uni-App מציעה את uniCloud. אפשר לפתח שרת ב-JavaScript, והתוכנית והאפליקציה יכולות להשתמש בו בלי שם מתחם.
בחרתי אחרת: אחסון הנתונים בפלטפורמה ללא שרת LeanCloud. התוכנית והאפליקציה ניגשות למסד הנתונים דרך JavaScript SDK של LeanCloud.
מסלול הפיתוח תומך ב-30,000 בקשות API חינמיות ביום ומספק גם SMS. די בכך למערכת משתמשים, העלאת נתוני משתמשים ושליפת נתוני הפלטפורמה.
כשהבקשות עוברות את המכסה, יש למוצר קהל בגודל מסוים. ההכנסה מן התעבורה אמורה אז לכסות מסלול מסחרי של תשלום לפי שימוש.
דרך ערמומית להשגת נתונים
מה אם רוצים אפליקציית מזג אוויר או מידע, אך אין נתוני מזג אוויר או חדשות?
בסין יש שוקי API רבים, ובהם:
ואחרים.
השווקים מציעים ממשקי API בתשלום ובחינם.
אם יש דרך טובה להפיק הכנסה מתעבורה, שקלו API בתשלום.
אם לא, שקלו מכסות חינמיות. אבל 100 בקשות ניסיון עלולות להיגמר בבדיקות. מה אז?
אפשר לשלב את מסד LeanCloud עם שוק API. במזג אוויר יומי, למשל, מחפשים קודם במסד; אם אין נתונים, מבקשים מן השוק ושומרים במסד.
ואם 100 בקשות לא מכסות את כל הערים? המשיכו ברוח החינם והירשמו לכמה פלטפורמות.
6. השקה ותפעול
כעת סיימנו לפתח את התוכנית, האפליקציה והשרת. איך משיקים?
תוכניות זעירות פשוטות יחסית: פעלו לפי ההנחיות ב-פלטפורמת החשבונות הרשמיים של WeChat.
פרסום ב-iOS דורש חשבון מפתח בתשלום. זו משוכה, אך להפעלה ארוכת טווח מומלץ להירשם ב-אתר המפתחים של Apple. כיום מורידים את אפליקציית Developer ב-iPhone ומשלמים בה.
להפצה ב-Android נדרש רישום זכויות יוצרים לתוכנה. בקשה רגילה עשויה לקחת 1–2 חודשים, או שאפשר לשלם למתווך חיצוני.
וברוח החינם: איפה מאחסנים תמונות, שמע וסרטונים לאזורי קידום באפליקציה ובתוכנית?
ספריית המדיה של החשבון הרשמי פותרת זאת. אחסנו שם מדיה, קבלו את כתובותיה המקוריות, והאפליקציה והתוכנית יוכלו לגשת אליה.
7. יצירת הכנסה
דרך פשוטה להפיק הכנסה מתעבורה היא פרסום.
אך דרישות הסף של הפלטפורמות למפרסמים עולות, ולכן למפתחים עצמאיים קשה לשלב פרסום.
Uni-App מציעה שילוב בלחיצה; ראו תיעוד.
חשבון רשמי שצבר קהל יכול להפעיל פרסום במאמרים.
תוכנית זעירה יכולה להפעיל הכנסות מפרסום אחרי 1,000 מבקרים ייחודיים.
8. מחשבות לסיום
כעת השלמנו את מערכת החשבון הרשמי של WeChat, התוכנית הזעירה והאפליקציה שתוארה בתחילה.
בעזרת השלבים האלה השלמתי את התהליך בשלושה מוצרים. סרקו את הקודים כדי לנסות:
