একটি দলে 150 জন লোক থাকতে পারে? দ্রুত চটপটে হ্যাঁ বলে

FAST agile হল সবচেয়ে আকর্ষণীয় সাংগঠনিক অনুশীলন যা আমি কিছুক্ষণের মধ্যে শিখেছি। আজ আমি FAST চটপটে কী তা শেয়ার করব এবং এটি পরীক্ষা করার উপযুক্ত কিনা তা অন্বেষণ করি৷ টিএল;ডিআর? বেশ জোরদার, কিন্তু এখনও পরীক্ষামূলক।

ফাস্ট অ্যাজিল কী?

1. FAST Agile একটি চটপটে সফ্টওয়্যার বৈকল্পিক। FAST খুব বড় দলের মধ্যে স্ব-সংগঠনের উপর দৃষ্টি নিবদ্ধ করে। এই বড় দলগুলোকে বলা হয় কালেক্টিভ। তারা কয়েক জন হতে পারে, 150 জনের মত হতে পারে [1]।

সপ্তাহে দুবার, যৌথসভা হয়। সাক্ষাতে:

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

FAST চটপটের সবচেয়ে আকর্ষণীয় অংশ হল এই স্ব-সংগঠিত দলগুলি, তাই আসুন একটু বিস্তারিতভাবে তাদের বর্ণনা করি।

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

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

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

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

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

পার্থক্যের সারাংশ

FAST যেভাবে বেশিরভাগ চটপটে সফ্টওয়্যার সংস্থাগুলি আজ চালায় তার থেকে অনেক আলাদা। আমি তাদের দেখতে এখানে পার্থক্য আছে:

আপনি দেখতে পাচ্ছেন, বেশিরভাগ কোম্পানি আজ যা করছে তার থেকে FAST একটি ভিন্ন পদ্ধতি।

তাই ট্রেডঅফ কি?

আমি এটি দেখতে পাচ্ছি, এগুলি হল দ্রুত চটপটের ট্রেডঅফ:

• FAST আরও ভাল সাংগঠনিক মাপযোগ্যতা অফার করতে পারে
• FAST ক্রমবর্ধমান সঙ্গে পরীক্ষা করা যেতে পারে
• FAST এর ফলে কম পুনর্গঠন হওয়া উচিত
• দ্রুত অগ্রাধিকার পরিবর্তনে সাড়া দেওয়া সহজ করে তোলে
• অভ্যন্তরীণ প্রেরণা এবং ধরে রাখার জন্য FAST আরও ভাল হতে পারে

কিন্তু…

• অনেক পরিবেশ FAST এর সাথে বেমানান
• আপনাকে স্ব-ব্যবস্থাপনা পরিচালনা করতে হতে পারে
• FAST এর জন্য অনেক কাজ করতে হয়
• FAST উপকরণগুলি পরিভাষায় পূর্ণ

আমরা পালাক্রমে এই প্রতিটি আলোচনা করব.

FAST আরও ভাল সাংগঠনিক মাপযোগ্যতা অফার করতে পারে

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

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

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

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

দল কত বড় হওয়া উচিত?

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

ছোট দলের সুবিধা

• দলের মধ্যে কম সমন্বয় এবং যোগাযোগ ওভারহেড.
• ফলে দ্রুত চলাচল করতে পারে।
• কাজের কম প্রবাহ, তাই ফোকাস করা এবং ফলাফল তৈরি করা সহজ।
• পরিচালনা করা সহজ।

বড় দলের সুবিধা

• চাটুকার সংগঠন। 150 জন প্রকৌশলী সহ একটি প্রকৌশল সংস্থায় দশজনের দল সহ 3-4 জন পরিচালক থাকবে। এতে 6-8 জন পরিচালক এবং 1-2 জন ভিপি থাকবে এবং পাঁচজনের দল থাকবে। একটি প্রতিষ্ঠানে বিভ্রান্তি কোথা থেকে আসে? সম্ভবত নেতৃত্ব, তাই বড় দল বিভ্রান্তি কমাতে পারে.
• আরও স্থিতিস্থাপকতা। কেউ ছুটি নিতে পারে এবং দল ঠিকঠাক চালিয়ে যেতে পারে।

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

