বড় আইটি প্রকল্পগুলি কেন ব্যর্থ বা বড় ব্যয় / সময়সূচী ছাড়িয়ে যায়? [বন্ধ]


34

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

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

ভাগ করে নেওয়ার জন্য আপনার কোনও ব্যক্তিগত অভিজ্ঞতা আছে?


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

3
@ মোজুবা আমি উভয়ই, এবং আমি উত্তর দিয়েছি। আমি আশা করি এর ফলে একাধিক ব্যক্তিত্বের ব্যাধি সনাক্তকরণ হয় না।
টিম পোস্ট

1
যখন গ্রাহক জানে না তারা কী চায় তা চৈতন্য সেরা। সংস্থাগুলি অসম্পূর্ণভাবে সংজ্ঞায়িত প্রকল্পগুলিতে সাধারণত যে বিপুল পরিমাণে খবরের কাগজগুলিতে ঝোঁকায় ব্যয় করতে ইচ্ছুক হয় না তারা।
টাঙ্গুরেনা

1
এটি সফ্টওয়্যার বিশ্বে অনন্য নয়।
চাকরী

1
প্রাইভেট ইন্ডাস্ট্রির তুলনায় এই ধরনের বিশাল প্রকল্প ব্যর্থতা সরকারী প্রতিষ্ঠানে বেশি ঘটবে বলে মনে হয় বা কমপক্ষে এটি প্রায়শই খবরে থাকে বলে মনে হয়।
ব্র্যাচ

উত্তর:


34

মূল কারণটি স্কোপ বৃদ্ধি , যা "দ্য প্র্যাগমেটিক প্রোগ্রামার" বইটি বর্ণনা করেছে:

  • বৈশিষ্ট্য ব্লাটস
  • লতানো বৈশিষ্ট্য
  • প্রয়োজনীয় হামাগুড়ি

এটি সেদ্ধ-ব্যাঙ সিনড্রোমের একটি দিক।

বিভিন্ন "চতুর" পদ্ধতির ধারণাটি প্রতিক্রিয়া ত্বরান্বিত করা এবং - আশা করি - সময় মতো প্রকল্পের বিবর্তন সংশোধন করা।

তবে অন্য কারণটি হ'ল রিলিজ ম্যানেজমেন্ট : যদি আপনি প্রকল্পটি প্রকাশের দিকে মনোনিবেশ না করেন (তবে এটি অসম্পূর্ণ হতে পারে) তবে সম্ভাবনা রয়েছে এটি ব্যর্থ হবে (কারণ অনেকগুলি বগি বৈশিষ্ট্য সহ অনেক দেরিতে মুক্তি পেয়েছে, এবং ঠিক করা / আপডেট / আপগ্রেড)।

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


" দেরী প্রকল্পগুলি একবারে একদিন দেরিতে আসে " ব্লগ পোস্টে আরও অনেক উদাহরণ রয়েছে:

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

এ কারণেই আমরা চশমাগুলির পক্ষে বা "কার্যকারিতার উপর একমত হয়েছি" পরামর্শ দিই না That's এটিই সমস্যার মূল কথা - প্রথম পিক্সেলটি আঁকার আগে বা কোডের লাইনটি লেখার আগেই আপনাকে কী প্রয়োজন এবং এটি কীভাবে কার্যকর করা হবে সে সম্পর্কে আপনারা সমস্ত কিছু জানেন saying ।

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


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

29

সাধারণত প্রকল্পের জটিলতা হ্রাস করা হয়


2
+1: যদিও আমি সম্ভবত চূড়ান্ত অবমূল্যায়ন বলেছি
কেন হেন্ডারসন

@ কনফিউজড আমি " মিস্যান্ড্রেস্টিমেটেড" পছন্দ করি । আমি কখনই জানতাম না যে শব্দটি এত পুরানো!
সি সি

তারপরে আমি আমার প্রশ্নটিতে যুক্ত করব "জটিলতা কেন অবমূল্যায়ন করা হয়?"। সুযোগ এবং জটিলতার অনুমান এসডিএলসির একটি অংশ। সুতরাং আমার কাছে অবমূল্যায়ন করা লক্ষণ কারণ নয়।
সফটভেদ

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

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

18

স্টিভ ম্যাককনেল ("কোড কমপ্লিট" খ্যাতির) ক্লাসিক ভুলগুলির একটি তালিকা রয়েছে ।

