ללמוד מטעויות: 5 אתגרים ושיעורים בצוותי פיתוח

סטארט-אפ פור סטארט-אפ, אודיו בלוג. חמישה אתגרים שהפכו לשיעורים בקבוצת הפיתוח שלנו. יוסי אברמוב, Head of Engineering בלילי. הנרי פורד ר, the only real mistake is the one from which we learn nothing. בכל סטארט-אפ, ובמיוחד בשלבי הפיתוח הראשוניים, טעויות הן חלק בלתי נפרד מהתהליך. אשתף אתכם בחמישה מהאתגרים והטעויות שהשפיעו על הקמת קבוצת הפיתוח שלנו בלילי. נבחן האם ב ת היה מדובר בטעות או בדבר מה שהיה נכון לשעתו. נבחן איך תיקנו לאורך הדרך, וכל זאת כדי לתמוך במטרות העסקיות של החברה. הייתי שמח לחסוך מכם טעויות, אבל המטרה היא אחרת. המטרה היא לעזור לכם לזהות וללמוד מהטעויות והאתגרים במהירות ולצמוח מהן. אז יאללה, נתחיל. שיעור מספר אחת, בחירה טכנולוגיות. מדובר כנר בנושא הכי ברור מאליו. ברוב הסטארט-אפים, לפחות אחד המייסדים בעל רקע טכנולוגי. האם הטכנולוגיות בהן הצוות הראשוני שולט ומכיר רלוונטיות? אם כן, מדהים. אפשר להתחיל לרוץ. ואם לא, במה נבחר בטכנולוגיה הכי חדשה ונוצצת? בטכנולוגיה שכולם מדברים עליה לאחרונה? בואו נעצור רגע. לפני שנופלים לפיתוי לרוץ עם המוכר והידוע או שמים את כל הז'יטונים על הטכנולוגיה שהיא המילה האחרונה בתחום, יש כמה דברים שצריך לשקול. קודם כל, טכנולוגיה מוכרת עלולה להיות מיושנת ופחות נפוצה בשוק. גיוס מפתחים נוספים בעתיד עלול להפוך קשה יותר ויותר עם הזמן. בנוסף, טרנדים והדבר החם ביותר היום עלולים להיות מלכודת דבש. האם הטכנולוגיה מספיק בשלה? האם עדכונים עתידיים עלולים להסיט משאבים רבים לטובת העניין? האם מדובר בטרנד שבעיקר מדברים עליו או שעוד חברות מ צות את אותה הטכנולוגיה? גם אנחנו בלילי נתקלנו בדילמות הללו. בחלקן בחרנו נכון, בחלק אחר לא. או לפחות לא נכון לצרכים שלנו היום. אז איך תיקנו? גייסנו אנשים מוכשרים ורעבים שרוצים להרחיב את היריעה. ועבורם אפשרנו פתח לשנות את הטכנולוגיות בהן אנו משתמשים, בין אם בפרויקטים חדשים או קיימים. לגמישות הזו סרטטנו שני קווים אדומים עבור פרויקטים קיימים. אחת, השינוי אינו מצריך ריפקטור לכל הפרויקט. שתיים, השינוי אינו משפיע בצורה משמעותית על העמידה ביעדים העסקיים של החברה ואף ישפיע לטובה על היכולת לתת מענה ליעדים העסקיים העתידיים. שיעור שני, אוטסורס או אינהאוס. כאשר התחלנו לעבוד על לילי אי שם ב-2018, פיתחנו אפליקציית מובייל למכשירי אפל כי פנינו לשוק ה ריקאי אשר נטע באופן מובהק לטובת מכשירי אפל. בהמשך, רצינו לבחון האם יהיה עניין למוצר שלנו בשוק ה ריקאי גם אצל משתמשי אנדרואיד. החלטנו לפתח את האפליקציות הללו על ידי מפתחי אוטסורס בשל חוסר ודאות לגבי היקף השימוש בהן. היתרונות והחסרונות ברורים. שני הפרויקטים הפכו למשמעותיים ביותר עבורנו והבנו כי הדבר הנכון הוא להעביר את הפיתוח אוטסורס לפיתוח אינהאוס. האם היינו צריכים לבחור מלכתחילה בפיתוח אינהאוס? אולי. הדבר היה חוסך לנו מ ורות בהמשך הדרך. אך גיוס אינהאוס הוא בעצמו אתגר שדורש זמן והקומת למידה, בייחוד בטכנולוגיה או מומחיות שלא קיימת בחברה. הבחירה להתחיל עם אוטסורס ולעבור לאינהאוס בצורה הדרגתית התברר רק האסטרטגיה הנכונה. בחירה נכונה אינה תעודת ביטוח מפני סיכונים. לכן, בכל אחד מהפרויקטים שכרנו בנוסף למפתחים מומחה באותה טכנולוגיה כדי להבטיח את איכות התוצרים. שיעור שלישי. סקוואדס ורסס טק טימס. בתחילת הדרך, עבדו בלילי קבוצה קטנה של מפתחים, כל אחד על טכנולוגיה אחרת. עם צמיחת החברה וגיוס עובדים חדשים, לצד היכולות הניהוליות של כל אחד מהמפתחים הראשונים, היה ברור כי כל אחד מהם יוביל את האנשים החדשים בפרויקט שלו, משמע חלוקה טכנולוגית. עם הגידול של מחלקת הפרודקט והחלוקה העסקית בתוך המחלקה, הבנו כי חלוקה על בסיס טכנולוגי אינה תורמת למטרותינו ואף מעטה אותנו. בשל כך, איחדנו את שני הצוותים הטכנולוגיים לצוות אחד, עם מטרה שבהמשך התחלק לשני סקוואדס בהם יש מפתח מכל טכנולוגיה. פאסט פורוד, צרכי החברה השתנו פעם נוספת, ושמנו לב כי הסקוואדס כבר אינם עובדים ככאלה. כל אחד מהמפתחים עבד על פרויקט אחר לחלוטין, מול פרודקט אחר, ולא היה עוד היגיון לקיומו של הסקוואד. בשל כך, החלטנו לעשות שינוי נוסף, ולחזור לצוותים הטכנולוגיים. בכך, עבודה משולבת של כמה מפתחים מאותה טכנולוגיה הפכה לקלה ונוחה, ועזרה לנו לקדם דברים בצורה מהירה. מה נכון לכם? נסו לענות על השאלות הבאות. אחת, האם יש לכם מספר גדול של טכנולוגיות או פרויקטים? אם התשובה לכך היא לא, כנר שחלוקה טכנית תייצר צוות גדול מדי. על כן, צריך למצוא את המפתח שיאפשר חלוקה לצוותים קטנים. שתיים, האם במחלקת…

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