متدلوژی های موفق طراحی سایت (قسمت سوم)
ادامه از قسمت دوم
استفاده از روش FDD برای تیمهای کوچک
یکی از بزرگترین مشکلات متدلوژی های مبتنی بر AGILE اینست که آنها را نمی توان به سادگی تغییر مقیاس داد. اما برای ما دانستن این نکته که با اجرا FDD برای بیزینس های کوچک بازهم می توان از مزایای آن استفاده کرد یا نه ، بسیار مهم است . اصلی وجود دارد که می گوید با کاهش سایز تیم سازنده ، تاثیر متدلوژی نیز کاهش می یابد و این در مورد FDD نیز صدق می کند . اگر چه خود من توانستم با موفقیت این روش را بر روی یک تیم 4 نفره ( شامل مدیر پروژه ، طراح و برنامه نویس ) در طول 3 هفته آزمایش کنم و نتیجه این بود که با کاهش تعداد نفرات تیم ، FDD هنوز بخوبی کار می کرد.
دو جنبه FDD که در تیمهای کوچک بسیار مهمند عبارتند از :
1. تعریف پروژه بر اساس ویژگی ها
2. نظارت بر پروژه بر اساس ویژگی ها
ساده به نظر می رسد ، اما همین سادگی FDD است که آن را موثر می سازد. در صورتیکه نتوانید یک پروژه را بر اساس ویژگیهایش تعریف کنید ، جلو رفتن پروژه بر اساس شانس و اقبال و نامنظم خواهد بود . معمولا این مشکل ، خود را هنگام تحویل پروژه نشان می دهد . برای تیمهای کوچک رفع چنین مشکلاتی کار سختی نیست ، اگرچه انجام چند روز کار اضافه بر روی پروژه ای کوچک نشان از درصد زیادی خطاست که می تواند حاشیه سود پروژه را بشدت تنزل دهد .
مانند خیلی چیزهای دیگر در زندگی ، گذاشتن سنگ بنای اولیه متدلوژی ساخت سایت بصورت صحیح ، بهترین راه پیشبرد آن است . بکاربردن تکنیک تعریف پروژه بصورت ویژگیهای مورد نیاز کارفرما تاثیرات مطلوبی چه بر روی پروژه های بزرگ و چه بر روی پروژه های کوچک می گذارد.
FDD برای ساختن سایت
تاریخ اولین استفاده از FDD برای ساختن سایت به سال 2000 باز می گردد . من برای بهبود و افزایش راندمان طیف وسیعی از پروژه های ساخت سایت ( از پروژه های 2 هفته ای تا 6 ماهه ) از این روش استفاده کردم . این متد را باید برای پوشش مواردی که FDD در مورد آنها ساکت است کمی دستکاری می کردم . مراحل زیر نمای کلی از FDD را که می تواند به شما در ساخت سایت بصورت موثری یاری دهد ، شرح می دهد .
نمای کلی پروژه
اگرچه در میان 5 پروسه مطروحه ، این مورد به صراحت عنوان نشد اما ، تمامی پروژه های مبتنی بر FDD باید هدف واضحی داشته باشند . این موضوع چیزی فراتر از بیان یک جمله ساده برای توضیح پروژه و هدف نهایی آن است
هدف تیم
این موضوع میتواند بنظر زائد برای یک پروژه بنظر برسد . هدف تیم باید خیلی واضح باشد ، اگرچه برای کارفرما این امر واضح است اما ممکن است برای سازندگان اینطور نباشد . اولین مرحله نوشتن یک پاراگراف و توضیح فلسفه وجودی تیم است . البته گفتن این موضوع از انجامش آسانتر است ، برای کارفرما هایی که پروژه های کوچک می خواهند ، روشن نبودن اهداف تیم می تواند دردسرساز شود . این مرحله مقدمه اصلی برای مرحله بعد یعنی اهداف پروژه است .
مقصود پروژه
بار دیگر ، این موضوع بدیهی بنظر می رسد اما باز هم می گویم که می تواند کار سختی باشد. بسیاری کارفرما ها، تفکرات ، تمایلات ، انتظارات و موارد مطلوب متفاوتی در مورد یک وب سایت دلخواه دارند . در واقعیت کاری را باید به عنوان یک پروژه تعریف کرد که برای تمامی اعضای تیم به دقت و شفافیت توضیح داده شود و اعضاء با فلسفه اصلی پروژه موافق باشند. قصد از پروژه باید روشن ، مختصر و قابل اندازه گیری باشد و نتایج آن را از لحاظ بیزینس بتوان سنجید.
هدف از پروژه
اهداف مشخص پروژه باید به روشنی مشخص شود . در صورت ممکن این اهداف باید بصورت لیست مشخص و نوشته شود ; در این مرحله همکاری و اخذ توافق از سوی کارفرما بسیار مهم است .
به این مثال دقت کنید ، که اهداف تعیین شده برای یک تولید کننده قطعات اتوموبیل بنام اختصاری ACME را بیان می کند :
اهداف تعیین شده برای بازسازی وب سایت عبارتند از :
• ایجاد تصوری واحد از نام تجاری ACME در تمام دنیا
• برپایی یک وب سایت تجاری با خصوصیاتی از جمله سادگی ، هوشمندانه بودن ، حرفه ای ، پیشرفته ، منتقل کننده حس اطمینان ، و از همه مهمتر user friendly .
• حصول اطمینان از اینکه طراحی وب سایت با نسخه 10 راهنمای ابتدایی وب سایت گروه ACME مطابقت داشته باشد.
• استفاده از وب سایت به عنوان ابزار مکان یابی برای مشخص کردن مکان ACMO به عنوان یک تولید کننده قطعات اتوموبیل جهانی و فن آوری محور .
• نصب قابلیت آپدیت در هر مکان توسط سیستم مدیریت محتوی (CMS)
محدوده پروژه
فهمیدن وتعریف محدودیت یک پروژه کاری بسیار دشوار است . کارفرماها توقعات فراوانی دارند و معمولا انتظار چیزهای کامل و بی نقصی را دارند . مواظب باشید دچار سندروم سینک ظرفشویی نشوید .
نکته اصلی رسیدن به این تعریف است که چه مواردی داخل پروژه و چه مواردی خارج از آن است. من به شما پیشنهاد می کنم که از تکنیکی قدیمی که به راحتی موارد داخل و خارج پروژه را تعریف می کند استفاده کنید . این روش ابزار بسیار مناسبی برای کارفرماهاست که تمامی مواردی را که جزو پروژه هستند ، بشناسند . برای آشنایی با این ابزار دوباره به سراغ وب سایت شرکت ACME می رویم :
| داخل پروژه | خارج از پروژه |
|
بازسازی و طراحی وب سایت شرکت ACME مطابق با ورژن 1.0 راهنمای پایه وب سایت گروه ACME . بازسازی بانک اطلاعاتی محصولات انتقال اطلاعات به بانک اطلاعاتی جدید محصولات تهیه یک سیستم مدیر محتوی رده بیزینس (CMS) آموزش استفاده از CMS به افراد |
ایجاد قابلیت لیست کردن مشتریان ( این قابلیت در سایت فعلی موجود است ) ایجاد محتوی مدیریت محتوی یافتن منابع و آماده سازی محتوی گرافیکی اضافه کردن محتوی به CMS برای راه اندازی سایت |
| مواردی که باید در مورد وجودشان در پروژه تصمیم گرفت هاستینگ سایت و CMS حمایت مداوم و مدیریت CMS |
بازار هدف
بار دیگر ، موضوع مهمی در میان است . سایت های زیادی بدون توجه کافی به بینندگان هدف ساخته می شوند. گفتن اینکه یک سایت بر اساس نیاز کارفرما ایجاد شده کافی نیست . بلکه ما باید جمعیت شناسی مشتریان کارفرما را بخوبی بدانیم و اگر گروه خاصی از آنان را هدف قرار داده ایم بخوبی این گروه را رصد کنیم .
در عمل ، بیشتر وب سایت ها گروه های متفاوتی را به عنوان گروه هدف قرار می دهند ، در این شرایط راه حل مناسب رده بندی این گروه ها به اولویت های اول و دوم و سوم و ... است .
محتوی
مهمترین تفاوت تولید نرم افزارهای سنتی و تولید وب سایت ، طبیعت محتوی است . بیشتر وب سایت ها باید مقادیر زیادی محتوی ارائه دهند . ممکن است وب سایت بصورت اپلیکیشن و یا سیستم فرامتن باشد . بیشتر پروژه ها ترکیبی از این دو است که در این صورت هردو جنبه باید مورد بررسی قرار گیرد . برای پروژه هایی با مقادیر عظیمی اطلاعات ، معماری اطلاعات و نحوه چینش آن نقش بسیار مهمی در موفقیت وب سایت ایجاد می کند.
معماری اطلاعات
در ساده ترین فرم خود ، معمار اطلاعات را می توان به شکل سایت مپ دید . معماری اطلاعات را می توان ساختار منطقی محتوی برای رسیدن به اهداف وب سایت تعریف کرد. اگرچه کار سرراستی بنظر می رسد اما نباید دست کم گرفته شود.
یک وب سایت با ساختار منسجم برای مراجعه کنندگان قابل فهم و برای مدیریت کنندگان بسادگی قابل نگهداری است. مثالی از یک سایت با ساختار اطلاعاتی نامناسب ، سایتی است که مراجعه کنندگان برای دریافت اطلاعات مورد نیاز مجبور به استفاده از سرچ باکس هستند.
طراحی اطلاعات
امروزه بیشتر مردم مفهوم سایت مپ را بخوبی می دانند و به راحتی می توانند سایت مپی مناسب بسازند. مرحله بعدی که بسیار پیچیده تر است ، مربوط به نحوه چینش اطلاعات روی صفحه است که به آن طراحی اطلاعات گویند. روند فعلی طراحی اطلاعات بصورت زیر است : ****( بسیار مهم : اطلاعات این مقاله مربوط به چند سال قبل است ، با دقت استفاده شود)****
عملکرد
حالا زمان ایفای نقش خصوصیات است و جایی که جنبه کاربردی وب سایت خود را نشان می دهد . کلید اصلی این مرحله تقسیم پروژه به قطعات کوچکی است که قابل تعریف برای کارفرما است و این قطعات باید در بازه زمانی بین 2 ساعت یا 2 هفته قابل انجام باشد.
خصوصیات قابل تعریف برای وب سایت ACME ( که هیچ کدام بیش از 2 هفته زمان نمی برند ) عبارتند از :
• امکانات اشتراکی
• قابلیت جستجو توزیع کنندگان
• قابلیت جستجو محصولات
• فرم بازخورد
مدیریت پروژه
بخش جدایی ناپذیر FDD گزارش هفتگی آن است ، که من آن را برای پروژه های کوچکتر بهبود بخشیدم . گزارش هفتگی پروژه های بزرگ مبتنی بر FDD ، شامل ویژگیهای استارت خورده ، ویژگیهای استارت نخورده ، ویژگیهای در حال پیاده سازی ، پایان یافته و تاخیر خورده است . با این اطلاعات می توان یک دیاگرام " درصد پیشرفت " با دقت بالا رسم کرد.
در پروژه های کوچک معمولا نیاز به چنین جزییاتی نیست . اگرچه پیگیری پیشرفت پروژه و اطلاع رسانی آن به کارفرما بطور منطم بسیار مهم است . پیشنهاد می کنم از دو روش زیر استفاده کنید .
بسته روزانه
بسته روزانه عبارتند از جلسه روزانه با تیم . این موضوع در تمامی متدلوژی های مبتنی بر AGILE معمول است ، در متد Scrum به آن اسکرام روزانه و یا Stand up meeting می گویند.
در این جلسه کوتاه ، هرکدام از اعضا به کارهای روز گذشته اشاره کرده و برنامه خود برای روز جاری را شرح می دهد. اهداف این جلسه عبارتند از :
- اطمینان از اینکه هیچ کس از برنامه عقب نیست
- اطمینان از اینکه اعضاء از کارهای جاری دیگران در تیم باخبر شوند
- اطمینان یافتن از مشکلات و حل آنها به سرعت
- کمک به افزایش همکاری بین اعضاء
از دید مدیریت پروژه ، بسته روزانه ابزار قدرتمندی برای قرار دادن تیم در مسیر درست است .وقتی افراد قول می دهند کاری را انجام دهند و می دانند که فردا از انجام شدن یا نشدن قول در مقابل دیگران سوال می شوند ، حس مسوولیتشان تحریک می شود. بسته روزانه همچنین باعث می شود اعضاء دو بار در مورد قول هایشان فکر کنند و همچنین این جلسات تاثیر اجتماعی قوی بر روی اعضاء می گذارد که منتج به جهش در کارگروهی تیم می شود.
گزارشهای پیشرفت کار
این گزارش ها بر اساس پیشرفت های هفتگی بنا نهاده شده. این کار دلایل زیادی دارد ، اولین آن اینست که مدیر پروژه می تواند از سطحی بالاتر وضعیت پروژه را زیر نظر داشته باشد . لازم نیست این گزارش ها خیلی پیچیده و جامع باشد ; فقط کافیست حاوی کارهای انجام شده و مشکلات بوجود آمده باشد. من از قالب زیر استفاده می کنم که ثابت کرده بسیار مفید است .
دستاوردها
چه کارهایی در هفته گذشته کامل شده ؟ این قسمت حسی از پیشرفت و رضایت ایجاد می کند.
کارهای معلق
این تکنیک به انجام کارها کمک شایانی می کند . غالبا کارهای معلق چیزهایی است که کارفرما باید تحویل دهد . با نوشتن این موضوع ، شما به وضوح اعلام می کنید که چه کسی مسوول تاخیر تکمیل آن است.
پیش فرض ها
کلمات از بیان شدت اهمیت پیش فرضهایی که شما اعلام می کنید قاصر است. اگر این پیش فرضها به وضوح اعلام نشوند میتواند شما را دچار دردسر بزرگی کند. برای مثال ، یک برنامه نویس ممکن است فرض کند که اطلاعات ارائه شده بدلیل سادگی ورود به صورت جدولی است اما کارفرما بی خبر از همه جا ، اطلاعات را بصورت فایل ورد و یا حتی بدتر بصورت گرافیکی ارائه دهد ! تمام پیش فرض هایتان را به وضوح مکتوب کنید.
مشکلات
تمام پروژه ها دچار مشکل می شوند که باید بصورت گزارش مکتوب ثبت شوند.
اقدامات
هرچه پروژه جلوتر میرود ، مشکلات پیش آمده حل می شوند . فکر مناسبی است که این اقدامات مکتوب شوند که هرگاه در طول پروژه سوالی پیش آمد شما بتوانید برگردید و گزارش مشکلات رخ داده و اقدامات مربوطه را مشاهده کنید . این کار مخصوصا برای تعامل با کارفرماهایی که عادت به تغییر عقیده دارند بسیار کارامد است.
وب سایت پروژه
این مرحله بخش بزرگی از پروژه های مبتنی بر FDD را شامل می شود و KMS (Knowledge Management System) نامیده می شود. تمامی اطلاعات پروژه مانند مستندات ، گزارش جلسات ، گزارش های پیشرفت و غیره باید در مکانی آن لاین ضبط و نگهداری شود که هم اعضاء تیم و هم مشتری بصورت آنی به آن دسترسی داشته باشد.این کار به ثبات تمامی اطلاعات در مکانی یکسان کمک شایانی می کند.
خلاصه
معجزه ای در کار نیست !
استفاده از FDD برای پاسخ گویی به تمامی نیازهای سازندگان سایت پیشرفت بسیار خوبیست، اما این متد هنوز پاسخ کامل و بی نقصی نیست . موضوعاتی مانند جمع آوری نیازمندی ها ، طراحی بصری ، آزمایش و استقرار پروژه با اینکه برای هر پروژه ای ضروری است هنوز تحت پوشش قرار نگرفته ، اما در نبود متدلوژی های قابل اعتماد ، داشتن روشی مانند FDD که با اینکه کامل نیست اما مزایای فوق العاده ای دارد ، قدمی بزرگ رو به جلوست.
