چه کسانی یک محصول نرم‌افزاری را می‌سازند؟ از Product Manager و Architect تا Developer و DevOps

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

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

این راهنما نقش‌های رایج را جدا می‌کند تا بفهمید هر کدام چه مسئله‌ای را حل می‌کنند، مرزشان کجاست، و در چه اندازه‌ای اصلاً به نقش جدا نیاز دارید. هدف استخدام یک ارتش نیست. هدف این است که تصمیم بی‌صاحب نماند.

پاسخ کوتاه

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

بنیان‌گذار (Founder) چرایی کسب‌وکار را مالک است. مدیر محصول (Product Manager) تصمیم می‌گیرد چه ارزشی، برای چه کسی، با چه اولویتی ساخته شود. مالک محصول (Product Owner) در چارچوب اسکرام (Scrum) بک‌لاگ را شفاف و مرتب نگه می‌دارد. مدیر پروژه (Project Manager) زمان، وابستگی و تحویل را می‌بیند. اسکرام مستر (Scrum Master) فرآیند را سالم نگه می‌دارد؛ کار افراد را مدیریت نمی‌کند.

طراحی تجربه و رابط، معماری، توسعه، کیفیت، عملیات، امنیت و داده بقیهٔ زنجیره را می‌سازند. جزئیات هر نقش و مرز آن در ادامه است.

نقش یعنی مالکیت یک کلاس تصمیم؛ نه صندلی خالی روی چارت سازمانی.

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

سایت ساده در برابر محصول دیجیتال جدی

سایت شرکتی، صفحهٔ خدمات، یا فروشگاه کوچک روی سیستم مدیریت محتوا (CMS) مثل WordPress اغلب مسیر مشخصی دارد: محتوا، تماس، شاید پرداخت ساده. ریسک شکست محدود است. تغییر عمده کم است. یک فرد باتجربه می‌تواند طراحی، پیاده‌سازی و انتشار را جلو ببرد.

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

اشتباه دو طرفه است. بودجهٔ محصول جدی را مثل سایت پنج‌صفحه دیدن، کیفیت را می‌شکند. برای همان سایت پنج‌صفحه معمار تمام‌وقت، Scrum Master و تیم امنیت جدا خریدن، اسراف است. اندازهٔ تیم باید با اندازهٔ مسئله و ریسک جور باشد.

مالکیت مسئله: Founder، Product Manager و Product Owner

Founder

Founder مالک چرایی کسب‌وکار است: بازار، مدل درآمد، محدودیت نقدینگی، و خط قرمز قانونی یا اعتباری. در تیم خیلی کوچک، Founder عملاً Product Manager هم هست: اولویت را می‌گوید، مشتری را می‌شناسد، و «نه» گفتن را بر عهده می‌گیرد.

مرز مهم این است که سلیقهٔ شخصی جایگزین شواهد کاربر نشود. تصمیم نهایی بودجه با Founder است؛ جزئیات هر دکمه نه. اگر همان نفر هم اولویت را تعیین کند، هم کد بزند، هم سرور را نگه دارد، باید بداند کجا خستگی به تصمیم بد تبدیل می‌شود.

Product Manager

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

PM فنی‌ترین فرد تیم نیست و نباید به‌جای معمار تکنولوژی انتخاب کند. مدیر افراد هم نیست. سوءتفاهم رایج یکی دانستن Product Manager و Project Manager است: اولی «چرا و چه» را مالک است، دومی «کی و با چه وابستگی» را.

Product Owner

در راهنمای اسکرام ۲۰۲۰، Product Owner یکی از سه پاسخگویی تیم اسکرام است؛ در کنار Scrum Master و Developers. کارش شفاف کردن هدف محصول، مدیریت بک‌لاگ محصول، و اطمینان از این است که کارِ در صف برای تیم فهمیدنی و مرتب باشد. PO می‌تواند همان PM باشد؛ در سازمان بزرگ‌تر گاهی جدا می‌شود.

PO مدیر پروژه نیست و افراد را وظیفه‌محول نمی‌کند. اگر اولویت را Founder هر روز عوض کند و این نقش اختیاری روی ترتیب کار نداشته باشد، عنوان روی کارت ویزیت چیزی را عوض نمی‌کند.

هماهنگی کار: Project Manager، Scrum Master و Business Analyst

Project Manager

Project Manager تحویل را در زمان و وابستگی واقعی نگه می‌دارد: چه چیزی به چه چیزی بند است، کجا ریسک تأخیر است، و چه چیزی باید بیرون تیم هماهنگ شود — قرارداد، تأمین‌کننده، محتوا، مجوز.

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

