8 טעויות יקרות בפיתוח אפליקציות שעסקים קטנים ממשיכים לעשות

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

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

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

טעות 1: בונים לפני שהוכחתם שמישהו רוצה את זה

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

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

טעות 2: התרחבות היקף שמתחפשת לשאפתנות

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

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

טעות 3: אין בריף כתוב — רק תמונה מנטלית משותפת

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

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

טעות 4: בוחרים את המפתח בדרך הלא נכונה

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

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

מה לבדוק באמת

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

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

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

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

טעות 6: מעצבים עבור עצמכם במקום עבור המשתמש שלכם

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

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

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

טעות 7: בונים iOS ו-Android נייטיב כשלא הייתם צריכים

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

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

טעות 8: מתייחסים להשקה כאל סוף העבודה

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

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

איך להישאר מחוץ לכל השמונה בבת אחת

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

1. 1
   הוכיחו ביקוש לפני שאתם בונים

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

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

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

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

   ווב או cross-platform תחילה ברוב המקרים. עברו לנייטיב מלא בהמשך, עם ראיות, רק אם השימוש דורש זאת.
6. 6
   בדקו עם משתמשים אמיתיים, ואז תכננו את ההשקה

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

שאלות נפוצות