ব্যবহারকারীদের নিজস্বভাবে একসাথে প্রয়োজনীয়তা পেতে দেয় বা তাদের গাইড করতে দেয়?


16

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

1) ব্যবহারকারীদের বলুন, "ঠিক আছে, তাই আপনি যদি এখনও এটি বর্ণনা না করতে পারেন তবে আমি আপনার জন্য কিছু তৈরি করতে পারি না what আপনি কী চান আপনি যখন জানেন তখন আমরা কেন কয়েক সপ্তাহের মধ্যে একসাথে ফিরে আসব না"।

2) কয়েকবার ব্যবহারকারীদের সাথে দেখা করুন এবং ভাল ওলে সকরাটিক পদ্ধতিতে তাদেরকে গাইড করে কী চান তা নির্ধারণ করতে তাদের সহায়তা করুন। "আপনার কি এক্স ট্র্যাক করতে হবে?", "ওয়াই সম্পর্কে কী?", "আপনার কী কার্যকারিতা জেড দরকার?"

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

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


কৌতূহলী প্রশ্ন: আপনি কেন প্রয়োজনীয়তা বিশ্লেষণ অন্য কারও কাজ বলে মনে করেন?
স্টিভেন এ। লো

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

1
প্রসঙ্গের জন্য ধন্যবাদ, আপনার প্রশ্নটি এখন অনেক বেশি অর্থবোধ করে। একদিকে যেমন মনে হচ্ছে আপনার অভ্যন্তরীণ ব্যবসায়ের বিশ্লেষকরা তাদের কাজ করছেন না, অন্যদিকে তারা যদি বিকাশকারী না হয় তবে আমি তাদের বিশ্লেষণকে সম্পূর্ণ বা সঠিক বলে বিশ্বাস করব না - তবে এটি কেবল আমার ;-)
স্টিভেন এ। লো

উত্তর:


9

আমাকে স্বীকার করতে হবে যে আমি মাঝে মাঝে 3 বিকল্পটি পছন্দ করি)

3) ক্লায়েন্টদের অস্পষ্ট ধারণা শুনুন, সপ্তাহের জন্য তাদের ঠিক কী চান তা নির্ধারণে সহায়তা করার ধারণাটি ব্ল্যাচ করুন ... সুতরাং তাদের কী প্রয়োজন তা নির্ণয় করুন, এটি তৈরি করুন এবং প্রয়োজনীয় রিফ্যাক্টর হিসাবে প্রয়োজন।

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

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

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

মূল প্রশ্নের পদে; আমি এটি অনেকটা প্রসঙ্গে নির্ভর করি। যদি ক্লায়েন্টের সাথে আটকে থাকে (যেমন এটি কোনও কাজের চুক্তির মাধ্যমে আমি আবদ্ধ, বা কোনও বিকল্প কাজ নেই) তবে # 2 হ'ল স্যানিস্ট পদ্ধতি। অন্যথায় একটি উচ্চ সম্ভাবনা রয়েছে যে এক সপ্তাহের মধ্যে আপনাকে একটি দুর্দান্ত এবং বিশদ বিবরণ দেওয়া হবে ... যা প্রোগ্রামার হিসাবে আপনার কাছে সম্পূর্ণ অকেজো।

উপরে উল্লিখিত হিসাবে একই সমস্যা (# 3) এবং যে কোনওভাবে আপনাকে # 2 করতে হবে leaves


1
+1: "প্রয়োজনীয়", "পছন্দসই" এবং "Oচ্ছিক" সম্পর্কে অনুমানমূলকভাবে কথা বলা অনেক লোকের পক্ষে প্রায় অসম্ভব। একটি কংক্রিট বাস্তবায়ন সম্পর্কে কথা বলা অনেক বেশি সহজ।
এস .লট

আমি "আবশ্যক", "পছন্দসই" এবং "
ptionচ্ছিক

@ ম্যাটনজ: এটি কিছু ব্যবহারকারীর জন্য "বাস্তববাদী" হওয়ার চেষ্টা করতে পারে। কংক্রিট বাস্তবায়নের জন্য আলোচনা করা আরও সহজ। ব্যবহারকারীরা প্রকৃত কংক্রিট বৈশিষ্ট্যগুলি যুক্ত করতে, পরিবর্তন করতে বা অপসারণের জন্য বলতে পারেন। কম অনুমানমূলক। কম "বাস্তববাদী"। আরও প্রকৃত, বাস্তব এবং কংক্রিট।
এস .লট

27

আপনি যদি কেবল প্রোগ্রামার হতে চান তবে ক্লায়েন্টের কী কী প্রয়োজন তা অন্য কেউ না বের হওয়া পর্যন্ত আপনি অপেক্ষা করুন এবং তারপরে কোডটি কোড করুন

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

যোগ করুন: এই প্রক্রিয়াটিকে "সিস্টেম বিশ্লেষণ এবং নকশা" ওরফে পরামর্শ বলা হয় এবং এটি কখনই নিখরচায় করা উচিত নয়


1
বিনামূল্যে জন্য +1 বিট :) সঙ্গিনী জন্য ঘন্টার ওয়েবসাইট লেআউট যে দম্পতি করছেন মধ্যে suckered কখনো ....
বীর

