সফ্টওয়্যার গতির গ্রাহকদের নজরে কত ঘন ঘন প্রকট হয়?


10

তত্ত্ব অনুসারে, গ্রাহকদের প্রথম হাতের অভিজ্ঞতা থেকে সফ্টওয়্যার কার্যকারিতা উন্নতি অনুভব করতে সক্ষম হওয়া উচিত।

বাস্তবে, কখনও কখনও উন্নতিগুলি পর্যাপ্ত পরিমাণে লক্ষণীয় হয় না, যেমন উন্নতিগুলি থেকে নগদীকরণ করতে, গ্রাহকদের আকর্ষণ করার জন্য বিপণনে উল্লেখযোগ্য পারফরম্যান্সের পরিসংখ্যান ব্যবহার করা প্রয়োজন।

আমরা ইতিমধ্যে অনুভূত কর্মক্ষমতা (জিইউআই ল্যাটেন্সি ইত্যাদি) এবং সার্ভার-পার্শ্বের পারফরম্যান্স (মেশিন, নেটওয়ার্ক, অবকাঠামো, ইত্যাদি) এর মধ্যে পার্থক্যটি জানি।

প্রায়শই এটি কীভাবে হয় যে প্রোগ্রামারদের "লিখন আপ" পারফরম্যান্স বিশ্লেষণের জন্য অতিরিক্ত দৈর্ঘ্যের প্রয়োজন হয় যার জন্য শ্রোতারা সহকারী প্রোগ্রামার নয়, তবে পরিচালক এবং গ্রাহক?

উত্তর:


20

যদিও @ জওয়েন্টিং কিছু ভাল বিষয় তুলে ধরেছে , তবে আমাকে সাধারণ মূল্যায়নের সাথে একমত হতে হবে না।

একজন ব্যবহারকারী প্রায়শই সামান্য কর্মক্ষমতা উন্নতি লক্ষ্য করেন না not

তার সাথে, আমি একমত হতে পারি।

যেখানে আমি অসম্মতি জানাই এই বিবৃতিটি ঘিরে:

বেশিরভাগ শেষ-ব্যবহারকারীর মুখোমুখি অ্যাপ্লিকেশনগুলি তাদের বেশিরভাগ সময় ব্যবহারকারী ইনপুটটির জন্য অপেক্ষা করে।

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

একজন ব্যবহারকারী হবে লক্ষ্য তারা তা লোড করার জন্য অপেক্ষা করতে হবে যখন যে একটি অ্যাপ্লিকেশন ধীর। কোনও ব্যবহারকারী তাদের ডেটা প্রবেশের মধ্যে যখন প্রোগ্রামটির জন্য বিরতি দিতে হয় তখন তা লক্ষ্য করবেন

কোনও সিস্টেমের সাথে যখন প্রাকৃতিক এবং তরল মিথস্ক্রিয়া ভেঙে যায় তখন কোনও সফ্টওয়্যার কার্যকারিতা স্পষ্ট হয়।

কোনও ব্যবহারকারী যখন সিস্টেমটি পুরোপুরি কার্যকরভাবে কাজ করে এবং ব্যবহারকারীকে ধরে না রাখে তখন কেবল সিস্টেমের পারফরম্যান্সটি লক্ষ্য করবে না।


5
দুর্ভাগ্যক্রমে কিছু প্রোগ্রামার তাদের ব্যবহারকারীদের অপেক্ষার প্রত্যাশায় খেলতে হবে বলে মনে করে। আমি অন্য দিন এটি প্রোডাকশন কোডে দেখেছি:Thread.Sleep(1000); //pretend this does more than change a 0 to a 1 in the database.
বেন এল

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

2
অন্যদিকে @ বেনএল আমি বিপরীতে অভিজ্ঞতা পেয়েছি, এমন কিছু অপারেশন যা আমাদের দ্রুত তৈরি করার আগে ধীর ছিল, এত তাড়াতাড়ি ব্যবহারকারীরা ভেবেছিলেন যে কর্মটি কার্যকর হয়েছে বা ব্যর্থ হয়নি।
পিটার বি

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

5

কিছু কর্মক্ষমতা বর্ধন কর্মক্ষমতা হিসাবে লক্ষ্য করা যায় না। গ্রাহক কেবল লক্ষ্য করবেন যে সিস্টেমটি "ভাল" অনুভব করে।

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


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

3

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

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

কে খেয়াল করবেন যে সিসাদমিন যিনি একটি ব্যাচের কাজ দেখেন যেটি 90 মিনিটের মধ্যে শেষ হতে 2 ঘন্টা সময় নেয়, তবে তিনি কেবল লক্ষ্য করবেন যে যদি ফলাফলটির জন্য অপেক্ষা করতে হয় এবং দ্রুত রাগ করতে হয় তবে দ্রুত ফিরে তাকে অর্ধেক বাধা দেয় তার চলচ্চিত্রের মাধ্যমে :)


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

হ্যাঁ, এটি চরম ঘটনা। এমন একটিতে কাজ করেছেন যেখানে একটি কাজ যা প্রতিদিন একবার চালাতে হয় তার জন্য 36 ঘন্টা প্রয়োজন। "কেবল" 20 ঘন্টা প্রয়োজনে এটি রিফ্যাক্টর রাখতে সক্ষম হয়েছিল। গ্রাহক ছিল খুশি :)
jwenting

