حين يتجاوز تطبيقك المبنيّ بالذكاء الاصطناعي نسخته الأولى: إعادة الهيكلة مقابل إعادة الكتابة

أطلقت شيئاً. وأحبّه المستخدمون. والآن صار هناك عشرة مستخدمين، ويريدون ميزات لا تناسب الشكل الأصلي. أنت واقف عند مفترق: ترقّع التطبيق ليناسب الاستخدام الجديد، أو تعترف بأن النسخة الأولى كانت نموذجاً أوّلياً وتبنيه بالشكل الصحيح. إنه السؤال الذي يقتل مشاريع صغيرة أكثر من أي سؤال آخر، لأنه لا توجد له إجابة تقنية — بل إجابة عمل فقط.

اللحظة التي تدرك فيها أن التطبيق ناجح

معظم التطبيقات المبنيّة بالذكاء الاصطناعي تبدأ شيئاً ما وتصبح شيئاً آخر. بنيت نموذج استقبال عملاء لممارستك في التدريب؛ والآن يريد العملاء رؤية المواعيد السابقة وإعادة جدولة مواعيدهم بأنفسهم. بنيت أداة لتسجيل النقاط للعملاء المحتملين؛ والآن يريد فريق مبيعاتك ملخّصات مصدَّرة إلى نظام إدارة علاقات العملاء (CRM) لديهم. بنيت نظام حفظ؛ والآن يريد الناس التعاون داخله.

كل طلب معقول. وكل واحد يجرّ التطبيق بعيداً قليلاً عمّا بُنِيَ ليكونه. وعند نقطة معيّنة — بعد ستة أشهر، أو شهرين، أحياناً أسبوعين — تشعر بالاحتكاك. كل ما تضيفه يصارع الأساس. الميزات الجديدة تتطلّب “أوه، علينا أن نعيد تنظيم ذلك الجزء أولاً”. يتباطأ التطبيق. ويستغرق تغيير الأشياء وقتاً أطول.

ذلك الشعور هو إشارتك للتفكير في ما إذا كان هذا ما زال التطبيق نفسه، أم أنك تجاوزته.

ما الذي تشتريه إعادة الهيكلة وما تكلّفه

إعادة الهيكلة تعني الإبقاء على التطبيق نفسه، لكن تنظيفه لتتمكّن من البناء أكثر فوقه. تطلب من أداة الذكاء الاصطناعي إعادة تنظيم الشيفرة، أو تقسيم سير عمل مفرط التعقيد، أو إعادة تصميم شاشة صارت مكبّاً للميزات. يستغرق الأمر بضع ساعات. ولا يضيف ميزات جديدة. بل يجعل الأساس أمتن فقط.

حين تنجح إعادة الهيكلة، تكون سحرية. كنت تشعر أنك تصارع التطبيق؛ وفجأةً لم تعد كذلك. تضيف ثلاث ميزات جديدة في أسبوع كانت ستستغرق ثلاثة أسابيع من قبل.

لكن إعادة الهيكلة تنجح فقط إن كانت المشكلة هي شكل ما لديك. إن بنيت نموذج استقبال ويريد المستخدمون نموذج استقبال أسرع، فإعادة هيكلة الجزء البطيء تستغرق بعد ظهر يوم. وإن أرادوا نموذج استقبال أسرع و يخزّن السجلّ، فما زال تطبيقاً واحداً، وقد تساعد إعادة الهيكلة. لكن إن أرادوا سجلّ مواعيد، وتكاملات مع التقويم، وتذكيرات بالرسائل النصّية، وفوترة، فأنت لم تعد تبني نموذج استقبال أفضل — بل تبني المكتب الخلفي لممارسة تدريب. وذلك منتج مختلف.

ما الذي تشتريه إعادة الكتابة وما تكلّفه

إعادة الكتابة تعني: تعلّمت ما ينبغي أن يكون عليه التطبيق فعلاً، وستبنيه من الصفر بتلك المعرفة. لا ترمي النسخة الأولى — فمستخدموك ما زالوا يعتمدون عليها. بل تبني تطبيقاً جديداً من القاعدة، مستنيراً بما علّمك إيّاه القديم، ثم تنقل المستخدمين حين يصبح جاهزاً.

إعادة الكتابة تبدو مهدِرة. بنيت شيئاً، والآن تبنيه من جديد. تلك هي الكلفة النفسية. أما الكلفة العملية فهي الوقت: ستقضي شهرين إلى أربعة على النسخة الجديدة قبل أن تكون جاهزة لنقل المستخدمين. ولن تملك النسخة الأولى كعكّاز بعد الآن — أنت تمضي قُدُماً دون شبكة أمان.