1
"বিনামূল্যে কখনই করা উচিত নয়" অন্য প্রশ্ন আইএমওতে প্রসারণযোগ্য।
এন্ডি তেজহোনো

7

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

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

সুতরাং নীচের লাইনটি হ'ল আমাদের ফোকাসটি ব্যবহারকারীদের সমস্যা সমাধান করা উচিত। এর জন্য মাঝে মাঝে কিছু লক্ষ্যযুক্ত প্রশ্ন জিজ্ঞাসা করতে এবং উত্তরগুলি বের করার জন্য তাদের আরও সময় দেওয়ার প্রয়োজন হতে পারে। কখনও কখনও এটি ঘনিষ্ঠ সহযোগিতায় একসাথে ডোমেন চার্ট করা প্রয়োজন। কখনও কখনও এটি সাধারণ স্কেচ / প্রোটোটাইপস / মকআপগুলি তৈরি করতে কিছু সময় ব্যয় করতে হয়, তারপরে ফলাফলটি দেখায় এবং জিজ্ঞাসা করে "আপনার মনে যা আছে তা কি এটির মতো দেখাচ্ছে?" (তারপরে প্রোটোটাইপটি ছুঁড়ে ফেলে যখন তারা বলে "আসলে, আমি পুরোপুরি আলাদা কিছু নিয়ে ভাবছিলাম ..." এবং শুরু করছি ... :-)

আসল দক্ষতা সঠিক সময়ের জন্য সঠিক পদ্ধতির চয়ন করা choosing

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

এটি "অতিরিক্ত" প্রচেষ্টা হিসাবে দেখা যেতে পারে যা পরিশোধ করে না - তবে, আমি এটিকে দুটি কারণ হিসাবে বিনিয়োগ হিসাবে দেখতে পছন্দ করি:

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

3

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

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

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

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

যে কোনও ক্ষেত্রে: কোনও কোডের টুকরো পুনর্লিখন কোনও প্রয়োজনের পুনরায় লেখার চেয়ে বেশি নয়।

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


2

আপনার ব্যবহারকারীগণ বিকাশকারী না হলে অবশ্যই 2 বিকল্পটি (তবুও বিকল্প 2 এর প্রয়োজন হতে পারে)।

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


2

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

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


2

সাধারণভাবে, ক্লায়েন্টরা আপনার কাছে আসবে ঠিক কী তা তারা জানে যে তারা তাদের প্রয়োজন বলে মনে করে। দুর্ভাগ্যক্রমে, এগুলি তারা আপনাকে বলবে, সমস্যা (গুলি) বর্ণনা না করে সমাধানের দিকে নিয়ে যায় যা তারা মনে করে যে আপনি সরবরাহ করবেন।

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

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

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


2

বিকল্প 1 কিছু কাজ না এড়ানোর একটি দুর্দান্ত উপায়। আমি যখন কাজটি অপ্রয়োজনীয় বলে বিশ্বাস করি বা আমার আরও বেশি গুরুত্বপূর্ণ কাজ করার দরকার ছিল তখন আমি এটি ব্যবহার করেছি।

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

দ্বিতীয়ত, ব্যবহারকারীরা অগত্যা তাদের প্রয়োজনীয় কী তা জানে না এবং সাধারণত কোনও ক্রিয়ামূলক অর্থে তারা কী চায় তা জানে না।

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

ব্যবহারকারীদের এমন কিছু দেওয়ার একমাত্র উপায় যা তারা যা পছন্দ করে এমনভাবে প্রয়োজন যা তাদের নিজের সাথে কাজ করা।

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