חוב טכני בשנה הראשונה: מה נורמלי, מה מסוכן, ואיך למנוע

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

שני סוגים של חוב

חוב טכני הוא לא דבר אחד. מדובר בשני יצורים שונים לחלוטין שקרה להם לשתף שם.

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

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

הסוג הראשון הוא כלי. הסוג השני הוא מלכודת.

חמישה דוגמאות לחוב מכוון (שבסדר גמור לסחוב)

אלה החלטות חוב שראיתי עובדות טוב בשנה הראשונה:

• ערכי קונפיגורציה hard-coded. תעביר אותם לפרמטרי סביבה כשתהיה לך סביבת פריסה שנייה. עד אז, הם בקוד. בסדר.
• אין כיסוי טסטים על ה-happy path. תוסיף טסטים לפני שהלקוח הארגוני הראשון יבקש. עד אז, אתה זזה מהר מדי והמוצר משתנה תכופות. מוצדק.
• מונוליט במקום מיקרו-שירותים. כל סטארטאפ שמתחיל עם מיקרו-שירותים מתחרט. בנה את המונוליט. פצל כשהתפרים ברורים.
• תהליכים ידניים מאחורי ממשק שנראה אוטומטי. קלאסי MVP "קוסם מאוז". המשתמש חושב שהוא מקבל תגובה אוטומטית — אתה עושה את זה ידנית. בסדר עד שיש מספיק נפח לאוטומציה.
• סכמה רלציונית פשוטה, ללא אופטימיזציה. עדיין לא יודע את פטרני השאילתות. נרמל כראוי, דלג על האינדקסים. הוסף אותם כשהשאילתות האיטיות יופיעו.

המכנה משותף: אתה יודע מה אתה עושה, יש לך תוכנית לתקן, והחוב מוגבל.

חמישה דוגמאות לחוב בשוגג (שיכאב לך)

אלה אלה שהורגים סטארטאפים בשנה השנייה:

• אין הפרדה בין טננטים. לקוח א' יכול לראות את הנתונים של לקוח ב' אם הוא יודע את ה-URL הנכון. זה לא חוב — זה אירוע אבטחה שמחכה לקרות. חייבים לתקן.
• לוגיקה עסקית בפרונטאנד. חישובי מחיר, כללי הנחה, בקרת גישה — כולם גרים ב-React components. כשתבנה אפליקציית מובייל או API, תבנה הכל מחדש.
• אין מעקב שגיאות או אובזרוואביליטי. אתה לא יודע מתי דברים מתקלקלים. המשתמשים יודעים לפניך. עד שתגלה, הם כבר עזבו.
• מיגרציות DB שאף אחד לא אחראי עליהן. כל מפתח משנה את הסכמה כשצריך. אין קבצי מיגרציה. אין תוכנית rollback.
• סודות בקוד. מפתחות API, סיסמות בסיס נתונים, מפתח סודי של Stripe — בהיסטוריית git. לנצח.

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

איך למנוע את הסוג המסוכן

שלוש פרקטיקות שעולות כמעט כלום וחוסכות כאב עצום:

שמור קובץ `TECH_DEBT.md` בריפו. בכל פעם שמישהו עושה קיצור דרך, מוסיפים שורה: מה נעשה, למה, ומה הפתרון הנכון נראה כמוה. לוקח 90 שניות. יוצר שביל נייר. אומר שה"נתקן אחר כך" באמת מתוקן אחר כך.

סקירת חוב דו-שבועית של 30 דקות. לא ספרינט מלא. לא ספרינט חוב רבעוני (אלה לעולם לא קורים). שלושים דקות, כל שבועיים, קוראים את הקובץ. בוחרים פריט אחד. מתקנים באותו ספרינט.

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

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

כל השאר ניתן לניהול. השלושה האלה — לא.

שינוי המסגרת המנטלית

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

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

עוד דבר אחד

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

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

— בוריס