אחת ההחלטות החשובות ביותר בחייו של סטארטאפ היא בחירת ה-stack הטכנולוגי. באיזו שפת תכנות נשתמש, באיזה framework, גישות ארכיטקטורה, איזה סוג data-base, וכו׳… קשה להמעיט בחשיבות של ההחלטות הטכנולוגיות שלוקחים בשלבים הראשונים מכיוון שאלו ישפיעו על סוג האנשים שתגייסו, על תהליכי העבודה, על מהירות הפיתוח, עלויות ועוד המון פרמטרים שמושפעים במישרין ובעקיפין מהבחירות הטכנולוגיות שיעשו בתחילת הדרך. בפוסט הזה, אנסה לתת כמה טיפים על איך בכל זאת לקבל את ההחלטה הנכונה. בבואנו לבחור את ההחלטה אנחנו ניצבים מול המון אפשרויות ומעט מאוד נתונים על מה באמת נצטרך בהמשך הדרך. על מנת שלא תלכו לאיבוד, רציתי לחלוק כמה טיפים על מנת לעזור לכם בהליך ההחלטה.
Disclaimer קטן: הפוסט הזה לא הולך להציע לכם שום טכנולוגיה ספציפית. אני לא מאמין שיש טכנולוגיה מושלמת, אחת ויחידה, שנכונה לכל חברה ולכל מצב.
טיפ 1 – העדיפו את מה שאתם מכירים
אז אחרי שסיכמנו שאין טכנולוגיה מושלמת ואין one size fits all. בשלבים הראשוניים של הקמת סטארטאפ, אתם צריכים לזוז מהר ככל הניתן. מן הסתם, היכרות טובה עם הטכנולוגיה שתבחרו תחסוך לכם את שלב הלימוד וכמובן את אותן טעויות של מתחילים. לכן, אחרי שהשוויתם כמה אפשרויות, אם גיליתם שהטכנולוגיה בה אתם הכי מנוסים נמצאת בשלושת המקומות הראשונים ברשימה, לכו על מה שאתם מכירים. זה יעזור לכם לזוז הכי מהר ובשלבים הראשוניים זה מה שחשוב.
טיפ 2 – התייעצו והרבה
קהילת הסטארטאפים בארץ היא קהילה מדהימה. אתם תופתעו כמה אנשים ישמחו לעזור לכם אם רק תבקשו. כדאי תמיד להגיע לאנשים רלוונטיים דרך מכרים או לנסות להתייעץ בפורומים מוכרים. לדוגמא, קבוצת שאלות ותשובות – עזרה לסטארטאפים (לשעבר – ״השבוע״) בפייסבוק זה אחלה מקום למצוא אנשים להתייעץ איתם. כשאנחנו רק התחלנו את אוריבי חיפשנו חברות שעובדות בטכנולוגיות שעניינו אותנו או פותרות בעיות טכנולוגיות שדומות לבעיות שלנו. ההתייעצויות האלו עזרו לנו המון בהבנה של יתרונות, ואף יותר חשוב מזה, חסרונות של טכנולוגיות וגישות פתרון שונות. למען האמת, הייתי ממליץ לכם להתמקד אף יותר בחסרונות של הטכנולוגיות השונות אותן אתם בוחנים. אין כמו ללמוד מכאב של אחרים כדי להבין מאיזה מהמורות אפשר להמנע מראש. בנוסף, מומלץ מאוד לתכנן מראש מה אתם רוצים לשאול. הנה כמה שאלות לדוגמא:
- מה היה השיקול המרכזי בבחירת טכנולוגיה X?
- האם בדקתם גם את טכנולוגיה Y? אם כן – מה היו הפרמטרים העיקריים שגרמו לבחירת X?
- מה הבעיות העיקריות שיש לכם עם טכנולוגיה X?
- כמה זמן אתם כבר רצים עם טכנולוגיה X?
- מה הדבר העיקרי שכדאי לנו לחשוב עליו בשימוש בטכנולוגיה X?
טיפ 3 – הזהרו מאנשים שמדברים בשחור ולבן
במהלך ההתייעצויות ייתכן שתמצאו את עצמכם מבולבלים. בעוד שרמי מחברת MyCoolApp אמר לכם כמה טכנולוגיה מסויימת שעניינה אתכם היא מעולה ומשרתת אותם נהדר, רננה מחברת MyCoolerApp אמרה שהטכנולוגיה הזו מיושנת, גרועה ותעשה לכם רק כאב ראש. לצערי אין לי טיפ מוצלח כדי לעזור לכם להבין מי צודק. אבל אני כן אוכל להציע – הזהרו ממי שמדבר על טכנולוגיה במושגים מוחלטים. לכל טכנולוגיה יש יתרונות וחסרונות. המתכנתים מבין קוראינו לא זרים למלחמות הדת הנפוצות בקהילת המתכנתים – רווחים לעומת טאבים, vi או emacs, סוגר בסוף שורה או בשורה נפרדת ועוד ועוד…. סיכוי גבוה מאוד שתרגישו במהלך ההתייעצויות שלכם סוג כזה של מלחמת דת. אבל דיברנו כבר על כך שאין פיתרון מושלם. השתדלו לא ללכת אחרי הנואם הכי כריזמטי ודווקא להקשיב לאנשים שמסוגלים להבין שלאו דווקא מה שמתאים להם זה גם מה שמתאים לכם. אלו האנשים שיוכלו לפרט לכם באופן אובייקטיבי למה טכנולוגיה מסויימת עשויה להתאים לכם, אבל לא פחות חשוב מכך, איפה הטכנולוגיה הזו לא תתאים לכם.
תת-טיפ חשוב בעקבות תגובה שקיבלתי מנועם אביגדור: באותו נושא, טעות נפוצה היא ללכת בעקבות אופנות. הרבה אנשים ייעצו לכם בהתלהבות רבה ללכת עם טכנולוגיה מסויימת מכיוון שלדעתם זה ה-דבר. מאוד מתחבר לאנשים שמדברים במושגים מוחלטים. לפני שהולכים עם מה שטרנדי, חשוב לשאול את עצמינו – האם זה באמת מה שאנחנו צריכים?
טיפ 4 – יתרונות וחסרונות בגיוס עובדים
אחד הדברים שקל להתעלם מהם, אבל שישפיעו על החברה באופן משמעותי הוא נושא גיוס עובדים. לא חשוב כמה המוצר שלכם מגניב וכמה שהוא הולך לשנות את העולם, בסוף אתם צריכים אנשים טובים שירתמו לחזון שלכם וירצו לעבוד איתכם כדי לגרום לו להפוך למציאות. והאמת היא שעל האנשים האלו מתחרות עוד המון חברות מוצלחות ומעניינות. עבור מתכנתים בפרט ואנשים טכניים בכלל, הטכנולוגיה היא פקטור משמעותי ביותר בבחירת עבודה. לכן, הייתי חושב גם איך טכנולוגיה מסויימת נתפסת בעיני מועמדים פוטנציאליים. לדוגמא, אם תבחרו להשתמש בטכנולוגיה שנחשבת מיושנת, יהיה לכם מאוד קשה לשכנע אנשים מוכשרים להצטרף אליכם.
אני לא חושב שהייתי שם את השיקול הזה גבוה מאוד בשיקלול כל הפרמטרים, אבל כן זה משהו שהייתי חושב עליו. אני חושב שהמקום בו זה הכי ישפיע יהיה בחירת שפת התכנות. כנראה שנושאים כמו DB או ספק-ענן כזה או אחר פחות ישפיעו.
שיקול נוסף כאשר חושבים על עובדים זה נושא המומחיות. גם בחירה של טכנולוגיה איזוטרית, תקשה עליכם למצוא אנשים אשר יודעים (או רוצים) להתמודד עם הטכנולוגיה הזו וכנראה שמאגר האפשרויות שלכם יצטמצם מאוד ועשוי להאריך את משך חיפוש העובד המתאים לכם באופן משמעותי.
טיפ 5 – המנעו מאופטימיזציית-יתר – חשבו בשבועות או חודשים, לא בשנים
הטיפ הבא שאתן מיועד בעיקר לסטארטאפיסטים שקוראים את הבלוג הזה ונמצאים ממש בהתחלה. משהו שקל לשכוח בזמן שמתייעצים עם חברות ואנשים אחרים הוא שאתם עוד לא בשלב ה״בשל״ של החברה. בתקופה הראשונה של סטארטאפ, אתם בעיקר רוצים להגיע לשוק כמה שיותר מהר. ברגע שהמוצר יגיע לשוק אתם תגלו המון דברים שלא ידעתם בהתחלה – על אופן השימוש בו, על הרצונות של המשתמשים, על use-cases נפוצים יותר וגם על מקרי קצה שלא חשבתם עליהם מראש. בשלב ההתחלתי הזה, בחרו את מה שיעזור לכם להגיע ל-milestone הבא הכי מהר והכי בקלות. אני לא אומר להתעלם ממה יהיה בעתיד – איך נעשה לזה scale? מה יקרה אם נרצה להוסיף פיצ׳רים מסויימים? וכו׳… אבל כן אמליץ להרשות לעצמכם לחשוב כמה חודשים קדימה ולא כמה שנים קדימה מכיוון שהמון דברים הולכים להשתנות.
על מנת להמחיש את הנקודה, אשמח לחלוק אנקדוטה מהניסיון שלנו. אנחנו באוריבי בונים כלי אנליטיקות שנועד לנטר המון אירועים (events). לשם כך אנחנו שומרים מידע על אירועים שקרו באתר (בעיקר קליקים של משתמשים) ונותנים למשתמש יכולת לנתח את המידע. לשם כך בחרנו בכלי שנקרא Druid, בחירה אשר הרימה לא מעט גבות. אנחנו לא בטוחים האם הכלי הזה יתאים לנו לנצח. אבל בעבודה של מספר ימים הגענו לתוצר שבשימוש ב-Spark, האלטרנטיבה המתחרה שבדקנו, כנראה היה לוקח מספר שבועות. לקחנו את ההחלטה הזו מתוך הבנה וידיעה שייתכן ועוד מספר חודשים נאלץ להחליף את הבחירה הזו ולבנות פתרון אחר מעל טכנולוגיה אחרת. אבל אנחנו בסדר עם זה מכיוון שכבר עכשיו התחלנו ״להרגיש״ את המוצר, מה הלקוחות רוצים, מה עובד יותר טוב ומה פחות טוב. אם נחליט להחליף את Druid בהמשך ולבנות פתרון מורכב יותר באמצעות Spark, או כל טכנולוגיה אחרת, נגיע להחלטה הזו עם הרבה יותר מידע מאשר כשרק התחלנו לבנות את המוצר. ההבנות שאנחנו כבר עכשיו לומדים, יעזרו לנו לתכנן את ה-data-flow שאולי נחליט לבנות בהמשך עם Spark בצורה הרבה יותר טובה.
טיפ 6 – בדקו שיש מספיק מקורות מידע
- הרבה פעמים נראה שטכנולוגיה מסויימת היא ממש מה שאנחנו צריכים. משחקים קצת, מרימים איזה דמו או PoC קטן והכל עובד. אבל החיים הם לא רק דמו והבעיות צצות מהר ממה שלפעמים אנחנו מצפים. אז הנה שלוש נקודות שחשוב לשים לב אליהן מראש:
- תיעוד (documentation) – בעיקר בעולם ה-open-source, מאוד חשוב לבחור בטכנולוגיות עבורן יש מספיק תיעוד. כשטכנולוגיה מסויימת נמצאת בליבת המוצר, מהר מאוד מגיעים לצרכים שונים ומשונים וחשוב לוודא מראש שיהיה איפה להשיג את כל המידע שצריך ובאופן ברור. מבחן די אפקטיבי כדי לבדוק האם התיעוד טוב הוא לתת לעובד שלא התנסה בטכנולוגיה להכנס אליה ללא עזרה מחברי הצוות שכבר חפרו וחקרו בנושא. אם הכניסה היא מהירה, כנראה שהתיעוד מוצלח. בנוסף, תוכלו לדעת גם שעקומת לימוד לעובדים שיצטרכו להכנס לטכנולוגיה הזו תהיה מהירה יחסית שזו גם נקודת בונוס חשובה בבחירת טכנולוגיה.
- קהילה (community) – חשוב להבין איפה אפשר לשאול שאלות אם נתקעים בבעיות. האם יש הרבה שאלות על הטכנולוגיה הזו ב-stack overflow? האם יש איזשהו פורום או mailing-list בו ניתן להתייעץ? אם מדובר על טכנולוגיית open-source – האם המוצר מתוחזק באופן פעיל או שהעדכון האחרון שלו היה ב-2004? (אפילו אם זה ב-2014 הייתי חושד)
- בשלות (maturity) – הייתי נמנע מלקחת מוצרים ניסיוניים ומוצרים שרק בתחילת דרכם. זה מאוד מתחבר לפרמטר ה״קהילה״. קשה לדעת האם המוצרים האלו יצליחו ובעקבות כך יתוחזקו באופן רציף. סביר גם שכשתתקלו בבעיות, יהיה יותר קשה לפתור אותן במוצרים חדשים וניסיוניים.
טיפ אחרון – בדקו האם הטכנולוגיה תוכל לגדול עם החברה
במידה וטכנולוגיה מסויימת (לדוגמא DB) עשויה לגדול יחד עם החברה ולשמש אתכם גם כשמספר המשתמשים יעלה באופן משמעותי, שווה לחשוב מראש על היכולת שלה לעמוד בגדילה. חשוב לציין שבשלבים הראשונים של החברה אתם פחות צריכים להיות מודאגים מ-scale, אבל אני ממליץ לפחות להבין עד איזה שלב הטכנולוגיה תוכל ללוות את החברה וכמה השקעה יהיה להחליף אותה בעת הצורך.
