কোনও বিকাশকারীকে অপ্রয়োজনীয় বা ক্ষতিকারক বৈশিষ্ট্যের বিরুদ্ধে তর্ক করা উচিত?


32

নতুন বৈশিষ্ট্যগুলি এবং যখন, অ সমালোচনামূলক / প্রশ্নযুক্ত বৈশিষ্ট্যগুলি নিয়ে আলোচনা করার সময় বিকাশকারীদের কাছ থেকে একটি ভাল মনোভাব কী?

বলুন যে আপনি কোনও জাভা ভাষার মতো বিকাশ করছেন, এবং বস বলেছেন: "আমাদের পয়েন্টার দরকার যাতে বিকাশকারীরা সরাসরি বস্তুর মেমরি নিয়ে ঝাঁকুনি দিতে পারে!"

বিকাশকারীকে কি ধারণাটি ছুঁড়ে দেওয়া উচিত কারণ এটি অভাবনীয় জটিলতা এবং সুরক্ষা দুর্বলতা যুক্ত করে, বা তাকে যা জিজ্ঞাসা করা উচিত তা করা উচিত?

এটি একটি ভাল উদাহরণ নাও হতে পারে তবে ধূসর অঞ্চলে এমন জিনিসগুলির সম্পর্কে কী বলা যায়, যেমন ওয়ার্কফ্লো ভাঙ্গা বাটন বা প্রোগ্রামের অভ্যন্তরীণ কাঠামোর বিরুদ্ধে যায় ইত্যাদি বোতাম যুক্ত করার মতো?

নিয়মিত প্রোগ্রামারটির বিতরণ "বনাম" করতে পারে না "কী করতে পারে তা কী?

সম্পাদনা: প্রশ্নটি কোনও খারাপ বস সম্পর্কে নয়: ডি

আমি আরও আগ্রহী ছিলাম যে লোকেরা কীভাবে সামান্য উপযোগী হয়ে উঠতে পারে এমন সমস্যাগুলির একটি লক্ষণীয় পরিমাণ যুক্ত করে যে নতুন সমস্যার দিকে এগিয়ে যায়?

সাধারণ মনোভাব হওয়া উচিত:

  1. হ্যাঁ আমরা এটি করব, জটিলতা স্ক্রু করব
  2. হতে পারে
  3. না, সাধারণ পুনর্নির্মাণ এবং প্রভাবগুলি পরিবর্তনকে ন্যায়সঙ্গত করে না

একজন ভাল বিকাশকারীটির প্রতিক্রিয়া কী হওয়া উচিত?


1
"আর্কিটেকচারের একমাত্র নীতি" - কোন নীতিটি এটি? এই উদাহরণটি খুব খারাপ, আমি এটি আপনার প্রশ্নের বাইরে নিয়ে যাব।
জেরেমি

@ জেরেমি: আপনি ঠিক বলেছেন, আমি স্থির বক্তা নই।
কোডার

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

উত্তর:


26

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

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

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

এটি কাজের রাজনীতির সাথে জড়িত একটি কোমল পরিস্থিতি, তবে এটি সুদৃ .়ভাবে পরিচালনা করা যেতে পারে।


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

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

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

1
@ জেফ ওয়েলিং এবং আপনার পায়ে ভোট দেওয়ার বিষয়ে আমি আপনার সাথে আরও একমত হতে পারি না। :) এবং আমি এই উত্তরটির সম্পাদিত আকারে মূলটির চেয়ে আরও বেশি একমত, তবে আমি মনে করি এটি এখন অন্যরকম উত্তর।
পিটারএলেন ওয়েবেব

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

14

যদি আপনার বস আপনাকে বোকা কাজ করতে বলে, তবে আপনার (দয়া করে) এটি বোকা কেন তা বোঝানো উচিত।

