چطور اپ ساختهشده با هوش مصنوعیتان را بهروز کنید بدون اینکه برای کسانی که همین حالا از آن استفاده میکنند خرابش کنید
وقتی آدمهای واقعی به اپ شما تکیه میکنند، هر تغییری ریسک به همراه دارد. این یک روال ساده برای بهروزرسانی امن اپ ساختهشده با هوش مصنوعیتان است — پشتیبان بگیرید، آزمایش کنید، یک چیز را تغییر دهید، و بدانید چطور آن را برگردانید.
نسخهٔ اول اپتان بهراحتی قابلتغییر بود. اگر چیزی خراب میشد، تنها کسی که متوجه میشد خودتان بودید. بعد آدمهای واقعی شروع به استفاده از آن کردند — و حالا هر تغییری حس جراحی روی بیماری را دارد که بیدار است. یاد گرفتن اینکه چطور اپ ساختهشده با هوش مصنوعیتان را بدون خراب کردنش بهروز کنید، عمدتاً مسئلهٔ یک روال است، و آن روال کوچکتر از آن چیزی است که فکر میکنید.
صاحب یک کسبوکار تدریس خصوصی که میشناسیم این را به روش دردناکی یاد گرفت. اپ زمانبندی او ماهها بینقص کار کرده بود، پس یک شب از اپساز هوش مصنوعیاش یک بهبود کوچک خواست: «Session» را همهجا به «Lesson» تغییر نام بده، چون این کلمهای بود که معلمهایش واقعاً استفاده میکردند. اپساز با خوشحالی تغییر نامش داد — از جمله، مشخص شد، آن جایی که رزروهای موجود ذخیره میشدند. صبح روز بعد، سه معلم تقویمهایشان را باز کردند و خالی یافتند. دادهها از بین نرفته بودند، اما اپ دیگر نمیتوانست پیدایشان کند، و او یک روز پرتنش را صرف وصل کردن دوبارهٔ آنها کرد.
هیچچیز آن تغییر نامعقول نبود. او فقط هنوز روالی نداشت برای اینکه چطور اپ ساختهشده با هوش مصنوعیاش را وقتی کاربر دارد بهروز کند. این پست همان روال است — چهار عادت که شاید پانزده دقیقهٔ اضافی به ازای هر تغییر وقت ببرند و جلوی بیشتر فاجعهها را بگیرند.
چرا وقتی کاربر دارید، بهروزرسانیها حس متفاوتی دارند
سه چیز همان لحظهای که کسی دیگر به اپ شما تکیه میکند تغییر میکنند:
- حالا داده در آن هست. تغییراتی که روی یک اپ خالی بیخطر بودند — تغییر نام چیزها، بازساختاردهی فرمها — میتوانند اطلاعاتی را که مردم پیشتر وارد کردهاند قطع یا درهموبرهم کنند.
- مردم عادت دارند. کاربرانتان یاد گرفتهاند دکمهها کجا هستند. حتی یک بهبود هم اختلال است اگر چیزی را که هر روز استفاده میکنند جابهجا کند.
- نمیتوانید زمان مشکلات را انتخاب کنید. وقتی اپ فقط مال خودتان بود، یک عصر خراب اهمیتی نداشت. حالا یک صبح سهشنبهٔ خراب یعنی سه معلم با تقویمهای خالی.
هیچکدام از اینها به این معنا نیست که باید بهبود دادن اپتان را متوقف کنید. اپهایی که از تغییر کردن باز میایستند بهجای ناگهانی، آرامآرام میمیرند. به این معناست که تغییرات به کمی تشریفات نیاز دارند.
عادت ۱: پیش از دست زدن به هر چیزی پشتیبان بگیرید
این همان عادتِ غیرقابلمذاکره است. پیش از هر تغییری بزرگتر از اصلاح یک تایپو، مطمئن شوید که یک پشتیبان بهروز از دادهٔ اپتان دارید — و میدانید چطور بازگردانیاش کنید.
اگر پشتیبانگیری خودکار را از قبل راهاندازی کردهاید، این عادت به یک پرسش از اپساز هوش مصنوعیتان تقلیل مییابد: «آخرین پشتیبان کی بود، و چطور آن را بازگردانی میکنم؟» اگر پاسخ مطمئن و اخیر بود، پیش بروید. اگر هنوز پشتیبانگیری راهاندازی نکردهاید، پیش از بهروزرسانی بعدیتان این کار را بکنید — ما یک راهنمای کامل برای پشتیبانگیری از اپ ساختهشده با هوش مصنوعیتان نوشتیم، و این بهترین ساعتی است که این ماه روی محصولتان خرج میکنید.
داستان اپ تدریس بالا دقیقاً به این خاطر پایان خوشی داشت که پلتفرم او پشتیبان نگه میداشت. وگرنه آن روز پرتنش، یک روز فاجعهبار میشد.
عادت ۲: پیش از گفتن بله، بپرسید «این چه چیزی را میتواند خراب کند؟»
این همان پرسشی است که بیشتر سازندگان هرگز به فکر پرسیدنش نمیافتند، و بیش از سه عادت دیگر روی هم کار میکند. بعد از اینکه یک تغییر را به اپساز هوش مصنوعیتان توصیف کردید، و پیش از اینکه تأییدش کنید، یک خط اضافه کنید:
«پیش از اینکه این تغییر را اعمال کنی — چه قابلیتها یا دادههای موجودی میتواند تحت تأثیر قرار بگیرد؟»
این کار جواب میدهد چون هوش مصنوعی معمولاً میتواند ارتباطهایی را ببیند که شما نمیتوانید. صاحب اپ تدریس نمیتوانست بداند که «Session» اسم آن جایی هم بود که رزروها زندگی میکردند. اپساز میدانست — او فقط هرگز نپرسید. وقتی بعد از آن روالش را بازسازی کرد، همین یک پرسش به گامی تبدیل شد که مشکلات را میگرفت: علامت داد که تغییر فرم قیمتگذاریاش روی دو فاکتور قدیمی اثر میگذارد، و اینکه افزودن یک فیلد اجباری کاربران قبلیای را که بدون آن ثبتنام کرده بودند مسدود میکند.
پاسخ را مثل یک خلبان که گزارش هواشناسی میخواند بخوانید. «این ظاهری است، هیچچیز دیگری به آن دست نمیخورد» — آسمان صاف، برو. «این نحوهٔ ذخیرهٔ رزروها را تغییر میدهد» — این نشانهٔ شماست که آهستهتر پیش بروید، دوباره پشتیبان بگیرید، و شاید یک نسخهٔ ملایمتر از تغییر را بخواهید.
عادت ۳: هر بار یک چیز را تغییر دهید، و آن را مثل یک غریبه آزمایش کنید
دستهکردن پنج بهبود در یک بهروزرسانی بزرگ حس کارآمدی میدهد. در واقع برعکس است: وقتی چیزی خراب میشود، نمیدانید کدامیک از آن پنج تا باعثش شد، و برگرداندن آن یکیِ خراب یعنی برگرداندن هر پنج تا.
یک تغییر، بعد بررسی. بررسی به اندازهٔ تقسیم کردن اهمیت دارد:
- از یک حساب دوم استفاده کنید، نه حساب مالکتان. شما اپ را بهعنوان مدیرش میبینید؛ کاربرانتان نمیبینند. بهعنوان یک کاربر عادی وارد شوید — یک حساب آزمایشی دائمی دقیقاً برای همین نگه دارید — و مسیری را که تغییرتان به آن دست زده طی کنید. (اگر هرگز اپ خودتان را آزمایش نکردهاید، این هم نحوهٔ انجامش بدون پیشینهٔ QA.)
- چیزی را که تغییر دادید بررسی کنید، و چیز کنارش را. اگر فرم رزرو را بهروز کردید، یک رزرو بسازید — بعد یک رزرو قدیمی را هم باز کنید و مطمئن شوید همچنان نمایش داده میشود. بیشتر خرابیهای ناشی از بهروزرسانیها در دادهٔ قدیمی ظاهر میشوند، نه جدید.
- همین حالا انجامش دهید، نه فردا. بلافاصله بعد از تغییر آزمایش کنید، تا وقتی تازه و کوچک است. مشکلی که پنج دقیقه بعد از بهروزرسانی پیدا شود آشکارا ناشی از بهروزرسانی است. مشکلی که جمعه پیدا شود میتواند هر چیزی باشد.
عادت ۴: یک لحظهٔ آرام انتخاب کنید، و راه بازگشتتان را بدانید
دو نکتهٔ زمانبندی نهایی که حرفهایها استفاده میکنند و افراد غیربرنامهنویس بهندرت دربارهٔ آن میشنوند:
وقتی کاربرانتان دور هستند عرضه کنید. احتمالاً ریتم اپتان را میشناسید — اپ تدریس بعدازظهرهای روزهای کاری پرترددترین بود، و عصرهای یکشنبه تقریباً ساکت. عصر یکشنبه همان وقتی است که تغییرات اتفاق میافتند. اگر چیزی به هم بریزد، ساعتها وقت دارید پیش از اینکه کسی برسد آن را اصلاح کنید، بهجای دقیقهها.
پیش از اینکه به راه بازگشت نیاز پیدا کنید آن را بدانید. از اپساز هوش مصنوعیتان بپرسید: «اگر این تغییر مشکل ایجاد کند، میتوانی برش گردانی؟ چه چیزی لازم دارد؟» گاهی پاسخ «یک کلیک» است. گاهی «برگرداندن تغییر آسان است، اما دادهای که بعد از تغییر ساخته شده ممکن است با نسخهٔ قدیمی جور نباشد». میخواهید آن پاسخ را وقتی آراماید بشنوید، نه وقتی سه معلم دارند به شما پیام میدهند.
و وقتی یک تغییر برای کاربران قابلمشاهده است — یک دکمهٔ جابهجاشده، یک فیلد تغییرنامداده، یک گام جدید — به آنها بگویید. یک پیام کوتاه («میبینید که Sessionها حالا Lesson نامیده میشوند — همان رزروها، اسمی دوستانهتر») یک غافلگیری گیجکننده را به نشانهای تبدیل میکند که کسی دارد فعالانه از محصولی که به آن تکیه میکنند مراقبت میکند.
نسخهٔ پانزدهدقیقهای
این هم کل روال، آنقدر کوچک که روی یک کاغذ یادداشت جا بگیرد: از وضعیت فعلی پشتیبان بگیر ← بپرس چه چیزی میتواند خراب شود ← هر بار یک تغییر ← مثل یک غریبه آزمایش کن، با احتساب دادههای قدیمی ← ساعات آرام ← راه بازگشتت را بدان ← به کاربرانت بگو.
مالکانی که چیزی شبیه این را دنبال میکنند، اپهای ساختهشده با هوش مصنوعیشان را کمتر از آدمهای بیاحتیاط بهروز نمیکنند — بیشتر بهروز میکنند، چون هر تغییر دیگر یک قمار نیست. این همان پاداش واقعی است: نه اجتناب از خرابی، بلکه باثباتماندنِ کافی برای ادامهٔ بهبود چیزی که مردم رویش حساب میکنند.
دفعهٔ بعد که میخواهید از اپسازتان یک تغییر بخواهید، آن پرسش تکخطی از عادت ۲ را امتحان کنید و ببینید چه چیزی را آشکار میکند. و اگر این همان پستی است که بالاخره شما را وادار به راهاندازی پشتیبانگیری میکند — از اینجا شروع کنید.