পোর্টফোলিও ওয়েবসাইটে শুধু কাজ নয়, সমস্যা সমাধানের দক্ষতা কীভাবে ফুটিয়ে তুলবেন?

ওয়েবসাইটটি তৈরি করেছেন আপনি। অথচ পোর্টফোলিওতে সেটির একটি সুন্দর স্ক্রিনশট ছাড়া তেমন কিছু নেই। কোথাও লেখা নেই, মোবাইলে লেআউট ঠিক রাখতে গিয়ে কী পরিবর্তন করেছেন, কোন প্রযুক্তিগত সমস্যায় পড়েছিলেন কিংবা কাজের মাঝপথে কোনো সিদ্ধান্ত বদলাতে হয়েছিল কি না।

ফলে প্রকল্পটি দেখা যাচ্ছে, কিন্তু সেটি তৈরির পেছনে আপনার চিন্তাভাবনা অনেকটাই অজানা থেকে যাচ্ছে। ফ্রন্টএন্ড ডেভেলপার, ইউআই/ইউএক্স ডিজাইনার কিংবা ফ্রিল্যান্সারদের পোর্টফোলিওতে এমন ঘাটতি থাকতে পারে। বিশেষ করে নতুন কাজের জন্য আবেদন করার সময় এটি সমস্যা হয়ে দাঁড়াতে পারে। একজন সম্ভাব্য ক্লায়েন্ট হয়তো আপনার তৈরি ওয়েবসাইটটি পছন্দ করলেন। কিন্তু একই ধরনের নতুন কোনো সমস্যার দায়িত্ব আপনাকে দিতে চাইলে তিনি কাজের প্রক্রিয়া সম্পর্কেও জানতে পারেন।

অনলাইনে Portfolio website guide খুঁজে ওয়েবসাইটের কাঠামো, ডিজাইন বা টেমপ্লেট সম্পর্কে ধারণা পাওয়া যায়। কিন্তু নিজের কাজের পেছনের যুক্তিগুলো কীভাবে তুলে ধরবেন, সেই সিদ্ধান্ত আলাদা করে নিতে হয়। এখানে কেস স্টাডি কাজে আসে। একটি প্রকল্প কেন শুরু হয়েছিল, সেখানে আপনার ভূমিকা কী ছিল, কোন সমাধানটি বেছে নিয়েছেন এবং কাজ শেষে কী জানা গেছে, তা সংক্ষেপে দেখানো যায়। প্রতিটি ছোট সিদ্ধান্তের বিবরণ দেওয়ার দরকার নেই। যেসব সিদ্ধান্ত থেকে আপনার দক্ষতা বোঝা যায়, সেগুলোই সামনে আনুন।

স্ক্রিনশট দেখাচ্ছেন, কিন্তু আপনার কাজটা কোথায়?

একজন ফ্রন্টএন্ড ডেভেলপার একটি অনলাইন দোকানের ওয়েবসাইট তৈরি করেছেন। তাঁর পোর্টফোলিওতে হোমপেজের ছবি, লাইভ ডেমো এবং React, CSS ও JavaScript ব্যবহারের তথ্য রয়েছে। এই তথ্য থেকে ওয়েবসাইটটির চেহারা এবং ব্যবহৃত প্রযুক্তি সম্পর্কে ধারণা পাওয়া যায়। কিন্তু কাজটি কীভাবে হয়েছে, তা জানা যায় না।

হতে পারে, ওয়েবসাইটের পুরো নকশা আগে থেকেই তৈরি ছিল। ডেভেলপারের দায়িত্ব ছিল সেটিকে কোডে রূপ দেওয়া। আবার এমনও হতে পারে, মোবাইল সংস্করণের নেভিগেশন কিংবা ফর্মের জটিলতা সমাধান করতে তাঁকে আলাদা করে কাজ করতে হয়েছে। দুই ক্ষেত্রেই কাজের ধরন আলাদা। অথচ পোর্টফোলিওতে শুধু চূড়ান্ত ছবি থাকলে সেই পার্থক্য বোঝার উপায় নেই।

কেস স্টাডি এই জায়গাটিতে বাড়তি তথ্য দেয়। ইউএক্স গবেষণা ও পরামর্শদানকারী প্রতিষ্ঠান Nielsen Norman Group-এর পোর্টফোলিওবিষয়ক নির্দেশনাতেও কাজের প্রক্রিয়া, সিদ্ধান্তের কারণ এবং ব্যক্তিগত অবদান তুলে ধরার ওপর গুরুত্ব দেওয়া হয়েছে।

নির্দেশনাটি মূলত ইউএক্স ডিজাইন ও সংশ্লিষ্ট নিয়োগপ্রক্রিয়ার জন্য তৈরি। সব পেশার নিয়োগকারীর চাহিদা এক হবে, এমন নয়। তবে নিজের দায়িত্ব এবং সিদ্ধান্তের যুক্তি ব্যাখ্যা করার পদ্ধতিটি অন্য প্রযুক্তিনির্ভর কাজেও প্রাসঙ্গিক। এ জন্য প্রজেক্ট গ্যালারি বাদ দেওয়ার প্রয়োজন নেই। গ্যালারিতে কাজের সংক্ষিপ্ত পরিচিতি থাকুক। যে প্রকল্পগুলো সম্পর্কে বিস্তারিত বলার মতো তথ্য রয়েছে, সেগুলোর জন্য আলাদা পৃষ্ঠা তৈরি করতে পারেন।

সব প্রজেক্টের কেস স্টাডি বানাতে হবে না

