وقتی اپ ساخته‌شده با هوش مصنوعی از نسخهٔ اولش بزرگ‌تر می‌شود: بازنویسی جزئی یا بازنویسی کامل؟

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

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

لحظه‌ای که می‌فهمید اپ موفق شده است

بیشتر اپ‌های ساخته‌شده با هوش مصنوعی به‌عنوان یک چیز شروع می‌شوند و به چیزی دیگر تبدیل می‌شوند. یک فرم دریافت اطلاعات مشتری برای کسب‌وکار مربیگری‌تان ساختید؛ حالا مشتری‌ها می‌خواهند قرارهای گذشته را ببینند و خودشان زمان‌بندی را تغییر دهند. یک ابزار امتیازدهی به سرنخ‌ها ساختید؛ حالا تیم فروشتان می‌خواهد خلاصه‌ها به CRMشان صادر شود. یک سیستم بایگانی ساختید؛ حالا مردم می‌خواهند درون آن با هم همکاری کنند.

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

آن حس همان سیگنالی است که باید به آن فکر کنید: آیا این هنوز همان اپ است، یا از آن جلو زده‌اید؟

بازنویسی جزئی چه چیزی برایتان می‌خرد و چه هزینه‌ای دارد

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

وقتی بازنویسی جزئی جواب می‌دهد، مثل جادو است. حس می‌کردید با اپ می‌جنگید؛ ناگهان دیگر نمی‌جنگید. در یک هفته سه قابلیت جدید اضافه می‌کنید که قبلاً سه هفته طول می‌کشید.

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

بازنویسی کامل چه چیزی برایتان می‌خرد و چه هزینه‌ای دارد

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

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

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

اپ‌هایی که بعد از بازسازی کامل موفق می‌شوند معمولاً به این دلیل موفق می‌شوند که درک تیم از مسئله آن‌قدر از کد اولیه فاصله گرفته بود که تلاش برای وصله کردن مثل پوشیدن لباسی بود که اندازه نیست. بازنویسی کامل یعنی این بار برای خودشان ساختند.

سه پرسش برای انتخاب میان این دو

پرسش ۱: آیا شکل اصلی هنوز درست است؟

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

اگر دارید گونه‌هایی از همان هسته را اضافه می‌کنید — «فرم دریافت برای افراد، فرم دریافت برای تیم‌ها، فرم دریافت با فیلدهای سفارشی» — این هنوز همان اپ است. بازنویسی جزئی کنید و گسترشش دهید.

پرسش ۲: اگر امروز بازنویسی جزئی کنید، چند ماه دیگر تا برخورد دوباره با اصطکاک فاصله است؟

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

پرسش ۳: کاربرهایتان واقعاً به چه چیزی وابسته‌اند؟

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

مسیری که معمولاً جواب می‌دهد

بیشتر بنیان‌گذارانی که با موفقیت بازسازی می‌کنند این کار را به‌صورت موازی انجام می‌دهند: اپ اولیه را روشن نگه می‌دارند و از ظرفیت اضافی برای ساختن اپ جدید استفاده می‌کنند. وقتی اپ جدید با اپ قدیمی برابریِ قابلیت پیدا کرد، یک هفته صرف انتقال داده‌ها و کاربرها می‌کنند و تمام.

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

زمان درست برای تصمیم‌گیری

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