চতুর সফ্টওয়্যার বিকাশ: ব্যবহারকারীর প্রয়োজনীয়তা পরিবর্তনের ক্ষেত্রে আপনি কীভাবে * আর্থিকভাবে প্রতিক্রিয়া জানান?


13

এখানে এসই এবং অন্যান্য সাইটগুলিতে এই "চতুর বিকাশ" বিষয়গুলি পড়ার সময় আমি সবসময়ই ভাবতাম:

"ট্র্যাডিশনাল" সফ্টওয়্যার ইঞ্জিনিয়ারিংয়ে আপনি

  1. ব্যবহারকারীর প্রয়োজনীয়তা সংগ্রহ করুন,
  2. এই প্রয়োজনীয়তার উপর ভিত্তি করে একটি স্পেসিফিকেশন লিখুন,
  3. এটি গ্রাহককে দিন এবং এ পর্যন্ত করা কাজের জন্য তাকে বিল দিন,
  4. একটি (রুক্ষ) প্রযুক্তিগত নকশা করুন, যাতে আপনি বাস্তবায়নের ব্যয়টি অনুমান করতে পারেন,
  5. ব্যবহারকারীর প্রয়োগের জন্য একটি মূল্য মূল্য দিন,
  6. গ্রাহকের নির্দিষ্টকরণে স্বাক্ষর করার জন্য এবং অফারটি স্বীকার করার জন্য অপেক্ষা করুন,
  7. ডিজাইন, বাস্তবায়ন, পরীক্ষা,
  8. বিল.

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

সুতরাং, কীভাবে এই চঞ্চল প্রকল্পে (আর্থিকভাবে) কাজ করা হয়, যেখানে ঘন ঘন প্রয়োজনীয়তা পরিবর্তন প্রক্রিয়ার একটি অংশ হয়?

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

5
আমি মনে করি পার্থক্যটি এই নয় যে "ঘন ঘন প্রয়োজনীয়তা পরিবর্তনগুলি প্রক্রিয়াটির একটি অংশ", তবে তারা প্রক্রিয়াটির একটি স্পষ্টরূপে স্বীকৃত অংশ।

উত্তর:


13

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

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

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

এখানে দুটি নোট রাখার মতো ঝুঁকি রয়েছে। প্রথমটি হ'ল গ্রাহক ভয় পেয়ে যেতে পারেন, যদি তিনি চপলতা আপ-ফ্রন্ট বুঝতে না পারেন। দেখে মনে হচ্ছে তিনি সমস্ত ঝুঁকি নিচ্ছেন। কেবল অভিজ্ঞতা থেকেই বোঝা যায় যে তিনি সত্যই নন।

দ্বিতীয়টি হ'ল তাদের অবশ্যই পুরো প্রক্রিয়া জুড়েই ব্যস্ত থাকতে হবে, বা প্রত্যেকেই হারাবে। অনেক গ্রাহক খুব দেরি না হওয়া অবধি তাদের কতটা ব্যস্ত থাকতে হবে তা বুঝতে ব্যর্থ হন।

তবে আপনি যদি একটি সংস্থা হিসাবে এটি যথাযথভাবে ব্যাখ্যা করেন তবে প্রত্যেকেই বিজয়ী।


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

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

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

এর অর্থ কি চুক্তির ধরণের চটজলদি প্রকল্পের মূল্য নির্ধারণ করা উচিত নয়?
বেন চেং

4

কিছু মানুষ চেষ্টা করতে দিতে অতীতে নির্দিষ্ট দাম প্রকল্পে তত্পরতা ব্যবহার করতে সমাধান। আমি ব্যক্তিগতভাবে মনে করি এটি সাধারণত সম্ভব নয়।

বিশেষত স্ক্রাম পণ্য সফ্টওয়্যার সংস্থাগুলির জন্য উপযুক্ত এবং পরিষেবা সংস্থায় কম ব্যবহৃত হয়।

আপনি আপনার প্রকল্পগুলিতে কিছুটা তত্পরতা ব্যবহার করতে পারেন, যেমন পুনরাবৃত্তি, প্রতিদিনের স্ট্যান্ড-আপস, বার্নডোন ইত্যাদি but আপনার একটি সমস্যা হবে