পোর্টফোলিওতে অনেক কাজ থাকলে সবগুলো নিয়ে বিস্তারিত লেখার চেষ্টা না করাই ভালো। বিশেষ করে কাজগুলোর ধরন কাছাকাছি হলে একই বিষয় বারবার উঠে আসতে পারে। মনে করুন, একজন ডেভেলপারের তৈরি পাঁচটি ওয়েবসাইট রয়েছে। এর মধ্যে তিনটি সাধারণ তথ্যভিত্তিক ওয়েবসাইট। অন্য দুটির একটিতে মোবাইল ইন্টারফেসের জটিলতা সামলাতে হয়েছে, আরেকটিতে বিদ্যমান ডিজাইন সিস্টেম পরিবর্তন না করেই নতুন সুবিধা যুক্ত করতে হয়েছে।

শেষের দুটি প্রকল্প নিয়ে বিস্তারিত কেস স্টাডি তৈরি করার সুযোগ বেশি থাকতে পারে। সেখানে ভিন্ন পরিস্থিতিতে তাঁর নেওয়া সিদ্ধান্তগুলো দেখানো সম্ভব। অবশ্য কোনো কাজ জটিল হলেই সেটি ভালো কেস স্টাডি হবে, এমন নয়। প্রকল্পে আপনার নিজের দায়িত্ব স্পষ্ট হতে হবে। কাজটি কীভাবে করেছেন, তা ব্যাখ্যা করার মতো তথ্যও থাকা প্রয়োজন।

নতুনদের জন্য দুটি বা তিনটি নির্বাচিত প্রকল্প দিয়ে শুরু করা বাস্তবসম্মত হতে পারে। সংখ্যাটি বাধ্যতামূলক নয়। একটি প্রকল্পের পর্যাপ্ত তথ্য থাকলেও সেটি দিয়ে শুরু করা যায়। আরেকটি বিষয় ভেবে দেখুন। আপনি ভবিষ্যতে যে ধরনের কাজ করতে চান, নির্বাচিত প্রকল্পগুলো কি সেই দক্ষতা বোঝাতে সাহায্য করছে?

একজন ফ্রন্টএন্ড ডেভেলপার যদি ইন্টারফেস তৈরির কাজ পেতে চান, তাহলে ইন্টারফেসসংক্রান্ত সিদ্ধান্ত দেখানো তাঁর জন্য বেশি প্রাসঙ্গিক হতে পারে। একইভাবে একজন কনটেন্ট ক্রিয়েটরের পোর্টফোলিওতে গবেষণা, তথ্য সাজানো এবং সম্পাদনার কাজ দেখানোর সুযোগ থাকা উচিত।

সমস্যাটি আসলে কী ছিল?

কেস স্টাডির শুরুতে অনেক সময় লেখা হয়, ‘একটি আধুনিক ও ব্যবহারবান্ধব ওয়েবসাইট তৈরি করাই ছিল প্রকল্পের লক্ষ্য।’ কথাটি ভুল নয়। কিন্তু এতে আগের ব্যবস্থায় কী অসুবিধা ছিল, তা বোঝা যাচ্ছে না।

সমস্যার বিবরণে যতটা সম্ভব নির্দিষ্ট হওয়া দরকার। একটি অনলাইন দোকানের মোবাইল সংস্করণের কথা ভাবা যাক। সেখানে পণ্যের বিবরণ এমনভাবে সাজানো ছিল যে গুরুত্বপূর্ণ তথ্য দেখতে ব্যবহারকারীকে বারবার স্ক্রল করতে হচ্ছিল। এ অবস্থায় প্রকল্পটির লক্ষ্য হতে পারে পণ্যের তথ্য নতুনভাবে সাজানো, যাতে ছোট স্ক্রিনেও প্রয়োজনীয় বিবরণ সহজে খুঁজে পাওয়া যায়।

এখানে পরিবর্তনের প্রয়োজন বোঝা যাচ্ছে। কিন্তু আরও একটি প্রশ্ন রয়েছে। সমস্যাটি কীভাবে শনাক্ত হয়েছিল? হতে পারে, ডিজাইনার নিজের পর্যবেক্ষণ থেকে অসুবিধাটির কথা ভেবেছেন। আবার বাস্তব ব্যবহারকারীদের পরীক্ষায়ও সমস্যাটি পাওয়া যেতে পারে।

দুটি পরিস্থিতি এক নয়। নিজের পর্যবেক্ষণে কোনো সমস্যা মনে হলে সেটিকে প্রাথমিক ধারণা হিসেবে লিখুন। ব্যবহারকারী পরীক্ষার তথ্য থাকলে সেই পরীক্ষার বিবরণ উল্লেখ করুন। পরীক্ষা না করে ‘ব্যবহারকারী গবেষণায় সমস্যাটি পাওয়া গেছে’ লেখা উচিত নয়। প্রকল্পের লক্ষ্য, ব্যক্তিগত অনুমান এবং যাচাই করা সমস্যার মধ্যে এই পার্থক্য বজায় রাখলে পাঠক বুঝতে পারবেন, কোন সিদ্ধান্তের পেছনে কী ধরনের তথ্য ছিল।

দলীয় কাজে নিজের অবদান বোঝানো

