AI Project Manager چه کارهایی می‌تواند و نمی‌تواند انجام دهد؟

AI Project Manager یک نقش واحد نیست

وقتی می‌گوییم «مدیر پروژهٔ AI»، ممکن است دربارهٔ چهار چیز متفاوت حرف بزنیم. یک ابزار می‌تواند فقط دستیار باشد و خلاصهٔ جلسه بدهد. ابزار دیگری می‌تواند coordinator باشد و از روی eventها task بسازد. یک Agent محدود می‌تواند با مجوز مشخص، issue باز کند، owner را یادآوری کند یا یک گزارش را به‌روز کند. اما accountable owner کسی است که هدف، trade-off و پیامد تصمیم را می‌پذیرد. این چهار سطح را نباید در یک برچسب محصولی مخلوط کرد.

در مستندات رسمی فعلی OpenAI، Agentها به‌عنوان سیستم‌هایی توضیح داده می‌شوند که می‌توانند با ابزار کار کنند، taskهای چندمرحله‌ای را جلو ببرند و با Agentهای دیگر همکاری کنند. همان مستندات بین runtimeهای مختلف، محل نگه‌داری state، اجرای ابزار و میزان کنترل application تفاوت می‌گذارد. این یعنی «می‌تواند چند مرحله را اجرا کند» با «می‌تواند مسئولیت پروژه را بپذیرد» یکی نیست.

برای تصمیم‌گیری، به جای پرسیدن اینکه Agent چقدر مستقل است، باید بپرسیم در هر مرحله چه نوع خروجی دارد و چه سطح اختیاری برای اقدام گرفته است. استقلال فنی، مسئولیت سازمانی تولید نمی‌کند.

• دستیار: context را جمع و خروجی را برای فهم انسان آماده می‌کند.
• هماهنگ‌کننده: کارهای تکراری بین ابزارها و افراد را با قواعد روشن جابه‌جا می‌کند.
• Agent محدود: برای یک workflow مشخص تصمیم‌های قابل‌برگشت می‌گیرد و action انجام می‌دهد.
• مالک پاسخ‌گو: هدف، تعهد، ریسک و پیامد تصمیم را می‌پذیرد؛ این بخش همچنان انسانی است.

AI امروز در مدیریت پروژه کجا واقعاً مفید است؟

بهترین نقطهٔ شروع جایی است که مشکل اصلی، پراکندگی context و کار تکراری است؛ نه جایی که سازمان می‌خواهد با یک bot کمبود تصمیم‌گیری را پنهان کند. AI می‌تواند issueها، meeting noteها، تغییرات repository، تصمیم‌های قبلی، dependencyها و deadlineها را در یک context pack کوتاه کنار هم بگذارد. ارزش این کار در کم‌کردن زمان جست‌وجو و آماده‌شدن برای تصمیم است، نه در طولانی‌ترکردن گزارش.

Agent می‌تواند چند plan پیشنهادی بسازد و برای هرکدام فرض، dependency، ریسک، ظرفیت لازم و نقطهٔ بازبینی را توضیح دهد. این با اعلام یک تاریخ قطعی فرق دارد. وقتی دادهٔ پروژه ناقص یا متناقض است، خروجی درست باید uncertainty را نشان دهد و سؤال بعدی را روشن کند، نه اینکه یک timeline تمیز اما ساختگی تحویل دهد.

همچنین بخشی از هماهنگی کم‌ریسک قابل‌واگذاری است: یادآوری یک owner، تبدیل تصمیم تأییدشده به task، به‌روزرسانی وضعیت بر اساس event معتبر یا ساختن پیش‌نویس status report. در همهٔ این موارد باید source، زمان استخراج، owner و امکان اصلاح برای انسان قابل‌مشاهده باشد.

