מתי לבנות מחדש את האפליקציה שבניתם עם בינה מלאכותית (ומתי להמשיך לשכלל)

האפליקציה שצמחה הצידה

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

היא שאלה אותי: “באיזו נקודה כדאי לי פשוט להתחיל מחדש?”

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

למה בנייה מחדש מרגישה מפתה (גם כשהיא שגויה)

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

האינסטינקט הזה בדרך כלל שגוי.

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

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

שלושה סימנים שאתם באמת צריכים לבנות מחדש

1. הרעיון המרכזי השתנה, לא רק הפיצ’רים

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

השאלה לשאול: האם הייתי מתאר את האפליקציה הזו באותה דרך שתיארתי אותה כשבניתי אותה לראשונה?

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

2. הבינה המלאכותית כבר לא מוצאת את הדרך באפליקציה

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

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

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

3. לאפליקציה יש משתמשים אבל היא מעכבת אותם

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

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

מה לעשות לפני שאתם בונים מחדש

גם אם החלטתם לבנות מחדש, עשו את זה קודם:

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

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

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

מתי להמשיך לשכלל (רוב הזמן)

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

העיצוב שלכם נראה מיושן? שכללו — רענון עיצוב הוא 100% אפשרי בכלי בינה מלאכותית בלי לגעת בלוגיקה הבסיסית.

פיצ’ר מרכזי מרגיש מסורבל? שכללו — בנו מחדש רק את הפיצ’ר הזה, לא את כל האפליקציה.

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

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

האפליקציה של מריה

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

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

שישה חודשים של פיצ’רים מצטברים, לא אבודים.

השאלה האמיתית

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

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

תתחילו שם. בנייה מחדש תמיד זמינה. היא עדיין תהיה שם בעוד שבוע.

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