সফটওয়্যার ডেভেলপমেন্ট: পর্দার পেছনের বাস্তবতা এক ডেভেলপারের চোখে

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

ছয় বছর আর অসংখ্য প্রজেক্ট হাতে নেয়ার পর বুঝেছি—বইয়ের SDLC (Software Development Life Cycle) ডায়াগ্রামে সবচেয়ে গুরুত্বপূর্ণ জিনিসটাই নেই: "মানুষ" আর তার জটিলতা। বইয়ের ছবিতে সবকিছু খুব গোছানো দেখায়:

requirements → design → development → testing → deployment → maintenance

কিন্তু বাস্তবটা? বাস্তবে সবকিছুই এলোমেলো, জটপাকানো, আর মাঝেমাঝে মনে হয় এই diagram আসলে একেকটা গোলকধাঁধা!

Requirements: আসলে আমরা চাইটা কী?

সবকিছুর শুরু হয় একটা শান্ত-সাদামাটা মিটিং দিয়ে। সবাই এমন ভাব করে যেন সব একদম crystal clear—কে কী বানাবে, কেন বানাবে, কবে বানাবে, সব নাকি ঠিকঠাক বুঝে ফেলেছে।

প্রডাক্ট ম্যানেজার বলেন,

"একটা ড্যাশবোর্ড লাগবে, যেটা ইউজার অ্যানালিটিক্স দেখাবে।"

শুনতে সহজ, তাই না?

কিন্তু একটু পরেই বোঝা যায়, উনার মানে আসলে ছিল:

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

এই জন্যই আমি বুঝে গেছি, রিকোয়ায়ারমেন্ট গ্যাদারিং মানে একটা মিটিং না—এটা হচ্ছে একটানা আলোচনা, বোঝাপড়া, দরকষাকষির একটা চলমান প্রক্রিয়া।

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

• "এই ফিচারটা আসলে দরকার কেন?"
• "এটা কোন সমস্যার সমাধান করছে?"

এমন প্রশ্ন আমাদের শুধু requirements পরিষ্কার করে না, অনেক সময় ভুল দিকেও যেতে বাঁধা দেয়।

Design: স্বপ্ন আর বাস্তবতার লড়াই

এই ধাপে ডেভেলপারদের কিছু সময়ের জন্য স্বপ্ন দেখার সুযোগ থাকে।

• "নতুন ফ্রেমওয়ার্ক ইউজ করবো!"
• "সবকিছু একদম মডুলার হবে!"
• "টেস্ট কভারেজ ১০০%!"

আর অবশ্যই,

"পারফেক্ট আর্কিটেকচার বানাবো, যেটা দেখে সবাই বলবে—'ওয়াও!'"

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

ডিজাইন মিটিংগুলোতে আমি বহুবার তর্ক হতে দেখেছি:

• "Redux নাকি Zustand?"
• "GraphQL নাকি REST?"
• "Clean architecture নাকি simple folder structure?"

যেখানে ইউজারদের কাছে এসবের কিছুই গুরুত্বপূর্ণ না। তাদের শুধু দরকার অ্যাপটা যেন ঠিকমতো কাজ করে।

সবচেয়ে কাজে আসা ডিজাইন ডকুমেন্টগুলো ছিল সেইগুলো, যেগুলো পরিষ্কারভাবে দেখাত:

• কোথায় কী ট্রেড-অফ করা হয়েছে
• কেন কোন সিদ্ধান্ত নেওয়া হয়েছে
• সেটা কীভাবে ইউজারের অভিজ্ঞতায় প্রভাব ফেলবে

স্বপ্ন দেখা ভালো, কিন্তু বাস্তবতার সাথে তাল মেলাতে না পারলে, সেই স্বপ্নই পরে দুঃস্বপ্ন হয়ে যেতে পারে।

Development: যেখানে টাইম এস্টিমেট সবসময় ঠিক হয় না

