۲۰ ایده پروژه نمونه کار که مهارت واقعی را نشان می‌دهد

بهترین ایده‌های پروژه نمونه کار مسئله‌ای واقعی را برای فرد واقعی حل می‌کنند، یک یا دو مهارت را روشن نشان می‌دهند و تمام‌شده هستند: زنده، مستندسازی‌شده و قابل توضیح. بازبین‌ها برای هر نمونه کار چند دقیقه وقت می‌گذارند، پس یک اپ کاربردی برای یک کاربر واقعی (سیستم رزرو یک باشگاه، داشبورد داده‌های عمومی، یا بازطراحی همراه با تحقیق) بهتر از یک کپی دیگر از یک محصول معروف است. در ادامه بیست ایده را بر اساس نقش دسته‌بندی کرده‌ایم، با آنچه نشان می‌دهد، نسخه اولی که باید بسازید و سخت‌ترین بخش صادقانه‌اش.

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

یک پروژه نمونه کار قوی چه ویژگی‌هایی دارد

توسعه‌دهندگان فرانت‌اند

۱. نمونه کتابخانه فرم دسترس‌پذیر

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

۲. بازسازی یک صفحه واقعی، سپس بهبود آن

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

۳. جدول داده‌محور که سریع می‌ماند

• نشان می‌دهد: عملکرد، مرتب‌سازی، فیلتر، صفحه‌بندی، حالت‌های بارگذاری.
• نسخه اول: جدولی با بیش از ۱۰٬۰۰۰ ردیف از یک مجموعه داده عمومی، با جستجو، فیلترها و نماهای ذخیره‌شده.
• سخت‌ترین بخش: اندازه‌گیری. زمان بارگذاری را قبل و بعد از تغییراتتان نشان دهید.

۴. چک‌لیست دوستدار حالت آفلاین

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

توسعه‌دهندگان فول‌استک و بک‌اند

۵. سیستم رزرو برای یک کسب‌وکار کوچک واقعی

• نشان می‌دهد: مدل‌سازی داده، ورود کاربر، ایمیل، منطقه زمانی، موارد لبه.
• نسخه اول: خدمات، زمان‌های در دسترس، رزروها، ایمیل‌های تأیید و نمای مدیریت. سازنده رزرو می‌تواند پایه‌ها را راه بیندازد تا روی قوانین سخت تمرکز کنید.
• می‌تواند درآمد داشته باشد: اگر کسب‌وکار از آن استفاده کند، یک هزینه ماهانه کوچک.
• سخت‌ترین بخش: رزرو دوباره و لغو. درباره اینکه چطور آنها را جلوگیری کردید بنویسید.

۶. پورتال چندکاربره کلاینت با نقش‌ها

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

۷. ردیاب موجودی با گزارش تغییرات

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

۸. API عمومی با مستندات

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

۹. خط لوله کار پس‌زمینه

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

داده و تحلیل

۱۰. داشبورد داده عمومی با یک پرسش

• نشان می‌دهد: پاک‌سازی داده، انتخاب نمودار، روایت یک داستان.
• نسخه اول: یک مجموعه داده عمومی، یک پرسش روشن («کدام خطوط اتوبوس بیشتر دیرکرد دارند؟»)، سه نمودار و یک پاسخ مکتوب. سازنده داشبورد چیدمان را انجام می‌دهد.
• سخت‌ترین بخش: گفتن اینکه داده چه چیزی نشان نمی‌دهد. شکاف‌ها و محدودیت‌ها را یادداشت کنید.

۱۱. تحلیل هزینه‌های شخصی

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

۱۲. ردیاب KPI برای کسب‌وکار کوچک

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

طراحان

۱۳. بازطراحی همراه با تحقیق

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

۱۴. سیستم طراحی برای یک محصول کوچک

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

۱۵. یک نمونه اولیه کار، نه فقط ماکت

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

نقش‌های محصول و بدون‌کد

۱۶. مطالعه موردی از مسئله تا راه‌اندازی

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

۱۷. ابزار داخلی که جای یک صفحه‌گسترده را می‌گیرد

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

۱۸. پورتال بازخورد با نقشه راه عمومی

• نشان می‌دهد: جمع‌آوری و اولویت‌بندی ورودی کاربر.
• نسخه اول: کاربران ایده‌ها را ثبت و رأی می‌دهند؛ شما آنها را «برنامه‌ریزی‌شده»، «در حال انجام» یا «انجام‌شده» علامت می‌زنید. چطور یک پورتال بازخورد مشتری بسازیم را ببینید.
• سخت‌ترین بخش: «نه» گفتن در ملأعام.

پروژه‌های متمرکز بر هوش مصنوعی

۱۹. ابزار هوش مصنوعی برای یک کار باریک

• نشان می‌دهد: طراحی پرامپت، آگاهی از هزینه، مدیریت خروجی بد.
• نسخه اول: یک کار را خوب انجام دهد، مثل تبدیل یک دستور پخت به فهرست خرید، با نتایج ذخیره‌شده و راهی برای اصلاح اشتباهات. چطور از APIهای LLM استفاده کنیم کلیدها و هزینه‌ها را توضیح می‌دهد.
• سخت‌ترین بخش: نشان دادن اینکه چطور ارزیابی‌اش کردید: ده ورودی آزمایشی و اینکه چندتا را درست جواب داد.

۲۰. جستجو در اسناد خودتان

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

چطور یک پروژه را تمام و ارائه کنیم

۱. پیش از شروع یک کاربر واقعی انتخاب کنید. یک دوست، یک باشگاه، یک کارفرمای سابق، یا خودتان. ۲. یک نسخه کوچک را در دو هفته ارسال کنید، سپس بر اساس آنچه کاربر می‌گوید بهبودش دهید. ۳. کد را در Git نگه دارید. حتی اگر با یک سازنده هوش مصنوعی شروع کردید، آن را خروجی بگیرید؛ چطور Git را با اپ ساخته‌شده با هوش مصنوعی به کار ببریم نشان می‌دهد. (در Mythex، خروجی کد و GitHub در طرح Pro هستند.) ۴. کد را بخوانید و بفهمید. اگر هوش مصنوعی بخش‌هایی از آن را نوشته، چطور کد تولیدشده با هوش مصنوعی را بازبینی کنیم کمک می‌کند تا به نقطه‌ای برسید که بتوانید در مصاحبه توضیحش دهید. ۵. آن را بنویسید. مسئله، کاربر، آنچه ساختید، تصمیم‌های کلیدی، آنچه خراب شد و آنچه بعدی است. یک صفحه. ۶. آن را زنده نگه دارید. یک لینک نمونه خراب بدتر از نبودنش است. پیش از هر درخواست، همه لینک‌ها را بررسی کنید.

برای ایده‌های بیشتر که برای کارفرما نیستند، ایده‌های پروژه جانبی که با هوش مصنوعی می‌سازید یا ایده‌های اپ وب را ببینید.

پرسش‌ها