حين يصبح المنتج الواحد منتجَين: كيف تقسّم تطبيقك المبنيّ بالذكاء الاصطناعي دون أن تبدأ من جديد

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

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

كيف تكتشف أن لديك منتجَين

نادراً ما تبدو الإشارة كطلب ميزة. بل تبدو كاحتكاك.

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

ستعرف أنك تجاوزت ذلك الخطّ حين يصبح أحد هذه الأمور صحيحاً:

• اضطرار صفحتك الرئيسية إلى دفن عرضها الفعلي خلف لغة عامّة لأن جمهورَين لن يصدّقا الكلمات نفسها.
• ارتباط كل ميزة جديدة بتحفّظ من نوع “لكن بالنسبة إلى النوع الآخر من المستخدمين ينبغي أن تعمل بشكل مختلف”.
• تفرّع ردودك على الدعم: “إن كنت تستخدمه لنفسك…” مقابل “إن كنت تدير فريقاً…”.
• احتفاظ عدد غير قليل من المستخدمين بحسابَين منفصلَين للفصل بين الوضعَين.

إن كنت ترى اثنين أو أكثر من هذه، فأنت لا تواجه مشكلة ميزة. بل لديك انقسام منتج ينتظر أن يحدث.

الأشكال الثلاثة للانقسام

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

الشكل الأول: تطبيق واحد، بابان

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

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

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

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

الشكل الثاني: تطبيقان، خلفية واحدة

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

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

هذا الشكل هو الإجابة الصحيحة حين:

• يشتري الجمهوران لأسباب مختلفة.
• سيشعران بالحيرة أو بالنفور من رسائل التسويق الموجّهة للجمهور الآخر.
• تكون البيانات التي يهتمّان بها متشابهة الشكل في الغالب، لكنها مؤطّرة بشكل مختلف.
• لا تريد صيانة قاعدتَي بيانات أو إعدادَي فوترة.

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

الشكل الثالث: تطبيقان، خلفيتان

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

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

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

ما الذي تفعله قبل أن تقسّم أي شيء

قبل أن تصف الانقسام لمنصّتك لبناء التطبيقات بالذكاء الاصطناعي، افعل ثلاثة أشياء صغيرة. قيمتها أكبر ممّا توحي به.

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

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

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

ما الذي يتغيّر بعد الانقسام

شيئان يصبحان أسهل وشيء يصبح أصعب.

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

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

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

سؤال صغير في الختام

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

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

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