פעם היה לרעיונות מסנן טבעי. פיתוח היה יקר. אם רצית feature חדש, היית צריך זמן, מפתח, תקציב ותכנון.
היום אפשר לפתוח Codex, Claude או כלי אחר ולראות prototype עובד הרבה לפני שסיימת להחליט אם בכלל היית צריך אותו.
זה כיף. וזה מסוכן.
ב-Studio Haim אחת השאלות שאנחנו מנסים לשאול יותר ויותר היא לא: אפשר לבנות את זה? אלא: מה הדבר הזה צריך להיות, אם בכלל?
רעיון לא חייב להפוך לפיצ'ר
זו הבחנה פשוטה שעזרה לנו בכמה פרויקטים.
רעיון יכול להיות פסקה, כרטיס, עמוד, כלי, feature, מוצר עצמאי, או הערה במסמך שנשארת שם.
העובדה שאפשר לייצר לו route חדש בתוך עשר דקות לא אומרת ש-route הוא הצורה הנכונה.
Reality Check כמעט נפל בדיוק למלכודת הזאת
כשהתחלנו לחשוב איך להכניס את Reality Check להירו של Studio Haim, אפשר היה להמשיך מהר מאוד.
Input שבו המשתמש מדביק URL. סריקה חיה. Progress bar. כמה פסקי דין. Replay אוטומטי. Dashboard. אולי אפילו "בדוק את האתר שלך עכשיו".
אבל זה היה משנה את המשימה.
המטרה לא הייתה לבנות Reality Check נוסף בתוך ההירו. המטרה הייתה להראות איך Studio Haim חושב.
לכן צמצמנו. כתובת אחת: studio-haim.com. תסריט אחד. שלושה signals. פסק דין אחד. יעד אחד: /reality-check.
אחרי עשר שניות האנימציה נעצרת. בלי loop אינסופי. בלי URL input. בלי מוצר חדש בתוך עמוד הבית.
זה ההבדל בין feature לבין demonstration.
גם BY+ לימד אותנו לחכות
בפרויקטים אחרים עלתה אותה שאלה בצורה אחרת. למשל: מפה.
מפה יכולה להיראות מצוין במוצר מקומי. אבל מפה ריקה כמעט לא נותנת ערך.
אם עדיין אין מספיק עסקים או נקודות כדי שהמפה תהיה שימושית, אין סיבה לבנות אותה רק כדי לסמן שיש "map feature".
אותו דבר לגבי אפליקציה native. אם PWA מספקת כרגע את הצורך ואין עדיין שימוש שמצדיק מוצר native, אפליקציה היא לא בהכרח השלב הבא. היא פשוט יותר תחזוקה.
יש גם רעיונות טובים שלא צריכים להיכנס למוצר הנוכחי
עוד מלכודת היא לקחת רעיון טוב ולדחוף אותו למקום הלא נכון.
למשל, רעיון צד יכול להיות מעניין בפני עצמו - ועדיין לא להשתייך ל-BY+.
אם כל רעיון נכנס למערכת המרכזית, המוצר מתחיל לאבד זהות. ואם על כל רעיון פותחים project חדש, גם הסטודיו מתחיל להתפזר.
לכן אחת ההחלטות הכי שימושיות היא: רעיון טוב. לא עכשיו.
זה לא כישלון של הרעיון. זו החלטת מוצר.
ארבע שאלות לפני שבונים
איזו בעיה זה פותר?
לא "מה הפיצ'ר עושה?" אלא מה קורה למשתמש היום שלא עובד מספיק טוב. אם אין תשובה ברורה, כנראה מוקדם לבנות.
האם הצורה שאנחנו מציעים היא הקטנה ביותר שעובדת?
אולי לא צריך dashboard. אולי צריך status קטן. אולי לא צריך כלי. אולי צריך דוגמה. אולי לא צריך עמוד. אולי צריך פסקה. אנחנו מחפשים את הצורה הקטנה ביותר שמספקת את הערך.
מה נצטרך לתחזק אחרי שההתלהבות תיגמר?
זה החלק ש-AI מסתיר מצוין. אפשר לבנות feature ביום. אבל אחר כך יש tests, mobile, accessibility, analytics, SEO, data, states, errors, dependencies, documentation. כל feature חדש הוא התחייבות. גם אם עלות ה-generation שלו הייתה כמעט אפס.
מה יקרה אם פשוט לא נבנה אותו?
זו אולי השאלה הכי טובה. אם התשובה היא "שום דבר משמעותי" - יש סיכוי טוב שמצאנו את התשובה.
לפעמים "לא" הוא הפיצ'ר
העיקרון הזה נכנס גם ל-Reality Check. הכלי לא אמור להמליץ לשנות כל דבר. הוא צריך לדעת להגיד: זה עובד. אל תיגע.
אותו הדבר נכון לסטודיו עצמו. אנחנו לא רוצים למדוד התקדמות לפי מספר העמודים, הפיצ'רים או הפרויקטים שנוספו.
לפעמים התקדמות היא מערכת שנשארה קטנה.
AI שינה את צוואר הבקבוק
פעם צוואר הבקבוק היה בנייה. היום, בהרבה מקרים, צוואר הבקבוק הוא שיקול דעת.
אפשר לייצר חמש גרסאות. אפשר לפתוח route. אפשר לבנות dashboard. אפשר להפוך רעיון קטן ל-SaaS לפני ארוחת ערב.
השאלה היא אם צריך.
מה לקחנו מזה
לפני שאנחנו שואלים איך לבנות משהו, אנחנו מנסים לשאול: האם זה צריך להיות מוצר, פיצ'ר, עמוד, רכיב קטן - או פשוט לא להיבנות עכשיו?
AI גרם לבנייה להיות זולה. הוא לא הפך מורכבות לחינם.