SEPEHR.SYS

Starting SEPEHR.SYS…

Loading

سپهر محسنی

مهندس نرم‌افزار فول‌استک و هوش مصنوعی

استخدام برنامه‌نویس فریلنسر: راهنمای کارفرما برای اینکه انتخاب اشتباه نکنی — NOTES ×
AddressC:\DOCS\NOTES\استخدام-برنامه-نویس-فریلنسر-راهنمای-کارفرما

استخدام برنامه‌نویس فریلنسر: راهنمای کارفرما برای اینکه انتخاب اشتباه نکنی

۲۱/۰۹/۲۰۲۶۴ دقیقه مطالعهSepehr Mohseni

بیشتر پروژه‌های شکست‌خورده به‌خاطر بلد نبودن برنامه‌نویس شکست نمی‌خورند؛ به‌خاطر مبهم بودن صورت‌مسئله شکست می‌خورند. این راهنما می‌گوید قبل از استخدام برنامه‌نویس فریلنسر چه چیزی را باید مشخص کنی، چطور مهارت واقعی را بسنجی و کدام نشانه‌ها یعنی فرار کن.

اگر تا حالا یک بار برنامه‌نویس فریلنسر گرفته‌ای و نتیجه آن چیزی نشده که می‌خواستی، احتمال زیادی هست که مشکل از بلد نبودن او نبوده. در بیشتر پروژه‌هایی که خراب می‌شوند، کد بد آخرِ زنجیره است، نه اولش. اولش معمولاً این است که هیچ‌کس دقیقاً ننوشته بود قرار است چه چیزی ساخته شود و از کجا بفهمیم تمام شده.

این نوشته از سمت کارفرماست: چه چیزی را قبل از شروع مشخص کن، چطور بفهمی طرف مقابل واقعاً بلد است، و کجاها باید بترسی.

قبل از اینکه دنبال کسی بگردی، این سه چیز را بنویس

لازم نیست سند فنی بنویسی. سه پاراگراف ساده کافی است، ولی این سه تا باید داخلش باشد:

  1. مشکل، نه راه‌حل. «می‌خواهم اپلیکیشن موبایل داشته باشم» یک راه‌حل است. «سفارش‌ها را روی کاغذ می‌نویسیم و روزی دو ساعت وقت می‌برد و اشتباه می‌شود» یک مشکل است. جملهٔ دوم به برنامه‌نویس اجازه می‌دهد راه ارزان‌تری پیشنهاد کند؛ جملهٔ اول فقط یک سفارش ساخت است.
  2. معیار موفقیت. از کجا می‌فهمی کار درست انجام شده؟ اگر جوابش «وقتی خوب باشد» است، هیچ‌وقت تمام نمی‌شود. اگر «وقتی بشود سفارش را از گوشی ثبت کرد و مشتری پیامک بگیرد» است، تمام‌شدنی است.
  3. محدودیت‌ها. بودجه، تاریخی که برایت مهم است، سیستم‌هایی که حتماً باید بهشان وصل شود، و اینکه چه کسی بعد از تحویل نگهش می‌دارد. پنهان کردن بودجه فقط وقت هر دو طرف را تلف می‌کند؛ عدد که روی میز باشد، طرف مقابل می‌تواند بگوید با این بودجه چه چیزی شدنی است.

چطور بفهمی واقعاً بلد است؟

رزومه و فهرست تکنولوژی‌ها کمترین ارزش را دارند، چون نوشتن‌شان آسان است. سه چیز بیشتر به کار می‌آید:

۱. چیزی که بشود باز کرد و استفاده کرد

نمونه‌کاری که فقط اسکرین‌شات است چیز زیادی ثابت نمی‌کند. لینکی که باز شود و کار کند، یا کد عمومی که بشود خواندش، خیلی بیشتر می‌گوید. لازم نیست خودت کد بلد باشی؛ همین که چیزی هست که کار می‌کند، یک واقعیت قابل بررسی است.

۲. سؤال‌هایی که می‌پرسد

این مهم‌ترین نشانه است. کسی که بعد از شنیدن توضیح تو هیچ سؤالی ندارد، یا کار را کامل فهمیده — که بعید است — یا اصلاً فکر نکرده که چه چیزهایی ممکن است پیچیده باشد. برنامه‌نویس باتجربه معمولاً اول چند سؤال ناراحت‌کننده می‌پرسد: با داده‌های قدیمی چه کنیم؟ چند نفر همزمان استفاده می‌کنند؟ اگر این سرویس بیرونی جواب نداد چه؟

۳. یک تصمیم فنی قدیمی‌اش را توضیح بدهد

