بازگرداندن مسئولیت پذیری در تیم

براساس تجربه‌ای که تو این سال‌ها داشتم، مهمترین فاکتوری که دیدم باعث پیشرفت یک نفر در کارش شده، حس مسئولیت پذیریش در کار بوده. به همین ترتیب، موفق‌ترین تیم‌هایی که دیدم اون‌هایی بودن که نفراتش مسئولیت پذیری بالایی داشتند.

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

به نظر من جواب اینه که خیلی زیاد. مقالات زیادی هست در این رابطه و کارهای بسیاری هست که در شرکت‌ها انجام می‌شه تا افراد تیم مشارکت بیشتری داشته باشن و با علاقه و مسئولیت پذیری بالاتری کار کنند.

اما تو این مطلب می‌خوام یکی از ساده‌ترین و کاربردی‌ترین روش‌هایی که در طول این سال‌ها پیدا کردم و از اون استفاده کردم و می‌تونم بگم همیشه هم خوب کار کرده رو در موردش بنویسم.

اسم این روش DRI (Directly Responsible Individuals) هست که گفته می‌شه استیو جابز و شرکت اپل ابداع کننده اون هستند.

روش کار بسیار ساده هست: هر کاری تنها و تنها به یک نفر باید اساین شود و مسئولیت انجام آن کار نیز به عهده همان فرد باشد.

اگر اشتباه نکنم سرویس Asana بود که مشکل اساسی‌ای که باهاش داشتم عدم امکان اساین کردن یک تسک به بیش از یک نفر بود در حالی که در ترلو نفرات زیادی را می‌شد به یک کارت اساین کرد. بعدها که با این سیستم آشنا شدم، متوجه شدم دلیل اینکه بیش از یک نفر را نمی‌شود به یک تسک اساین کرد همین موضوع بود (اینجا بود که فهمیدم پشت سیستم‌های مدیریت پروژه بزرگ یکسری تفکر هست و چه بهتر که با این تفکرها آشنا بشیم تا بتونیم ابزار بهتری برای خودمون و کارمون پیدا کنیم).

اساین کردن بیش از یک نفر به تسک می‌تونه مشکلاتی رو بوجود بیاره حتی اگر تک تک اون نفرات هم مسئولیت پذیری بالایی داشته باشند. برای مثال جلوی مشکلی نظیر اینکه «من فکر می‌کردن فلانی داره روش کار می‌کنه»، یا «در تصور من مسئولیت انجامش با اون بود» و… جلوش گرفته می‌شه.

