7 wastes of software development and How They Kill Productivity

ধরুন, sprint planning শেষ। বোর্ড ভর্তি টাস্ক, সবাই বেশ আগ্রহ নিয়ে কাজ শুরু করলেন। দুই সপ্তাহ পরে দেখা গেলো তিনটা বড় feature হাফ ডান (half done) অবস্থায় পড়ে আছে, দুইটা “high priority” ফিচার শেষ হলেও ইউজাররা ঠিক ব্যবহারই করছে না, আর টিমের অর্ধেক সময় গেছে মিটিং আর follow-up-এর পেছনে। ডেভেলপাররা বলছে “কাজ অনেক”, ম্যানেজমেন্ট বলছে “ডেলিভারি কম”, কিন্তু কেউ ঠিক বুঝতে পারছে না আসলে সমস্যা কোথায়। এটা শুধু আপনার টিমের গল্প না, আমাদের ইন্ডাস্ট্রিতে এটা প্রায় নিত্যদিনের ঘটনা।

আমরা নতুন Technology, নতুন Framework, নতুন Tool খুব দ্রুত adopt করি, কিন্তু খুব কম সময় নেই এটা ভাবার জন্য যে আমাদের প্রক্রিয়াগুলোর ভেতর কত waste লুকিয়ে আছে। অর্ধসমাপ্ত কাজ, অপ্রয়োজনীয় feature, handoff-এর ঝামেলা, বারবার task switching, অকারণে waiting, আগের শেখা আবার নতুন করে শেখার প্রয়োজন হওয়া, defect-এর জন্য দ্বিগুণ ত্রিগুণ effort সব মিলিয়ে আমরা আসলে নিজেরাই নিজেদের গতি কমিয়ে দেই।

Lean software development ঠিক এই জায়গাটাতেই প্রশ্ন তোলে “আপনি আসলে কতটা value তৈরি করছেন, আর কতটা শুধু ব্যস্ততা দেখাচ্ছেন?”

এই আর্টিকেলে আমরা Lean-এর দৃষ্টিতে Software Development-এর বিভিন্ন ধরনের waste নিয়ে আলোচনা করেছি। Partially done work থেকে শুরু করে Management activities আর unused talent পর্যন্ত। উদ্দেশ্য খুব সোজা, আপনাকে আর আপনার টিমকে এমন একটা lens দেওয়া, যেটা দিয়ে নিজের process-এর দিকে তাকিয়ে বলতে পারবেন “কোথায় Muda আছে, আর কীভাবে সেটা বাদ দিলে আমরা সত্যিকারের smart ও efficient হতে পারি?”

Lean Software Development-এর ভিত্তি: অপচয় চিহ্নিত করা ও জটিলতার মাঝে পথ খোঁজা

অপ্রয়োজনীয় কাজ বা waste দূর করার প্রথম ধাপ হলো আগে এটাকে পরিষ্কারভাবে চিহ্নিত করা। এজন্য সব ধরনের Business process-কে ভিজ্যুয়ালি ভেঙে দেখতে হয়, আর সেখান থেকে খুঁজে বের করতে হয় কোন কোন কাজ আসলে গ্রাহকের জন্য কোনো বাস্তব value যোগ করছে না।

Lean methodology এই দৃষ্টিকোণ থেকে সাত ধরনের আলাদা waste নির্ধারণ করেছে, যেগুলো বাদ দিতে পারলে পুরো প্রক্রিয়াটাই অনেক বেশি অপটিমাইজ করা সম্ভব।

দুইজন Industrial Engineer, Shingo এবং Ohno, মিলে তৈরি করেছিলেন Toyota Production System (TPS), যেটাকে পরে Lean production নামে ডাকা শুরু হয়। যদিও এটি মূলত Automotive ইন্ডাস্ট্রির জন্য তৈরি হয়েছিল, কিন্তু এই সিস্টেমের মূল নীতিগুলো যখন Software industry-তে প্রয়োগ করা হয়, তখনও তা সমানভাবে সফল প্রমাণিত হয়।