بپرس در پروژهٔ قبلی‌اش یک جایی چه انتخابی کرد و چرا، و اگر امروز بود چه کار می‌کرد. کسی که واقعاً کار کرده باشد جوابش پر از «این را انتخاب کردیم ولی این هزینه را داشت» است. کسی که فقط دربارهٔ چیزها خوانده باشد، جوابش فهرست مزایاست.

پرچم‌های قرمز

  • بدون سؤال قیمت می‌دهد. قیمت‌دادن روی چیزی که هنوز معلوم نیست چیست یعنی یا بعداً قیمت عوض می‌شود، یا کیفیت قربانی می‌شود. هر دو حالتش مال توست.
  • همه‌چیز سریع و آسان است. «دو هفته‌ای تمومه» دربارهٔ کاری که هنوز دامنه‌اش روشن نیست، خوش‌بینی نیست؛ یعنی هنوز نگاهش نکرده.
  • کد را نشان نمی‌دهد و دسترسی نمی‌دهد. اگر مخزن کد و سرور دست خودش باشد و تو دسترسی نداشته باشی، پروژه گروگان است. این را از روز اول شرط کن، نه آخرش.
  • هیچ‌وقت «نه» نمی‌گوید. کسی که به هر درخواستی می‌گوید چشم، یا دارد بعداً را خراب می‌کند یا دارد از الان هزینه‌اش را پنهان می‌کند.
  • فقط با خودش قابل ادامه است. اگر کار طوری نوشته شود که هیچ‌کس دیگری نتواند ادامه‌اش بدهد، هزینه‌اش را سال بعد می‌دهی.

قرارداد حداقلی

لازم نیست قرارداد بیست صفحه‌ای باشد. حتی یک صفحه هم اگر این چند بند را داشته باشد، جلوی بیشتر دعواها را می‌گیرد:

  • دامنهٔ کار: چه چیزی داخل است و — مهم‌تر — چه چیزی بیرون است.
  • تحویل‌های مرحله‌ای: کار تکه‌تکه تحویل شود، نه یک‌باره در انتها. هر تکه چیزی باشد که بتوانی ببینی و امتحان کنی.
  • مالکیت: کد، دیتابیس، دامنه و دسترسی‌ها بعد از تسویه مال توست. این را صریح بنویس.
  • شرایط پایان: اگر وسط کار یکی‌تان خواست جدا شود، چه اتفاقی می‌افتد. دانستن جواب از قبل، خودش آرامش است.
  • دورهٔ رفع اشکال: بعد از تحویل، چه مدت اشکالات بدون هزینهٔ اضافه درست می‌شوند.

کجا پیدایش کنی

سایت‌های کاریابی و پلتفرم‌های فریلنسری نقطهٔ شروع بدی نیستند، ولی بهترین نتیجه‌ها معمولاً از ارجاع می‌آید: از کسی بپرس که خودش پروژه‌ای تحویل گرفته و راضی بوده. راه سوم، رفتن سراغ آدم‌هایی است که کارشان بیرون است — کد عمومی، نوشتهٔ فنی، یا محصولی که خودشان ساخته‌اند. آن‌جا قبل از هر حرفی می‌توانی خودت ببینی طرف چه‌کاره است.

جمع‌بندی

صورت‌مسئلهٔ روشن، تحویل مرحله‌ای، و دسترسی کامل به کار خودت — این سه تا بیشترِ ریسک استخدام یک فریلنسر را برمی‌دارد. بقیه‌اش مذاکره است.

من خودم مهندس نرم‌افزار فول‌استکم و پروژه‌های بیرونی را دورکار می‌گیرم. اگر می‌خواهی ببینی چه کارهایی می‌گیرم و همکاری چطور شکل می‌گیرد، صفحهٔ همکاری را ببین، و اگر دنبال سوابق و مهارت‌ها هستی، رزومه آن‌جاست.

شرح پروژه‌ات را بفرست

یادداشت‌های مرتبط

  • هزینهٔ استخدام برنامه‌نویس فریلنسر چطور تعیین می‌شود؟

    هیچ‌کس نمی‌تواند بدون دیدن صورت‌مسئله عدد درستی بدهد — و هر کسی که بدهد، بعداً پسش می‌گیرد. این نوشته می‌گوید قیمت یک پروژهٔ نرم‌افزاری از کجا می‌آید، سه مدل قیمت‌گذاری چه تفاوتی دارند و هزینه‌های پنهان کجا قایم شده‌اند.

    مشترک:استخدام برنامه‌نویسبرنامه‌نویس فریلنسراستخدام

‹ برگشت به یادداشت‌ها

SEPEHR.SYS — همه‌چیز در همین مرورگر اجرا می‌شود.