مدل «مسوول مستقیم» (directly responsible individual-DRI) یک مفهوم مدیریته که شرکت‌هایی مثل اپل، گیت‌لب، فلیپ‌بورد از آن برای توزیع مسوولیت استفاده می‌کنند. در این مدل، برای هرکاری از بزرگ‌ترین حماسه(Epic) سازمان مثل تولید آیفون۱۳ گرفته تا کوچیک‌ترین کار مثل طراحی یک آیکون برای iMessage یک مسوول مستقیم مشخص می‌شه.
در DRI همه چیز خیلی مشخص به یک فرد سپرده می‌شه از گردهم آوردن همکاران تا تهیه سخت‌افزار و موارد دیگه و به طبع مسوولیت موفقیت یا شکست کار هم به عهده این فرد قرار می‌گیره. این نقش میتونه مسوول یک حماسه، پروژه یا داستان، نگهداری یک سرویس یا برطرف کردن یک باگ باشه، به عنوان نمونه می‌شه به موارد زیر اشاره کرد:
در واقع با تفکیکDRI به صورت مشخص می‌تونیم موضوع رو به افراد بسپاریم.
مدل «مسوول مستقیم» یک مفهومه و نباید با فرآیند اشتباه گرفته بشه. هدف این مفهوم جلوگیری از گم شدن مسوولیته و باعث می‌شه اعضای شرکت به عنوان یک نقش در سازمان از مسوولیت‌های خودشون آگاه باشن و نسبت بهش دغدغه‌مند عمل کنند.
در ساختار DRI ما با مشخص کردن یک نفر به عنوان «مسوول مستقیم» و سپردن کارها به اون جلوی «پخش مسوولیت»(Diffusion of responsibility) رو می‌گیریم و با ایجاد حس مسوولیت در یک نفر از پیشبرد کار اطمینان پیدا می‌کنیم. همچنین با مشخص شدن مسوولیت باعث افزایش تمرکز افراد می‌شیم.
برای واضح‌تر شدن فرض کنید یک رخداد بوجود آمده و بخشی از سرویس از دسترس خارج شده، ممکنه چندین نفر در این موضوع درگیر باشن اما یک نفر به عنوان DRIاین رخداد مشخص می‌شه که اون فرد هم میتونه برای بقیه کارهای لازم DRI مشخصه کنه، به عنوان مثال مسوولیت اطلاع رسانی و سوشال رو به یک نفر محول کنه و یا مسوولیت یک تغییر یا تست رو به صورت مشخص به یک نفر دیگه بسپاره یا حتی مسوولیت پیگیری با یک وندور یا تامین کننده رو می‌شه به صورت مشخص واگذار کنه. ما با این کار می‌دونیم کی دقیقا قراره چه کاری انجام بده و هر فرد هم نقش خودش رو در این رخداد می‌دونه و تمرکز افراد نیز به حوزه مسوولیت خودشون محدود می‌شه.
در تیم های توسعه هم به همین شکله، هر حماسه، داستان(Story) یا کار(Task) باید یک DRI مشخص داشته باشه و هر نقش در تیم از PM، PO، Team lead، Tech lead، Developer یک DRI واضح و شفاف دارد.
انتخاب DRI در واقع یک فضای اعتماد ایجاد می‌کنه. اعتماد به آدم‌ها که بتوانند در حوزه مسوولیت خودشون کارها رو به نحو احسن انجام بدن و نیازی به میکرومنیج کردن کارها نباشه. این کار علاوه بر تفویض اختیار در حوزه تصمیم‌گیری باعث افزایش سرعت انجام کارها می‌شه، چون در کنارمون افرادی هستند که ما بهشون اعتماد داریم و اون‌ها می‌تونند مسوولانه در پیشبرد/نگهداری حوزه مسوولیتشون عمل کنند. نکته کلیدی در DRIفرصت کافی به فرد مسوول دادنه. یعنی ممکنه ما پیشبردی نبینیم ولی علت آن فراهم آوردن منابع یا مقدمات لازم باشه، در واقع اعتماد و عدم دخالت در حوزه DRI بخش خیلی مهمی از این کانسپت رو تشکیل می‌ده، تفویض اختیار به افراد به صورت سلسله مراتبی اتفاق می‌افته برای این‌که یک‌جور پیمان دوطرفه است. از سمت لیدر، فرد توانمند و مورد اعتماد انتخاب می‌شه و با شفافیت حوزه اختیار مسوولیت تفویض می‌شه و متقابلن فرد مسوول با آگاهی از توانایی خودش و انتظاری که از خروجی وجود داره این مسوولیت رو قبول می‌کنه و این پیمان که با آگاهی دو سمت شروع می‌شه اعتماد بیشتری ایجاد می‌کنه. مثل کسی که یک بسته رو به پیک می‌سپاره و برای به مقصد رسیدنش به پیک اعتماد می‌کنه لیدر به انجام رسوندن یک مسوولیت رو به شخصی می‌سپاره و برای به نتیجه رسیدنش به فرد اعتماد می‌کنه. هرجایی که این پیمان نقض بشه لیدر میتونه مسوولیت‌ها رو از فرد بگیره یا به شخص جدیدی منتقل کنه یا اگر فردی پذیرای مسوولیت موضوعی نیست بهتره براش بدنبال یک مالک جدید بگردیم. "افراد مسوول مستقیم" اجباری برای این‌که تایید دیگران در تصمیما‌تشون رو بگیرن ندارن و نیازی نیست از دیگران تایید بگیرن و نباید میکرومنیج بشن چون میتونه در تصمیم گیری براشون فشار ایجاد کنه. DRI باید کاملا آزاد و با در نظر گرفتن حلقه اعتماد در جهت انجام مسوولیتش تصمیم گیری کنه. از سمت دیگه مسوولیت تیم‌لید‌ها یا مسوولین سطح بالاتر سپردن مسوولیت به افراد با توانمندی و قابلیت‌های قابل دفاع هستش و حمایت از اون‌ها در توانمندتر شدن و به نتیجه رساندن مسوولیت‌ها.
با سپری شدن زمان ممکنه یک سری موضوعات بدون DRI بوجود بیان که «مسوول مستقیم» مشخص نداشته باشن، معمولا این موارد روی میز می‌مونه و شاید حتی بهشون اشاره بشه اما به دلیل دغدغه به فراموشی سپرده بشن. برای همین لازمه تو بازه های زمانی DRI هامون رو بازبینی کنیم و اگر به موضوعی برخوردیم که DRI نداره سعی کنیم براش یک مسوول پیدا کنیم.
با داشتنDRI ما با مشخص کردن مسوولیت‌ها جلوی عدم تمرکز تیم رو می‌گیریم، فرض کنید در یک تیم ۱۲ نفره نیاز نیست همه اعضا نگران چندین موضوع مختلف باشن و هر فرد بر روی موضوعات مربوط به خودش تمرکز داره.
در این ساختار، تصمیم گیری رو به DRI ها واگذار می‌کنیم و ممکنه یک DRI مثل شخصی که مسوول یک حماسه است داستان‌ها رو به اشخاص دیگه‌ای بسپره و حتی اونایی که DRI یک داستان هستن برای تسک‌ها اشخاص دیگه‌ای رو به عنوان DRI مشخص کنن و این چرخه رو می‌شه ادامه دار دید اما موضوع مهم اینه که در این روند بتونیم به افراد اعتماد کنیم و هر فرد مسوول موفقت یا شکست مواردی هستش که تصمیمش رو به عهده داره.
همچنین در مفهوم DRI تصمیم‌گیری‌ها به شکل خودکامه انجام می شن، ولی ما باید به خاطر داشته باشیم که مسوول موفقیت یا شکست تصمیم‌گیری هم ما هستیم و اگر چارچوبی برای موضوعی تعریف شده ما اون چارچوب رو باید رعایت کنیم. مثلن اگر برای پروداکشن شدن یک قطعه کد نیاز به Peer Review هست ما حتی اگر DRI باشیم نمی‌تونیم این مورد رو نقض کنیم و باید کدمون Reviewبشه. بهتره وقتی ما DRIموضوعی هستیم که می تونه بر روی افراد دیگه تاثیرگذار باشه در مورد تصمیمی که میخوایم بگیریم با افرادی که تحت تاثیر قرار می‌گیرن هم مشورت کنیم اما این موضوع پیچیدگی های خودشو داره، مثلن فرض کنید شخصی مسوول خرید خودکار در یک تیم باشه آیا چون قراره از این خودکار همه استفاده کنن باید نظر همه رو قبل از خرید کسب کنه؟ مشخصن نه! اما اگر خودکاری بخره که کسی نتونه استفاده کنه یا مقبول بقیه نباشه، تصمیمش با شکست مواجه شده. یا فرض کنیم من تیم لید یک تیم ۱۲ نفره باشم، آیا برای مثلا مهاجرت از Kanban به Scrum باید نظر همه رو جلب کنم؟ در اینجا هم مشخصا خیر! چون این مورد جزو DRI های تیم‌لید محسوب می‌شه و اونه که باید نسبت به عملکرد تیم و نحوه چرخش کارها و … دغدغه داشته باشه. اما باز هم می‌شه پرسید تصمیمی که با همراهی و مقبولیت همراه نباشه موفقیت آمیزه؟ احتمالا خیر. مثال ملموس دیگه ساعت دیلی تیم میتونه باشه، تیم لید میتونه ساعت دیلی رو مشخص کنه اما اگر این ساعت با همراهی اعضای تیم نباشه مشخصا یک تصمیم شکست خورده است. در واقع DRI به میزان زیادی به افراد اختیار می‌ده اما در مقابل پاسخگویی و مسوولیت‌پذیری هم انتظار داره. زمانی که ما DRI موضوعی هستیم مسوول خوشحال بودن بقیه نیستیم(البته برای مدیران و تیم‌لید‌ها متفاوته و حال خوب تیم بخشی از مسوولیت‌هاشون رو شامل می‌شه) اما باید به یاد داشته باشیم تصمیمی که روی بقیه افراد یا DRI ها تاثیرگذار باشه یا با همراهی نباشه معمولا موفقیت آمیز نیست.
یکی از مواردی که باید در بحث DRI بهش توجه کنیم عدم ایجاد دایره تاریک در تصمیم گیری‌ها و موضوعاته، برای همین بخش مهمی از چرخه به تولید داکیومنت و شفافیت در تصمیم‌گیری‌ها بر می‌گرده ما همواره ازDRI هامون میخوایم دلیل تصمیم‌هاشون و یا مواردی که ما رو نسبت به موضوعی که مسوولش هستن آگاه کنن. با این کار ما زمینه رو برای Handover موضوعات و ایجاد زمینه برای دادن فیدبک در راستای ایجاد فضای گفت‌وگو فراهم می‌کنیم. وقتی DRI ها تصمیم‌هاشون رو شفاف بیان کنن هر کسی میتونه نسبت به تصمیم فیدبک بده و یک جورایی ما فضا رو برای مشارکت همه فراهم می‌کنیم اما تصمیم گیرنده در مورد موضوع شخص مسوول مستقیمه. ما افراد مسوول مستقیم رو همواره تشویق می‌کنیم که پذیرای نظرات و مشارکت بقیه افراد باشن.
ما از DRI هامون انتظار داریم موارد زیر رو در خصوص موضوعاتی که DRI ش هستن داشته باشن:
توجه داشته باشیم که درسته تصمیم گیرنده نهایی DRI هست ولی این نمی‌تونه جلوی نظر دادن بقیه و مشارکت بقیه رو بگیره، به عنوان مثال من میتونمDRI تسکی نباشم اما راهکاری براش ارایه بدم، اما این‌که این راهکار به مرحله عمل برسه رو "شخص مسوول مستقیم" اون تسک باید تصمیم گیری کنه.
همچنین DRI ها می‌تونن برای تصمیم گیریشون تایید بقیه افراد رو هم بگیرن، فرض کنید من میخوام تصمیم بگیرم که ممکنه بارحقوقی داشته باشه و میتونم برای اطمینان تایید واحد حقوقی شرکت رو نسبت به تصمیمم بگیرم، لازم به ذکر با این کار چیزی از مسوولیت من نسبت به موضوع کاهش پیدا نمی‌کنه.
در انتها به نظرمDRI يک کانسپت خیلی خوب برای اطمینان از در جریان بودن کارها و افزایش مشارکت و حس مسوولیت پذیری در افراد میتونه باشه که با توجه به سایز شرکت و تیم می‌شه ازش بهره برد و خصوصا در دوران دورکاری میتونه به مدیریت تیم های Operation و توسعه کمک کنه.
منابع:
https://about.gitlab.com/handbook
https://medium.com/@mmamet/directly-responsible-individuals-f5009f465da4
https://www.forbes.com/sites/quora/2012/10/02/how-well-does-apples-directly-responsible-individual-dri-model-work-in-practice/?sh=1a90f9a2194c