ধরা যাক, পাঁচজনের একটি দল ওয়েব অ্যাপ্লিকেশন তৈরি করেছে। সেখানে আপনার দায়িত্ব ছিল লগইন ইন্টারফেস তৈরি, ফর্ম ভ্যালিডেশন যুক্ত করা এবং মোবাইল স্ক্রিনে লেআউট ঠিক রাখা। পোর্টফোলিওতে এই কাজগুলো সরাসরি লিখুন। পুরো অ্যাপ্লিকেশনের ছবি ব্যবহার করা যেতে পারে। কিন্তু অন্য সদস্যদের তৈরি ব্যাকএন্ড বা ডেটাবেজকে নিজের কাজ হিসেবে উপস্থাপন করবেন না।

দলীয় প্রকল্পে কাজ ভাগাভাগি হয়। তাই কে কোন অংশ করেছেন, সেটি পরিষ্কার থাকলে কেস স্টাডি পড়তে সুবিধা হয়। প্রকল্পের সীমাবদ্ধতার কথাও বলা যায়। হয়তো নির্দিষ্ট সময়ের মধ্যে কাজ শেষ করতে হয়েছে। বিদ্যমান ডিজাইন সিস্টেম পরিবর্তনের সুযোগ ছিল না কিংবা পুরোনো ব্রাউজারের সঙ্গে সামঞ্জস্য বজায় রাখা প্রয়োজন হয়েছিল।

এসব তথ্য থাকলে কাজের সিদ্ধান্তগুলো কোন পরিস্থিতিতে নেওয়া হয়েছে, তা বোঝা যায়। তবে প্রকল্পকে কঠিন দেখানোর জন্য বাস্তবে ছিল না এমন বাধার কথা লেখার প্রয়োজন নেই।

একটি সমাধান কেন বেছে নিলেন?

এবার একটি দীর্ঘ ফর্মের কথা ভাবুন। ব্যবহারকারীকে সেখানে অনেক তথ্য দিতে হয়। সব তথ্য একই পৃষ্ঠায় রাখা হবে, নাকি কয়েকটি ধাপে ভাগ করা হবে, সেই সিদ্ধান্ত নিতে হচ্ছে। দ্বিতীয় পদ্ধতিটি দেখতে বেশি গোছানো মনে হতে পারে। কিন্তু ব্যবহারকারীকে বারবার আগের ধাপে ফিরতে হলে তাতে নতুন অসুবিধাও তৈরি হতে পারে।

অন্যদিকে, তথ্যগুলো যৌক্তিকভাবে আলাদা করা গেলে কিছু ক্ষেত্রে ধাপে ধাপে ফর্ম পূরণ করা সুবিধাজনক হতে পারে। এখানে কোন বিকল্প ভালো হবে, তা ফর্মের উদ্দেশ্য, তথ্যের ধরন এবং ব্যবহারকারীর কাজের ওপর নির্ভর করছে।

কেস স্টাডিতে এই বিবেচনাগুলো লিখতে পারেন। কোন বিকল্পগুলো সামনে ছিল, শেষ পর্যন্ত কী বেছে নিয়েছেন এবং কেন, তা ব্যাখ্যা করুন। সুযোগ থাকলে বাস্তব ব্যবহারকারীদের দিয়ে বিকল্পগুলো পরীক্ষা করার তথ্যও যুক্ত করা যায়। প্রথমে নেওয়া সিদ্ধান্ত পরে পরিবর্তন করতে হলে সেই কারণটি লেখাও প্রাসঙ্গিক।

সব সিদ্ধান্ত সফল ছিল, এমন দেখানোর দরকার নেই। প্রকল্পের মাঝপথে কোনো ধারণা বদলাতে হলে কী কারণে বদলেছে, সেটি জানলেও কাজের প্রক্রিয়া সম্পর্কে ধারণা পাওয়া যায়।

একটি সাধারণ প্রকল্পের কেস স্টাডি কেমন হতে পারে?

এবার ছোট একটি উদাহরণ দেখা যাক। এটি সম্পূর্ণ কাল্পনিক, বাস্তব কোনো প্রকল্পের বিবরণ নয়। একটি অনলাইন বইয়ের দোকানের ওয়েবসাইট তৈরি করা হচ্ছে। প্রাথমিকভাবে ধারণা করা হয়েছে, মোবাইল সংস্করণে বইয়ের তালিকা থেকে প্রয়োজনীয় বই খুঁজে পাওয়া কঠিন হতে পারে। বিশেষ করে ফিল্টারের বিন্যাস নিয়ে অসুবিধা থাকার আশঙ্কা রয়েছে।

প্রকল্পে আপনার দায়িত্ব বইয়ের তালিকার ইন্টারফেস এবং ফিল্টার ব্যবস্থা তৈরি করা। কাজ শুরুর সময় দুটি বিকল্প বিবেচনা করা হলো। ফিল্টারগুলো তালিকার ওপরেই রাখা যেতে পারে। আবার আলাদা প্যানেলেও দেখানো সম্ভব।

ছোট স্ক্রিনে জায়গার ব্যবহার বিবেচনা করে আলাদা ফিল্টার প্যানেল তৈরির সিদ্ধান্ত নেওয়া হলো। এ পর্যন্ত কেস স্টাডিতে সমস্যার প্রাথমিক ধারণা, নিজের দায়িত্ব এবং নির্বাচিত সমাধানের যুক্তি দেখানো সম্ভব। কিন্তু কাজটি ব্যবহারযোগ্য হয়েছে কি না, তা এখনো জানা যায়নি।