কিছু অকার্যকর বিকাশের অভ্যাসগুলি এতবার বেছে নেওয়া হয়েছে, এত লোকের দ্বারা এমন ভবিষ্যদ্বাণীমূলক, খারাপ ফলাফল রয়েছে যেগুলি তাদের "ক্লাসিক ভুল" হিসাবে ডাকা প্রাপ্য ...

এই বিভাগে তিন ডজন ক্লাসিক ভুল গণ্য করা হয়। আমি ব্যক্তিগতভাবে কমপক্ষে একবার এই ভুলগুলি প্রত্যক্ষ করে দেখেছি এবং সেগুলির অনেকগুলি আমি নিজেই করেছি ...

এই তালিকার সাধারণ ডিনোমিনেটর হ'ল আপনি যদি ভুলটি এড়ান তবে প্রয়োজনীয়ভাবে দ্রুত বিকাশ পাবেন না, তবে আপনি এড়াতে না পারলে অবশ্যই স্পষ্টভাবে ধীর বিকাশ পাবেন ...

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

সম্প্রদায়

# 1: সংক্ষিপ্ত প্রেরণা ...

# 2: দুর্বল কর্মীরা ...

# 3: অনিয়ন্ত্রিত সমস্যা কর্মীরা ...

# 4: বীর ...

# 5: দেরী প্রকল্পে লোকদের যুক্ত করা হচ্ছে ...

# 6: কোলাহলপূর্ণ, জনাকীর্ণ অফিস ...

# 7: বিকাশকারী এবং গ্রাহকদের মধ্যে ঘর্ষণ ...

# 8: অবাস্তব প্রত্যাশা ...

# 9: কার্যকর প্রকল্প স্পনসরশিপের অভাব ...

# 10: স্টেকহোল্ডার ক্রয়-ইনয়ের অভাব ...

# 11: ব্যবহারকারীর ইনপুট অভাব ...

# 12: পদার্থের উপরে রাজনীতি স্থাপন ...

# 13: ইচ্ছামত চিন্তা ...

প্রক্রিয়া

# 14: অতিরিক্ত আশাবাদী সময়সূচী ...

# 15: অপর্যাপ্ত ঝুঁকি ব্যবস্থাপনা ...

# 16: ঠিকাদার ব্যর্থতা ...

# 17: অপর্যাপ্ত পরিকল্পনা ...

# 18: চাপের মধ্যে পরিকল্পনার ত্যাগ ...

# 19: অস্পষ্ট সামনের প্রান্ত সময় নষ্ট সময়। "अस्पष्ट ফ্রন্ট এন্ড" প্রকল্পটি শুরু হওয়ার আগের সময়, সাধারণত অনুমোদনের সময় এবং বাজেট প্রক্রিয়াতে ব্যয় করা সময় ...

# 20: স্বল্প পরিবর্তিত উজানের ক্রিয়াকলাপগুলি ... "কোডিংয়ে জাম্পিং" নামে পরিচিত known

# 21: অপর্যাপ্ত নকশা ...

# 22: সংক্ষিপ্ত মানের গুণমান ...

# 23: অপর্যাপ্ত ব্যবস্থাপনা নিয়ন্ত্রণ ...

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

# 25: প্রয়োজনীয় কাজগুলি অনুমান থেকে ছাড় দেওয়া হচ্ছে ...

# 26: পরে ধরা পরিকল্পনা ...

# 27: কোড-মত-নরক প্রোগ্রামিং। কিছু সংস্থাগুলি মনে করে যে দ্রুত, আলগা, সর্বসাধারণের কোডিং দ্রুত বিকাশের পথে ...

প্রোডাক্ট

# 28: প্রয়োজনীয়তা সোনার-ধাতুপট্টাবৃত। কিছু প্রকল্পের শুরু থেকে প্রয়োজনের তুলনায় আরও প্রয়োজনীয়তা থাকে ...

# 29: বৈশিষ্ট্য স্খলন ...

# 30: বিকাশকারী সোনার-ধাতুপট্টাবৃত। বিকাশকারীরা নতুন প্রযুক্তিতে মুগ্ধ হন এবং কখনও কখনও নতুন বৈশিষ্ট্যগুলি চেষ্টা করতে উদ্বিগ্ন হন ... - তাদের পণ্যগুলিতে এটি প্রয়োজন কিনা বা না ...

# 31: আমাকে ধাক্কা দিন, আমাকে আলাপ আলোচনা করুন ...