2

আজকের অন্যরা যেমন বলছেন, এটি প্রকৃত কাঁচা গতির চেয়ে অনুধাবন করা পারফরম্যান্স এবং "ফ্লুইডিতি" সম্পর্কে আরও বেশি।

এর অর্থ হ'ল আপনার সফ্টওয়্যারটির ইউআইতে কেবল প্রাকৃতিক অনুভূতি এবং ছন্দ থাকায় আপনি কিছুটা অতি দ্রুত এবং অন্যদের খুব ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে চলতে পারেন। (মানুষ হিসাবে, আমরা অনিয়মগুলি খুব ভালভাবে লক্ষ্য করি, যেহেতু এটি বাঘ হতে পারে আমাদের দিকে উপনীত হতে পারে ...)

এই বিলম্বগুলি গোপনে অপরিহার্য যেগুলি সম্পর্কে আপনি কিছুই করতে পারবেন না, তাই এটি অনুশীলন করা ভাল দক্ষতা।


2

আমি কেবল এখানে ঝাঁপিয়ে পড়তে চেয়েছিলাম এবং এমন একটি অস্বাভাবিক ঘটনা প্রস্তাব দিতে চাই যেখানে ....

* গ্রাহকরা পারফরম্যান্সের বিষয়ে যত্নশীল এবং মজাদার প্রতিটি ছোট পরিবর্তনকে লক্ষ্য রাখছেন!

এটি আমার ক্ষেত্রে যেখানে আমরা উত্পাদন উপস্থাপনাটি কভার করি যা গ্রাহকরা নিজেরাই পারফরম্যান্সের ক্ষেত্রে মৃত্যুর জন্য বিশ্লেষণ করে। অপ্রাপ্তবয়স্ক সংস্করণে পারফরম্যান্সে 2% মন্থরতা "বাগ রিপোর্ট" আকারে প্রকাশিত ধীরগতির সমতুল্য হতে পারে।

ফোরামের থ্রেডগুলি প্রায়শই গ্রাহকরা তাদের দৃশ্যের সাথে সফ্টওয়্যারটির বিভিন্ন সংস্করণের বিপরীতে তাদের দৃশ্য বেঞ্চমার্ক করে শুরু করেন, যেখানে গ্রাহকরা আসলে বিকাশকারীরা তাদের চেয়ে বেশি বেঞ্চমার্ক করছেন। "এই দৃশ্যটি X সংস্করণে রেন্ডার করতে 1 ঘন্টা 40 মিনিট সময় নিয়েছে Y এখন Y সংস্করণে 32 মিনিট সময় লাগে" "

"এই দৃশ্যটি X সংস্করণে লোড হতে 18 মিনিট সময় নিয়েছে, এখন Y সংস্করণে লোড হতে 4 মিনিট সময় লাগে"

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

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

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

প্রায়শই এটি কীভাবে হয় যে প্রোগ্রামারদের "লিখন আপ" পারফরম্যান্স বিশ্লেষণের জন্য অতিরিক্ত দৈর্ঘ্যের প্রয়োজন হয় যার জন্য শ্রোতারা সহকারী প্রোগ্রামার নয়, তবে পরিচালক এবং গ্রাহক?

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


1

আমি কেবল একবারে আসি:

  1. সফ্টওয়্যার একই সময় ফ্রেমে আরও কাজ করে উন্নত।
  2. অফলাইন রেন্ডারিং বা প্রক্রিয়াকরণ স্পষ্টতই দ্রুততর তবে অদেখা।
  3. স্পিড বুস্ট কিছুটা নামমাত্র তবে উন্নতিগুলি ভবিষ্যতের বাধা রোধ করে
  4. সমান্তরাল প্রক্রিয়াকরণ যা একই গতিতে একই কাজটি সম্পাদন করে, অনেকের জন্য।
  5. যে কোনও সময় অদম্য গতি বৃদ্ধি পায় শক্তিশালীভাবে উত্পাদনশীলতার উপর প্রভাব ফেলে।

1

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

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


1

প্রায়শই এটি কীভাবে হয় যে প্রোগ্রামারদের "লিখন আপ" পারফরম্যান্স বিশ্লেষণের জন্য অতিরিক্ত দৈর্ঘ্যের প্রয়োজন হয় যার জন্য শ্রোতারা সহকারী প্রোগ্রামার নয়, তবে পরিচালক এবং গ্রাহক?

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

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


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

0

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

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

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


0

আপনি আপনার সফ্টওয়্যার পণ্য কাকে বিক্রি করছেন তা নির্ভর করে।

তবে প্রায়শই না, আপনার গ্রাহক শেষ / দিনের ব্যবহারকারীর নয়। সুতরাং প্রায়শই আপনি পারফরম্যান্স সমস্যার সমাধানের পরিবর্তে আরও সুন্দর এবং চকচকে প্রতিবেদন তৈরি করে শেষ করেন। কারণ সত্যিই আপনি পরিচালকের কাছে বিক্রি করছেন, শেষ ব্যবহারকারী নয় end

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

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