ডিজিটাল প্রসেস-ফ্লো এবং এনালগ কর্মপন্থা

কাগুজে ডকুমেন্ট এবং সফটওয়্যার

১৯৯২-৯৪ সালের কথা। পোস্টিং তখন সৈয়দপুরে। ব্রিগেড হেডকোয়ার্টারে আইবিএমের একটা কম্পিউটার ছিল আমার অফিস এবং অবসরের সঙ্গী। মাইক্রোসফট ডসের উপর ওয়ার্ড পারফেক্ট এবং লোটাস ১২৩ এর ম্যানুয়ালগুলো পড়তে ভালই লাগতো সন্ধায়। ব্রিগেড সিগন্যাল কোম্পানীর (যোগাযোগ দেবার একটা ইউনিট) কোম্পানি অফিসার, অটোমেশনে খুব ঝোক।

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

ইন্টেলেকচুয়াল ডিসটেন্স

The design process should reduce the gap between real-world problems and software solutions for that problem meaning it should simply minimize intellectual distance.

-- Minimize Intellectual distance, Principles of Software Design, GeeksforGeeks

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

এর মানে হচ্ছে, একই জিনিস লিখতে হতো বেশ কয়েক জায়গায় কাগজের ডকুমেন্ট হিসেবে। লোটাস ১২৩ এর কাজের ধারা দেখে মাথায় ভুত চাপল এই ডকুমেন্টকে স্প্রেডশিটে নেয়া যায় কিনা? একটা এনালগ অর্থাৎ কাগজের ডকুমেন্ট থেকে স্প্রেডশিটে হুবহু তুলতে গিয়ে ধারণা পেলাম কয়েকটা জিনিস। সেটাই পাল্টে দিয়েছে অটোমেশন সম্মন্ধে আমার ধারণা, জীবনের শুরুতে।

কাগুজে ডকুমেন্ট এবং ওয়ার্ক-ফ্লো

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

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

ডিজাইন 'থিঙ্কিং' অর্থাৎ চিন্তাভাবনা প্রসেস

বাইরের চিন্তা

Design thinking takes the next step, which is to put these tools into the hands of people who may have never thought of themselves as designers and apply them to a vastly greater range of problems.

-- Change by Design, Tim Brown

এই প্রসেসে ব্যবহারকারী অথবা কাস্টমার হিসেবে আমরা শেষ পর্যায়ে কি আশা করছি সেটা বলে দিলেই হল। ‘ইন্টারমিডিয়েট’ অথবা মাঝখানে কি হবে সে ব্যাপারে ডিজাইনারকে “ডিকটেট’ করলে তার ‘অপটিমাল ডিজাইন প্রসেস’ ব্যাহত হয়। আমরা সর্বশেষে কি পাব অর্থাৎ আমরা সফটওয়্যার থেকে কি আশা করছি সেটা নিয়ে কাজ করলে সেখান থেকে ‘ব্যাক ক্যালকুলেশন’ করে অনেক কিছুই পাওয়া সম্ভব, তবে আমাদের চিন্তা ধারণার সীমাবদ্ধতার কথা চিন্তা করে কাগজের ফরম্যাট সরাসরি সফট্ওয়ারে নেবার যৌক্তিকতা নেই। বোঝার জন্য - ডিজাইন চিন্তাভাবনা একটা নন-লিনিয়ার, আইটেরেটিভ অর্থাৎ পুনরাবৃত্তি প্রক্রিয়া যা ব্যবহারকারীদের বোঝার জন্য আমরা ব্যবহার করতে পারি। এটা ব্যবহার করা যেতে পারে - ১. অনুমানকে চ্যালেঞ্জ জানাতে, ২. সমস্যাগুলোকে নতুন করে সংজ্ঞায়িত করতে এবং ৩. প্রোটোটাইপ, পরীক্ষার উদ্ভাবনী সমাধান তৈরি করতে। যে সমস্যাগুলো ঠিকমতো সংজ্ঞায়িত করা নেই অথবা অজানা; সেগুলোকে ঠিক করতে এটা সবচেয়ে বেশি কার্যকর। এটাই লাগবে আমাদের যখন কাগুজে ডকুমেন্ট থেকে সফটওয়্যারে আসবো।