كيف بنى مدير منتج من دون خلفية تقنية مشروعين تجريبيين خلال أسبوع باستخدام Claude وKiro

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

مكونات المكدس

في قلب سير العمل يوجد تقسيم الأدوار بين عدة أدوات ذكاء اصطناعي. استخدم المؤلف Claude Sonnet 4.5 لمرحلة الاكتشاف: يتم تحميل الجمهور والمشاكل والعمليات المراد إنجازها والقيود والقيمة التجارية. تتضمن النتائج التحليلات والمحتوى والأوامر للمراحل التالية. كانت Figma Make مسؤولة عن توليد واجهة المستخدم الأمامية، بينما كانت Kiro من Amazon مسؤولة عن التجميع والقرارات المعمارية والنشر. تم استخدام Supabase لقاعدة البيانات و GitHub Pages للاستضافة وخوادم MCP للسياق والاختبارات.

• Claude Sonnet 4.5 — الاكتشاف والتحليلات والمحتوى والأوامر النظامية
• Figma Make — توليد واجهة المستخدم الأمامية للنسخة التجريبية
• Kiro — تجميع المشروع وتوثيق الحلول والنشر
• Supabase و GitHub Pages — قاعدة البيانات والنشر
• Context7 و Playwright عبر MCP — الذاكرة بين الجلسات والتحقق الأساسي من طرف النهاية

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

سير العمل خطوة بخطوة

لم تبدأ العملية بالكود بل بتعريف المشكلة. تم إنشاء مساعد منفصل في Claude لكل منتج، وتم تمريره السياق الكامل: من هو المستخدم وما المشكلة التي يحلها الخدمة وما يُعتبر قيمة وأي قيود لا يمكن انتهاكها. بعد ذلك تم نقل المواد إلى Figma Make حيث تم توليد واجهة مستخدم بدون تحسين يدوي. في الحالة، كان الحديث عن مشروعين: موقع شخصي للاستشارات في المنتجات وأداة agile مجانية يعتبرها المؤلف بديلاً أولياً لـ Jira للشركات الناشئة.

الخطوة التالية كانت نقل واجهة المستخدم والتحليلات إلى Kiro. يركز المؤلف على هذه الأداة بالذات كمركز لكل سير العمل، لأن Kiro تصيغ الحلول كتابياً أولاً ثم تنفذها بدون القفز مباشرة إلى الكود. بعد ذلك تم توصيل ثلاثة خوادم MCP: Context7 للحفاظ على السياق بين الجلسات و Supabase MCP لمخطط قاعدة البيانات والترحيلات و Playwright MCP للتحقق من السيناريوهات الحرجة للمستخدم.

بدت المرحلة النهائية عملية للغاية: التسجيل في GitHub و Supabase وإنشاء قاعدة بيانات والنشر على GitHub Pages وتعليمات لربط المجال.

أين تكون الاختناقات

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

ينطبق الأمر نفسه على نوافذ السياق: تساعد Context7 على عدم فقدان خيط المشروع لكنها لا تجعل مشكلة الذاكرة تختفي تماماً.

"كتابة الكود بالشعور ليست بديلاً عن المطورين."

هناك خطر آخر يتعلق بالاختبارات. تغطي Playwright MCP بثقة المسار السعيد أي السيناريوهات الأساسية حسب ملاحظة المؤلف، لكنها لا تلغي الحاجة للتحقق بشكل منفصل من الحالات الحدية. وبالتالي يبدو المكدس الموصوف بمثابة أداة للتحقق السريع من فرضية وعملية يمكن التنبؤ بها لمدير منتج غير تقني؛ نقطة ضعفه هي الحاجة لإشراك مهندس في الوقت المناسب عندما يبدأ النموذج الأولي بالتحول إلى منتج حقيقي.

ماذا يعني هذا

تظهر الحالة تحولاً في اقتصاد الإطلاق: اليوم يمكن لمدير منتج أو مؤسس أن يجمع نموذجاً أولياً عاملاً دون توظيف فريق وبدون أسابيع من التحضيرات إذا كان بإمكانه صياغة المتطلبات بوضوح وتجميع الأدوات في سير عمل متسق. لكن هذه أيضاً حدود النهج: تسرع الذكاء الاصطناعي الإصدار الأول وليس الانضباط الهندسي عندما يبدأ المنتج في النمو.