صورتجلسه بررسی طراحی ماژولمحور و جریان ثبتنام
Note
خلاصه جلسه
در این جلسه، رویکرد اجرایی پروژه از طراحی یکپارچه کل سیستم به طراحی و تکمیل ماژولبهماژول تغییر یافت. همچنین چارچوب هفتمرحلهای طراحی هر ماژول، منطق ثبتنام و ورود کاربران، نحوه ایجاد یا ورود به ساختمان، جایگاه پرداخت اشتراک و تفاوت میان User Flow و Workflow بررسی شد. در پایان نیز گزارشی از پیشرفت مستندات و توسعه پنل مدیریت سهمها ارائه شد.
اطلاعات جلسه
| عنوان | شرح |
|---|---|
| موضوع جلسه | بررسی منطق ساختاری، طراحی جریانهای کاری و تعیین رویکرد ماژولمحور برای سامانه مدیریت ساختمان |
| تاریخ | ۳۱ تیر ۱۴۰۵ |
حاضرین
- محمدامین علیمیرزایی
- منصور مجیدی
هدف جلسه
هدف اصلی جلسه، تعیین روش اجرایی مناسب برای طراحی و مستندسازی ماژولهای محصول، بررسی دقیق جریان ورود و ثبتنام کاربران و مشخصکردن منطق ایجاد یا عضویت در ساختمان بود.
همچنین مقرر شد مرز میان مسیر تجربه کاربر در محصول و گردش کارهای مدیریتی و بیننقشی بهصورت روشن تعریف شود تا تیم طراحی و توسعه بتواند هر ماژول را با ساختاری کامل و قابلپیادهسازی پیش ببرد.
شرح مباحث
۱. تغییر رویکرد اجرایی به طراحی ماژولمحور
در ابتدای جلسه، استراتژی جدید طراحی و توسعه محصول مطرح شد. بر اساس این رویکرد، بهجای استخراج و طراحی همزمان سناریوها، جریانهای کاربری و گردشکارهای کل سامانه، هر ماژول بهصورت مستقل از مرحله تحلیل تا طراحی نهایی تکمیل خواهد شد.
هدف از این تغییر، جلوگیری از پراکندگی تحلیلها، کاهش ابهامهای بین بخشهای مختلف و امکان تحویل خروجیهای کامل و قابلپیادهسازی در هر مرحله است.
بر این اساس، هر ماژول باید پیش از ورود به مرحله توسعه، تمامی اجزای تحلیلی و طراحی موردنیاز خود را در بر داشته باشد.
Important
اصل اجرایی مورد توافق
هر ماژول باید بهصورت کامل تحلیل، مستند و طراحی شود و سپس تیم به سراغ ماژول بعدی برود. شروع همزمان چند ماژول بدون تکمیل خروجیهای تحلیلی و طراحی، با رویکرد جدید همخوانی ندارد.
۲. چارچوب هفتمرحلهای طراحی هر ماژول
برای طراحی و تکمیل هر ماژول، یک فرایند هفتمرحلهای مورد توافق قرار گرفت:
۲.۱. تعیین هدف، محدوده و سناریوها
در نخستین مرحله باید هدف اصلی ماژول، مسئلهای که حل میکند، کاربران مرتبط و محدوده عملکرد آن مشخص شود.
سناریوهای اصلی، سناریوهای فرعی و حالتهای خاص نیز باید پیش از طراحی جریانها استخراج شوند.
۲.۲. طراحی User Flow
در این مرحله، مسیر حرکت کاربر در محصول ترسیم میشود؛ از نقطه ورود تا رسیدن به هدف نهایی.
User Flow باید مشخص کند کاربر چه صفحهها، تصمیمها، فرمها و وضعیتهایی را تجربه میکند.
۲.۳. طراحی Workflow
Workflow به گردش کار میان نقشها، وضعیتها و فرایندهای داخلی سیستم مربوط است.
برای نمونه، در یک ماژول تیکتینگ باید مشخص شود:
- تیکت توسط چه نقشی ایجاد میشود.
- تیکت به چه شخص یا واحدی ارجاع داده میشود.
- چه وضعیتهایی دارد.
- چه کسی امکان تأیید، رد یا بستن آن را دارد.
- تغییر هر وضعیت چه اثر یا اعلانهایی ایجاد میکند.
در جلسه تأکید شد که Workflow با User Flow یکسان نیست. User Flow مسیر تجربه یک کاربر در رابط محصول است، در حالی که Workflow منطق گردش فرایند میان نقشها و اجزای سیستم را تعریف میکند.
۲.۴. تعیین سطوح دسترسی
برای هر ماژول باید مشخص شود هر نقش چه عملیات و اطلاعاتی را میتواند مشاهده، ایجاد، ویرایش، تأیید یا حذف کند.
سطوح دسترسی باید بهصورت مستقل برای همان ماژول تعریف شوند و صرفاً به نقش کلی کاربر در سامانه متکی نباشند.
۲.۵. تعیین اعلانها
تمامی رویدادهایی که نیازمند اطلاعرسانی هستند باید مشخص شوند.
برای هر اعلان نیز لازم است موارد زیر تعیین شود:
- رویداد ایجادکننده اعلان
- دریافتکننده اعلان
- کانال ارسال
- متن یا محتوای اعلان
- زمان ارسال
- وضعیت خواندهشدن یا پیگیری
۲.۶. مدیریت خطاها و حالتهای خاص
خطاهای فنی، خطاهای کاربری، دادههای ناقص، دسترسی نامعتبر و سناریوهای خارج از مسیر عادی باید پیش از طراحی نهایی بررسی شوند.
این مرحله باید شامل حالتهای مرزی و شرایطی باشد که ممکن است جریان اصلی را متوقف یا تغییر دهند.
۲.۷. طراحی نهایی رابط کاربری
با توجه به وجود Design System، مقرر شد مرحله Wireframe سیاهوسفید بهصورت مستقل حذف شود و طراحی مستقیماً بر اساس ساختار و کامپوننتهای سیستم طراحی انجام شود.
با این حال، ورود مستقیم به طراحی نهایی مشروط به تکمیل مراحل تحلیل، User Flow، Workflow، دسترسیها، اعلانها و مدیریت خطاها خواهد بود.
۳. منطق ثبتنام و ورود کاربران
بخش قابلتوجهی از جلسه به بررسی جریان ثبتنام و ورود کاربران اختصاص یافت.
۳.۱. روش احراز هویت
احراز هویت کاربران صرفاً بر اساس شماره موبایل انجام خواهد شد.
اطلاعات تکمیلی کاربر میتواند پس از ورود و در مراحل بعدی دریافت شود تا فرایند اولیه ورود ساده و سریع باقی بماند.
۳.۲. بررسی وضعیت کاربر پس از ورود
پس از تأیید شماره موبایل، سیستم باید وضعیت عضویت کاربر در ساختمانها را بررسی کند.
دو سناریوی اصلی برای این مرحله تعریف شد:
سناریوی اول: کاربر از قبل به یک ساختمان اضافه شده است
اگر شماره موبایل کاربر پیشتر توسط مدیر یا مسئول ساختمان در سامانه ثبت شده باشد، کاربر پس از ورود باید به محیط ساختمان مربوط هدایت شود.
در صورت عضویت در بیش از یک ساختمان، نیاز به انتخاب ساختمان فعال وجود خواهد داشت. جزئیات این سناریو در جلسه نهایی نشد و باید در طراحی User Flow بررسی شود.
سناریوی دوم: کاربر هیچ ساختمانی ندارد
اگر شماره موبایل کاربر به هیچ ساختمانی متصل نباشد، صفحهای برای شروع کار نمایش داده میشود که شامل گزینه ایجاد ساختمان خواهد بود.
موضوع امکان پیوستن به ساختمان از طریق دعوت، کد یا درخواست عضویت در این جلسه بهصورت نهایی تعیین نشد و نیازمند بررسی جداگانه است.
۳.۳. اصل سادهسازی ثبتنام
تأکید شد که ثبتنام اولیه نباید شامل فرمهای طولانی یا تنظیمات پیچیده ساختمان باشد.
هدف از این تصمیم، کاهش احتمال رهاکردن فرایند توسط کاربر و رساندن سریع او به محیط اصلی محصول است.
اطلاعات تکمیلی و تنظیمات پیشرفته باید پس از ورود و در قالب مراحل قابلفهم و تدریجی دریافت شوند.
Important
اصل تجربه کاربری
ورود اولیه باید با کمترین تعداد مرحله و حداقل اطلاعات موردنیاز انجام شود. تنظیمات پیچیده ساختمان نباید مانع ورود کاربر به محصول شوند.
۴. جریان ایجاد ساختمان
برای کاربری که هیچ ساختمانی ندارد، امکان ایجاد ساختمان در نظر گرفته شد.
اطلاعات اولیه موردنیاز برای ایجاد ساختمان میتواند شامل موارد زیر باشد:
- نام ساختمان
- تعداد طبقات
- تعداد واحدها
- اطلاعات پایه مدیر یا ایجادکننده
- اطلاعات موردنیاز برای ساخت ساختار اولیه ساختمان
مقرر شد جزئیات غیرضروری در مرحله اولیه دریافت نشوند و پس از ایجاد ساختمان، از طریق تنظیمات یا فرایند تکمیل اطلاعات ثبت شوند.
۴.۱. جایگاه پرداخت اشتراک
در صورت اشتراکی بودن سامانه، پرداخت هزینه باید در انتهای فرایند ایجاد ساختمان قرار گیرد.
بر این اساس، کاربر ابتدا اطلاعات ضروری ساختمان را ثبت میکند و پس از آمادهشدن ساختار اولیه، وارد مرحله انتخاب یا پرداخت اشتراک میشود.
در جلسه مطرح شد که قرارگرفتن پرداخت در ابتدای مسیر میتواند نرخ رهاکردن فرایند را افزایش دهد.
با این حال، نحوه برخورد سیستم با ساختمان ایجادشده اما پرداختنشده، دوره آزمایشی و محدودیت امکانات تا پیش از پرداخت نیازمند تصمیمگیری تکمیلی است.
۵. تفاوت User Flow و Workflow
در جلسه بر تفکیک این دو مفهوم تأکید شد:
| مفهوم | تعریف | نمونه |
|---|---|---|
| User Flow | مسیر و تجربهای که یک کاربر برای رسیدن به هدف در محصول طی میکند | ورود با شماره موبایل، مشاهده وضعیت عضویت و ورود به ساختمان |
| Workflow | گردش یک فرایند میان نقشها، وضعیتها و قواعد سیستم | ثبت درخواست توسط ساکن، بررسی مدیر، تأیید یا رد و ارسال اعلان |
این تفکیک باید در تمامی مستندات و خروجیهای طراحی رعایت شود تا جریان تجربه کاربری با منطق عملیاتی سامانه ترکیب نشود.
۶. گزارش اقدامات انجامشده
۶.۱. بهروزرسانی مستندات جلسات
ساختار مستندات جلسات بازنگری و اصلاح شده است.
محتوای سه جلسه پیشین نیز در بخش مستندات پروژه ثبت و یکدستسازی شده است.
۶.۲. بهبود پنل مدیریت سهمها
پنل مربوط به مدیریت سهمها توسعه یافته و ساختار آن کاملتر شده است.
قابلیت محاسبه سهم بر اساس درصد و تعداد در حال اضافهشدن است تا سناریوهای مختلف تقسیم هزینه قابل پشتیبانی باشند.
۶.۳. بهبود زیرساخت مستندسازی
ماژولها و ابزارهای جدیدی برای بهبود نمایش و ساختار مستندات نصب شدهاند.
همچنین یک فایل راهنما برای استفاده ابزارهای هوش مصنوعی تدوین شده است تا مستندات بر اساس ساختار، لحن و قالب بصری مشخص تولید یا بازنویسی شوند.
این راهنما شامل قواعدی برای عنوانبندی، Calloutها، جداول، چکلیستها و یکدستسازی متن مستندات است.
تصمیمات نهایی
- طراحی محصول بهصورت ماژولبهماژول انجام شود.
- هر ماژول پیش از توسعه، بر اساس چارچوب هفتمرحلهای تحلیل و طراحی شود.
- User Flow و Workflow بهعنوان دو خروجی مستقل تدوین شوند.
- احراز هویت کاربران صرفاً بر اساس شماره موبایل انجام شود.
- وضعیت عضویت کاربر در ساختمان پس از ورود بررسی شود.
- کاربرانی که از قبل به ساختمان اضافه شدهاند، پس از ورود به محیط همان ساختمان هدایت شوند.
- کاربران فاقد ساختمان، امکان ایجاد ساختمان داشته باشند.
- فرایند ثبتنام و ورود اولیه تا حد ممکن کوتاه و ساده باشد.
- تنظیمات تکمیلی ساختمان پس از ورود دریافت شوند.
- در مدل اشتراکی، پرداخت در انتهای فرایند ایجاد ساختمان قرار گیرد.
- با توجه به وجود Design System، مرحله مستقل Wireframe حذف و طراحی مستقیماً در قالب نهایی انجام شود.
- مستندات جلسات و خروجیهای طراحی بر اساس راهنمای مستندسازی پروژه تهیه شوند.
Warning
موضوعات باز
موارد زیر در جلسه به تصمیم نهایی نرسیدند و باید در مراحل بعدی تعیین تکلیف شوند:
- نحوه انتخاب ساختمان برای کاربران عضو چند ساختمان
- امکان پیوستن به ساختمان از طریق دعوت، کد یا درخواست عضویت
- وضعیت ساختمان ایجادشده پیش از پرداخت اشتراک
- وجود یا عدم وجود دوره آزمایشی
- محدودیتهای سامانه برای ساختمانهای فاقد اشتراک فعال
- اطلاعات حداقلی موردنیاز برای ایجاد ساختمان
- اولویت نهایی ماژولهای نخست برای طراحی و پیادهسازی
وظایف و اقدامات
| ردیف | شرح وظیفه | مسئول | مهلت | وضعیت | خروجی قابلبررسی |
|---|---|---|---|---|---|
| ۱ | تکمیل قابلیت محاسبه سهم بر اساس درصد و تعداد در پنل مدیریت سهمها | محمدامین علیمیرزایی | جلسه بعد | در حال انجام | نسخه قابلنمایش و تست قابلیت |
| ۲ | آغاز طراحی ماژولها بر اساس چارچوب هفتمرحلهای | منصور مجیدی | جلسه بعد | برنامهریزی شده | مستند کامل نخستین ماژول |
| ۳ | تدوین User Flow ثبتنام، ورود و ایجاد ساختمان | منصور مجیدی | جلسه بعد | شروع نشده | نمودار و شرح سناریوهای اصلی |
| ۴ | تدوین Workflow عضویت و راهاندازی ساختمان | منصور مجیدی | جلسه بعد | شروع نشده | وضعیتها، نقشها و قواعد گردش کار |
| ۵ | ثبت محتوای جلسه جاری در مستندات پروژه | محمدامین علیمیرزایی | فوری | در حال انجام | فایل صورتجلسه ثبتشده در مخزن |
| ۶ | بررسی موارد باز مربوط به اشتراک و پرداخت | تیم محصول | جلسه بعد | نیازمند تصمیمگیری | فهرست گزینهها و تصمیم پیشنهادی |
موارد نیازمند پیگیری
- تعیین نخستین ماژول برای اجرای کامل رویکرد هفتمرحلهای
- تعیین روش عضویت کاربر در ساختمانهایی که مدیر قبلاً او را ثبت نکرده است
- طراحی سناریوی کاربران عضو چند ساختمان
- مشخصکردن وضعیت ساختمان پیش از فعالشدن اشتراک
- بررسی امکان دوره آزمایشی و محدودیتهای آن
- تعیین حداقل اطلاعات لازم برای ایجاد ساختمان
- تعریف اعلانهای مرتبط با دعوت، عضویت، ایجاد ساختمان و پرداخت
- تعیین خطاها و حالتهای خاص جریان ورود و ایجاد ساختمان
- یکدستسازی اصطلاحات User Flow، Workflow، سناریو و دسترسی در مستندات
آمادگی برای جلسه بعدی
Note
موارد زیر باید پیش از جلسه بعدی آماده و برای بررسی در اختیار اعضای جلسه قرار گیرند.
- نسخه اولیه User Flow ثبتنام و ورود
- مسئول: منصور مجیدی
-
خروجی مورد انتظار: مسیر ورود با شماره موبایل، بررسی عضویت، ورود به ساختمان و ایجاد ساختمان بهصورت کامل ترسیم شده باشد.
-
نسخه اولیه Workflow عضویت و ایجاد ساختمان
- مسئول: منصور مجیدی
-
خروجی مورد انتظار: نقشها، وضعیتها، تصمیمها و قواعد گردش کار مشخص شده باشند.
-
تعیین سطوح دسترسی ماژول عضویت و راهاندازی
- مسئول: منصور مجیدی
-
خروجی مورد انتظار: دسترسی مدیر، ساکن و سایر نقشهای مرتبط در این ماژول ثبت شده باشد.
-
مشخصشدن اعلانها و خطاهای جریان ثبتنام
- مسئول: منصور مجیدی
-
خروجی مورد انتظار: رویدادهای اعلان، دریافتکنندگان و مهمترین حالتهای خطا مستند شده باشند.
-
تکمیل قابلیت درصد و تعداد در پنل مدیریت سهمها
- مسئول: محمدامین علیمیرزایی
-
خروجی مورد انتظار: قابلیت برای سناریوهای اصلی تقسیم سهم آماده نمایش و تست باشد.
-
ثبت صورتجلسه در مخزن مستندات
- مسئول: محمدامین علیمیرزایی
-
خروجی مورد انتظار: فایل نهایی صورتجلسه با ساختار استاندارد پروژه در مخزن ثبت شده باشد.
-
جمعبندی منطق پرداخت اشتراک
- مسئول: تیم محصول
-
خروجی مورد انتظار: زمان پرداخت، وضعیت پیش از پرداخت، دوره آزمایشی و محدودیتهای اشتراک مشخص شده باشند.
-
تعیین ماژول بعدی برای طراحی
- مسئول: تیم محصول
- خروجی مورد انتظار: اولویت ماژول بعدی و دلیل انتخاب آن ثبت شده باشد.
نتیجهگیری
در این جلسه، چارچوب اجرایی جدید پروژه بر پایه طراحی کامل و مرحلهای هر ماژول مورد توافق قرار گرفت. این رویکرد باید باعث کاهش ابهام، افزایش کیفیت مستندات و نزدیکترشدن خروجیهای طراحی به نیازهای توسعه شود.
ماژول عضویت، ثبتنام و راهاندازی ساختمان بهعنوان یکی از نخستین حوزههای طراحی تفصیلی مطرح شد. در این بخش، سادهسازی ورود، بررسی وضعیت عضویت کاربر، ایجاد ساختمان و جایگاه پرداخت اشتراک از موضوعات اصلی بودند.
همچنین مقرر شد پیشرفت فنی پنل مدیریت سهمها ادامه یابد و تمامی تصمیمات و خروجیهای طراحی بر اساس ساختار استاندارد مستندسازی پروژه ثبت شوند.