מפתחים ויזמים: הסטארטאפ שלכם עולה לאוויר? ודאו שאתם מוכנים
מאת: ישי טנצר, 16.2.17, 09:17
 
מהן 9 השאלות החשובות, שכל מפתח וסטארטאפיסט חייב לשאול לפני שלב העלייה לאוויר עם האפליקציה/המוצר שלו?
 
אחרי כל הקשיים של חשיבה,זיקוק הרעיון, פגישות עם משקיעים ומשתמשים, פיתוח המוצר,בדיקות ותיקונים, החלטתם שאתם מוכנים ורוצים לעלות לאוויר.
 
התהליך שעברתם הוא תהליך קשה ומייגע, אתם להוטים ללחוץ על הכפתור, לראות שהמערכת עולה והמשתמשים נוהרים אליה בהמוניהם.
 
זה בדיוק הזמן לעצור, לקחת נשימה עמוקה ולתכנן את תהליך העלייה לאוויר כהלכה. זהו לא צעד טריוויאלי, טעויות בשלב הזה עלולות להיות קטלניות למוצר שלכם.
 
להלן רשימה של שאלות, שצריך לשאול בתהליך תכנון:
 
האם המוצר נבדק כהלכה?  תמיד יהיו באגים שלא יתגלו, אבל מתפקידכם לוודא שהפונקציונלית העיקרית עובדת ושניתן להשתמש במוצר. זכרו אין כמו רושם ראשוני  למשתמשים שלכם.
 
האם יש סוגיות של אבטחת מידע/פרטיות שצריך לקחת בחשבון? האם אתם שומרים מידע רגיש? האם יש רגולציה בתחום? בתהליך הפיתוח היה קל להתעלם מנושאים אלה, אבל ברגע שאתם עולים ומשתמשים מזרימים מידע, יש עליכם אחריות כבדה ואתם חשופים לתביעות משפטיות. מצגת מפורטת בנושא - כאן.
 
האם כל התוכן הוכן והוזן? במהלך הפיתוח והבדיקות קל להתעלם מתוכן חסר (הרי זה לא משפיע על פונקציונליות המוצר). הצוות מכיר את המוצר על בוריו ויכול להתעלם מכך, שחסר תוכן. המשתמשים לא מכירים את המוצר שלכם וקצת תוכן חסר יכול להפוך אותו ללא שמיש. וודאו, שהתוכן קיים ותורגם לכל השפות הנתמכות.
 
האם יש לכם תכנית כתובה איך עולים לאוויר? לפעמים המושג "עליה לאוויר" נשמע כל כך הרבה פעמים בחדר, שאף אחד לא טרח לרשום ולפרט את כל השלבים ומה קורה במקרה של בעיות. דברים שצריך לקחת בחשבון: לאיזה תשתיות/שרתים עולים? באיזה סדר מעלים את הדברים? מה קורה אם פעולה מסוימת נכשלת? חוסר בהירות כאן יכול לגרום, שיישכחו צעדים קריטיים או להביא לחוסר ידיעה מה לעשות במקרה ומשהו משתבש.
 
האם עשיתם הפרדת סביבות? מהרגע שהמוצר עולה לאוויר שום דבר לא נגמר, הכל רק מתחיל. במקביל לגרסה, שרצה בשטח, אתם תמשיכו לפתח, לבדוק ולשפר את המוצר. אבל אי אפשר לעשות זאת על אותו שרת, בסיס נתונים החשוף למשתמשים. לכן, מכינים סביבות עבודה נפרדות מבחינת תשתיות לסביבת בדיקות, סביבת ריצה (לפעמים יש יותר סביבות בהתאם לצרכים). ודאו, שחשבתם על כך מראש, תכננתם והקמתם תשתיות.
 
האם אתם ערוכים לתמוך בתקלות ופניות משתמשים? יש לחשוב על מענה לפניות משתמשים, דיווחי תקלות, אימות תקלות, ביצוע תיקונים, שוב פעם בדיקות והעלאת התיקונים לאוויר. כל זה בלי להשבית את המערכת (או עם מינימום זמן השבתה) ובלו"ז צפוף כדי שהמשתמשים הראשונים לא יברחו.
 
האם התקנתם כלי אנליטיקה ומעקב אחרי התנהגות משתמשים? בעידן של ביג דאטה, קריטי לאסוף את הנתונים מהשנייה הראשונה, כדי שאחר כך (רצוי כמה שיותר מהר) ניתן יהיה  לנתח אותם, להסיק מסקנות ולהכניס שיפורים למערכת. לכן, קבעו מה הדברים, שאתם רוצים למדוד, איזה כלי מדידה אתם בוחרים ושעשיתם להם אינטגרציה לקוד.
 
האם יש לכם רשימה של שירותים חיצוניים בהם אתם משתמשים? האם פתחתם חשבונות ויש לכם פרטי גישה? ישנה רשימה ארוכה של שירותי צד שלישי, שאתם משתמשים/תשתמשו, חבל להגיע לרגע הגורלי ולגלות שלא פתחתם חשבון מפתח באפל, התהליך לוקח חודש. בלי זה אתם לא יכולים לעלות את האפליקציה שלכם לאוויר. הכינו רשימה מראש, וודאו, שיש לכם את כל המידע. להלן דוגמה לכמה שירותים שכיחים:
 
חשבון אפל/גוגל,
כלי אנליטיקות,
פרטי דומיין/DNS.
 
האם עשיתם מעבר על הקוד כדי לוודא, שהוא מוכן לעליה? האם קבעתם נהלים לטיפול בקוד אחרי העלייה? צריך להבין, שבמהלך פיתוח, מפתחים מכניסים לקוד דברים, שנועדו לעזור להם לבדוק את התוכנה ולמצוא תקלות. כמו כן במהלך הפיתוח המשתמשים מעלים את התיקונים שלהם בצורה חופשית למדי למערכת ניהול קוד (GIT, בתקווה שנעשה שימוש במערכת ניהול קוד).  דברים שצריך לבדוק:
 
להוריד מהקוד הודעות בדיקות (debug),
מיניפיקציה של קוד (minification),
הפרדה בGIT- בין קוד של סביבת בדיקות לסביבת ריצה,
נוהל העלאת דברים ל-.GIT
 
לסיכום: השאלות אמורות לסייע לכם לתכנן את שלב העליה לאוויר בצורה הטובה ביותר. אפילו עלייה במודעות לנושא עושה ניסים.
 
מאת: ישי טנצר, פברואר 2017
מנכ"ל Initech Software services