কোন প্রকল্পে সন্ধানের জন্য আসন্ন আযাবের সতর্কতা লক্ষণগুলি কী কী? [বন্ধ]

66

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

এই প্রকল্পগুলি দুর্দান্ত শেখার অভিজ্ঞতা, আত্মা-চূর্ণকারী বিপর্যয় (বা উভয়!) হতে পারে এবং বিভিন্ন কারণে ঘটতে পারে:

  • হৃদয়ের উচ্চতর পরিবর্তন
  • আন্ড-দক্ষ / আন্ডার রিসোর্স দল
  • দেব চক্র চলাকালীন শীর্ষ প্রতিযোগীর উত্থান
  • ওভার / আন্ডার ম্যানেজমেন্ট

একবার আপনি এই জাতীয় কয়েকটি প্রকল্পে কাজ করার পরে, কোনও প্রকল্প ব্যর্থ হওয়ার জন্য ঠিক কখন প্রাথমিক পর্যায়ে সনাক্ত করা সম্ভব?

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

আপনার মাথার নিকটে আসন্ন ডুমের অ্যালার্মের ঘণ্টা বন্ধ করে দেওয়া সতর্কতা সংকেতগুলি কী কী?

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

উত্তর:

70

বীরত্ব কোডিং

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

— Fishtoaster
সূত্র
12
অল-নিউটারকে টানার একমাত্র অজুহাত হ'ল একটি স্পেসিফিক অলস সময়সীমার জন্য একটি স্পেসিফিক ইস্যুটি সম্বোধন করা। সম্ভবত এটি কেবল আমারই, তবে আমি যখন ভোগা এবং ঘুম-বঞ্চিত তখন দিনের নির্মম আলোয় রক্তাক্ত ঘৃণ্য দেখতে ঝোঁক দেখি তখন আমি সকাল তিনটায় কোডটি লিখি।
— ব্লেয়ারহিপ্পো
5
ঠিক আছে, অন্য একটি বাহিনী এটি ছাত্র হিসাবে। দরিদ্র প্রকল্প পরিকল্পনা তখন কোর্সের সমান। :)
— ফিশটোস্টার
20
ওহ, খ্রিস্ট কলেজ। আমি আমার টার্মিনাল সামনে বসে মনে সূর্য rose, ঠেলাঠেলি *'s এবং &এর বেশী বা র্যান্ডম কম আশা যে জঘন্য জিনিস কাজ শুরু হবে আমার সি ++ কোডে ভেরিয়েবল সামনে। আমি কলেজের একটি অংশ মিস করি না।
— ব্লেয়ারহিপ্পো
2
এই বছরের শুরুর দিকে আমাদের মতো একটি প্রকল্প হয়েছিল - একজন লোক নিয়মিত সকাল 2 টা অবধি কাজ করছিল এবং আমি 4 টা শুরু করছিলাম। যদিও আমাদের উপর চাপানো হাস্যকর সময়-স্কেলগুলি সত্ত্বেও আমরা কাজটি সেরে ফেলেছি (আমরা আইনসভার শেষ সময়সীমার দ্বারা সম্পূর্ণ হওয়ার প্রতিশ্রুতিবদ্ধ)। আমরা এখনও গোছানো এবং রিফ্যাক্টরিং করছি!
— ক্রিস বালতি
3
আমি এখানে আমার কর্মফলকে বিপদে ফেলতে যাচ্ছি এবং উল্লেখ করব যে "বীরত্ব কোডিং" একটি দেরী সূচক। প্রকল্পগুলি যেখানে "বীরত্বের কোডিং" ঘটতে শুরু করে সেই পর্যায়ে যাওয়ার অনেক আগেই সমস্যার মধ্যে পড়ে যায়। সাধারণত প্রচুর প্রারম্ভিক সমস্যার সূচক রয়েছে, কোডিংয়ের আন্তরিকতার আগেই পপ আপ হয়ে যায়। দুর্ভাগ্যক্রমে, তারা সব ঘন ঘন উপেক্ষা করা হয়। রবার্ট গ্লাস এই বিষয়টির উপর, "দ্য ইউনিভার্সাল এলিক্সির" এবং অন্যান্য বইতে ব্যাপক লিখেছেন। আপনার বিপদে তাকে অগ্রাহ্য করুন।
— জন আর স্ট্রোহম
44