অনেক নেতা যে পন্থা অবলম্বন করেন তা হল বড় দল তৈরি করা যা কাজের কম প্রবাহে ফোকাস করে। এটি অভ্যন্তরীণ দলের জটিলতা হ্রাস করে, এবং সাংগঠনিক জটিলতাও হ্রাস করে।

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

স্কেলিং সংস্থাগুলি চ্যালেঞ্জিং কাজ

আমার পরামর্শমূলক ব্যবসার বেশিরভাগই সংস্থাগুলিকে স্কেল মোকাবেলায় সহায়তা করছে। স্কেলিং চ্যালেঞ্জের বেশ কয়েকটি পর্যায় রয়েছে সংস্থাগুলির মধ্যে রয়েছে৷

প্রথম বাধাটি সাধারণত 15-25 ইঞ্জিনিয়ার চিহ্নে থাকে। এই সময় আপনার অ্যামিবা অনেক বড় হয়েছে, এবং বিভক্ত করা প্রয়োজন। আপনি এই ধরনের সমস্যা দেখতে পাচ্ছেন:

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

এবং একটি দ্বিতীয় বাধা প্রায় ষাট প্রকৌশলী. এই মুহুর্তে, আপনি অনেক বেশি সমন্বয় সমস্যা দেখতে শুরু করেন:

• ক্রস-টিম প্রকল্পগুলি খুব কমই সফল হয়।
• পণ্যের কাজ প্ল্যাটফর্ম দলগুলিকে জলাবদ্ধ করে, বা তদ্বিপরীত।
• বড় উদ্যোগ সম্পন্ন করতে অক্ষমতা।

আমি দেখেছি মেধাবী ব্যক্তিরা সাংগঠনিক জটিলতায় এই ধাপ-ক্রম পরিবর্তনগুলি নেভিগেট করতে বারবার ব্যর্থ হন। আমার ধারণা হল যে আপনি যখন ব্যবস্থাপনার একটি অতিরিক্ত স্তর যুক্ত করেন তখন এই ধাপের ক্রম জটিলতার সাথে মিলে যায়।

ক্রমবর্ধমান প্রকৌশল সংস্থা একটি বাস্তব দক্ষতা. সংস্থা এবং লোকেরা কীভাবে কাজ করে তার গভীর বোঝার প্রয়োজন। আপনি যেমন জিনিস সম্পর্কে শিখুন:

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

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

দ্রুত চটপটে একটি চিন্তা পরীক্ষা

সুতরাং, কল্পনা করুন যে আপনি দলের আকার স্কেল করতে পারেন । পাঁচ বা দশ জনের দল না হয়ে, আপনার যদি কার্যকর বিশ-জনের দল থাকতে পারে? নাকি ষাট জনের দল?

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

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

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

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

যদি এটি করে, তাহলে এটি এমন একটি উপায় অফার করবে যা সংস্থাগুলিকে স্কেল করার জন্য যা সম্ভাব্যভাবে স্কেলিং সংস্থাগুলিতে আরও ভাল মাত্রার অর্ডার। কেন এত? ষাট জনের আকারের "টিম/সম্মিলিত" সহ একটি সংস্থা স্কেলিং বনাম ছয় জন লোকের দলগুলির সাথে বেড়ে ওঠা একটি সংস্থার তুলনা করা যাক৷

এই যুক্তিতে অনেক অনুমান তৈরি করা হয়েছে এবং আপনি এতে কিছু ছিদ্র করতে সক্ষম হতে পারেন। কিন্তু আপনি যদি তাও করেন, FAST মূলত একটি বৃহত্তর সাংগঠনিক ইউনিটকে পণ্য এবং কোডবেসের একটি এলাকা মালিকানার অনুমতি দেয়।

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

