20 პორტფოლიოს პროექტის იდეა, რომელიც რეალურ უნარებს აჩვენებს

საუკეთესო პორტფოლიოს პროექტის იდეები რეალური ადამიანისთვის ხსნის რეალურ პრობლემას, ცალსახად აჩვენებს ერთ ან ორ უნარს და დასრულებულია: ცოცხალია, დოკუმენტირებულია და ახსნადი. მიმომხილველები თითო პორტფოლიოზე რამდენიმე წუთს ხარჯავენ, ამიტომ მომხმარებლისთვის მომუშავე აპი (კლუბის დაჯავშნის სისტემა, საჯარო მონაცემების დაფა, ხელახალი დიზაინი კვლევის უკან) უკეთესია, ვიდრე კიდევ ერთი ცნობილი პროდუქტის კლონი. ქვემოთ ოცი იდეაა დაჯგუფებული როლის მიხედვით, თითოეულთან ერთად: რას აჩვენებს, რომელი პირველი ვერსია ავაშენოთ და გულწრფელი რთული ნაწილი.

ყველა ეს მუშაობს როგორც ვებ აპი ან საიტი, რომელზეც შეგიძლიათ მიუთითოთ. როცა სამი-ოთხი მაინც გექნებათ, როგორ ავაშენოთ პორტფოლიოს საიტი გიჩვენებთ, როგორ წარმოადგინოთ ისინი.

რას შეიცავს ძლიერი პორტფოლიოს პროექტი

Front-end დეველოპერები

1. ხელმისაწვდომი ფორმების ბიბლიოთეკის დემო

• აჩვენებს: სემანტიკურ HTML-ს, კლავიატურის მხარდაჭერას, შეცდომის შეტყობინებებს, ეკრანის წამკითხველით ტესტირებას.
• პირველი ვერსია: ხუთი გავრცელებული ფორმის ნიმუში (რეგისტრაცია, მისამართი, თარიღის დიაპაზონი, ფაილის ატვირთვა, მრავალეტაპიანი), სწორად აშენებული, გვერდით თითოეული ხელმისაწვდომობის არჩევანის ასახსნელად.
• რთული ნაწილი: ტესტირება რეალურ ეკრანის წამკითხველთან და არა მხოლოდ ავტომატური შემოწმების ინსტრუმენტით. როგორ გავხადოთ ვებსაიტი ხელმისაწვდომი შეიცავს ჩეკლისტს.

2. რეალური გვერდის ხელახლა აშენება და გაუმჯობესება

• აჩვენებს: განლაგებას, რესპონსივ დიზაინს, დეტალებზე ყურადღებას.
• პირველი ვერსია: აირჩიეთ საჯარო გვერდი მკაფიო პრობლემით (დამაბნეველი განრიგი, გადატვირთული მენიუ), ხელახლა ააშენეთ, შემდეგ გამოაქვეყნეთ ვერსია, რომელიც პრობლემას ასწორებს, «სანამ და მერე» შედარებით.
• რთული ნაწილი: პატივისცემა. გამოიყენეთ თქვენი საკუთარი ტექსტი და სურათები, მონიშნეთ როგორც კონცეფცია და ნუ დააკოპირებთ ლოგოებს ან ნუ წარმოადგენთ კომპანიის ნამუშევრად.

3. მონაცემებით მძიმე ცხრილი, რომელიც სწრაფი რჩება

• აჩვენებს: მუშაობას, დალაგებას, ფილტრაციას, პაგინაციას, ჩატვირთვის მდგომარეობებს.
• პირველი ვერსია: 10 000+ სტრიქონიანი ცხრილი საჯარო მონაცემთა ნაკრებიდან, ძიებით, ფილტრებითა და შენახული ხედებით.
• რთული ნაწილი: გაზომვა. აჩვენეთ ჩატვირთვის დრო თქვენი ცვლილებების წინ და შემდეგ.

4. ოფლაინ-მეგობრული ჩეკლისტის აპი

• აჩვენებს: service workers-ს, ლოკალურ შენახვას, სინქრონიზაციას ონლაინში დაბრუნებისას.
• პირველი ვერსია: ჩეკლისტები, რომლებიც სიგნალის გარეშე მუშაობს და კავშირის დაბრუნებისას სინქრონდება. ნატიური vs პროგრესული ვებ აპები ვარიანტებს განმარტავს.
• რთული ნაწილი: სინქრონიზაციის კონფლიქტები, როცა ორი მოწყობილობა ერთსა და იმავე სიას არედაქტირებს.

