متدلوژی های موفق طراحی سایت (قسمت اول)
طرح مسئله
طراحی و توسعه وب سایت به عنوان یک صنعت قدمتی 20 ساله دارد ، بنابراین به نسبت صنایعی با قدمت بیش از چند صد سال کودکی نوپا محسوب میشود اما این بدان معنی نیست که اصول موفقیت برای آن تدوین نشده باشد.
وب سایتهایی را در نظر بگیرید که تقریبا هر روز برای تامین خواسته های مشتریان مجبور به تغییر میشوند و همچنان جوابگوی کارفرماها نیستند و این موضوع نشانه آن است که برای سازندگان سایت ، مشتریان غیر قابل پیش بینی هستند و نیازهایشان ثبات لازمه را ندارند و این کل بیزینس طراحی سایت را تهدید میکند.
برای فائق آمدن بر این مشکلات تکراری و هرروزه نیاز به استانداردهایی قابل اتکا داریم که ما را در این راه یاری کند ، اما پیدا کردن چنین متولوژی برای نیازهای متغیر مشتریان بسیار سخت است البته این خبر خوب بود خبر بد این است که تطابق این استاندارد با شرایط مارکت واقعی چند پله سخت تر است.
این مقاله سعی دارد جای خالی چنین استانداردهایی را پر کند که نتیجه آن تطابق متدولوژی های طراحی سایت با نیازهای امروز طراحی سایت است.
علائم بیماری
چندین فاکتور همزمان باعث میشوند که تیم ساخت وب سایت برای رسیدن به اهداف مجبور به تغییر مسیر شوند.
اولین ومهمترین فاکتور گذشت زمان است ، نمیتوان علت کلی برای این امر ارائه کرد زیرا در هر پروژه ای علل آن متفاوت است
اما بیشتر اوقات باعث و بانی این امر تغییر نظر کارفرماست ، بعضی اوقات نیز سازنذگان سایت نیازها و نظرات کارفرما را اشتباه تفسیر میکنند و گاهی اوقات نیز علت دست کم گرفتن کار لازم برای پایان پروژه است . گذشته از دلیل این امر ، نتیجه پایانی همیشه یکیست : افزایش هزینه های ملموس و غیر ملموس پروژه از جمله زمان و اعصاب سازندگان بدون اینکه کارفرما پرداختی خود را افزایش دهد و همچنین تاثیری بدی که این تاخیر بر روی زمان بندی پروژه های در صف میگذارد.
هرچقدر این اتفاق بیشتر بیوفتد اوضاع بدتر میشود و در نهایت در مخمصه ای خواهیم افتاد که تمام پروژه ها با ریسک بالا مواجه میشوند و معمولا دچار سندروم سینک ظرفشویی میشوند ( تغییر پی در پی و بی نتیجه پروژه ها پس از شروع ) و به پایین آمدن روحیه افراد منتج شده و برنامه ریزی و زمان بندی را نا ممکن میسازد.
راه حل ساده است : ما به راهکاری بهتر نیاز داریم که امتحان خود را در زمینه تامین نیازهای کارفرما با بودجه و زمان منطقی پس داده باشد این راهکار باید منطبق بر فرهنگ کارکنان سازمان باشد .
ما به یک وب متدولوژی نیازمندیم
قبول کنید ، چکش کاری کنید یا یکی از اول بسازید
هنگام اتخاذ یک استاندارد برای انجام پروژه ، سه انتخاب پیش روی ماست :
- خود را با متدی طراحی شده تطبیق دهیم
- متدی را با شرایط خود بومی کنیم
- یک متد مناسب برای خود ایجاد کنیم
تیم های سازنده سایت براساس اتخاذ تصمیم از بین گزینه های بالا تقسیم بندی میشوند ، بعضی معتقدند باید بر اساس اصول خود روشی کاملا انحصاری بوجود آورند ، بعضی دیگر به این کار به چشم اختراع دوباره چرخ می نگرند. بدیهی است که برای انخاب گزینه مناسب احتیاج به نیازسنجی دقیق است. ( کلا در نظر داشته باشید بدلیل جوان بودن این صنعت تعداد متدولوژی های موجود بسیار اندک است )
معیارهای ارزیابی
برای شروع بررسی متدهای موجود ، در درجه اول به سراغ معیارهای انتخاب آنها میرویم.
پیچیدگی
راه حل چیزی بیش از یک دستورالعمل ساده و کوتاه است اما از طرف دیگر اگر بیش از حد هم مفصل و سنگین باشد کارایی خود را ازدست میدهد. ما به متدی نیاز داریم که هم به سادگی فهمیده شود – به طوری که هم کارکنان و هم کارفرمایان بتوانند آن را درک کنند – و از طرفی نیز بتواند با عمق کافی نیازهای پیچیده سازندگان وب سایت را پاسخگو باشد.
اندازه
امروزه ترغیب مردم به خواندن متون خشک و طولانی بسیار مشکل و حتی غیرممکن است بنابراین متدهای طولانی و پر از جزییات غیرضروری جایی جز بایگانی نخواهند داشت . مثلا اگر شما دستورالعملی 100 صفحه ای با چکیده ای 10 صفحه ای داشته باشید مطمئنن مردم به سراغ چکیده آن خواهند رفت.
هزینه
هر چیزی که مستلزم صرف هزینه مادی باشد باید به دقت صرفه جویی شود . هزینه کمتر ، احساس بهتر.
ریسک
چیزی بدتر از یک متدولوژی اشتباه وجود ندارد . در صورت اجرا یک استاندارد غلط ، متقائد کردن مردم به اجرای متدی دیگر بسیار مشکل خواهد بود.
عملی بودن
راه حل باید ملموس و عملی باشد ، نه صرفا دستوراتی تئوری و غیرقابل اجراء . متدی قابل اتکا است که در دنیای واقعی و شرایط بازار امتحان خود را پس داده باشد ، البته بیشتر از یک بار.
متدولوژی های بررسی شده
فرایند یکپارچه منطقی (RUP)
من به عنوان یک تحلیلگر دوبار در جلسات توجیحیrup شرکت کردم و هردوبار بعد از جلسه احساس کردم گیج تر از قبل شده ام همچنین چندین بار با کسانی که از این روش استفاده کرده بودند در باره نقاط قوت آن بحث کرده ام . قلمرو آر یو پی بسیار گسترده است و تقریبا شامل همه چیز در پروسه طراحی نرم افزار میشود . من به تازگی در کنفرانسی با حضور "فیلیپ کروخن" یکی از رهبران دنیای آر یو پی شرکت کردم ، از نظر ایشان مشکل اصلی اینست که مردم سعی میکنند تمامی این روش را به دقت و با رعایت تک تک دستورالعمل هایش انجام دهند . این دقیقا نکته ایست که یکی از دوستان خبره من در این زمینه به آن شاره میکند . آر یو پی بسیار مفصل و پیچیده است و نصیحت من اینست که فقط خود را درگیر قسمتهایی از آن کنید که بدرد بیزینس شما میخورد نه همه آن .
به هر حال از نظر تیم ما ، آر یو پی دارای خصوصیات زیر است :
آر یو پی ، بزرگ مشکل و پیچیده است ، در حالیکه تیم شما محدود است . به عنوان مثال بعضی از اعضای تیمتان هنوز در مراحل اولیه یادگیری اصول طراحی نرم افزار هستند و آموزش آر یو پی به آنان بشدت مشکل است .
چون آر یو پی متدی جامع است ، برای پیدا کردن قسمت هایی از آن که مربوط به نیازها و شرایط شما میباشد نیاز به تحقیق عمیق در مورد آن دارید و البته پس از آن باید مقدار زیادی سعی و خطا داشته باشید.
قیمت ابزار های مورد نیاز برای پیاده کردن آر یو پی بالاست (rational rose, requisite pro…etc)
در مجموع اجرا آر یو پی و یا حتی قسمتی از آن متضمن پذیرش پیچیدگی های احتمالی ، سختی ، صرف زمان فراوان و هزینه های جانبی زیاد است که احتمال شکست پروژه را افزایش می دهد.
Process mentor
تیم ما به تازگی یک جلسه توجیحی با مسوولان و طراحان متد پروسس منتور داشت . این متد از آر یو پی جمع و جور تر بود ، و طبیعتا کارکردن با آن آسانتر . در حقیقت پروسس منتور ، وب سایتی با یک سری مراحل ، فرم ها و قالب هاست که برای اجراء یک پروژه طراحی شده است . برای تیم ما ، کار کردن با پروسس منتور آسانتر و کم دردسر تر از آر یو پی است اما هنوز رضایت بخش نیست . برخلاف آر یو پی ، پروسس منتور مشکل عمده ای ندارد اما گزینه مناسبی هم بنظر نمی رسد.
متدلوژی های غیر رسمی
تیم ما ترتیب مصاحبه های زیادی با سازنده های حرفه ای وب سایت را که هرکدام تجربه متدهای من دراوردی و ابتکاری مخصوص به بیزینس خود را تجربه کرده اند ترتیب داد. در مصاحبه هایی که با آنها انجام شد به بحث پیرامون تجربیاتشان ، کارهایی که انجام داده اند ، روش هایی که میپسندند و آنهایی که دوباره بکار خواهند برد پرداختیم . تکنیک های مفیدی نیز در این میانه پیدا کردیم اما در مجموع به این نتیجه رسیدیم که نمیتوان از روش های غیر منسجم و پراکنده ، استانداردی کلی بدست آورد که برای سایر سازمانها نیز بکار رود.
چرا متدلوژی های قدیمی دیگر کارساز نیست ؟
در زمینه متدلوژی ، تعداد زیادی شرکت و سازمان وجود دارند که سعی دارند راه حل ها و ابزار مکمل آن را به شما ارائه کنند اما چیزی که نیاز ما را به عنوان سازندگان وب سایت برطرف کند بین آنها نیست دلیل اصل آن هم اینست که این متد ها بخوبی با ساخت وب سایت منطبق نیستند. در مقام مقایسه با ساختن نرم افزارهای سنتی ، تایم فریم های ساختن وب سایت کوتاهتر ، تجربه افراد تیم سازنده بشدت متفاوت ، دید کارفرما از امکان پذیر بودن خواسته هایش بسیار کم ، سرعت تغییر تکنیک ها بسیار بالا و وابستگی نمایش سایت به مرورگر به طرز ناراحت کننده ای بالاست . نمیتوان گفت که این عوامل در ساختار تولید نرم افزار های سنتی وجود ندارد اما شدت آن در طراحی و ساخت وب سایت به نسبت نرم افزارهای سنتی بسیار بالاست. نقطه ضعف دیگر متدلوژی های سنتی اینست که به جنبه " نرم " ساخت نرم افزار کمتر توحه شده است . نتایج یک تحقیق در سال 2005 در مورد مهمترین عوامل موفقیت تیمهای ساخت نرم افزار ، نشان میدهد که از 17 فاکتور بررسی شده ، قابلیت اطمینان به عنوان مهمترین و مهارت تکنیکی کم اهمیت ترین عامل موفقیت این تیمهاست . اما هیچ کجای آر یو پی شما نمیتوانید پروسه ای برای افزایش قابلیت اطمینان محصول و تیم سازنده آن پیدا کنید و این موضوع در مورد سایر مهارت های نرم این بیزینس نیز که تاثیر فراوانی بر روی موفقیت سازمان دارد هم صدق می کند. خلاصه اینکه نمیتوان با تطبیق یکی از متدلوژی های سنتی راه حل مناسبی برای بیزینس ساخت وب سایت پیدا کرد ، خب پس بیایید یکی بسازیم.
ادامه مقاله قسمت دوم
