تأسیس ۲۰۰۸ · نسخهٔ دیجیتال · 19 ژوئن 2026

SMB IT Journal

منبع فناوری اطلاعات برای کسب‌وکارهای کوچک

فارسی
مسیر شغلی

نقش‌های IT: بهره‌وری و در دسترس بودن

به عنوان مدیران IT با نیاز به تعامل با دو نوع بسیار متفاوت از متخصصان فنی روبرو هستیم. این دو نوع متخصص نه با توجه به نوع شخصیت یا سبک کارشان، بلکه بر اساس ماهیت نقش‌های شغلی‌شان از هم جدا می‌شوند. درک نیازهای منحصربه‌فرد این دو نوع شغلی در مدیریت مؤثر کارکنان فنی حیاتی است، اما بخش‌های IT کمی واقعاً وقت می‌گذارند تا ظرافت‌های ذاتی این دو نقش شغلی متفاوت را درک و قدردانی کنند.

نوع اول، که تا به حال بهترین درک را از آن داریم، «مهندس» می‌نامم. این نقش مهندسی طیف وسیعی از وظایف شغلی را در بر می‌گیرد، از توسعه‌دهندگان نرم‌افزار و طراحان، معماران، مهندسان سیستم، مهندسان شبکه تا هر کسی که وظیفه اصلی‌اش طراحی یا پیاده‌سازی خلاقانه سیستم‌های جدید از هر نوعی است. اصطلاح مهندس گسترده است اما نسبتاً معنادار.

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

بدیهی است که هیچ انسان واقعی در دنیای واقعی احتمالاً هرگز کاملاً فقط در یک دسته نخواهد بود، اما تقریباً تمام وظایف شغلی در IT بسیار زیاد بر یکی یا دیگری تمرکز می‌کند. می‌توان با اطمینان نسبی فرض کرد که تقریباً هر نقشی استثنائاً به یک نقش یا دیگری وزن داده شده است. بسیار نادر است که یک موقعیت واحد به طور مساوی بین این نقش‌ها تقسیم شود.

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

نقش‌های پشتیبانی این مفهوم یکسان را ندارند. البته می‌توانید از یک معیار مصنوعی مانند «تیکت‌های بسته‌شده» برای اندازه‌گیری بهره‌وری در نقش پشتیبانی استفاده کنید، اما این بسیار گمراه‌کننده خواهد بود. یک تیکت می‌تواند بی‌اهمیت و دیگری یک چالش تحقیقاتی بزرگ باشد. در بسیاری از موارد ممکن است برای مدت طولانی هیچ تیکتی موجود نباشد و بعد بسیاری به یکباره برسند که نمی‌توانند به طور همزمان سرویس شوند. بهره‌وری احتمالاً پراکنده و غیرقابل تداوم خواهد بود و در نهایت اصلاً اندازه‌گیری آن معنادار نیست.

موقعیت‌های مهندسی از طریق تولید مؤثر خروجی در یک دوره زمانی نسبتاً طولانی که اغلب حتی تا ماه‌ها و سال‌ها برای پروژه‌های بزرگ ادامه دارد، ارزش خود را ثابت می‌کنند. بنابراین هدف با موقعیت‌های مهندسی ایجاد یک محیطی است که بهره‌وری پایدار را تشویق کند. به خوبی شناخته شده است که مهندسان اغلب با کار در ساعات کوتاه‌تر یا جایگزین، گرفتن تعطیلات منظم و غیره بهره‌وری بیشتری کسب می‌کنند. این نه تنها اغلب بهره‌وری را افزایش می‌دهد بلکه اغلب کیفیت خروجی را نیز بسیار افزایش می‌دهد.

