مسیر یک مبتدی از یک ایده خام تا اولین اپلیکیشن کارآمد، بدون نوشتن حتی یک خط کد: چطور خواستهتان را طوری توصیف کنید که نتیجه دقیق و مشخص باشد، مرور گامبهگام ساخت در یک ساعت، پنج اشتباهی که اپلیکیشنهای اول را غرق میکند، و اینکه از کجا بفهمید نسخه یک شما واقعاً آماده است.
کسانی که برای اولین بار میسازند، بنیانگذاران، مدیران اجرایی، و هر کسی که ایده یک اپلیکیشن را دارد اما پیشینه برنامهنویسی ندارد.
- روشی برای نوشتن شرح خواسته که به شما اپلیکیشنی مشخص میدهد، نه یک محصول عمومی
- مرور عملی یکساعته از توصیف تا نسخهای که کار میکند
- پنج اشتباه اپلیکیشن اول و آزمونهایی که آنها را زود لو میدهند
ساختن اولین اپلیکیشن زمانی به معنای ماهها یادگیری یا فاکتوری چند ده میلیونی بود. امروز گلوگاه واقعی چیز دیگری است: اینکه بدانید چه بخواهید، چطور نتیجه را بررسی کنید، و کجا دست از اضافه کردن بردارید. این راهنما کل این مسیر را با شما طی میکند، از ایدهای که در ذهن دارید تا نسخهای که آدمهای واقعی میتوانند استفاده کنند، بدون نوشتن یک خط کد.
بله، و نه فقط یک اسباببازی. شما به زبان ساده توصیف میکنید اپلیکیشن باید چه کاری انجام دهد، و یک اپساز مبتنی بر AI یک اپلیکیشن واقعی تولید میکند: صفحهها، یک پایگاه داده واقعی، حسابهای کاربری، و قواعدی که اینها را به هم وصل میکند. نقش شما از نوشتن کد به سه کاری منتقل میشود که کد هیچوقت حلشان نکرده بود: تصمیم بگیرید چه بسازید، نتیجه را آزمایش کنید، و هفته به هفته بهترش کنید.
ارزش دارد دقیق بگوییم چه چیزی تغییر کرده، چون دو ابزار کاملاً متفاوت مدعی این حرف هستند. قالبسازها اجازه میدهند صفحهها را از بلوکهای آماده سرهم کنید؛ سریعاند، تا وقتی که ایده شما در قالب جا نشود. اپسازهای مبتنی بر AI اما خود اپلیکیشن را از روی توصیف شما تولید میکنند، از جمله پایگاه داده و منطق زیر آن، و این یعنی شکل ایده شما، نه شکل یک قالب، تعیین میکند در نهایت به چه میرسید. برای یک اپلیکیشن اول، این همان تفاوت بین کوتاه آمدن از روز اول و ساختن همان چیزی است که واقعاً تصور کرده بودید.
اما آنچه تغییر نکرده: یک اپلیکیشن به این دلیل موفق میشود که مشکلی واقعی را برای آدمهای واقعی حل میکند. هیچ ابزاری این بخش را تعیین نمیکند. و این خبر خوبی است، چون یعنی مهمترین بخش کار هیچوقت کد نبوده است.
کیفیت نسخه اول شما پیش از زدن دکمه تولید تعیین میشود. توصیف مبهم اپلیکیشن مبهم تحویل میدهد؛ توصیف مشخص چیزی تحویل میدهد که همان ساعت میتوانید آزمایشش کنید. خبر خوب اینکه مشخص بودن به معنای فنی بودن نیست. چهار جمله لازم دارید، به زبان معمولی.
این قالب را امتحان کنید: "یک اپلیکیشن نوبتدهی برای یک کلینیک کوچک فیزیوتراپی بساز. بیماران یک نوبت خالی ۳۰ دقیقهای برای هفته آینده انتخاب میکنند و با نام و شماره تلفن رزرو میکنند. هر یک از دو فیزیوتراپیست من برنامه روز خودش را میبیند؛ من هر دو را میبینم. بیماران، نوبتها و یادداشتهای درمانی را دنبال کن، یادداشتهایی که فقط فیزیوتراپیستها میبینند. هرگز اجازه نده دو رزرو در یک نوبت ثبت شود." چهل ثانیه خواندن، و هر جمله به یک تصمیم مشخص تبدیل شد که اپساز میتواند بر اساسش عمل کند.
فریمورک، پایگاه داده یا هاستینگ مشخص نکنید؛ فقط حدس میزنید، و حدسها نتیجه را محدود میکنند. خروجی کسبوکاری را توصیف کنید و انتخابهای فنی را به اپساز بسپارید. همیشه میتوانید بعداً زیر کاپوت را نگاه کنید، و با اپسازی که کد واقعی را به شما میدهد، این "بعداً" واقعاً وجود دارد.
این توالی واقعبینانه است، و زمان جایی صرف میشود که مبتدیها کمتر انتظارش را دارند: بیشترش در آزمایش و اصلاحهای کوچک، نه در انتظار.
همان ردیف آخر مهارتی است که همه هفتههای آینده را پیش میبرد: هر بار یک تغییر، و تأیید آن پیش از تغییر بعدی. درخواستهای رویهمانباشته نتایج درهمتنیده میسازند و تشخیص اینکه کدام تغییر چه چیزی را شکسته غیرممکن میشود. اپسازهایی که نسخههای ذخیرهشده دارند این کار را امن میکنند: اگر تغییری خراب شد، یک دقیقه به عقب برمیگردید، به جای اینکه یک بعدازظهر کامل گره باز کنید.
تمام بودن یک چکلیست است، نه یک حس. نسخه یک وقتی آماده است که آن یک جریان با داده واقعی از ابتدا تا انتها کار کند، آن یک قاعده وقتی فعالانه سعی میکنید بشکنیدش دوام بیاورد، حساب دوم نتواند دادههای حساب اول را ببیند، ورودی خالی و اشتباه به جای کرش کردن پیام منطقی بگیرد، و اپلیکیشن روی یک لینک منتشر شده باشد، ترجیحاً روی دامنه خودتان، لینکی که بتوانید برای یک غریبه بفرستید.
دقت کنید چه چیزهایی در این فهرست نیست: قابلیتهای بیشتر، طراحی بینقص، اپ موبایل در استورها. هر محصول موفقی که میشناسید نسخه اولی منتشر کرده که امروز بنیانگذارانش را شرمنده میکند. تفاوت آنها با پروژههای جانبی رهاشده در خوب بودن نسخه اول نیست؛ در این است که نسخه اول آنقدر زود به کاربران واقعی رسید که یاد بگیرد نسخه دو باید چه باشد.
یک نکته دیگر هم پیش از تعهد به هر ابزاری ارزش بررسی دارد: اینکه اپلیکیشن واقعاً مال شما باشد، کد و دادهای واقعی که بتوانید با خودتان ببرید، نه پیکربندیای قفلشده داخل آن ابزار. اپلیکیشن اول جایی است که بیشترین چیزها را یاد میگیرید، و باید داراییای باشد که نگهش میدارید، هر چه که بعدش بسازید.
نه. به شفافیت درباره کسبوکار خودتان نیاز دارید: چه کسی از اپلیکیشن استفاده میکند، چه چیزهایی را دنبال میکند، آن یک جریانی که باید کار کند، و آن یک قاعدهای که هرگز نباید بشکند. اینها را به زبان ساده توصیف کنید و اپساز بخش فنی را انجام میدهد: صفحهها، پایگاه داده، حسابها و منطق.
یک نسخه اول کارآمد و قابل آزمایش در حدود یک ساعت واقعبینانه است: چند دقیقه برای تولید، و بقیه صرف کلیک کردن با نقشهای مختلف، وارد کردن داده واقعی و اعمال اصلاحهای اول، یکییکی. آماده شدن واقعی آن برای غریبهها معمولاً چند شب از همین چرخه میگیرد.
یک جریان، از ابتدا تا انتها، و هیچ چیز دیگر. اپلیکیشن نوبتدهیای که رزرو در آن واقعاً کار میکند از یک نوبتدهیفروشگاهوبلاگ که هیچکدامش درست کار نمیکند بهتر است. هر ایده دیگر را برای بعد یادداشت کنید؛ نسخه دو را خواستههای کاربران واقعی انتخاب میکند، نه تصورات شما در هفته اول.
سه آزمون: یک حساب آزمایشی دوم نباید بتواند دادههای حساب اول را ببیند؛ قاعده حیاتی کسبوکارتان باید وقتی فعالانه سعی میکنید بشکنیدش دوام بیاورد؛ و ورودی اشتباه یا خالی باید پیامی منطقی تولید کند، نه کرش. این سه را رد کنید و نسخه یک شما از بیشتر اسپردشیتهایی که جایگزینشان میشود امنتر است.