وبلاگ رادمان

پیشتر ها وقتی تفاوت تولید صنعتی با تولید نرم افزاری مقایسه می شد، یکی از دلایل سودآوری بیشتر تولید نرم افزاری را در آن می دانستند که در تولید صنعتی یک بار تولید می کنی، یک بار می فروشی، اما در تولید نرم افزاری یک بار تولید می کنی، n بار می فروشی. اینکه هزینه تکثیر محصول نرم افزاری آنقدر پایین است که می توان آن را نسبت به هزینه اولیه ساخت نادیده گرفت.
اما …
این روزها، این قاعده را باید به فراموشی سپرد. چرا؟ چون در اغلب محصولات تخصصی،   نمی توان یک محصول را در اختیار همه قرار داد، مگر آنکه عمومیت مساله، حجم فروش و انحصاری بودن بازار آنقدر باشد که بتوانید با رعایت یک الگوی ورژن بندی، برای پوشش نیازهای مشتریان ، در یک روش تکاملی محصول را ارتقاء داد.
در مسائل جدید نرم افزار و در بازارهای اختصاصی تر و یا با وجود رقبای زیاد، شما به عنوان یک تولید کننده نرم افزار مواجه خواهید شد با مقداری از منطبق سازی، که خود یک پروژه کوتاه مدت جدید خواهد بود و باعث تغییر در نرم افزار شما می شود. به دلایلی که ذکر کردم گاهی اوقات دست شما بسته است که به مشتری بگویید همین است و بس٫
برای مثال در مورد سیستمهای مالی اداری، با وجودیکه محصولات پر فروشی مانند سیستم های همکاران سیستم در بازار وجود دارد، اما به دلیل تغییر نگرش کاربران و استفاده کنندگان، که ترجیح می دهند هر چقدر کم، آنقدر در نرم افزار تغییر داده شود که احساس کنند آن نرم افزار اختصاصی برای خودشان است و نیاز واقعیشان را برآورده می کند، سراع تولید کنندگان کوچکتر و محصولات کمتر رایج اما در عین حال پویا تر می روند.می بینم که شرکتهای کوچک حتی در تبلیغاتشان، اینکه نرم افزار را اختصاصی می کنند را به عنوان یک مزیت مطرح می کنند و در پرسش خریداران ، قابلیت اختصاصی شدن نرم افزار با نیازهای آنان هم به عنوان یک عامل تاثیر گذار در تصمیم گیری مطرح می شود.

اگر بخواهم نگاه دقیق تری به مساله اختصاصی سازی نرم افزار داشته باشم باید مروری بکنیم بر سیر تحول تولید محصول نرم افزاری:
- در دوره های اول به دلیل نیازهای کم و رشد نیافته بودن تکنیک های مهندسی نرم افزار، هر مساله یک پروژه جدید بود و حجم فروش دوباره محصولات بسیار پایین بود.
- با رشد نیازها و وضع تکنیک ها، روشها و فرآیند های توسعه نرم افزار، مساله تولید یک بار، فروش چند بار از طریق ساخت بسته های نرم افزاری (Software Packages ) عام رواح پیدا کرد و تولید کنندگان، مصرفکننده را ملزم به استفاده از همان محصول ثابت می کردند. مشتریان هم به دلیل عدم تنوع در انتخاب ناچار به پذیرش این واقعیت بودند.
- با بلوغ تکنیک های توسعه نرم افزار و افزایش سطح توقعات مشتریان، دیگر نمی شد محصول را بدون منطبق سازی مطرح کرد، اما تلاش می شد این منطبق سازی در حجم کم و یا در قالب نسخه های بعدی (Next Version ) حل و فصل شود.
در این دوره با ساخت سیستمهایی نظیر ERP تلاش شد همه فرآیند های سازمانها استاندارد و پیاده سازی گردد تا یک محصول یا بخشی از آن بتواند نیاز یک مشتری جدید را برآورده سازد، اما باز هم بحث Tailoring را برای منطبق سازی محدود سیستم با نیاز های مشتری مطرح است و رایج. چنانچه می بینیم متدولوژی های تحلیل و طراحی سیستمها نیز به سمت روشهای قابل انعطاف تری مانند متدولوژی های چابک (Agile) مانند روش برنامه سازی کرانه ای (XP) حرکت کرده اند که پذیرش تغییر از جانب مشتری را به عنوان یک اصل می شناسند.
به عنوان یک تولید کننده نرم افزار، این مساله که باید برای هر مشتری منطبق سازی را انجام داد، گاهی مواقع آزار دهنده می شود. در نظر گرفتن نظرات مشتریان مختلفدر یک محصول، بویژه مسائلی که هیچ استاندارد مشخص و رایجی در مورد آنها وجود ندارد، باعث می شود محصول شما آنقدر بزرگ و حجیم شود که عملا کارایی آن از دست برود و برای مشتریان سخت گردد. نوشتن نسخه های مختلف از یک سیستم برای هر مشتری هم چنانچه با مدیریت صحیح کد همراه نباشد، باعث می شود که پشتیبانی و به روز کردن هر کدام از محصولات سخت گردد و تست نرم افزار سخت تر.
البته، متخصصان امر ، راه هایی برای مدیریت صحیح تغییرات و برآورده سازی نیاز مشتریان مطرح می کنند که برخی فقط در بخشهای آکادمیک و برخی در عمل و کاربرد، جواب خود را پس داده اند و می توانند مورد استفاده قرار گیرند. اگر فرصت کنم در مورد روش مدیریت این گونه تغییرات ، منطبق سازی متعدد یک محصول با نیازهای مختلف مشتریان، خواهم نوشت.
همین!