Lean মূলত এসেছে এক ধরনের অত্যন্ত জটিল ও দ্রুত পরিবর্তনশীল পরিবেশের প্রতিক্রিয়া হিসেবে। আজকের আধুনিক Business Climate-কেও আপনি এমনই এক জটিল পরিবেশ বলতে পারেন বিশেষ করে এখনকার startup-নির্ভর দুনিয়ায়। নতুন কোম্পানি হোক বা বহু বছরের প্রতিষ্ঠিত প্রতিষ্ঠান, দু’ক্ষেত্রেই ছোট ছোট ধাপে Lean principles খুব কার্যকরভাবে প্রয়োগ করা যায়।

এখানে মূল ফোকাস থাকে বারবার পরীক্ষা-নিরীক্ষা করা, hypothesis টেস্ট করা, আর ক্রমাগত পরিবর্তনশীল পরিস্থিতি ও requirement-এর সাথে নিজেকে মানিয়ে নেওয়া।

আমরা যেহেতু Software Development-এর জগতে কাজ করি, এখানে Agile অনেক জনপ্রিয় একটি approach। Scrum, Kanban, আর Lean এগুলো Agile-এর ছাতার নিচে থাকা কিছু পরিচিত framework, যেগুলো একই লক্ষ্যকে সামনে রেখে ভিন্ন ভিন্ন পদ্ধতিতে কাজ করে।

Eliminate Waste – অপ্রয়োজনীয়তা দূর করা

Lean software development-এর সাতটি মূল principle ভালোভাবে লক্ষ্য করলে দেখা যায়, এদের মূল উদ্দেশ্য হল টিমকে agile আর flexible রাখা। একই সঙ্গে এমন একটি মানসিকতা তৈরি করা, যেখানে আপনি সব সময় সঠিক সিদ্ধান্ত নিতে প্রস্তুত থাকবেন, আর নিজেকে খুব বেশি rigid, দীর্ঘমেয়াদি প্ল্যানের মধ্যে আটকে রাখবেন না।

ভাবুন তো, জানুয়ারি ২০২০-এ করা এক বছরের rigid স্ট্র্যাটেজির সাথে যদি আপনাকে পুরো বছর বেঁধে রাখা হত প্যান্ডেমিকের মতো অপ্রত্যাশিত ঘটনায় সেটি কতটা অবাস্তব হয়ে যেত! Agile approach-এর সৌন্দর্যই হলো, বড় ধরনের চ্যালেঞ্জ হোক বা পরিবেশের ছোটখাট পরিবর্তন দুই ক্ষেত্রেই দ্রুত মানিয়ে নেওয়ার সুযোগ তৈরি করে দেয়, যাতে কোনো দেরি না হয়।

২০০৩ সালে Mary এবং Tom Poppendieck তাঁদের “Lean Software Development: An Agile Toolkit” বইতে traditional Lean manufacturing-এর নীতিগুলোকে Software Engineering-এর প্রেক্ষাপটে রি-ডিফাইন করেন। সেখানে Lean software development-এর সাতটি মূল principle হিসেবে যেগুলো উল্লেখ করা হয়েছে, সেগুলো হলোঃ

• Eliminate waste
• Amplify learning
• Decide as late as possible
• Deliver as fast as possible
• Empower the team
• Build integrity in
• Optimize the whole

এখানে আমরা প্রথম principle “Eliminate waste” নিয়ে বিস্তারিত দেখব। কোনো waste দূর করতে হলে, তার আগে সেটাকে চিনতে শেখা জরুরি। Lean manufacturing-এ শুরুতে যে সাত ধরনের waste-এর কথা বলা হয়েছিল, সেগুলো হলোঃ অতিরিক্ত inventory, waiting, defects, overproduction, motion, transportation আর overprocessing।