প্রোগ্রামাররা যখন যুক্তিটি জিততে শুরু করে "কোডটি ভয়ঙ্কর, তখন আমাদের স্ক্র্যাচ থেকে শুরু করা দরকার।" কোন পরিপক্ক অ্যাপ্লিকেশন।

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

এছাড়াও, একদিন আপনাকে প্রকল্প পরিচালককে ব্যাখ্যা করতে হবে কেন 6 মাস কাজ করার পরে আপনি প্রায় 85% সক্ষমতা এবং অ্যাপ্লিকেশনটি যখন শুরু করেছিলেন তখন তার 150% ত্রুটি রয়েছে।

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

সমস্যা সমাধানকারী হিসাবে একটি নতুন সরঞ্জাম।

লোকেরা যখন অপরিচিত সরঞ্জামগুলি ব্যবহার করার পরিকল্পনা শুরু করে, আমি আপত্তি করি না তবে আমি এতে নজর রাখি। যখন তারা এই সরঞ্জামগুলির সমস্ত বিজ্ঞাপনযুক্ত সুবিধার সময়সূচীতে পরিকল্পনা শুরু করে, আমি চিন্তিত হই get মজার উদাহরণ:

  • আমরা তফসিলের এক মাস শেভ করতে পারি কারণ আমরা কোনও অবজেক্ট ওরিয়েন্টেড ভাষা ব্যবহার করার চেষ্টা করতে যাচ্ছি (যদিও আমাদের সমস্ত কিছু সি বিকাশকারী হলেও) ers
  • আমরা এই নতুন স্ক্র্যাম জিনিসটি চেষ্টা করব - যা আমাদের সমস্ত প্রক্রিয়া সমস্যার সমাধান করবে!
  • আমি জানি এটি প্রায় অর্ধেক প্রকল্পের মধ্য দিয়ে গেছে, তবে যদি আমরা ওআরএমগুলি নতুন কিছুতে পরিবর্তন করি?

নতুন প্রযুক্তি এবং অনুশীলন দুর্দান্ত তবে আপনি গেটের বাইরে প্রায় সব সুবিধা পাবেন না।

— Fishtoaster
সূত্র
3
আমি একবার এমন একটি প্রকল্পে ছিলাম যেখানে দুটি ইন্টারফেসের কারণে দুটি কাঁটাচামচ ছিল - ডেস্কটপ এবং হ্যান্ডহেল্ড গ্যাজেট। সময়ের অনুমান এই ধারণাটির উপর ভিত্তি করে ছিল যে আমরা এই চকচকে নতুন "EJB" জিনিসগুলি দুজনের মধ্যে মডেল-স্তর কোডটি পুনরায় ব্যবহার করতে ব্যবহার করতে পারি। দুর্ভাগ্যক্রমে, ডাটাবেসটি এমন ভয়াবহ ইঁদুরের বাসা ছিল যে এটি থেকে বেরিয়ে আসা সমস্ত ডেটা নির্দিষ্ট যত্ন সহকারে নির্মিত এসকিউএল অনুসন্ধানগুলি থেকে আসতে হয়েছিল; মটরশুটি সম্পূর্ণরূপে পপুলেশন করা অত্যন্ত নির্মম একটি পারফরম্যান্স হিট হত। যখন দেখা গেল যে (আশ্চর্য!) ডেস্কটপ সংস্করণটির হ্যান্ডহেল্ড সংস্করণের চেয়ে আরও বেশি ডেটা দরকার ছিল, সময়রেখা স্ট্রাইটে নরকে গেল।
— ব্লেয়ারহিপ্পো
2
"অপূর্ব! এখন আমরা ইউনিট পরীক্ষার কাঠামোটি উদ্ধার করেছি, আমরা সেই দীর্ঘতর কিউএ পর্যায় থেকে সময় কাটা শুরু করতে পারি!"
— আরকাইতো
হা হা হা। চমৎকার। নতুন সরঞ্জামের জন্য +1 আমার সমস্ত সমস্যার সমাধান করবে।
— দ্রুত_ফেব্রুয়ারি
40