যদি সে বা সে কথাটি না পায় তবে আপনি বোকা কাজগুলি করতে বাধ্য। এটাই. তিনি হলেন বস। এই ক্ষেত্রে আপনি কেবল সে / সে যা বলতে পারে তা করতে পারেন, বা তার সাথে কথা বলতে পারেন বা চাকরি পরিবর্তন করতে পারেন।


বসের সাথে কোনও সমস্যা নেই, এটি আইসবার্গের লুকানো অংশের বৈশিষ্ট্যগুলি নিয়ে।
কোডার

3
@ কোডার: সেক্ষেত্রে আপনাকে এটি পরিচালনা করতে হবে যে আপনি এমনকি উন্নয়ন শুরু করার আগে বিশ্লেষণের প্রয়োজন হবে।
হতাশিত

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

9

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

যদি বৈশিষ্ট্যটির জন্য অনুরোধ করা হয় তবে অ্যাপ্লিকেশনটির কিছু মূল নীতি লঙ্ঘন করা হয়েছে (যেমন একটি ইউআইতে "একটি নীল বোতাম যুক্ত করুন!" যা গ্রাহকের অনুরোধ অনুসারে কেবল লাল বোতাম রাখার জন্য ডিজাইন করা হয়েছে) তবে আমি মনে করি এটি ঠিক আছে জিজ্ঞাসা "কেন?" এবং উল্লেখ করুন যে এটি প্রাক-প্রতিষ্ঠিত নকশার বিরুদ্ধে যায়।

শেষ পর্যন্ত, প্রায় সবকিছুই "করতে পারে" (কোনও প্রযুক্তিগত দিক থেকে নীল-কেবলমাত্র ইউআইতে লাল বোতাম যুক্ত করা শক্ত নাও হতে পারে ), এটি "করণীয়?" এর একটি প্রশ্ন আরও বেশি?


আপনার সম্পাদিত প্রশ্নের উত্তর দেওয়ার জন্য, আমি মনে করি উত্তরটি # 2, "হতে পারে", আরও তদন্ত এবং বিশ্লেষণের জন্য মুলতুবি থাকা উচিত।

আপনি # 1 "হ্যাঁ, নিঃশর্তভাবে" উত্তর দিতে চান না কারণ আপনি প্রদত্ত সময়সীম সরবরাহ করতে সক্ষম নন এমন কোনও কিছুর প্রতিশ্রুতিবদ্ধ হতে আটকে যেতে পারেন।

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


6

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

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

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

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

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


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

3
আমি সম্পূর্ণ একমত। একজন বিকাশকারী, যা লোকেরা তাদের যা চান তার চেয়ে বেশি যা তাদের প্রয়োজন তা দেয় (বা তাদের যা প্রয়োজন তার পক্ষে ক্ষতিসাধনের জন্য), একটি ভয়ানক বিকাশকারী।
ডেভিড শোয়ার্জ

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

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

2
@ কিথস: হুবহু ! আমার চেয়ে ভাল বলে এটির জন্য আপনাকে ধন্যবাদ।
ডেভিড শোয়ার্জ

5

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

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

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

অবশ্যই এটি সম্ভব যে আপনি ঠিক ভুল are সফটওয়্যার ইঞ্জিনিয়ারিং মজা না?


3

প্রশ্নটি যেহেতু অস্পষ্ট তাই আমি আমার প্রতিক্রিয়া নিয়ে কিছুটা সাধারণীকরণ করব।

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

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


2

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

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

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

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


2

মাফ করবেন, তবে এই প্রশ্নটি নাবালকের মতো পিতৃ পরামর্শের জন্য জিজ্ঞাসা করছে। যদি এটি হয় তবে ভাল বিকাশকারীকে এই আদেশগুলি আলিঙ্গন করতে হবে:

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

2

আমি খারাপ প্রয়োজনগুলি পিছনে ঠেকাতে বিশ্বাস করি। তবে আমি এটাও বিশ্বাস করি যে যখন আপনি কেন খারাপ সেগুলি ব্যাখ্যা করার জন্য যখন আপনি সেরা শট দিয়েছেন এবং তারা এখনও তাদের চান, তখন আপনি সম্মত হন এবং আপনার কাজটি করেন।

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

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

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

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

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


