از طرح روی دستمال‌کاغذی تا اپ کارآمد: چطور با هوش مصنوعی از یک ایده نرم‌افزار بسازیم

همه ایدهٔ اپ دارند. اکثرشان در مرحلهٔ «این می‌توانست باحال باشد» می‌میرند — نه به این دلیل که ایده‌ها بد هستند، بلکه چون فاصلهٔ بین «می‌خواهم این وجود داشته باشد» و «این وجود دارد» زمانی به استخدام یک برنامه‌نویس یا یادگیری کدنویسی نیاز داشت. هیچ‌کدامشان یک بعدازظهر سه‌شنبه اتفاق نمی‌افتند.

آن فاصله از همیشه کوچک‌تر است. سازنده‌های اپ هوش مصنوعی به شما اجازه می‌دهند آنچه می‌خواهید را به زبان ساده توصیف کنید و یک اپ کارآمد پس بگیرید — پایگاه داده، رابط، منطق، همه‌اش. می‌توانید از یک ایده در عرض چند ساعت، نه چند ماه، یک اپ بسازید.

اما «آنچه می‌خواهید را توصیف کنید» در آن جمله بار سنگینی به دوش می‌کشد. بخش سخت هرگز کدنویسی نبود. فهمیدن این بود که واقعاً به چه نیاز دارید.

با فعل شروع کنید، نه با اسم

اکثر مردم ایدهٔ اپشان را به‌عنوان یک چیز توصیف می‌کنند: «مثل Uber برای سگ‌گردانی» یا «یک ابزار مدیریت پروژه برای فریلنسرها». این یک ارائه است، نه یک مشخصات. یک سازندهٔ هوش مصنوعی نمی‌تواند با آن کار زیادی بکند چون یک دسته را توصیف می‌کند، نه یک رفتار.

با کاری که مردم با اپ شما خواهند کرد شروع کنید. سه تا پنج کنش بنویسید:

  • «یک سگ‌گردان اپ را باز می‌کند و رزروهای امروزش را می‌بیند»
  • «یک صاحب سگ یک بازهٔ زمانی انتخاب می‌کند و یک گردش رزرو می‌کند»
  • «سگ‌گردان یک گردش را تکمیل‌شده علامت می‌زند و صاحب سگ یک عکس می‌گیرد»

این‌ها قابل‌ساخت‌اند. هر کدام به یک صفحه، یک جدول پایگاه داده و یک تکه منطق نگاشت می‌شود. سازندهٔ هوش مصنوعی به ارائهٔ آسانسوری شما نیاز ندارد — به فهرست کارهای شما نیاز دارد.

کارلوس، یک مربی شخصی در مکزیکوسیتی، یک اپ می‌خواست که مشتری‌هایش بتوانند جلسه رزرو کنند و تمرین‌هایشان را دنبال کنند. تلاش اولش این بود: «برایم یک اپ تناسب اندام بساز». نتیجه یک کتابخانهٔ تمرین عمومی با برنامه‌های تمرین آماده بود — هیچ شباهتی به آنچه نیاز داشت نداشت.

تلاش دومش آنچه را واقعاً هر روز انجام می‌داد فهرست کرد:

۱. مشتری‌ها بازه‌های زمانی در دسترس هفته را می‌بینند ۲. یک بازه رزرو می‌کنند و یک تأیید WhatsApp می‌گیرند ۳. پس از هر جلسه، کارلوس آنچه را انجام دادند ثبت می‌کند (تمرین‌ها، ست‌ها، وزن) ۴. مشتری‌ها تاریخچه‌شان را باز می‌کنند و پیشرفت در طول زمان را می‌بینند

آن توصیف دوم چیزی تولید کرد که او در عرض چند ساعت می‌توانست از آن استفاده کند.

اول یک صفحه بسازید

شاید ده قابلیت در ذهنتان داشته باشید. یکی را بسازید.

صفحه‌ای را انتخاب کنید که به مشکل اصلی نزدیک‌ترین است — کاری که اپ شما انجام می‌دهد و هیچ چیز دیگری نمی‌کند، یا چیزی که مردم بیشتر از همه از آن استفاده می‌کنند. برای کارلوس، آن صفحهٔ رزرو بود. هر چیز دیگر (ثبت تمرین، نمودارهای پیشرفت، اعلان‌ها) می‌توانست بعداً بیاید.

وقتی با یک صفحه شروع می‌کنید، سه چیز خوب اتفاق می‌افتد.

یاد می‌گیرید سازنده چطور فکر می‌کند. هر سازندهٔ هوش مصنوعی دربارهٔ چیدمان، ساختار داده و الگوهای تعامل نظراتی دارد. ساختن یک صفحه به شما یاد می‌دهد چطور با آن ارتباط بگیرید — کدام توصیف‌ها نتایج خوب تولید می‌کنند و کدام‌ها به جزئیات بیشتری نیاز دارند.