اما دیگر مشکلاتی که الان به ذهنم میاد که با این روش دیگر آن‌ها را نخواهید دید یا خیلی کمتر می‌بینید:

  • چرا این انجام نشده؟ فلان جاش منتظر فلانی بودم. خب چرا خبر ندادی؟ گفتم تو می‌دونی دیگه!
  • به من تسک بدید منم انجام می‌دم. بقیش برام مهم نیست (این دسته از نفرات جایی در این گونه تیم‌ها ندارند، پس باهاشون خداحافظی کنید)
  • چرا به این شکل انجام شده؟ برای اینکه فلانی کارش رو درست انجام داده. چه انتظاری از من داری؟
  • واقعا هیچ کاری براش انجام ندادین؟ من در تصورم این بود که فلانی باید انجام بده (و اون یکی نفر هم همین موضوع رو عنوان می‌کنه)

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

  • یک تسک یک فرآیند انجام داره، از تعریف اون تا انجامش در بخش‌های مختلف و در آخر تست اون و تحویل. می‌توانید برای چند تا از این قسمت‌ها به تفکیک تسک‌های جداگانه باز کنید اما به هر حال لازم می‌شه که در طول این مسیر، براساس شرایط و موقعیت تسک، اون به نفرات مختلفی در تیم اساین بشه. فقط توجه داشته باشید که هیچوقت نباید بیش از یک نفر به اون اساین شده باشه.
  • مدیریت پروژه در اینجا یک مرحله بالاتر می‌ره و بخش زیادی از آن در خود تیم انجام می‌شه. برای مثال ایجاد بسیاری از تسک‌ها و اساین کردن اون به بقیه نفرات تیم، پیگیری برای انجام و… توسط خود اعضای تیم انجام خواهد شد. یه اصلی که برای خودم همیشه در نظر می‌گیرم: یک مدیر پروژه در یک تیم زیر ۱۰ نفر را در نظر بگیرید. اگر بیش از ۲۰درصد از زمان او صرف مدیریت پروژه می‌شه، قطعا جایی از کار مشکل داره. رقم مناسب عددی بین ۱۰-۱۵٪ هست.
  • چون این موضوع بالا برای خیلی‌ها ممکنه در شروع عجیب و نشدنی به نظر برسه، در ابتدای کار باید نظارت، صحبت و هماهنگی زیادی با نفرات تیمتون داشته باشید تا بتونید این موضوع را جا بندازید. مثلا جایی یکی با عصبانیت به من گفت مگه تو مدیر پروژه نیستی؟ چرا من باید اینکار رو انجام بدم؟ و یا در جایی دیگر: فلانی با چه اجازه‌ای برای من تسک زده؟ چطور خودش رو تونسته در جایگاهی ببینه که برای تسک بزنه؟ و امثالهم.
  • این بخش از کار که مسئولیت انجام هر تسکی که به شما اساین شده با شماست قسمت حیاتی این سیستم هست و این به این معنی هست که: اگر نیاز هست پیگیری‌ای انجام بشه براش پس انجام بدید، اگر کسی یا موضوعی هست که جلوی انجام این کار را می‌گیرد پس مطرح کنید، اگر فکر می‌کنید اشتباه به شما اساین شده موضوع رو انتقال بدید، اگر نیاز هست تسکی برای فرد دیگری ایجاد شود، آن‌را ایجاد کنید و… . جایگاه مدیر پروژه در اینجا رفع موانع و حل مشکلات خواهد بود اما اینکه یک تسک به شما اساین شده باشد، مسئولیتش با شماست پس اگر بنا به هر دلیلی فکر می‌کنید به نتیجه دلخواه و مد نظر نمی‌رسد، آن‌را به مدیر پروژه منتقل کنید.
  • از دیگر مواردی که باید براش زمان بگذارید، آموزش نحوه انتقال یک کار، نوشتن و اساین کردن یک کار به کل تیم هست. ممکنه خیلی جا بخورید وقتی ببینید چقدر آدم‌ها در توضیح و انتقال کار به یکدیگر مشکل دارند و بخصوص در شروع کار همواره باید فرآیند رو با جزییات زیر نظر داشته باشید و در جاهایی که لازم هست نحوه نوشتن صحیح رو منتقل کنید (البته قرار نیست وارد هر جزییاتی بشید، اتفاقا این فضا باید باشه تا نفرات بتوانند متوجه منظور یکدیگر بشوند و از هم این رو درخواست کنند).
  • نکته دیگه مستند کردن هست. یعنی از حرف روی نوشتار و ویدئو بیاورید حتی اگر اولش بسیار دردناک باشه، این لزومی هست که باید انجام شود.
  • تیم را کوچک نگه دارید (در این رابطه بیشتر می‌نویسم) و آن‌ها را در جریان کار یکدیگر قرار دهید (برای این مورد هم در یک مطلب دیگه روش فوق العاده‌ای رو معرفی می‌کنم).
  • بازم اشاره می‌کنم که یک کار مهم یادگیری نحوه تعامل افراد با یکدیگر هست. از اونجایی که ما خیلی در این زمینه‌ها مشکل داریم، عدم تعامل درست بزرگترین خطر نابودی این سیستم هست و ممکنه در کوتاه مدت باعث بشه برگردید به همان روال سابق تا جلوی درگیری‌های رخ داده در تیم رو بگیرید.
  • انتظاراتتون رو همیشه شفاف کنید. هم انتظاراتی که از یک فرد وقتی یک کاری بهش اساین شده (که در بالا بهش اشاره شد) و هم انتظارات از کیفیت انجام کار و فرآیند و مسئولیت‌های هر نفر. تا قبل از این یک نفر در ذهنش انتظارات، مسئولیت‌های افراد تیم رو می‌دونسته و حالا چون بقیه باید بتونن با یکدیگر کار کنند، پس نیاز هست این انتظارات از داخل ذهن روی کاغذ بیاد.

امیدوارم این روش همونطور که تونسته به ما خیلی کمک کنه، برای شما هم خیلی مفید باشه.