আমার কাছে একক বৃহত্তম সমস্যা এবং তত্ক্ষণাত আপনি চিহ্নিত করতে পারেন, যখন ব্যবসায় लिखित প্রয়োজনীয়তাগুলি সময়ের অপচয় হিসাবে বিবেচনা করে।

তাই মূলত; কোনও লিখিত প্রয়োজনীয়তা নেই

এটি মৃত্যুর চুম্বন।

— জন ম্যাকআইন্টির
সূত্র
3
বা আরও খারাপ, লিখিত প্রয়োজনীয়তা যা কেউ পড়ে না। আসলে, আমি এমন প্রকল্পগুলিতে এসেছি যেখানে প্রোগ্রামারদের কাছে বিস্তৃত প্রয়োজনীয়তা লিখিত ছিল এবং কখনই প্রদর্শিত হয়নি।
— জনএফএক্স
1
@ অ্যাডলফ রসুন - লিখিত প্রয়োজনীয়তা আপনার সময় বা বাজেটের উপর নির্ভর করে না, তবে প্রত্যাশাগুলি অবহিত না হলে, ধূসর সমস্ত অঞ্চল খালি না করে এবং ক্রমাগত পরিবর্তিত হয় (আপনার মানসিক ধারণা পরিবর্তন হবে) )।
— জন ম্যাকআইন্টির
5
আমার একবার ব্যবসায় বিশ্লেষক ছিল আমাকে বলুন প্রয়োজনীয়তার প্রয়োজন ছিল না। শুধু আবার ব্যবসা বিশ্লেষকের কাজ কী? ওহ হ্যাঁ প্রয়োজনীয়তা লিখতে! Hkjk.com এর মতো এই কাজটি করার মতো প্রয়োজনীয়তা আমরা পাব।
— এইচএলজিইএম
1
আপনি যদি কোনও একক ক্লায়েন্টের জন্য একটি কাস্টম পণ্যের জন্য বিকাশ করছেন তবে নিশ্চিত। তবে আপনি যদি পাওয়ারপয়েন্টের পরবর্তী সংস্করণ বা ইন-হাউস সফটওয়্যার সিস্টেমের পরবর্তী সংস্করণটি লিখছেন তবে আমি বিন্দুটি দেখতে পাচ্ছি না। বিকাশের সময় আপনি প্রয়োজনীয়তাগুলি সম্পর্কে সর্বদা আরও শিখতে পারবেন (উদাহরণস্বরূপ যে কিছু প্রয়োজনীয়তা কার্যকর নয় এবং অন্যটি সম্ভব হয় না)। আমি বরং এই জ্ঞানটি ব্যবহার করব এবং নিকৃষ্ট পণ্য প্রকাশের চেয়ে উন্নয়নের সময় প্রয়োজনীয়তাগুলি পরিবর্তন করব।
— নিকি
1
@ নিকি - আমি বলছি না যে প্রয়োজনীয়তাগুলি স্থিতিশীল হওয়া উচিত, এবং কখনই পরিবর্তন করা উচিত না। আমি বলছি আপনার ভুল লেখাপড়া রোধ করতে এবং সময়ের সাথে সাথে জনগণের মাথায় ধারণা পরিবর্তন হওয়া থেকে বিরত রাখতে আপনার এটি লিখতে হবে। প্রয়োজনীয়তাগুলি পরিবর্তন হওয়া উচিত, তবে সেগুলি পরিবর্তন করুন, তবে বর্তমানের প্রয়োজনীয়তাগুলি লিখিতভাবে রাখুন। যে জানার জন্য?
— জন ম্যাকআইন্টির
33

পরিচালনা বিচ্ছিন্ন