سریع چیزی قابل‌استفاده به دست می‌آورید. یک صفحه که کار می‌کند بسیار مفیدتر از ده صفحهٔ نیمه‌کاره است. کارلوس مشتری‌هایش در عرض دو ساعت در حال رزرو جلسه بودند. ثبت تمرین سه روز بعد آمد. اگر سعی کرده بود همه چیز را یک‌جا بسازد، هنوز در حال تنظیم بود.

کشف می‌کنید واقعاً به چه نیاز دارید. قابلیت‌هایی که پیش از ساختن فکر می‌کنید مهم‌اند، به‌ندرت همان‌هایی هستند که بعد از شروع استفاده اهمیت پیدا می‌کنند. کارلوس فرض می‌کرد نمودارهای پیشرفت قابلیت کشنده خواهند بود. مشتری‌هایش بیشتر به توانایی جابه‌جا کردن یک رزرو در دو ضربه اهمیت می‌دادند.

طوری توصیف کنید که انگار برای یک دوست توضیح می‌دهید

وقتی با یک سازندهٔ هوش مصنوعی صحبت می‌کنید، تظاهر کنید دارید اپ را برای دوستی توضیح می‌دهید که قرار است آن را برایتان بسازد. نمی‌گویید «یک API رزرو RESTful با تشخیص تعارض پیاده کن». می‌گویید «وقتی کسی یک بازهٔ زمانی را انتخاب می‌کند که از قبل گرفته شده، به‌جایش بازهٔ در دسترس بعدی را نشانش بده».

زبان ساده بهتر از زبان فنی کار می‌کند چون نتایج را توصیف می‌کند، نه پیاده‌سازی‌ها را. هوش مصنوعی پیاده‌سازی را می‌فهمد. کار شما این است که دربارهٔ آنچه کاربر می‌بیند و انجام می‌دهد دقیق باشید.

چند توصیف که خوب کار می‌کنند:

  • «وقتی روی “رزرو” کلیک می‌کنند، بررسی کن آیا زمان هنوز در دسترس است. اگر بود، تأییدش کن. اگر کس دیگری آن را گرفت، یک پیام نشان بده و نزدیک‌ترین بازهٔ باز را پیشنهاد بده.»
  • «داشبورد باید سه عدد را در بالا نشان دهد: کل مشتری‌ها، جلسات این هفته، و درآمد این ماه. زیر آن، فهرستی از جلسات امروز با نام مشتری و زمان.»
  • «بعد از یک جلسه، می‌خواهم آنچه انجام دادیم را تایپ کنم — مثل “اسکوات ۳×۱۰ ۸۰ کیلو، پرس سینه ۳×۸ ۶۰ کیلو” — و در تاریخچهٔ آن مشتری ذخیره شود.»

الگو در هر کدام: چه کسی چه کاری می‌کند، کِی، و بعدش چه اتفاقی می‌افتد.

از آن استفاده کنید، بعد درستش کنید

نسخهٔ اول هر چیزی به شکل‌هایی غلط خواهد بود که نمی‌توانستید پیش‌بینی کنید. این یک شکست نیست — این فرایند است. مزیت ساختن با هوش مصنوعی این نیست که بار اول درستش می‌کنید. این است که درست کردن چیزها به‌جای هفته‌ها چند دقیقه طول می‌کشد.

وقتی کارلوس نسخهٔ اول صفحهٔ رزروش را دید، سه چیز اذیتش کرد:

۱. بازه‌های زمانی در بلوک‌های ۳۰ دقیقه‌ای نشان داده می‌شدند، اما جلسات او ۵۰ دقیقه بودند ۲. هیچ راهی برای مشتری نبود که بدون پیام مستقیم به او لغو کند ۳. پیام تأیید به انگلیسی بود، اما مشتری‌هایش اسپانیایی صحبت می‌کنند

هر اصلاح کمتر از ده دقیقه طول کشید. او مشکل را توصیف می‌کرد، سازنده تنظیم می‌کرد، و او پیش می‌رفت. با یک شرکت توسعهٔ سنتی، هر کدام از این‌ها یک تیکت پشتیبانی و یک انتظار می‌بود.

عادت کلیدی: پیش از نشان دادن اپ خودتان به هر کس دیگری، از آن استفاده کنید. هر دکمه را کلیک کنید. هر فرم را پر کنید. سعی کنید بشکنیدش. اشکالاتی که خودتان پیدا می‌کنید ارزان‌تر از آن‌هایی هستند که کاربرانتان برایتان پیدا می‌کنند.

آن را به کسی که خودتان نیستید نشان دهید

وقتی به‌اندازهٔ کافی از آن استفاده کردید که به آن اعتماد کنید، آن را جلوی یک کاربر واقعی بگذارید. نه پنج تا. نه ده تا. یکی.

کارلوس لینک رزرو را اول به راحت‌ترین مشتری‌اش با فناوری داد. او یک جلسه رزرو کرد، جابه‌جایش کرد، و بعد به او پیام داد: «کجا می‌توانم ببینم هفتهٔ پیش چه کار کردیم؟» او هنوز نمای تاریخچهٔ تمرین را نساخته بود. اما حالا دقیقاً می‌دانست قابلیت بعدی را چه بسازد — نه از روی حدس، بلکه از روی تماشای یک آدم واقعی که سعی می‌کرد کار واقعی‌ای انجام دهد و به یک دیوار خورد.