সেটি যাচাই করতে দেখতে হবে, ফিল্টার প্যানেল ঠিকভাবে খুলছে কি না, অপশন নির্বাচন করলে ফলাফল বদলাচ্ছে কি না এবং কিবোর্ড দিয়েও ফিল্টার ব্যবহার করা যাচ্ছে কি না। মোবাইল ও ডেস্কটপে এসব পরীক্ষা করার পরিকল্পনা রাখা হয়েছে। কেস স্টাডিতে তৈরি ইন্টারফেসের ছবি, সংশ্লিষ্ট কোডের অংশ এবং পরীক্ষার পরিকল্পনা দেখানো যেতে পারে। পরীক্ষা সম্পন্ন হলে প্রকৃত ফলাফলও যুক্ত করা যাবে।

এখানে বিক্রি বৃদ্ধি কিংবা ব্যবহারকারীর সন্তুষ্টির কোনো কাল্পনিক পরিসংখ্যান দেওয়া হয়নি। কারণ, সেসব বিষয়ে তথ্য নেই। বাস্তব প্রকল্পের ক্ষেত্রেও এই সতর্কতা প্রয়োজন। কাজের প্রক্রিয়া বোঝাতে প্রতিটি ধাপে বড় কোনো ফলাফল দেখানোর বাধ্যবাধকতা নেই।

স্ক্রিনশট রাখুন, তবে কারণটাও লিখুন

কেস স্টাডিতে ছবি দেখানোর উদ্দেশ্য হওয়া উচিত কাজের পরিবর্তন বোঝানো। একজন ইউআই/ইউএক্স ডিজাইনার প্রাথমিক স্কেচ, ওয়্যারফ্রেম এবং চূড়ান্ত ইন্টারফেস পাশাপাশি রাখতে পারেন। এতে নকশা কীভাবে বদলেছে, তা দেখা যাবে। কিন্তু কেন বদলেছে, সেটি ছবির সঙ্গে লিখলে আরও পরিষ্কার হয়।

একটি অ্যাপের পুরোনো ও নতুন নেভিগেশন মেনুর ছবি দেখানোর কথা ভাবুন। সেখানে কোন সমস্যাটি সমাধানের চেষ্টা করা হয়েছে এবং নতুন বিন্যাসে কী পরিবর্তন এসেছে, তা সংক্ষেপে ব্যাখ্যা করা যায়। ডেভেলপারদের ক্ষেত্রে কোডের প্রাসঙ্গিক অংশ, সিস্টেমের গঠনের চিত্র কিংবা পরিবর্তনের আগের ও পরের ইন্টারফেস কাজে আসতে পারে।

তবে বড় কোডের স্ক্রিনশট সব সময় পাঠযোগ্য হয় না। প্রয়োজন হলে সংশ্লিষ্ট অংশ কোড ব্লকে দেখানো ভালো। একই ধরনের অনেক ছবি রাখার দরকার নেই। কোন ছবিটি কাজের সিদ্ধান্ত বোঝাতে সাহায্য করছে, সেটি বিবেচনা করে নির্বাচন করুন। ছবির সঙ্গে অল্প কয়েকটি বাক্য থাকলেই অনেক সময় যথেষ্ট। পোর্টফোলিওর পাঠক যেন বুঝতে পারেন, ঠিক কোন পরিবর্তনটি দেখানো হচ্ছে।

ফলাফল নেই বলে বড় দাবি তৈরি করবেন না

কোনো প্রকল্পের শেষে কী অর্জিত হয়েছে, তা জানতে পাঠকের আগ্রহ থাকবে। কিন্তু ফলাফল দেখানোর নামে যাচাই করা হয়নি এমন দাবি যুক্ত করা ঠিক নয়। মনে করুন, পোর্টফোলিওতে লেখা হয়েছে, ‘ওয়েবসাইটের পারফরম্যান্স উল্লেখযোগ্যভাবে উন্নত হয়েছে।’ এখানে উন্নতির বিষয়টি কীভাবে নির্ধারণ করা হয়েছে, তা জানা প্রয়োজন।

পরিবর্তনের আগে ও পরে প্রকৃত পরীক্ষা করা হলে তার ফলাফল উল্লেখ করুন। পরীক্ষার পদ্ধতি ও পরিবেশও জানাতে হবে। ভিন্ন ডিভাইস, নেটওয়ার্ক কিংবা পরীক্ষার অন্য শর্তে পাওয়া ফলাফল সরাসরি তুলনা করলে বিভ্রান্তি তৈরি হতে পারে।

ব্যবহারকারীর অভিজ্ঞতার ক্ষেত্রেও একই কথা প্রযোজ্য। কোনো অসুবিধা শনাক্ত করার পর নকশা পরিবর্তন করা হয়েছে এবং পুনরায় পরীক্ষা করে উন্নতি পাওয়া গেছে, এমন হলে সেই পর্যবেক্ষণ লিখুন। কিন্তু পরীক্ষা না করা হলে কী করবেন?

সে ক্ষেত্রে কী তৈরি হয়েছে এবং কোন নির্ধারিত শর্ত পূরণ করা হয়েছে, সেটিই দেখান। যেমন, মোবাইল নেভিগেশনের লেআউট পরিবর্তন করে নির্দিষ্ট স্ক্রিনের আকারে পরীক্ষা করা হয়ে থাকলে সেই তথ্য উল্লেখ করা যায়। তবে পরিবর্তনটির কারণে ব্যবসার বিক্রি বেড়েছে দাবি করতে হলে আরও প্রমাণ প্রয়োজন। একই সময়ে ওয়েবসাইট পরিবর্তন ও বিক্রি বৃদ্ধি ঘটলেই একটি অন্যটির কারণ হিসেবে প্রতিষ্ঠিত হয় না।

