من خربشة على منديل إلى تطبيق يعمل: كيف تبني برمجيات من فكرة بالذكاء الاصطناعي

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

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

لكن عبارة “صِف ما تريده” تحمل عبئاً ثقيلاً في تلك الجملة. لم يكن الجزء الصعب يوماً هو البرمجة. كان دائماً معرفة ما تحتاجه فعلاً.

ابدأ بالفعل، لا بالاسم

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

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

• “متنزّه بالكلاب يفتح التطبيق ويرى حجوزاته لهذا اليوم”
• “صاحب كلب يختار فترة زمنية ويحجز نزهة”
• “المتنزّه يضع علامة ‘مكتملة’ على النزهة فيتلقّى صاحب الكلب صورة”

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

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

أما محاولته الثانية فقد سردت ما كان يفعله فعلاً كل يوم:

1. يرى العملاء الأوقات المتاحة للأسبوع
2. يحجزون فترة ويتلقّون تأكيداً عبر WhatsApp
3. بعد كل جلسة، يسجّل كارلوس ما فعلوه (التمارين، المجموعات، الأوزان)
4. يفتح العملاء سجلّهم ويرون تقدّمهم عبر الوقت

ذلك الوصف الثاني أنتج شيئاً تمكّن من استخدامه خلال ساعات.

ابنِ شاشة واحدة أولاً

قد تكون لديك عشر ميزات في رأسك. ابنِ واحدة.

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

حين تبدأ بشاشة واحدة، تحدث ثلاثة أشياء جيدة.

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

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

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

صِفه كأنك تشرح لصديق

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

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

بعض الأوصاف التي تعمل جيداً:

• “حين ينقرون ‘احجز’، تحقّق إن كان الوقت لا يزال متاحاً. إن كان كذلك، أكّده. إن خطفه شخص آخر، أظهِر رسالة واقترح أقرب فترة متاحة.”
• “ينبغي أن تعرض لوحة التحكّم ثلاثة أرقام في الأعلى: إجمالي العملاء، وجلسات هذا الأسبوع، وإيرادات هذا الشهر. وتحتها قائمة بجلسات اليوم مع اسم العميل والوقت.”
• “بعد الجلسة، أريد أن أكتب ما فعلناه — مثل ‘سكوات 3×10 بوزن 80 كغ، بنش بريس 3×8 بوزن 60 كغ’ — ويُحفظ في سجلّ ذلك العميل.”

النمط في كلٍّ منها: من يفعل ماذا، ومتى، وما الذي يحدث بعده.

استخدمه، ثم أصلِحه

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

حين رأى كارلوس النسخة الأولى من شاشة حجزه، أزعجته ثلاثة أمور:

1. الفترات كانت تظهر في كتل من 30 دقيقة، لكن جلساته كانت 50 دقيقة
2. لم تكن هناك وسيلة ليلغي العميل دون مراسلته مباشرةً
3. رسالة التأكيد كانت بالإنجليزية، لكن عملاءه يتحدّثون الإسبانية

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

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

أرِه لشخص ليس أنت

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

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

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

أطلِق قبل أن تكون جاهزاً

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

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

أضاف هذه على مدى الأسابيع التالية، ميزة في كل مرة، بناءً على ما طلبه عملاؤه فعلاً. بُني تسجيل التمارين بعد أن طلبه ثلاثة عملاء في الأسبوع نفسه. وجاء تكامل المدفوعات بعد شهر، حين أدرك كارلوس أنه ما زال يجمع الرسوم نقداً وعبر Venmo.

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

كان نظامه السابق تقويم Google، وجدول Google، وقائمة بثّ على WhatsApp. كان يعمل، لكن أخطاء الحجز كانت تحدث أسبوعياً لأن العملاء كانوا ينسون التحقّق من التقويم قبل طلب موعد.

ثلاثة أخطاء تبطّئ الناس

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

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

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

الحاجز الحقيقي لم يكن تقنياً قط

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

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

إن كان بإمكانك شرحه لصديق، فبإمكانك بناؤه.

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