# 32: গবেষণা-ভিত্তিক উন্নয়ন। ক্রে সুপার কম্পিউটারের ডিজাইনার সিমুর ক্রে বলেছেন যে তিনি একবারে ইঞ্জিনিয়ারিং সীমা অতিক্রম করার চেষ্টা করেন না কারণ ব্যর্থতার ঝুঁকি খুব বেশি (গিল্ব 1988)। অনেকগুলি সফ্টওয়্যার প্রকল্প ক্রে থেকে একটি পাঠ শিখতে পারে ...

প্রযুক্তি

# 33: সিলভার-বুলেট সিন্ড্রোম ...

# 34: নতুন সরঞ্জাম বা পদ্ধতি থেকে ওভারেস্টিমেটেড সঞ্চয় ... যখন প্রকল্পগুলি পূর্ববর্তী প্রকল্পগুলি থেকে কোড পুনরায় ব্যবহার করে তখন অতিমাত্রায় সঞ্চয়ের একটি বিশেষ ঘটনা ঘটে ...

# 35: একটি প্রকল্পের মাঝখানে সরঞ্জাম স্যুইচিং ...

# 36: স্বয়ংক্রিয় উত্স-কোড নিয়ন্ত্রণের অভাব ...


যাইহোক, অভিনন্দন!
সি

14

বড় প্রকল্প = আরও জটিলতা
আরও জটিলতা = আরও অনিশ্চয়তা
আরও অনিশ্চয়তা = অনুমান করা শক্ত
থেকে অনুমান করা = খারাপ অনুমানের
খারাপ অনুমান = ব্যয়কে ছাড়িয়ে যাওয়া


তবে "খারাপ অনুমান" কেন সর্বদা খুব কম অনুমানের দিকে ঝোঁক করে?
রোমানোজ

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

12

আমি বিডিং প্রক্রিয়াটিকে দোষ দিই। এটি সেই গোষ্ঠীকে পুরস্কৃত করে যা চুক্তিটিকে কাগজে সবচেয়ে সস্তা / দ্রুত দেখায়।

একসাথে বিড করা লোকেরা তাদের জয়ের কোনও সুযোগ না থাকলে তাদের সময় নষ্ট করতে চায় না, তাই তাদের স্বাভাবিক অনুমানটি ধরে রাখা যায়। আমি এমন লোকদের জানি যারা O 80 বাঁচাতে পিওই সুইচগুলির পরিবর্তে সাধারণ সুইচগুলি নির্দিষ্ট করেছে। তবে প্রকল্পটির পিওই দরকার ছিল কারণ এতে আইপি ক্যামেরা ছিল। সেই $ 80 ব্যয় করা দরকার, তবে এখন এটি অনুমানের বাইরে।

আমার দৃ firm় বিশ্বাস আছে যে 2 মাসের 2,000,000 ডলার প্রকল্পটি এখনও আপনি কত বিড পান না কেন 2 মাস still 2,000,000 লাগবে। আপনি যদি মনে করেন এটি সঠিকভাবে করা ব্যয়বহুল, অপেক্ষা করুন এবং দেখুন এটি ভুল করে নেওয়া কত ব্যয়বহুল।


আমি এই বাক্যটি বুঝতে পারি না, "আমার দৃ belief় বিশ্বাস আছে ..." - দ্বিতীয় অংশটি "2 মাস এবং 2M ..." পড়ার পরিবর্তে উচিত?
সি সি

6

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

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


আশাবাদ পক্ষপাতের জন্য +1 আমি কয়েক প্রকল্পের কষ্ট বিভিন্ন ধরণের আছে জানি, আর সব তাদের যে ত্রুটি শেয়ার করুন। প্রায়শই, যদিও তারা একটি যুক্তিসঙ্গত অনুমান দিয়ে শুরু করেছিল, কিন্তু ক্লায়েন্ট বলেছিল "আমরা এটি কেবলমাত্র এক মিলিয়ন ডলার কম করে করব" এবং ঠিকাদারের পরিচালন শূন্য পাওয়ার চেয়ে এন -১ মিলিয়ন ডলার অর্জনকে বেছে নিয়েছিল, যদিও তাদের কোনও অভাব ছিল না though ভাবার কারণ তারা এটিকে সরবরাহ করতে সক্ষম হবেন।
টম অ্যান্ডারসন

4

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

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

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

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

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

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


3

বেশিরভাগ সময় নীচের দুটি বা তারও বেশি সংমিশ্রণ:

  • বিভাগগুলির মধ্যে সহযোগিতার সমস্যা
  • রাজনীতি ... খুব বেশি রাজনীতি ...
  • ভুল দল
  • অবাস্তব সময়সূচী
  • উপযুক্ত পদ্ধতি ছাড়া সুযোগ পরিবর্তন
  • অনুপস্থিত তথ্য