যখন সময়সীমা, বৈশিষ্ট্য, কর্মচারী ইত্যাদির জন্য দায়বদ্ধ ব্যক্তিরা প্রকল্পটি সরবরাহের জন্য দায়ী ব্যক্তিদের থেকে সংযোগ বিচ্ছিন্ন হয়ে যায়। এটি হতে পারে:

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

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

— Fishtoaster
সূত্র
আপনার প্রথম আইটেমের জন্য +1। আপনি যে দৃশ্যের উল্লেখ করেছেন সে ক্ষেত্রে আমি একজন গ্রাহক হয়েছি এবং এটি সবার পক্ষে খারাপ (কেউই অপ্রত্যাশিত বিল চায় না, এবং কেউ এটি প্রদানের বিষয়ে যুক্তি চায় না)।
— ভয়ঙ্কর
+1 আমেন। ওখানে এসেছেন, হয়ে গেলেন, আবার সেই অবস্থানে থাকার চিন্তা করবেন না।
— ইভান প্লেস
আমি এই সমস্ত গুলির সাথেই বাস করছি (সম্ভবত চতুর্থটি বাদে) +
— এশেলি
দুর্দান্ত উত্তর। এমনকি যদি আপনি বিস্তৃত হতে বিরক্ত না করেন এবং আপনি কেবল 'ম্যানেজমেন্ট ডিসকানেক্ট' রেখে দেন তবে আপনার উত্তরটি একটি 10 ​​দামের হতে পারে।
— জিম জি।
25

  1. কী বিকাশকারীরা চলে গেলে এবং পরিচালনার কোনও যত্ন নেই

  2. কী বিকাশকারীরা চলে গেলে এবং অন্যান্য বিকাশকারীদের কেউই তার যত্ন করে না

এক নম্বর সাধারণত ম্যানেজারদের ইঙ্গিত দেয় যারা টিম গতিবেগের সাথে মারাত্মকভাবে যোগাযোগ রাখেন না (যারা "10 এক্স সুপার স্টার", যারা শালীন প্রোগ্রামার এবং তারা একে অপরের সাথে কীভাবে যোগাযোগ করেন ইত্যাদি)।

দুই নম্বর সাধারণত বাকী বিকাশকারীদের পক্ষ থেকে আগ্রহের তীব্র অভাবকে নির্দেশ করে।

— MrDatabase
সূত্র
24

প্রথম বার কেউ, সাধারণত পরিচালন বলে "আমাদের সময় নেই .."

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

— Mawg
সূত্র
8
তার জন্য একটি রেফারেন্স পেয়েছি? এটি ব্যবহারের জন্য দুর্দান্ত
— বারুদ
1
এটিকে "সফটওয়্যার পরিচালনার প্রথম মাউগের আইন" বলুন
— মগ
1
@ অ্যালেক্স ফেইনম্যান: আইআইআরসি কোড কমপ্লিট এ জাতীয় পরিসংখ্যানের প্রচুর উল্লেখ রয়েছে।
— নিকি
21

গ্রাহক, বিপণন বা পরিচালনা একটি তারিখ চয়ন করুন এবং তারপরে একটি কাল্পনিক সময়সূচী পিছনে কাজ করার চেষ্টা করুন

— Mawg
সূত্র
ধন্যবাদ। অ্যালভিসি মনে রাখবেন, আপনি এটি দ্রুত, সস্তা বা কাজ করতে পারেন ... যে কোনও দুটি চয়ন করুন
— মওগ
21

যখন ব্যবসায়ের পক্ষে "না" বলতে পরিচালনা খুব দুর্বল হয়।

এটি ডেডলাইনগুলিতে নিয়ে যায় যা কখনই পূরণ করা যায় না, এটি আইটি বিভাগের প্রতি আস্থার অভাবের দিকে পরিচালিত করে যা বিকাশকারীদের হ্যাক তৈরির দিকে পরিচালিত করে (অর্থাত্ কারওর মেশিনে চলমান ডিবি ... কোথাও) এটি আইটির জন্য দুঃস্বপ্নের দিকে নিয়ে যায় ' সমালোচনামূলক সিস্টেম 'স্থানান্তর করতে হবে যা বাড়ে ...

