کدام تئوری در طراحی وب سایت و پورتال موثرتر است؟
صنعت وب دنیای عجیبی است. در کشور ما نیز “صنعت وب” تبدیل به یک واژه ی معنادار شده و مبالغ هنگفتی بر پایه و اساس آن در میان سازمان ها و شرکت ها جابجا می شود. جدا از چگونگی هزینه کرد در این سازمان ها، یک سوال همیشه برای فعالان این عرصه باقی مانده است و آن سوال این است: در یک همکاری دو جانبه ی اقتصادی، به عنوان یک پیمانکار، آنچه که به کارفرما تحویل می دهیم یک پروژه طراحی وب سایت باشد یا یک محصول؟ به بیان دیگر، نتیجه ی کدام یک بهتر و موثرتر است؟

 

در روزگاری نه چندان دور، دانش HTML پاسخگوی اجرای پروژه های طراحی وب سایت بود. پس از آن پروژه های انحصاری و متن بازی مانند نیوک، مامبو و سپس جوملا و وردپرس توانستند تلفیقی از محتوای پویا و ایستا را به کاربران هدیه کنند. در این میان نیز شرکت های معدودی در کشور به دنبال تولید محصول نرم افزاری با عناوین “سیستم مدیریت محتوا” یا “پورتال” رفتند که برخی بر پایه ی فریم ورک و معماری سیستم های متن باز بود و برخی ترجمه و توسعه ی ماژول و سرویس بر روی سیستم های موجود. با این حال همچنان ضعف اجرای پروژه حتی در قالب نرم افزارهای قوی، عاملی بازدارنده برای حرکت سازمان های بزرگ به سوی الکترونیکی کردن کسب و کار و فرآیندهایشان بود.
به اعتقاد نگارنده، عوامل موثر بر اجرای یک پروژه ی موفق در صنعت وب به ترتیب تجزیه و تحلیل فرآیندها و نیازمندی های کارفرما، تجربه و تعهد پیمانکار و کارفرما در حین اجرای پروژه، مدیریت پروژه و در نهایت محصول و بستر نرم افزاری است. قاطعانه بر این موضوع اصرار دارم که محصول نرم افزاری همیشه آخرین عامل اجرای یک پروژه ی قوی طراحی وب سایت و پورتال است. حال می خواهم دلایلم را با چند مثال شرح دهم:
1-      محصولی را تصور کنید که کار کردن با سرویس های محتوایی آن به قدری مشکل است که کارفرما را با مشکلات متعدد روبرو می کند. فرآیند انتشار سریع محتوا، موردی است که در اکثر سیستم های مدیریت محتوا مورد اشکال است. این مورد در سیستم مدیریت محتوای وردپرس بسیار عالی نهادینه شده است و نیاز نیست چندین صفحه برای رسیدن به ویرایشگر متن برای درج محتوا طی شود و در انتها کاربر با صفحه ای مواجه شود که فیلدهای غیرضرور بسیاری جهت پر کردن در خود دارد. از همه بدتر اینکه محصول، امکان حذف هیچ یک از فیلدهای غیرضرور به ازای هر پروژه را ندارد. در یک کلمه همه چیز عمومی و ثابت است و سفارشی نمی شود.
2-    محصولی را تصور کنید که کارفرما نمی تواند مدیران هر قسمت از وب سایت یا پورتال اش را به سادگی تعیین کند. کار کردن با حقوق دسترسی به هر سرویس باید به قدری ساده باشد که برای هربار تغییر آن نیازی به پاسخگویی و مشاوره پیمانکار نباشد. حال اگر کارفرما بخواهد یک سطح دسترسی ساده به همه کاربران بدهد و محصول توانایی اداره ی گروهی کاربران را نداشته باشد، تکلیف چیزی جز ویرایش تک تک کاربران و انجام موازی کاری نیست.
3-    و مثال آخر مصداق این جمله است: “درخواست شما امکان توسعه و اجرا ندارد.” پاسخی که بسیاری از کارفرمایان در مقابل درخواست توسعه قسمتی از سرویس ها و فرآیندها کسب می کنند و این همان ضعف محصول محوری و اجرای یک پروژه بر مبنای یک محصول نرم افزاری خاص است.
در مثال های ذکر شده، می توان درخواست های کارفرما را تحلیل کرد، آن ها را نیازسنجی کرد و در قالب پروژه های فرزند، به پروژه ی اصلی چسباند. اما اگر محصول مان توانایی توسعه نداشت و یا نیروی انسانی مان توانایی اجرای آن در بستر فوق را نداشت، به شکست یک پروژه نزدیک شده ایم. آنجاست که در صنعت وب دچار این دوگانگی می شویم که مگر محصولات نرم افزاری نیامده اند که یک پروژه ی موفق را تشکیل دهند؟
از ویژگی های دیگر پروژه محور بودن شرکت های نرم افزاری، تعهد در اجرای صحیح درخواست های کارفرماست. پروژه های کوچکی که به درستی تحلیل و پیاده سازی شده باشند، کارفرما را به محصول مطمئن تر خواهند کرد و در نتیجه کسب و کار پیمانکار نیز رشد خواهد کرد.
همیشه از خود سوال می کنم اگر نتوانیم یک درخواست سمت سرور را در محصول نرم افزاری مان، از حالت پیش فرض خود به یک درخواست ناهمگام (Ajax) تبدیل کنیم یا یک افکت زیبای jQuery را به قسمتی از قالب وب سایت مان دیکته کنیم، آیا این نمونه ای از دیکتاتوری و در نتیجه پایان کار شرکت و کسب و کارمان نیست؟