5 כלים פנימיים שחוסכים לנו שעות ביום

שניים מבין העקרונות החשובים ביותר עבורי בבניית סטארטאפ הם :

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

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

אז למה החלטנו להשקיע בכתיבת כלים שהם לא חלק אינטגרלי מהמוצר המרכזי? נושא שאני מתכננת לכתוב עליו בהרחבה בבלוג זה בעתיד הוא work life balance. אני מאמינה שסטארטאפים בהם הנורמה היא לעבוד כל יום עד אמצע הלילה לא בהכרח מתקדמים מהר יותר מסטארטאפים 'רגועים' (ולרוב בהכרח לא). לחץ תמידי בסטארטאפים מעיד לדעתי בעיקר על שיטות עבודה לא מספיק יעילות וחוסר פוקוס. אחד הנושאים העיקריים שאני מתמקדת בהם בתקופה זו הוא איך אפשר לעבוד חכם יותר ולייעל תהליכים.

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

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

Kob – Slack Integration with our DB

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

Who is [user name]?

וכך מכל מכשיר אנחנו יכולים לקבל באופן מיידי את כל המידע שאנחנו צריכים עבור support. שאלות אחרות בקנה הן לגבי אירועים ביום מסויים (what happened on 1.7.16) רשימות של יוזרים ע"פ פרמטרים שונים ועוד. אנחנו 'מדברים' עם קוב עשרות פעמים ביום. 'קוב' מקל מאד גם על אנשים פחות טכניים להכנס בקלות אל המידע בלי צורך ללמוד לעבוד מול ה DB.

זמן פיתוח : יומיים

Dik Dik – 3rd party tools API changes tracking

כיום אנחנו עובדים באופן אינטנסיבי מול ה API של פייסבוק ובעתיד הלא רחוק נתחיל לעבוד עם APIs של כלים נוספים. אחת הבעיות הנפוצות בעבודה אינטנסיבית מול APIs שונים היא שינויים תכופים. בין אם מדובר על שינויי הגדרות שיכולים להוביל לשבירות במוצר שלנו ובין אם מדובר על תוספות ושינויים שכדאי לאמץ בהקדם. הבעיה העיקרית שנתקלנו בה היא שרוב החברות מודיעות רק על שינויים משמעותיים מאד ב API שלהן בזמן שיש אינסוף שינויים קטנים שקורים על בסיס יומיומי, על חלקם קריטי לנו לדעת. פיתחנו כלי שסורק את כל ה documentation תחת roots מסויימים ומדווח לנו על דפים שהשתנו ועל דפים חדשים שנוספו. אנחנו מקבלים מייל יומי עם סיכום כל השינויים ו"תקציר" מתוך הדף כדי שנוכל להבין ברפרוף על האימייל אם משהו השתנה. לבניית דיק דיק עשינו שימוש ב Git להשוואה בין הקבצים השונים ובחבילת הקוד הזו : www.crummy.com/software/BeautifulSoup

זמן פיתוח : שבוע

Impala – Live UI tests

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

1. מקום מרוכז בו ניתן לראות את כל הקומפוננטות שמרכיבות את הממשק (מ check box ועד תפריטים מורכבים) ולזהות בקלות מה אפשר ל"מחזר" ואיך לבנות קומפוננטות חדשות באופן יעיל יותר על בסיס הקודמות.
2. כלי ל'הזרמת' כל סוג מידע לקומפוננטה. ניתן לערוך את הקוד בתוך הכלי עצמו ולהזין כל סט ערכים שבוחרים. במידה רבה זה כלי מקביל ל developer tools של כרום המאפשר לשנות צבעים/ פונטים/ מיקומים של אלמנטים. אימפלה מאפשר לשנות באופן דינמי את הערכים. אימפלה מבוסס על stack.formidable.com/component-playground

זמן פיתוח : יומיים

Dashboard