বিষয়টিতে দুর্দান্ত বই: ডেথ মার্চ


3

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

একই "ট্রেন্ড" অনুসরণ করে তারা সমস্ত সম্ভাবনা coverেকে রাখবে এবং পরবর্তীকালে প্রোগ্রামারকে কেবল টাইপিস্টে পরিণত করবে এই ভেবে একটি বিশাল অ্যানালিসিস (আবার এক বছর এগিয়ে) করার চেষ্টা করে। কেউ কীভাবে ভাবতে পারে যে এটি কাজ করতে পারে? এই ধরণের আচরণ কেবল খারাপ অনুমান এবং প্রচুর আমলাতন্ত্রের দিকে পরিচালিত করে।


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

3

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


2

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

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

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

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


2

বাস্তবের উপলব্ধি

এখানে আমি খুঁজে পেয়েছি এই সমস্যার সর্বোত্তম বর্ণনা এখানে। বিজনেসবলস.কম থেকে ট্রি সুইং ing

আমি আমার প্রোগ্রামিং ক্যারিয়ারের প্রথম দিকে "বাস্তবতার উপলব্ধি" ধারণার সাথে পরিচিত হয়েছিল । এ জন্য আমি সত্যই কৃতজ্ঞ। আমি বিশ্বাস করি যে কোনও প্রকল্প ব্যর্থ হওয়ার সবচেয়ে বড় কারণ এটি কেবল আইটি প্রকল্প নয় projects


2

ব্যর্থতার একটি কারণ হ'ল একটি বড় প্রকল্প সাধারণত একটি হাই-প্রোফাইল, গুরুত্বপূর্ণ-থেকে-ব্যবসায়িক প্রকল্প। যখন প্রকল্পগুলি এবং কার্যগুলি হাই-প্রোফাইল হয়, তখন এটি মানুষকে মিথ্যা বলতে উত্সাহ দেয়।

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

এবং তাই এবং তাই ঘোষণা.

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

অবশেষে, আমি আবিষ্কার করেছি প্রকল্পটি 7 মাস 16 মিলিয়ন ডলারে বিড হয়েছিল। আমি অনুমান করেছি একটি খামের পিছনে এটি 24 মাস এবং 50 থেকে 100 মিলিয়ন হওয়া উচিত। আমি আমার ম্যানেজার এবং তার পরিচালকের সাথে একটি বৈঠক স্থাপন করেছি, এবং আমার কেসটি উপস্থাপন করেছি এবং কীভাবে আমরা সময় বা বাজেটে সরবরাহের কাছাকাছি আসছি না; তারা সমস্ত সমস্যা হ্রাস। বৈঠক শেষে সিআইও এই দুটি পরিচালককে মূল বিডের ত্রুটি বাদ দিয়ে মূলত যা বলেছিলাম তা বলেছিল এবং জানিয়েছিল।

যখন আমি দক্ষ নই তখন তারা যখন প্রযুক্তিগুলিকে পরিবর্তন করে তখন আমি প্রকল্পটি রোল অফ করার সুযোগ পেয়েছিলাম। কারও সাথে অনেক পরে কথা বলেছি। প্রকল্পটি প্রায় অর্ধেক হয়ে গেলে 12 মাস এবং 35 মিলিয়ন ডলারে বাতিল হয়ে যায়।

হাই প্রোফাইল বড় প্রকল্পগুলি "এটি একটি ভুল" বলে লোকেদের নিরুৎসাহিত করে। ভুল সহ্য করা হয় না।


1

ভনসির উত্তরের উপর কিছুটা বিশদ বর্ণনা:

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

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

এর সমাধান কী?

আমি সত্যিই জানি না যে কেউ দু'জনের মধ্যে পরিবর্তিত ফাংশনগুলির সেটগুলির সাথে সমান্তরালভাবে দুটি সিস্টেম চালু রাখতে চায় না।


1

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

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


1

এমন একটি উপাদান যা স্পর্শ করা হয়েছে তবে এখনও তার সমাধান করা হয়নি:

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

যদি সংস্থাটি সঠিকভাবে অনুমান করতে না পারে তবে অবাক হওয়ার মতো কী তারা কোনও সিস্টেমও সঠিকভাবে তৈরি করতে পারবেন না?


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

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

0

