"The only real mistake is the one from which we learn nothing." - Henry Ford

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

אז יאללה, נתחיל… שיעור מספר 1 - בחירות טכנולוגיות:

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

בואו נעצור רגע. לפני שנופלים לפיתוי לרוץ עם המוכר והידוע או שמים את כל הז'יטונים על הטכנולוגיה שהיא ה״מילה האחרונה״ בתחום… יש כמה דברים שצריך לשקול:

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

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

שיעור 2 - Outsource vs In-house:

כאשר התחלנו לעבוד על Lili אי שם ב-2018, פיתחנו אפליקציית מובייל למכשירי אפל כי פנינו לשוק האמריקאי, אשר נטה באופן מובהק לטובת מכשירי אפל. בהמשך, רצינו לבחון האם יהיה עניין למוצר שלנו בשוק האמריקאי גם אצל משתמשי אנדרואיד. שנים קדימה, היתה לנו את אותה דילמה גם לגביי אפליקציית ה-Web שלנו. החלטנו לפתח את האפליקציות הללו ע״י מפתחי outsource בשל חוסר וודאות לגביי היקף השימוש בהן. היתרונות והחסרונות ברורים. שני הפרוייקטים הפכו למשמעותיים עבורנו והבנו כי הדבר הנכון הוא להעביר את הפיתוח outsource לפיתוח in-house.

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

שיעור מספר 3 - squads vs tech teams

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

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

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

שיעור מספר 4 - גיוס מפתחים

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

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

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

שיעור מספר 5 - דוקומנטציה ובדיקות

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

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

רגע לפני הצלצול להפסקה, זו האמ״ט שלי

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