یکی از اشتباهات رایج در پروژههای فریلنسری این است که خیلی زود سراغ کدنویسی میرویم. مشتری ایدهای مطرح میکند، ما چند سؤال کلی میپرسیم، تکنولوژی را انتخاب میکنیم و شروع میکنیم به ساختن.
اما مشکل معمولا چند هفته بعد خودش را نشان میدهد:
مشتری چیزهایی میخواهد که از اول توافق نشده بود.
محدوده پروژه مشخص نیست.
فیچرها مدام تغییر میکنند.
طراحی دیتابیس بههم میریزد.
زمان و هزینه از کنترل خارج میشود.
پروژهای که ساده به نظر میرسید، تبدیل به یک فرسایش طولانی میشود.
واقعیت این است که مشکل اکثر پروژههای فریلنسری، کمبود شفافیت قبل از کدنویسی است. مهندسی نرمافزار فقط مخصوص شرکتهای بزرگ نیست. هر پروژهای که قرار است واقعی استفاده شود، تحویل مشتری شود، توسعه پیدا کند یا بعدا نگهداری داشته باشد، به حدی از مهندسی نیاز دارد.
قبل از اینکه کد بزنیم، بدانیم دقیقا چه چیزی میسازیم، برای چه کسی میسازیم، چرا میسازیم و نسخه اول باید شامل چه چیزهایی باشد. این همان چیزی است که میتوان آن را مهندسی نرمافزار به اندازه کافی نامید.
در این مقاله تمرکز اصلی روی بخشهای قبل از کدنویسی است؛ چون همانجا جایی است که بیشتر پروژهها یا درست پایهگذاری میشوند یا از همان ابتدا مسیر اشتباه را میروند.
اولین قدم، انتخاب فریمورک، طراحی دیتابیس یا تخمین قیمت نیست. اولین قدم این است که بفهمید مسئله چیست. خیلی وقتها مشتری به جای مسئله، راهحل پیشنهادی خودش را بیان میکند. مثلا میگوید:
یک سایت شبیه دیوار میخواهم.
اما این جمله هنوز نیازمندی نیست. باید بفهمیم دقیقا چرا چنین چیزی میخواهد.
سؤالهای مهم این مرحله:
پروژه قرار است چه مشکلی را حل کند؟
کاربران اصلی چه کسانی هستند؟
الان این مشکل چطور حل میشود؟
چرا راهحل فعلی کافی نیست؟
مشتری از نسخه اول چه انتظاری دارد؟
موفقیت پروژه یعنی چه؟
بعد از فهم اولیه مسئله، باید تصویر کسبوکاری پروژه را شفافتر کرد. برای این کار Lean Canvas ابزار خوبی است؛ مخصوصا برای پروژههای محصولی، مارکتپلیس، اپلیکیشنهای خدماتی و ایدههایی که قرار است رشد کنند. اما برای همه پروژههای فریلنسری لازم نیست Lean Canvas را خیلی رسمی و کامل پر کنیم. گاهی یک نسخه سبکتر، کاربردیتر است.
این چند سؤال ساده میتوانند جلوی بسیاری از سوءتفاهمها را بگیرند:
مثلا در پروژهای شبیه دیوار، ممکن است مشتری تصور کند نسخه اول باید همه چیز داشته باشد: ثبت آگهی، چت، پرداخت، تبلیغات، احراز هویت، پیشنهاد هوشمند، اپلیکیشن موبایل، پنل مدیریت و غیره. اما Mini Canvas کمک میکند بفهمیم ارزش اصلی نسخه اول چیست. شاید در شروع، فقط این کافی باشد:
کاربران بتوانند آگهی ثبت کنند و دیگران بتوانند آن آگهیها را جستجو و مشاهده کنند.
همین شفافسازی، پروژه را از یک غول مبهم به یک نسخه قابل ساخت تبدیل میکند.
بعد از فهم مسئله و تصویر کلی محصول، باید محدوده پروژه مشخص شود. در پروژههای فریلنسری، Scope حیاتی است. چون اگر محدوده شفاف نباشد، پروژه به مرور بزرگتر میشود، بدون اینکه زمان و هزینه آن درست مدیریت شود.
یعنی مشخص کنیم پروژه شامل چه چیزهایی هست و چه چیزهایی نیست. برای مثال، در نسخه اول یک سیستم ثبت آگهی:
این بخش را باید مکتوب کرد. حتی اگر سند رسمی نمینویسید، یک فایل ساده هم کافی است. مهم این است که هم شما و هم مشتری بدانید نسخه اول دقیقا شامل چه چیزهایی است.
MVP یعنی کوچکترین نسخهای که ارزش اصلی محصول را ارائه میدهد. به معنی محصول بیکیفیت نیست. MVP یعنی محصولی که اضافات غیرضروری ندارد. برای فریلنسرها، باعث میشود پروژه سریعتر قابل تحویل باشد و ریسک کمتری را متحمل بشود و از همه مهم تر زودتر بازخورد واقعی بگیرد.
مهندسی نیازمندیها یعنی تبدیل صحبتهای مشتری به مواردی شفاف، قابل پیادهسازی و قابل تست. در پروژههای کوچک نیازی به سندهای طولانی نیست، اما حداقل باید این موارد مشخص شوند:
نقشهای کاربری
قابلیتهای اصلی
قوانین کسبوکار
محدودیتها
حالتهای خطا
معیار پذیرش هر قابلیت
مثلا برای قابلیت ثبت آگهی:
به عنوان کاربر،
میخواهم بتوانم یک آگهی ثبت کنم،
تا محصول یا خدمت خود را به دیگران نمایش دهم.
معیار پذیرش:
- عنوان آگهی اجباری است.
- دستهبندی اجباری است.
- شهر اجباری است.
- شماره تماس باید معتبر باشد.
- تصویر آگهی اختیاری/اجباری است.
- آگهی قبل از تأیید مدیر منتشر نمیشود.
نیازمندیهای غیرعملکردی مشخص میکنند سیستم با چه کیفیتی باید کار کند. مثلا:
سیستم چقدر سریع باشد؟
چند کاربر همزمان را پشتیبانی کند؟
اطلاعات کاربران چطور محافظت شود؟
بکاپ چگونه گرفته شود؟
اگر خطا رخ داد، چطور متوجه شویم؟
سطح دسترسی کاربران چگونه کنترل شود؟
برای پروژههای کوچک هم این موارد مهماند، مخصوصا اگر پروژه شامل پرداخت، اطلاعات شخصی، سفارش، رزرو، فایلهای کاربران باشد.
System Design یعنی قبل از پیادهسازی، تصمیم بگیریم سیستم از چه بخشهایی تشکیل میشود و این بخشها چطور با هم کار میکنند. برای تیمهای کوچک، System Design نباید پیچیده و سنگین باشد. اما حذف کردن آن اشتباه بزرگی است.
در بسیاری از پروژههای کوچک و متوسط، انتخاب Modular Monolith بهتر است. یعنی پروژه یکپارچه است، اما داخل آن ماژولها تمیز و جدا طراحی میشوند.
مزیت این روش، توسعه سریعتر و دیپلوی سادهتر است که باعث کمتر شدن هزینه ها هم می شود و علاوه براین ها مدریت پروژه رو بسیار راحتتر کرده و در آینده اگر لازم شد، میتوان بعضی بخشها را جدا کرد.
برای بیشتر پروژههای فریلنسری، شروع با Microservice انتخاب خوبی نیست. Microservice پیچیدگی زیادی دارد: دیپلوی جداگانه، مانیتورینگ، ارتباط بین سرویسها، مدیریت خطا، دیتابیسهای جدا و هزینه عملیاتی بیشتر.
نیازمندیها و طراحی کلی مشخص شدند، کدنویسی مفهومی و هدفمند میشود و در این مرحله باید چند اصل ساده را رعایت کرد، از جمله استفاده حتمی از سیستم کنترل نسخه Git و چیدن ساختاری تمیز برای پروژه، همچنین نباید به صرف کارکرد کد اکتفا کرد و باید به اصول کدنویسی تمیز پایبند بود، مانند جدا کردن منطق کسبوکار، مدیریت صحیح خطاها و استفاده از محیطهای جداگانه برای توسعه (development) و تولید (production) که این کار خود مانع از بروز بسیاری از بحرانها خواهد شد.
اکثر پروژه ها بر زمان تأکید دارند که متأسفانه اولین چیزی که قربانی میشود بخش تست است، اما نباید این مراحل را حذف کنید و باید حداقل برای امور اصلی پروژه تست های حداقلی داشته باشید، مثلاً برای ثبت نام، ورود و سطوح دسترسی کاربران که واقعاً مهم هستند و به همریختن آنها بعدها میتواند بحران های جدی ایجاد کند، و از همه مهمتر سناریوهای پرداخت اگر در پروژه وجود دارند یا فرم های حساسی که ممکن است پروژه شامل آنها باشد، در حالی که بسیاری از این تست ها را حتی میتوان یکبار نوشت و با حداقل تغییرات در همهٔ پروژه ها استفاده کرد؛
همچنین باید از ابتدای پروژه تعیین شود که پروژه کجا مستقر (deploy) میشود، بکاپ ها چگونه گرفته شوند، لاگ های سیستم کجا ذخیره گردند و در صورت رخداد خطا از کجا و چگونه متوجه قضیه شویم،
و در نهایت به نگهداری کدها میرسیم که ممکن است در اکثر مواقع کارفرما برای تغییرات و آپدیت ها به سوی شما بازگردد، یا شاید شما پشتیبانی تا مدت زمان مشخصی را در قرارداد خود تعیین کرده اید، چون اگر این موارد شفاف نباشد، پروژه بعد از تحویل هم تمام نمیشود.
مهندسی نرمافزار برای فریلنسرها به معنای فرآیندهای سنگین، سندهای طولانی و جلسات بی پایان نیست، بلکه یعنی پروژه را پیش از کدنویسی شفاف کنیم و برای بیشتر پروژه های فریلنسری، رعایت همین مسیر کافی است که با فهم مسئله شروع میشود، سپس به Mini Canvas میرسیم، بعد از آن Scope و MVP را مشخص میکنیم، نیازمندی ها را استخراج کرده، System Design را انجام می دهیم و در نهایت به کدنویسی، تست، دیپلوی و نگهداری میرسیم؛ در این میان فریلنسر حرفه ای فقط کسی نیست که خوب کد میزند، بلکه کسی است که میتواند پروژه را از یک ایده مبهم به یک محصول قابل تحویل، قابل نگهداری و قابل توسعه تبدیل کند و اصل ماجرا ساده است که پیش از اینکه سریع کد بزنید، کمی درست فکر کنید، چون همین مقدار از مهندسی نرمافزار برای بسیاری از پروژه ها کافی است.
