در ادامه نوشته قبل (اینجا) به بحث تاثیر ماهیت نرم افزار در رضایتمندی مشتریان خواهم پرداخت.
یکی از اصول اولیه ای که در همه کتابهای مهندسی نرم افزار مطرح می شود، تفاوت ماهوی تولید و محصول نرم افزاری با تولید و محصول سخت افزاری از جنبه هزینه های آن و پایداری محصول است. برای مثال در کتاب مرجع پرسمن دو نمودار زیر به خوبی نمایش دهنده تفاوت ماهوی محصول سخت افزاری و نرم افزاری هستند.
نمودار زیر مشخص کننده رفتار تیپ یک محصول سخت افزاری که در زمان تست اولیه و نهایتا در زمان فرسودگی تعداد خطا زیاد است اما در این بین تعداد خطا ها در یک حد تقریبا ثابت می ماند.
نمودار میزان خطا ها در محصول سخت افزاری
در حالیکه با توجه به فرسوده نشدن نرم افزار انتظار می رود میزان خطاها برای نرم افزار با توجه به زمان بالا نرود اما در عمل به دلیل تغییرات (چه در نیاز و چه در فنآوری) و اثرات جانبی آنها عملا یک نمودار همواره صعودی خواهیم داشت. مطابق نمودار زیر
نمودار ایده آل و واقعی خطا ها نسبت به زمان در محصول نرم افزاری
طبیعی است وقتی تغییر نیازی ایجاد شود، مجری (چه فرد و چه شرکت) نسبت به انجام ان تغییر نیاز ها اهتمام می ورزد (فرض می کنیم قراردادهای مالی مرتبط چه برای فروش و پشتیبانی به شکل کامل و سودمند بسته شده و همه هزینه های مرتبط با انجام این تغییرات به درستی پرداخت می شود).
در هنگام اجرای این تغییرات توسط مجری دو مساله پیش می آید، اول همان بحث تعداد خطاها است که باعث می شود مشتری ناراضی گردد و در نمودار بالا نمایش داده شد و دوم بحث تاثیر زمان بر افزایش ناراضایتی مشتری است. تاثیر زمان در نمودار زیر (که نمایش غیردقیقی از این اعلام نیاز و انجام آن است) آورده شده است.
نمودار تاثیر زمان بر نارضایتی مشتری
اگر دقت شود در این نمودار برای هر درخواست نیاز ۵ نقطه کلیدی وجود دارد:
نقطه A: زمانی است که یک کاربر استفاده کننده با یک مشکل (Bug) چه نرم افزاری و چه منطقی مواجه می شود و یا یک نیاز جدید پیدا می کند. از این مرحله به بعد مشتری یک نارضایتی از محصول پیدا می کند . این نارضایتی ادامه پیدا می کند تا در نقطه B آن را به نماینده (برای مثال کارشناس IT و یا مدیر مرتبط خود منتقل می کند.) این مرحله شیب افزایش نارضایتی افزایش پیدا می کند چرا که کاربر معتقد است این مشکل را گزارش کرده است. ممولا مدت زمانی طول می کشد تا نماینده با جمع بندی نیازهای کاربران، مطمئن شود که این نیاز واقعی است و با مجری تماس بگیرد تا این مشکل حل شود. از اینجا به بعد تا نقطه D که مشکل توسط مجری حل می شود و یا نیاز جدید پیاده سازی می شود شیب نارضایتی شتاب بیشتری می گیرد چرا که استدلال آن است که ما منتظریم. با برآورده سازی نیاز و تا زمانی که به مشتری اعلام شود که کار مورد نظر انجام شده است و او واقعا زمان گذاشته و تایید کند که چنین اتفاقی افتاده است نارضایتی همچنان در سازمان هست چون هنوز کاملا تایید نکرده اند.در زمان E به نظر همه چیز درست است. اما واقعیت آنجاست که میزان نارضایتی ناگهان صفر نمی شود و با یک شیب کاهش پیدا می کند. اگر مجری خوش شانس باشد تا زمان تعییر نیاز جدید این نارضایتی مشمول مرور زمان می شود و صفر می شود ولی همیشه چنین نیست بروز یک نیاز جدید باعث می شود عملا نارضایتی از محصول کاملا صفر نشود و با یک انباشتگی این سیکل مجددا تکرار شود. که نتیجه آن باعث می شود حجم این نارضایتی از محصول مرتبا در سازمان افزایش یابد تا زمانیکه سازمان به این نتیجه برسد که باید از محصول دیگری استفاده شود.
دقت شود نمودار فوق شامل رفتار عمومی در این زمینه است. اگر هر کاربر بتواند مستقیما با خود مجری تماس بگیرد و هر مجری مستقیما هر برآورده سازی را به کاربر نهایی تحویل دهد (مثلا مجری یا به صورت چابک در اختیار مشتری باشد و یا خود در داخل سازمان مشتری باشد) دو بخش از این چرخه حذف می شود که عملا در مورد پروژه های بزرگ و کار با سازمانها این اتفاق نمی افتد ( عملا باید برای هر تغییر نیازی یک تاییدیه گرفته شود و مجری نمی تواند با همه کاربران مستقیما در ارتباط باشد زیرا ارتباط مستقیم با هر کاربر و اعمال سلیقه های آنها باعث آشفتگی در طراحی سیستم می شود) از سوی دیگر هر چقدر تغییرات در نرم افزار کم باشد (در مورد نرم افزارهای کوچک شامل ابزارهای سودمند Utility و یا گجت ها Gadget ها عملا تغییر نیاز کمتر است و در مورد نرم افزارهای کاربردی و یا با تعداد کاربر بالا و حجم استفاده گسترده این تغییر نیازهای بیشتر است ) طبیعتا نارضایتی مشتری به شکل انباشته نمی شود و به صورت موردی حل می شود.
از سوی دیگر هر چقدر زمان از انتهای پروژه پیاده سازی سیستم سپری شود، هزینه (چه مالی و چه زمانی) برای اجرای تغییرات زیاد تر می شود. چرا که مجری از پروژه فاصله گرفته و مراجعه به کدهای قبلی برای رفع عیوب و تغییر نیازها برایش دشوارتر می شود و حتی اگر به سادگی هم بتواند کدی را تغییر دهد اعمال آن در سیستم مشتری و ایجاد یک هماهنگی با داده های قبلی کاری زمانبر است.. ( مراجعه کنید به نموار زیر مجددا از کتاب پرسمن)
نسبت هزینه تغییرات به چرخه حیات پروژه و نرم افزار
در نمودار فوق نمایش داده شده است که اگر هزینه انجام تغییرات در زمان تعریف پروژه X باشد، این هزینه در زمان توسعه نرم افزار ۱٫۵ الی ۶ برابر می شود و بعد از تحویل نرم افزار به مشتری ۶۰ الی ۱۰۰ می گردد.
با توجه به این مطلب است که به نظر من ما مشتری کاملا و مطلقا راضی از محصول نرم افزار نداریم. حتی اگر یک محصول کاملا مطابق با نیازهای مشتری و در قالب یک پروژه اختصاصی تولید گردد باز هم به مرور تغییر نیازهای مشتری در نرم افزار باعث بروز خطا ها و افزایش نارضایتی مشتری از این بابت می گردد(مطلب مرتبط را در اینجا بخوانید).
در این زمینه باید روی این نکات تاکید بکنم:
- همه متدولوژی های تولید و پشتیبانی نرم افزار برای آن آمده اند که تولید و نگهداری نرم افزار را کم هزینه تر بکنند. بنابراین ذکر این نکته ضروری است که اگر شما روش تولید متناسبی را در پیش گیرید و محصولی پویا و یا قابل توسعه و یا سازگار ایجاد کنید (نرم افزار خوب) این هزینه ها قطعا کاهش می یابد اما مطمئنا هیچگاه صفر نخواهد شد(اگر می شد، چه خوب می شد!).
- دقت شود روی بحث نارضایتی تاکید روی نارضایتی از محصول است. شما حتی اگر بهترین و کم خطاترین محصول را تولید کنید باز هم زمانی می رسد که به دلیل تغییرات تکنولوژی، قوانین و … آن محصول دیگر قابل استفاده نباشد (رجوع کنید به نوشته “نرم افزار ها می میرند”).
- نارضایتی از محصول لزوما به نارضایتی از مجری منجر نمی شود. ممکن است شما مجری خوبی باشید و با کمترین زمان و هزینه درخواست های مشتری را اجرا کنید. در این حین ممکن است مشتری از محصول شما ناراضی باشد (و حتی با تغییرات فنآوری یا قوانین روزی آن را کنار بگذارد) اما او از شما ناراضی نخواهد بود و ممکن است سفارش پروژه های جدید و یا خرید محصولات توسعه پیدا کرده را هم با شما داشته باشد.
- این بحث کاملا مستقل از شیوه و مختصات قرارداد های بین خریدار و فروشنده و یا کارفرما و پیمانکار است و فرض شده است مجری حتما مکلف به انجام تغییرات است و هزینه ها نیز کامل پرداخت می شود. در عمل گاهی ممکن است مجری توانمندی فنی برای انجام تغییرات را داشته باشد، اما عدم وجود رابطه همکاری باعث شود نسبت به انجام آنها مسؤولیتی نداشته باشد که در نهایت باعث انباشته شدن نارضایتی ها می شود.
- جنبه روانی نارضایتی ها و بحث هایی نظیر یک کلاغ چهل کلاغ هم در این بحث “نادیده” گرفته شده اند. پیش آمده است که کاربری ضعف خود را با مطرح کردن اینکه “نرم افزار مشکل دارد” پوشش داده و یا یک مشکل نرم افزار را بزرگنمایی می کند و به غلط آن را بر سر زبان ها می اندازد. پیش آمده که یک کاربر صرفا به دلیل مسائل غیر کاری (مثلا پسرخاله اش هم همین نرم افزار را دارد و یا نرم افزار کارش را زیاد کرده و یا قدرتش را کاسته) به شکل شایعه به مشکلات یک نرم افزار دامن می زند و … که اینها هم باعث افزایش نارضایتی عمومی از یک نرم افزار -با وجودیکه مشکلات صحت ندارد- می گردد.
- دامنه این بحث در مورد نرم افزارهای تجاری و کاربردی (Application) هاست. مطمئنا رفتار در سایر پروژه ها، مثلا پروژه های دانشگاهی، و یا سایر نرم افزار ها متفاوت است.طبیعتا من در مورد جایی صحبت می کنم که شما نرم افزار را برای برطرف کردن یک نیاز کاربردی ساخته اید و مشتری به عنوان خریدار استفاده کننده در طی یک مدت زمانی نامعین از آن استفاده می کند.
در پایان مجددا روی نتیجه این مطلب تاکید می کنم: شما هیچگاه مشتری مطلقا و کاملا راضی از محصول نرم افزاری ندارید.زمان تعیین کننده است و این نقش شما به عنوان مجری (پیاده ساز و پشتیبان) است که تعیین می کند مشتری از شما و محصولتان راضی باشد یا نه و اصلا همین بحث رضایت/نارضایتی نسبی از محصول است که بحث نسخه بندی (Version) را مطرح می کند و شرکتهای معتبر همواره در حال ارائه نسخه های جدیدی از نرم افزارهای قدیمی خود هستند.
در مطلب بعد به نقش مجری (فرد یا شرکت) در تعیین میزان رضایت مشتری از محصول نرم افزاری خواهم پرداخت، پس ادامه دارد…
همین!
آقای واحد،
از خواندن این مطلب شما بسیار استفاده کردم. اما یک نکته به نظرم اینجا برای من به عنوان یک مشتری مطرح است. موافقید که نرم افزار باید به روز آوری شود؟ مثلاً ویندوز نمیتوانست در ۹۸ بماند … موافقید که این به روز آوری بر اساس تحلیلهای جدید + فهرست آرزوها و خواسته های مشتریان موجود باید انجام شود؟ یعنی اگر هیچ مشتری هیچ خواسته ای نداشت، اگر ما هیچ به روز آوری بر اساس نیازهای و مسائل بازار انجام ندهیم، آهسته آهسته از بین میرویم؟
به نظرم اشکال همینجاست.
بسیاری از شرکتها اولاً اگر خواسته ای از مشتری نیامد، یا خواسته ساده بود، به جای یک آپدیت اساسی، کد را موضعی دستی به سر و گوشش میکشند و میگذرند. که این همانطور که شما بهتر از من میدانید، از بین میبرد.
اما خیلی خیلی کم دیده ام، صادقانه بگویم که ندیده ام که شرکتی در ایران، تحلیلهای به روزی از مشتریان و بازار داشته باشد.
اما در مقابل دیده ام که شرکتهای بسیار کوچک خارجی، یکی از کارهایشان این است که به مشتری به صورت دوره ای مراجعه میکنند، و نیازهایش را میپرسند، و برای تمام آنها به او یک تاریخ میدهند، با جریمه که اگر تامین نشد، یا به روشنی میگویند که این در برنامه نیست. اینجا چه میشود؟ شما بفرمائید.
در حالت نمودار شما هم،به نظرم مقیاس زمانی کمی غیر منصفانه است. فاصله اعلام به مجری تا جواب دادن (نه عملی کردن، بلکه فقط نشان دادن عکس العمل، ) در مثالهای زنده ای که دارم، سال بوده است. بله سال. و نقطه E که مربوط به یک باگ بوده است،هرگز نرسیده است.
البته قبول میکنم که ما هم خریدار خوبی نبوده ایم که چنین کلاهی سرمان رفته است.
خلاصه خواهشم این است که به موضوع از این منظر هم نگاه کنید که پس رسالت شرکت نرم افزاری در تحلیل های جدید و به روز کردن محصول قبل از آنکه حتی نیازی به وجود آید، کجا دیده میشود؟ آیا فقط شرت باید بر اساس نیازهای مشتری حرکت کند؟
باز هم از مطلب مفیدتان سپاسگزارم
@وفا
در این نوشته صرفا قصد داشتم به بحث ماهیت نرم افزار بپردازم و رفتار مجری را همانگونه که گفتم در نوشته بعد تحلیل خواهم کرد.بنابراین اگر اجازه بدهید پاسخ بخش اول نظر شما را موکول کنم به نوشته بعد.
اما در مورد نمودار زمانی، محور ها و زمانبندی ها اصلا معیار نیست. با توجه به اینکه برای روشن شدن بقیه بحث از نمودارهای کتاب آقای پرسمن استفاده کرده بودم، بهتر دیدم اینجا هم خودم یک نمودار تهیه کنم که خیلی سریع و دم دستی است.
بنابراین در محور افقی و عمودی شما می توانید مقیاس ها و فاصله ها را عوض کنید اما کلیت موضوع فرقی نمی کند. اتفاقا فاجعه کار در بین همکاران من در همان فاصله نقطه C و D است. چرا که در این فاصله شیب افزایش نارضایتی مشتری حداکثر است و اگر زمان در اینجا هدر برود، ممکن است آنقدر نارضایتی از یک باگ ساده زیاد شود که حتی گذر زمان و برخورد نکردن با باگ جدید هم این نارضایتی را آرام نکند.
مساله دیگر نوع باگ یا مشکل است. مشکلات ظاهری یا غیرساختاری و یا غیر ضروری طبیعی است که شیب افزایشی کمتری نسبت به مشکلات ساختاری و پایه ای دارند. شما اگر در منطق اصلی کاربرد اشتباهی کنید ممکن است نه به شکل خطی بلکه به شکل نمایی نارضایتی را افزایش دهید.
مجددا آن نوشته در وبلاگ را مورد تاکید قرار می دهم: نمودار نمایش دهنده رفتار تیپ است.
در مورد رسالت شرکتهای نرم افزاری هم در تحلیل بازار به موقع صحبت خواهم کرد. در این زمینه هم حق با شما است و هم حق با شما نیست! چرا بعدا توضیح خواهم داد.
مجددا تاکید می کنم که در این نوشته ها فعلا جنبه های داخلی تولید نرم افزار را می بینم. حقوق مشتریان مبحث بزرگی است که شاید فرصت شود و در این چند نوشته به آن اشاره کنم و شاید هم باید بگذاریم برای جایی که افرادی مانند جنابعالی با نگاه از بیرون به مشکلات نرم افزاری کشور نگاه کنند. چون برای منی که در حال کار هستم ، دیدن از بیرون بسیار دشوار است.
به هر حال ممنون که به این نوشته ها توجه می کنید.
همین!
خیلی خوشحالم که مطالب وبلاگ شما رو دنبال می کنم ، مطمئن هستم در آینده بیشتر به ارزش مطالبی که عنوان می کنید پی می برم.
چون مطالب چندین پست آخر شما پیوسته بود من اینجا یک نکته ای رو با اون خیلی درگیر شدم عنوان می کنم .
افرادی که به عنوان پشتیبان به محل مشتریان اعزام می شوند ، نقش بسزایی در معرفی نرم افزار به مشتری ایفا می کنند ولی بارها شاهد این موضوع بودم افراد پشتیبانی که به محل اعزام میشن کم سواد ترین بی تجربه ترین فرد اون مجموعه هستند وحتی اوضاع وقتی بدتر میشه که پرسنل در حال استخدام در دوره آزمایشی و شروع به کار به عنوان پشتیبان به محل اعزام می کنند.
پیشنهاد می کنم نقش پرسنل پشتیبانی و آموزش در معرفی یک نرم افزار یا همون ذهنیت خوب و بد رو به گفتگو بگذارید.
مطلب بسیار آموزنده ای بود. جالب بود برایم که ما نمودار میزان خطا ها در محصول سخت افزاری را با عنوان نمودار وان (مثل وان حمام است) در درس نگهداری و تعمیرات می شناختیم. اما در مورد نرم افزار به صورت تجربی به آن رسیده بودم و ضرب المثلی هم در این مورد داشتم که آقا بچه آرام خوابیده، بیدارش نکن گریه و زاری می کند و …
اما بازهم بر اساس تجربه می گویم که نارضایتی مشتری نباید روند صعودی داشته باشد. این روال معمولا ثابت است و اصولا باید کاهشی باشد.
@محمدی
در مورد پرسنل پشتیبانی پیشتر نوشته ام، اما باز هم اگر فرصتی و عمری باشد در این زمینه خواهم نوشت. علی الحساب ان نوشته قدیمی را ببینید:
http://weblog.radmanitd.com/index.php/archives/336
به هر حال خوشحالم که این نوشته ها ممکن است به درد شما بخورد.
@مجید آواژ
در مورد عدم صعودی بودن و یا حتی کاهشی بودن نارضایتی مشتری، ایده آل همین است. اما در واقعیت به دلیل تغییر نیازها اتفاق دیگری می افتد. و در مورد بهترین نرم افزارها هم وقتی شرایط محیطی، قوانین، آدمها، فنآوری و … عوض شود، روند نارضایتی از آن نرم افزار تازه شروع می شود . چون به قول شما آن بچه خوابیده را بیدار کرده اید!
همین!
[...] padding-top: 1px; } #bottomcontainerBox .buttons { float: left; margin: 4px 4px 4px 4px; } در بخش دوم این سلسله مطالب اشاره کردم که یک محصول نرم افزاری در طی [...]