כשהאפליקציה שבניתם עם בינה מלאכותית צומחת מעבר לגרסה הראשונה: שיפוץ קוד מול כתיבה מחדש

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

הרגע שאתם מבינים שהאפליקציה מצליחה

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

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

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

מה שיפוץ קוד קונה ועולה

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

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

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

מה כתיבה מחדש קונה ועולה

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

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

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

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

שלוש שאלות לבחור ביניהן

שאלה 1: האם הצורה המרכזית עדיין נכונה?

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

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

שאלה 2: אם תשפצו היום, כמה חודשים נוספים עד שהחיכוך יחזור?

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

שאלה 3: על מה המשתמשים שלכם באמת תלויים?

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

המסלול שבדרך כלל עובד

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

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

הזמן הנכון להחליט

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