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

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

وهي تحدّق فيه منذ أسبوعين دون أن تطلقه.

حين سألتها عن السبب، قالت: “إنه يعمل، لكن… لا يشعرني بأنه اكتمل.”

سألتها عمّا ستغيّره. قالت: “لا أعرف. تلك هي المشكلة.”

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

ماذا يعني “اكتمل” فعلاً

إليك التمييز الذي يهمّ: النموذج الأوّلي شيء تستخدمه لاختبار فكرة. المنتج شيء تستخدمه لحلّ مشكلة.

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

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

لا يعطّل أيٌّ من هذه أشياء التطبيق. لكنها جميعها تجعل معالجاً حقيقياً يفكّر: “هذا يبدو كشيء ركّبته في عطلة نهاية أسبوع، لا شيء يُتقاضى مقابله منّي.”

ذلك الشعور حقيقي، وهو يهمّ. النموذج الأوّلي يحلّ المشكلة نظرياً. أمّا المنتج فيحلّها عملياً، للإنسان الفعلي الذي يستخدمه.

ثلاثة أسئلة تفصل النموذج الأوّلي عن المنتج

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

1. هل ستستخدم هذا لحلّ مشكلتك أنت؟

هذا السؤال صادق، لأن عليك أن تعيش فعلاً مع منتجك أنت.

إن كنت مؤسِّس تطبيق جدولة المعالجين، فهل ستستخدمه لجدولة مواعيد علاجك النفسي أنت؟ ليس “هل تستطيع” — بل هل ستستخدمه فعلاً بدلاً من سلسلة رسائل بريد أو مستند Google Doc مشترك؟

إن كانت الإجابة لا، فأنت لم تكتمل. أنت تعرف بالضبط ما الخطأ — تشعر به في كل مرّة تفتح فيها التطبيق. وإن كانت الإجابة نعم، فأنت أقرب.

المؤسِّسة التي ذكرتها مرّت بمسار تسجيل المعالج الخاص بها. وعَلِقت عند النموذج (طلب معلومات أكثر من اللازم قبل أن يسمح لها بالحجز). ورأت رسالة التأكيد ووجدتها تبدو هاوية. وبدأت تفكّر في كيف سيستقبل معالجها الرسالة وهل ستنتهي في البريد المزعج.

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

2. هل عرضته على ثلاثة أشخاص غيرك؟

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

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

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

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

تلك معلومة عن المنتج. لم تكن لتخمّنها من مستند مواصفات.

3. ما الذي سينكسر لو أعطيت هذا لعشرة مستخدمين حقيقيين؟

هذا أصعب سؤال لأنه يتطلّب منك أن تفكّر فعلاً في حالاتك الحدّية.

بالنسبة لتطبيق المعالجين:

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

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

المنتج يتعامل مع الحالات الحدّية. لا كلّها — بعض الأشياء يمكن أن تنتظر. لكن تلك التي تحدث في أول أسبوعين مع مستخدمين حقيقيين، تلك يجب أن تعمل.

كيف تقرّر: اختبار الطبقات الثلاث

استخدم هذا لتحديد أين أنت:

الطبقة 1: المسار الأساسي — هل يعمل المسار السعيد؟ هل يستطيع المستخدم فعل الشيء الرئيسي الذي صُمّم له تطبيقك؟

بالنسبة لمجدول المعالجين: نعم. يستطيع أحدهم التسجيل، وحجز موعد، والحصول على تأكيد. إنه يعمل.

الطبقة 2: الحالات الحدّية من الاستخدام الحقيقي — لقد عرضته على ثلاثة مستخدمين فعليين. هل اصطدموا بشيء لم تبنِه؟ هل ارتبكوا في أي مكان؟

بالنسبة لمجدول المعالجين: نعم. أراد المعالجون الثلاثة توفّراً قائماً على قواعد. وارتبك أحدهم لأن رسالة التأكيد بدت عامّة أكثر من اللازم. وحاول أحدهم حذف المواعيد دفعةً واحدة فلم يستطع.

الطبقة 3: الصقل والاحترافية — هل يشعرك بأنك تهتمّ؟ أم يشعرك بأنك لفّقته معاً؟

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

إليك القاعدة الإرشادية:

الطبقات الثلاث تعمل كلّها؟ أنت منتج. أطلقه.
الطبقتان 1 و2 تعملان، لا الثالثة؟ أنت أنجزت 80%. اقضِ يوماً على الصقل.
الطبقة 1 تعمل، لا الطبقتان 2 و3؟ أنت نموذج أوّلي. لا تطلق بعد.
الطبقة 1 ليست صلبة؟ أنت لم تكتمل. واصل البناء.

كان تطبيق المعالجين عالقاً عند الحدّ بين الطبقة 1 والطبقة 2. المسار الأساسي يعمل، لكن المعالجين الحقيقيين وجدوه ناقص الأجزاء. فكان أمام المؤسِّسة خيار: أن تقضي أسبوعاً آخر مع منصّتها لإضافة الميزات التي يحتاجها المعالجون فعلاً، أو أن تطلق بما لديها وتضيفها لاحقاً.

(أضافتها. استغرق الأمر ثلاثة أيام. وهو الآن منتج.)

الأمر الذي يجعل هذا صعباً

السبب في عَلَق كثير من المؤسّسين هنا هو أن البناء ممتع والإطلاق مخيف.

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

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

ليس السبب الخطوط.

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

قائمة جاهزية الإطلاق

استخدم هذه. إنها قصيرة وصادقة.

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

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

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

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