نقش‌های اصلی یک تیم توسعه نرم‌افزار چیست؟ (PM, PO, Designer, UX, Frontend, Backend, QA, Architect, DevOps)

تیم توسعه نرم‌افزار فقط «چند برنامه‌نویس» نیست. از کشف مسئله و طراحی تجربه تا ساخت کلاینت و سرور، تضمین کیفیت، تصمیم ساختاری و مسیر تحویل به Production، مسئولیت‌های متفاوتی وجود دارد که اگر روی یک نفر بدون توافق تلنبار شود یا بین چند نفر بدون مالک بماند، هزینهٔ تجاری پیدا می‌کند: تأخیر، دوباره‌کاری، و محصولی که کاربر نمی‌فهمد یا سیستم نمی‌کشد.

این صفحه نقشهٔ نقش‌های رایجی است که در عنوان آمده — به‌اضافهٔ اشاره به Scrum Master چون در تیم‌های Scrum حیاتی است. هدف اعلام «بهترین ترکیب» نیست؛ هدف این است که بدانید هر نقش چه خلأ تجاری را پر می‌کند تا در تیم کوچک ترکیب آگاهانه، و در تیم بزرگ‌تر مرز شفاف بسازید. جزئیات عمیق‌تر هر نقش در مقالات ۰۵۱ تا ۰۵۶ آمده است.

Scrum Guide داخل Scrum Team فقط سه accountability می‌نامد: Product Owner، Scrum Master و Developers. بقیهٔ عنوان‌ها (PM، Designer، QA، Architect، DevOps و تفکیک Frontend/Backend) عرف سازمانی و تخصصی بازار کارند که روی همان کار ساخت محصول سوار می‌شوند.

پاسخ کوتاه

نقش‌های اصلی معمولاً زنجیرهٔ ارزش را این‌طور پوشش می‌دهند: Product Manager جهت و ارزش کسب‌وکار را روشن می‌کند؛ Product Owner (در Scrum) Backlog و ارزش Increment را پاسخگوست؛ Designer/UX تجربه و رابط را شکل می‌دهند؛ Frontend و Backend می‌سازند؛ QA کیفیت را نظام‌مند می‌کند؛ Architect تصمیم ساختاری می‌گیرد؛ DevOps مسیر تحویل و پایداری عملیات را می‌سازد. در تیم کوچک چند کلاه روی یک سر می‌رود؛ در تیم حرفه‌ای‌تر جدایی وقتی معنا دارد که بار و ریسک از ظرفیت ترکیب خارج شده باشد.

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

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

جدول نقشهٔ نقش‌ها

لایهٔ محصول و تصمیم

Product Manager

کشف مسئله، اولویت ارزش، roadmap و هم‌راستایی فروش/پشتیبانی. جزئیات در ۰۵۱. از نظر تجاری اگر کسی «نه»ی معتبر نگوید، مهندسی گران‌ترین درخواست را می‌سازد نه درست‌ترین را.

Product Owner

طبق Scrum Guide پاسخگوی حداکثر ارزش محصول و مدیریت مؤثر Backlog است؛ یک نفر نه کمیته. Agile Alliance هم بر شفافیت backlog و تصمیم اولویت تأکید دارد. تفاوت با PM در ۰۵۲.

Scrum Master (مکمل عنوان شما)

پاسخگوی اثربخشی تیم و برقراری Scrum؛ رفع مانع و کوچینگ. در جدول عنوان اصلی شما نبود، اما اگر Scrum می‌کنید خلأ آن را با «مدیر پروژهٔ دستوری» پر نکنید. مقالهٔ ۰۵۳.

لایهٔ تجربه

Designer (اغلب UI) و UX

UX روی فهم کاربر، جریان و可用性 تمرکز دارد؛ UI روی نمود بصری و اجزای رابط. گاهی یک نفر هر دو را پوشش می‌دهد. بدون این لایه، Frontend مجبور به حدس طراحی می‌شود و نتیجه ناسازگار و پرهزینه است. مقالات ۰۸۷–۰۹۰ عمیق‌ترند.

ارزش تجاری: کاهش آموزش کاربر، کاهش تیکت پشتیبانی، افزایش تکمیل جریان‌های پول‌ساز. خلأ: «ما مهندس داریم خودش قشنگ می‌کند» — معمولاً یعنی بدهی تجربه.

لایهٔ ساخت

Frontend و Backend

MDN Front-end را حول HTML/CSS/JS، دسترسی و ابزار می‌چیند؛ server-side را مسئول انتخاب و ارسال اطلاعات درست و امن. تفاوت کامل در ۰۵۵. تجاری: FE روی تبدیل و اعتماد دیداری؛ BE روی صحت معامله و داده.

QA