ব্যক্তিগত বা শিক্ষার্থী প্রকল্পে অনেক সময় ব্যবসায়িক ফলাফল থাকে না। সে ক্ষেত্রে কী কাজ সম্পন্ন হয়েছে, কী পরীক্ষা করা হয়েছে এবং কোন বিষয়গুলো এখনো যাচাই করা বাকি, তা পরিষ্কার রাখাই যথেষ্ট।

আরও পড়ুন: রিমোট জব খোঁজার আগে নিজের টাইম জোন ও যোগাযোগের দক্ষতা যাচাই করুন

পেশাভেদে কী ধরনের তথ্য দেখাবেন?

একজন ফ্রন্টএন্ড ডেভেলপার এবং একজন কনটেন্ট ক্রিয়েটরের কাজের ধরন আলাদা। তাঁদের পোর্টফোলিওতেও সেই পার্থক্য থাকা স্বাভাবিক। ফ্রন্টএন্ড ডেভেলপারদের ক্ষেত্রে রেসপনসিভ ডিজাইন, কোডের গঠন, ব্যবহারকারীর ইন্টারঅ্যাকশন এবং পারফরম্যান্সসংক্রান্ত সিদ্ধান্ত প্রাসঙ্গিক হতে পারে। ইউআই/ইউএক্স ডিজাইনারের জন্য ব্যবহারকারীর সমস্যা, গবেষণার তথ্য, নকশার পরিবর্তন এবং ব্যবহারযোগ্যতা পরীক্ষার বিবরণ বেশি অর্থবহ।

সফটওয়্যার প্রকৌশলীরা প্রযুক্তিগত সমস্যার কারণ, সিস্টেমের গঠন, বিকল্প সমাধান এবং পরীক্ষার তথ্য দেখাতে পারেন। কনটেন্ট ক্রিয়েটরদের কেস স্টাডিতে আবার গবেষণা ও সম্পাদনার প্রক্রিয়া বেশি গুরুত্ব পেতে পারে। কোন পাঠকের জন্য কনটেন্ট তৈরি করা হয়েছে, তথ্য কীভাবে সংগ্রহ ও সাজানো হয়েছে এবং সম্পাদনার সময় কী সিদ্ধান্ত নিতে হয়েছে, তা ব্যাখ্যা করা যায়।

প্রকাশিত কনটেন্টের মূল্যায়নের তথ্য থাকলে সেটিও যুক্ত করা যেতে পারে। ফ্রিল্যান্সারদের ক্ষেত্রে ক্লায়েন্টের চাহিদা বোঝা, কাজের পরিধি নির্ধারণ এবং নিজের দায়িত্ব সম্পন্ন করার প্রক্রিয়া দেখানোর সুযোগ রয়েছে। কোন পেশার জন্য একটি নির্দিষ্ট কাঠামো বাধ্যতামূলক নয়। কাজের ধরন অনুযায়ী প্রাসঙ্গিক তথ্য বেছে নিতে হবে।

শিক্ষার্থীরা ক্লায়েন্টের কাজ না থাকলে কী করবেন?

ক্যারিয়ার শুরুর আগে অনেক শিক্ষার্থীর কাছে বাস্তব ক্লায়েন্টের প্রকল্প থাকে না। সে ক্ষেত্রে বিশ্ববিদ্যালয়ের অ্যাসাইনমেন্ট, ব্যক্তিগত প্রকল্প কিংবা ওপেন সোর্সে অবদান রাখার কাজ ব্যবহার করা যায়। একজন শিক্ষার্থী লাইব্রেরি ব্যবস্থাপনার ওয়েব অ্যাপ তৈরি করে থাকলে সেখানে প্রযুক্তি নির্বাচনের কারণ, ডেটা ব্যবস্থাপনার পদ্ধতি এবং পরীক্ষার বিবরণ দেখাতে পারেন। কিন্তু প্রকল্পটি কোনো প্রতিষ্ঠানের জন্য তৈরি না হলে সেটিকে বাণিজ্যিক কাজ হিসেবে উপস্থাপন করবেন না।

শিক্ষার্থী প্রকল্পে বাস্তব ব্যবহারকারী, বাজেট কিংবা প্রতিষ্ঠানের পরিচালনাগত সীমাবদ্ধতা নাও থাকতে পারে। সেটি স্বীকার করতে অসুবিধা নেই। কাল্পনিক ব্যবহারকারীকে কেন্দ্র করে কোনো অ্যাপের নকশা তৈরি করলে সেটিকে প্রকৃত ব্যবহারকারী গবেষণার ফলাফলও বলা উচিত নয়।

এ ধরনের পোর্টফোলিওতে নিজের প্রযুক্তিগত সিদ্ধান্ত, কাজের প্রমাণ এবং প্রকল্পের সীমাবদ্ধতা পরিষ্কারভাবে তুলে ধরার সুযোগ রয়েছে।

কেস স্টাডির পৃষ্ঠা সাজাতে গিয়ে অকারণে জটিল করবেন না

ওয়েবসাইটের হোমপেজে নির্বাচিত প্রকল্পগুলোর সংক্ষিপ্ত পরিচিতি রাখতে পারেন। সেখান থেকে বিস্তারিত পৃষ্ঠায় যাওয়ার ব্যবস্থা থাকলে আগ্রহী পাঠক পুরো কেস স্টাডি দেখতে পারবেন। বিস্তারিত পৃষ্ঠার শুরুতে প্রকল্পটির নাম, কাজের ধরন এবং উদ্দেশ্য জানান। এরপর সমস্যার বিবরণ ও নিজের দায়িত্ব তুলে ধরুন।

