by macrovector - www.freepik.com

הסטארט-אפ שלכם עולה לאויר? וודאו שאתם מוכנים!

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

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

כבית תוכנה שליווה מאות עליות לאוויר, יצרנו עבורכם רשימה של שאלות שצריך לשאול בתהליך תכנון:

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

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

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

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

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

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

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

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

9האם עשיתם מעבר על הקוד על מנת לוודא שהוא מוכן לעליה? האם קבעתם נהלים לטיפול בקוד אחרי העלייה? צריך להבין שבמהלך פיתוח מפתחים מכניסים לקוד דברים שנועדו לעזור להם לבדוק את התוכנה ולמצוא תקלות. כמו כן במהלך הפיתוח המשתמשים מעלים את התיקונים שלהם בצורה חופשית למדי למערכת ניהול קוד(GIT, לפחות אני מקווה שאתם משתמשים במערכת ניהול קוד).  דברים שצריך לבדוק:
– להוריד מהקוד הודעות בדיקות(debug)
– מיניפיקציה של קוד(minification)
– הפרדה בGIT בין קוד של סביבת בדיקות לסביבת ריצה
– נוהל העלאת דברים לGIT

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

9האם עשיתם מעבר על הקוד על מנת לוודא שהוא מוכן לעליה? האם קבעתם נהלים לטיפול בקוד אחרי העלייה? צריך להבין שבמהלך פיתוח מפתחים מכניסים לקוד דברים שנועדו לעזור להם לבדוק את התוכנה ולמצוא תקלות. כמו כן במהלך הפיתוח המשתמשים מעלים את התיקונים שלהם בצורה חופשית למדי למערכת ניהול קוד(GIT, לפחות אני מקווה שאתם משתמשים במערכת ניהול קוד).  דברים שצריך לבדוק:
– להוריד מהקוד הודעות בדיקות(debug)
– מיניפיקציה של קוד(minification)
– הפרדה בGIT בין קוד של סביבת בדיקות לסביבת ריצה
– נוהל העלאת דברים לGIT

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