1

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

সেক্ষেত্রে আমি কিছুটা ঝুঁকি নিরসনের কৌশলটি সুপারিশ করব। আপনি যে চিত্রটি আপনার এপিআইতে ডাব্লুসিএফ / ওয়েব পরিষেবা যুক্ত করার বিষয়ে বিবেচনা করছেন, যা পুরষ্কার ব্যতীত দুর্দান্ত বা অনেক জটিলতা হতে পারে:

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

1

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

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

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

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


1

আমি যে সমস্যাটি দেখছি তা হ'ল যুক্তিটি ব্যবহার করা of

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

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

যদি তা না হয়, তবে সম্ভবত এগুলি কোড করার উপযুক্ত সময়!


1
  1. বুঝতে পারুন যে আপনি সবকিছু জানেন না এবং সব কিছু করতে পারবেন না।

  2. আপনি যদি নিশ্চিত হন যে এটি তখন একটি খারাপ ধারণা, কী খারাপ তা বলুন।

  3. যদি তারা এটি আপনার দিকে চাপ দেওয়ার চেষ্টা করে, তবে বলুন - বিশ্লেষণের জন্য আরও সময় প্রয়োজন, আপনার যদি আরও সময় প্রয়োজন হয় বা বলুন যে আমরা এই সমস্যার কোনও ভাল সমাধান পাইনি।

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


0

একটি আদর্শ দৃশ্যে আপনার কাছে একটি নেতৃত্ব বিকাশকারী থাকবেন যা প্রযুক্তিগত দিক থেকে চূড়ান্ত সিদ্ধান্ত নেয় এবং ব্যবসায়ের দিক দিয়ে চূড়ান্ত সিদ্ধান্ত নেয় এমন একটি ব্যবসায় নেতৃত্ব দেয়। এটি দুটি প্রধান প্রশ্নের উত্তর দেবে:

1) কি? গ্রাহক কি চান?

2) কিভাবে? আমরা প্রযুক্তিগত দৃষ্টিকোণ থেকে এটি কীভাবে সম্পাদন করব।

গ্রাহক যা চায় তা হ'ল চূড়ান্ত সিদ্ধান্ত গ্রহণকারী যেমন তারাই বিল পরিশোধ করে


0

বিকাশকারী হিসাবে, আপনার প্রয়োজনীয়তাগুলি কার্যকর করার জন্য অনুরোধ করা হচ্ছে তা সত্যিই যত্ন নেওয়া উচিত নয়।

যাইহোক, আপনার কিছু ব্যাখ্যা করা উচিত যদি অবাস্তব নয় এবং আরও ভাল উপায় আছে কিনা।


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

@ অতিলা আপনি ভুল বুঝে গেছেন। "কোনও প্রকল্পের বিষয়ে বহন করা হচ্ছে না" এবং "প্রকল্প পরিচালকের জন্য এটি বা সেই বৈশিষ্ট্যটির জন্য অনুরোধ করা হচ্ছে কিনা তা বহন করছে না" আলাদা জিনিস
21

0

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


0

এটি আমার জন্য প্রায় দিনের একটি কাজ, এবং বাস্তবে আমি এটি খুশি।

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

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

আপনার প্রশ্নের উত্তরের জন্য এটি কোনও বিকাশকারী (যা বিকাশ করা) এর কাজের অংশ নয়, তবে এটি একটি "অতিরিক্ত" যা গুণমান এবং দলের কাজ সরবরাহ করে।


0

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

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

এবং, নতুন বৈশিষ্ট্যটি যদি খুব বোকা বা কাজের পরিবেশটি খুব কৃপণ হয় তবে অন্য কোনও কাজ সন্ধানের সময় এসেছে।

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