কাজের প্রক্রিয়া ব্যাখ্যা করতে গিয়ে কোন বিকল্পগুলো বিবেচনা করেছিলেন এবং কেন নির্দিষ্ট সমাধান বেছে নিয়েছেন, তা লিখুন। প্রাসঙ্গিক ছবি, প্রোটোটাইপ, লাইভ ডেমো কিংবা প্রকাশের অনুমতি রয়েছে এমন কোড যুক্ত করা যেতে পারে।

শেষে প্রকৃত ফলাফল এবং অসম্পূর্ণ বিষয়গুলো উল্লেখ করুন। প্রতিটি প্রকল্পে এই ক্রম হুবহু অনুসরণ করতে হবে, এমন নয়। কোনো প্রকল্পে গবেষণার তথ্য বেশি জায়গা পেতে পারে, আবার কোথাও প্রযুক্তিগত সিদ্ধান্তের ব্যাখ্যা বেশি প্রয়োজন হতে পারে। ওয়েবসাইটটি পড়তে সুবিধা হচ্ছে কি না, সেটিও দেখতে হবে।

মোবাইল স্ক্রিনে ছোট ফন্ট, বড় ছবি, দীর্ঘ অনুচ্ছেদ কিংবা অতিরিক্ত অ্যানিমেশন সমস্যা তৈরি করতে পারে। তাই প্রকাশের আগে মোবাইল ও ডেস্কটপে পৃষ্ঠাগুলো খুলে পরীক্ষা করা ভালো। প্রয়োজনীয় লিংকগুলো কাজ করছে কি না, প্রজেক্ট কার্ড থেকে বিস্তারিত পৃষ্ঠায় যাওয়া যাচ্ছে কি না এবং কিবোর্ড দিয়েও নেভিগেশন ব্যবহার করা যাচ্ছে কি না, দেখুন।

তথ্যবহুল ছবিতে যথাযথ বিকল্প বিবরণ বা Alt Text যোগ করুন। জটিল চিত্রে গুরুত্বপূর্ণ তথ্য থাকলে লেখার মাধ্যমেও ব্যাখ্যা দিন। তবে সব ছবির জন্য বর্ণনামূলক Alt Text প্রয়োজন হয় না। সম্পূর্ণ অলংকারমূলক ছবির ক্ষেত্রে HTML-এ খালি Alt Text ব্যবহার করা উপযুক্ত। এতে স্ক্রিন রিডার ব্যবহারকারীদের অপ্রয়োজনীয় বিবরণ শুনতে হয় না। কাজের পরিবর্তন বোঝাতে স্থির ছবি ও সংক্ষিপ্ত ব্যাখ্যা যথেষ্ট হলে আলাদা অ্যানিমেশন যোগ করার প্রয়োজন নেই।

ক্লায়েন্টের কাজ প্রকাশের আগে যা যাচাই করবেন

ফ্রিল্যান্সার ও চাকরিজীবীদের পোর্টফোলিওতে গোপনীয়তার বিষয়টি বিশেষ গুরুত্ব পায়। কোনো প্রতিষ্ঠানের প্রকল্পে কাজ করেছেন বলেই তার সব নথি, নকশা বা কোড ব্যক্তিগত ওয়েবসাইটে প্রকাশ করা যাবে, এমন নয়। অপ্রকাশিত পণ্যের নকশা, গ্রাহকের তথ্য, অভ্যন্তরীণ প্রতিবেদন, ব্যক্তিগত ডেটা কিংবা গোপন কোড প্রকাশের আগে সংশ্লিষ্ট অনুমতি ও চুক্তির শর্ত যাচাই করতে হবে।

বিশেষ করে গোপনীয়তা চুক্তি বা Non-disclosure Agreement (NDA) থাকলে কোন তথ্য প্রকাশ করা যাবে, তা চুক্তির শর্ত এবং প্রযোজ্য আইনের ওপর নির্ভর করতে পারে। শুধু প্রতিষ্ঠানের নাম মুছে ফেললেই কোনো নথি প্রকাশযোগ্য হয়ে যায় না। নকশা, প্রকল্পের বিবরণ কিংবা অন্য তথ্য থেকেও গোপন বিষয় শনাক্ত করা সম্ভব হতে পারে।

প্রয়োজনে সংবেদনশীল তথ্য বাদ দিয়ে সমস্যার সাধারণ ধরন ও নিজের দায়িত্ব ব্যাখ্যা করতে পারেন। তাতেও গোপন তথ্য প্রকাশের আশঙ্কা থাকলে সংশ্লিষ্ট প্রতিষ্ঠানের অনুমতি নেওয়া প্রয়োজন। অনুমতি না পাওয়া গেলে প্রকাশের অধিকার রয়েছে এমন ব্যক্তিগত প্রকল্প ব্যবহার করাই যুক্তিসংগত। পোর্টফোলিওতে নিজের কাজের প্রমাণ দেখাতে গিয়ে অন্যের গোপন তথ্য প্রকাশ করা গ্রহণযোগ্য নয়।

পোর্টফোলিও তৈরির জন্য কোন প্ল্যাটফর্ম উপযুক্ত?

