מתי סטארטאפים צריכים להכניס IT?

תמונה: dreamstime

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

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

בשלבים הראשונים של סטארטאפ כל אחד עושה הכל: ה-CTO מפרמט לפטופים, מפתחי ה-Frontend מחברים VPN, ומי שיש לו עבר בצבא בתור “איש תקשורת” הופך בינתיים ל-helpdesk של החברה. בשלב הזה יש נטייה לחכות עם גיוס של איש IT. הסיבות ידועות: למה להכניס עכשיו משרה מלאה של IT אם אנחנו רק 15 עובדים?; זה עוד תקן, עוד עלות חודשית; הקלאסי – כל עוד זה עובד, לא נוגעים; ומעל הכל יש התחושה שזה פחות דחוף מול הפיתוח, המוצר והשיווק.

אבל אז מגיע הרגע, וזה באמת קורה ברגע, שמגלים שחיכיתם יותר מדי. עובד חדש נכנס ואין לו לפטופ, השרת במעבדה קורס ואין גיבוי; מישהו פותח לינק בפישינג וכל החברה ב-Panic Mode; ולפעמים הרגע מגיע כשמתחילים לעבוד עם לקוח תאגידי ושואלים אתכם על מדיניות סיסמאות, SOC2 או ניהול הרשאות ואין לכם את מי לעלות לשיחה.

החלטות קריטיות בשלב מוקדם

אחרי שליוויתי כמה סטארטאפים המסקנה שלי מהשטח היא שאם חציתם את רף ה־60 עובדים ויש לכם תשתית בסיסית (VPN, SaaS, הרשאות, Onboarding) – זה הזמן להכניס לפחות פונקציה טכנית אחת שתחזיק אותה. זה לא חייב להיות איש IT קלאסי וגם לא משרה מלאה – אפשר משרה חלקית, פרילנסר או MSP, העיקר שיהיה מישהו שמבין תשתיות, אבטחה ותהליכים ויכול לייצר סדר, אוטומציה ותמיכה.

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

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

לא פעם סטארטאפים דוחים "לאחר כך" הקמה של תהליכים מסודרים. בהתחלה, כל deploy נעשה ידנית על ידי המפתח הראשי באמצע הלילה ואין CI/CD אמיתי; ייתכן גם שאין מדיניות סיסמאות והצפנה ברמת החברה כי "כולם בחדר אחד וסומכים אחד על השני”

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

לא פעם סטארטאפים דוחים "לאחר כך" הקמה של תהליכים מסודרים. בהתחלה, כל deploy נעשה ידנית על ידי המפתח הראשי באמצע הלילה ואין CI/CD אמיתי; ייתכן גם שאין מדיניות סיסמאות והצפנה ברמת החברה כי "כולם בחדר אחד וסומכים אחד על השני”. הגישה הזו מובנת בתחילת הדרך, אבל תרבות האד הוק הזו גם גובה מחירים: גרסאות לא עקביות גרמו להשבתות, קוד אבד בגלל חוסר בבקרת גרסאות נכונה ונתקלתי גם בפרצת אבטחה שנוצלה כי לא הייתה הקשחת מערכת בסיסית.

משמעת טכנולוגית מוקדמת

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

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

מיקור חוץ מושכל – זה בסדר גמור (ואף חכם) להוציא חלק מהפעילויות החוצה. אם אין לכם מומחה אבטחת מידע, שקלו לשכור יועץ חיצוני לבצע בדיקת חדירות ואבטחת אפליקציה. אם נושא ה-HIPAA מבלבל אתכם, ניתן להיעזר במומחה רגולציה חיצוני שיעזור לבנות את הנהלים הנדרשים. מיקור חוץ נקודתי בתחומים מורכבים יכול לחסוך טעויות קריטיות, ללמד את הצוות שלכם best practices, ובסופו של דבר לחסוך כסף וזמן. העיקר הוא לנהל נכון את נותני השירות, לקבוע יעדים ברורים ולא לשכוח מהנושא אצל ספק חיצוני בלי בקרה.

ניטור, בקרה וכלי ניהול חכמים – נצלו כלים מודרניים שיעזרו לכם לשלוט במערכות מבלי להעמיס על הצוות. יש היום מערכות מעולות לניטור ביצועים ואבטחה בענן שיתריעו לכם על חריגות או פרצות בזמן אמת. כלי FinOps (ניהול פיננסי לענן) יכולים לסייע בשליטה בהוצאות – להתריע כששרת נשכח דולק בסוף השבוע או כשיוצאים משימוש חורג מעבר לתקציב. גם ניהול תצורה אוטומטי (Infrastructure as Code) באמצעות כלים כמו Terraform יכול להבטיח שהמערכת ניתנת לשחזור ובקרה. השקיפות והמידע שהכלים האלו מספקים יתנו לכם יכולת תגובה מהירה וקבלת החלטות מבוססות נתונים, במקום לנחש לאן נעלם התקציב או למה האתר קרס.

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

הכותב הוא Director Of IT ב-viz.ai