در دوران دانشجويي و حتی قبل از دانشجویی برای من خیلی پیش آمد که برای کسی برنامه بنویسم و پروژه نرم افزاری انجام بدم. بعضی هایش را قبول کردم و برخی را به علت هایی رد کردم. اوایل که جوگیر شده بودم و فکر میکردم خیلی برنامه نویسم، اگر هر پروژه ای به من واگذار میشد، نه نمی گفتم. خوشبختانه آن اوایل به جز یک برنامه، پیشنهاد دیگری به من نشد! به هر حال، در این اواخر رویه ای را پیش گرفتم در پروژه گرفتن و پروژه انجام دادن، که فکر میکنم رویه درستی است و از آن نتیجه های خوبی هم گرفتم. اگر دانشجو هستید و مثل من کم تجربه، حتماً قبل از گرفتن پروژه مسائلی که در این مطلب ذکر کردم را در نظر داشته باشید.
پروژه را قبول کنيم يا خير!
قبل از اينکه جواب اين سئوال را بدهيد، بايد پروژه اي که قرار است انجام دهيد را بفهميد. براي اين کار هم بايد به صورت حضوري با کارفرما ملاقات کنيد و اگر ملاقات حضوري در دسترس نيست، بوسيله تلفن با او صحبت کنيد. سئوالات و ابهامتان را در مورد پروژه از کارفرما بپرسيد. سعي کنيد تمام سئوال هايتان را از قبل در يک برگه بنويسيد تا هنگام صحبت با کارفرما سئوالي را فراموش نکنيد، چون معمولاً کارفرما را کمتر در طول انجام پروژه ملاقات مي کنيد. بعضي از کارفرمايان عادت دارند که از جواب دادن به سئوالات شما فرار کنند و با گفتن جمله اي شبيه به “ببينيد من فقط ميخواهم اين پروژه کار من را راه بيندازد و فلان کار را به خوبي انجام دهد” و از اين دست جمله ها، سر و ته صحبت را به هم بياورند. شما بايد بتوانيد هر اطلاعاتي که لازم داريد از زير زبان کارفرما بيرون بکشيد. اين يک مهارت است. خيلي وقت ها کارفرمايان شما از سيستم هاي کامپيوتري چيزي نمي دانند و نبايد تعجب کنيد که حتي دستشان به ماوس هم نخورده باشد! اگر کاربر سيستم شما همان کارفرما باشد که کارتان خيلي سخت خواهد بود. در غير اين صورت حتماً بعد از صحبت با کارفرما با کاربراني که قرار است با سيستم شما کار کنند نيز صحبت کنيد و از سطح آشنايي با کامپيوتر و سواد آن ها اطلاع پيدا کنيد. آشنايي با کاربران سيستم، ديد شما را بازتر خواهد کرد.
امکان سنجي کنيد
بعد از اينکه فهميديد کارفرما واقعاً چه مي خواهد، امکان سنجي کنيد که آيا مي توانيد با دانش خود و ابزارهاي موجود اين پروژه را انجام دهيد يا خير. به هر حال خودتان بهتر مي دانيد چه توانايي هايي داريد و با چه ابزارهايي آشنايي داريد. اگر پروژه اي فقط با يک ابزار خاص بايد انجام شود و شما کار با آن ابزار را بلد نيستيد، خيلي راحت پروژه را قبول نکنيد. هرگز به اميد اينکه طي انجام پروژه، کار با ابزاري را ياد خواهيد گرفت، پروژه اي را قبول نکنيد. فاکتورهای بسیار مهم دیگری که باید تخمین بزنید و در نظر بگیرید، زمان و هزینه پروژه هستد. معمولاً زمان تحویل را کارفرما تعیین می کند، اگر حتی یک درصد هم امکان می دهید که این زمان برای انجام چنین پروژه ای کم است، پروژه را قبول نکنید یا وقت بیشتری از کارفرما بخواهید. اگر زمان تحویل دست خودتان است، زمانی که تخمین می زنید را دو برابر کنید و در قرارداد ذکر کنید. دستمزد انجام پروژه معمولاً دست شما نسیت و کارفرما آنقدر چانه زنی می کند که شما را از رو خواهد برد. اگر پول برایتان مهم نیست و فقط برای کسب تجربه پروژه انجام می دهید که هیچ، اما اگر دستمزدتان برایتان مهم است حتماً قیمت معقولی را بر اساس حجم کار و زمانی که از شما خواهد گرفت، بدهید. این قیمت می تواند تحت تاثیر اعتبارتلن نیز قرار گیرد. به هر حال من خودم هنوز به فرمول مشخصی برای قیمت دادن نرسیدم.
حتماً قرارداد ببنديد
هر چقدر هم پروژه مورد نظر کوچک باشد، شما بايد با طرف مقابل قرارداد محکمي ببنديد و حتماً امضا و احتمالاً مهر کارفرما را زير آن قرارداد داشته باشيد. حتماً فاکتور زمان و استثناهايي که ممکن است در طول انجام پروژه پيش بيايد را در بندهاي قرارداد جاي دهيد. هزينه انجام پروژه را به صراحت در قرارداد ذکر کنيد و بندي قرار دهيد که مثلاً 50 درصد هزينه را کارفرما در طي انجام پروژه پرداخت کند و بقيه را حداکثر تا 10 روز پس از تحويل پروژه بپردازد. اگر کارفرما به پشتيباني نياز دارد، حتماً و تاکيد مي کنم حتمآً چند بند را در قرارداد براي خدمات پشتيباني و استثناهاي مربوط به آن کنار بگذاريد. به طور مثال شما مي توانيد با همان هزينه انجام پروژه، يک سال به صورت رايگان پشتيباني را انجام دهيد. در اين صورت بطور دقيق تاريخ اتمام يک سال خدمات پشتيباني رايگان را ذکر کنيد. براي استفاده از خدمات پشتيباني نرخي را در قرارداد ذکرکنيد و بندي هم قرار دهيد که ممکن است در سال هاي بعد اين نرخ افزايش يابد. حتماً مشخص کنيد که اين خدمات پشتيباني فقط مربوط به مشکلات مربوط به نرم افزار شماست نه چيز ديگر. مثلاً ذکر کنيد که شما در قبال مشکلات سخت افزاري و نصب ويندوز و اين جور چيزها مسئوليتي نداريد.
پروژه را تحليل کنيد
نيازهاي هر کاربر از سيستم را ليست کنيد. سرويس هايي که قرار است سيستم به کاربران مختلف بدهد را مشخص کنيد. اگر با مباحث مهندسي نرم افزار آشنايي داريد، اين قسمت همان شناسايي Actorها و Usecaseهاي سيستم است. هر چقدر شناخت خود را از پروژه افزايش دهيد، کيفيت خروجي کار شما بالاتر خواهد بود و در نتيجه کارفرما راضي تر. پس تا مي توانيد مرحله شناخت نيازها و تحليل سيستم را جدي بگيريد. خروجي فسمت تحليل، مستنداتي است که بر اساس آن پروژه شکل مي گيرد. سعي کنيد همه چيز را مستند کنيد. از مصاحبه هايي که با کاربران سيستم انجام داده ايد تا مسائل فني را براي خودتان بنويسيد. حتي اگر پروژه خيلي هم به نظراتان کوچک باشد، باز هم اين مستندات لازم و حياتي هستند. در قسمت طراحي و پياده سازي متوجه خواهيد شد که اين مستندات چقدر فهم مسئله را ساده تر مي کنند. در اینجا می توانید از یکی از روش های معمول مهندسی نرم افزار برای تحلیل استفاده کنید.
فاز طراحي را جدي بگيريد
با استفاده از مستندات قسمت تحليل، بايد طراحي سيستم نرم افزاري را شروع کنيد. کلاس هاي سيستم را با توجه به مستندات و شناختي که از سيستم داريد مشخص کنيد. اين کلاس ها ممکن است در زمان پياده سازي تغييراتي بکنند. شما فعلاً به صورت کلي کلاس ها را ببينيد. سعي کنيد براي درک بهتر آن ها، دياگرام کلاس ها را نيز رسم کنيد. در اين فاز معماري سيستم نيز مشخص مي شود. ابتدا معلوم کنيد که پلت فرمي که قرار است سيستم روي آن کار کند چيست. مثلاً قرار است نرم افزار تحت وب کار کند يا تحت ويندوز. البته پلت فرم بسياري از پروژه ها در هنگام سفارش، معلوم مي شود. اگر پلت فرم بستگي به نظر شما دارد، سعي کنيد پلت فرمي را انتخاب کنيد که هم روي آن تجربه و تخصص داريد و هم مناسب انجام اين پروژه است.
پياده سازي
اگر فازهاي قبلي را به درستي انجام داده باشيد، در پياده سازي با مشکل حادي برخورد نخواهيد کرد. مستندات دو فاز قبلي مشخصات پياده سازي را تعيين مي کنند. اگر پروژه شما نياز به يک پايگاه داده براي ذخيره اطلاعات دارد (که در اکثر پروژه ها همينطور است)،ابتدا داده هايي که قرار است ذخيره کنيد را بر اساس مستندات فازهاي قبلي شناسايي کنيد. اگر مي توانيد نمودار روابط بين موجوديت ها يا ERD و Data Model را براي درک بهتر بانک اطلاعاتي سيستم رسم کنيد. براي بانک اطلاعاتي خود يک RDBMS مناسب انتخاب کنيد. وقتي به طور مثال SQLite يا Access نياز شما را برطرف مي کنند، بيخودي خود را درگير پيچيدگي هاي SQL Server يا Oracle نکنيد.
براي پياده سازي يک پروژه نرم افزاري، احتياج به ابزارهاي توسعه نرم افزار و يک زبان برنامه نويسي داريد. اگر کارفرما اين ها را مشخص کرده که هيچ، اما اگر بستگي به خودتان دارد، ابزار و زباني را انتخاب کنيد که در آن تجربه داريد و متناسب با پروژه شماست. پلت فرم ها و محيط هاي معمول توسعه نرم افزار براي پروژه هاي شما مناسب هستند، پس اصلاً نگران انتخاب ابزار و زبان نباشيد.
معمولاً بعد از پیاده سازی و تحویل نهایی به کارفرما کارتان تمام نمی شود. تازه بعد از آن است که کارفرما هر روز با شما تماس می گیرد که فلان قسمت برناه را برایش عوض کنید یا قابلیت جدیدی به آن اضافه کنید. در اینجا فقط یک قرارداد محکم می تواند شما را نجات بدهد. باید در قراردادی که با کارفرما بسته اید، بندهایی برای تغییر در نرم افزار و اضافه کردن قابلیت جدید به آن در نظر بگیرید که زبان شما هم در مقابل کارفرما دراز باشد.
در آخر
اگر صلاحیت فنی و روحی انجام پروژه ای را در خودتان نمی بینید، به هیچ وجه قبولش نکنید، چون دردسرهای زیادی برایتان پیش خواهد آورد. سعی کنید به هیچ وجه با کارفرما خودمانی نشوید و شوخی نکنید، کلاس کاری خود را حفظ کنید و فاکتور زمان را حتمآً رعایت کنید. پروژه را که سروقت تحویل دهید در حقیقت به اعتبارتان افزوده اید. کارفرمایان اوصولاً در هنگام پول دادن کم پیدا می شوند و شما اگر بهترین نرم افزار هم برایش تولید کرده باشید، باز ایراد خواهد گرفت و از شما تخفیف خواهد خواست.
اگر سئوال یا ابهامی دارید در کامنت های همین مطلب ذکر کنید تا به آن پاسخ داده شود.
