বাই-ডিজাইন "বাগগুলি" কী খারাপ চিহ্ন রয়েছে?


29

ব্যবহারকারীরা ডিজাইন অনুসারে জিনিসগুলির জন্য বাগ প্রতিবেদন জমা দিলে এটি কি একটি খারাপ চিহ্ন?

এটির কি সাধারণত অর্থ হয় যে অ্যাপ্লিকেশনটি বিভ্রান্তিকর বা অস্পষ্ট, বা নির্দিষ্টভাবে না বলা পর্যন্ত আমার কেবল এটি এক-বন্ধ ব্যবহারকারী ভুল পর্যন্ত চক করা উচিত?

(আমার কাছে আসলে এরকম কোনও প্রতিবেদন নেই by বাই-ডিজাইন "বাগগুলি" এর অস্তিত্ব খারাপ জিনিস কিনা তা সম্পর্কে এটি একটি খাঁটি অনুমানমূলক প্রশ্ন))


19
সম্ভবত লোটাস নোটের কিছু অগ্রগামী মন্তব্য করতে আগ্রহী, যেহেতু মানক উত্তরটি "এটি কোনও বাগ নয় এটি এমন একটি বৈশিষ্ট্য যা আপনি বুঝতে পারবেন না" is
জেমস অ্যান্ডারসন

5
এটি আমার কাছে পরামর্শ দেয় যে বিকাশকারীদের প্রদত্ত ব্যবহারকারীর প্রয়োজনীয়তাগুলি ব্যবহারকারীরা যা চেয়েছিলেন তার সাথে মেলে না।
টেম্পটার

7
@tempar "আমি যা চেয়েছিলাম এটি তা কিন্তু আমি যা চেয়েছিলাম তা তা নয়" "
StuperUser

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

7
@ ডাঙ্ক: আমি এমন একটি সিস্টেম প্রয়োগ করেছি যা প্রতিদিন 24 ঘন্টা ধরে নিয়েছিল, কারণ আমরা গ্রাহককে দিবালোক সঞ্চয় সময়ের উপস্থিতি বোঝাতে ব্যর্থ হয়েছি। তারা কেবল বিশ্বাস করবে না যে 25 ঘন্টা সহ কিছু দিন রয়েছে। প্রোগ্রামে কি এটি একটি বাগ আছে?
এমসাল্টারস

উত্তর:


54

এটা কি খারাপ চিহ্ন? আমি মনে করি এটি একটি সতর্কতা যা সন্ধান করা মূল্যবান, তবে আমি এটিও হতে বাধ্য বলে মনে করি।

লোকেরা যখন আমার কাছে কোনও ধরণের প্রতিক্রিয়া জমা দেয়, আমি এটিকে তিনটি বালতিতে ফিল্টার করার চেষ্টা করি:

  • বাগ
  • বৈশিষ্ট্য অনুরোধ
  • ভুল যোগাযোগ

বাগ

বাগগুলি হ'ল যখন কোনও কিছু আপনার প্রত্যাশার মতো স্পষ্টতভাবে কাজ করে না বা ব্যবহারকারী যেভাবে প্রত্যাশা করে। যেমন, এটি আমার নাম জিজ্ঞাসা করেছিল, আমি "স্কট" এ প্রবেশ করলাম, এন্টার টিপুন এবং এতে বলা হয়েছে, "হাই জো!"

বৈশিষ্ট্য অনুরোধ

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

ভুল যোগাযোগ

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

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

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


3
ভুল-যোগাযোগের মধ্যে ভুল প্রত্যাশা (বা সাধারণ ভুলে যাওয়া) অন্তর্ভুক্ত রয়েছে যা প্রত্যাশাগুলি জানানো হয়েছিল এবং সম্মত হয়েছিল।
পিটার টেইলর

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

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

7

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