یک کاربر به شما می‌گوید چه چیزی گیج‌کننده است. پنج کاربر به شما می‌گویند چه چیزی محبوب است. قبل از اینکه نوع دوم بازخورد مفید باشد به نوع اول نیاز دارید.

پیش از آماده شدن راه‌اندازی کنید

اپ شما برای مفید بودن لازم نیست کامل باشد. لازم است یک مشکل را آن‌قدر خوب حل کند که کسی به‌جای آنچه اکنون انجام می‌دهد — که احتمالاً یک صفحهٔ گسترده، یک گروه WhatsApp، یا اصلاً هیچ چیز است — از آن استفاده کند.

کارلوس سیستم رزروش را برای هر ۱۵ مشتری با فقط سه قابلیت راه‌اندازی کرد: رزرو یک بازه، لغو یک بازه، و دیدن جلسات پیش رو. بدون ثبت تمرین. بدون نمودارهای پیشرفت. بدون یکپارچه‌سازی پرداخت.

او آن‌ها را در هفته‌های بعدی، یک قابلیت در هر زمان، بر اساس آنچه مشتری‌هایش واقعاً می‌خواستند اضافه کرد. ثبت تمرین بعد از اینکه سه مشتری در یک هفته آن را خواستند ساخته شد. یکپارچه‌سازی پرداخت یک ماه بعد آمد، وقتی کارلوس فهمید هنوز هزینه‌ها را نقدی و با Venmo جمع می‌کند.

شش هفته بعد از آن اولین بعدازظهر شنبهٔ ساختن، اپی داشت که ۱۵ مشتری پولی روزانه از آن استفاده می‌کردند. رزروها را مدیریت می‌کرد، تمرین‌ها را دنبال می‌کرد، پیشرفت را نشان می‌داد و یادآور قرار می‌فرستاد. شاید در مجموع ۲۰ ساعت — پخش‌شده در عصرها و آخر هفته‌ها — و ۰ دلار صرف توسعه کرده بود.

سیستم قبلی‌اش یک Google Calendar، یک Google Sheet و یک فهرست پخش WhatsApp بود. کار می‌کرد، اما اشتباهات رزرو هفتگی اتفاق می‌افتاد چون مشتری‌ها قبل از درخواست یک زمان فراموش می‌کردند تقویم را چک کنند.

سه اشتباه که آدم‌ها را کند می‌کنند

تلاش برای ساختن کل چیز یک‌جا. با یک صفحه شروع کنید. کارش بیندازید. بعد چیز بعدی را اضافه کنید. خزش محدوده بیشتر از کد بد ایده‌های اپ را می‌کشد.

کپی کردن یک رقیب به‌جای توصیف گردش‌کار خودتان. اگر اپتان را «مثل Calendly اما برای مربیان شخصی» توصیف کنید، یک کلون Calendly با رنگ‌های متفاوت می‌گیرید. به‌جایش گردش‌کار واقعی‌تان را توصیف کنید و چیزی می‌گیرید که با شیوهٔ کار شما جور است، نه با شیوه‌ای که Calendly تصمیم گرفت باید کار کنید.

انتظار برای کمال. نسخهٔ اول شما لبه‌های ناهموار خواهد داشت. به‌هرحال منتشرش کنید. از چهرهٔ گیج یک کاربر واقعی بیشتر یاد می‌گیرید تا از یک هفته صیقل دادن صفحه‌هایی که هیچ‌کس امتحانشان نکرده.

مانع واقعی هرگز فنی نبود

پیش از وجود سازنده‌های اپ هوش مصنوعی، اگر ایده‌ای داشتید و نمی‌توانستید کد بزنید سه گزینه داشتید: یاد گرفتن کدنویسی (ماه‌ها)، استخدام یک برنامه‌نویس (هزاران دلار)، یا رها کردن ایده (رایگان). اکثر مردم گزینهٔ سوم را انتخاب می‌کردند — نه به این دلیل که ایده‌هایشان بد بود، بلکه چون دو گزینهٔ دیگر از نظر زمان یا پول گران بودند.

حالا می‌توانید از یک ایده در عرض یک روز یک اپ بسازید. نه یک نمونهٔ اولیه. نه یک ماکاپ. یک اپ کارآمد با پایگاه داده، حساب کاربری و منطق واقعی. مانع دیگر فنی نیست. وضوح است — می‌توانید آنچه نیاز دارید را آن‌قدر دقیق توصیف کنید که یک هوش مصنوعی بتواند بسازدش؟

اگر می‌توانید برای یک دوست توضیحش دهید، می‌توانید بسازیدش.

اگر روی یک ایده نشسته‌اید، آن را با Proyecta بسازید. با یک صفحه شروع کنید — همانی که بیشترین اهمیت را دارد — و ببینید چه می‌شود.