Scrum Master

Scrum Master مربی فرآیند است: کمک می‌کند تیم اسکرام را بفهمد، مانع‌ها دیده شوند، و رویدادها به گزارش‌دهی نمایشی تبدیل نشوند. طبق راهنمای اسکرام، این نقش مدیریت افراد یا بستن اسپرینت با فشار نیست.

سوءتفاهم رایج این است که Scrum Master همان «منشی جلسات چابک» یا Project Manager با نام جدید است. اگر قدرت نه گفتن به اضافه‌بار نباشد و فقط استیکر روی بورد باشد، فرآیند نمایشی است نه چابک.

Business Analyst

تحلیل‌گر کسب‌وکار (Business Analyst) نیاز را از زبان عملیات و ذی‌نفع به زبان قابل‌ساخت برمی‌گرداند: قاعده، استثنا، دادهٔ لازم، و معیار پذیرش. در دامنه‌های پیچیده — بیمه، مالی، لجستیک — این نقش جلوی جملهٔ «فکر می‌کردیم بدیهی است» را می‌گیرد.

در محصول کوچک، PM یا PO همین کار را می‌کند. BA جدا وقتی لازم است که قواعد کسب‌وکار از حافظهٔ یک نفر خارج شده باشد. BA اولویت استراتژیک را از PM نمی‌گیرد و معماری را از Architect نمی‌دزدد.

تجربه کاربر: UX Designer و UI Designer

UX Designer

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

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

UI Designer

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

یکی دانستن UI و UX رایج‌ترین اشتباه است. می‌توان رابطی زیبا ساخت که مسیر خرید را خراب کند. توسعه‌دهنده فرانت‌اند UI را پیاده می‌کند؛ جایگزین طراح نیست، مگر همان فرد هر دو مهارت را واقعاً داشته باشد.

ساخت سیستم: Software Architect و Developerها

Software Architect

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

معمار تمام‌وقت برای هر پروژه لازم نیست. در تیم کوچک، یک Tech Lead یا Senior Developer همین کلاه را می‌گذارد — به شرط آن‌که فرصت فکر کردن داشته باشد، نه فقط بستن تیکت. معمار نباید در سند زندانی شود و از کد و عملیات جدا بماند.

Frontend Developer

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

فرانت‌اند زیباسازی نیست. تصمیم‌های این لایه روی تبدیل، اعتماد و هزینهٔ پشتیبانی اثر دارد. مرز با بک‌اند قرارداد API است؛ مرز با طراحی، نظام کامپوننت و حالت‌های خطا.

Backend Developer

توسعه‌دهنده بک‌اند منطق پشت صحنه را می‌سازد: هویت، مجوز، موجودی، پرداخت، قواعد و دوام داده. کاربر این لایه را نمی‌بیند؛ نتیجهٔ خرابش را می‌بیند.

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

Mobile Developer

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

هر محصولی اپ نمی‌خواهد. اگر کار اصلی روی وب موبایل خوب انجام می‌شود، اپ جدا هزینهٔ تیم و فروشگاه را اضافه می‌کند. موبایل‌کار جایگزین فرانت وب نیست؛ کانال و محدودیت متفاوت است.

پایداری: QA، DevOps، Security و Data/BI

QA

تضمین کیفیت فقط «کلیک آخر قبل از انتشار» نیست. QA می‌پرسد چه چیزی باید درست بماند، در چه شرایطی ممکن است بشکند، و چطور این ادعا تکرارپذیر است. تست اکتشافی، سناریوهای پول‌ساز، و گاهی خودکارسازی در این نقش است.

کیفیت را نمی‌شود به انتهای صف پرتاب کرد. اگر Developer هیچ آزمونی ننویسد و QA فقط بعد از اتمام کار وارد شود، باگ گران می‌شود. در تیم کوچک، Developer با چک‌لیست و تست مسیر اصلی همان نقش را پوشش می‌دهد.

DevOps

DevOps عنوان جادویی استخدام نیست؛ مجموعه‌ای از کارهاست: ساخت تکرارپذیر، انتشار، محیط‌ها، مشاهده‌پذیری، پشتیبان و بازیابی. هدف این است که «روی لپ‌تاپ من کار می‌کرد» به تولید قابل‌اعتماد برسد.