আমি FAST-এ উৎসাহী হওয়ার দ্বিতীয় কারণ হল যে স্ব-সংগঠন করার জন্য লোকেদের একটি বড় গোষ্ঠীর সাথে আমার কিছু অভিজ্ঞতা আছে। এবং আমি অবাক হয়েছিলাম যে এটি কতটা ভাল কাজ করেছে।

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

তাই যদিও জুরি এই বিষয়ে আউট, আমার ধারণা এই অনুশীলন সঠিক প্রসঙ্গে অনেক সম্ভাবনা আছে.

FAST ক্রমবর্ধমান সঙ্গে পরীক্ষা করা যেতে পারে

এটি FAST উপকরণগুলিতে উল্লেখ করা হয়নি, তবে একটি জিনিস যা আমার কাছে FAST সম্পর্কে আকর্ষণীয় বলে মনে হয়েছে তা হল আপনি এটিকে ক্রমবর্ধমানভাবে পরীক্ষা করতে পারেন।

আপনি একটি পরীক্ষা হিসাবে একটি দলে FAST Agile প্রয়োগ করতে পারেন এবং তারপরে একটি ব্লব পদ্ধতি ব্যবহার করতে পারেন যেখানে আপনি সময়ের সাথে সাথে অতিরিক্ত দলগুলিকে গ্রাস করতে পারেন। যদি এটি ভাল হয় তবে অতিরিক্ত দলগুলিকে গ্রাস করা চালিয়ে যান। যদি তা না হয়, পরীক্ষাটি বাতিল করুন।

FAST এর ফলে কম পুনর্গঠন হওয়া উচিত

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

এই সমস্ত জিনিস আপনার প্রতিষ্ঠানের কাঠামোর উপর প্রভাব ফেলে। আপনার দলগুলির একটি সেট রয়েছে, যার প্রত্যেকটির নিজস্ব মালিকানার ক্ষেত্র রয়েছে। এই পরিবর্তনটি ঘটলে, আপনি যথাসাধ্য সেরা কাজ করার জন্য সময়ের সাথে সাথে আপনার প্রতিষ্ঠানকে রিফ্যাক্টর করুন। এই রিফ্যাক্টরিংগুলি হল "পুনর্বিন্যাস" এবং ক্রমবর্ধমান সংস্থাগুলিতে, এগুলি ঘন ঘন ঘটতে পারে!

FAST এর সাথে Reorgs অনেক কম ঘন ঘন হওয়া উচিত। পুনর্গঠনের ইউনিট এত বড় যে আপনাকে এটি প্রায়শই করতে হবে না।

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

দ্রুত অগ্রাধিকার পরিবর্তনে সাড়া দেওয়া সহজ করে তোলে

যখন প্রথাগতভাবে কাঠামোবদ্ধ দলগুলিতে অগ্রাধিকারগুলি পরিবর্তিত হয়, তখন আপনার কাছে কাজ করার জন্য দলগুলি সেট আপ থাকে। যদি সেই দলের গঠনটি নতুন অগ্রাধিকার সমর্থন না করে, তাহলে আপনাকে আপনার প্রতিষ্ঠানের পুনর্বিন্যাস করতে হবে।

FAST-এর জন্য, অগ্রাধিকারের পরিবর্তনগুলি আরও তরল এবং অবিচ্ছিন্ন। যতক্ষণ দায়িত্বগুলি সমষ্টির মধ্যে থাকে, দলগুলি কেবল কাজের চারপাশে নিজেদের সংগঠিত করে এবং এটি অন্য দিনের মতো।

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

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

অভ্যন্তরীণ প্রেরণা এবং ধরে রাখার জন্য FAST আরও ভাল হতে পারে

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

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

ড্যানিয়েল পিঙ্ক বিখ্যাতভাবে অন্তর্নিহিত অনুপ্রেরণার তিনটি দিক তুলে ধরেছেন:

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

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

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

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

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

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

অনেক পরিবেশ FAST এর সাথে বেমানান

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