• ساختن یک خلاصهٔ قابل‌اعتماد از وضعیت، تصمیم‌های باز و blockerها
• استخراج dependency و سؤال‌های بدون پاسخ از issue، سند و تغییرات فنی
• ارائهٔ چند سناریوی برنامه به جای یک تاریخ قطعی بدون فرض
• پیش‌نویس‌کردن گزارش برای stakeholder با تفکیک واقعیت، ریسک و پیشنهاد
• انجام actionهای محدود، قابل‌برگشت و auditپذیر پس از approval
• یادآوری follow-upهایی که owner و deadline مشخص دارند

مستقل‌بودن با پاسخ‌گو بودن فرق دارد

یک اشتباه رایج این است که هرچه Agent action بیشتری انجام دهد، آن را مدیر پروژهٔ بهتری بدانیم. این معیار خطرناک است. تعداد taskهای ساخته‌شده، پیام‌های ارسال‌شده یا statusهای به‌روزشده، نشانهٔ outcome نیست. ممکن است Agent با سرعت زیاد کارهایی تولید کند که تیم باید دوباره آن‌ها را بررسی، اصلاح یا حذف کند.

مستندات رسمی GitHub دربارهٔ Copilot cloud agent نمونهٔ خوبی از تفکیک capability و اختیار است: cloud agent می‌تواند repository را بررسی کند، plan بسازد، روی branch تغییر ایجاد کند و بعد امکان review، iteration و pull request را فراهم کند. همین مسیر نشان می‌دهد research و coding مستقل می‌تواند بخشی از workflow باشد، اما review و تصمیم برای آماده‌بودن تغییر همچنان یک مرحلهٔ جداست. automationهای schedule یا event هم بدون تعریف owner و approval، خودبه‌خود کیفیت پروژه را تضمین نمی‌کنند.

در پروژهٔ واقعی، autonomy باید با سطح ریسک تنظیم شود. actionی که فقط یک draft می‌سازد با actionی که دادهٔ مشتری را تغییر می‌دهد، کد production را merge می‌کند یا تعهد بیرونی ایجاد می‌کند یکسان نیست. هرچه برگشت‌پذیری کمتر و اثر تصمیم بیشتر باشد، مرز approval باید انسانی‌تر و روشن‌تر شود.

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

در Scrum، AI مالک کدام مسئولیت‌ها نیست؟

Scrum Guide مسئولیت‌ها را به شکل قابل‌توجهی روشن می‌کند. Product Owner پاسخ‌گوی بیشینه‌کردن value و مدیریت مؤثر Product Backlog است؛ حتی اگر بعضی کارها را به دیگران واگذار کند، پاسخ‌گویی ناپدید نمی‌شود. Developers برنامهٔ Sprint را می‌سازند، کیفیت را با Definition of Done نگه می‌دارند و هر روز plan را با واقعیت تطبیق می‌دهند. Scrum Master به اثربخشی تیم، رفع impediment و استفادهٔ درست از Scrum کمک می‌کند.

AI می‌تواند برای هر سه نقش context و پیشنهاد آماده کند، اما نمی‌تواند از طرف آن‌ها قضاوت کند که کدام outcome ارزشمندتر است، چه سطحی از کیفیت قابل‌قبول است، کدام ریسک اخلاقی یا تجاری پذیرفتنی است یا یک گفت‌وگوی سخت انسانی چگونه باید پیش برود. می‌توانیم draft Product Backlog یا پیشنهاد Sprint بسازیم؛ نمی‌توانیم مالکیت آن را با یک prompt جابه‌جا کنیم.

حتی Daily Scrum هم با status report خودکار جایگزین نمی‌شود. هدف Daily Scrum inspect کردن progress به سمت Sprint Goal و تطبیق‌دادن plan است. اگر bot خلاصهٔ خوبی تولید کرده باشد، جلسه می‌تواند از خواندن وضعیت عبور کند و روی blocker و تصمیم متمرکز شود. اما اگر تیم فقط گزارش bot را برای هم بخواند، AI به ceremony جدید تبدیل شده است؛ موضوعی که در مقالهٔ قبلی این مجموعه بررسی کردم.

