টিম লিস্টার - বইয়ের সহ-লেখক

• "মানব ফ্যাক্টর। সফল প্রকল্প এবং দল" (মূল বইটিকে "পিপলওয়্যার" বলা হয়)
• "ভাল্লুকের সাথে ওয়াল্টজিং: সফ্টওয়্যার প্রকল্পে ঝুঁকি ব্যবস্থাপনা"
• "অ্যাড্রেনালিন-পাগল এবং প্যাটার্ন দ্বারা zombified. প্রকল্প দলের আচরণের নিদর্শন"

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

টিমের সফ্টওয়্যার বিকাশে 40 বছরের অভিজ্ঞতা রয়েছে; 1975 সালে (যারা এই হ্যাব্রাপোস্টটি লিখেছেন তাদের কেউই এই বছর জন্মগ্রহণ করেননি), টিম ইতিমধ্যেই Yourdon Inc এর নির্বাহী ভাইস প্রেসিডেন্ট ছিলেন। তিনি এখন পরামর্শ, শিক্ষাদান এবং লেখালেখিতে সময় ব্যয় করেন, মাঝে মাঝে সফর করেন রিপোর্ট সহ বিশ্বজুড়ে সম্মেলন।

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

মাইকেল: আপনি এখন কি করছেন সে সম্পর্কে আপনি কিছু শব্দ বলতে পারেন?

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

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

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

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

মাইকেল: অর্থাৎ, আপনি প্রজেক্ট চালু করেন, কিকঅফ করেন এবং চেক করেন যে রেলগুলি সঠিক দিকে যাচ্ছে?

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

চটপটে 19 বছর

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

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

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

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

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

ওলেগ: আপনি চটপটে ইশতেহার উল্লেখ করেছেন। সমস্যাটির আধুনিক উপলব্ধি বিবেচনায় নিয়ে আমাদের কি কোনোভাবে আপডেট বা সংশোধন করতে হবে?

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

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

পিপলওয়্যার: 30 বছর পরে

ওলেগ: পিপলওয়্যার কি একটি বিপ্লবের পাশাপাশি ইশতেহার ছিল?

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

টিম বিপুল সংখ্যক বক্তৃতা দিয়েছে তা সত্ত্বেও, তাদের মধ্যে খুব কমই ইউটিউবে পোস্ট করা হয়েছে। আপনি 2007 থেকে "The Return of Peopleware" প্রতিবেদনটি দেখতে পারেন। গুণমান, অবশ্যই, পছন্দসই হতে অনেক ছেড়ে.

মাইকেল: বইটি প্রকাশিত হওয়ার পর থেকে গত 30 বছরে কি কিছু পরিবর্তন হয়েছে?

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

আমরা সবাই DevOps-এ থাকি

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

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

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

মাইকেল: devops এর সম্পূর্ণ ধারণা যত তাড়াতাড়ি সম্ভব অর্থপূর্ণ উন্নয়ন প্রদান করা হয়. আমি দেখতে পাচ্ছি যে পৃথিবী আরও দ্রুত গতিতে শুরু করেছে। কিভাবে এই ধরনের accelerations মানিয়ে? দশ বছর আগেও এর অস্তিত্ব ছিল না!

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

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

প্যাটার্নস এবং অ্যান্টিপ্যাটার্নস

ওলেগ: আপনি সাধারণত নিদর্শন এবং অ্যান্টিপ্যাটার্ন সম্পর্কে কথা বলেন, এবং এটি প্রকল্পের জীবন এবং মৃত্যুর মধ্যে পার্থক্য। এবং এখন, devops আমাদের জীবনে বিস্ফোরিত. এটির কি নিজস্ব প্যাটার্ন এবং অ্যান্টি-প্যাটার্ন আছে যা প্রকল্পটিকে ঘটনাস্থলেই মেরে ফেলতে পারে?

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