এই ধারণা যখন software industry-তে প্রয়োগ করা হয়, তখন Lean অনুযায়ী সফটওয়্যারে waste-এর সাতটি প্রধান ধরনকে এভাবে সংজ্ঞায়িত করা হয়ঃ

• Partially done work: অর্ধসমাপ্ত কাজ, যা কখনোই গ্রাহকের কাছে real value হিসেবে পৌঁছায় না।
• Extra features: এমন ফিচার, যেগুলো গ্রাহক ব্যবহারই করছে না বা দরকারই নেই।
• Handoffs: এক জন থেকে আরেক জনের কাছে কাজ বেশি বেশি “ছাড়া-ধরা” হওয়া। যেমন্টা গার্মেন্টস এ হয়ে থাকে।
• Task switching: বারবার কনটেক্সট বদলে কাজ করার ফলে productivity কমে যাওয়া।
• Waiting: অন্য কারও কাজ বা অনুমতির জন্য অকারণে বসে থাকা।
• Relearning: আগের শেখা জিনিস আবার নতুন করে শিখতে যাওয়া, কারণ জ্ঞান properly capture বা শেয়ার করা হয়নি। অর্থাৎ একই জিনিষ বার বার টিম মেম্বারদের সাথে শেয়ার করা কারন কোন প্রপার ডকুমেন্টস নাই।
• Defects: বাগ বা ত্রুটি, যা ঠিক করতে সময় ও রিসোর্স নষ্ট হয়।

অনেক লেখক আবার অতিরিক্ত অষ্টম ধরনের waste হিসেবে management-এর অকার্যকর কাজকর্ম বা দুর্বল leadership-কে এই তালিকার অংশ হিসেবে ধরেন।

এই সব ধরনের waste মিলেই তৈরি হয় “Muda” যা একটি জাপানিজ শব্দ, যার অর্থ হলো এমন কোনো অপচয় বা activity, যা business-এর জন্য কোনো value তৈরি না করে শুধু রিসোর্স খরচ করে। Muda কমিয়ে দিয়ে manager-রা শুধু খরচ কমিয়েই profitability বাড়াতে পারেন। Lean manufacturing-এ এই বিষয়টি খুব গুরুত্বপূর্ণ, যেখানে কোম্পানিগুলো operating cost কমায়, inventory management উন্নত করে।

Lean-এর মূল কাঠামোতে Muda-র পাশাপাশি আরও দুটি ধারণা থাকে Mura (unevenness বা কাজের ওঠানামা) এবং Muri (overburden বা অতিরিক্ত চাপ)। এই তিনটি ধারণাকে কেন্দ্র করেই Lean চিন্তাধারা অপচয় কমিয়ে, প্রক্রিয়াকে আরও দক্ষ ও কার্যকর করার পথ দেখায়।

Partially Done Work – অর্ধসমাপ্ত কাজ

Software Development-এর ভাষায় partially done work মানে হচ্ছে সেই সব unfinished features, যেগুলোতে আমাদের টিম অনেক শ্রম দিয়েছে, কিন্তু সেগুলো কখনই ব্যবহারকারীর হাতে পৌঁছায়নি। এই ধরনের কাজ আসলে আমাদের বিনিয়োগ করা সময় ও শক্তিকে এক ধরনের অদৃশ্য অপচয়ে পরিণত করে আর এটাই এমন জিনিস, যেটা আমরা যেকোনো মূল্যে এড়াতে চাই।

অনেকেই ভাবে, “ফিচার তো মাত্র ১০% কমপ্লিট ছিল, মাঝপথে বন্ধ করলে ১০% effort-ই নষ্ট হলো।” বাস্তবে বিষয়টা এরকম না। ডেভেলপমেন্ট শুরু হওয়ার আগেই ঐ ফিচারের পিছনে অনেক research, সিদ্ধান্ত নেওয়া, data সংগ্রহ, design, planning ইত্যাদি হয়ে গেছে। তাই কাজ বন্ধ হলে আসলে শুধু ১০% ডেভেলপমেন্ট নয়, সেই ফিচারের পেছনে করা পুরো প্রস্তুতির বড় একটা অংশই অপচয় হয়ে যায়।