দয়া করে চটপটি পরিবেশন করবেন না les কম সসকে স্পর্শ করে । আমাদের অবশ্যই একটি প্রদত্ত সমস্যার উপযুক্ত সমাধান ব্যবহার করতে হবে।


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

1
@ ম্যাপেল_শ্যাফ্ট: হ্যাঁ এটি সত্যিই সম্ভব এবং পুনর্নির্মাণ করা। আমি যুক্ত লিঙ্কগুলি হ'ল এমন লোকদের থেকে যারা দাবি করে যে এটি কাজ করেছে। তবে আপনাকে গ্রাহক দ্বারা এই পদ্ধতিতে কাজ করতে হবে (স্থির মূল্য এবং সময় বা নির্দিষ্ট দাম এবং সময় নির্দিষ্ট সুযোগের সন্ধান করুন) by

3

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

আপনার যে পদ্ধতির ব্যবহার করতে হবে তা গ্রাহক এবং আপনার সম্পর্কের উপর নির্ভর করে।

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

অন্যান্য গ্রাহকদের জন্য, যে পদ্ধতিটি ভালভাবে কাজ করে তা নিম্নলিখিত:

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

  • যখন গ্রাহক কোনও প্রয়োজনীয়তা পরিবর্তন করতে বলেন, তখন তার ব্যয়টি অনুমান করুন এবং এটি প্রকৃত ব্যয় এবং রাজ্যের সাথে তুলনা করুন। আপনি যদি পণ্যটি প্রায় সমাপ্ত করেন এবং আসল ব্যয় $ 2,108.36 হয় এবং পরিবর্তনের ব্যয়টি আনুমানিক $ 150 হিসাবে নির্ধারণ করা হয়, কেবল এটি করুন। অন্যদিকে, যদি সর্বোচ্চে পৌঁছানোর ঝুঁকি থাকে, তবে আপনার গ্রাহককে বলুন যে আপনাকে সামগ্রিক ব্যয়কে এক সাথে মূল্যায়ন করতে হবে।


3

চৌকস এবং 'একটি অফার লিখুন' মনে হচ্ছে একটি বিরোধী :) - দ্বিতীয়টি উত্পাদনশীল সফটওয়্যার ইঞ্জিনিয়ারিং নয়: ডি

ঠিক আছে, এখন আমাদের কাছে রসিকতা রয়েছে - আসল জিনিসটিতে ফিরে আসুন।

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

এটার মানে কি? এর অর্থ হ'ল চুক্তিটি বানান করে যে আমরা (ক্লায়েন্ট) ব্যয়ের একটি প্রাথমিক অনুমান ঠিক করি এবং +/- প্রকরণটি যা আমরা হ্যান্ডেল করতে পারি eg উদাহরণস্বরূপ $ 100K বিড কিন্তু আমি K 120 কে যেতে ইচ্ছুক (এটি হতে পারে না) চুক্তির অংশ, তবে গ্রাহকের মনে)।

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

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

আপনার যদি গ্রাহকের দেখার জন্য এই গ্রাফটি কোথাও পাওয়া যায় তবে আপনি ক্রমাগত আর্থিক নিয়ে ফিরে যাওয়া ছাড়া এটির সহায়তা করা উচিত।

আশাকরি এটা সাহায্য করবে!


1

অন্যান্য মানুষের অভিজ্ঞতা সম্ভবত পরিবর্তিত হতে পারে, তবে একটি উপায় আমি এটি দেখেছি বেশ কয়েকটি জিনিস নোট করার সাথে আপনার "traditionalতিহ্যবাহী" সমান:

  1. পরিবর্তনের জন্য কিছু ওভারহেডে তৈরি করুন (উদাহরণস্বরূপ, 10%)
  2. বৃহত পরিবর্তন বা সমষ্টিগত এবং বিল্ট-ইন ব্যয় ছাড়াই বিল পরিবর্তনের জন্য বিল পৃথকভাবে বিলগুলি (একটি ভাল, যদিও প্রোগ্রামিং নয়, উদাহরণস্বরূপ ডিজাইনের কাজ, যেখানে প্রায়শই প্রাথমিক ব্যয় অন্তর্ভুক্ত থাকে, 3 টি পুনর্বিবেচনাগুলি বলে, এবং পরবর্তী সংশোধনগুলি বা সম্ভবত মোট রেডো হয়) অতিরিক্ত)

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

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

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