השאלה הנפוצה ביותר שאנו מקבלים ממייסדים אחרים אינה לגבי תמחור או יציאה לשוק. זה שקט, מעט חשוד: איך צוות בגודל שלך שומר על 150 מודולים מבלי שכל העניין יקרוס? התשובה הכנה היא שאנחנו לא מתחזקים 150 מודולים. אנו שומרים על פלטפורמה אחת ועליה שכבה דקה מאוד. הטריק הוא חוסר הרחמים לאיזו שכבה שייכת יצירה נתונה.
המתמטיקה שמפחידה אנשים.
אם אתה מדמיין 150 מודולים כ-150 יישומים קטנים - כל אחד עם מודל נתונים משלו, הרשאות משלו, חיוב משלו, התראות משלו - אז 22 אנשים הם ללא ספק מטורפים. זה שישה מודולים לכל מהנדס, כל אחד מוצר בפני עצמו. אף קבוצה לא שורדת את זה. החשש נכון, לארכיטקטורה הזו.
אבל זו לא הארכיטקטורה. CRM, כלי לחשבונית ודלפק עזרה נראים למשתמש כמו שלושה מוצרים שונים. מתחת, הם אותו קומץ פרימיטיביים: רשומות, מערכות יחסים, ציר זמן של אירועים, תפקידים והרשאות, כסף, מסמכים ואפיק הודעות. ההבדלים הם בעיקר אוצר מילים ופריסה, לא מכונות.
אנחנו לא בונים 150 מוצרים מעולים. אנחנו בונים מספר קטן של פרימיטיבים בנויים היטב, המוגדרים ב-150 דרכים.
פיצול הליבה/מודול.
כל דבר קשה חי בליבה, והוא נבנה פעם אחת: זהות, הרשאות, שכבת הנתונים הרלוונטיים, תשלומים, אחסון קבצים, חיפוש, יומן הביקורת, מערכת ההתראות, מנוע הייצוא. אלו הם החלקים שבאמת קשים ומשותפים באמת. באג שתוקן כאן תוקן עבור כל 150 המודולים בבת אחת. יכולת שנוספה כאן - למשל, חתימות אלקטרוניות - הופכת לזמינה מיידית לכל מודול שרוצה אותה.
מודול, אם כן, הוא דק בכוונה. זוהי סכימת נתונים, קבוצת תצוגות, זרימת עבודה או שתיים ואוצר המילים עבור עבודה אחת. "CRM" היא תצורה שאומרת: סוגי הרשומות הללו הם לידים ועסקאות, זו תצוגת הצינור, אלו השלבים, הנה המשמעות של המרה. הוא רוכב כולו על הליבה. מודול חדש הוא בעיקר הצהרה, לא קוד.
הכלל הקשה: הרוויח את הייחודיות שלך.
המשמעת שמונעת מזה להירקב היא כלל יחיד, שנאכף בבדיקה: אסור למודול להיות מיוחד אלא אם כן הוא באמת הרוויח אותו. בכל פעם שמודול רוצה מודל הרשאה בהתאמה אישית משלו, פורמט הודעות חד פעמי משלו, דרך פרטית משלו לאחסון תאריך - ברירת המחדל של התשובה היא לא. דחוף את זה לליבה כיכולת כללית, או אל תעשה את זה.
זה מעצבן ברגע ומכריע לאורך שנים. רוב הבקשות "צריך כאן משהו מותאם אישית" הן באמת "לא חשבנו מספיק על המקרה הכללי". כאשר אתה מכריח את המקרה הכללי, הליבה נעשית עשירה יותר, כל מודול מרוויח, ושטח הפנים שאתה צריך לשמור נשאר כמעט שטוח גם כשספירת המודולים מטפסת.
על מה ויתרנו.
לגישה הזו יש מחיר אמיתי, ועלינו למנות אותה. כלי נקודתי מהזן הטוב ביותר, שנבנה על ידי צוות אובססיבי לעבודה אחת, יכלול את המודול המקביל שלנו באותה עבודה. לפלטפורמת האימייל העמוקה ביותר יש אוטומציה שאין לנו. לכלי הפרויקט העמוק ביותר יש דעות שאין לנו. אנחנו לא מעמידים פנים אחרת.
בשביל מה אנחנו סוחרים בעומק הזה הוא קוהרנטיות - מודולים שחולקים מודל נתונים אחד, כניסה אחת, חשבון אחד, ייצוא אחד ושכבת הודעה אחת. עבור צוות של 5-50, הקוהרנטיות הזו שווה יותר מ-20% העומק האחרונים בכל קטגוריה בודדת. עבור צוות שכל העסק שלו הוא קטגוריה אחת, זה לא. אנחנו יודעים בדיוק למי אנחנו מיועדים, והארכיטקטורה היא הסיבה שאנחנו יכולים לשרת אותם עם 22 אנשים.