নিজস্ব কোড, কনটেন্ট ম্যানেজমেন্ট সিস্টেম কিংবা ভিজ্যুয়াল ওয়েবসাইট বিল্ডার দিয়ে পোর্টফোলিও তৈরি করা যায়। কোন পদ্ধতিটি ব্যবহার করবেন, তা নির্ভর করবে কাজের ধরন এবং ওয়েবসাইটে কী ধরনের সুবিধা প্রয়োজন তার ওপর। ওয়েব ডেভেলপাররা নিজস্ব কোডে পোর্টফোলিও তৈরি করে তাঁদের অতিরিক্ত দক্ষতা দেখাতে পারেন। তবে ওয়েবসাইটে সার্ভার-সাইড কার্যক্রম প্রয়োজন হলে হোস্টিংয়ের সীমাবদ্ধতা বিবেচনা করতে হবে।

GitHub Pages ব্যবহার করে স্ট্যাটিক ওয়েবসাইট প্রকাশ করা সম্ভব। HTML, CSS ও JavaScript-ভিত্তিক সাইট এবং উপযুক্ত স্ট্যাটিক সাইট জেনারেটর দিয়ে তৈরি পৃষ্ঠা এখানে প্রকাশ করা যায়। তবে GitHub Pages সরাসরি PHP, Python বা Ruby-এর মতো সার্ভার-সাইড ভাষা চালানোর সুবিধা দেয় না। সার্ভারে নিজস্ব কোড চালাতে হলে আলাদা ব্যবস্থা প্রয়োজন হতে পারে।

GitHub Free পরিকল্পনায় পাবলিক রিপোজিটরি থেকে GitHub Pages ব্যবহার করা যায়। কিছু পেইড পরিকল্পনায় প্রাইভেট রিপোজিটরি থেকেও প্রকাশের সুবিধা রয়েছে। তাই নিজের অ্যাকাউন্টের পরিকল্পনা ও প্রযোজ্য শর্ত আগে দেখে নেওয়া উচিত। নিজস্ব ডোমেইন ব্যবহার করা সম্ভব হলেও ডোমেইনটির নিয়ন্ত্রণ থাকতে হবে এবং প্রয়োজনীয় DNS সেটিং ঠিকভাবে করতে হবে। ডোমেইন নিবন্ধনের আলাদা খরচও থাকতে পারে।

অন্যদিকে, ডিজাইনার বা কনটেন্ট ক্রিয়েটরদের জন্য সহজে পৃষ্ঠা সম্পাদনা করা যায় এমন প্ল্যাটফর্ম বেশি সুবিধাজনক হতে পারে। প্ল্যাটফর্ম বাছাইয়ের সময় কেস স্টাডি সম্পাদনা, ছবি ব্যবস্থাপনা, মোবাইল উপযোগিতা এবং ভবিষ্যতে তথ্য অন্যত্র নেওয়ার সুযোগ রয়েছে কি না, দেখে নিন।

পেইড টেমপ্লেট বা অতিরিক্ত ফিচার কেনার আগে সেগুলোর প্রয়োজন বুঝে নেওয়া ভালো। কেস স্টাডির মূল তথ্য অসম্পূর্ণ রেখে জটিল ডিজাইন বা অ্যানিমেশনে বেশি সময় ও অর্থ ব্যয় করার যুক্তি নেই।

পুরোনো পোর্টফোলিও নতুনভাবে সাজাবেন যেভাবে

আগে থেকেই পোর্টফোলিও ওয়েবসাইট থাকলে পুরো ডিজাইন বদলানোর প্রয়োজন নাও হতে পারে। শুরুতে এমন একটি প্রকল্প নির্বাচন করুন, যেটির কাজ ও সিদ্ধান্ত সম্পর্কে আপনার কাছে যথেষ্ট তথ্য রয়েছে। এবার বর্তমান বিবরণটি পড়ুন। সমস্যার ব্যাখ্যা কি সেখানে আছে? নিজের দায়িত্ব বোঝা যাচ্ছে? কোন সিদ্ধান্তের পেছনে কী যুক্তি ছিল, সেটি কি উল্লেখ করেছেন? ফলাফল নিয়ে কোনো দাবি থাকলে তার প্রমাণ রয়েছে?

যেখানে তথ্যের ঘাটতি আছে, শুধু সেই অংশগুলো ঠিক করুন। প্রয়োজন অনুযায়ী প্রাসঙ্গিক ছবি, প্রকাশের অনুমতি রয়েছে এমন নথি এবং প্রকৃত পরীক্ষার বিবরণ যোগ করতে পারেন। অপ্রয়োজনীয় প্রযুক্তির তালিকা, একই ধরনের অনেক স্ক্রিনশট কিংবা দীর্ঘ ব্যাখ্যা বাদ দিলেও পৃষ্ঠাটি পড়তে সহজ হতে পারে।

কেস স্টাডিটি সম্পাদনা করার পর অন্য কাউকে পড়তে দিন। তিনি প্রকল্পের সমস্যা, আপনার দায়িত্ব এবং নির্বাচিত সমাধান বুঝতে পারছেন কি না, জানতে চান। কোনো অংশ অস্পষ্ট মনে হলে সেটি আবার সংশোধন করুন। একটি ভালো Portfolio website guide থেকে ওয়েবসাইট তৈরির কাঠামো জানা যায়। কিন্তু নিজের কাজের কোন দিকগুলো সামনে আনবেন, সেই সিদ্ধান্ত আপনাকেই নিতে হবে।