• Product Owner: AI پیشنهاد می‌دهد؛ مالک value، Product Goal و ترتیب نهایی کار انسان است.
• Developers: AI plan یا تخمین را آماده می‌کند؛ تعهد Sprint و کیفیت خروجی با تیم است.
• Scrum Master: AI الگو و impediment را برجسته می‌کند؛ تغییر سیستم همکاری و coaching انسانی است.
• Stakeholder: AI گزارش را خلاصه می‌کند؛ مذاکره، اعتمادسازی و پذیرش trade-off واگذارشدنی نیست.

چه چیزهایی را نباید به AI Project Manager بسپاریم؟

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

هدف و ارزش را نمی‌شود از روی تعداد issue یا sentiment گزارش‌ها استخراج کرد. تصمیم دربارهٔ اینکه چه مسئله‌ای ارزش حل‌کردن دارد، چه کسی از نتیجه سود می‌برد و چه چیزی عمداً ساخته نمی‌شود، یک قضاوت محصولی و کسب‌وکاری است. AI می‌تواند شواهد را مرتب کند؛ انتخاب outcome و پذیرش هزینهٔ فرصت را انجام نمی‌دهد.

تعهد بیرونی هم فقط جمع‌زدن زمان taskها نیست. وقتی به مشتری، مدیر، سرمایه‌گذار یا تیم دیگری تاریخ و کیفیتی قول می‌دهیم، در واقع دربارهٔ ریسک و trade-off تعهد داده‌ایم. AI می‌تواند سناریو بسازد، اما انسان باید بداند چه فرضی را می‌پذیرد و اگر آن فرض شکست خورد، چه چیزی را تغییر می‌دهد.

در quality، security، privacy، استخدام، ارزیابی افراد، قرارداد و release هم باید approval و امکان اعتراض انسانی جدی باشد. مدل می‌تواند نشانهٔ خطر را پیدا کند، ولی نباید با confidence ظاهری تصمیم نهایی را پنهان کند.

• انتخاب Product Goal و تعریف value برای کاربر و کسب‌وکار
• قول‌دادن تاریخ، scope یا SLA به بیرون از تیم
• پذیرش risk، استثنا از policy یا عبور از quality gate
• ارزیابی عملکرد، حل تعارض و گفت‌وگوی حساس با افراد
• merge، release، حذف داده یا تغییر برگشت‌ناپذیر بدون approval روشن
• تبدیل حدس مدل به واقعیت رسمی در status یا تصمیم مدیریتی

یک ماتریس اختیار ساده برای شروع

برای اینکه مرزها فقط در حد شعار نمانند، هر action را با اثر، برگشت‌پذیری و حساسیت داده بررسی کنید. اینجا نمرهٔ ریسک جای قضاوت را نمی‌گیرد؛ فقط کمک می‌کند approval را از ابتدا طراحی کنیم. اگر تیم دربارهٔ ریسک اختلاف جدی دارد، همان اختلاف یک signal است که context یا owner هنوز روشن نیست.

در سطح کم‌ریسک، AI می‌تواند action را با قواعد ثابت انجام دهد؛ مثلاً ساختن draft یا یادآوری owner. در سطح متوسط، پیشنهاد می‌دهد و انسان پیش از action تأیید می‌کند. در سطح بالا، AI فقط evidence و گزینه‌ها را آماده می‌کند و تصمیم، اجرا و ثبت rationale انسانی می‌ماند. برای هر سطح یک log و مسیر rollback لازم است.

• کم‌ریسک: خلاصه‌سازی، برچسب‌گذاری اولیه، ساخت draft و یادآوری؛ action محدود و قابل‌برگشت.
• ریسک متوسط: پیشنهاد تغییر اولویت، تخصیص task یا plan؛ approval صاحب تصمیم پیش از اجرا.
• پرریسک: تغییر production، release، دادهٔ حساس، تعهد بیرونی یا استثنا از policy؛ AI فقط تحلیل و evidence.
• برای همهٔ سطوح: source، timestamp، مدل یا نسخهٔ workflow، owner، rationale و rollback ثبت شود.