Full-stack და back-end დეველოპერები

5. დაჯავშნის სისტემა რეალური პატარა ბიზნესისთვის

• აჩვენებს: მონაცემთა მოდელირებას, შესვლას, ელფოსტებს, დროის სარტყელებს, შემთხვევით კუთხეებს.
• პირველი ვერსია: სერვისები, ხელმისაწვდომობა, დაჯავშნები, დადასტურების ელფოსტები და ადმინისტრატორის ხედი. დაჯავშნის კონსტრუქტორი შეუძლია ძირითადი ნაწილები მოამზადოს, რომ თქვენ მკაცრ წესებს შეუდგეთ.
• შეიძლება მოიტანოს: თუ ბიზნესი იყენებს, პატარა თვიური საფასური.
• რთული ნაწილი: ორმაგი დაჯავშნები და გაუქმებები. დაწერეთ, როგორ აიცილეთ ისინი.

6. მრავალმომხმარებლიანი კლიენტის პორტალი როლებით

• აჩვენებს: ავთენტიფიკაციას, უფლებებს, ფაილების ატვირთვას, უსაფრთხოების აზროვნებას.
• პირველი ვერსია: კლიენტები შედიან მხოლოდ თავიანთ ფაილებსა და შეტყობინებებზე სანახავად; თანამშრომლები ყველაფერს ხედავენ. იხილეთ როგორ ავაშენოთ კლიენტის პორტალი და პორტალის კონსტრუქტორი.
• რთული ნაწილი: იმის დამტკიცება, რომ ერთი კლიენტი ვერ ხედავს მეორის მონაცემებს. ჩართეთ თქვენი ტესტები დაწერილ აღწერაში.

7. ინვენტარის თვალყურის დევნება აუდიტის ჟურნალით

• აჩვენებს: რელაციურ მონაცემებს, ისტორიის ცხრილებს, ანგარიშებს.
• პირველი ვერსია: ნივთები, მარაგის მოძრაობა, დაბალი მარაგის გაფრთხილებები და ჟურნალი იმის შესახებ, ვინ რა შეცვალა. დაიწყეთ ინვენტარის კონსტრუქტორით.
• რთული ნაწილი: რაოდენობების სწორად შენარჩუნება, როცა ორი ადამიანი ერთდროულად განაახლებს მარაგს.

8. საჯარო API დოკუმენტაციით

• აჩვენებს: API დიზაინს, ვალიდაციას, მოთხოვნების ლიმიტირებას, დოკუმენტაციას.
• პირველი ვერსია: პატარა API მონაცემთა ნაკრებზე, რომელიც თქვენთვის მნიშვნელოვანია, გასაღებებით, ლიმიტებითა და დოკუმენტაციის გვერდით. როგორ ავაშენოთ REST API სტრუქტურას ხსნის.
• რთული ნაწილი: კარგი შეცდომის შეტყობინებები. სწორედ მათ ყველაზე მეტად ამჩნევენ API-ს მომხმარებლები.

9. ფონური სამუშაოების კონვეირი

• აჩვენებს: რიგებს, ხელახალ ცდებს, დაგეგმილ სამუშაოებსა და მონიტორინგს.
• პირველი ვერსია: აპი, რომელიც CSV-ს იმპორტირებს, ფონში ამუშავებს და დასრულებისას ელფოსტით აგზავნის ანგარიშს. იხილეთ როგორ გავუშვათ ფონური სამუშაოები.
• რთული ნაწილი: წარუმატებლობა. აჩვენეთ, რა ხდება, როცა სამუშაო შუაზე ჩავარდება.

მონაცემები და ანალიტიკა

10. საჯარო მონაცემთა დაფა კითხვით

• აჩვენებს: მონაცემების გასუფთავებას, დიაგრამების არჩევას, ისტორიის მოყოლას.
• პირველი ვერსია: ერთი საჯარო მონაცემთა ნაკრები, ერთი მკაფიო კითხვა («რომელი ავტობუსის მარშრუტები აგვიანებს ყველაზე ხშირად?»), სამი დიაგრამა და დაწერილი პასუხი. დაფის კონსტრუქტორი განლაგებას უმკლავდება.
• რთული ნაწილი: იმის თქმა, რასაც მონაცემები არ აჩვენებს. აღნიშნეთ ხარვეზები და დათქმები.