অর্থাৎ, feature completion-এর শতাংশ আর মোট invest করা energy কখনোই এক জিনিস না। এখানে একটা স্পষ্ট অসামঞ্জস্য থাকে। একদিকে নষ্ট হওয়া কাজের ঘন্টা, আর অন্যদিকে টিমের সদস্যদের motivation আর enthusiasm কমে যায়। সবাই চায় নিজের কাজের tangible ফল যত তাড়াতাড়ি সম্ভব দেখতে। কিন্তু আমরা যদি ধারাবাহিকভাবে এমন কাজ করি, যা শেষ হয় না বা শেষ হলেও user-এর কাছে পৌঁছায় না, তাহলে আমাদের মনে প্রশ্ন জাগে “আমরা এত পরিশ্রম করছি কার জন্য?”

ফলাফল খুব পরিষ্কারঃ
যদি আমরা ব্যবহারকারীর সামনে সময়মতো কোনো real value তুলে ধরতে না পারি, তাহলে টিমের মনোবল ধীরে ধীরে কমতে শুরু করে, আর দীর্ঘমেয়াদে productivity ও ownership দুটোই ক্ষতিগ্রস্ত হয়।

Extra Features: অতিরিক্ত বা অপ্রয়োজনীয় ফিচার

যে সব ফিচার আমরা সম্পূর্ণ ডেভেলপ করি, কিন্তু ব্যবহারকারীরা প্রায় ব্যবহারই করেন না সেগুলোই মূলত extra features। এতে কী হয়? আমরা এমন কিছুর পিছনে সময় ও রিসোর্স খরচ করি, যা হয়তো মাত্র ৪% ব্যবহারকারীর কাজে লাগে। একই সময়ে আমরা চাইলে এমন একটি ফিচার বানাতে পারতাম, যেটা ৪০% ব্যবহারকারীর জন্য সরাসরি উপকার বয়ে আনত।

অর্থাৎ, এখানে শুধু কোড লেখার সময় নষ্ট হয় না, বরং আপনার পুরো টিমের ফোকাস, energy এবং সুযোগ সবকিছুরই ভুল ব্যবহার হয়।

Handoffs – কাজ এক হাত থেকে আরেক হাতে যাওয়া

Software development process-এ handoff সব সময়ই ঝুঁকিপূর্ণ একটা ধাপ। যখন কোনো কাজ এক ব্যক্তি বা টিম থেকে আরেক জনের কাছে যায়, তখন কয়েকটা বড় সমস্যা হবার সুযোগ থাকে। যেমনঃ-

• গুরুত্বপূর্ণ তথ্য হারিয়ে যেতে পারে।
• কাজ সঠিকভাবে delegate নাও হতে পারে।
• আগের বা নতুন assignee কেউই পূর্ণ দায়িত্ব নিতে চাইতে নাও পারে, “এটা তো তাদের/তাদের টিমের কাজ ছিল” টাইপ মানসিকতা তৈরি হতে পারে।

এই কারণেই flow-এর মধ্যে handoff যতটা সম্ভব কমানো, আর যেগুলো থাকবে সেগুলোর গুণগত মান বাড়ানো অত্যন্ত জরুরি।

এ সমস্যা কমানোর একটি প্রস্তাবিত উপায় হচ্ছে অস্থায়ী “feature team” তৈরি করা। মানে, আলাদা আলাদা টিম আর রোল (যেমন dev, QA, UX, ops ইত্যাদি) থেকে লোক নিয়ে একটা ছোট cross-functional টিম বানানো, যারা একসাথে সেই ফিচার ডেলিভারি পর্যন্ত কাজ করবে, কাজটা বারবার এক হাত থেকে আরেক হাতে ঘোরানোর বদলে।