Workflow درست از signal تا learning چگونه است؟

الگوی عملی من برای AI Project Manager یک زنجیرهٔ شش‌مرحله‌ای است: signal، context، recommendation، approval، action و learning. اگر یک حلقه حذف شود، یا سیستم کور می‌شود یا به تولید خروجی بدون مسئولیت می‌رسد.

در signal باید معلوم باشد چه چیزی trigger شده است: یک issue جدید، تغییر scope، نزدیک‌شدن deadline، شکست تست یا افزایش waiting. در context، AI باید sourceها و محدودیت‌های مرتبط را جمع کند و موارد متناقض یا missing را بگوید. در recommendation، چند گزینه با trade-off ارائه شود، نه یک جواب قطعی که منشأ آن معلوم نیست.

approval باید دست صاحب واقعی تصمیم باشد و با سطح ریسک تغییر کند. بعد از action، اثر واقعی را ثبت کنید: زمان انتظار کم شد؟ blocker زودتر دیده شد؟ rework بالا رفت؟ stakeholder تصمیم بهتری گرفت؟ این evidence باید به prompt، policy یا حذف workflow برگردد. AI بدون learning فقط یک موتور تکرار است.

• Signal: رویداد معتبر و قابل‌مشاهده‌ای که نیاز به بررسی را شروع می‌کند.
• Context: source، تازگی، محدودیت و uncertainty که پیشنهاد بر اساس آن ساخته می‌شود.
• Recommendation: گزینه‌ها، trade-off، ریسک و سؤال‌های باز.
• Approval: صاحب تصمیم و سطح تأیید متناسب با اثر action.
• Action: اقدام محدود، auditپذیر و در صورت امکان قابل‌برگشت.
• Learning: مقایسه با baseline و تصمیم برای ادامه، اصلاح یا خاموش‌کردن workflow.

هزینهٔ واقعی فقط اشتراک ابزار نیست

اگر بخواهیم AI Project Manager را اقتصادی بسنجیم، نباید فقط قیمت مدل یا اشتراک نرم‌افزار را ببینیم. اتصال به ابزارها، پاک‌سازی permissionها، طراحی prompt و policy، نگه‌داری integration، review خروجی، observability، مدیریت داده و آموزش تیم هم هزینه‌اند. مهم‌تر از همه، هزینهٔ توجه انسان است: چه تعداد پیشنهاد باید بررسی شود و چه کسی مسئول تصمیم است؟

در محیطی که دادهٔ پروژه ناقص است، AI ممکن است زمان تولید گزارش را کم کند اما زمان را به راستی‌آزمایی منتقل کند. این انتقال لزوماً بد نیست؛ اگر verification آگاهانه جای حدس‌زدن را بگیرد، ارزش ایجاد شده است. اما اگر تیم تصور کند گزارش خودکار حقیقت نهایی است، هزینهٔ پنهان آن rework و ازبین‌رفتن اعتماد خواهد بود.

برای یک pilot، چند metric محدود کافی است: زمان پیدا کردن context، زمان رسیدن به تصمیم، درصد پیشنهادهایی که نیاز به اصلاح داشتند، زمان انتظار برای approval، rework مرتبط با پیشنهاد AI، و outcome workflow. تعداد run، token، task یا notification را فقط برای فهم هزینه و load نگه دارید؛ آن‌ها معیار ارزش نیستند.

• Decision latency: از signal معتبر تا تصمیم قابل‌اجرا چقدر زمان می‌برد؟
• Context time: تیم برای پیدا کردن اطلاعات لازم چقدر وقت صرف می‌کند؟
• Recommendation quality: چند پیشنهاد پذیرفته، اصلاح یا رد می‌شوند و چرا؟
• Rework و failure: بعد از action چند مورد برگشت، اصلاح یا incident ایجاد می‌شود؟
• Outcome: آیا blocker، waiting، خطا یا زمان رسیدن به ارزش واقعاً بهتر شده است؟

Pilot چهارده‌روزه برای یک تیم کوچک