11. პირადი ხარჯების ანალიზი

• აჩვენებს: კატეგორიზაციას, დროით მწკრივებს, კონფიდენციალურობის ცნობიერებას.
• პირველი ვერსია: ბანკის ექსპორტის იმპორტი (საჯარო ვერსიაში გამოიყენეთ ნიმუში ან ანონიმიზებული მონაცემები), ავტომატური კატეგორიზაცია და ტენდენციების ჩვენება.
• რთული ნაწილი: არასდროს გამოაქვეყნოთ რეალური ფინანსური მონაცემები.

12. პატარა ბიზნესის KPI თვალყურის დევნება

• აჩვენებს: ბიზნეს საჭიროებების მეტრიკებად თარგმნას.
• პირველი ვერსია: მეგობრის მაღაზიისთვის ან კლუბისთვის: ხუთი მეტრიკა, რომელზეც ისინი ნამდვილად გკითხავენ, განახლებული ცხრილიდან. როგორ დავაკავშიროთ Google Sheets თქვენს აპთან კავშირს ხსნის.
• რთული ნაწილი: მეტრიკების შერჩევა მფლობელთან ერთად და არა მისი ნაცვლად.

დიზაინერები

13. ხელახალი დიზაინი კვლევით

• აჩვენებს: მომხმარებლის კვლევას, პრობლემის ჩამოყალიბებას, იტერაციას.
• პირველი ვერსია: ესაუბრეთ სამ მომხმარებელს ადგილობრივი სერვისის საიტზე ან აპში, იპოვეთ ერთი პრობლემა, შექმენით და ტესტირება ჩაუტარეთ გადაწყვეტას. წარმოადგინეთ დასკვნები და არა მხოლოდ ეკრანები.
• რთული ნაწილი: რეალური მომხმარებლების პოვნა. სამი მოკლე საუბარი საკმარისია; როგორ ჩავატაროთ მომხმარებლის ინტერვიუები გეხმარებათ.

14. დიზაინის სისტემა პატარა პროდუქტისთვის

• აჩვენებს: თანმიმდევრულობას, კომპონენტებს, დოკუმენტაციას.
• პირველი ვერსია: ფერები, შრიფტი, დაშორებები, ათი კომპონენტი მდგომარეობებით და ცოცხალი გვერდი, სადაც ისინი გამოყენებულია.
• რთული ნაწილი: ამის ჩვენება რეალურ პროდუქტში და არა მხოლოდ სტიკერების ცხრილში.

15. მომუშავე პროტოტიპი და არა მხოლოდ მაკეტები

• აჩვენებს: რომ გესმით, როგორ იქცევა დიზაინი რეალურ მონაცემებთან.
• პირველი ვერსია: აიღეთ ერთ-ერთი თქვენი დიზაინის პროექტი და ააშენეთ როგორც მომუშავე ვებ აპი, თუნდაც პატარა. AI აპის კონსტრუქტორს, როგორიცაა Mythex, შეუძლია თქვენი აღწერა მომუშავე აპად გადააქციოს ცოცხალი გადახედვით, რაც საშუალებას გაძლევთ რეალურ მონაცემებსა და მომხმარებლებთან სცადოთ.
• რთული ნაწილი: გულწრფელობა იმის შესახებ, რა თავად ააშენეთ და რა გენერირდა ინსტრუმენტით.

პროდუქტის და no-code როლები

16. პრობლემიდან გაშვებამდე: შემთხვევის შესწავლა

• აჩვენებს: აღმოჩენას, პრიორიტეტიზაციას, გაშვებას.
• პირველი ვერსია: იპოვეთ პატარა პრობლემა ჯგუფში, რომლის წევრიც ხართ, დაწერეთ ერთგვერდიანი სპეციფიკაცია, გააკეთეთ უმარტივესი გამოსწორება, გაუშვით და გაზომეთ გამოყენება. როგორ დავწეროთ პროდუქტის მოთხოვნების დოკუმენტი AI-ით შაბლონს გვთავაზობს.
• რთული ნაწილი: ნამდვილად რაიმეს გაზომვა. ისიც კი შედეგია, რომ «20 წევრიდან 12-მა პირველ კვირაში გამოიყენა».

