משרבוט על מפית לאפליקציה שעובדת: איך לבנות תוכנה מרעיון בעזרת בינה מלאכותית

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

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

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

התחילו בפועל, לא בשם העצם

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

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

• “מטייל כלבים פותח את האפליקציה ורואה את ההזמנות שלו להיום”
• “בעל כלב בוחר זמן ומזמין טיול”
• “המטייל מסמן טיול כמושלם והבעלים מקבל תמונה”

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

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

הניסיון השני שלו פירט מה הוא באמת עשה כל יום:

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

התיאור השני הזה הניב משהו שהוא יכל להשתמש בו תוך שעות.

בנו מסך אחד קודם

אולי יש לכם עשר יכולות בראש. בנו אחת.

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

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

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

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

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

תארו את זה כאילו אתם מסבירים לחבר

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

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

כמה תיאורים שעובדים טוב:

• “כשהם לוחצים ‘הזמן’, בדוק אם הזמן עדיין פנוי. אם כן, אשר אותו. אם מישהו אחר חטף אותו, הראה הודעה והצע את הזמן הפנוי הקרוב ביותר.”
• “לוח הבקרה צריך להראות שלושה מספרים בראש: סך הלקוחות, מפגשים השבוע, והכנסה החודש. מתחת לזה, רשימה של מפגשי היום עם שם הלקוח והזמן.”
• “אחרי מפגש, אני רוצה להקליד מה עשינו — כמו ‘סקוואט 3x10 80 ק”ג, לחיצת חזה 3x8 60 ק”ג’ — ושזה יישמר להיסטוריה של הלקוח הזה.”

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

השתמשו בזה, ואז תקנו את זה

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

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

1. הזמנים הוצגו בבלוקים של 30 דקות, אבל המפגשים שלו היו 50 דקות
2. לא הייתה דרך ללקוח לבטל בלי לשלוח לו הודעה ישירות
3. הודעת האישור הייתה באנגלית, אבל הלקוחות שלו דוברי ספרדית

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

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

הראו את זה למישהו שהוא לא אתם

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

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

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

השיקו לפני שאתם מוכנים

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

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

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

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

המערכת הקודמת שלו הייתה Google Calendar, גיליון Google, ורשימת תפוצה ב-WhatsApp. זה עבד, אבל טעויות הזמנה קרו מדי שבוע כי לקוחות שכחו לבדוק את לוח השנה לפני שביקשו זמן.

שלוש טעויות שמאיטות אנשים

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

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

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

המחסום האמיתי מעולם לא היה טכני

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

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

אם אתם יכולים להסביר את זה לחבר, אתם יכולים לבנות את זה.

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