কোন পরিবেশগুলি দ্রুত চেষ্টা করার জন্য সবচেয়ে উপযোগী? এবং কোথায় আপনার দ্রুত এড়ানো উচিত?

আপনার কোম্পানির এই তালিকা থেকে যত বেশি গুণাগুণ রয়েছে, FAST-এর জন্য তত বেশি উপযুক্ত:

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

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

আপনাকে স্ব-ব্যবস্থাপনা পরিচালনা করতে হতে পারে

স্ব-সংগঠিত ব্যবস্থা কার্যকরভাবে কাজ করতে পারে। কিন্তু তারা মুক্ত নয়। তারা আরও একটি সম্প্রদায় পরিচালনার মত।

সঠিক আচরণে উদ্বুদ্ধ করার জন্য আপনাকে সীমাবদ্ধতা এবং উপায় তৈরি করতে হবে। এবং জিনিসগুলি অফ-ট্র্যাক না হয় তা নিশ্চিত করতে আপনাকে সাবধানে দেখতে হবে এবং পরিচালনা করতে হবে৷

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

FAST-এর মাধ্যমে, আপনি লোকেদের একটি সম্প্রদায় পরিচালনার জন্য সাইন আপ করছেন।

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

অন্য চরম হ'ল গ্রুপের সমস্যাগুলি বের করতে না দেওয়া এবং ম্যানেজমেন্টকে এটি সম্পূর্ণভাবে পরিচালনা করা। এটি ক্ষতিকারকও হতে পারে ।

তাই FAST এর জন্য ভালো সুবিধা, সতর্ক পর্যবেক্ষণ এবং মাঝে মাঝে হস্তক্ষেপ প্রয়োজন।

FAST এর জন্য অনেক কাজ করতে হয়

আপনি FAST নিয়ে পরীক্ষা না করার সবচেয়ে বড় কারণ হল যে FAST এর সাথে অনেক লুকানো কাজ রয়েছে। এটি আপনার প্রতিষ্ঠানে অনেক পরিবর্তন প্রয়োজন, অপারেটিং একটি অপরিচিত উপায়.

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

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

কর্মক্ষমতা ব্যবস্থাপনা কিভাবে কাজ করে?

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

FAST দলগুলিতে, কার্যক্ষমতা পর্যালোচনা করার জন্য সত্যিই একটি সুস্পষ্ট উপায় নেই। ব্যক্তিটির ম্যানেজার কি এমনকি জানেন যে তারা কী করছে বা তারা কীভাবে কাজ করছে? আপনি এমনকি "টিম" মূল্যায়ন করতে পারবেন না, কারণ তারা ক্ষণস্থায়ী।

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

ফাস্টে ইঞ্জিনিয়ারিং ম্যানেজারদের ভূমিকা কী?

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

FAST-এ, ইঞ্জিনিয়ারিং ম্যানেজারের ভূমিকা কম স্পষ্ট। আপনার দীর্ঘজীবী দল নেই, তাই ইঞ্জিনিয়ারিং ম্যানেজারের পক্ষে তাদের সরাসরি প্রতিবেদনের পাশাপাশি কাজ করা কঠিন।

আপনি ইঞ্জিনিয়ারিং ম্যানেজারদের স্ব-একত্রিত দলগুলির নেতৃত্ব দিতে পারেন। অথবা আপনি তাদের খাঁটি মানুষ ম্যানেজার হতে পারে. অথবা আপনি তাদের খেলোয়াড়-কোচ হতে পারেন।

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

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

এটি কার্যকর হয় কিনা তা দেখতে আমি সত্যিই কৌতূহলী, এবং FAST নিয়ে পরীক্ষা করে এমন সংস্থাগুলির কাছ থেকে শুনতে চাই৷ ম্যানেজমেন্ট দিয়ে আপনি কি করবেন?

মালিকানার ক্ষেত্র ছাড়া আপনি কীভাবে কোডের গুণমান নিশ্চিত করবেন?

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

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

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

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

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