مسئول نظام کیفیت: آزمون دستی اکتشافی، خودکارسازی تست‌های حیاتی، ریسک‌بر اساس اولویت، و کمک به Definition of Done واقعی. QA پلیس بعد از فاجعه نیست؛ شریک پیشگیری است. در Scrum، Developers به کیفیت و Done پایبندند؛ QA سازمانی این توانایی را تقویت می‌کند نه جایگزین مالکیت کیفیت تیم.

ارزش تجاری: هزینهٔ باگ در Production معمولاً چند برابر هزینهٔ یافتن زود هنگام است — به‌ویژه در پرداخت، هویت و دادهٔ حساس.

لایهٔ ساختار و تحویل

Software Architect

تصمیم‌های ساختاری و ویژگی‌های کیفی؛ جزئیات ۰۵۴. تجاری: سرعت افزودن قابلیت‌های هم‌راستا در آینده.

DevOps Engineer

Google Cloud DevOps را حرکت سرعت+اطمینان+مالکیت مشترک می‌داند؛ نقش مهندس روی لولهٔ تحویل و Production تمرکز دارد. جزئیات ۰۵۶. تجاری: انتشار به‌عنوان قابلیت رقابتی نه آیین ترس.

الگوهای تیم بر اساس اندازه — بدون نسخهٔ مطلق

۱) دو تا چهار نفر: بنیان‌گذار/PM سبک + یک Full-stack یا FE+BE؛ کلاه UX و Ops پاره‌وقت. تمرکز روی یک جریان عمودی.

۲) پنج تا ده نفر: جدا کردن مالک محصول (PM/PO)، حداقل تفکیک FE/BE، کسی برای کیفیت، و سهم مشخص برای استقرار. Architect ممکن است Tech Lead باشد.

۳) چندتیمی: PO per team یا مدل واضح اولویت، Architect و DevOps به‌عنوان توانمندی مشترک، UX پژوهش در لایهٔ محصول. بدون هماهنگی Product Goal مشترک (طبق راهنمای Scrum برای چند تیم)، دوباره‌کاری افقی زیاد می‌شود.

چگونه خلأ نقش را تشخیص دهید؟

• باگ‌های تکراری بعد از انتشار → کیفیت/تست/Done ضعیف
• کاربر نمی‌فهمد چه کار کند → UX/UI یا UX Writing
• هر هفته اولویت عوض می‌شود بدون دلیل بازار → PM/PO
• فقط یک نفر می‌تواند Deploy کند → DevOps/مستندسازی مسیر
• هر ویژگی جدید سیستم را می‌لرزاند → معماری/مرزها
• فروش قول می‌دهد مهندسی غافلگیر می‌شود → هم‌راستایی محصول

اشتباه‌های رایج در چیدن تیم

• استخدام بر اساس مد عنوان بدون تعریف مسئولیت.
• پر کردن همهٔ عنوان‌ها روی کاغذ و خالی گذاشتن اختیار تصمیم.
• حذف QA برای سرعت و پرداخت هزینه در Production.
• یکی دانستن Designer با Frontend.
• انتظار معجزه از یک DevOps بدون تغییر فرهنگ مالکیت.

مالکیت مسئولیت در برابر عنوان روی کاغذ

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

در تیم‌های ایرانی و بین‌المللی هر دو دیده می‌شود که عنوان انگلیسی استخدام می‌شود ولی کار واقعی همان «همه‌کاره» است. صادق بودن دربارهٔ چندکلاهه بودن بهتر از تظاهر به تخصص کامل است — هم برای حقوق انتظارات، هم برای برنامه‌ریزی ظرفیت.

پیشنهاد عملی: یک جدول کانبان نقش/مسئولیت روی دیوار یا سند یک‌صفحه‌ای؛ هر فصل بازبینی. وقتی فرد جدید می‌آید، اول این صفحه را می‌خواند نه ده اسلاید استراتژی.

نقش کیفیت (QA) را جدی‌تر از «تست آخر» ببینید

QA در عنوان شما هست چون خلأ آن گران است. کیفیت از نوشتن تست واحد توسط Developer شروع می‌شود و با آزمون پذیرش، اکتشاف، و دادهٔ Production ادامه می‌یابد. QA متخصص کمک می‌کند ریسک را بر اساس اثر اولویت‌بندی کند: نه اینکه همه چیز را یکسان تست کند و هیچ‌چیز را عمیق.

در تیم بدون QA اختصاصی، حداقل یک نفر باید مالک چک‌لیست انتشار و مسیرهای دود باشد. حذف کامل این مالکیت به نام Agile، Agile نیست — قمار است. Definition of Done بدون معیار قابل‌آزمون فقط شعار است؛ Scrum Guide روی Done به‌عنوان تعهد Increment تأکید دارد.