পোর্টফোলিওর সব প্রকল্প একসঙ্গে নতুনভাবে সাজানোর চেষ্টা না করে এমন একটি কাজ দিয়ে শুরু করুন, যেটিতে নিজের ভূমিকা ও সিদ্ধান্তগুলো পরিষ্কারভাবে ব্যাখ্যা করতে পারবেন। প্রকল্পটির সমস্যা, নেওয়া সিদ্ধান্ত এবং যাচাইকৃত ফলাফল গোছানোর পর দেখুন, পাঠক আপনার কাজ সম্পর্কে আগের চেয়ে বেশি কিছু জানতে পারছেন কি না। সেটি সম্ভব হলে অন্য প্রকল্পগুলোও একইভাবে পর্যালোচনা করা যাবে।

প্রায়শই জিজ্ঞাসিত প্রশ্ন

১. পোর্টফোলিওতে অসম্পূর্ণ প্রজেক্ট রাখা কি ঠিক হবে?

অসম্পূর্ণ প্রকল্পও পোর্টফোলিওতে রাখা যায়, যদি সেখানে আপনার উল্লেখযোগ্য কাজ থাকে এবং সেটি ব্যাখ্যা করার মতো তথ্য পাওয়া যায়। তবে প্রকল্পটি সম্পূর্ণ হয়েছে, এমন ধারণা দেওয়া উচিত নয়। কোন অংশের কাজ শেষ হয়েছে, কোন সিদ্ধান্তগুলো নিয়েছেন এবং কী কী পরীক্ষা করা বাকি রয়েছে, তা উল্লেখ করুন। শুধু প্রাথমিক ধারণা বা অসম্পূর্ণ নকশা থাকলে সেটিকে পূর্ণাঙ্গ কেস স্টাডি হিসেবে দেখানোর প্রয়োজন নেই।

২. প্রজেক্টের লাইভ ডেমো কাজ না করলে পোর্টফোলিওতে কী করবেন?

লাইভ ডেমো বন্ধ থাকলে প্রথমে লিংকটি ঠিক করা সম্ভব কি না, দেখুন। প্রকল্পটি আর অনলাইনে চালু না থাকলে পুরোনো বা অকার্যকর লিংক রেখে দেওয়ার পরিবর্তে স্পষ্টভাবে বিষয়টি জানান। প্রকাশের অনুমতি রয়েছে এমন স্ক্রিনশট, ভিডিও বা প্রকল্পের বিবরণ দিয়ে কাজটি দেখানো যেতে পারে। এতে পাঠক অন্তত বুঝতে পারবেন, প্রকল্পে কী তৈরি করা হয়েছিল এবং আপনার দায়িত্ব কী ছিল।

৩. পোর্টফোলিওতে প্রতিটি প্রজেক্টের GitHub লিংক দেওয়া কি বাধ্যতামূলক?

না, প্রতিটি প্রকল্পের GitHub লিংক দেওয়া বাধ্যতামূলক নয়। ব্যক্তিগত বা ওপেন সোর্স প্রকল্পের কোড প্রকাশযোগ্য হলে রিপোজিটরির লিংক যুক্ত করা যেতে পারে। তবে ক্লায়েন্টের মালিকানাধীন বা গোপনীয় কোড অনুমতি ছাড়া প্রকাশ করা উচিত নয়। কোড দেখানো সম্ভব না হলে প্রকল্পে নিজের দায়িত্ব, প্রযুক্তিগত সিদ্ধান্ত এবং প্রকাশযোগ্য কাজের নমুনা দিয়ে দক্ষতা ব্যাখ্যা করতে পারেন।

৪. একই পোর্টফোলিও দিয়ে চাকরি ও ফ্রিল্যান্স কাজের জন্য আবেদন করা যাবে?

একই পোর্টফোলিও ব্যবহার করা সম্ভব। তবে চাকরির নিয়োগকারী এবং সম্ভাব্য ফ্রিল্যান্স ক্লায়েন্টের তথ্যের চাহিদা সব সময় এক হবে না। চাকরির আবেদনে প্রযুক্তিগত দক্ষতা, দলীয় দায়িত্ব ও সিদ্ধান্তের প্রক্রিয়া বেশি প্রাসঙ্গিক হতে পারে। অন্যদিকে, ফ্রিল্যান্স ক্লায়েন্ট কাজের পরিধি, চাহিদা বোঝার পদ্ধতি এবং সম্পন্ন প্রকল্প সম্পর্কে জানতে চাইতে পারেন। তাই আবেদন অনুযায়ী প্রাসঙ্গিক কেস স্টাডিগুলো সামনে রাখা ভালো।

৫. আন্তর্জাতিক ক্লায়েন্টের জন্য পোর্টফোলিও বাংলা নাকি ইংরেজিতে তৈরি করবেন?

এটি মূলত আপনার লক্ষ্য পাঠকের ওপর নির্ভর করবে। আন্তর্জাতিক ক্লায়েন্ট বা ইংরেজিভাষী প্রতিষ্ঠানের সঙ্গে কাজ করতে চাইলে ইংরেজিতে পোর্টফোলিও রাখা ব্যবহারিক হতে পারে। বাংলাদেশের বাংলা ভাষাভাষী ক্লায়েন্টদের জন্য কাজ করলে বাংলাতেও প্রকল্পের বিবরণ দেওয়া যায়। দুই ধরনের পাঠকের জন্য পোর্টফোলিও তৈরি করলে আলাদা ভাষার সংস্করণ রাখা সম্ভব। তবে যে ভাষাই ব্যবহার করুন, প্রকল্পের সমস্যা, নিজের দায়িত্ব এবং কাজের ফলাফল যেন পরিষ্কারভাবে বোঝা যায়।