বেশিরভাগ ব্যবহারকারীর নির্দিষ্ট প্রয়োজনীয়তা পূরণের জন্য কীভাবে জটিল সফটওয়্যারটি থাকতে হবে তা অবগত নয়। 80% প্রচেষ্টার প্রভাবের কার্যকারিতা কেবলমাত্র 20% (ফ্রিঞ্জ এবং ব্যতিক্রম ক্ষেত্রে) এ চলে যায়।

তারা মাঝে মাঝে বুঝতে পারে না যে সফ্টওয়্যারটির অভ্যন্তরীণভাবে নির্দিষ্ট উপায়ে আচরণ করা প্রয়োজন, বহুবার ত্রুটি বা ডেটা ইত্যাদির দুর্নীতি রোধ করতে ...

এটি উদ্বেগজনক নয় কারণ স্পষ্ট এবং সংক্ষিপ্ত ডকুমেন্টেশন এবং যোগাযোগের মাধ্যমে এটি আরও ভাল হয়।


2
+1 তবে দয়া করে জটিল এবং জটিল মধ্যে পার্থক্যটি দেখুন ... সফ্টওয়্যারটি মোটেও জটিল হওয়ার দরকার নেই, তবে এটি প্রায়শই অনেক জটিল।
মার্জন ভেনেমা

এটা খুব সত্য। আমি যে সমস্ত সাধারণ ঘটনাটি চালাই সেগুলি হ'ল ব্যবহারকারীরা বহু-এক-এক বনাম বহু থেকে বহু সম্পর্কের মধ্যে পার্থক্যটি উপলব্ধি করে না। আমার কাছে পাওয়া একটি সাধারণ অনুরোধটি হ'ল, "আপনি কি প্রতিবেদনটি শিরোনামে অর্ডার নম্বরটি প্রদর্শন করতে পারেন?" এবং আমাকে ব্যাখ্যা করতে হবে যে প্রায় 95% ক্ষেত্রে যখন তারা কাজ করছে তার উপর কেবলমাত্র একটি অর্ডার সংখ্যা রয়েছে, এমন অনেকগুলি ক্ষেত্রে রয়েছে যেখানে কোয়েরিতে একাধিক অর্ডারগুলিতে ডেটা অন্তর্ভুক্ত থাকতে পারে। তারপরে আমাকে জিজ্ঞাসা করতে হবে, আপনি কি আমাকে কমা দ্বারা বিভক্ত শিরোনামে সমস্ত ক্রম সংখ্যা তালিকাবদ্ধ করতে চান বা প্রতিবেদনের প্রতিটি বিস্তারিত লাইনে আপনি অর্ডার নম্বর চান?
স্কট হুইটলক

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

5

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

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


1
এর পরে কোনও উত্তর নেই, তবে আমি মনে করি। কেস-কেস-কেস ভিত্তিতে এটি মূল্যায়ন করা উচিত। আমি যতটা মূর্ত.
ম্যাক্সপাম

5

আমার অভিজ্ঞতা অনুসারে ডিজাইন করা বাগের অর্থ আপনার ব্যবহারের কেসগুলি আপনার প্রকৃত ব্যবহারকারীদের সাথে খাপ খায় না। আপনার ব্যবহারের ক্ষেত্রে প্রকৃত ব্যবহারকারীদের ব্যবহার সম্পর্কে পড়ার চেষ্টা করুন (কেবলমাত্র তাদের নাম দেওয়া এবং একটি থাম্বনেইল বিবরণ ব্যবহারের মানের জন্য বিস্মিত করে))

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


5

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


3
বা, যে একটি বিভক্ত ব্যবহারকারী গ্রুপ আছে। উদাহরণস্বরূপ, ধরা যাক আপনার ওয়েব অ্যাপ্লিকেশন একটি ডেস্কটপ অনুকরণ করে m আপনি কি আশা করেন যে উইন্ডোটি বন্ধ করলে প্রোগ্রামটি বন্ধ হয়ে যায়? হ্যাঁ উইন্ডোজ ব্যবহারকারীদের জন্য, ম্যাক-ব্যবহারকারীদের জন্য নয়।
কেপলা