در محصول کوچک، همان Backend می‌تواند استقرار ساده را مالک شود. نقش جدا وقتی معنا دارد که چند محیط، چند سرویس، یا هزینهٔ قطعی بالا باشد. خریدن ابزار CI/CD بدون مسئولیت انتشار، DevOps نمی‌سازد.

Security

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

سازمان کوچک لزوماً Security Engineer تمام‌وقت ندارد. اما باید کسی مالک چک‌لیست حداقلی باشد: هویت، مجوز، رمزنگاری مسیر، و پشتیبان. سپردن امنیت به «بعداً ممیزی می‌کنیم» در محصولی با دادهٔ مشتری، ریسک باز است.

Data / BI

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

برای سایت ساده لازم نیست. اگر هر واحد فایل اکسل خودش را حقیقت می‌داند، مسئلهٔ داده دارید — حتی اگر عنوان BI روی چارت نباشد. Data جایگزین Product Manager نیست؛ شواهد را برای تصمیم او قابل‌اتکا می‌کند.

کدام نقش در چه اندازه پروژه؟

جدول زیر استخدام اجباری نیست؛ پوشش مسئولیت است. خانهٔ خالی یعنی «این کلاه را کسی باید داشته باشد»، نه «یک نفر با همین عنوان بخرید».

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

همکاری؛ کار کجا بین نقش‌ها می‌شکند؟

شکست رایج از کمبود استعداد نیست؛ از شکاف مالکیت است. اولویت بی‌خبر عوض می‌شود، صفحه بدون API می‌آید، قرارداد بک‌اند را فرانت ندیده، QA آخر هفته وارد می‌شود و انتشار بی‌صاحب می‌ماند.

1. مسئله و معیار موفقیت را قبل از تخمین فنی یکی کنید.
2. قرارداد بین فرانت و بک‌اند را زود بنویسید، نه بعد از اتمام هر دو.
3. مسیرهای پول‌ساز را با QA و عملیات از روز اول مشخص کنید.
4. انتشار و بازگشت را قبل از «تمام شد» تمرین کنید.

در تیم کوچک همین ترتیب با دو یا سه نفر ممکن است. مهم این است که مرحله حذف نشود، نه این‌که برای هر مرحله یک واحد سازمانی بسازید. چندنقشه بودن ضعف نیست؛ مبهم بودن مالکیت ضعف است.

سوءتفاهم‌های رایج

• Product Manager همان Project Manager است.
• Scrum Master مدیر تیم است و باید تاریخ تحویل را ضمانت کند.
• UX یعنی رنگ و فونت.
• فول‌استک یعنی یک نفر جایگزین کل تیم محصول پیچیده است.
• معمار فقط نمودار می‌کشد و کد نمی‌بیند.
• QA مسئول کیفیت است؛ پس Developer تست نمی‌نویسد.
• DevOps یعنی کسی که سرور را «آپ نگه می‌دارد».
• امنیت کار انتهای پروژه است.
• هر محصول جدی باید از روز اول همهٔ این نقش‌ها را جدا داشته باشد.

جمع‌بندی

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

قبل از استخدام، بپرسید کدام کلاس تصمیم امروز بی‌صاحب است. همان را پر کنید. صندلی خالی روی چارت، محصول را بهتر نمی‌کند.

ابزار را بعد از روشن شدن نقش‌ها و محدودیت واقعی انتخاب کنید، نه قبل از آن.

پرسش‌های متداول

آیا هر پروژه به معمار و Scrum Master جدا نیاز دارد؟

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

یک نفر می‌تواند هم Product Manager باشد هم Developer؟

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

تفاوت Product Owner و Product Manager چیست؟

PM معمولاً گسترده‌تر به بازار، استراتژی و معیار محصول نگاه می‌کند. PO در اسکرام روی بک‌لاگ و فهم کارِ پیشِ تیم تمرکز دارد. در تیم کوچک اغلب یک نفر هر دو را می‌کند. همهٔ شرکت‌ها اسکرام ندارند؛ عنوان را با کار واقعی بسنجید.

از چه زمانی QA و DevOps را جدا کنیم؟

وقتی هزینهٔ باگ تولیدی یا انتشار دستی از هزینهٔ یک نقش مشخص بیشتر شده، یا وقتی یک نفر دیگر نمی‌تواند هم بسازد هم پایدار نگه دارد. قبل از آن، مالکیت تست و انتشار را روی Developerها صریح کنید.

منابع و مراجع

• Ken Schwaber و Jeff Sutherland — The 2020 Scrum Guide: https://scrumguides.org/scrum-guide.html