«این کار بالاخره بر عهده کیست؟» اگر این پرسش در جلسات پروژه شما زیاد تکرار میشود، مشکل از بیانگیزگی افراد نیست؛ از تعریفنشدهبودن مرز مسئولیتهاست. در پروژههای نرمافزاری، جایی که یک قابلیت از محصول، توسعه، تست و واحد انطباق عبور میکند، بهآسانی پیش میآید که همه فکر کنند دیگری جوابگوست. نتیجه، تأخیر، کارهای تکراری و تعارضهای کوچکی است که کمکم بزرگ میشوند. ماتریس RACI (RACI Matrix) ابزاری ساده برای پایاندادن به همین ابهام است: جدولی که برای هر فعالیت مشخص میکند چه کسی اجرا میکند، چه کسی پاسخگوی نتیجه است، چه کسی باید نظر بدهد و چه کسی صرفاً باید در جریان باشد. در این مقاله چهار نقش RACI را با دقت میشناسیم، برای پروژهای فرضی جدول کامل میسازیم و خطاهایی را مرور میکنیم که این ابزار سودمند را به سندی قفسهای تبدیل میکند.
RACI دقیقاً چه میگوید؟ آشنایی با چهار نقش
چهار حرف RACI چهار نقش را میسازد و هر نقش، رابطه یک فرد با یک فعالیت را تعریف میکند. دقت در تفاوت این نقشها مهمترین بخش کار است؛ بیشتر مشکلات ماتریسهای RACI از خلطشدن همین نقشها شروع میشود.
مسئول اجرا (Responsible)
کسی که کار را عملاً انجام میدهد؛ برنامهنویسی که ماژول را مینویسد یا کارشناسی که سند را تهیه میکند. یک فعالیت میتواند چند مسئول اجرا داشته باشد، اما زیادبودن تعدادشان معمولاً نشانه تقسیمکاری روشننشده است. اگر بیش از دو یا سه نفر R یک فعالیت باشند، احتمالاً کار هنوز بهاندازه کافی خرد نشده است.
پاسخگو (Accountable)
مالک نتیجه؛ کسی که در برابر کیفیت و سرانجام کار جواب میدهد و تأیید نهایی را میدهد. قانون طلایی این است که هر فعالیت فقط یک پاسخگو دارد. اگر دو نفر Accountable باشند، در عمل هیچکس نیست، چون هر یک میتواند مسئولیت را به دیگری واگذار کند. به یاد داشته باشید واگذاری کار، واگذاری پاسخگویی نیست؛ مدیر پروژه ممکن است تهیه سندی را به کارشناسی بسپارد، اما همچنان خودش در برابر حامی پروژه (Sponsor) پاسخگوی آن باشد.
مشاور (Consulted)
کسی که پیش از تصمیم یا اجرا از او نظر خواسته میشود و این ارتباط دوطرفه است؛ مثلاً واحد امنیت پیش از نهاییشدن طراحی درگاه پرداخت، الزامات خود را مطرح میکند. مشاورها صاحب نظرند، نه صاحب تصمیم؛ اگر نظر مشاور نهاییکننده باشد، در واقع او Accountable شده است.
مطلع (Informed)
کسی که پس از تصمیم یا اتمام کار باید در جریان باشد؛ ارتباط یکطرفه است. مطلعکردن بیش از حد بهاندازه مطلعنکردن مضر است؛ افرادی که در همه پیامها کپی میشوند، بهمرور همه را نادیده میگیرند.
جدول RACI چه شکلی است؟
ساختار ماتریس ساده است: سطرها فعالیتها را نشان میدهند — معمولاً از ساختار شکست کار (WBS) یا فهرست تحویلشدنیها — و ستونها نقشها را، نه اسم افراد. نوشتن نقش بهجای نام، سند را در برابر جابهجایی نیروها پایدارتر میکند. سه قانون برای سلامت جدول وجود دارد:
- در هر سطر دقیقاً یک Accountable باشد؛ اگر یک ستون در همه سطرها A است، بپرسید آیا واقعاً هر تصمیم باید به آن فرد برسد.
- هر سطر حداقل یک Responsible داشته باشد؛ سطری بدون R یعنی فعالیتی که کسی آن را انجام نمیدهد.
- برای هر فعالیت حداکثر یکی دو مشاور نگه دارید؛ مشاورهای پرشمار یعنی تصمیمگیری به چرخه جلسههای بیپایان تبدیل شده است.
مثال کاربردی: توسعه درگاه پرداخت
برای روشنشدن ماجرا، فرض کنید یک شرکت فینتک تصمیم گرفته برای پلتفرم فروشگاهی خود درگاه پرداخت (Payment Gateway) جدیدی توسعه دهد که هم پرداخت با کارت و هم پرداخت از کیف پول را پشتیبانی کند. فعالیتهای اصلی عبارتاند از تدوین نیازمندیها، طراحی معماری و الگوی امنیت، توسعه ماژولها، تست امنیتی و بررسی انطباق، آمادهسازی پشتیبانی و در نهایت انتشار. جدول زیر نمونهای از ماتریس RACI همین پروژه فرضی است:
| فعالیت | مدیر محصول | مدیر پروژه | لید فنی | تیم توسعه | تیم تست | واحد انطباق | مدیر پشتیبانی |
|---|---|---|---|---|---|---|---|
| تدوین نیازمندیها و محدوده | A | R | C | C | C | C | I |
| طراحی معماری و الگوی امنیت | C | I | A | R | C | C | — |
| توسعه ماژولهای درگاه | I | I | A | R | I | — | — |
| تست امنیتی و بررسی انطباق | I | I | C | C | R | A | — |
| آمادهسازی پشتیبانی و مستندات | C | R | C | I | I | I | A |
| انتشار و پایش اولیه | I | A | C | R | R | I | I |
این ترکیبها صرفاً نمونهاند و در سازمان شما بسته به ساختار قدرت و فرهنگ تصمیمگیری متفاوت خواهند بود. نکته قابلتوجه در جدول، جابهجایی ستون A در طول پروژه است: نیازمندیها نزد مدیر محصول میماند، معماری نزد لید فنی، انطباق نزد واحد ریسک و انتشار نزد مدیر پروژه. دقیقاً همین جابهجایی است که وقتی مکتوب نشود، به سؤال همیشگی «این کار با کیست؟» منجر میشود.
خطاهای رایج؛ وقتی RACI به بوروکراسی تبدیل میشود
بیشتر شکستهای ماتریس RACI ناشی از خودِ ابزار نیست؛ از نحوه استفاده است. چند خطای پرتکرار را میتوان نامبرد:
- چند Accountable در یک فعالیت: وقتی دو نفر پاسخگو ثبت شوند، سند از همان لحظه بیاعتبار است؛ هر دو منتظر میمانند دیگری تصمیم بگیرد یا هر دو تصمیمهای متناقض میدهند.
- تبدیل ماتریس به چرخه تأیید: اگر برای هر کار کوچک چهار مشاور و شش مطلع تعریف کنید، سرعت تیم را میکشید و RACI به نماد بیفایده بوروکراسی بدل میشود. ماتریسی خوب است که کار را تیز کند، نه کند.
- عدم بهروزرسانی: تیمها تغییر میکنند، نقشها جابهجا میشوند و افراد عوض میشوند؛ جدولی که در ماه دوم پروژه مرور نشده، ماه ششم فعالانه گمراهکننده است.
- ساختن بدون حضور افراد: اگر مدیر پروژه در اتاقی جدا ماتریس را تکمیل کند، صبح روز بعد با چندین اعتراض روبهرو خواهد شد. ماتریس باید در گفتوگو با خود افراد ساخته شود تا پذیرفته شود.
- خلط R و A: نوشتن A برای کسی که فقط کار را اجرا میکند و R برای کسی که باید جواب بدهد، نقشها را دقیقاً برعکس تعریف میکند.
مزایا و محدودیتها
شفافترین مزیت ماتریس، حذف حدسزدن است. تعارضهای مرزی کاهش مییابد، ورود افراد تازه به تیم سادهتر میشود و در گزارشدهی به ذینفعان میتوانید دقیقاً بگویید هر تصمیم از چه کسی است. همچنین وقتی ماتریس با ماتریس ارتباطات ترکیب شود، معلوم میشود چه کسی باید به چه کسی خبر بدهد.
اما محدودیتها را هم باید جدی گرفت. در تیمهای چابک که نقشها چرخشی و تصمیمها جمعی است، ماتریس سفتوسخت میتواند روح خودسازماندهی را خفه کند. ماتریس RACI همچنین بهتنهایی فرهنگ پاسخگویی نمیسازد؛ در سازمانی که پاسخگو بودن تنبیه میشود، هیچ جدولی مشکل را حل نمیکند. سرانجام، ماتریس بیش از حد تفصیلی — برای هر کار خرد روزمره یک سطر — عملاً هیچکس را به خواندنش ترغیب نمیکند.
کاربرد عملی: چگونه آن را بسازیم و نگه داریم؟
- فهرست فعالیتها را از WBS یا بکلاگ استخراج کنید؛ نیازی به سطر برای هر تسک خرد نیست، سطح فعالیتهای معنادار کافی است.
- ستونها را نقشها تعیین کنند و فقط در نقاطی که ابهام جدی هست از نام افراد استفاده کنید.
- در یک کارگاه کوتاه با حضور صاحبان نقشها، سلولها را با هم پر کنید؛ اختلافنظرها خودشان بخشی از ارزش کارگاهاند.
- جدول را با چهار پرسش بسنجید: هر سطر یک A دارد؟ R مشخص است؟ مشاورها واقعاً نظر میدهند؟ مطلعها به حجم پیامها اعتاد دارند؟
- نسخه نهایی را در مکانی که همه میبینند منتشر کنید و بازنگری را به نقاط عطف پروژه — شروع فاز، تغییر افراد، تغییر محدوده — گره بزنید.
چه زمانی استفاده نکنید؟ در تیمهای دو-سه نفره که همه کارها را با هم انجام میدهند، رسمیکردن نقشها ارزشی نمیافزاید و یک توافق شفاهی کافی است. همچنین اگر سازمان هنوز مالکیت آیتمها را نمیپذیرد، پیش از RACI روی پذیرش مالکیت کار کنید؛ ماتریس تقویتکننده فرهنگ پاسخگویی است، نه جایگزین آن.
نکات کلیدی این مقاله
- هر فعالیت دقیقاً یک پاسخگو (Accountable) دارد؛ چندبودن پاسخگو یعنی هیچکس پاسخگو نیست.
- مسئول اجرا کار را میکند و پاسخگو نتیجه را میپذیرد؛ خلط این دو رایجترین خطای ماتریسهاست.
- جدول را با نقشها بسازید نه با اسامی، و با حضور خودِ افراد در کارگاه مشترک تکمیل کنید.
- ماتریس سند زنده است؛ بازنگری آن را به نقاط عطف پروژه و تغییرات تیم گره بزنید.
- معیار کیفیت ماتریس، سرعتبخشیدن به تصمیمهاست؛ اگر فرآیند را کند کرده، مشاورها و مطلعها را کم کنید.
برای مطالعه عمیقتر
- مسئولیتها و نقشهای مدیر پروژه: یک مدیر پروژه واقعاً چه میکند (بخش اول) — اگر میخواهید ببینید ماتریس RACI در چارچوب بزرگتر وظایف روزانه مدیر پروژه کجا مینشیند، این مقاله تصویر کاملتری از نقشها میدهد.
- مدیریت وابستگی بین فعالیتها و تیمها در پروژههای نرمافزاری — چون بسیاری از ابهامهای مسئولیت دقیقاً در مرز وابستگی بین تیمها بروز میکند، این مقاله مکمل طبیعی ماتریس RACI است.
سوالات متداول
اگر برای یک فعالیت دو نفر را پاسخگو بنویسیم چه اتفاقی میافتد؟
در عمل هیچکس پاسخگو نخواهد بود؛ هر یک فرض میکند دیگری تصمیم میگیرد و در نقاط حساس، تصمیم گیر میکند یا دو تصمیم متناقض صادر میشود. اگر واقعاً دو نفر باید مشارکت کنند، یکی را A و دیگری را C یا R بنویسید و مرز تصمیم را شفاف کنید.
آیا RACI در تیمهای چابک هم کاربرد دارد؟
بله، اما در نسخه سبک. در اسکرام معمولاً بهجای ماتریس تفصیلی برای هر تسک، نقشهای کلیدی مانند مالک محصول و مالک تصمیمهای فنی شفاف میشوند و برای فعالیتهای مقطعی مثل تأیید انتشار یا بررسی امنیت، ماتریس کوچکی ساخته میشود.
تفاوت RACI با شرح وظایف سازمانی چیست؟
شرح وظایف به فرد و جایگاه سازمانی او میپردازد و در طول زمان کم تغییر میکند؛ RACI به رابطه نقشها با فعالیتهای یک پروژه مشخص میپردازد. یک نفر ممکن است در یک پروژه پاسخگوی انطباق و در پروژه دیگر فقط مطلع باشد.
