چطور با هوش مصنوعی یک اپ بسازیم: از یک طرح روی دستمالکاغذی تا یک محصول کارآمد
ماریا یک استودیوی کوچک یوگا در آستین دارد. او یک مشکل داشت: مشتریها مدام برایش پیامک میفرستادند تا برای کلاسها وقت بگیرند، و او داشت پیگیری اینکه چه کسی برای چه کلاسی ثبتنام کرده را از دست میداد. او یک اپ رزرو ساده میخواست — چیزی که در آن مشتریها بتوانند برنامه را ببینند، یک کلاس انتخاب کنند و یک تأییدیه دریافت کنند.
یک سال پیش، این یعنی استخدام یک برنامهنویس فریلنسر (۳٬۰۰۰ تا ۸٬۰۰۰ دلار برای چیزی پایهای)، انتظار ۴ تا ۶ هفته، و امید به اینکه نتیجه با آنچه در ذهنش بود مطابقت داشته باشد. امروز، ماریا آنچه میخواست را برای یک اپساز هوش مصنوعی توصیف کرد و تا ظهر یک صفحهٔ رزرو کارآمد داشت.
این یک فرض خیالی نیست. مردم هر هفته با ابزارهای هوش مصنوعی اینچنین اپ میسازند. این هم اینکه فرایند واقعاً چطور کار میکند، گام به گام، برای هر کسی که مدتی روی یک ایده نشسته اما کد نمینویسد.
با مشکل شروع کنید، نه با فناوری
رایجترین اشتباهی که مردم وقتی برای اولین بار میخواهند با هوش مصنوعی یک اپ بسازند مرتکب میشوند، شروع کردن از قابلیتهاست. «میخواهم یک داشبورد با نمودار و یک صفحهٔ ورود و یک پایگاه داده داشته باشم.» از اینجا شروع نمیکنید.
شما با مشکل شروع میکنید. آن را در یک یا دو جمله بنویسید:
- «مشتریهایم نمیتوانند بدون پیامک مستقیم به من برای کلاسهای یوگا وقت بگیرند.»
- «باید پیگیری کنم کدام تأمینکنندهها پولشان پرداخت شده و کدام فاکتورها معوقاند.»
- «تیم ما هر صبح ۲۰ دقیقه را هدر میدهد تا بفهمد چه کسی روی چه چیزی کار میکند.»
آن جمله، کل بریف شماست. اپسازها وقتی بهترین عملکرد را دارند که به جای فهرستی از الزامات فنی، یک مشکل روشن برای حل کردن به آنها بدهید. هوش مصنوعی الزامات فنی را خودش درمیآورد — کل ماجرا همین است.
همانطور توصیفش کنید که برای یک دوست توصیف میکنید
وقتی مشکل را داشتید، راهحلتان را همانطور توصیف کنید که سر یک فنجان قهوه برای کسی توضیحش میدهید. نه با اصطلاحات فنی. فقط اینکه چه کاری باید انجام دهد و برای چه کسی است.
برای استودیوی یوگای ماریا، چیزی شبیه این بود:
«یک صفحه میخواهم که مردم بتوانند کلاسهای این هفته را ببینند — زمان، نوع کلاس، و اینکه چند جای خالی مانده. باید بتوانند روی یک کلاس کلیک کنند و با نام و ایمیلشان ثبتنام کنند. میخواهم فهرستی از کسانی که برای هر کلاس ثبتنام کردهاند را ببینم تا بتوانم برنامهریزی کنم. همین.»
سه جمله. هیچ اشارهای به پایگاه داده، API، چارچوبهای احراز هویت یا خطوط لولهٔ استقرار نیست. اپساز این توصیف را میگیرد و اینها را تولید میکند:
- یک نمای برنامه با کارتهای کلاس
- یک فرم ثبتنام که نام و ایمیل را میگیرد
- یک نمای مدیریتی که شرکتکنندگان هر کلاس را نشان میدهد
- ذخیرهسازی داده برای ماندگار کردن رزروها
نسخهٔ اول بینقص نخواهد بود. هیچوقت نیست. اما یک چیز واقعی و کارآمد است که میتوانید در آن کلیک کنید و آزمایشش کنید — نه یک ماکاپ، نه یک وایرفریم.
حلقهٔ بازخورد همه چیز را عوض میکند
اینجا جایی است که ساختن با هوش مصنوعی با کار کردن با یک برنامهنویس فرق دارد. با یک برنامهنویس، شما یک سند مشخصات مینویسید، او دو هفته میرود و بعد نتیجه را میبینید. اگر چیزی ایراد داشته باشد، وارد چرخههای بازنگری میشوید که هزینهٔ زمان و پول دارد.
با یک اپساز، حلقهٔ بازخورد با دقیقه سنجیده میشود. به آنچه تولید کرده نگاه میکنید و میگویید:
- «فرم ثبتنام باید شمارهٔ تلفن هم بپرسد.»
- «میشود وقتی کسی رزرو میکند یک ایمیل تأیید اضافه کنی؟»
- «برنامه باید دو هفتهٔ بعد را نشان بدهد، نه فقط این هفته را.»
هر تغییر چند دقیقه طول میکشد. منتظر یک چرخهٔ اسپرینت نیستید. در زمان واقعی تکرار میکنید و محصول را به سمت آنچه واقعاً نیاز دارید هدایت میکنید.
این طرز فکر شما دربارهٔ ساختن نرمافزار را عوض میکند. لازم نیست الزامات را از همان ابتدا درست درآورید. میتوانید مبهم شروع کنید و همانطور که محصول شکل میگیرد، دقیق شوید. برای کسی مثل ماریا، که دقیقاً میداند مشتریهایش به چه نیاز دارند اما هرگز یک سند الزامات محصول ننوشته، این تفاوت میان «باید این را بسازم» و «همین الان این را ساختم» است.
سه چیزی که اپسازها از پسش برمیآیند و در غیر این صورت به یک برنامهنویس نیاز داشتید
ذخیرهسازی داده. هر اپی باید اطلاعات را جایی ذخیره کند — رزروها، پروفایلهای کاربری، سوابق موجودی، هر چه باشد. راهاندازی یک پایگاه داده قبلاً نیاز به انتخاب میان Postgres، MySQL، MongoDB، پیکربندی اسکیماها و نوشتن کوئریها داشت. اپسازها این را بهصورت خودکار و بر اساس مدل دادهٔ شما فراهم میکنند.
طراحیای که افتضاح نیست. برای یک اپ ساده لازم نیست یک طراح استخدام کنید. اپسازها چیدمانهای تمیز و واکنشگرا تولید میکنند — فاصلهگذاری مناسب، فونتهای خوانا، شبکههای سازگار با موبایل. صفحهٔ رزرو ماریا شبیه چیزی به نظر میرسید که یک آژانس طراحی ساخته باشد، نه یک پروژهٔ آخر هفته. میتوانید رنگها را سفارشی کنید و لوگوی خودتان را اضافه کنید، اما حالتهای پیشفرض از همان روز اول کار میکنند.
استقرار. رساندن یک اپ از لپتاپ شما به یک URL که هر کسی بتواند بازدیدش کند، قبلاً درگیر پیکربندی سرور، رکوردهای DNS، گواهیهای SSL و کلی فحش دادن به پیامهای خطای ترمینال بود. حالا یک کلیک است. اپ شما یک URL عمومی میگیرد، روی موبایل و دسکتاپ کار میکند، و آن را همانطور به اشتراک میگذارید که یک Google Doc را — فقط لینک را بفرستید.
اپسازها در چه چیزی بد هستند (صادقانه)
هیچ ابزاری در همه چیز خوب نیست، و وانمود کردن به خلافش به هیچکس کمک نمیکند.
منطق کسبوکار پیچیده. اگر اپ شما باید حق بیمه را بر اساس ۴۷ متغیر و سه چارچوب قانونی محاسبه کند، یک اپساز به مشکل میخورد. هرچه منطق شما بیشتر خاص یک حوزه و قانونمحور باشد، احتمال اینکه به کد سفارشی یا یک ابزار تخصصی نیاز پیدا کنید بیشتر است.
یکپارچهسازی با سیستمهای ناشناخته. اتصال به Stripe، Google Calendar یا APIهای رایج؟ معمولاً اشکالی ندارد. اتصال به سیستم ERP اختصاصی شرکت شما از سال ۲۰۰۸؟ احتمالاً همینطوری از کار درنمیآید.
اپهایی با نیازهای سنگین بلادرنگ. یک تختهٔ سفید مشارکتی که ۵۰ نفر همزمان روی آن نقاشی میکشند، یا یک پلتفرم معاملاتی با تأخیر در حد میلیثانیه؟ اینها چالشهای مهندسیاند که به راهحلهای مهندسی نیاز دارند. اپسازها برای ۸۰٪ اپهایی که این محدودیتها را ندارند عالیاند.
نقطهٔ ایدهآل، ابزارهایی است که به تیمهای کوچک یا افراد کمک میکند کاری را که حالا دستی انجام میدهند انجام دهند — زمانبندی، پیگیری، سازماندهی، ارتباط. اگر اپ شما با این توصیف جور درمیآید، وضعیتتان خوب است.
یک مثال عملی: ساختن یک پورتال مشتری در یک بعدازظهر
بیایید یک مثال مفصلتر را با هم مرور کنیم. فرض کنید یک مشاور فریلنسر هستید و یک پورتال میخواهید که مشتریها بتوانند در آن:
- پروژههای فعالشان و وضعیتشان را ببینند
- اسناد را آپلود کنند (قراردادها، بریفها، فایلها)
- فاکتورها و سابقهٔ پرداختها را ببینند
- بدون رفتن سراغ ایمیل برایتان پیام بفرستند
این هم اینکه آن بعدازظهر چطور میگذرد:
ساعت ۱: شما پورتال را برای اپساز توصیف میکنید. یک نسخهٔ اول با چهار صفحه میگیرید — پروژهها، اسناد، فاکتورها، پیامها. چیدمان تمیز اما عمومی است.
ساعت ۲: سفارشیسازی میکنید. «وضعیت پروژه را بصریتر کن — برای رویروال سبز، برای درخطر زرد، برای متوقف قرمز میخواهم.» لوگو و رنگهای برندتان را اضافه میکنید. چیدمان فاکتور را طوری تنظیم میکنید که با قالب موجودتان جور دربیاید.
ساعت ۳: آزمایش میکنید. یک پروژهٔ نمونه میسازید، یک سند آپلود میکنید، برای خودتان یک پیام میفرستید. متوجه میشوید که آپلود سند اندازهٔ فایل را نشان نمیدهد — درخواستش را میدهید. میفهمید که میخواهید مشتریها بتوانند روی پروژهها نظر بگذارند — آن را اضافه میکنید.
ساعت ۴: منتشر میکنید و لینک را برای اولین مشتریتان میفرستید. او وارد میشود، پروژهاش را میبیند و یک فایل آپلود میکند. کار میکند.
چهار ساعت. بدون برنامهنویس. بدون آژانس طراحی. بدون سربار مدیریت پروژه. پورتال به اندازهٔ چیزی که یک تیم شش هفته رویش کار کرده صیقلی نیست، اما هر کاری که نیاز دارید را انجام میدهد و امروز وجود دارد، نه سهماههٔ بعد.
پرسش واقعی این نیست که «آیا میتوانم این را بسازم؟»
این است که «اگر ساختن آسان بود، چه میساختم؟»
اکثر مردم کمبود ایده ندارند. آنها کمبود یک مسیر واقعبینانه از ایده تا محصول کارآمد دارند. وقتی آن مسیر از دل استخدام برنامهنویس، مدیریت زمانبندی و خرج کردن هزاران دلار میگذرد، اکثر ایدهها در تودهای از «یک روزی» میمیرند.
وقتی مسیر «توصیفش کن و یک بعدازظهر تکرار کن» است، حسابوکتاب عوض میشود. مربی یوگا یک صفحهٔ رزرو میسازد. مشاور یک پورتال مشتری میسازد. سازمان غیرانتفاعی یک ابزار هماهنگی داوطلبان میسازد. رستوران کوچک یک سیستم سفارشگیری میسازد.
هیچکدام از اینها محصول نرمافزاری میلیارد دلاری نیستند. آنها ابزارهای عملیاند که مشکلات واقعی را برای آدمهای واقعی حل میکنند. و وجود دارند چون دانستن اینکه چطور با هوش مصنوعی یک اپ بسازیم یعنی مانع حالا تخیل شماست، نه مهارت فنیتان.
اگر مدتی روی یک ایده نشستهاید، این را امتحان کنید: یک اپساز هوش مصنوعی باز کنید، سادهترین نسخهٔ آنچه میخواهید را در دو یا سه جمله توصیف کنید، و ببینید چه برمیگردد. هدفتان بینقص بودن نباشد — هدفتان «آیا این همان کاری را که نیاز دارم انجام میدهد؟» باشد. همیشه میتوانید از همانجا تکرار کنید. کل ماجرا همین است.