তবে এমন টিম বানানোর ক্ষেত্রে সাবধানতা অবলম্বন করা খুবই গুরুত্বপূর্ণ, কারণ এগুলো মূলত বিদ্যমান organizational structure-এর পাশাপাশি এক ধরনের parallel structure তৈরি করে।

ফলে,

• একজন ব্যক্তির ওপর একাধিক scrum master / manager / product owner এর প্রভাব পড়তে পারে, যা task-এর priority ঠিক করতে কনফিউশন তৈরি করে।
• অন্যদিকে, ম্যানেজারদের জন্যও সমস্যা হতে পারে, কারণ তারা পরিষ্কারভাবে নাও জানতে পারেন, ঠিক এই মুহূর্তে কোন ব্যক্তি আসলে কোন কাজগুলো নিয়ে ব্যস্ত।

সঠিকভাবে পরিকল্পনা না করলে, handoff কমানোর চেষ্টা করতে গিয়েও আবার নতুন ধরনের বিশৃঙ্খলা তৈরি হয়ে যেতে পারে।

Task Switching – এক কাজ ছেড়ে বারবার অন্য কাজে ঝাঁপ দেওয়া

Task switching সমস্যাটা ডেভেলপার থেকে শুরু করে সব ধরনের creative পেশাজীবীই খুব ভালো করে চেনেন। আমাদের মস্তিষ্ক কোনো কাজ নিয়ে সত্যিকারের ফোকাসড হতে একটু সময় নেয়। হঠাৎ সুইচ অন/অফের মতো সঙ্গে সঙ্গে deep focus তৈরি হয় না। দিনের পুরোটা সময় জুড়ে সমান মাত্রায় deep focus ধরে রাখতে না পারা একদমই স্বাভাবিক।

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

অনেক ম্যানেজার ভুলভাবে ধরে নেন, এক জনের কাঁধে বেশি বেশি কাজ আর অতিরিক্ত দায়িত্ব চাপিয়ে দিলে নাকি productivity বাড়বে। বাস্তবে হয় ঠিক উল্টো। এ ধরনের approach-এর শেষ ফলাফল হয় প্রায়ই এমন একজন টিম মেম্বার, যিনি ধীরে ধীরে burnout-এর দিকে চলে যান। যেখানে তিনি আর ঠিকমতো code লিখতে পারেন না, না অন্য কোনো কাজ করতে আগের মতো মানসিক শক্তি আর মনোযোগ খুঁজে পান।

Waiting – অকারণ অপেক্ষা আর ধীরগতি

যে কোনো অপ্রয়োজনীয় দেরি টিমের momentum নষ্ট করে দেয়, আর সেই সঙ্গে সিদ্ধান্ত নেয়ার বা দ্রুত ঘুরে দাঁড়ানোর maneuvering space-ও কমিয়ে ফেলে। বিশেষ করে সেই সব টিমের জন্য “অপেক্ষা” খুবই ক্ষতিকর, যাদের কাজ সরাসরি অন্য টিমের রেজাল্ট বা আউটপুটের ওপর নির্ভর করে।

অবশ্যই সব waiting খারাপ নয়। কিছু কিছু ক্ষেত্রে অপেক্ষা পুরোপুরি যৌক্তিক। যেমন, কোনো সিদ্ধান্ত নেয়ার আগে পরিষ্কার হয়ে নেওয়া যাতে পরে একই কাজ দু’বার করতে না হয়, বা ভুল পথে অনেক দূর গিয়ে আবার সব ঠিক করতে না হয়। এই ধরনের অপেক্ষা আসলে waste কমাতেই সাহায্য করে।

কিন্তু বেশিরভাগ সময়ই “অপেক্ষা করি দেখি”, “পরে দেখা যাবে”, “এখন একটু hold করে রাখি” এই মানসিকতা আসলে এক ধরনের conformism, যেটা আমাদের initiative আর ownership কমিয়ে দেয়। এ ধরনের অযথা delay যতটা সম্ভব এড়িয়ে চলা দরকার।

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

