ঘন ঘন প্রয়োজনীয়তার পরিবর্তনগুলি কীভাবে মোকাবেলা করতে হবে?


9

আমি আমার বর্তমান কাজের জায়গায় বেশ চাপযুক্ত (আমার মতে) পরিস্থিতি নিয়ে কাজ করছি।

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

এখানে 'প্রক্রিয়া' কীভাবে দেখায়:

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

আমাকে ভুল করবেন না, আমি বুঝতে পারি যে কখনও কখনও প্রয়োজনীয়তা পরিবর্তন হয়। আমার কর্মক্ষেত্রে ঘন ঘন পরিবর্তনটি কীভাবে ঘটে এবং 'পরিচালনার' পক্ষে দু'টি নতুন বৈশিষ্ট্য দেয় বা কখনও কখনও বিদ্যমান বৈশিষ্ট্যগুলিতে মৌলিক পরিবর্তন দেয় তা আমাকে বিরক্ত করে।

একই সাথে আমরা শক্ত সময়সীমা নিয়ে কাজ করছি এবং আমার ধারণা আছে যে আমাদের সফ্টওয়্যারটির সাথে এগিয়ে যাওয়ার পরিবর্তে আমরা চেনাশোনা চালাচ্ছি।

আমি কীভাবে এই পরিস্থিতি মোকাবেলা করতে আপনার কাছ থেকে পরামর্শ চাই? এটি কি সাধারণ পরিস্থিতি এবং আমি এ সম্পর্কে কেবল সংবেদনশীল?


যতক্ষণ না তারা বলে - "# $ @ $ # এর ব্লাস্টড টুকরোটি গত বছর শেষ করা উচিত ছিল, আপনাকে এত দীর্ঘ সময় কী লাগে?", এবং সময়মতো অর্থ প্রদান করা ঠিক আছে, ঠিক আছে।
কোডার

আপনার শেষ প্রশ্নের জবাবে: এটি ঘটতে পারে, এটি কি স্বাভাবিক - না, আপনার যত্ন নেওয়া উচিত - হ্যাঁ, আপনার কি পরিস্থিতির উন্নতি করার চেষ্টা করা উচিত - হ্যাঁ। প্রকল্পের সাফল্যের সাথে জড়িত সবার বিবেচনা করা উচিত। পরিস্থিতি উন্নত করার জন্য - নীচে আমার উত্তরটি পড়ুন।
ড্যানি ভারোড

এটি pm.stackexchange.com এর জন্য সত্যিই খুব ভাল প্রশ্ন হবে যে কোনও মডারেটর মনে করে যে এটি সরানো উচিত?
ড্যানি ভারোড

দুঃখিত, প্রতিহত করতে পারেনি: dilbert.com/strips/comic/2007-02-02
হেইঞ্জি

Xkcd এ র্যান্ডাল ওভারের একটি স্পষ্ট ফ্লোচার্ট রয়েছে যা পরিবর্তনের প্রয়োজনীয়তার সাথে কীভাবে व्यवहार
জেসন লুইস

উত্তর:


6

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

মূলত, এমন কোনও প্রতিক্রিয়া লুপকে জোর করুন যেখানে পরিচালনা জানে যে এটি কী আপনি তৈরি করতে চলেছেন। বার্তাটি পাওয়ার সাথে সাথে আপনার নিজের প্রয়োজনীয় কাগজপত্রগুলি লিখে রাখুন।

গল্প কার্ড

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


আপনি এটি পেরেক দিয়েছেন: প্রয়োজনীয়তা ছাড়াই সফ্টওয়্যার লিখবেন না। প্রয়োজনীয়তা খাবারের মতো ..... আপনি এগুলি রান্না না করেই খেতে পারেন তবে তা স্পষ্ট হবে না। যদি "ম্যানেজমেন্ট" কোনও প্লেটে প্রয়োজনীয়তা ডিশ না করে থাকে, আপনাকে রান্নাঘরে যেতে হবে এবং রান্না শুরু করতে হবে।
mattnz

1
প্রয়োজনীয়তা কি খাবারের মতো? প্রয়োজনীয়তা রেসিপি মত হয়। প্রকৃতপক্ষে, প্রয়োজনীয়তাগুলি মেনুটির মতো ... রেসিপিগুলি অ্যালগরিদম হয়, এবং খাবারটি নিজেই সফ্টওয়্যারটির প্রয়োগ হয়।
রবার্ট হার্ভে

আমি মনে করি এই পদ্ধতির ব্যবহার ম্যানেজারকে স্পষ্টভাবে বিশ্বাস করতে সহায়তা করবে যে বিরোধী প্রয়োজনীয়তা সরবরাহ করা হয়, যা সর্বদা ঘটে থাকে।
আাদি ড্রড

3

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

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

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

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


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

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

আমি বেশ কয়েকবার ব্যবসায়িক পরামর্শদাতার সাথে কথা বলেছি - তার জন্য আগের সিদ্ধান্তটি সংশোধন করা মোটেও সমস্যা নয়;)
পিটার

1
@ পিটার, স্ক্রাম সম্পর্কিত একটি জিনিস হ'ল আপনি পুনরাবৃত্তির সীমানা (সাধারণত দুই সপ্তাহ) সংজ্ঞায়িত করেছেন যার সময় কিছুই পরিবর্তন হয় না। এটি আপনার জন্য খুব ভাল ফিট হতে পারে।
কার্ল বিলেফেল্ট