موقعیت‌های پشتیبانی نان خود را با «در دسترس بودن» هنگام نیاز به دست می‌آورند. اگر یک فرد پشتیبانی در تلاش است با حداکثر کارایی کار کند، به طور طبیعی دلالت دارد که یک عقب‌افتادگی مداوم از مشکلات پشتیبانی در انتظار توجه تیم پشتیبانی وجود دارد و افراد زیادی هستند که به پشتیبانی نیاز دارند و باید برای آن صبر کنند تا یک صف تشکیل دهند. با داشتن یک صف همیشه در حال شکل‌گیری، این همچنین به این معناست که پرسنل پشتیبانی به جای حل آیتم‌های زنده به طور مداوم کار را از صف برمی‌دارند - یا آیتم‌های اولویت بالا را نادیده می‌گیرند یا به طور منظم دچار وقفه می‌شوند - که باعث تغییر زمینه مداوم می‌شود که توانایی مدیریت کارآمد صف را به طور قابل توجهی کاهش می‌دهد - که هدف کامل آن از ابتدا ایجاد ظاهر بهره‌وری مصنوعی بود.

نقش‌های پشتیبانی «رویدادمحور» هستند. من این اصطلاح‌بندی را دوست دارم زیرا فکر می‌کنم دقیق‌ترین توصیف از حالتی است که تقریباً تمام متخصصان پشتیبانی در آن کار می‌کنند. چه یک رویداد توسط یک تماس تلفنی، یک پیام فوری، یک ایمیل یا یک تیکت ایجاد شود، یک «رویداد» است که انتقال فرد پشتیبانی از بیکاری به اقدام را شروع می‌کند یا در برخی موارد از یک آیتم اولویت پایین به یک آیتم اولویت بالا. به هر شکلی، یک رویداد نمایانگر یک «تغییر زمینه» برای متخصص پشتیبانی است. بدون یک رویداد هیچ کاری برای یک متخصص پشتیبانی وجود ندارد. حتی اگر «رویداد» با یک صف تیکت یا یک عقب‌افتادگی ایمیل نمایندگی شود، هنوز هم یک شکل از رویداد است.

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

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

مهم‌ترین مفهوم، از تجربیات من، ایجاد یک جریان خوب از وقفه‌های رسیده به تیم پشتیبانی است. اغلب تیم‌های پشتیبانی با تعدادی از کانال‌های مختلف پشتیبانی مانند ایمیل و تلفن کار می‌کنند. محدود کردن و هدایت رویدادها به کانال‌های مناسب حیاتی است.

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

به آخرین باری فکر کنید که در یک پیتزافروشی بودید و سفارش خود را در پیشخوان می‌دادید. صبورانه در صف منتظر ایستادید تا هر نفر سرویس شد. کار درست را انجام دادید. به جلوی صف رسیدید. شروع به سفارش دادن کردید که تلفن زنگ زد. فردی که سفارش شما را می‌گرفت شما را «منتظر» گذاشت حتی در حالی که همانجا ایستاده بودید، تلفن را برداشت، سفارش را گرفت، تلفن را گذاشت و به شما برگشت. آنچه این می‌گوید این است که فرد تماس‌گیرنده که «چرخ جیرجیرکننده» است، برای رستوران مهم‌تر از افرادی است که واقعاً در رستوران هستند. همین اثر در بسیاری از میزهای پشتیبانی اتفاق می‌افتد - کار در حال انجام توسط تماس‌هایی که به یک خط گروهی یا مستقیماً به فرد پشتیبانی می‌رود قطع می‌شود. این در بهترین حالت ناکارآمد است و در بدترین حالت ممکن است فرایندهای پشتیبانی حیاتی برای مشکلات بسیار بحرانی را مختل کند.

پس هنگام فکر کردن درباره نحوه مدیریت متخصصان IT، به هدف نقش‌شان فکر کنید. هدف یک مهندس بهره‌وری است. هدف یک متخصص پشتیبانی در دسترس بودن است.

برچسب‌خوردهadministration administrator engineer operations roles

آگهی

SMB IT Journal — the IT resource for small business