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