Relearning – আগেই শিখেছি, আবার নতুন করে শেখা

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

এর মধ্যে আপনি অনেকগুলো নতুন feature release করেছেন, নতুন কোড লিখেছেন, এক কাজ থেকে আরেক কাজে, এক context থেকে আরেক context-এ বারবার সুইচ করেছেন। ফলে, ওই সাব-সিস্টেমটা আসলে ভেতরে কীভাবে কাজ করে, তার অনেক কিছুই মনে নেই! এখন পুরো টিমকে একসাথে বসে প্রায় পুরো দিন ধরে পুরোনো কোড, design আর logic রিকল করতে হচ্ছে মানে, আবার নতুন করে শিখতে হচ্ছে, যা একবার আগেই শেখা হয়েছিল।

লজিক্যালি দেখলে, যখন আপনি প্রথমবার সেই সমস্যার ভিতর “knee-deep” ডুবে ছিলেন, তখন যদি বাড়তি এক-দুই ঘণ্টা সময় নিয়ে ভালোভাবে ডকুমেন্টেশন করতেন, ক্লিন স্ট্রাকচার দিতেন, বা ভবিষ্যতের জন্য নোট রেখে দিতেন তাহলে পরের বার ফিরে এসে একটা পুরো দিন বা তারও বেশি সময় শুধু মনে করতে নষ্ট হত না।

অর্থাৎ, তখন সামান্য বাড়তি সময় না দিলে পরে গিয়ে তা অনেক বড় অপচয়ে পরিণত হয় এটাই মূলত relearning waste।

Defects – বাগ, গ্লিচ আর তাড়াহুড়োর আসল মূল্য

প্রায় সব টিমেই এখন যত দ্রুত সম্ভব নতুন product বা service বাজারে আনার চাপ থাকে। নতুন feature শেষ করা, release শিডিউল মেনে চলা, “ফাস্ট মুভ” করার এই তাড়াহুড়োর ভেতরেই আস্তে আস্তে জন্ম নেয় defects। যেগুলো আমরা কখনও bug, কখনও slip, কখনও বা glitch বলে ডাকি। কিন্তু নাম যাই হোক, এগুলোর প্রত্যেকটারই একটা না একটা খরচ আছে, আর সেগুলো এক সময় গিয়ে আপনাকে ধরবেই।

Defect নিয়ে সবচেয়ে বড় অসামঞ্জস্যটা হচ্ছে এটি:
যত বেশি দেরি করে ঠিক করবেন, ঠিক করতে তত বেশি সময় ও পরিশ্রম লাগবে।

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

একটা সমস্যা, যেটা এক সময় মাত্র এক দিনে সমাধান করা যেত, সেটাই কয়েক সপ্তাহ পরে এসে ঠিক করতে তিন দিন বা তারও বেশি সময় লেগে যায়। শুধু এই জন্য যে, মানসিকভাবে আবার পুরো context-টা রিকনস্ট্রাক্ট করতে হচ্ছে।

অর্থাৎ, তাড়াহুড়ো করে delivery দিয়ে পরে defect সামলানোর চেষ্টা করা মানে, সামনে এগোনোর গতি বাড়ানোর বদলে পেছনে গিয়ে বেশি দামে পুরোনো ভুলের বিল পরিশোধ করা।

Management Activities – ম্যানেজমেন্টের কাজকর্ম কখন অপচয়ে পরিণত হয়?

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

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

যে কোনো মিটিং বা অনুরূপ কার্যক্রমের ক্ষেত্রে কিছু বেসিক বিষয় পরিষ্কার থাকা দরকার। যেমনঃ

• একটি স্পষ্ট লক্ষ্য (goal)
• প্রাসঙ্গিক ও সত্যিকারের আগ্রহী অংশগ্রহণকারী
• আগে থেকেই agenda ঠিক করা।
• শেষে কী হবে – তার well-defined next step

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

