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