— অ্যাডলফ রসুন
সূত্র
কিছুই ছাড়ের সুযোগকে 'ছাড়ের বৈশিষ্ট্যগুলির চেয়ে খারাপ' করে তোলে না কারণ মাইলফলকের তারিখগুলি সেট আপ করার সময় প্রধানমন্ত্রী আঁতকে উঠেছিলেন।
— ইভান প্লেস
21

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

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

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

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

— এইচএলজিইএম
সূত্র
হ্যাঁ, খবর যাত্রা শুরু করার সাথে সাথে আরও ভাল হয়ে যায় :)
— হ্যান্স ওয়েস্টারবিক
18

আমার কেরিয়ারে একটি নিশ্চিত লক্ষণ হ'ল ম্যানেজমেন্ট যখন সময়সূচীতে সময় কাটাতে আরও দেহ আনার কথা বলা শুরু করে। আমি কোনও প্রকল্প সহায়তায় আসলে আরও মৃতদেহ দেখিনি।

— ওয়াল্টার
সূত্র
6
আমার একবার একজন ম্যানেজার ছিলেন যিনি কোনও প্রজেক্টে প্রথম দিকের ওয়েব কোডার আনতে চেয়েছিলেন (সঠিক সিদ্ধান্ত) তবে প্রকল্পের অন্য কেউ দীর্ঘমেয়াদী অসুস্থ হয়ে পড়েছিল বলে নতুন ছেলের চুক্তিতে লেখা হয়েছিল যে তাকে অনুমতি দেওয়া হয়নি। অসুস্থ পেতে.
— জন হপকিন্স
1
@ জন - এটি দুঃখজনক ... মজার, তবে খুব দুঃখের!
— ওয়াল্টার
16

যখন নন-টেকনিক্যাল ম্যানেজাররা প্রযুক্তিগত সিদ্ধান্ত নেওয়ার জন্য জোর দেওয়া শুরু করে যে তারা কোনওভাবেই যোগ্য নয়। বড়, বড় লাল-পতাকা!

— GrandmasterB
সূত্র
16

সর্বাধিক সুস্পষ্ট চিহ্ন হ'ল উচ্চ কর্মীদের টার্নওভার। যখন সবাই নতুন চাকরির সন্ধান করছেন, আপনারও সম্ভবত এটি করা উচিত।

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

— user281377
সূত্র
1
সর্বোচ্চ টার্নওভারের হার আমি দেখেছি দুটি প্রকল্পে। একটি হ'ল একটি স্থিতিশীল প্রকল্প যা চালিয়ে যাচ্ছে, এবং একটি ছিল একটি ব্যাংকের একটি ডুমড প্রকল্প। এই দুজনের মতো বেকার হয়ে আমি কখনও খুশি হইনি।
— ডেভিড থর্নলি
11

আপনি "90% সম্পন্ন" হয়ে গেছেন, বিতরণটি পরের সপ্তাহে, তবে এটি ঠিক কারণ আপনি যা রেখে গেছেন তা সমস্তই "পরীক্ষা" করা হয়।

