توسعهدهندهها باید مینیPM بشن
هوش مصنوعیخلاصهٔ کاملتر
رومن نیکولایف، CTO شرکت Cambri، تعریف میکنه وقتی مدیرعامل جدیدشون اومد، رفت از مدیرعاملها و رهبرهای دیگه پرسید چی واقعاً سطح یه تیم مهندسی رو بالا میبره. جواب یکی بود: دادن business context به خود مهندسها، یعنی اینکه توسعهدهنده بدونه کاربر کیه، با چی دستوپنجه نرم میکنه و کسبوکار دنبال چیه. نویسنده میگه تو همهٔ جاهایی که قبلاً کار کرده مرز سفت و سخت بوده: PM کار PM رو میکنه، توسعهدهنده کد میزنه.
به گفتهٔ نویسنده، اون تیم نیمهسیلو از اولش هم ایدهٔ بدی بود، ولی قبل از AI به چشم نمیاومد. وقتی یه پروژه شیش ماه طول میکشید، سه ماه همتراز کردن ذینفعها و جمع کردن نیازمندی خیلی هم بد به نظر نمیرسید. اون با این حرف رایج که «نوشتن کد هیچوقت گلوگاه نبوده» مخالفه و میگه کدنویسی دقیقاً کندترین و گرونترین بخش کار بوده؛ برنامهریزی سنگین، تخمین و تیکتهای پرجزئیات هم دور همین کمبود ساخته شده بودن.
سطح اول اینه که تیم مسئله رو بشناسه؛ سطح دوم اینه که بتونه تصمیم محصولی هم بگیره. شرطبندیهای بزرگ محصول، اولویتبندی و تصمیمهای پرریسک همچنان مال PMه، ولی جزئیات تعامل کاربر، حالتهای خاص و وضعیتهای خطا لازم نیست از بالا بیاد. روال خود نویسنده اینه: توسعهدهنده بررسی میکنه، یکی دو راهحل میده، تو Slack یا به شکل RFC (یه سند کوتاه پیشنهادی که بقیه روش نظر میدن) مطرحش میکنه و اگه مخالفتی نبود خودش تیکت رو میسازه و میره جلو.
نتیجهاش اینه که نه توسعهدهنده پشت PM معطل میمونه، نه PM زیر بار همهٔ تصمیمها له میشه. نویسنده میگه مدیریت محصول از بین نمیره و یکی باید تصمیم بگیره چی انجام بشه و چی نه، ولی «چطور انجامش بدیم» داره میافته گردن مهندسها. به باورش دیگه دونستن سینتکس و یه فریمورک کافی نیست، چون LLMها هر روز تو تبدیل زبان طبیعی به کد بهترن و یه تیکت کاملاً مشخص خوراک ایدهآل یه agentه.
نویسنده playbook قدمبهقدم نمیده، ولی چند تا کار رو از تجربهٔ خودش پیشنهاد میکنه. اول context رو باز کن: ضبط جلسههای محصول و فروش، بازخورد پشتیبانی و عددهای واقعی مثل adoption، churn و معاملههای برده و باخته. بعد مهندس رو زودتر بیار وسط، یه تیم سهنفره از PM و طراح و مهندس که از خود درد کاربر شروع میکنه و به جای سند مشخصات، پروتوتایپ سریع میسازه. آخرش هم مرز تصمیمگیری رو مکتوب کن و کل تغییر رو مثل یه آزمایش ببین.
نکات کلیدی:
- شرطبندی محصول، اولویتبندی و تصمیمهای پرریسک دست PM میمونه؛ حالتهای خاص و جزئیات تعامل کاربر میره سمت توسعهدهنده.
- روال ششمرحلهای پیشنهادی: تحقیق، ارائهٔ یکی دو راهحل، طرحش تو Slack یا RFC، صبر برای بازخورد، اصلاح راهحل، بعد ساخت تیکت.
- منظور از context اینه: ضبط جلسههای فروش و محصول، بازخورد پشتیبانی و عددهای adoption، churn و معاملههای برده و باخته.
- الگوی product trio از PM و طراح و مهندس، همراه پروتوتایپ سریع به جای سند مشخصات، همون چیزیه که تو بازنویسی بزرگ تیمشون جواب داد.
- نویسنده میگه ۵۰ سال به توسعهدهنده پول میدادن که «ترجمه» کنه؛ از این به بعد پول میگیره که خلق کنه.