אני מאמינה שדשבורד הוא אחד הכלים הראשונים שכל חברה צריכה לפתח. נכון, שבשלבים מוקדמים אפשר פשוט לעדכן את הנתונים ב Google doc אבל מבחינה עקרונית, לדעתי קריטי שתהיה תפיסה של מדידה מדוייקת, קביעת מטרות ברורות וריכוז הכל במקום אחד. מוזמנים לקרוא עוד פרטים בפוסט שכתבתי על דשבורדים בחברות סטארטאפ. כמובן שעדיף לעשות שימוש בכלי קיים מאשר לפתח משהו מאפס. הבעיה שנתקלנו בה היא שכל כלי הדשבורד שבחנו התבססו על שאיבת נתונים ממקור אחר ולא נתנו מענה לפיצ'רים שלא מבוססים על הצגת נתונים קיימים. למשל – יצירת רשימה של כל ה milestones של החברה או רשימה של המטרות לכל חודש וכל שבוע. הנה המרכיבים שאנחנו בחרנו לייצג בדשבורד של אוריבי :

• רשימת המטרות לחודש הנוכחי ולשבוע הקרוב. מבחינתי, החלק המשמעותי ביותר בדשבורד. אחת הבעיות המרכזיות של סטארטאפים היא חוסר פוקוס. סטארטאפים רבים מתים בגלל שלא הצליחו להתמקד בפתרון בעיה מדוייקת אלא התפזרו לכיוונים שונים. ברמה האישית אני מגדירה לעצמי כל חודש את הפוקוס המרכזי ומשתדלת שלפחות 80% מהזמן שלי יוקדש למטרה זו. הדגשת המטרות מול הצוות היא קריטית ועוזרת לזוז מהר יותר ולתעדף בקלות. בדשבורד שבנינו יש מקסימום 5 מטרות חודשיות ו 5 שבועיות. אני חושבת להוריד בקרוב את מספר המטרות ל 3 כדי למקד את הצוות (ואותי) עוד יותר.

• מעקב אחר הפרמטרים המרכזיים – מספר משתמשים, מספר משתמשים חוזרים, אחוזי משתמשים בפיצ'רים מרכזיים. כיום אנחנו מציגים 6 פרמטרים. אחת הבעיות בדשבורדים היא שפעמים רבות נוטים להוסיף עוד ועוד פרמטרים עד שלא ברור מה חשוב ומה לא. אני רוצה להגביל את מספר הפרמטרים העיקריים שעוקבים אחריהם ל 5 ולהוריד כמה פרמטרים של 'feel good'. לדוגמה, היום אנחנו מציגים את סכום ההוצאות בכל החשבונות שניתחנו. זה נחמד מאד לראות מספר של מאות מיליוני דולרים שעולה כל הזמן אבל זה לא באמת מעיד על איכות המוצר.
• Milestones – סוג של לוג ארוך אליו כל אחד מחברי הצוות יכול להזין 'ציוני דרך' בחברה. מהצטרפות עובד חדש, סיום פיצ'ר, שינוי בתשתית הטכנית, ציון דרך עיסקי. כל milestone הוא לגיטימי ואין דבר כזה כ milestone קטן מדי. כאשר אחד מחברי הצוות מוסיף milestone חדש, הדשבורד מתחלף ל animated gif שמח במיוחד (מגרילים אחד מתוך סדרה של כמה עשרות) כדי לחגוג את המאורע.

• Traffic – מעקב אחרי כמות המבקרים היומית והחודשית באתרים השונים. מבוסס על אינטגרציה בסיסית עם Google Analytics.
• פרטי יוזרים חדשים – מי המשתמשים החדשים שהגיעו היום? מאיפה הגיעו? מאיזה חברה? חלק זה נועד בעיקר לקשר את כל הצוות למשתמשים שלנו ולהרגיש את האנשים שעובד עם מה שאנחנו מפתחים.

זמן פיתוח : שבוע

Debug mode

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

זמן פיתוח : 3 ימים.

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