একাধিক সমষ্টি এবং সমষ্টিগত সীমানা অতিক্রম করার সাথে কী ঘটে?

যে কাজটি যৌথ সীমানা অতিক্রম করে তা মূলত FAST-এ অনির্ধারিত। এবং বৃহৎ উদ্যোগের জন্য উচ্চ মাত্রার সমন্বয়ের প্রয়োজন FAST-এর দ্বারা কম-নির্দিষ্ট। তাই আপনাকে এই পরিস্থিতিতে সমাধান উদ্ভাবন করতে হবে।

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

কিভাবে FAST অন-কলের সাথে মোকাবিলা করে?

FAST গাইডে অন-কল বিশেষভাবে উল্লেখ করা হয়নি। তাই এটি মোকাবেলা করার জন্য আপনাকে একটি স্কিম উদ্ভাবন করতে হবে।

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

FAST-এর সাহায্যে, আপনি একটি অন-কল ঘূর্ণন তৈরি করতে পারেন যার স্তর রয়েছে (এই রানবুকটি অনুসরণ করুন এবং এটি ঠিক না হলে এগিয়ে যান)। এবং আপনাকে স্পষ্টভাবে একটি মানচিত্র রাখতে হবে কে কি সমর্থন করতে সক্ষম। এটি আপনার দলকে ম্যাপ করবে না।

এটি করা খুব কঠিন নয়, তবে এটি প্রচলিত অন-কল অনুশীলনের তুলনায় কম সাধারণ, এবং পরিচালনার মনোযোগ প্রয়োজন।

বাগ সংশোধন এবং সমর্থন বৃদ্ধি সম্পর্কে কি?

FAST-এর একটি ঐচ্ছিক ভূমিকা রয়েছে যাকে "ফিচার স্টুয়ার্ড" বলা হয়। তারা একটি নির্দিষ্ট বৈশিষ্ট্যের জন্য একজন বিশেষজ্ঞ এবং স্টেকহোল্ডারদের জন্য সেই বৈশিষ্ট্যটির চারপাশে যোগাযোগের বিন্দু। তাদের সেই বৈশিষ্ট্যটিতে অবিচ্ছিন্নভাবে কাজ করার প্রয়োজন নেই, তবে এটির অবিচ্ছিন্ন বোঝার প্রয়োজন।

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

আপনাকে নিশ্চিত করতে হবে যে আপনার জ্ঞানের ফাঁক পূরণ করার জন্য একটি ব্যবস্থা আছে যখন দক্ষতা এক বা দুইজনের কাছে বিচ্ছিন্ন হয়।

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

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

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

নির্ভরযোগ্যতা ঘটনা এবং ঘটনার পূর্ববর্তী ঘটনা সম্পর্কে কি?

FAST কীভাবে ঘটনাগুলি পরিচালনা করা হয় তা সংজ্ঞায়িত করে না। আপনার অন-কল প্যাটার্নগুলি অনেকাংশে নির্ধারণ করবে যে ঘটনাগুলি কীভাবে পরিচালনা করা হয় এবং সম্ভবত যারা এটিকে ঠিক করার জন্য যে পরিস্থিতি টানা হচ্ছে তা কীভাবে ঠিক করতে হবে তা জানে।

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

ঘটনার পরপরই যৌথ সভায়, আমরা যা শিখেছি তা শেয়ার করব, এবং পরবর্তী চক্রের জন্য একটি স্বয়ংক্রিয় অগ্রাধিকারও তৈরি করব যা পূর্ববর্তী সময়ে চিহ্নিত করা হয়েছে।

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

কিভাবে ডিজাইনার দ্রুত কাজ করে?

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

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

পণ্য পরিচালকরা কিভাবে FAST এ কাজ করে?

FAST-এ পণ্যের ভূমিকা মূলত অগ্রাধিকার এবং যোগাযোগের জন্য। এর বাইরের কাজ সম্পর্কে FAST ম্যানুয়ালটিতে এমন অনেক কিছু রয়েছে যা সত্যিই বর্ণনা করা হয়নি।