1
... তবে, যদি এটি পুরোপুরি জ্ঞান দিয়ে করা হয় যে এটি প্রয়োজনীয়তাগুলি পরিবর্তন করছে, এবং এটি সেই পরিবর্তনের ব্যয় সম্পর্কে সম্পূর্ণ জ্ঞানের সাথে সম্পন্ন হয়েছে, তবে তারা আপনাকে এই পরিবর্তনগুলি সহ্য করার জন্য অর্থ প্রদান করবে। ;)
ড্যানিয়েল পিটম্যান

1

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

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

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

আমি জানি যে এই ধরণের ডকুমেন্টেশন তৈরি করা আপনি প্রোগ্রামার হয়ে উঠছেন তা নয়, তবে আপনি হয় এই তালিকাগুলি ফেলে দেওয়ার ঝুঁকি নিতে পারেন বা আপনার হার্ড-অর্জিত কোডটি দূরে ফেলে রাখতে পারেন।

ফেরত পাঠাও. দায়িত্বে থাকা লোকদের এই অনুরোধগুলি কতটা ব্যয় করছে তা দেখতে হবে।


1

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

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


1

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

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

যদি সপ্তাহের মাঝামাঝি সময়ে পরিবর্তনগুলি আসে তবে এই যাদু শব্দের উচ্চারণ করুন:

আমি [এই নতুন বৈশিষ্ট্য], [এই নতুন পরিবর্তন], [ইত্যাদি] করতে পারি, তবে আপনি কী করতে চান না ?

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

প্রয়োজনীয়তা যদি এর চেয়ে আরও ঘন ঘন পরিবর্তিত হয়, আপনার পরিবেশে আরও স্থিতিশীলতার জন্য আপনার আলোচনার প্রয়োজন হতে পারে।


0

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

  1. শেষ ব্যবহারকারীকে যত তাড়াতাড়ি সম্ভব সুখী করা এবং দ্রুত অগ্রগতি দেখানোর জন্য পরিচালনার উচ্চাকাঙ্ক্ষা।

  2. বিশদ বিশ্লেষণের অভাব। মনে রাখবেন যে বিশ্লেষকদের কেবল কেন নয় তা নিয়ে প্রশ্ন করা দরকার। বিশ্লেষকদের কেবল "সমাধান" সম্পর্কে শেষ ব্যবহারকারীকে "চিন্তা" করা দরকার কেবল অর্ডার নেওয়া উচিত নয়।

  3. প্রয়োজনীয়তা যাচাইকরণ এবং নিশ্চিতকরণের জন্য একটি আনুষ্ঠানিক প্রক্রিয়ার অভাব, তার পরে অনুমোদনের পরে।

  4. ভুল ব্যক্তিকে এক বা একাধিক ভূমিকা পালনের জন্য জিজ্ঞাসা করা যেমন তারা ব্যবসায়িক বিশ্লেষক বা সিস্টেম বিশ্লেষক ভূমিকার জন্য প্রশিক্ষণপ্রাপ্ত নয়।

  5. সীমিত প্রোটোটাইপিং।

  6. অনুমান / ভয় যে এটি দ্রুত সম্পন্ন করতে হবে এবং যদি এটির জন্য এটি আইটি দোষ দেয় না।

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


0

আমি মনে করি আপনার কয়েকটি দিক থেকে এটি পৌঁছানো উচিত:

  1. সমস্ত স্টেক হোল্ডারকে (পুরো উন্নয়ন দল সহ) ব্যবসায় পরামর্শদাতার সাথে (অফলাইন / অনলাইন) সাক্ষাত করুন এবং ডোমেন, দৃষ্টি এবং তারপরে বুদ্ধিমানের প্রয়োজনীয়তাগুলি একসাথে বোঝার চেষ্টা করুন।

  2. প্রতিটিের গ্রেডিং করে প্রয়োজনীয়তা / ব্যবহারকারীর গল্পগুলি আনুষ্ঠানিক করুন:
    ক। অগ্রাধিকার (জরুরি / গুরুত্ব)
    খ। পরিপক্কতা (এটি কতটা সংজ্ঞায়িত - এটি বেশিরভাগ স্টেক হোল্ডার দ্বারা বোঝা এবং সম্মত হয়)
    গ। জটিলতা (মোটামুটি অনুমান)

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

  3. প্রতিটি বাস্তবায়নের আগে ডিজাইন করার সময় কয়েক ধাপ এগিয়ে ভাবার চেষ্টা করুন - একটি নমনীয় আর্কিটেকচার ডিজাইন করুন যাতে পরিবর্তনের সামঞ্জস্য রাখার জায়গা রয়েছে।

  4. একটি চৌকস বিকাশ প্রক্রিয়া যেমন: এসসিআরএম বা কানবানকে খাপ খাইয়ে নেওয়ার চেষ্টা করুন - এটি আপনাকে পরিবর্তনের প্রয়োজনীয়তা সহ একটি পণ্য বিকাশের জন্য একটি সরঞ্জামকিট সরবরাহ করবে।

আপনার মডারেটরদের এই প্রশ্নটি PM.stackexchange.com- এ সরিয়ে নিতে বলার বিষয়টিও বিবেচনা করা উচিত (এটি পতাকাঙ্কিত করে) যদিও এই প্রশ্নটি এখানে ফিট করে তবে এটি আরও ভাল মানায়।

(*) চুক্তির জন্য স্টেক হোল্ডারগুলি: ব্যবসা, বিপণন, প্রকল্প পরিচালনা, উন্নয়ন এবং কিউএ।

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