— স্কট হুইটলক
সূত্র
2
আপনি এখন বলছেন যে খুব মজার মনে হচ্ছে। আমার হয়েছে যদিও। এই সময় মজার ছিল না।
+1000 ঘটে যেখানে আমি সারাক্ষণ কাজ করি টিটি
— গানের
1
এটি মজার বিষয় যে প্রতিটি তফসিলের শেষ ধাপ হিসাবে টেস্টিং থাকে যেন পরীক্ষার কোনও বাগ পাওয়া যায় না। যদি তা না হয় তবে কেন পরীক্ষা দিয়ে বিরক্ত করবেন?
— জনএফএক্স
চিন্তা করবেন না, "গ্রাহক এটি আমাদের জন্য পরীক্ষা করবে" :-(
— মাউগ
10
  • প্রত্যেকে শারীরিক ও মানসিকভাবে ক্লান্ত
  • গ্রাহক / ব্যবহারকারীরা টাইমকেলগুলি বা তারা যা দেখছেন সে সম্পর্কে পরিষ্কারভাবে অসন্তুষ্ট
  • মূলত সুন্দর ডিজাইনটি এখন আপোশ বোধ করে
  • আপনি কিছু তুলনামূলক তাৎপর্যপূর্ণ বাগ সহ শিপিংয়ে পদত্যাগ করেছেন যা আপনি সত্যিই বরং ঠিক করতে চেয়েছিলেন তবে সক্ষম হবেন না
  • আপনি যে গৌরব করছেন তা শিপিংয়ের পরিবর্তে আপনি গর্বিত রয়েছেন - পেশাদার গর্বের চেয়ে বেঁচে থাকা মানসিকতার কাছাকাছি
  • দলটি ভয় পেয়েছে যে কিছু নির্দিষ্ট জিনিস রয়েছে যা কাজ করে না এবং সেই বিভাগগুলি উপেক্ষা করছে এবং সেরাের জন্য প্রত্যাশা করছে কারণ তারা সেখানে কী হতে পারে তা নিয়ে ভয় পেয়েছে
  • প্রত্যেকে নিশ্চিত যে তারা উপরে এবং তার বাইরে চলে গেছে (এবং তারা ঠিক আছে)
  • লোকেরা জ্বলজ্বলের লক্ষণ দেখায় (সাধারণ হতাশাবোধ, বিরক্তি, ক্রোধ)

(জিম ম্যাকার্থারির ডায়নামিক্স অফ সফটওয়্যার ডেভেলপমেন্ট থেকে নেওয়া )।

— জন হপকিন্স
সূত্র
"আপনি যে শিপিং করছেন তার চেয়ে শিপিংয়ের ক্ষেত্রে আপনি গর্ব বজায় রেখেছেন" for তাই সত্যি (যদিও আমি শুধু দেখেছি যে আমার ম্যানেজার আমরা ডেভেলপারদের কি জানত দরজা ... পায়ের প্রথম আক্রমণ করলো।)
10

কাউবয় কোডার, বড় ইগো এবং পরিচালনা এর স্বীকৃতি

— রেভ মাগ
সূত্র
একটি কাউবয় কোডার কি?
— ক্রিয়েটিভ যাদু
উইকিপিডিয়া আপনার বন্ধু en.wikipedia.org/wiki/Cowboy_coding
— Mawg
এটি একটি শব্দ জানেন না, ধন্যবাদ! স্বাগতম, আমি আমার রাঞ্চোতে ফিরে যাচ্ছি ...
— ক্রিয়েটিভ ম্যাজিক
9

যদি প্রকল্প পরিকল্পনায় ডিজাইন, বিকাশ, পরীক্ষা এবং স্থাপনার একক পুনরাবৃত্তির জন্য বলা হয় - ক্লাসিক জলপ্রপাত - 1 মাসের বেশি দীর্ঘ প্রকল্পের জন্য, আমি এক মাইল চালিয়ে যাব।

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

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

বিকাশকারীরা ওয়াইল্ড অন রেঞ্জ চলছে

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

  • আপনার মানের সিস্টেমটি ভেঙে গেছে; সংশ্লিষ্ট বিকাশকারীরা ডিজাইন / বাস্তবায়ন পর্যায়ে কেন বিষয়টি গ্রহণ করলেন না। কোডটি কি পর্যালোচনা / পরিদর্শন করা হয়নি? ইউনিট এবং ইন্টিগ্রেশন পরীক্ষাগুলি কেন এটি গ্রহণ করল না? আপনার যদি স্থিরভাবে সামঞ্জস্য ইউনিট / ইন্টিগ্রেশন পরীক্ষার কোনও ধরণের না থাকে তবে আপনি ক্ষতিগ্রস্থ হন।
  • আপনার প্রকল্প পরিচালক / প্রযুক্তিগত সীসা তাদের উন্নয়ন দলের নিয়ন্ত্রণে নেই। যদি তারা বিকাশকারীদের প্রয়োজনীয় জিনিস সরবরাহ করতে না পারে তবে তারা কখনই একটি সম্পূর্ণ সমাধান সরবরাহ করতে সক্ষম হবে না।
— রেভস ম্যাজিকঅ্যান্ডি
সূত্র
8

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

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

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

প্রধানমন্ত্রী কেবল ক্লায়েন্টের সাথে বৈঠকটি খালি করার জন্য এবং হিজি ফিট রাখার জন্য সিডিআর (ক্রিটিকাল ডিজাইন রিভিউ) -এর জন্য উড়ে যাওয়ার নার্ভও রেখেছিলেন। প্রকল্পের আওতায় তাঁর ভ্রমণ ব্যয়ের জন্য তিনি যখন দাবি করেছিলেন তখন তাকে বিনীতভাবে নিজের সাথে ব্যভিচার করার কথা বলা হয়েছিল।

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

— ইভান প্লেস
সূত্র
8

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

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

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

ম্যানেজাররা যখন থ্যাঙ্কসগিভিং-এ কোড দিচ্ছেন।

আপনি যখন ইমেলগুলি পেতে শুরু করেন যেগুলি ডেটটাইম স্ট্যাম্প সহ রাত ১১ টার পরে এবং তার আগে সকাল 6 টার আগে।

কিছু জটিলতা কীভাবে পরিচালনা করতে হবে সে সম্পর্কে প্রতিটি প্রশ্নের উত্তর যখন একই প্রশ্নের সাথে মিলিত হয়, "এখনও সে সম্পর্কে চিন্তা করবেন না।"

যখন তারা এখনও প্রয়োজনীয়তা করছে তখনই বীটোরে আপনি কিউএতে যান বা লাইভ যান।

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

যখন ডাটাবেস দল এবং অ্যাপ্লিকেশন দল একে অপরের সাথে কথা বলবে না।

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

আপনি যখন কোনও ম্যানেজারের অফিসের বাইরে স্টপ লাইট ইনস্টল করার বিষয়টি বিবেচনা করেন তখন সেদিন তাঁর কাছে যাওয়া নিরাপদ কিনা তা আপনাকে জানানোর জন্য।

— HLGEM
সূত্র
2
আপনার প্রথম অনুচ্ছেদে কিকারটি হ'ল, যদি ব্যবস্থাপনা এটি করে থাকে তবে ডেডলাইনগুলি সম্ভবত ইতিমধ্যে বিনষ্ট এবং বোনাসগুলি অপ্রাপ্য।
— ডেভিড থর্নলি
1
@ ডেভিড থর্নলি, হ্যাঁ ঠিক তাই
— এইচএলজিইএম
6

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

মূলটি হ'ল আগাম একটি ব্যর্থ প্রকল্পের পথ চিহ্নিত করা। আমি মনে করি এক্ষেত্রে একমাত্র আসল 'দোযানের চিহ্ন' হ'ল আমরা কখন শেষ 'এর সংজ্ঞাটির সম্পূর্ণ অভাব হবে। অফসেটে আমরা এটি না জানলে আমরা ব্যর্থতা আইএমওর জন্য ডومড আছি।

— জ্যাকো প্রিটোরিয়াস
সূত্র
1
— আইএফ
6

আমি গত পাঁচ বছরে তিনটি ডেথ মার্চে এসেছি। এখানে এমন কিছু জিনিস রয়েছে যা আসন্ন আযাবের জন্য আমার অন্ত্রের অনুভূতিতে অবদান রাখে।

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

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

এটি আমার জন্য হয়েছিল যখন আমি যে প্রকল্পে ছিলাম তখন "হৃদয়ের উচ্চতর পরিবর্তন পরিবর্তন" হিট হয়েছিল। এটি কীভাবে কাজ করা উচিত সে সম্পর্কে আমি প্রশ্ন জিজ্ঞাসা করছিলাম এবং হঠাৎ করেই কারও পক্ষে সত্যিকার মতামত ছিল না।

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

— Vaccano
সূত্র
5

পল ভিক ব্ল্যাকহোল প্রকল্পগুলি সম্পর্কে বেশ কয়েক বছর আগে একটি দুর্দান্ত পোস্ট লিখেছিলেন । আমি মনে করি যে সমস্ত পরামর্শই প্রাসঙ্গিক। (আমি দৈর্ঘ্যের জন্য আইটেম এবং সারাংশ সম্পাদনা করেছি।)

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

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

আমি এখনও কোনও ব্যবস্থাপককে এই লাইনের সাথে কিছু বলতে শুনেছি এবং এটি মিথ্যা হিসাবে পরিণত হয়নি ।

— জেসন বেকার
সূত্র
Lolx! আসলেই সত্য; "আপনি হয়ত গুজব (ইউ) আরএস শুনেছেন ..." সভাটি।
— মাউগ
4

একটি মৃত প্রকল্পের কয়েকটি পয়েন্ট আমি এর অংশ ছিল:

  • ম্যানেজমেন্ট দ্রুত শেষ করতে দলকে দ্বিগুণ করে।
  • ডেভেলপাররা নির্ধারিত সময়সীমা পূরণের জন্য বাগগুলি "কবর দেওয়া" শুরু করে এবং এটি স্পষ্ট হলেও, কোড পর্যালোচনার সময় এটিকে উপেক্ষা করা হচ্ছে।
— Okan
সূত্র
3

পরিচালনা যখন প্রকল্পটি একই সাথে বিভিন্ন দিকে টেনে নিয়ে যায় এবং গাড়িটি এখনও স্থির থাকে।

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

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

এই সংক্ষিপ্ত নিবন্ধটি দেখুন: যখন আইটি প্রকল্পগুলি ডানদিকে যায় ।

নিবন্ধে বর্ণিত কোনও উপাদানের অনুপস্থিতিতে অ্যালার্ম ঘণ্টা বাজানো উচিত:

সুতরাং আপনার প্রকল্পে নিম্নলিখিত সমস্ত কিছু রয়েছে তা নিশ্চিত করুন, তা না হলে আপনার উদ্বেগ হওয়া উচিত:

(উপরের নিবন্ধটি উদ্ধৃত :)

  1. "প্রথমটি হ'ল তারা কী অর্জন করতে হবে তার সুস্পষ্ট দৃষ্টিভঙ্গির ভিত্তিতে।"

  2. "দ্বিতীয় বৈশিষ্ট্যটি ব্যবসায় জুড়ে থাকা বিভিন্ন পক্ষের সমর্থন এবং প্রতিশ্রুতি সম্পর্কিত, বিশেষত সিনিয়র ম্যানেজমেন্ট সম্পর্কিত।"

  3. "তৃতীয়টি হ'ল সমস্যাগুলি মোকাবেলা করার একটি বোঝাপড়া" "

  4. "চূড়ান্ত সাধারণ বৈশিষ্ট্যটি হ'ল পর্যাপ্ত সংস্থান এবং দক্ষতা উপলব্ধ করা হয়েছে" "

— থেরোবায়ুন
সূত্র
দুর্দান্ত নিবন্ধ! আমি "যখন জিনিসগুলি ঠিক হয়" পদ্ধতির পছন্দ করি।
— ব্যবহারকারী 8865
3

পরিসংখ্যানগতভাবে একটি সফ্টওয়্যার প্রকল্প শুরু হচ্ছে এটি একটি নিখুঁত চিহ্ন যে এটি ব্যর্থ হবে, তাদের মধ্যে অপ্রতিরোধ্য সংখ্যাগরিষ্ঠ হিসাবে ...

— নিতসান ওয়াকার্ট
সূত্র
1
আমি মনে করি এটি একটি স্টার্ট-আপ পরিসংখ্যান, অগত্যা কোনও সাধারণ সফ্টওয়্যার প্রকল্পের পরিসংখ্যান।
— এরিক পুনরায়
2
এখানে এলোমেলোভাবে গুগলযুক্ত একটি রেফারেন্স রয়েছে যা এটি মনে করে যে এটি কেবল স্টার্ট আপগুলিতে সীমাবদ্ধ নয়। বিষয়টিতে আরও রত্নগুলির জন্য মিঃ ম্যাককনেলের দুর্দান্ত র‌্যাপিড বিকাশ দেখুন ।
— নিতসান ওয়াকার্ট
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.