برای شروع، یک پروژهٔ کامل را به Agent نسپارید. یک workflow باریک انتخاب کنید که دردش معلوم، sourceهایش در دسترس و actionهایش کم‌ریسک باشد؛ مثلاً آماده‌کردن خلاصهٔ هفتگی blockerها و تصمیم‌های باز. پیش از فعال‌کردن AI، baseline ساده بگیرید: این گزارش اکنون چقدر زمان می‌برد، چند بار اصلاح می‌شود و کدام تصمیم‌ها به‌خاطر نبود context عقب می‌افتند.

در چند روز اول فقط observe و draft کنید. خروجی را به source و uncertainty وصل کنید و از تیم بخواهید false positive، missing context و جمله‌های گمراه‌کننده را علامت بزند. در هفتهٔ دوم فقط یک action برگشت‌پذیر را با approval روشن فعال کنید. در پایان، دربارهٔ scale، اصلاح یا retire تصمیم بگیرید؛ نه بر اساس هیجان demo، بر اساس baseline و شواهد.

این pilot همچنین نشان می‌دهد آیا مسئله واقعاً کمبود automation بوده است یا کمبود owner، تعریف Done، دسترسی به داده و تصمیم روشن. گاهی بهترین نتیجهٔ AI Project Manager این است که به ما نشان دهد قبل از خرید Agent باید workflow و مسئولیت را اصلاح کنیم.

• روز ۱ و ۲: workflow، owner، source، baseline و stop criterion را مشخص کنید.
• روز ۳ تا ۵: AI فقط context و draft recommendation تولید کند؛ action ممنوع باشد.
• روز ۶ تا ۹: خطاها، missing source، زمان review و سطح اعتماد تیم را ثبت کنید.
• روز ۱۰ تا ۱۲: یک action کم‌ریسک و قابل‌برگشت با approval فعال کنید.
• روز ۱۳ و ۱۴: metricها را با baseline مقایسه و دربارهٔ ادامه، اصلاح یا توقف تصمیم بگیرید.

نشانه‌های شکست AI Project Manager چیست؟

اگر bot هر روز statusهای بیشتر، alertهای بیشتر و taskهای بیشتری می‌سازد اما کسی نمی‌داند چه تصمیمی باید بگیرد، سیستم شکست خورده است. اگر افراد برای جلوگیری از خطا خروجی را در چند کانال دوباره کپی می‌کنند، اگر owner فقط در ظاهر مشخص است یا اگر approval به کلیک بدون خواندن تبدیل شده، autonomy به بدهی عملیاتی تبدیل شده است.

نشانهٔ دیگر، صاف‌کردن عدم‌قطعیت است. پروژه‌ای که در واقع dependency حل‌نشده دارد نباید در گزارش AI با زبان قطعی «on track» دیده شود. سیستم خوب باید بتواند بگوید «نمی‌دانم»، source متناقض است، داده قدیمی است یا برای تصمیم به یک گفت‌وگو نیاز داریم. قابل‌اعتمادبودن همیشه به معنی confidentبودن نیست.

در نهایت، اگر AI بهانه‌ای برای حذف گفت‌وگوی لازم با تیم یا stakeholder شود، هدف را از دست داده‌ایم. مدیریت پروژه فقط حرکت کارت‌ها نیست؛ هماهنگ‌کردن معنا، مسئولیت، محدودیت و تصمیم در شرایط ناقص است. AI باید این کار را روشن‌تر کند، نه اینکه آن را پشت زبان رسمی و خلاصه‌های زیبا پنهان کند.

• تعداد گزارش و alert بالا رفته اما waiting یا rework کم نشده است.
• پیشنهادها source، timestamp یا owner ندارند.
• مدل uncertainty را پنهان و یک status قطعی تولید می‌کند.
• approvalها تشریفاتی شده‌اند و کسی rationale را نمی‌خواند.
• تیم به خروجی Agent عادت کرده اما معیار stop یا rollback ندارد.
• گفت‌وگوی انسانی با summary یا score جایگزین شده است.