FAST ম্যানুয়ালটিতে অনুমানটি মনে হচ্ছে যে পণ্য পরিচালকরা অনুপ্রাণিত করে এবং যোগাযোগ করে এবং তারপরে প্রকৌশলীরা বৈশিষ্ট্যগুলির উপর কাজ করে।

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

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

সুতরাং আপনি দেখতে পাচ্ছেন, FAST-এ অনেক ফাঁক রয়েছে। আপনাকে সমস্যাটি করতে হবে-বাকিটি সমাধান করতে হবে।

FAST উপকরণগুলি পরিভাষায় পূর্ণ

আপনি FAST ওয়েবসাইট এবং ম্যানুয়াল বিভ্রান্তিকর খুঁজে পেতে পারেন। FAST Agile এর সোনা পেতে আপনাকে প্রচুর পরিভাষা এবং বিরক্তিকর পরিভাষা নেভিগেট করতে হবে। উদাহরণ হিসেবে, এখানে FAST Agile-এর ভয়ঙ্কর সংজ্ঞা দেওয়া হল যা FAST গাইডের সংস্করণ 2.12- এ অনুশীলনটিকে সংজ্ঞায়িত করার চেষ্টা করে:

"ফ্লুইড স্কেলিং প্রযুক্তি কি? ফ্লুইড স্কেলিং টেকনোলজি ওপেন স্পেস টেকনোলজি এবং ওপেন অ্যালোকেশনকে একত্রিত করে একটি হালকা ওজনের, বোঝার মতো সহজ, এবং কাজের আশেপাশে লোকেদের সংগঠিত করার জন্য সহজ থেকে মাস্টার পদ্ধতি তৈরি করে - যা স্কেল। FAST হল ফ্লুইড স্কেলিং প্রযুক্তির সংক্ষিপ্ত রূপ। চতুরতার জন্য ফ্লুইড স্কেলিং প্রযুক্তি দ্রুত চটপটে।"

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

উপসংহার

তাই যেখানে যে আমাদের ছেড়ে? FAST চটপটে পরীক্ষা করার যোগ্য?

আমি বিশ্বাস করি যে উত্তরটি হ্যাঁ, তবে সতর্কতার সাথে এবং সঠিক প্রসঙ্গে। আপনি পৃথক দলের মধ্যে এটির সাথে খেলতে পারেন। এবং যদি আপনার নেতৃত্বের সমর্থন থাকে তবে বড় প্রতিষ্ঠানের মধ্যে ধীরে ধীরে এটি নিয়ে পরীক্ষা করুন।

আপনি যদি এটি নিয়ে পরীক্ষা করেন তবে দয়া করে আমার সাথে ভাগ করুন। এবং আপনি যদি আপনার প্রতিষ্ঠানে এটি রোল আউট করতে সাহায্য করতে চান, আমার সাথে যোগাযোগ করুন। আমি হয় আপনাকে সরাসরি সাহায্য করব, অথবা সাহায্য করতে পারে এমন অন্যদের সাথে আপনাকে সংযুক্ত করব।

ধন্যবাদ

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

জিম শোর আমাকে দ্রুত চটপটে পরিচয় করিয়ে দিল। তিনি এটির সাথে তার অভিজ্ঞতার উপর কিছু চমৎকার কথা বলেছেন। এবং আমরা কয়েকবার দেখা করেছি এবং FAST এর প্রভাব এবং বাস্তবায়ন নিয়ে আলোচনা করেছি। জিম দ্য আর্ট অফ এজিল ডেভেলপমেন্টের লেখক।

Pixabay থেকে Kanenori দ্বারা ছবি

পাদটীকা

1. আমি বিশ্বাস করি 150 জন সম্ভবত একটি সমষ্টির জন্য অদম্য। আমি সন্দেহ করি ষাট জন একটি ভাল সর্বোচ্চ আকার.