Y@SiN
11-19-2009, 07:05 PM
پيشتر ها وقتي تفاوت توليد صنعتي با توليد نرم افزاري مقايسه مي شد، يکي از دلايل سودآوري بيشتر توليد نرم افزاري را در آن مي دانستند که در توليد صنعتي يک بار توليد مي کني، يک بار مي فروشي، اما در توليد نرم افزاري يک بار توليد مي کني، n بار مي فروشي. اينکه هزينه تکثير محصول نرم افزاري آنقدر پايين است که مي توان آن را نسبت به هزينه اوليه ساخت ناديده گرفت.
اما ...
اين روزها، اين قاعده را بايد به فراموشي سپرد. چرا؟ چون در اغلب محصولات تخصصي، نمي توان يک محصول را در اختيار همه قرار داد، مگر آنکه عموميت مساله، حجم فروش و انحصاري بودن بازار آنقدر باشد که بتوانيد با رعايت يک الگوي ورژن بندي، براي پوشش نيازهاي مشتريان ، در يک روش تکاملي محصول را ارتقاء داد.
در مسائل جديد نرم افزار و در بازارهاي اختصاصي تر و يا با وجود رقباي زياد، شما به عنوان يک توليد کننده نرم افزار مواجه خواهيد شد با مقداري از منطبق سازي، که خود يک پروژه کوتاه مدت جديد خواهد بود و باعث تغيير در نرم افزار شما مي شود. به دلايلي که ذکر کردم گاهي اوقات دست شما بسته است که به مشتري بگوييد همين است و بس.
براي مثال در مورد سيستمهاي مالي اداري، با وجوديکه محصولات پر فروشي مانند سيستم هاي همکاران سيستم در بازار وجود دارد، اما به دليل تغيير نگرش کاربران و استفاده کنندگان، که ترجيح مي دهند هر چقدر کم، آنقدر در نرم افزار تغيير داده شود که احساس کنند آن نرم افزار اختصاصي براي خودشان است و نياز واقعيشان را برآورده مي کند، سراع توليد کنندگان کوچکتر و محصولات کمتر رايج اما در عين حال پويا تر مي روند.مي بينم که شرکتهاي کوچک حتي در تبليغاتشان، اينکه نرم افزار را اختصاصي مي کنند را به عنوان يک مزيت مطرح مي کنند و در پرسش خريداران ، قابليت اختصاصي شدن نرم افزار با نيازهاي آنان هم به عنوان يک عامل تاثير گذار در تصميم گيري مطرح مي شود.
اگر بخواهم نگاه دقیق تري به مساله اختصاصي سازي نرم افزار داشته باشم بايد مروري بکنیم بر سير تحول توليد محصول نرم افزاري:
- در دوره هاي اول به دليل نيازهاي کم و رشد نيافته بودن تکنيک هاي مهندسي نرم افزار، هر مساله يک پروژه جديد بود و حجم فروش دوباره محصولات بسيار پايين بود.
- با رشد نيازها و وضع تکنيک ها، روشها و فرآيند هاي توسعه نرم افزار، مساله توليد يک بار، فروش چند بار از طريق ساخت بسته هاي نرم افزاري (Software Packages ) عام رواح پيدا کرد و توليد کنندگان، مصرفکننده را ملزم به استفاده از همان محصول ثابت مي کردند. مشتريان هم به دليل عدم تنوع در انتخاب ناچار به پذيرش اين واقعيت بودند.
- با بلوغ تکنيک هاي توسعه نرم افزار و افزايش سطح توقعات مشتريان، ديگر نمي شد محصول را بدون منطبق سازي مطرح کرد، اما تلاش مي شد اين منطبق سازي در حجم کم و يا در قالب نسخه هاي بعدي (Next Version ) حل و فصل شود.
در اين دوره با ساخت سيستمهايي نظير ERP تلاش شد همه فرآيند هاي سازمانها استاندارد و پياده سازي گردد تا يک محصول يا بخشي از آن بتواند نياز يک مشتري جديد را برآورده سازد، اما باز هم بحث Tailoring را براي منطبق سازي محدود سيستم با نياز هاي مشتري مطرح است و رايج. چنانچه مي بينيم متدولوژي هاي تحليل و طراحي سيستمها نيز به سمت روشهاي قابل انعطاف تري مانند متدولوژي هاي چابک (Agile) مانند روش برنامه سازي کرانه اي (XP) حرکت کرده اند که پذيرش تغيير از جانب مشتري را به عنوان يک اصل مي شناسند.
به عنوان يک توليد کننده نرم افزار، اين مساله که بايد براي هر مشتري منطبق سازي را انجام داد، گاهي مواقع آزار دهنده مي شود. در نظر گرفتن نظرات مشتريان مختلفدر يک محصول، بويژه مسائلي که هيچ استاندارد مشخص و رايجي در مورد آنها وجود ندارد، باعث مي شود محصول شما آنقدر بزرگ و حجيم شود که عملا کارايي آن از دست برود و براي مشتريان سخت گردد. نوشتن نسخه هاي مختلف از يک سيستم براي هر مشتري هم چنانچه با مديريت صحيح کد همراه نباشد، باعث مي شود که پشتيباني و به روز کردن هر کدام از محصولات سخت گردد و تست نرم افزار سخت تر.
البته، متخصصان امر ، راه هايي براي مديريت صحيح تغييرات و برآورده سازي نياز مشتريان مطرح مي کنند که برخي فقط در بخشهاي آکادميک و برخي در عمل و کاربرد، جواب خود را پس داده اند و مي توانند مورد استفاده قرار گيرند. اگر فرصت کنم در مورد روش مديريت اين گونه تغييرات ، منطبق سازي متعدد يک محصول با نيازهاي مختلف مشتريان، خواهم نوشت.
همين!
اما ...
اين روزها، اين قاعده را بايد به فراموشي سپرد. چرا؟ چون در اغلب محصولات تخصصي، نمي توان يک محصول را در اختيار همه قرار داد، مگر آنکه عموميت مساله، حجم فروش و انحصاري بودن بازار آنقدر باشد که بتوانيد با رعايت يک الگوي ورژن بندي، براي پوشش نيازهاي مشتريان ، در يک روش تکاملي محصول را ارتقاء داد.
در مسائل جديد نرم افزار و در بازارهاي اختصاصي تر و يا با وجود رقباي زياد، شما به عنوان يک توليد کننده نرم افزار مواجه خواهيد شد با مقداري از منطبق سازي، که خود يک پروژه کوتاه مدت جديد خواهد بود و باعث تغيير در نرم افزار شما مي شود. به دلايلي که ذکر کردم گاهي اوقات دست شما بسته است که به مشتري بگوييد همين است و بس.
براي مثال در مورد سيستمهاي مالي اداري، با وجوديکه محصولات پر فروشي مانند سيستم هاي همکاران سيستم در بازار وجود دارد، اما به دليل تغيير نگرش کاربران و استفاده کنندگان، که ترجيح مي دهند هر چقدر کم، آنقدر در نرم افزار تغيير داده شود که احساس کنند آن نرم افزار اختصاصي براي خودشان است و نياز واقعيشان را برآورده مي کند، سراع توليد کنندگان کوچکتر و محصولات کمتر رايج اما در عين حال پويا تر مي روند.مي بينم که شرکتهاي کوچک حتي در تبليغاتشان، اينکه نرم افزار را اختصاصي مي کنند را به عنوان يک مزيت مطرح مي کنند و در پرسش خريداران ، قابليت اختصاصي شدن نرم افزار با نيازهاي آنان هم به عنوان يک عامل تاثير گذار در تصميم گيري مطرح مي شود.
اگر بخواهم نگاه دقیق تري به مساله اختصاصي سازي نرم افزار داشته باشم بايد مروري بکنیم بر سير تحول توليد محصول نرم افزاري:
- در دوره هاي اول به دليل نيازهاي کم و رشد نيافته بودن تکنيک هاي مهندسي نرم افزار، هر مساله يک پروژه جديد بود و حجم فروش دوباره محصولات بسيار پايين بود.
- با رشد نيازها و وضع تکنيک ها، روشها و فرآيند هاي توسعه نرم افزار، مساله توليد يک بار، فروش چند بار از طريق ساخت بسته هاي نرم افزاري (Software Packages ) عام رواح پيدا کرد و توليد کنندگان، مصرفکننده را ملزم به استفاده از همان محصول ثابت مي کردند. مشتريان هم به دليل عدم تنوع در انتخاب ناچار به پذيرش اين واقعيت بودند.
- با بلوغ تکنيک هاي توسعه نرم افزار و افزايش سطح توقعات مشتريان، ديگر نمي شد محصول را بدون منطبق سازي مطرح کرد، اما تلاش مي شد اين منطبق سازي در حجم کم و يا در قالب نسخه هاي بعدي (Next Version ) حل و فصل شود.
در اين دوره با ساخت سيستمهايي نظير ERP تلاش شد همه فرآيند هاي سازمانها استاندارد و پياده سازي گردد تا يک محصول يا بخشي از آن بتواند نياز يک مشتري جديد را برآورده سازد، اما باز هم بحث Tailoring را براي منطبق سازي محدود سيستم با نياز هاي مشتري مطرح است و رايج. چنانچه مي بينيم متدولوژي هاي تحليل و طراحي سيستمها نيز به سمت روشهاي قابل انعطاف تري مانند متدولوژي هاي چابک (Agile) مانند روش برنامه سازي کرانه اي (XP) حرکت کرده اند که پذيرش تغيير از جانب مشتري را به عنوان يک اصل مي شناسند.
به عنوان يک توليد کننده نرم افزار، اين مساله که بايد براي هر مشتري منطبق سازي را انجام داد، گاهي مواقع آزار دهنده مي شود. در نظر گرفتن نظرات مشتريان مختلفدر يک محصول، بويژه مسائلي که هيچ استاندارد مشخص و رايجي در مورد آنها وجود ندارد، باعث مي شود محصول شما آنقدر بزرگ و حجيم شود که عملا کارايي آن از دست برود و براي مشتريان سخت گردد. نوشتن نسخه هاي مختلف از يک سيستم براي هر مشتري هم چنانچه با مديريت صحيح کد همراه نباشد، باعث مي شود که پشتيباني و به روز کردن هر کدام از محصولات سخت گردد و تست نرم افزار سخت تر.
البته، متخصصان امر ، راه هايي براي مديريت صحيح تغييرات و برآورده سازي نياز مشتريان مطرح مي کنند که برخي فقط در بخشهاي آکادميک و برخي در عمل و کاربرد، جواب خود را پس داده اند و مي توانند مورد استفاده قرار گيرند. اگر فرصت کنم در مورد روش مديريت اين گونه تغييرات ، منطبق سازي متعدد يک محصول با نيازهاي مختلف مشتريان، خواهم نوشت.
همين!