جمع‌بندی از نگاه من

AI Project Manager زمانی ارزش دارد که فاصلهٔ بین signal معتبر و تصمیم خوب را کوتاه کند، نه اینکه فقط یک شخصیت شبیه مدیر پروژه بسازد. اگر Agent بتواند context را سریع‌تر جمع کند، گزینه‌ها را با فرض و ریسک نشان دهد، کار تکراری کم‌خطر را انجام دهد و برای هر action ردپای قابل‌بررسی بگذارد، یک تقویت‌کنندهٔ واقعی برای تیم است.

اما مالکیت هدف، trade-off، تعهد، کیفیت، رابطه و پیامد همچنان باید در نقش‌های انسانی بماند. Product Owner، Developers، Scrum Master، مدیر پروژه یا بنیان‌گذار می‌توانند کارهایی را delegate کنند؛ accountability را delegate نمی‌کنند. این تفاوت کوچک در واژه، مرز اصلی بین استفادهٔ مسئولانه از AI و شبیه‌سازی خطرناک یک نقش است.

پیشنهاد عملی حکیم ساده است: یک workflow باریک انتخاب کنید، baseline بسازید، AI را ابتدا در حالت draft و decision support آزمایش کنید، سپس فقط action کم‌ریسک و قابل‌برگشت را واگذار کنید. source، uncertainty، owner، approval، rollback و metric را از روز اول بگذارید. اگر بعد از چند چرخه decision time، waiting یا rework بهتر نشد، Agent را بزرگ‌تر نکنید؛ workflow را کوچک‌تر یا خاموش کنید.

پروژهٔ خوب پروژه‌ای نیست که در آن AI بیشترین کار را انجام می‌دهد. پروژهٔ خوب پروژه‌ای است که در آن انسان‌ها تصمیم‌های بهتر، سریع‌تر و قابل‌دفاع‌تری می‌گیرند و دقیقاً می‌دانند کدام بخش را به ماشین سپرده‌اند.

منابع اولیه برای بررسی

راهنمای رسمی Scrum برای مسئولیت‌های Product Owner، Developers و Scrum Master، هدف Sprint و Daily Scrum و نقش inspect و adapt: https://scrumguides.org/scrum-guide.html — بررسی‌شده در 2026-09-15.

مستندات رسمی OpenAI دربارهٔ انتخاب runtime برای Agentها، اجرای taskهای چندمرحله‌ای، ابزار، همکاری بین Agentها، state و تفاوت کنترل در Agents API و Agents SDK: https://developers.openai.com/api/docs/guides/agents — بررسی‌شده در 2026-09-15.

مستندات رسمی GitHub دربارهٔ توانایی Copilot cloud agent برای research، plan، ایجاد تغییر روی branch، review، iteration، pull request و automation بر اساس schedule یا event: https://docs.github.com/en/copilot/concepts/agents/cloud-agent — بررسی‌شده در 2026-09-15.

مرز شواهد و تحلیل

تعریف مسئولیت‌های Scrum و capabilityهای اعلام‌شدهٔ OpenAI و GitHub از منابع اولیهٔ بالا گرفته شده‌اند. این منابع تضمین نمی‌کنند که یک Agent برای هر تیم زمان، کیفیت یا outcome را بهتر کند. تفکیک دستیار، coordinator، Agent محدود و مالک پاسخ‌گو، ماتریس اختیار، زنجیرهٔ signal تا learning، معیارهای pilot و تحلیل اثر AI بر مدیریت پروژه، چارچوب تحلیلی امین رضا سیدآبادی است و باید با داده، ریسک و workflow واقعی همان سازمان تطبیق داده شود.

مثال‌های pilot در این مقاله فرضی‌اند و نتیجهٔ یک پروژهٔ مشخص را ادعا نمی‌کنند. هیچ عدد عملکردی برای پروژه یا سابقهٔ کاری شخصی ساخته نشده است؛ عددهای پیشنهادی فقط برای تعریف baseline و مقایسهٔ قبل و بعد هستند.