17. შიდა ინსტრუმენტი, რომელიც ცხრილს ანაცვლებს

• აჩვენებს: პროცესის აზროვნებას, ცვლილებების მართვას.
• პირველი ვერსია: სამსახურში, კლუბში ან ფონდში არსებული აშლილი საერთო ცხრილი გადააქციეთ მარტივ აპად. იხილეთ როგორ გადავაქციოთ ცხრილი აპად.
• რთული ნაწილი: ადამიანების გადაყვანა. დაწერეთ, რა გააკეთეთ იმისთვის, რომ ისინი გადასულიყვნენ.

18. უკუკავშირის პორტალი საჯარო როუდმეპით

• აჩვენებს: მომხმარებლის შეყვანის შეგროვებასა და პრიორიტეტიზაციას.
• პირველი ვერსია: მომხმარებლები აგზავნიან და ხმას აძლევენ იდეებს; თქვენ ნიშნავთ მათ დაგეგმილად, მიმდინარედ ან დასრულებულად. იხილეთ როგორ ავაშენოთ მომხმარებლის უკუკავშირის პორტალი.
• რთული ნაწილი: საჯაროდ უარის თქმა.

AI-ზე ორიენტირებული პროექტები

19. AI ინსტრუმენტი ერთი ვიწრო საქმისთვის

• აჩვენებს: პრომპტის დიზაინს, ხარჯების ცნობიერებას, ცუდი პასუხების დამუშავებას.
• პირველი ვერსია: ერთი დავალება კარგად შესრულებული, მაგალითად რეცეპტის გადაქცევა საყიდლების სიად, შენახული შედეგებითა და გზით შეცდომების გასასწორებლად. როგორ გამოვიყენოთ LLM API-ები გასაღებებსა და ხარჯებს ეხება.
• რთული ნაწილი: იმის ჩვენება, როგორ შეაფასეთ: ათი სატესტო შეყვანა და იმის დათვლა, რამდენი სწორად გაიცა.

20. ძებნა თქვენს საკუთარ დოკუმენტებში

• აჩვენებს: მოძიებას, დაყოფას ნაწილებად, წყაროების ციტირებას.
• პირველი ვერსია: ატვირთეთ საჯარო დოკუმენტების ნაკრები (კლუბის წესები, თამაშის სახელმძღვანელო) და უპასუხეთ კითხვებს წყაროს პასაჟების ბმულებით. რა არის RAG ამ მიდგომას ხსნის.
• რთული ნაწილი: იმის აღიარება, როცა პასუხი დოკუმენტებში არ არის.

როგორ დაასრულოთ და წარმოადგინოთ პროექტი

1. აირჩიეთ რეალური მომხმარებელი დაწყებამდე. მეგობარი, კლუბი, ყოფილი დამსაქმებელი, თავად თქვენ.
2. გამოუშვით პატარა ვერსია ორ კვირაში, შემდეგ გააუმჯობესეთ იმის მიხედვით, რას ამბობს მომხმარებელი.
3. კოდი ჩადეთ Git-ში. თუნდაც დაიწყოთ AI კონსტრუქტორში, ექსპორტი გააკეთეთ; როგორ გამოვიყენოთ Git AI-ით აშენებულ აპთან გიჩვენებთ როგორ. (Mythex-ზე კოდის ექსპორტი და GitHub Pro გეგმაში შედის.)
4. წაიკითხეთ და გაიგეთ კოდი. თუ AI ნაწილები დაწერა, როგორ გადავხედოთ AI-ით დაწერილ კოდს დაგეხმარებათ, რომ ინტერვიუზე ახსნა შეძლოთ.
5. დაწერეთ აღწერა. პრობლემა, მომხმარებელი, რა ააშენეთ, მთავარი გადაწყვეტილებები, რა გატყდა, რა არის შემდეგი. ერთი გვერდი.
6. შეინარჩუნეთ ცოცხალი. გატეხილი დემო ბმული უარესია, ვიდრე არ არსებობს. შეამოწმეთ ბმულები ყოველი განაცხადის წინ.

პროექტის იდეებისთვის, რომლებიც დამსაქმებლებზე არ არის ორიენტირებული, იხილეთ გვერდითი პროექტის იდეები, რომელთა აშენებაც AI-ით შეგიძლიათ ან ვებ აპის იდეები.

კითხვები