"এই জিনিসটা বানাতে কতদিন লাগবে?"

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

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

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

Testing: ইউজারদের মাথার ভেতর ঢুকতে শেখা

"এই অর্ডারে কেউ বাটন চাপবে কেন?"

এই প্রশ্নটা আমি নিজেও করেছি—আর হ্যাঁ, পরে বুঝেছি, কেউ না কেউ ঠিকই ওইভাবে বাটন টিপবে।

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

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

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

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

Deployment: যখন প্রোডাকশনে হঠাৎ নিঃশ্বাস বন্ধ হয়ে আসে

বড় কোনো ডিপ্লয়মেন্টের দিনটা একেবারে আলাদা ফিল দেয়। সবাই ঠাট্টা করে, কিন্তু আসলে কারো নিঃশ্বাস ঠিকমতো নিচ্ছে না। কেউ মনিটরিং টুল ঘনঘন রিফ্রেশ করছে, কেউ সাইলেন্ট প্রে-মোডে চলে গেছে।

স্টেজিং-এ যতই খুঁটিয়ে টেস্ট করো, প্রোডাকশন একেবারেই অন্য জিনিস। এখানে ইউজার আসল, ডেটা আসল, আর চাপটা তো একেবারে রিয়েল ফিল দেয়।

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

• মনিটরিং ছিল?
• রোলব্যাক স্ক্রিপ্ট রেডি ছিল?
• টিমের মধ্যে কে কী করছে সেটা সবাই জানত?

যদি সব ঠিকমতো হয়, একটা ছোট নিঃশ্বাস ফেলা যায়। কিন্তু সেখানেই তো গল্প শেষ না।

Maintenance: নিজের পুরনো কোড দেখে আঁতকে ওঠা

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

মজার ব্যাপার হলো, ওই "কে যেন" অনেক সময় তুমিই—তবে দুই বছর আগের ভার্সনে। তোমার নিজের কোড দেখে মাথায় হাত পড়ে,

"আমি ঠিক কী ভেবে এটা করেছিলাম?"

আজ একটু সময় নিয়ে ভালো কমেন্ট লিখলে, একটা ছোট টেস্ট কেস যদি লিখে রাখো—আগামীর তুমিই তোমাকে ধন্যবাদ দেবে।

The Human Element: প্রযুক্তির ভেতরেও যা আমাদের মানুষ করে তোলে

এই পেশায় আসার পর আমি বুঝেছি—সবচেয়ে বড় চ্যালেঞ্জ আসলে কোড না, কম্পিউটার না, বরং মানুষ।

টিকটিক শব্দে টাইপ করা লাইনগুলো যতটা জটিল মনে হয়, তার চেয়েও বেশি জটিল হলো মানুষে-মানুষে বোঝাপড়া।

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

এগুলো প্রথমে বিরক্তিকর বা হতাশাজনক লাগলেও, দিনশেষে এগুলোই আমাদের কাজের প্রাণ। একসাথে বসে মাথা ঘামানো, ঝামেলা কাটিয়ে ওঠা, আর রিলিজের পর টিমের কারো মুখে হাসি—"nice work!" এই ছোট ছোট মুহূর্তগুলোর কোনো মেট্রিক্স হয় না, কিন্তু এটাই থেকে যায় মনে, এটাই তৈরি করে গল্প।

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

তাই, হ্যাঁ—SDLC ফলো করো, CI/CD জানো, ফ্রেমওয়ার্ক চেনো, কিন্তু যেটা ভুললে চলবে না—এই সবকিছু আসলে একটা মানুষের যাত্রা। খানিক বিশৃঙ্খল, খানিক অপ্রত্যাশিত, কিন্তু ঠিক সেই কারণেই, গভীরভাবে অর্থবহ।

এবং সম্ভবত, এই কারণেই—আজও প্রতিদিন উঠে আবার কোড লিখতে বসার মানে হয়।