همکاری QA با UX روی جریان‌های گیج‌کننده، و با DevOps روی دادهٔ تست و محیط پایدار، کیفیت را از کار انفرادی پایان‌اسپرینت خارج می‌کند.

طراح و UX در کنار PM — مثلث کشف

PM بدون شواهد فقط اولویت سیاسی می‌دهد؛ UX بدون اولویت تجاری ممکن است تجربهٔ زیبا برای مسئلهٔ کم‌اثر بسازد؛ Designer بدون پژوهش ممکن است پوسته‌ای بسازد که جریان را درست نمی‌کند. مثلث سالم: مسئله را با هم قاب می‌کنند، آزمایش کوچک می‌کنند، بعد به ساخت می‌سپارند.

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

جونیور Frontend که به UX نزدیک می‌شود ارزش دوبرابر می‌آورد اگر یاد بگیرد قبل از کد، جریان را روی کاغذ بیازماید. این به‌معنی حذف نقش UX نیست؛ به‌معنی زبان مشترک است.

اولویت استخدام وقتی بودجه فقط یک نفر است

اگر محصول در مرحلهٔ کشف بازار است و ساخت هنوز سبک، توان محصول+UX سبک ممکن است جلوتر از تخصص Ops باشد. اگر هر هفته در آتش استقرار هستید، یک مهندس با مهارت تحویل ممکن است فوری‌تر از طراح سوم باشد. معیار: کدام ریسک الان رشد یا بقا را تهدید می‌کند؟

1. ریسک بازار/مسئله → PM/UX
2. ریسک تجربه و تبدیل → UX/UI + Frontend
3. ریسک داده/منطق → Backend (+Architect سبک)
4. ریسک کیفیت بحرانی → QA یا خودکارسازی تست
5. ریسک انتشار/پایداری → DevOps

مقالهٔ ۰۵۸ همین دوگانگی «یک نفر همه کاره‌ها» را باز می‌کند. این صفحه فقط نقشه است؛ آن صفحه محدودیت انسان را یادآوری می‌کند.

زبان مشترک برای جلسهٔ kickoff پروژه

در شروع پروژه این سوال‌ها را روی میز بگذارید و جواب را با نام فرد بنویسید:

• چه کسی اولویت backlog را نهایی می‌کند؟
• چه کسی تجربهٔ کاربر را قبل از ساخت سنگین تأیید می‌کند؟
• چه کسی Done کیفیت را برای انتشار تعریف می‌کند؟
• چه کسی استقرار Production و Rollback را بلد است؟
• چه کسی روی مرزهای سیستم و ریسک ساختاری حساس است؟

اگر جواب «همه» یا «نمی‌دانیم» است، قبل از تعهد تاریخ انتشار سخت، خلأ را پر کنید — با استخدام، آموزش، یا کاهش آگاهانهٔ scope.

جمع نقش‌ها با مقالات این خوشه

۰۵۱ PM، ۰۵۲ تفاوت PO/PM، ۰۵۳ Scrum Master، ۰۵۴ Architect، ۰۵۵ FE/BE، ۰۵۶ DevOps، و این صفحه ۰۵۷ نقشهٔ کل. ۰۵۸ محدودیت یک‌نفره را می‌پرسد. خواندن پشت‌سرهم به مالک کمک می‌کند بودجه را روی درد واقعی بگذارد نه روی مد عنوان.

Scrum Guide و منابع MDN/Google Cloud در این خوشه لنگر تعریف‌اند؛ عرف عنوان شغلی را با accountability رسمی قاطی نکنید. محصول پایدار از وضوح مسئولیت می‌آید.

جمع‌بندی برای تصمیم

نقش‌های تیم نرم‌افزار زنجیرهٔ کشف تا تحویل پایدار را پوشش می‌دهند. Scrum سه accountability رسمی دارد؛ بقیه تخصص‌های ضروری بازار و سازمان‌اند. جدول این صفحه را به‌عنوان چک‌لیست خلأ استفاده کنید: برای هر خطر تجاری یک مالک نام ببرید. جزئیات هر نقش در ۰۵۱–۰۵۶ و پرسش ترکیب یک‌نفره در ۰۵۸ است.

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

منابع و مراجع

• The 2020 Scrum Guide — Scrum Team accountabilities — https://scrumguides.org/scrum-guide.html
• Agile Alliance Glossary — Product Owner — https://www.agilealliance.org/glossary/product-owner/
• MDN — Front-end web developer — https://developer.mozilla.org/en-US/docs/Learn/Front-end_web_developer
• MDN — Introduction to the server side — https://developer.mozilla.org/en-US/docs/Learn/Server-side/First_steps/Introduction
• Google Cloud — DevOps — https://cloud.google.com/devops

این نقشه برای تصمیم نقش است؛ برای اجرای Scrum و مسیر فنی مقالات تخصصی همان سری را دنبال کنید.