একটি দলে দ্বন্দ্ব ব্যবস্থাপনা - একটি ভারসাম্যমূলক কাজ বা একটি গুরুত্বপূর্ণ প্রয়োজনীয়তা?

এপিগ্রাফ:
একবার, হেজহগ এবং ছোট ভালুক বনে মিলিত হয়েছিল।
- হ্যালো, হেজহগ!
- হ্যালো, ছোট ভালুক!
সুতরাং, কথায় কথায়, কৌতুক করে রসিকতা, হেজহগটি ছোট ভালুকের মুখে আঘাত করেছিল...

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

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

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

কাজের দ্বন্দ্বের পরিস্থিতি হিসাবে সংজ্ঞায়িত করা যেতে পারে এমন সমস্ত পরিস্থিতিতে সাধারণ কী?



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

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

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

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

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

সংঘাতের পরিস্থিতির কয়েকটি উদাহরণ দেখার আগে, আসুন কিছু গুরুত্বপূর্ণ পয়েন্ট দেখি যা সমস্ত দ্বন্দ্বের জন্য সাধারণ।

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

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

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

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

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

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

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

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

আসুন সাধারণ থেকে জটিল পর্যন্ত কয়েকটি সাধারণ দ্বন্দ্ব পরিস্থিতি বিবেচনা করি:

দ্বন্দ্ব কর্ম সংক্রান্ত সমস্যা সম্পর্কিত নয়

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

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

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

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

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

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

কাজের সমস্যা সম্পর্কিত দ্বন্দ্ব:

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

আমি এখানে দুটি সাধারণ ক্ষেত্রে হাইলাইট করব:

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

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

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

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

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

আমাদের আলোচনাটি এরকম কিছু লাগছিল (খুব পরিকল্পিতভাবে, অবশ্যই, কথোপকথনটি আধা ঘন্টা ধরে চলেছিল):

- পাশা, কয়েকদিনের মধ্যে আমাদের একটা ফিচার ফ্রিজ আছে। এটা গুরুত্বপূর্ণ যে আমরা সবকিছু একসাথে করি এবং যত তাড়াতাড়ি সম্ভব পরীক্ষা শুরু করি। আমরা কিভাবে Igor মাধ্যমে পেতে পারি?
— তিনি অন্যভাবে পরিষেবাগুলি সেট আপ করতে চান, তিনি সেখানে আমার জন্য মন্তব্য আটকে দিয়েছেন...
- এবং সেখানে কি, বড় পরিবর্তন, অনেক ঝগড়া?
- না, ঘন্টা দুয়েক কাজ আছে, কিন্তু শেষ পর্যন্ত কোন পার্থক্য নেই, যেকোন ভাবেই কাজ হবে, এটার দরকার কেন? আমি এমন কিছু তৈরি করেছি যা কাজ করে, আসুন এটি গ্রহণ করি।
- শোন, কতদিন ধরে এসব নিয়ে আলোচনা করছেন?
- হ্যাঁ, আমরা এখন দেড় সপ্তাহ ধরে সময় চিহ্নিত করছি।
- উম... আমরা কি কয়েক ঘন্টার মধ্যে একটি সমস্যা সমাধান করতে পারি যেটি ইতিমধ্যে দেড় সপ্তাহ সময় নিয়েছে এবং এটি করতে পারে না?
- আচ্ছা, হ্যাঁ, কিন্তু আমি চাই না ইগোর মনে করুক যে আমি ঢুকে গেছি...
- শুনুন, আপনার কাছে আরও গুরুত্বপূর্ণ কী, আপনার ভিতরের সিদ্ধান্ত সহ মুক্তি দেওয়া, নাকি ইগরকে হত্যা করা? আমরা এটি ব্লক করতে পারি, তবে, রিলিজের মাধ্যমে উড়ে যাওয়ার একটি ভাল সুযোগ রয়েছে।
- আচ্ছা... অবশ্যই, ইগরের নাক মুছতে ভালো হবে, কিন্তু ঠিক আছে, মুক্তিটা আরও গুরুত্বপূর্ণ, আমি রাজি।
- ইগর যা ভাবছেন তা কি আপনার কাছে এত গুরুত্বপূর্ণ? সত্যি কথা বলতে, তিনি মোটেও অভিশাপ দেন না, তিনি কেবল যে জিনিসটির জন্য দায়ী তার বিভিন্ন জায়গায় একটি ঐক্যবদ্ধ পদ্ধতি চান।
- আচ্ছা, ঠিক আছে, তিনি মন্তব্যে যা বলেছেন আমাকে করতে দিন এবং আসুন পরীক্ষা শুরু করি।
- ধন্যবাদ, পাশা! আমি নিশ্চিত ছিলাম যে আপনারা দুজনের মধ্যে আপনি আরও পরিণত হবেন, যদিও ইগোরেক আপনার চেয়ে বড় :)

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

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

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

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

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

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

একটি প্রযুক্তিগত সমাধানের পছন্দ নিয়ে অন্য একটি দ্বন্দ্বে, একটি পক্ষের অনুপ্রেরণা বুঝতে আমার একটি লক্ষণীয় পরিমাণ সময় লেগেছিল (এটি একটি খুব অস্বাভাবিক ঘটনা ছিল), কিন্তু প্রেরণাটি পরিষ্কার হওয়ার পরে, সমাধানটি সুস্পষ্ট ছিল।

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

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

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

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

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

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

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

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

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

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

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

উত্স: www.habr.com