لكن إعادة الكتابة تشتري لك شيئاً لا يستطيع غيرها: الحرّية. التطبيق الجديد غير مقيّد بشكل القديم. إن كان الأصل نموذجاً بسيطاً وينبغي أن يكون الجديد مكتباً خلفياً كاملاً، فأنت تصمّم لذلك من البداية. إن كان الأداء يهمّ، فأنت تصمّم لذلك. وإن كان الأمن أو التكاملات أو سير العمل يهمّ، فهي ليست إضافات لاحقة — بل أساسية.

التطبيقات التي تنجح بعد إعادة البناء تميل إلى ذلك لأن فهم الفريق للمشكلة انزاح بعيداً جداً عن الشيفرة الأصلية لدرجة أن محاولة الترقيع كانت كارتداء ملابس لا تناسب تماماً. وإعادة الكتابة عنت البناء لأنفسهم بدلاً من ذلك.

ثلاثة أسئلة للاختيار بينهما

السؤال 1: هل الشكل الجوهري ما زال صحيحاً؟

شكلك الجوهري هو سير العمل الرئيسي الواحد أو الاثنان اللذان يعرّفان التطبيق. بالنسبة لنموذج استقبال للتدريب، هو “العميل يملأ الاستقبال، المدرّب يراجع، المدرّب يجدول”. إن كنت تضيف سيرَ عمل مختلفة — فوترة، إدارة تقويم، مراسلة العملاء — فأنت لا توسّع الجوهر، بل تركّب ميزات جانبية. وتلك علامة على أنك تبني منتجاً مختلفاً، ما يعني إعادة الكتابة.

أما إن كنت تضيف تنويعات من الجوهر نفسه — “استقبال للأفراد، استقبال للفِرَق، استقبال بحقول مخصّصة” — فما زال التطبيق نفسه. أعِد هيكلته ووسّعه.

السؤال 2: لو أعدت الهيكلة اليوم، فكم شهراً حتى يضرب الاحتكاك من جديد؟

كن صادقاً. إن زال الاحتكاك لمدّة ستة أشهر، فإعادة الهيكلة هي الحركة الصحيحة. أما إن كان سيؤلم من جديد خلال شهرين لأن المشكلة ليست شكل الشيفرة بل الأساس نفسه، فإن إعادة الكتابة توفّر عليك الوفورات الزائفة الناتجة عن الترقيع مرّتين. اسأل أداة الذكاء الاصطناعي: “لو نظّفنا هذا، فكم سيمضي حتى نحتاج إلى فعل هذا من جديد؟” إن كانت الإجابة “على الأرجح ليس طويلاً”، فقد حان وقت إعادة البناء.

السؤال 3: ما الذي يعتمد عليه مستخدموك فعلاً؟

إن كان لديك ثلاثة مستخدمين نشطين على النسخة 1 وتفكّر في إعادة البناء، فيمكنك نقلهم في يوم أو يومين. أما إن كان لديك خمسون مستخدماً يعتمدون على التطبيق الحالي اعتماداً إنتاجياً، فإعادة الكتابة تعني أن عليك إبقاء النسختين تعملان لأشهر، وهو نوعه الخاصّ من الألم.

الطريق الذي ينجح عادةً

معظم المؤسّسين الذين يعيدون البناء بنجاح يفعلونه بالتوازي: يبقون التطبيق الأصلي يعمل ويستخدمون الطاقة الفائضة لبناء الجديد. وحين يصل الجديد إلى تكافؤ الميزات مع القديم، يقضون أسبوعاً في نقل البيانات والمستخدمين، وينتهون.

أما الطريق الذي لا ينجح عادةً: أعِد الهيكلة، أعِد الهيكلة، أعِد الهيكلة، إلى أن تدرك بعد ثلاث إعادات هيكلة أن البنية ما زالت خاطئة، وأنت الآن مستثمر أكثر من اللازم في النسخة “القديمة” لتعترف بذلك وتبدأ من جديد.

الوقت الصحيح للقرار

في المرّة القادمة التي تشعر فيها بالاحتكاك، اسأل نفسك: “هل أجعل هذا التطبيق يفعل ما كان يُفترض أن يفعله، بشكل أفضل؟ أم أطلب منه أن يكون شيئاً لم يُصمَّم له قطّ؟” إن كان الأول، فأعِد الهيكلة. وإن كان الثاني، فلا عار في بناء الشيء الذي كان ينبغي أن يكونه من البداية. معظم التطبيقات الناجحة على النسخة الثانية من الجوهر، لا الأولى.