মাইকেল ক্রিগসমান জেডডিনেট-এর উপর একটি ব্লগ রয়েছে " আইটি প্রকল্পের ব্যর্থতা ", যা এখানে আগ্রহী হতে পারে to

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


0

এই ধরণের প্রকল্পগুলিতে চটপটে ব্যবহার করা যেতে পারে বা traditionalতিহ্যবাহী পদ্ধতি এখনও সেরা।

চূড়ান্তভাবে কার্যকর প্রক্রিয়াগুলি প্রয়োগ করার কারণটি এতটা সহজ কারণ হিসাবে খুব বেশি সমস্যা থেকে ভুগছে বলে মনে হয় না। আপনি একটি চৌকস পদ্ধতিতে একটি বৃহত প্রকল্প শুরু করতে পারবেন না। আপনি এক বা অন্য চয়ন করতে পারেন।

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

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

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


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

0
  • প্রকৃত ব্যবহারকারীদের কাছে প্রেরণে ব্যর্থতা

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

  • ব্যয়টি সঠিকভাবে অনুমান করতে ব্যর্থ

যদি প্রকল্পগুলি মনে হয় যে তারা বিনিয়োগে তাদের আয় বাড়িয়ে তুলবে, তবে তারা বাতিল হয়ে যায়।

  • মান নিয়ন্ত্রণে ব্যর্থতা

পর্যাপ্ত ত্রুটি থাকলে ফরোয়ার্ড গতি শূন্য বা তার নিচে নেমে যাওয়া সম্ভব। মোটামুটি কোনও অগ্রগতি না থাকলে অবিচ্ছিন্ন অস্তিত্বের পক্ষে তর্ক করা শক্ত।


0

তারা হাফস্টাডটারের আইন ভুলে গেছে: আপনি হাফস্টাডটারের আইন বিবেচনা করলেও এটি আপনার প্রত্যাশার চেয়ে বেশি সময় নেয়।


0

ওয়েব ডেভলপমেন্টে আমি যে জিনিসগুলি দেখেছি:

  • অনেকগুলি রান্না - মেজর বি অ্যান্ড এম খুচরা বিক্রেতা যেখানে জোর হঠাৎ ওয়েবে স্থানান্তরিত হয়েছিল। হঠাৎ করে 20 বিভাগীয় প্রধান নতুন হেড পনিরকে প্রভাবিত করার জন্য প্রতিটি উদ্যোগ ডগপিল করছে। আমাকে একবার নতুন আইকন প্রয়োগ করতে হয়েছিল কারণ আইনী পুরানোগুলির চেহারা পছন্দ করে না।

  • লক্ষ্য অর্জনের তুলনায় মেশানো চশমাগুলিতে অতিরিক্ত ফোকাস - "আই 6 এর আইকনগুলি আই 7 এর তুলনায় কিছুটা ম্লান হয়ে গেছে Please অনুগ্রহ করে আপনি যে লঞ্চ-তারিখ-সমালোচনামূলক কাজটি করছেন তা ফেলে দিন এবং আমাদের গ্রাহক বেসের 0.0% এ ভয়াবহ কাজগুলি করতে অংশ নেবে যা দিনগুলি লাগবে Please আইই অভিজ্ঞতা আরও বেশি বাস্তবায়ন এবং ধীর করতে। "

  • খারাপ সরঞ্জামগুলি নন-ডেভদের দ্বারা বাছাই করা হয়েছে যারা তাদের ঘরে থাকা ডেভসকে পরামর্শ চাইতে জিজ্ঞাসাও করতে পারে না।

  • সরঞ্জামগুলির সাহায্যে বাজে ডেভসগুলি বেছে নিয়েছে - "যখন আমরা সংস্করণ নিয়ন্ত্রণ ব্যবহার করতে খুব কম জানি 200 সবে সংখ্যক কোড শিক্ষিত ছেলেদের আউটসোর্স করতে পারি তখন কেন 20 জন দক্ষ জাভা একটি উপযুক্ত বেতন দেবেন?" যেহেতু তারা একযোগে এবং বিভিন্ন দেশের লোকদের সাথে, মূলত 3 টি বড় অ্যাপ্লিকেশনের জন্য ব্যাক-এন্ডে কাজ করে।

  • খারাপ / ভাঙা আর্কিটেকচার - আতঙ্কিত, গতকাল করা কোডের স্তরগুলির উপরে স্তরগুলি, এমন লোকদের দ্বারা বরখাস্ত করা হয়েছিল যা এখন পরিচালক হয়ে পড়েছিল।

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