ওহ ছেলে, যদি আপনি সত্যিই বোঝাচ্ছিলেন যে সবকিছু আপনার সাথে ঘটেছে!
সতর্কতা : নীচের অনেকগুলি পয়েন্টে আপনার মনে হতে পারে যে আমি আপনাকে সমালোচনা করেছি এবং আমি আপনাকে ভুল-খুশির জন্য দায়ী করতে চাই এবং বাহ্যিক বিষয়গুলি বিবেচনা না করেই চাই। আমি না। এটি ঠিক যে আপনি বেশি বিবরণ দেন না এবং জিনিসগুলি যাতে খারাপ না হয় সেদিকে লক্ষ্য রাখার জন্য আমি কেবল পদক্ষেপের ক্রিয়াগুলির তালিকা সরবরাহ করি। আমি জানি আমি নিজে অনেক ভুল করেছি (প্রত্যেকেই করে) এবং সেগুলি থেকে শিখলে আমরা কেবল আরও ভাল হয়ে উঠি। এবং তাদের কাছ থেকে শিখতে, আমাদের প্রথমে তাদের ভুল হিসাবে দেখা শুরু করা উচিত, এবং আমাদের পক্ষ থেকে কী ভুল হয়েছে তার দায় স্বীকার করতে হবে। জাহান্নাম, অন্য ব্যক্তির অংশে যা ভুল হয়েছে তার দায় স্বীকার করুন, আপনি এটি থেকেও শিখতে পারেন।
আপনার প্রকল্প ব্যর্থ হয়েছে
এখনই এটি প্রশমিত করতে আপনি বেশি কিছু করতে পারবেন না।
তবে ভবিষ্যতে পুনরুত্পাদন করতে আপনি এড়াতে অনেক কিছু করতে পারেন। আমি আপনার প্রকল্প এবং সময় পরিচালনার দক্ষতা উন্নত করার চেষ্টা করার পরামর্শ দেব।
আমি এই বিষয়ের উপর সেরা অনুপাত ((বৈধ পরামর্শ) / পৃষ্ঠাগুলি) সহ একটি বই পড়েছি, যদিও এটি সেরা নাও হতে পারে, এটি রব থমসেটের র্যাডিকাল প্রকল্প পরিচালনা ।
আপনার প্রকল্পটি কীভাবে ব্যর্থ হয়েছে তা আপনি সত্যিই নির্দিষ্ট করেন না, তবে আমি এমন কোনও সংমিশ্রণ গ্রহণ করব যা স্বাভাবিক ব্যয় / সময় / কোয়ালি ত্রিভুজের ক্ষেত্রে ভারসাম্যহীনতা এনেছিল । আমার চোখের সবচেয়ে গুরুত্বপূর্ণ বিষয়টি হল আপনার প্রযুক্তিগত অভিনেতা (ডেভস এবং পরীক্ষক) উভয়ই কিন্তু আপনার স্টেকহোল্ডারদের সাথে সর্বদা যোগাযোগ রাখার সময় প্রকল্প এবং বিকাশের নেতৃত্ব দেওয়া। অনেক বেশি প্রকল্প ব্যর্থ হয় কারণ তারা স্পনসর বা স্টেকহোল্ডারদের কথায় কান দেয় না এবং তাদের প্রক্রিয়াতে জড়িত হওয়ার জন্য চাপ দেয় না।
যদি তারা জড়িত না হয় তবে তারা কী চায় তা আপনি জানতে পারবেন না। তারা কী চায় তা যদি আপনি না জানতে পারেন তবে আপনি এটি সরবরাহ করতে পারবেন না। যদি আপনি এটি সরবরাহ না করেন তবে তারা অসন্তুষ্ট হবেন। এটি একটি ব্যর্থতা। তদুপরি, আপনি যদি আপনার স্টেকহোল্ডারদের জড়িত না হন তবে তারা সফ্টওয়্যার ইঞ্জিনিয়ারিংয়ের বাস্তবতা থেকে সংযোগ বিচ্ছিন্ন হয়ে গেছে, যার অর্থ তারা আপনার সমস্যাগুলি বুঝতে পারে না। যদি তারা প্রায়শই আপনার সাথে যোগাযোগ করে তবে তারা আপনাকে কীভাবে মোকাবেলা করতে হবে তা আরও ভালভাবে উপলব্ধি করতে পারে। আপনি যখন তাদের বলবেন যে "ছোট" [হাসি] বৈশিষ্ট্যটি কয়েক মাস সময় নেবে তখন তারা বুঝতে সক্ষম হবে। তারা আপনার পরিকল্পনাকে আরও ভালভাবে বিশ্বাস করতে পারে কারণ তারা এটি তৈরিতে সহায়তা করেছিল। একটি প্রকল্প কেবল "শুরুতে চশমা, দেব, পরীক্ষা, শেষে বিতরণ" দিয়ে সফল হতে পারে না। এটা ঠিক কখনও না। আপনি চশমা জিজ্ঞাসা করা হয়েছিল যা বিতরণ করতে পারে,
সর্বাধিক গুরুত্বপূর্ণ, একটি পূর্বপরিকল্পিত করুন এবং নিশ্চিত করুন যে এটি অহং-কম এবং দোষ-খেলাই নয়। কেবল বিষয়গুলি চিহ্নিত করুন।
আপনি কোডিংয়ের জন্য দিন কাটিয়েছেন তা আপনার দল বাতিল করেছিল by
আমি সেই পরিস্থিতিতে ছিলাম। আবার, এটি বাদ দেওয়ার জন্য আপনি খুব বেশি কিছু করতে পারবেন না:
- পরে এসসিএমে রাখুন।
- ছোট বড় বিট এবং টুকরোগুলি একটি বিশাল রিফ্যাক্টরিংয়ের পরিবর্তে প্রধান কোড বেসের দিকে ধীরে ধীরে ধাক্কা দেওয়ার চেষ্টা করুন।
তবে এই ধরণের পরিস্থিতি রোধ করতে আপনি আবারও কিছু করতে পারেন:
- এটা কেন ঘটেছিল? প্রত্যাখার কারণ কী?
- বেশিরভাগ সময় যখন আমি এটি ঘটে দেখি (এবং এটি আমার ক্ষেত্রেও ছিল), এর অর্থ বিকাশকারী একাকী বা গরু-বালক-কোডিং মোডে গিয়ে এমন জিনিস তৈরি করেছিল যা কখনও জিজ্ঞাসা করা হয়নি। ব্যবসায়ের প্রয়োজনীয়তা থেকে আসে না এমন কোডটি অভিনব এবং "আরও ভাল" হতে পারে তবে প্রায়ই সময় এবং অর্থের অপচয় হয়। এছাড়াও, আপনি যদি এটি একীভূত করেন তবে এটি আরও পরীক্ষার প্রয়োজন হবে কারণ এটি আবার পরীক্ষার প্রয়োজন হবে। এমন লোকদের মতো ভাবুন যারা আপনাকে অর্থের লেনদেন করে: আপনাকে সেই স্তরেও দক্ষ হতে হবে।
- সফ্টওয়্যারটির মানটি সন্তুষ্টিজনক ছিল? এটি কি আপনার সংস্থার ক্রিয়াকলাপে মানদণ্ড এবং নিয়মাবলী মেনে চলে?
- আপনি কি নিয়মিত (এবং ঘন ঘন!) এ সম্পর্কে সরাসরি পরিচালকদের রিপোর্ট করেছিলেন? আপনি কি মাঝে মাঝে দলের অন্যান্য বিকাশকারীদের সাথে বিনিময় করেছেন? যদি তা না হয় তবে তারা এ সম্পর্কে কিছুই জানে না, এখনই এটি পর্যালোচনা করা ও পর্যালোচনা করা তাদের পক্ষে এক বিশাল সময় ব্যয়। এটি একই সময়ে অ্যাকাউন্টে আসে না। এটি সর্বদা আপনার ভাড়া অ্যাপার্টমেন্ট পরিষ্কার করার চেষ্টা করার পরে এবং বাইরে বেরোনোর সময়ই এটি পরিষ্কার করার চেষ্টা করার মতো: নিয়মিতভাবে করা যদি করা হত তবে এটি করা খুব কঠিন, এবং এটি প্রায়শই করা হবে না like ঠিক আছে।
- আপনি উত্পাদন পরীক্ষা উত্পাদন করেছেন? ইউনিট পরীক্ষা? একীকরণের পরীক্ষা?
- আপনার কোডটি কি নিয়মিত এসসিএম-এ পরীক্ষা করা হয়েছিল? এটি কি অন্য শাখায় ছিল? এটির জন্য কি আলাদা শাখা দরকার ছিল বা ট্রাঙ্কে এটি করা যেতে পারে? প্রতিশ্রুতিবদ্ধ কোড বন্ধ করা সাধারণত একটি খারাপ চিহ্ন। স্পষ্টতই কখনও কখনও আপনি এটি করার জন্য প্রলুব্ধ হন তবে আপনি কেবল নিজেকে পায়ে গুলি করেন।
আপনার সংস্থায় কেউ আপনার ধারণা শোনেন না
ঠিক আছে, এখানে 2 টি বিকল্প রয়েছে এবং আমরা উভয়ের দিকে নজর দেব:
- আপনার ধারণা খারাপ ছিল।
- আপনি ধারণা ভাল ছিল।
আসুন তারা খারাপ বলে ধরে নেওয়া শুরু করুন (আবার, সেটির প্রতি স্ব-প্রতিবিম্বিত করা এবং আপনার ধারণাটি গ্রহণ করা সহজ ছিল কেবল খারাপই হতে পারে, আমি জানি)। আপনি এটি পরিবর্তন করতে কি করবেন?
- কেন আপনি এই ধারণা নিয়ে এসেছেন? যুক্তি কী ? আপনার ধারণাটি টেবিলে আনার চেষ্টা করে যাবার কি প্রকৃত প্রয়োজন আছে?
- আপনি কীভাবে এই ধারণাটি নিয়ে এসেছেন? আপনি নিজে থেকে এটি করেছেন? ভাগ করে নিলে? উচ্ছ্বাস,? পরিকল্পনা? প্রোটোটাইপ? (এগুলি সঠিক ক্রমে করুন it যদি এটি পথে ব্যর্থ হয় তবে ধারণাটি বাতিল করুন, চালিয়ে যাবেন না least বা কমপক্ষে আপনার কাজের সময়সূচিতে যাবেন না))
আইডিয়াগুলি কেবল আইডিয়া। আপনি যদি তাদের কেবল ধারণা হিসাবে পরামর্শ দেন এবং সেগুলি প্রত্যাখ্যান করা হয় তবে আপনি কেন এটি সম্পর্কে খারাপ লাগবেন তা আমি দেখতে পাচ্ছি না। তবে আপনি যদি কাউকে না জানিয়ে এগুলি নিয়ে কাজ করেন এবং কেবলমাত্র আপনার ধারণাগুলি জমা দেন এবং সেগুলি প্রত্যাখ্যান হয় তবে স্পষ্টতই আমি নষ্ট হওয়ার সময় হতাশা অনুভব করি। এবং আপনার পরিচালকরা কি!
আপনার ধারণাগুলি ভাল ছিল ধরে নিলাম:
- আপনার উপস্থাপনা ভাল ছিল?
- আপনার উপস্থাপনা সরবরাহ করার উপায় কি ভাল ছিল? (আমি একজন বিকাশকারী নই, আমি জানি আমি কিসের কথা বলছি: আমরা ক্রুদ্ধ হন, অহংকারী , গোঁড়া PITAs যারা সবসময় সঠিক হয় এবং যার সাথে এটা নিয়ে কাজ করা কঠিন কারণ প্রায়ই এর আমাদের অনুপাতহীন অহংবোধের )।
- আপনি এটি বাস্তবায়নের পরিকল্পনা আছে? আপনি কি ব্যয় এবং সময় সম্পর্কে চিন্তা করেছিলেন? আপনি কী ভেবেছিলেন এটি কীভাবে ব্যবহারকারী / গ্রাহকদের উপকার করে? আপনি কী ভাবেন যে এটি বিক্রয়কে কীভাবে প্রভাবিত করে? আপনি কী ভাবেন যে কীভাবে সেই ধারণায় কাজ করা অন্যান্য প্রকল্প এবং অগ্রাধিকারগুলিকে প্রভাবিত করতে পারে? আপনি আমাকে বলছেন, "আমি কেন এই সমস্ত করবো, এগুলি আমার পরিচালক এবং বিপণন বা বিক্রয় দলের কাজ?!" এখনই বাদে আপনি তাদের সমস্ত কাজের একটি অংশ করার চেষ্টা করছেন।
আপনি আপনার দলে বলের সাথে যে নকশার প্যাটার্নটি প্রবর্তন করেছিলেন তা গণ্ডগোল তৈরি করেছে
- আপনি কেন প্যাটার্নটি চালু করলেন?
- যদি এটি কোনও বিশৃঙ্খলা সৃষ্টি করে তবে সম্ভবত এটি হয়:
- সঠিক প্যাটার্ন ছিল না,
- সঠিকভাবে প্রয়োগ করা হয়নি,
- সঠিকভাবে সংহত ছিল না।
- আপনি কিভাবে এটি পরিচয় করিয়ে দিয়েছিলেন? আপনি "জগাখিচুড়ি" রাষ্ট্রটি কীভাবে সংজ্ঞায়িত করেন?
- কম পাঠযোগ্য কোড?
- কম রক্ষণাবেক্ষণযোগ্য?
- বিল্ড ভেঙে গেছে?
- বিভিন্ন ধরণের "গণ্ডগোল" রয়েছে। জানা কি জগাখিচুড়ি হয় কি সেখানে সাফল্যর মুখ সাহায্য করতে পারে, এবং যদি এটা নকশা প্যাটার্ন দোষ ছিল।
এছাড়াও, আমি নিজেই পদ্ধতির দ্বারা কিছুটা অবাক হয়েছি। আপনাকে আসলে কোনও নকশার প্যাটার্ন চালু করার জন্য চাপ দিতে হয়েছিল? এটি বরং অদ্ভুত বলে মনে হচ্ছে। একটি প্যাটার্ন হয় ইতিমধ্যে সেখানে আছে, বা আপনাকে প্যাটার্ন অনুযায়ী আপনার সমাধানের একটি অংশ রিফ্যাক্টর করতে হবে। আপনি এটির মতো চাপ দেবেন না আপনি যেমন কোনও কাঠামো বা প্রযুক্তি গ্রহণ করবেন (যেমন লোকেরা সর্বত্র এক্সএমএল পাওয়াতে সত্যই শক্তিশালী হয়ে গেছে, এবং এখন লোকেরা বড় উজ্জ্বল বর্ণগুলিতে তাদের পণ্যের কভারটিতে এইচটিএমএল 5 লিখতে সক্ষম হওয়ার জন্য চাপ দেওয়া শুরু করে)।
কেন চাপ দিতে হবে? কেন প্রতিরোধ ছিল? সম্ভবত এটি ন্যায়সঙ্গত ছিল।
আপনি কি এমন উদাহরণ প্রদান করতে সক্ষম হয়েছিলেন যে এই নির্দিষ্ট প্যাটার্নটি আপনার কোড বেসকে উল্লেখযোগ্য উপায়ে উন্নত করতে সহায়তা করবে (উদাহরণস্বরূপ, এটি রিফ্যাক্টরিং টু প্যাটার্নসের উদাহরণের সাথে মিলিয়ে )।
পুরোপুরি অফ টপিক নোট তবে এটিই আমি প্রথমে ভেবেছিলাম যখন আমি প্রশ্নের শিরোনামটি পড়ি যেমন এটি ভেবেছিল এটি সফ্টওয়্যার ব্যর্থতার সাথে উল্লেখ করেছে ... আমার একটি সফ্টওয়্যার ছিল যার একটিতে একটি বিশেষ ধরণের ব্যতিক্রম পরিচালনা করার জন্য একটি ব্ল্যাকহোল শ্রেণি প্রয়োগ করা হয়েছিল উপাদান। এটি সম্ভবত (এবং সত্যিই হ'ল) একটি স্পষ্টতই অদ্ভুত এবং নোংরা হ্যাকের মতো মনে হতে পারে, তবে নামকরণটি নিজেই এত দুর্দান্ত ছিল যে ব্যর্থতা সামলানোর জন্য মোটামুটি দুর্দান্ত উপায়ের জন্য আমরা সকলেই এটির প্রশংসা করি! :)