1
@ কেপ্পলা - আপনি ভাল বক্তব্য রেখেছেন। আপনি সবাইকে খুশি করতে পারবেন না, সুতরাং এখানে যেমন বর্ণিত "বাগ" এর ক্ষেত্রে কিছুটা তদন্ত করা দরকার যা নিশ্চিত করা দরকার যে আপনি "ফিক্স" এর পরে আর আগের তুলনায় বেশি বাগ রিপোর্ট পাচ্ছেন না।
জোরিস টিমারম্যানস

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

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

2

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


2

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

(সম্পাদনা - @ মারজান ভেনমার পরামর্শ অনুসারে উত্তরে আমার মন্তব্য যুক্ত হয়েছে।


আমি সত্যিই দেখতে পাচ্ছি না যে এটি একটি বাগ রিপোর্ট হিসাবে চিহ্নিত হয়েছে। আরও একটি পরামর্শ বা বৈশিষ্ট্য অনুরোধ মত। (যদিও কিছু বাগ-ট্র্যাকিং সিস্টেমের সাহায্যে এটি যাইহোক এক হিসাবে গণনা করা যেতে পারে))
ম্যাক্সপাম্প

1
আমি বেশিরভাগ সময় একমত, তবে এটির অর্থ ডিজাইনের একটি তদারকি (বাগ), বা নির্দিষ্টকরণের ধূসর অঞ্চল, বা বিকাশকারী এবং ব্যবহারকারীর দ্বারা অনুমানের একটি আলাদা সেট হতে পারে।
জেমস ম্যাকলিউড

1
জেমস, আপনি যদি নিজের মন্তব্যে সেই মন্তব্য যুক্ত করেন তবে পুরো উত্তরটি আরও ভাল হয়ে যায়।
মার্জন ভেনেমা

1

আমি বিশ্বাস করি যে এটির একটি খারাপ লক্ষণ মূলত এই কারণে যে ডিজাইনটি জেনেরিক নয় এবং ব্যবহারকারীদের প্রয়োজনীয়তা সম্পূর্ণরূপে বোঝা / বিশ্লেষণ করা হয়নি।

আমি ডিজাইনের দুটি ক্যাটোগরি দেখছি, - দুর্ঘটনাক্রমে ডিজাইন। - ইচ্ছাকৃতভাবে ডিজাইন।

দুর্ঘটনাক্রমে ডিজাইনটি এই জাতীয় সমস্যাগুলিকে ঘন ঘন নিয়ে যায় এবং তা ধরে রাখতে পারে না।


1

আমি ব্যবহারকারীদের "অজ্ঞতা" সম্পর্কে ম্যাপেল_শ্যাফটের উত্তরে যুক্ত করতে চাই। আপনাকে এও মনে রাখতে হবে যে 90% ব্যবহারকারী কেবল তাদের নিজস্ব অভিজ্ঞতা এবং সিস্টেমটি ব্যবহারের উপায় সম্পর্কে চিন্তা করবেন । তারা অন্য ব্যবহারকারীদের সম্পর্কে চিন্তা করে না, তাদের কেন করা উচিত? ডিজাইনার / বিকাশকারী হিসাবে বিভিন্ন ধরণের ব্যবহারকারীর কাছ থেকে ইনপুট নেওয়া এবং এমন কিছু তৈরি করা যা আমাদের পক্ষে যথাসম্ভব ভাল। বেশিরভাগ সময় আপনি সবার জন্য সমাধান অনুকূল করতে পারেন না।

তবে অবশ্যই আপনার ব্যবহারকারীদের কাছ থেকে প্রতিক্রিয়াগুলি পড়তে এবং মূল্যায়ন করতে হবে! এগুলি, সর্বোপরি, যারা আপনার সৃষ্টি ব্যবহার করেন!


0

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

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.