‏توسعه‌دهنده‌ها باید مینی-PM بشن

قبل از AI، نوشتن کد کندترین و گرون‌ترین بخش ساخت نرم‌افزار بود، برای همین فرایندهای قدیمی دور همین کمبود شکل گرفته بودن: تحلیل سنگین، تخمین دقیق، تیکت‌های پر از جزئیات. به گفته‌ی رومن نیکولایف، CTO استارتاپ Cambri، این ساختار از اول هم ایده‌ی خوبی نبود، فقط قبل از AI اونقدر به چشم نمی‌اومد.

حالا که مدل‌های زبانی نوشتن کد رو خیلی سریع‌تر کردن، سوال‌های واقعی رو میارن جلو: کاربر قراره این ویژگی رو چطوری استفاده کنه؟ چرا این فیچر مهمه؟ اگه دولوپرها جواب این سوالا رو ندونن، سرعت بیشتر تو نوشتن کد فایده‌ی چندانی نداره.

نیکولایف پیشنهاد می‌ده تصمیم‌های محصولی رو به دو سطح تقسیم کنیم: تصمیم‌های استراتژیک (مثل شرط‌بندی روی محصول و اولویت‌بندی) که دست PM می‌مونه، و تصمیم‌های کوچیک‌تر (مثل کیس‌های خاص، خطاها و جزئیات تعامل کاربر) که دیگه لازم نیست منتظر تیکت بمونن. تو تیم اون، دولوپرها اول خودشون روی مسئله تحقیق می‌کنن، چند راه‌حل پیشنهاد می‌دن، تو Slack یا یه RFC به اشتراک می‌ذارن، فیدبک می‌گیرن و بعد میرن سراغ پیاده‌سازی.

به گفته‌ی نیکولایف، برای اینکه این مدل جواب بده باید زمینه‌ی بیزینس رو در اختیار دولوپرها گذاشت: ضبط تماس‌های فروش و محصول، فیدبک پشتیبانی، و عددهای واقعی مثل نرخ رشد و ریزش کاربر. اون همچنین پیشنهاد می‌ده مهندس‌ها رو زودتر، تو قالب یه تریو از PM، طراح و مهندس، وارد کار کرد، نه اینکه فقط یه تیکت آماده دستشون بدن.

نکات کلیدی:

• رومن نیکولایف، CTO استارتاپ Cambri، میگه حالا که AI نوشتن کد رو سریع کرده، فهمیدن نیاز کاربر گلوگاه اصلیه
• تصمیم‌های استراتژیک محصول مثل اولویت‌بندی و شرط‌بندی‌های بزرگ همچنان دست PM می‌مونه
• تصمیم‌های کوچیک‌تر مثل کیس‌های خاص و خطاها باید دست خود دولوپرها بیفته
• فرایند پیشنهادی: تحقیق، پیشنهاد راه‌حل، اشتراک تو Slack یا RFC، گرفتن فیدبک، بعد تیکت و پیاده‌سازی
• برای موفقیت این مدل باید زمینه‌ی بیزینس (فیدبک، اعداد رشد و ریزش) رو در اختیار تیم فنی گذاشت