আমরা কেবল আমাদের কমরেডদের সাথে আলোচনা করছিলাম যে এই বছরটি একটি বার্ষিকী বছর, মানুষ চাঁদে অবতরণের পঞ্চাশ বছর। এটি 1969 সালে হয়েছিল। যে প্রযুক্তিটি লোকেদের সেখানে যেতে সাহায্য করেছিল তা 1969 প্রযুক্তিও নয়, বরং 1960 বা 62, কারণ NASA শুধুমাত্র যা নির্ভরযোগ্যতার ভাল প্রমাণ ছিল তা ব্যবহার করতে চেয়েছিল। এবং তাই আপনি এটি তাকান এবং বুঝতে - হ্যাঁ, এবং তারা সত্য ছিল! এখন, না, না, তবে আপনি প্রযুক্তির সাথে সমস্যায় পড়েন কারণ সবকিছু খুব শক্তভাবে ঠেলে দেওয়া হয়, সমস্ত ফাটল থেকে বিক্রি হয়। লোকেরা সব জায়গা থেকে চিৎকার করছে: "দেখুন, কী জিনিস, এটি সবচেয়ে নতুন জিনিস, বিশ্বের সবচেয়ে সুন্দর জিনিস, একেবারে সবার জন্য উপযুক্ত!" ঠিক আছে, এটিই... সাধারণত এই সমস্তই কেবল একটি ছলনা হিসাবে পরিণত হয় এবং তারপরে এটিকে ফেলে দিতে হবে। সম্ভবত এটি সব কারণ আমি ইতিমধ্যে একজন বয়স্ক মানুষ এবং এই জাতীয় জিনিসগুলিকে অনেক সন্দেহের সাথে দেখি, যখন লোকেরা শেষ হয়ে যায় এবং বলে যে তারা সেরা প্রযুক্তি তৈরি করার একমাত্র, সবচেয়ে সঠিক উপায় খুঁজে পেয়েছে। এই মুহুর্তে, আমার ভিতরে একটি কণ্ঠস্বর জেগে ওঠে যা বলে: "কী জগাখিচুড়ি!"

মাইকেল: প্রকৃতপক্ষে, আমরা পরবর্তী রূপালী বুলেট সম্পর্কে কতবার শুনেছি?

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

মাইকেল: হ্যাঁ, প্রধান "জীবন, মহাবিশ্ব এবং সবকিছুর প্রশ্ন": এই প্রযুক্তি বা পদ্ধতি কি আপনার পরিস্থিতির জন্য উপযুক্ত নাকি?

টিম: এই প্রশ্নটি ইতিমধ্যে প্রযুক্তি গ্রুপের সাথে আলোচনা করা যেতে পারে। এমনকি কিছু পরামর্শদাতা আনতে পারে। প্রকল্পটি একবার দেখুন এবং বুঝুন - আমরা কি এখন আগের চেয়ে সঠিক এবং দরকারী কিছু করব? হয়তো মানিয়ে যাবে, হয়তো হবে না। কিন্তু সবচেয়ে গুরুত্বপূর্ণ, ডিফল্টরূপে এই ধরনের সিদ্ধান্ত নেবেন না, শুধুমাত্র এই কারণে যে কেউ আস্ফালন করেছে: “আমাদের একটি ব্লকচেইন খুবই প্রয়োজন! আমি বিমানের একটি ম্যাগাজিনে তার সম্পর্কে পড়েছি!” সিরিয়াসলি? এটা এমনকি মজার না.

পৌরাণিক "ডিভপস ইঞ্জিনিয়ার"

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

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

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

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

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

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

এখন এর চাহিদা অনেক দেখছি। আপনি যদি একজন প্রযুক্তিবিদ হন, আপনার কোম্পানি আপনাকে সাহায্য করতে পারে, কিন্তু নির্বিশেষে, আপনার প্রয়োজন, সত্যিই আপনার নিজের ক্যারিয়ারের পথ খুঁজে বের করতে হবে কারণ প্রযুক্তি পরিবর্তন হতে থাকে এবং আপনাকে এটির সাথে নিজেকে নতুনভাবে উদ্ভাবন করতে হবে! মাত্র বিশ বছরে, প্রযুক্তি অন্তত পাঁচবার পরিবর্তন করতে পারে। প্রযুক্তি একটি অদ্ভুত জিনিস ...

"সব বিষয়ে বিশেষজ্ঞ"

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

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

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

ঝুঁকি এবং অনিশ্চয়তা

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

ওলেগ: দ্রুত সরান এবং জিনিস ভাঙ্গা!

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

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

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

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

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

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

অন্যদিকে, এই ব্যবসাটি আমার এত পছন্দের কারণ এটি ঝুঁকিপূর্ণ। আমরা কিছু করি, এবং সেই জিনিসগুলি ঝুঁকিপূর্ণ। তাদের একটি প্রাপ্তবয়স্ক পদ্ধতির প্রয়োজন। একা উদ্দীপনা আপনার সমস্যার সমাধান করবে না!

প্রাপ্তবয়স্ক ইঞ্জিনিয়ারিং চিন্তা

মাইকেল: শিশুদের সঙ্গে উদাহরণ ভাল. আমি যদি একজন সাধারণ প্রকৌশলী হই, তবে আমি সন্তান হিসাবে খুশি। কিন্তু কিভাবে আপনি আরো প্রাপ্তবয়স্ক চিন্তার দিকে এগোবেন?

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

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

টিম: হুবহু। আমি মনে করি সেরা প্রযুক্তিবিদরা, যদি আপনি তাদের ঘনিষ্ঠভাবে দেখেন, তারা তাদের নিজস্ব ব্যবস্থাপক। আমি কিভাবে এটি গঠন করতে পারি ...

