আমার (অ-প্রযুক্তিগত) সহকর্মী আমাদের বর্তমানে একটি নতুন প্রকল্পের জন্য গ্যান্ট চার্টের হুমকি দিয়েছেন। এটি আমাদের জন্য কী সরবরাহ করার সম্ভাবনা রয়েছে এবং এটি কী সহায়ক সরঞ্জাম হবে?
আমার (অ-প্রযুক্তিগত) সহকর্মী আমাদের বর্তমানে একটি নতুন প্রকল্পের জন্য গ্যান্ট চার্টের হুমকি দিয়েছেন। এটি আমাদের জন্য কী সরবরাহ করার সম্ভাবনা রয়েছে এবং এটি কী সহায়ক সরঞ্জাম হবে?
উত্তর:
যেমন উইকিপিডিয়া বলেছে এটি গ্যান্ট চার্ট এক ধরণের বার চার্ট (প্রায়শই "লাইন টাইপ") যা প্রকল্প পরিকল্পনায় সহায়তা করে। এটি প্রায়শই দেওয়ালে একটি বড় (সত্যই বড়) কাগজের টুকরোটিতে ম্যানুয়ালি আঁকানো হয়, যেহেতু এটি সহজেই সেই ফর্ম্যাটে পরিবর্তিত হয়।
এটি একটি খুব সাধারণ ধরণের পরিকল্পনা সরঞ্জাম; আপনি এটি এক্সেল বা কিছু সমমানের মধ্যে উত্পাদন করতে পারেন; এবং বরং কার্যকর, যতক্ষণ না প্রকল্পের নির্দিষ্ট ধাপগুলির জন্য প্রয়োজনীয় সময় সম্পর্কে মোটামুটি অনুমান করা যায়। যদি কোনও বিলম্ব হয় - সমস্যা নেই - একটি লাইন দীর্ঘায়িত হয়ে যায়, অন্যগুলি একই থাকে এবং আপনার প্রকল্পের একটি নতুন সমাপ্তি তারিখ থাকে।
ওভারল্যাপিং পর্যায়গুলি (সময় অনুসারে) সহজেই এটিতে দেখা যায়, অন্য পর্বের শেষের উপর নির্ভর করে একটি পর্ব শুরু করার নির্ভরতা হিসাবে সহজেই।
'সত্যিই এটি আছে।
অবশ্যই, গ্যান্টের সমস্যা (বা "টাইম চার্ট" হিসাবে এটি সাধারণত বিশ্বের আমার অংশে বলা হয়) এটি হ'ল, কোনও প্রকল্পের শুরুতে আপনারা প্রাচীরের উপর সুন্দরভাবে আঁকেন এবং উত্সাহ বোধ করেন feeling এবং খুশি, ... তারপরে একটি বিলম্ব ঘটে, এবং আপনি এটি চার্টে পরিবর্তন করেন এবং আপনি এখনও খুশি হচ্ছেন ... তারপরে আর একটি বিলম্ব ঘটে, আপনি আবার এটি আঁকেন, এবং আপনি এখনও বেশ ভাল বোধ করছেন .. 100x বিলম্ব ঘটে ... আপনি _______ (সেন্সর করা) এর মতো অনুভব করছেন।
অর্থ, আপনি যদি সেই ছোট্ট সময়সীমার সাথে সংযুক্ত থাকেন তবে এটি কেবলমাত্র একটি ভাল প্রকল্প পরিকল্পনার সরঞ্জাম। তাই এখানে সময় নষ্ট করা বন্ধ করুন এবং কাজ করুন!
একটি ভাল উত্পাদিত এবং রক্ষণাবেক্ষণ করা গ্যান্ট চার্ট দুর্দান্ত সরঞ্জাম হতে পারে। মূল কার্যকারিতাটি দেখায় যে কোন কাজগুলি অন্যান্য কাজের উপর নির্ভরশীল, প্রজেক্টটি কীভাবে বিলম্বের দ্বারা প্রভাবিত হতে পারে তা পূর্বাভাস দেওয়া এবং নষ্ট ঘন্টা হাইলাইট করে কারণ আপনি অন্য কোনও কিছুর জন্য অপেক্ষা করেছিলেন।
আমি সফটওয়্যার প্রকল্প পরিচালনার জন্য অতীতে সাফল্যের সাথে গ্যান্ট চার্ট ব্যবহার করেছি। আমি লোকদের হতাশায় তাদের ত্যাগ করতেও দেখেছি।
যে কোনও প্রকল্প পরিচালনার সরঞ্জাম কেবল তখনই কার্যকর যখন যদি কেউ আসলে জিজ্ঞাসা করে এমন প্রশ্নের উত্তর দেয় answ আমার ক্ষেত্রে, আমাকে ক্রমাগত দুটি প্রশ্ন জিজ্ঞাসা করা হত, এবং আমার গ্যান্ট চার্ট এর উত্তর দিতে পারে:
সুতরাং গ্যান্ট চার্টটি কার্যকর হওয়ার জন্য কোন কারণগুলির প্রয়োজন?
এটা সুস্পষ্ট হওয়া উচিত। যদি কেবল একজন দলের সদস্য থাকেন, তবে আপনার কেবলমাত্র একটি কলামের কাজের তালিকা দরকার। আপনি কেবল একের পর এক সেগুলি করতে যাচ্ছেন।
এটি অন্য সুস্পষ্ট বক্তব্যের মতো মনে হচ্ছে, তবে আপনি অবাক হবেন যে কতগুলি সফ্টওয়্যার প্রকল্পগুলি কার্যগুলিতে বিভক্ত হওয়ার পক্ষে যথেষ্ট সংজ্ঞাযুক্ত নয়। আপনার প্রকৃতপক্ষে একটি সম্মুখ স্পেসিফিকেশন এবং কিছুটা ডিগ্রি অফফ্রন্ট ডিজাইনের প্রয়োজন হবে। কিছু চতুর / চরম পদ্ধতিতে আপনি একটি গ্যান্ট চার্ট ব্যবহার করতে পারেন নি, কারণ পরবর্তী 3 সপ্তাহের পুনরাবৃত্তিতে কোন কাজগুলি হবে তা আপনি জানেন না।
কেউ কেউ জিনিসটি বজায় রাখতে সময় লাগবে। প্রায়শই, কেউ বিস্তারিত গ্যান্ট চার্ট তৈরি করতে দিন ব্যয় করে, তবে এটিকে অবহেলা করে। হয়তো সে এক মাস পরে তা বের করে আনবে, ঘাবড়ে যাবে এবং হেসে ফেলে ফেলবে, আর কখনও এ বিষয়ে কথা বলবে না।
একবার আপনার কাছে কার্যগুলি এবং সর্বোত্তম অনুমানের পরে, আপনি সেগুলি চার্টে রাখবেন। এবং যখন প্রথম টাস্কটি শেষ হয়ে যায়, আপনাকে চার্টে চিহ্নিত করতে হবে এবং তারপরে আপনার অনুমানটি ভুল ছিল তার জন্য ক্ষতিপূরণ দেওয়ার জন্য চারপাশে অন্যান্য সমস্ত কাজকে জিগ্গল করতে হবে। এবং দু'দিন পরে আপনি এটি আবার করবেন। এবং তারপরে আবার, আরও দু'দিন পরে। এবং অবশ্যই, যখন দেখা যাচ্ছে আপনি কোনও কিছু ভুলে গেছেন বা কোনও ত্রুটি উপস্থিত হয়, আপনাকে নতুন কার্যগুলি চার্টে রেখে দিতে হবে।
এটি চলমান সময়ের প্রতিশ্রুতিবদ্ধ মনে হতে পারে এবং আপনি ঠিক বলেছেন। এটি করার অনুপ্রেরণা কোথা থেকে আসে?
আমি যে সময়টি গ্যান্ট চার্টটি সফলভাবে ব্যবহার করেছি সে সময় ছিল সাপ্তাহিক প্রকল্প পরিচালনার সভাগুলি meetings ম্যানেজার কক্ষের আশেপাশে প্রতিটি দলনেতাকে তাদের প্রকল্পটি কখন সরবরাহ করা হবে তা জানাতে বলতেন। যদি কোনও প্রকল্প পিছনে চলতে থাকে তবে সংস্থানগুলি পুনরায় স্থানান্তরিত হবে। প্রথম দুটি বৈঠকের জন্য আমি হঠকারী হয়ে উঠব যে কখন ডেলিভারি হবে তা আমি সত্যিই জানতাম না এবং "তিন মাসের মধ্যে" একটি অস্পষ্টতার সাথে উপস্থিত হব। এর বিব্রতকরতা আমাকে আমার কৌশল বদলাতে এবং অভিশাপের বিষয়টি নিশ্চিত করে তোলে যে আমার কাছে একটি গ্যান্ট চার্ট ছিল যা প্রতি সভার আগেই আপ-টু-ডেট এবং সঠিক ছিল।
পার্শ্ব প্রতিক্রিয়া হিসাবে, এটি আমার প্রকল্পটিকে আরও সুসংহত এবং আরও দক্ষ করে তুলেছে এবং আমার দলের সদস্যরা আরও উত্সাহিত।
ট্র্যাকিং গ্যান্টসের চেয়ে আজকের মতো প্রকল্প পরিকল্পনাকে অপ্রচলিত করে তোলার জন্য কোনও একক আবিষ্কারের বেশি creditণের দাবি নেই। ট্র্যাকিং গ্যান্টসকে কেবল ক্ষতিকারক হিসাবে বিবেচনা করা উচিত নয় - এগুলিকে মন্দ হিসাবে বিবেচনা করা উচিত। কারণটা এখানে.
কারণ # 1: তাদের অনুপ্রেরণা
ট্র্যাকিং গ্যান্টস আপনাকে আপনার পরিকল্পনার প্রতিটি পদক্ষেপের জন্য আপনাকে দেখতে দেয় যে এটি কতটা সময় নিবে এবং আসলে এটি কতটা সময় নিচ্ছে। আপনি জানতে পারবেন, প্রতিদিন এবং স্ট্যাটাস মিটিংয়ে, এই ধাপ এক্সটির মার্চ মাসের মধ্যেই শুরু হওয়ার কথা ছিল, তবে এটি স্পষ্টভাবে মে পর্যন্ত শুরু হবে না। অসাধারণ. আপনি ইতিমধ্যে জানতেন, আপনি যখন প্রাথমিক পরিকল্পনা করেছিলেন, তখন প্রকল্পটির অগ্রগতির সাথে সাথে পরিকল্পনার পরিবর্তন হতে চলেছে। নতুন তথ্য প্রকাশ্যে আসে। জনগণ এবং সংস্থানসমূহ অপ্রত্যাশিত, ইত্যাদি So তাই প্রতিটি স্থিতির বৈঠকে আপনার জীবনের প্রাথমিক ভবিষ্যদ্বাণীগুলি সত্যিকারের জীবনে কতটা খারাপ?
কারণ # 2: তারা আপনাকে মূল পরিকল্পনায় লেগে যেতে বাধ্য করে
কোনও প্রকল্পের গ্যান্ট চার্ট ট্র্যাক করার খুব ধারণার অর্থ হ'ল নতুন তথ্যের উপর ভিত্তি করে আপনার কাজের পরিকল্পনাটি নিয়মিত মানিয়ে নেওয়ার পরিবর্তে আপনি একটি পুরানো পরিকল্পনার সাথে আঁকতে পছন্দ করেন, কারণ এটি আপনাকে আঙ্গুলগুলি নির্দেশ করতে এবং ভুল ভবিষ্যদ্বাণীগুলি হাইলাইট করার সুযোগ দেয় প্রকল্পের প্রাথমিক পরিকল্পনার পর্যায়ে যে বিপুল পরিমাণ অনিশ্চয়তা রয়েছে তার অনিবার্য পরিণতি। সর্বোপরি, আপনি যদি গ্যান্টটিকে ট্র্যাক করতে পারবেন না যদি আপনি পরিকল্পনাটিকে আমূল পরিবর্তন করতে দেন, তাই না? এটি একই সাধারণ আকার ধারণ করতে হবে এবং একই পদক্ষেপ নিয়ে গঠিত হতে হবে, অন্যথায় ট্র্যাক করার মতো কিছুই নেই ... পরিকল্পনাগুলির প্রতি অবিচলিত থাকা এই কারণগুলির মধ্যে বর্তমানে "জলপ্রপাত" কে আসলে একটি ক্ষুদ্র শব্দ হিসাবে বিবেচনা করা হয় number সামনের পরিকল্পনাটি মূল পরিকল্পনায় লেগে থাকা নিয়ে বিভ্রান্ত।
কারণ # 3: তারা আপনাকে কিছুই শেখায় না
আপনার প্রকল্পগুলির পরিকল্পনাটি একইরকম এবং পুনরাবৃত্তি না করা না হলে এই প্রকল্পের বিলম্ব আসলে আপনার পরবর্তী প্রকল্পের পরিকল্পনার উপায়টিকে বদলে ফেলবে like সর্বোপরি, গ্যান্টস প্রাথমিকভাবে এর জন্য ব্যবহৃত হয়েছিল - কারখানার উত্পাদন লাইনে পরিকল্পনার কাজ, যেখানে কার্যগুলি খুব ভালভাবে সংজ্ঞায়িত করা হয় এবং তাদের সময়কাল অত্যন্ত অনুমানযোগ্য।
ট্র্যাকিং একটি সফ্টওয়্যার বিকাশ গ্যান্ট চার্টে যোগ করে এমন মান শূন্য। যুক্তিযুক্তভাবে শূন্যের চেয়েও কম। কেবলমাত্র নতুন প্রকল্পগুলির জন্য অতীত অনুমানগুলি অপ্রাসঙ্গিক নয়, আপনি যে বিভ্রমটি বাস্তবে পশ্চাদপসরণ দ্বারা সময়ের সাথে আপনার অনুমানের ক্ষমতাটি উন্নত করতে পারেন তা বিপজ্জনক। অবশ্যই, কোনও সিএস শিক্ষার্থী সত্যিই জানেন না যে ইন্টিগ্রেশন বাস্তব জীবনে অনেক সময় নেয়। তবে যে কেউ তাদের জীবদ্দশায় দুটিরও বেশি প্রকল্পের সাথে জড়িত রয়েছেন তিনি বিলম্বিত প্রকল্পগুলির জন্য সাধারণ সন্দেহভাজনদের সম্পর্কে ইতিমধ্যে ভাল জানেন। প্রকল্পগুলি বিলম্বিত হওয়ার আসল কারণটি কোনও গাণিতিক ত্রুটি ফ্যাক্টর নয় যা সাধারণভাবে অনুমানের জন্য প্রয়োগ করা উচিত - এটি অন্তর্নিহিত অনিশ্চয়তা যা প্রথমবারের জন্য কিছু করার সাথে আসে এবং এটি কীভাবে প্যানেলটি ঘটাতে চলেছে ঠিক তা না জেনে।
প্রকৃতপক্ষে প্রকল্প পরিচালনা ব্যবস্থা রয়েছে যা এই বিভ্রান্ত কোণ থেকে সমস্যাটি আক্রমণ করার চেষ্টা করে। তারা আপনার পূর্বাভাস বনাম প্রকৃত কর্মক্ষমতা পরিমাপ করে এবং পরিসংখ্যান বিশ্লেষণ ব্যবহার করে আপনার সামগ্রিক অনুমানটি সংশোধন করার চেষ্টা করে। যেন "ড্যানি সবসময়ই 14.3% দ্বারা সমস্ত কিছুকেই অবমূল্যায়ন করে" এমনটি ঘটে। ড্যানি বোকা নয়, এবং অনুমান করা যায় যে তার ভবিষ্যদ্বাণীগুলির ত্রুটিটি অনুমানযোগ্য সত্যই বোকামি। এটি আদিম "নিরাময়" কে বিভ্রান্ত করে - আপনার অনুমানের কারণগুলি যুক্ত করে - সমস্যার কারণ হিসাবে। আপনার অনুমানটি সঠিক নয় কারণ এটি "সঠিক" গুণক দ্বারা গুণিত হয়নি। আপনার পরিকল্পনাটি কেবল অসম্পূর্ণ; এবং প্রতিটি পরিকল্পনা নিজস্ব পদ্ধতিতে অসম্পূর্ণ।
কারণ # 4: তারা আপনার মনোযোগ ভুল জিনিসগুলিতে নিবদ্ধ করে
সময়মতো বিতরণ করার জন্য কী করা দরকার তার দিকে মনোনিবেশ করার পরিবর্তে, আপনি এখন আপনার ভুল ভবিষ্যদ্বাণীকে ন্যায্যতা দেওয়ার দিকে মনোনিবেশ করছেন। আরও বিশদে পরিকল্পনায় মনোনিবেশ করার পরিবর্তে এবং আপনার পরিকল্পনাকে নতুন তথ্যে অভিযোজিত করার পরিবর্তে আপনি একটি পুরানো পরিকল্পনার পুনর্নির্মাণ করছেন। প্রকল্পগুলি খুব কমই বিলম্বিত হয় কারণ কার্য-পরিকল্পনার অংশগুলি ভুলভাবে অনুমান করা হয়েছিল। এগুলি বিলম্বিত হয়েছে কারণ মূল পরিকল্পনার বাইরে কিছু জিনিস ছাঁটাই করে ফেলেছিল। ট্র্যাকিং গ্যান্টস এটিকে আরও খারাপ করে তোলে, কারণ আপনার পরিকল্পনার মধ্যে আরও কী কী অনুপ্রেরণা তৈরি করতে হবে যদি এটি সমস্ত স্ট্যাটাস মিটিংয়ে একটি দুর্বল অনুমান হিসাবে হাইলাইট করা হয়? তারা আপনাকে আপনার গ্যান্ট চার্টে বড়, ট্র্যাক-সক্ষম কাজের অংশে আটকে রাখে। আপনাকে অভিযোজন এবং সঠিক ট্র্যাকের দিকে মনোযোগ দেওয়ার পরিবর্তে,
পর্যাপ্ত পরিমাণে বিস্তৃত পরিকল্পনা পরিচালনা করার জন্য পর্যাপ্ত পরিমাণে সরঞ্জাম না থাকারও সমস্যা রয়েছে। আপনার সরঞ্জামগুলি যদি সেই পথে ঘন ঘন অবহেলিত সমস্ত পদক্ষেপগুলি উন্মোচন করতে দেয় তবে একটি ভাল প্রাথমিক পরিকল্পনা (এবং অনুমান) তৈরির ক্ষেত্রে আপনার আরও অনেক ভাল সুযোগ রয়েছে। Ditionতিহ্যবাহী গ্যান্টস হ'ল নিম্ন-রেজোলিউশনের প্রাণীগুলি যা বিকাশকারীরা যথাযথভাবে প্রকল্প পরিচালনার বাস্তবতার ক্যারিকেচার হিসাবে দেখেন। যা দরকার তা হ'ল একটি সরঞ্জাম যা প্রাথমিক পর্যায়ে কাজের পরিকল্পনায় যথাসম্ভব তথ্য যুক্ত করা সহজ করে তোলে এবং তারপরে আপনার প্রকল্পের সাথে অনিশ্চয়তার কুয়াশা ধীরে ধীরে বিবর্ণ হয়ে যাওয়ার সাথে সাথে আপনার পরিকল্পনাকে মানিয়ে নেওয়া ঠিক তত সহজ করে তোলে। আপনার শেষ জিনিসটি আপনার ভুল অতীত ভবিষ্যদ্বাণীগুলির অবিরাম কম রেজোলিউশনের অনুস্মারক। ট্র্যাকিং গ্যান্টস আঙুলগুলি দেখানো এবং গাধাগুলি coveringেকে রাখার জন্য ভাল, কাজগুলি করার জন্য নয়।
গ্যান্ট চার্ট সফ্টওয়্যার জটিল আন্ত নির্ভরতা বিশ্লেষণ করতে এবং ওভাররান এবং বিলম্বের প্রভাবগুলির পূর্বাভাস দিতে দেয়।
তবে, বেশিরভাগ সফ্টওয়্যার প্রকল্পের জন্য, কিছু আন্ত নির্ভরতা এবং বাহ্যিক ইনপুট রয়েছে, সুতরাং ভবিষ্যদ্বাণী করার মূল বিষয়টিটি যখন সফ্টওয়্যার টিম বলবে যে 3 সপ্তাহ লাগবে তখন সঠিক গুণকটি কী ব্যবহার করবে তা জেনে রাখা।
যেহেতু অন্যরা বলেছে যে একটি গ্যান্ট চার্ট (সাধারণত অনানুষ্ঠানিকভাবে একটি প্রকল্প পরিকল্পনা হিসাবে পরিচিত) হ'ল ম্যাপিংয়ের একটি উপায় এবং সেই কাজগুলির মধ্যে আন্তঃনির্ভরতা, যার লক্ষ্য কোনও প্রকল্পের জন্য সর্বনিম্ন মোট সময় কাটানো establish
পরিচালনার দৃষ্টিকোণ থেকে মূল আউটপুট হ'ল সমালোচনামূলক পথে চিহ্নিতকরণ, এটি সেই কার্যগুলির তালিকা যা যদি তারা বিলম্ব হয় তবে প্রকল্পটি বিলম্বিত হয়।
খুব সাধারণ উদাহরণ - বলুন যে দুটি প্রোগ্রামার তিনটি কাজ নিয়ে একটি প্রকল্পে কাজ করছে (কোড মডিউল একটি প্রোগ্রামারকে 10 দিন সময় নেয়, কোড মডিউল বি একটি প্রোগ্রামারকে 5 দিন সময় নেয়, তারপরে একটি সংহত করে এবং উভয় প্রোগ্রামারকে 2 দিন সময় নেয়)। প্রথম দুটি টাস্ক (কোডিং মডিউল এ এবং বি) সমান্তরালভাবে কাজ করা হবে এবং লক্ষ্যটি হল তিনটি কাজ শেষ করা এবং এভাবে 12 দিনের মধ্যে প্রকল্পটি শেষ করা।
এক্ষেত্রে সমালোচনামূলক পথটি কোডিং মডিউল A এর পরে ইন্টিগ্রেশন টেস্টিং। মডিউল বি এর কোডিংটি আসলে 5 দিন দেরিতে (বা পাঁচ দিন ধরে চালিত) কোনও প্রভাব ছাড়াই শুরু করতে পারে যদিও সময় মতো শেষ না হলেও কোডিং মডিউল এটিকে আরও বেশি সময় নিতে চলেছে। অন্যদিকে কোডিং মডিউল এ বা একীকরণের পরীক্ষার যে কোনও সময় পিছলে গেলে পুরো প্রকল্পটি পিছলে যাবে।
এই ধরণের জিনিস জানা আপনাকে কীভাবে সংস্থান স্থাপন করতে হবে এবং কোনও নির্দিষ্ট কাজে দেরি করা পুরো প্রকল্পকে প্রভাবিত করবে কিনা তা বুঝতে আপনাকে সহায়তা করে।
তারা দরকারী? অবশ্যই হ্যাঁ, তবে একটি উল্লেখযোগ্য সতর্কতা সহ: যতক্ষণ না তাদের মধ্যে informationোকানো তথ্য ভাল - ততক্ষণ:
এবং সেখান থেকে দলটিকে চার্টে কাজ করতে হবে এবং সঠিক ক্রমে কাজগুলি পরিচালনা করতে হবে (নির্ধারিত টাস্কটি সম্ভবত কোনও কিছু / অন্য কাউকে লাইনে নামিয়ে দেবে বলে আরও মজাদার এমন কিছু না করা)।
যদি আপনি এই সমস্ত কিছু করেন তবে হ্যাঁ, তবে এটি সত্যই আপনাকে সহায়তা করতে পারে তবে এটি সঠিক এবং বাস্তবসম্মত তা নিশ্চিত করার জন্য কাজটি সামনে রাখা উচিত।
আমি গ্যান্ট চার্টগুলি পছন্দ করি এবং ম্যাকের তৈরি করার জন্য যদি আরও ভাল সফ্টওয়্যার পছন্দ হত তবে আমি সেগুলি সর্বদা ব্যবহার করব।
নির্ভরতা দেখতে পাওয়া বিশাল। "যদি আমরা প্রকল্পের ডেটা ব্যাকফিলিং অংশটি না পেয়ে থাকি তবে কী কী উন্নত হবে তা নির্মাণ শুরু করতে পারে না" "
যদি আপনার প্রকল্পটি কোনও সফ্টওয়্যার বিকাশ প্রকল্প হয় তবে একটি গ্যান্ট চার্ট খুব বেশি সহায়ক হবে না এবং বেশিরভাগ সময় নষ্ট হবে। এগুলি সফ্টওয়্যার বিকাশের তরল প্রকৃতির জন্য ডিজাইন করা হয়নি, যেমন।
ফলশ্রুতিটি হ'ল আপনি কাজটি করার চেয়ে পরিকল্পনা আপডেট করতে আরও সময় ব্যয় করবেন।
কেবল আপনার প্রয়োজনীয়তাগুলি পরিচালনা করুন এবং অন্য সমস্ত কিছু নিজের যত্ন নেবে।
YMMV