وقتی «نیاز امروز» برای یک سال کافی نبود؛ تجربه‌ای از تحلیل یک نرم‌افزار بیمه
گاهی یک پروژه نرم‌افزاری در ابتدا کاملاً مشخص به نظر می‌رسد؛ کارفرما نیازها و قوانین موردنظرش را توضیح می‌دهد و انتظار دارد نرم‌افزار دقیقاً بر اساس همان نیازها ساخته شود. اما در بعضی پروژه‌ها، مسئله واقعی زمانی خودش را نشان می‌دهد که نرم‌افزار وارد استفاده واقعی شود و کسب‌وکار شروع به رشد و تغییر کند.
تجربه‌ای که در ادامه می‌خوانید مربوط به پروژه‌ای در حوزه فروش بیمه است؛ پروژه‌ای که در آن تغییر مداوم مدل محاسبه پورسانت به من نشان داد تحلیل نیازمندی فقط شناخت نیازهای امروز نیست، بلکه باید تغییرات احتمالی کسب‌وکار در آینده را هم تا حد امکان در نظر گرفت.
در این پروژه از من خواسته شد سامانه‌ای برای مدیریت بازاریابی و همکاری در فروش طراحی کنم.
این نرم‌افزار وظیفه ثبت بازاریاب‌ها و زیرمجموعه‌های آن‌ها، مدیریت ساختار شبکه و مهم‌تر از همه، محاسبه دقیق پورسانت‌ها و پاداش‌ها را بر عهده داشت.
در ابتدای کار، تعداد بازاریاب‌ها محدود بود؛ اما ایده شرکت این بود که با اجرای طرح‌های تشویقی و افزایش انگیزه، شبکه فروش به‌صورت مستمر توسعه پیدا کند.
سؤال مهمی که قبل از شروع پروژه مطرح شد
کارفرما در ابتدای پروژه یک پلن مشخص برای محاسبه پورسانت و پاداش طراحی کرده بود و انتظار داشت نرم‌افزار همان مدل را اجرا کند.
اما برای من سؤال مهم‌تری وجود داشت:
اگر این پلن در عمل آن‌طور که انتظار داریم جواب ندهد، نرم‌افزار باید چه کار کند؟
ممکن بود پلن روی کاغذ منطقی و کامل به نظر برسد، اما پس از شروع فعالیت واقعی شبکه، نتایج فروش و رفتار بازاریاب‌ها نشان دهد که بخشی از قوانین نیاز به اصلاح دارد یا حتی ساختار پاداش باید تغییر کند.
به همین دلیل، قبل از اعلام قیمت و شروع توسعه، حدود ۱۰ جلسه کاری با کارفرما و کارشناسان فنی برگزار کردم تا نیازها و جزئیات پروژه را بررسی و تحلیل کنیم.
هدف فقط تهیه فهرستی از امکانات موردنیاز نبود. لازم بود مدل کسب‌وکار، ساختار شبکه فروش، نحوه محاسبه پورسانت‌ها، ارتباط بین فروش مستقیم و فروش زیرمجموعه و همچنین تغییراتی که ممکن بود در آینده در این مدل ایجاد شود، به‌دقت بررسی کنم.
نتیجه این تحلیل باعث شد نرم‌افزار از ابتدا با در نظر گرفتن امکان تغییر و توسعه پلن‌های محاسبه پورسانت طراحی شود.
وقتی پلن در دنیای واقعی تغییر می‌کند
همان‌طور که در مرحله تحلیل پیش‌بینی کرده بودم، در طول یک سال، پلن محاسبه پورسانت و پاداش چندین مرتبه تغییر کرد و هر بار بر اساس نتایج به‌دست‌آمده اصلاح و بهینه‌سازی شد.
برخی تغییرات نیازمند اصلاح فرمول‌های قبلی بود و در بعضی موارد نیز تغییرات به اندازه‌ای بود که نیاز به برنامه‌نویسی و توسعه بخش‌هایی از سیستم داشت.
اما یکی از تصمیم‌های مهم در طراحی اولیه این بود که هر نسخه از پلن و قوانین مربوط به آن در کنار سوابق دوره‌های قبلی قابل نگهداری باشد.
بنابراین با تغییر پلن، اطلاعات و محاسبات دوره‌های گذشته از بین نمی‌رفت و می‌شد محاسبات هر دوره را بر اساس قوانین همان دوره بررسی کرد.
این موضوع با رشد شبکه اهمیت بیشتری پیدا می‌کرد؛ زیرا هرچه تعداد بازاریاب‌ها و حجم فروش افزایش پیدا می‌کرد، فشار بیشتری به سرور وارد می‌شد و سیستم باید می‌توانست حجم بیشتری از محاسبات را بدون کاهش دقت و سرعت مدیریت کند.
چرا دقت محاسبات اهمیت داشت؟
قرار بود پورسانت بازاریاب‌ها در ابتدای هر ماه پرداخت شود. بنابراین سیستم فقط یک ابزار ثبت اطلاعات نبود؛ خروجی آن مستقیماً با پرداخت مالی به اعضای شبکه ارتباط داشت.
در چنین سیستمی، یک خطای کوچک در محاسبه پورسانت می‌توانست به اختلاف مالی، نارضایتی و حتی از بین رفتن اعتماد اعضای شبکه منجر شود.
به همین دلیل، هر نسخه از پلن پس از اجرا در شرایط واقعی مورد ارزیابی قرار می‌گرفت. میزان فروش، نحوه عملکرد شبکه، رفتار بازاریاب‌ها و میزان استقبال آن‌ها از مدل پاداش بررسی می‌شد تا مشخص شود آیا پلن جدید در عمل نیز همان نتیجه‌ای را ایجاد می‌کند که انتظار داشتیم یا نه.
در واقع، نرم‌افزار قرار نبود فقط یک فرمول ثابت را اجرا کند؛ بلکه باید زیرساختی می‌بود که بتواند همراه با تغییر و تکامل مدل کسب‌وکار توسعه پیدا کند.
تجربه‌ای که اهمیت تحلیل اولیه را بیشتر نشان داد
مدیر این مجموعه بعدها درباره تجربه خود از انتخاب من به‌عنوان مجری پروژه نکته قابل تأملی را مطرح کرد.
او گفت پیش از مراجعه به من، با چند شرکت نرم‌افزاری صحبت کرده است. برخی از آن‌ها بدون بررسی دقیق جزئیات پروژه و مدل کاری مجموعه، صرفاً یک قیمت اعلام کرده و گفته بودند پروژه را اجرا می‌کنند؛ اما تو در این پروژه، قبل از اعلام قیمت، زمان قابل توجهی برای شناخت و تحلیل دقیق مسئله صرف کرده ای تا بفهمی ما دقیقا چه چیزی میخواهیم، این یعنی تو مسئله ما را درک کرده ای.
مدتی بعد، فرد دیگری با من تماس گرفت و گفت مجموعه آن‌ها نیز پروژه‌ای مشابه را با یک تیم برنامه‌نویسی دیگر اجرا کرده است. اما پس از گذشت چند ماه، با مشکلاتی در سیستم مواجه شده و شبکه فروش آن‌ها ریزش کرده است.
آن‌ها پس از شنیدن موفقیت این شرکت بیمه، با من تماس گرفتند و خواستند پروژه‌شان را بررسی کنم و در صورت امکان، آن را با رویکردی متفاوت طراحی و توسعه دهم.
آن‌ها درباره علت شکست پروژه از من پرسیدند. به آن‌ها گفتم تحلیل نادرست مسئله و انتخاب نامناسب فناوری و رویکرد فنی برای پیاده‌سازی نرم‌افزار از عوامل اصلی شکست پروژه آن‌ها بوده است؛ مسائلی که در پروژه‌های پیچیده ممکن است آثار خود را نه در روزهای اول، بلکه چند ماه بعد و همزمان با رشد کسب‌وکار نشان دهند.
چیزی که از این تجربه یاد گرفتم
این تجربه برای من یک نکته مهم را روشن‌تر کرد:
تحلیل نرم‌افزار فقط تهیه فهرستی از امکانات موردنیاز امروز نیست؛ بلکه باید تا حد امکان تغییرات و نیازهای احتمالی آینده را نیز در طراحی در نظر گرفت.
ممکن است کارفرما در روز اول تصور کند نیازش کاملاً مشخص است، اما وقتی یک کسب‌وکار وارد مرحله اجرا می‌شود، رفتار کاربران، شرایط بازار، مدل درآمدی و حتی قوانین داخلی آن می‌توانند در طول زمان تغییر کنند.
نرم‌افزاری که از ابتدا برای چنین تغییراتی آمادگی داشته باشد، می‌تواند همراه با کسب‌وکار رشد کند؛ اما نرم‌افزاری که فقط برای شرایط روز اول طراحی شده باشد، ممکن است با هر تغییر مهم، نیازمند اصلاحات اساسی شود.
به همین دلیل، در پروژه‌های نرم‌افزاری، یکی از مهم‌ترین پرسش‌هایی که باید قبل از شروع توسعه مطرح شود این نیست که:
«امروز چه چیزی میخواهیم؟»
بلکه این است:
«اگر فردا نیازمان تغییر کرد، این نرم‌افزار چقدر توانایی تغییر خواهد داشت؟»
دیدگاه شما
اگر تجربه یا نظری درباره این مقاله دارید، خوشحال می‌شوم آن را با من و سایر خوانندگان به اشتراک بگذارید.