Unused Talent – অব্যবহৃত দক্ষতা

“Management activities” প্রসঙ্গে ৯০-এর দশকে আরেকটি দিক যোগ করা হয় unused talent বা কর্মীদের অব্যবহৃত দক্ষতা। অনেক কোম্পানি আছে, যারা তাদের কর্মীদের ভেতরে থাকা সব স্কিল আর জ্ঞানকে সঠিকভাবে ব্যবহারই করে না। এর ফলাফল হতে পারে-

• Efficiency বা উৎপাদনক্ষমতা কমে যাওয়া।
• অপ্রয়োজনীয়ভাবে নতুন লোক নিয়োগ করা।
• বিদ্যমান কর্মীদের motivation হারিয়ে ফেলা।

অনেক ক্ষেত্রে এই অপচয়ের মূল কারণ হয়ে দাঁড়ায় ঠিক এই ম্যানেজমেন্ট কার্যক্রমই যেখানে ভুল অগ্রাধিকার, অকারণ প্রক্রিয়া আর rigid কাঠামোর কারণে মানুষের প্রকৃত দক্ষতা কাজেই লাগানোর সুযোগ তৈরি হয় না।

Lean mindset: কম কাজ না, অপচয় কমিয়ে বেশি value

দিনের শেষে আপনার টিমকে কেউ জিজ্ঞেস করবে না, “কত ঘন্টা ব্যস্ত ছিলেন?”, বরং জিজ্ঞেস করবে, “কী value deliver করেছেন?” Lean software development ঠিক এই বাস্তব সত্যিটাই আমাদের মনে করিয়ে দেয়। Partially done কাজ, extra feature, handoff-এর গ্যাঁড়াকল, context switch, waiting, relearning, defect আর অব্যবহৃত talent এগুলো একেকটা ছোট সমস্যা না, বরং সব মিলেই একটা বড় সিস্টেমিক অপচয় তৈরি করে, যেটা আপনার team velocity, প্রোডাক্টের quality আর মানুষের motivation সবকিছুর উপর প্রভাব ফেলে।

Lean আমাদের শিখায়, process improvement মানে আরও বেশি rule বা মিটিং যোগ করা না, বরং খুব সৎভাবে দেখে নেওয়া কোন কাজগুলো সত্যিই value তৈরি করছে, আর কোনগুলো শুধু অভ্যাস, culture বা “এভাবেই তো সবসময় করি” এর কারণে চলছে। ছোট ছোট Observation → Measurement → Improvement সাইকেল, দ্রুত feedback loop আর টিমকে empower করার মধ্য দিয়েই আসল পরিবর্তন শুরু হয়।

আপনি চাইলে আজই একটা ছোট এক্সারসাইজ দিয়ে শুরু করতে পারেন। টিম নিয়ে বসে গত এক-দুই মাসের কাজের দিকে তাকান, আর চিন্তা করুন কোন কাজগুলো Muda ছিল? কোথায় অর্ধসমাপ্ত কাজ পড়ে আছে, কোথায় অতিরিক্ত মিটিং হয়েছে, কোথায় মানুষ তাদের আসল talent ব্যবহার করার সুযোগ পায়নি? Lean কোনো ম্যাজিক ফ্রেমওয়ার্ক না, বরং একটি continuous learning এবং improvement-এর মানসিকতা। যেখানে আপনিই প্রশ্ন করেন, “আমরা কেন এভাবে কাজ করছি, এর চেয়ে স্মার্টভাবে করা যায় না?”

যখন আপনি টিমের সাথে মিলে সেই প্রশ্নটার সঠিক উত্তর খুঁজতে শুরু করবেন, তখনই আসলে Lean journey শুরু হবে। আর সেই যাত্রার প্রতিটি ধাপ আপনাকে অল্প effort-এ বেশি impact, কম অপচয়ে বেশি value আর ধীরে ধীরে আরও হ্যাপি, motivated টিমের দিকে নিয়ে যায়।