ওলেগ: আপনার জীবন আপনার প্রকল্প, যা আপনি পরিচালনা করেন।

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

কীভাবে ঝুঁকি ব্যবস্থাপনায় যেতে হয়

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

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

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

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

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

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

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

যোগাযোগের দাম

ওলেগ: বিভিন্ন কারণে এই ধরনের বিদায়ী কর্মীদের নিয়োগ করা কি আরও ব্যয়বহুল নয়? সর্বোপরি, তারা কাজ না করে প্রতিনিয়ত আড্ডা দিচ্ছেন!

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

মাইকেল: বিশেষীকরণ, দক্ষতা বা কাজের উপায় নির্বিশেষে এটি প্রকল্পের সাথে জড়িত প্রত্যেকের জন্য প্রযোজ্য। আপনি সবাই প্রকল্পের সাফল্য আগ্রহী.

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

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

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

মাইকেল: কিছু কোড লিখুন!

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

ওলেগ: মিশা, তুমি কিছু ভাবছ।

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

বেতন ছাড়া জীবন

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

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

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

সেরা পরামর্শ

মাইকেল: "সর্বোত্তম পরামর্শ" এ ফিরে যাওয়া, আপনি কি আপনার ক্লায়েন্টদের বারবার বলবেন এমন কিছু আছে? 80/20 সম্পর্কে একটি ধারণা আছে, এবং কিছু পরামর্শ সম্ভবত আরো প্রায়ই পুনরাবৃত্তি করা হয়।

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

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

আমার কাছে, এই সব ভীতিকর দেখায়. লোকেরা জটিল, বিরক্তিকর সমস্যাগুলির সাথে মোকাবিলা করে এবং ভান করতে থাকে যে তারা যদি কেবল তাদের আঙ্গুলগুলি অতিক্রম করে এবং সেরাটির জন্য আশা করে তবে "সেরা" আসলে ঘটবে। না, এটা সেভাবে কাজ করে না।

ঝুঁকি ব্যবস্থাপনা অনুশীলন করুন!

মাইকেল: আপনার মতে, ঝুঁকি ব্যবস্থাপনায় কতটি প্রতিষ্ঠান জড়িত?

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

মাইকেল: এবং তারপরও, এই সংস্থাগুলির মধ্যে কতজন ঝুঁকি ব্যবস্থাপনায় জড়িত, পাঁচ শতাংশ?

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

হ্যাঁ, আমি প্রায়শই শুনি, "সমস্যা যেমন আসবে আমরা সমাধান করব।" নিশ্চয় আমরা করব? আমরা কি সত্যিই সিদ্ধান্ত নেব?

ওলেগ: আপনি এটি সহজভাবে করতে পারেন এবং প্রকল্পের সনদে সহজভাবে গুরুত্বপূর্ণ ইনভেরিয়েন্টগুলি লিখতে পারেন, এবং যদি ইনভেরিয়েন্টগুলি ভেঙে যায়, শুধু প্রকল্পটি পুনরায় চালু করুন৷ এটা খুব piembucky সক্রিয় আউট.

মাইকেল: হ্যাঁ, এটি আমার সাথে ঘটেছিল যে যখন ঝুঁকিগুলি ট্রিগার করা হয়েছিল, তখন প্রকল্পটিকে সহজভাবে সংজ্ঞায়িত করা হয়েছিল। চমৎকার, বিঙ্গো, সমস্যা সমাধান, আর চিন্তা করবেন না!

টিম: এর রিসেট বোতাম টিপুন! না, এটা সেভাবে কাজ করে না।

DevOops 2019-এ মূল বক্তব্য

মাইকেল: আমরা এই সাক্ষাৎকারের শেষ প্রশ্নে আসি। আপনি একটি মূল বক্তব্য নিয়ে পরবর্তী DevOops-এ আসছেন, আপনি যা বলতে যাচ্ছেন তা কি গোপনীয়তার পর্দা তুলতে পারবেন?

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

মাইকেল: আমিও, কয়েক বছর ধরে পরামর্শে কাজ করছি এবং আপনি কী বিষয়ে কথা বলছেন তা ভালভাবে বুঝতে পারি।

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

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

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

টিম লিস্টার একটি মূল বক্তব্য নিয়ে আসবেন "চরিত্র, সম্প্রদায় এবং সংস্কৃতি: সমৃদ্ধির জন্য গুরুত্বপূর্ণ কারণ"DevOops 2019 সম্মেলনে, যা সেন্ট পিটার্সবার্গে 29-30 অক্টোবর, 2019-এ অনুষ্ঠিত হবে। আপনি টিকিট কিনতে পারেন অফিসিয়াল ওয়েবসাইটে. আমরা DevOops এ আপনার জন্য অপেক্ষা করছি!

উত্স: www.habr.com