توی پروژه های اودو، یکی از پرتکرارترین اشتباه ها اینه که نقش ها با هم قاطی میشن.
همه میگن BA و SA و PO؛ ولی وقتی پروژه جلو میره، معلوم نیست چه کسی باید مسئله رو از دل کسب و کار دربیاره، چه کسی باید اون رو به زبان سیستم ترجمه کنه و چه کسی باید اولویت انجام کارها رو مشخص کنه.
همین ابهام ساده، خیلی وقت ها از خود باگ و کمبود توسعه دهنده هم خطرناک تره، چون خروجی اش میشه نیازمندی مبهم، بک لاگ شلوغ، سفارشی سازی اضافه و دوباره کاری.
تحلیل گر کسب و کار (Business Analyst - BA)
تحلیل گر کسب و کار روی “چرا” و “چه چیزی” تمرکز داره.
یعنی باید بفهمه اصل مسئله کسب و کار چیه و دقیقا چه نیازی باید حل بشه.
توی اودو این یعنی قبل از هر حرف فنی، باید روشن بشه درد واقعی کجاست.
مثلا اگه مدیر فروش بگه “فروش آنلاین ما باید بیشتر بشه”، این هنوز نیازمندی نیست.
تحلیل گر کسب و کار باید بازش کنه:
- آیا مشکل از کم بودن تبدیل لید (
Lead) به فرصت فروشه؟ - آیا پیش فاکتور (
Quotation) دیر برای مشتری میره؟ - آیا کاربرها در مرحله پرداخت ریزش می کنن؟
- آیا گزارش های فروش برای تصمیم گیری کافی نیستن؟
یعنی BA قرار نیست سریع بگه “یک قابلیت جدید بسازیم”. اول باید مطمئن بشه داریم مسئله درست رو حل می کنیم.
مالک محصول (Product Owner - PO)
مالک محصول نماینده کسب و کاره و روی “ارزش” و “اولویت” تمرکز داره.
یعنی از بین همه درخواست ها، تغییرات، باگ ها و کارهای فنی، تصمیم می گیره الان کدوم مورد باید زودتر انجام بشه تا بیشترین ارزش رو برای کسب و کار ایجاد کنه.
یه نکته مهم اینه که مالک محصول لزوما خودش همه آیتم های بک لاگ (Backlog) رو جمع نمی کنه.
ورودی بک لاگ میتونه از تحلیل گر کسب و کار، تحلیل گر سیستم، تیم فنی یا مدیرها هم بیاد.
ولی تصمیم نهایی درباره اولویت با PO هست.
به زبان ساده، همه می تونن چیزی پیشنهاد بدن، ولی این PO هست که میگه الان چه چیزی ارزش اجرا داره.
تحلیل گر سیستم (System Analyst - SA)
تحلیل گر سیستم روی “چگونه” تمرکز داره.
وقتی مسئله و نیاز توسط BA روشن شد و PO اونو به نیازهای کوچیک تر شکستش و اولویت بندیشون کرد، SA وارد میشه و اون رو به راه حل قابل اجرا توی اودو تبدیل می کنه.
یعنی بررسی می کنه:
- این نیاز با پیکربندی (
Configuration) حل میشه یا سفارشی سازی (Customization) لازم داره؟ - کدوم ماژول ها درگیر میشن؟ مثلا فروش (
Sales)، حسابداری (Accounting)، وبسایت (Website) یا انبار (Inventory) - چه فیلدها، مدل داده (
Data Model)، قوانین دسترسی (Access Rights) یا جریان کاری (Workflow) باید تغییر کنن؟ - آیا
API یا یکپارچه سازی (Integration) با سرویس بیرونی لازم داریم؟ - این تغییر روی ماژول های وابسته، گزارش ها، امنیت و بقیه چه اثری میذاره؟
اینجا یه Best Practice خیلی مهم توی اودو هست:
اول باید راه حل استاندارد اودو بررسی بشه، بعد اگه واقعا لازم بود بریم سمت توسعه.
خیلی از پروژه ها از همینجا ضربه می خورن، چون تیم زود میره سمت کدنویسی، در حالی که مسئله با تنظیم درست هم حل می شده.
یه نکته مهم بگم: اهمیت ترتیب BA ← PO ← SA در این هست که جلوی اتلاف منابع رو میگیره؛ چون تا زمانی که BA مسئله درست رو کشف نکنه، هر اولویتبندی توسط PO عملاً تیری در تاریکیه، و تا زمانی که PO بر اساس ارزش کسب و کار تایید نکنه که کدوم نیاز اولویت داره، ورود SA به جزئیات فنی و چگونگیِ اجرا، چیزی جز هزینه فنی (Technical Debt) نیست. این زنجیره تضمین می کنه که تیم فنیِ اودو، فقط روی راه حل های درست و ارزشمند وقت می ذاره.
پس مدیر پروژه (Project Manager) و مدیر محصول (Product Manager) کجای کارن؟
اینجا معمولا ذهن خیلی ها گیر می کنه، چون توی پروژه های واقعی، مخصوصا پروژه های اودو، نقش ها همیشه مثل کتاب از هم جدا نیستن و خیلی وقت ها با هم ادغام می شن.
مدیر پروژه (Project Manager) بیشتر حواسش به اینه که پروژه از کنترل خارج نشه؛ از زمان بندی و بودجه گرفته تا منابع، ریسک ها و هماهنگی بین تیم ها.
یعنی مراقبه کارها روی هوا نمونن و تحویل ها بی دلیل عقب نیفتن.
مدیر محصول (Product Manager) هم معمولا یک لایه بالاتر از PO فکر می کنه.
بیشتر درگیر تصویر بزرگ تره: استراتژی محصول (Product Strategy)، مسیر رشد، جایگاه محصول تو بازار و این که در نهایت قراره این محصول به کجا برسه.
اما نکته مهم اینجاست که توی خیلی از تیم ها، این نقش ها جدا و خالص نیستن.
مثلا ممکنه یک نفر همزمان هم Product Manager باشه و هم Product Owner.
یا تو خیلی از پروژه های ERP، تحلیل گر کسب و کار (Business Analyst) و تحلیل گر سیستم (System Analyst) عملا یک نفر باشن.
گاهی هم مدیر پروژه بخشی از هماهنگی های مربوط به بک لاگ (Backlog) یا ارتباط با ذی نفع ها رو جلو می بره.
این ادغام شدن نقش ها به خودی خود مشکل نیست.
دردسر از جایی شروع می شه که مرز مسئولیت ها قاطی بشه.
یعنی دیگه معلوم نباشه چه کسی باید مسئله رو از دل کسب و کار دربیاره، چه کسی باید اون رو به راه حل سیستمی تبدیل کنه و چه کسی باید درباره اولویت تصمیم بگیره.
برای همین، حتی اگر چند نقش روی دوش یک نفر باشه، باز هم بهتره مرز ذهنی این نقش ها روشن بمونه.
یعنی بدونیم الان با کلاه BA داریم مسئله رو می فهمیم، با کلاه SA داریم راه حل اودو رو طراحی می کنیم، یا با کلاه PO و PM داریم درباره اولویت و زمان بندی تصمیم می گیریم.
یک مثال واقعی تر توی اودو
فرض کن مدیرعامل میگه:
“رقبا پرداخت با ارز دیجیتال دارن، ما هم باید این رو به سایتمون اضافه کنیم.”
نگاه تحلیل گر کسب و کار
اینجا BA نباید مستقیم بره سراغ راه حل.
اول باید بپرسه:
- آیا مشتری های ما واقعا این روش پرداخت رو می خوان؟
- این قابلیت واقعا فروش رو زیاد می کنه یا فقط از روی رقبا داریم تصمیم می گیریم؟
- این نیاز مربوط به همه مشتری هاست یا فقط یه بخش خاص؟
- از نظر فرایند مالی و عملیاتی، این کار برای شرکت قابل استفاده هست یا نه؟
خروجی BA باید یه نیاز شفاف باشه، نه یک دستور مبهم.
نگاه تحلیل گر سیستم
وقتی نیاز تایید شد، SA باید بره سراغ طراحی راه حل.
مثلا بررسی کنه:
- باید به کدام ارائه دهنده پرداخت (
Payment Provider) وصل بشیم؟ - اودو ماژول یا کانکتور (
Connector) آماده براش داره یا توسعه لازم داریم؟ - وضعیت های تراکنش چطور باید ذخیره بشن؟
- آیا لازمه فیلدی مثل شناسه تراکنش (
Transaction ID) یاTXID به سیستم اضافه بشه؟ - این پرداخت روی سفارش فروش (
Sales Order)، فاکتور (Invoice)، پرداخت (Payment) و تطبیق حساب (Reconciliation) چه اثری میذاره؟ - اگه پرداخت ناموفق یا معلق شد، رفتار سیستم باید چی باشه؟
این دقیقا همان مرز مهم BA و SA است.
BA میگه “آیا این قابلیت واقعا لازمه و چه چیزی باید حل بشه؟”
SA میگه “اگه لازمه، چطور درست و قابل نگهداری پیاده اش کنیم؟”
چند نکته که تو عمل خیلی زیاد اشتباه میشن
اول: درخواست خام، نیازمندی نیست.
جمله ای مثل “یک گزارش جدید می خواهیم” یا “برای این بخش یک ماژول بزنید” هنوز برای تیم فنی کافی نیست.
دوم: توی اودو اول پیکربندی، بعد سفارشی سازی.
این یکی از مهم ترین Best Practiceهاست.
سفارشی سازی بی دلیل، بعدا موقع ارتقا (Upgrade) و نگهداری هزینه درست می کنه.
سوم: بک لاگ فقط لیست خواسته ها نیست.
آیتم بک لاگ باید روشن، قابل فهم و قابل اجرا باشه.
چهارم: تحلیل گر سیستم باید اثر بین ماژولی رو ببینه.
خیلی از تغییرها در اودوو فقط داخل یه ماژول نمی مونن و ممکنه روی حسابداری، انبار، فروش و گزارش ها هم اثر بذارن.
پنجم: هر چیزی که از نظر فنی شدنیه، لزوما تصمیم درستی نیست.
راه حل خوب باید هم برای کسب و کار ارزش داشته باشه، هم برای سیستم قابل نگهداری باشه.
خلاصه اینکه:
- تحلیل گر کسب و کار مشخص می کنه چرا و چه چیزی
- تحلیل گر سیستم مشخص می کنه چطور
- مالک محصول مشخص می کنه اولویت با چیه
- مدیر پروژه اجرا را کنترل می کنه
- مدیر محصول جهت کلی محصول رو می بینه
توی پروژه های Odoo، هر جا این مرزها روشن باشن، تحلیل تمیزتر درمیاد، توسعه کمتر پرت میره و تیم خیلی کمتر درگیر دوباره کاری میشه.