1.6 সিদ্ধান্তের নথি

পরিচিতি ও প্রেরণা

সিদ্ধান্তের নথি হলো এমন একটি দলিল, যা একটি গুরুত্বপূর্ণ সিদ্ধান্তকে তার প্রেক্ষাপট ও পরিণতিসহ ধারণ করে। সবচেয়ে পরিচিত রূপ হলো স্থাপত্য সিদ্ধান্তের নথি (ADR), একটি সংক্ষিপ্ত, পছন্দমতো অপরিবর্তনীয় নোট, যা স্থাপত্যগতভাবে তাৎপর্যপূর্ণ একটি পছন্দ, তা কেন নেওয়া হয়েছিল এবং তার ফলে কী ঘটে তা লিপিবদ্ধ করে। একটি প্রকল্পের সম্পূর্ণ নথির সংগ্রহ তার সিদ্ধান্ত লগ (ADL), আর সেগুলো রাখার শৃঙ্খলা স্থাপত্য জ্ঞান ব্যবস্থাপনার (AKM) অংশ। এই অধ্যায় অধ্যায় 1.5-এর সিদ্ধান্ত গ্রহণ ও গভর্নেন্স চর্চার ওপর দাঁড়িয়ে আছে, এবং বড় পরিসরে সিদ্ধান্তের নথি কীভাবে লিখতে, সংরক্ষণ করতে ও টিকিয়ে রাখতে হয় তার ওপর মনোযোগ দেয়।

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

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

মূল নীতিসমূহ

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

সুপারিশ

অপরিহার্য কাঠামো ধারণ করুন

একটি ভালো সিদ্ধান্তের নথিতে কয়েকটি অপরিহার্য অংশ থাকে। নিজে উদ্ভাবনের বদলে পরিচিত একটি টেমপ্লেট মানিয়ে নিন:

• শিরোনাম: বর্তমান কালের আদেশসূচক একটি ছোট বাক্যাংশ (“খতিয়ানের জন্য PostgreSQL ব্যবহার করুন”)।
• অবস্থা: প্রস্তাবিত, গৃহীত, প্রতিস্থাপিত, বাতিল।
• প্রেক্ষাপট: পরিস্থিতি, শক্তিসমূহ, ব্যবসায়িক অগ্রাধিকার ও সীমাবদ্ধতা, যা এই সিদ্ধান্তকে আবশ্যক করে; এটি যে স্থাপত্যগতভাবে তাৎপর্যপূর্ণ প্রয়োজনীয়তার সমাধান করে তা অন্তর্ভুক্ত করুন।
• সিদ্ধান্ত: নেওয়া পছন্দ, সরল ভাষায়।
• পরিণতি: কী সহজ হয় এবং কী কঠিন হয়, কোন পরবর্তী সিদ্ধান্ত ট্রিগার হয়, এবং কোন ঝুঁকি গ্রহণ করা হলো।

জনপ্রিয় টেমপ্লেটের মধ্যে আছে Michael Nygard-এর (সরল ও বহুল গৃহীত), Tyree ও Akerman-এর (আরও বিস্তারিত, ওজনযুক্ত বিকল্পসহ), MADR (Markdown Any Decision Records, বিকল্প ও তাদের সুবিধা/অসুবিধায় শক্তিশালী) এবং Y-স্টেটমেন্ট (এক বাক্যের কাঠামোবদ্ধ রূপ)। প্রতিষ্ঠানে একটি টেমপ্লেটে প্রমিত হন, যাতে নথিগুলো তুলনীয় থাকে। কপি-পেস্ট টেমপ্লেটের জন্য অধ্যায় 12.3 দেখুন।

সুনির্দিষ্ট, তারিখযুক্ত ও প্রায়-অপরিবর্তনীয় নথি লিখুন

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

কাজ যেখানে হয় সেখানে নথি রাখুন

সিদ্ধান্তের নথি কোডের পাশে ভার্সন কন্ট্রোলে রাখুন: Markdown ফাইলের একটি decisions/ (বা adr/) ডিরেক্টরি, প্রতি সিদ্ধান্তে একটি, ছোট হাতের অক্ষরে, ড্যাশ-বিচ্ছিন্ন আদেশসূচক ক্রিয়াপদ বাক্যাংশে নামকরণ করা (choose-database.md, format-timestamps.md)। এতে ইতিহাস, পর্যালোচনা ও ডিফ বিনামূল্যে পান, এবং যুক্তি তার ব্যাখ্যার পাশেই থাকে। আপনার দল উইকি, Google Docs বা Jira-ধাঁচের ট্র্যাকার পছন্দ করলে সেগুলো ব্যবহার করুন। টুলের চেয়ে অভ্যাস অনেক বেশি গুরুত্বপূর্ণ। একটি হালকা কমান্ড-লাইন টুল (যেমন adr-tools) নথির কাঠামো ও সূচি তৈরি করতে পারে।

এগুলোর নাম দিন “সিদ্ধান্ত”, এবং স্থাপত্যের বাইরে বিস্তৃত করুন

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

জীবনচক্র ও গভর্নেন্স সংজ্ঞায়িত করুন

সিদ্ধান্তের নথি বড় হতে হলে আশেপাশের প্রক্রিয়া নিয়ে একমত হন (এখানেই অধ্যায় 1.5-এর গভর্নেন্স চর্চার সঙ্গে মেলে):

• কে একটি তুলতে পারেন, এবং কী তা যুক্তিসঙ্গত করে: সাধারণত যেকোনো অবহিত অবদানকারী; ভবিষ্যতের ডেভেলপারদের কেন-টি দরকার হলে নথি তুলুন, আর কম-ঝুঁকির, স্বয়ংসম্পূর্ণ, বা ইতিমধ্যে-নথিবদ্ধ পছন্দে এড়িয়ে যান।
• জীবনচক্র: সূচনা → গবেষণা → মূল্যায়ন → বাস্তবায়ন → রক্ষণাবেক্ষণ → অবসান-এর মতো সরল প্রবাহ, ধাপগুলোর মধ্যে সরতে গ্রহণযোগ্যতার মানদণ্ডসহ (সমস্যা স্পষ্ট করা, বিকল্প বিবেচনা, ট্রেড-অফ নথিবদ্ধ, অংশীজনদের সঙ্গে পরামর্শ)।
• ভূমিকা: প্রস্তাবক, গবেষক, পর্যালোচক, অনুমোদনকারী, এবং একজন জবাবদিহিযোগ্য রক্ষণাবেক্ষক, যিনি নির্দিষ্ট বিরতিতে (অন্তত বার্ষিক) নথি পর্যালোচনা করেন এবং শেষ পর্যন্ত অবসান চালান।
• গভর্নেন্স: ঐকমত্য, সংঘাত, উত্তরণ ও ভেটো কীভাবে কাজ করে, এবং কোনো বিধি-মান্যতার সীমাবদ্ধতা। কর্মের প্রতি ঝোঁক এবং দ্বিমত-করেও-প্রতিশ্রুতি-দাও-এর মতো নীতির ওপর ভরসা করুন, আর ভারী প্রক্রিয়া রাখুন অপরিবর্তনীয়, উচ্চ-বিস্ফোরণ-ব্যাসার্ধের (“একমুখী দরজা”) সিদ্ধান্তের জন্য।

সিদ্ধান্তকে পরীক্ষণযোগ্য ও খুঁজে-পাওয়া যায় এমন করুন

একটি সিদ্ধান্তের নথি একটি সিদ্ধান্ত নথিবদ্ধ করে; একটি ফিটনেস ফাংশন তা নিশ্চিত করে: কন্টিনিউয়াস ইন্টিগ্রেশনে (CI) চালানো একটি স্বয়ংক্রিয় পরীক্ষা, যা যাচাই করে সিদ্ধান্তটি এখনো ধরে আছে কি না (“সব অবস্থা-পরিবর্তনকে ইভেন্ট নির্গত করতে হবে”, “কোনো মডিউল এই সীমানা পেরিয়ে ইমপোর্ট করতে পারবে না”, ArchUnit-এর মতো টুল ব্যবহার করে)। এতে গভর্নেন্স পর্যায়ক্রমিক হাতে-করা পর্যালোচনা থেকে অবিচ্ছিন্ন, বড়-হওয়া-যায় এমন প্রয়োগে পরিণত হয়, যা নিয়ন্ত্রক ও অডিট লক্ষ্যের জন্য বিশেষভাবে মূল্যবান (অধ্যায় 3.1, 4.6, 8.5)। তারপর সঠিক মুহূর্তে সঠিক নথি সামনে আনুন। যে টুলিং ডেভেলপার যে কোডে হাত দেন তার নিয়ন্ত্রক সংশ্লিষ্ট সিদ্ধান্ত পুল রিকোয়েস্টে জুড়ে দেয়, তা মানুষ ডকস ফোল্ডার পড়বে এই আশার চেয়ে ভালো।

ট্রেড-অফ: সুবিধা ও অসুবিধা

পছন্দ	সুবিধা	অসুবিধা
হালকা ADR (Nygard/MADR)	লিখতে দ্রুত, সত্যিই লেখা হয়; কম আনুষ্ঠানিকতা	উচ্চ-ঝুঁকির, বিতর্কিত সিদ্ধান্তে কম কঠোরতা
ভারী টেমপ্লেট (Tyree-Akerman)	ওজনযুক্ত বিকল্প; বড়, ব্যয়বহুল পছন্দের জন্য শক্তিশালী	ধীর; রুটিন লিপিবদ্ধকরণে নিরুৎসাহিত করতে পারে
অপরিবর্তনীয় + প্রতিস্থাপন	পরিচ্ছন্ন অডিট ট্রেইল; ইতিহাস সংরক্ষিত	আরও নথি; পাঠকদের শৃঙ্খল অনুসরণ করতে হয়
জীবন্ত দলিল (তারিখযুক্ত সংশোধন)	একক বর্তমান সত্যের উৎস; রক্ষণাবেক্ষণ সহজ	দুর্বল অডিট গল্প; নিঃশব্দ সম্পাদনার ঝুঁকি
রিপোতে Markdown	ভার্সনযুক্ত, পর্যালোচনাযোগ্য, কোডের পাশে	অ-ডেভেলপারদের জন্য কম বান্ধব
উইকি / ডকস টুল	সব ভূমিকার জন্য সহজগম্য	ইতিহাস ও পর্যালোচনা দুর্বল; কোড থেকে সরে যায়

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

আপনার দলের সঙ্গে আলোচনার প্রশ্ন

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

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

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

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

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

6. আপনার কোন সর্বোচ্চ-ঝুঁকির সিদ্ধান্তগুলো আপনি স্বয়ংক্রিয় ফিটনেস ফাংশন দিয়ে নিশ্চিত করতে পারেন, পর্যায়ক্রমিক হাতে-করা পর্যালোচনা লঙ্ঘন ধরবে এই ভরসার বদলে? সিদ্ধান্তের নথি একটি পছন্দ নথিবদ্ধ করে, কিন্তু কেবল কন্টিনিউয়াস ইন্টিগ্রেশনে চালানো স্বয়ংক্রিয় পরীক্ষাই সেই পছন্দকে নিঃশব্দে ক্ষয়ে যাওয়া থেকে রক্ষা করে, যখন বছরের পর বছর ডজন ডজন ডেভেলপার কোডে হাত দেয়। ট্রেড-অফ হলো বিনিয়োগ, কারণ ফিটনেস ফাংশন লেখা ও রক্ষণাবেক্ষণে (ArchUnit-এর মতো টুল দিয়ে) প্রকৌশল সময় লাগে, আর অনেক সিদ্ধান্ত, বিশেষত প্রক্রিয়া বা বিক্রেতা পছন্দ, যান্ত্রিকভাবে পরীক্ষণযোগ্যই নয়। প্রমাণ আনুন: কোন সীমানা-সিদ্ধান্ত (মডিউল নির্ভরতা, ইভেন্ট নির্গমন, ডেটা-অ্যাক্সেস নিয়ম) নিঃশব্দে লঙ্ঘিত হয়েছে এবং কেবল দেরিতে পর্যালোচনায় বা প্রোডাকশনে ধরা পড়েছে। বহু দল চালানো এন্টারপ্রাইজের জন্য ফিটনেস ফাংশন গভর্নেন্সকে কেন্দ্রীয় বাধা থেকে অবিচ্ছিন্ন প্রয়োগে পরিণত করে, যা সবাইকে ধীর না করে বড় হয়। নিয়ন্ত্রিত ও সরকারি প্রেক্ষাপটে স্বয়ংক্রিয়, সদা-চালু পরীক্ষা পর্যালোচনার স্বাক্ষরের চেয়ে অনেক শক্তিশালী অডিট প্রমাণ, কারণ তা প্রমাণ করে সিদ্ধান্তটি আজও ধরে আছে, কেউ একবার অনুমোদন করেছিল তা নয়।

খাতভেদে দৃষ্টিভঙ্গি

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

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

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

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

উদাহরণ

স্টার্টআপ। পাঁচজনের একটি স্টার্টআপ তাদের প্রধান রিপোতে একটি সাদামাটা decisions/ ফোল্ডার যোগ করে, এবং কেউ তাদের ভবিষ্যৎ-নিজেরা প্রশ্ন তুলবে এমন সিদ্ধান্ত নিলেই দুই-অংশের একটি নোট (প্রেক্ষাপট ও পছন্দ) রাখে। কোনো জীবনচক্র নেই, কোনো ভূমিকা নেই, কোনো অনুমোদনকারী নেই: কেবল কোডের পাশে কেন লেখার অভ্যাস। ছয় মাস পর তাদের প্রথম নিয়োগ যোগ দিলে তিনি এক ঘণ্টায় পুরো ফোল্ডার পড়ে ফেলেন এবং “এটা এভাবে বানানো কেন?” জিজ্ঞেস করা বন্ধ করেন। হালকা লগে প্রতি এন্ট্রিতে কয়েক মিনিট লাগে, এবং দল বড় হওয়ার অনেক আগেই যে পুনরাবিষ্কারের কর লাগে তা থেকে তাদের বাঁচায়।

এন্টারপ্রাইজ। ৩০টি প্রকৌশল দলের একটি খুচরা বিক্রেতা প্রতিটি রিপোতে MADR-ধরনের নথি এবং একটি অনুসন্ধানযোগ্য কেন্দ্রীয় সূচিতে প্রমিত হয়। কোনো নতুন দল ”মনোরিপো বনাম মাল্টিরিপো”-র মুখোমুখি হলে তারা প্রেক্ষাপট ও পরিণতিসহ তিনটি পূর্ববর্তী নথি খুঁজে পায়, এবং এক মাসের বিতর্কের বদলে এক বিকেলে যুক্তি গ্রহণ করে। মূল সীমানা-সিদ্ধান্তগুলো (সার্ভিসের মালিকানা, ডেটা-অ্যাক্সেস নিয়ম) ArchUnit ফিটনেস ফাংশন দিয়ে সমর্থিত, তাই লঙ্ঘন পর্যালোচনায় ধরা পড়ার বদলে বিল্ড ব্যর্থ করে। এটাই কেন্দ্রীয় বাধা ছাড়া বড়-হওয়া গভর্নেন্স।

সরকার। একটি সুবিধা-ব্যবস্থা আধুনিকায়ন করা সংস্থা প্রতিটি স্থাপত্যগতভাবে তাৎপর্যপূর্ণ প্রয়োজনীয়তার জন্য একটি ADR আবশ্যক করে, প্রতিটি সিদ্ধান্তকে সেই আদেশ বা বিধি-মান্যতার নিয়ন্ত্রণের সঙ্গে যুক্ত করে যা তা পূরণ করে (অভিগম্যতা, ডেটার অবস্থান, নিরীক্ষণযোগ্যতা)। নথিগুলো অপরিবর্তনীয় ও প্রতিস্থাপিত, যা তদারকি পর্যালোচনা পূরণ করা একটি অনুসরণযোগ্য লগ তৈরি করে। গুরুত্বপূর্ণভাবে, এটি উত্তরসূরি ঠিকাদারকেও বুঝতে দেয় সিস্টেম কেন এই আকারের, যা জনকর্মসূচির সাধারণ বহু-বছরের, বহু-বিক্রেতার আয়ুষ্কাল জুড়ে ধারাবাহিকতা রক্ষা করে (অধ্যায় 4.6, 10.4)।

ব্যবসায়িক যুক্তি: প্রেরণা, ROI ও TCO

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

মালিকানার মোট খরচের ক্ষেত্রে সিদ্ধান্তের নথি আপনার রাখা সবচেয়ে উচ্চ-প্রভাবশালী নথিপত্রের অন্যতম, কারণ তা কর্মী-বদলে সবচেয়ে সংবেদনশীল সম্পদ লক্ষ্য করে: যুক্তি। অনবোর্ডিং দ্রুত হয় (নতুন নিয়োগ কেবল কোড নয়, কেন-ও পড়ে)। আধুনিকায়ন নিরাপদ হয় (অধ্যায় 3.6: আপনি অপরিহার্য সিদ্ধান্ত আর আনুষঙ্গিক সিদ্ধান্ত আলাদা করতে পারেন)। অডিট সস্তা হয় (প্রমাণ ইতিমধ্যে আছে)। সেগুলো না রাখার খরচ কোনো ড্যাশবোর্ডে অদৃশ্য, এবং প্রতিটি প্রস্থানের সঙ্গে নিঃশব্দে চক্রবৃদ্ধি হয়। নেতৃত্বের কাছে যুক্তি দিতে একটি সাম্প্রতিক ব্যয়বহুল পুনরাবিষ্কার, বা একটি উল্টে-দেওয়া সিদ্ধান্ত যা ঘটনা ঘটিয়েছিল, তা দেখান, এবং বলুন যে সমাধান চালু করতে প্রায় কিছুই খরচ হয় না।

অ্যান্টি-প্যাটার্ন ও ফাঁদ

• কেন ছাড়া কী লিপিবদ্ধ করা: প্রেক্ষাপট ও বাতিল বিকল্প বাদ দেওয়া, যা পুরো উদ্দেশ্য।
• ঘটনার-পরের কাগজপত্র: আদেশ পূরণে লেখা নথি, ভাবার জন্য নয়; সেগুলো ফাঁপা পড়ায় এবং কেউ বিশ্বাস করে না।
• বহু-সিদ্ধান্তের মেগা-দলিল: একটি বিশাল পাতা, যা কেউ নেভিগেট বা পরিচ্ছন্নভাবে প্রতিস্থাপন করতে পারে না।
• তারিখবিহীন দাবি: একসময় সত্য ছিল এমন খরচ ও সীমাবদ্ধতা, চিরন্তন হিসেবে উপস্থাপিত।
• নিঃশব্দ সম্পাদনা: তারিখযুক্ত নোট ছাড়া সিদ্ধান্তের ইতিহাস বদলে অডিট ট্রেইল নষ্ট করা।
• শুধু-লেখার লগ: নথি তৈরি হয়, কিন্তু প্রাসঙ্গিক মুহূর্তে কখনো সামনে আনা হয় না, তাই আচরণ প্রভাবিত করে না।
• সংক্ষিপ্ত রূপের দ্বাররক্ষা: “ADR” ও “স্থাপত্য” নিয়ে জেদ করে অবদান নিরুৎসাহিত করা।
• জীবনচক্রহীনতা: যে নথি কখনো পর্যালোচিত, প্রতিস্থাপিত বা অবসানিত হয় না, ভুল তথ্যে ক্ষয়ে যায়।

পরিপক্বতা মডেল

• স্তর ১ (সূচনা): সিদ্ধান্ত থাকে মানুষের মাথায়, চ্যাট থ্রেডে ও কমিট বার্তায়; ধারণ প্রতিক্রিয়াশীল ও তাৎক্ষণিক, এবং কর্মী বদলে যুক্তি নিয়মিত হারিয়ে যায়।
• স্তর ২ (বিকাশ): কিছু দল নথি রাখে, বিভিন্ন ধরন ও টেমপ্লেটে, যখনই কারও মনে পড়ে; চর্চা দলগুলোর মধ্যে অসঙ্গত, কোনো ভাগ করা লগ, নামকরণ বা প্রক্রিয়া ছাড়া।
• স্তর ৩ (মানসম্মতকরণ): একটি টেমপ্লেট, রিপোতে সংরক্ষণ, এবং সংজ্ঞায়িত জীবনচক্র ও গভর্নেন্স (তোলা/এড়ানোর মানদণ্ড, ভূমিকা, পর্যালোচনার বিরতি) নথিবদ্ধ এবং প্রতিষ্ঠানজুড়ে সামঞ্জস্যপূর্ণভাবে প্রযুক্ত; নথি নিঃশব্দে সম্পাদনার বদলে পর্যালোচিত ও প্রতিস্থাপিত হয়।
• স্তর ৪ (ব্যবস্থাপনা): সিদ্ধান্ত লগ ভিত্তিরেখার বিপরীতে মাপা হয়: আওতা (নথিযুক্ত স্থাপত্যগতভাবে তাৎপর্যপূর্ণ সিদ্ধান্তের অংশ), সতেজতা (বিরতির মধ্যে পর্যালোচিত নথির অংশ, এবং তারিখবিহীন বা সেকেলে দাবির সংখ্যা) এবং খুঁজে-পাওয়া-যাওয়া (নিয়ন্ত্রিত কোড বদলানো ডেভেলপারের কাছে একটি প্রাসঙ্গিক নথি কত ঘন ঘন সত্যিই পৌঁছেছে)। জবাবদিহিযোগ্য রক্ষণাবেক্ষকরা এই মেট্রিকের ওপর ভিত্তি করে কাজ করেন, গল্পের বদলে প্রমাণের ভিত্তিতে সেকেলে নথি প্রতিস্থাপন করেন ও আওতার ফাঁক বন্ধ করেন।
• স্তর ৫ (সমন্বয়): একটি অনুসন্ধানযোগ্য আন্তঃদল সিদ্ধান্ত লগ দৈনন্দিন কাজে একীভূত: প্রাসঙ্গিক নথি যে পরিবর্তন তা নিয়ন্ত্রণ করে তার ওপর স্বয়ংক্রিয়ভাবে সামনে আসে, মূল সিদ্ধান্ত কন্টিনিউয়াস ইন্টিগ্রেশনে ফিটনেস ফাংশন দিয়ে নিশ্চিত হয়, এবং লগ অনবোর্ডিং, আধুনিকায়ন ও অডিটকে জীবন্ত সম্পদ হিসেবে জোগান দেয়। প্রতিষ্ঠান চর্চাটিকেই নিরন্তর উন্নত করে, সিস্টেম ও তার সীমাবদ্ধতা সরলে নথি অবসান, প্রতিস্থাপন ও পুনঃসীমানা করে, এবং সিদ্ধান্তের পোর্টফোলিও বাড়লে কোথায় কঠোরতায় বিনিয়োগ করে তা নতুন করে ভারসাম্যে আনে।

আলোচনার ভাবনা

1. আপনার দল সর্বশেষ কোন সিদ্ধান্ত উল্টে দিয়েছে বা নিয়ে আবার তর্ক করেছে কারণ কেউ মূল যুক্তি মনে রাখেনি?
2. আপনার adr/ ডিরেক্টরির নাম decisions/ রাখলে কে অবদান রাখেন এবং কী লিপিবদ্ধ হয় তা কি বদলাবে?
3. আপনার কোন গুরুত্বপূর্ণ সিদ্ধান্তগুলো আজই স্বয়ংক্রিয় ফিটনেস ফাংশন দিয়ে নিশ্চিত করা যায়?
4. অপরিবর্তনীয়-ও-প্রতিস্থাপন নাকি জীবন্ত-দলিল: কোনটি আপনার অডিট বাধ্যবাধকতা ও সংস্কৃতির সঙ্গে খাপ খায়, এবং কেন?
5. একজন নতুন নিয়োগ (বা উত্তরসূরি ঠিকাদার) বর্তমানে কীভাবে আবিষ্কার করবেন যে আপনার সিস্টেম কেন এই আকারের?
6. আপনার দলে সিদ্ধান্তের নথি তোলাকে কী যুক্তিসঙ্গত করে, এবং না তোলাকে কী যুক্তিসঙ্গত করে?

প্রধান শিক্ষা

• একটি সিদ্ধান্তের নথি একটি গুরুত্বপূর্ণ সিদ্ধান্তকে তার প্রেক্ষাপট ও পরিণতিসহ ধারণ করে: শুধু কী নয়, কেন।
• নথি সুনির্দিষ্ট, সময়ছাপযুক্ত ও হালকা রাখুন; একটি টেমপ্লেটে প্রমিত হন (Nygard, MADR বা অনুরূপ)।
• সেগুলো কোডের পাশে ভার্সন কন্ট্রোলে রাখুন; অবদান বিস্তৃত করতে এগুলোর নাম “সিদ্ধান্ত” রাখার কথা ভাবুন।
• একটি জীবনচক্র ও গভর্নেন্স সংজ্ঞায়িত করুন (তোলা/এড়ানোর মানদণ্ড, ভূমিকা, পর্যালোচনার বিরতি); ভারী প্রক্রিয়া রাখুন একমুখী-দরজার সিদ্ধান্তের জন্য।
• সিদ্ধান্তকে পরিবর্তনের মুহূর্তে খুঁজে-পাওয়া যায় এবং যেখানে সম্ভব ফিটনেস ফাংশনের মাধ্যমে পরীক্ষণযোগ্য করুন।
• ROI হলো এড়ানো পুনরাবিষ্কার ও ভুল-উল্টানোর খরচ; TCO-র যুক্তি সবচেয়ে শক্তিশালী যেখানে কর্মী-বদল, আধুনিকায়ন ও অডিট সবচেয়ে বেশি গুরুত্বপূর্ণ। অধ্যায় 1.5 (সিদ্ধান্ত গ্রহণ ও গভর্নেন্স) এবং অধ্যায় 3.1 (স্থাপত্যের মূলনীতি) দেখুন।

তথ্যসূত্র ও আরও পড়ার জন্য

• Michael Nygard, “Documenting Architecture Decisions” (2011): মৌলিক হালকা ADR।
• MADR: Markdown Any Decision Records প্রকল্প (adr.github.io/madr)।
• Jeff Tyree ও Art Akerman, “Architecture Decisions: Demystifying Architecture” (IEEE Software, 2005)।
• Olaf Zimmermann, “Y-Statements” এবং “Architectural Decision Making” (ozimmer.ch)।
• Joel Parker Henderson, Architecture Decision Record (ADR): টেমপ্লেট, উদাহরণ ও দলীয় কাজের নির্দেশিকা (github.com/joelparkerhenderson/architecture-decision-record)।
• ThoughtWorks Technology Radar: “Lightweight Architecture Decision Records.”
• Neal Ford, Rebecca Parsons, Patrick Kua, Pramod Sadalage, Building Evolutionary Architectures (ফিটনেস ফাংশন)।
• AWS Prescriptive Guidance, “ADR process”; Red Hat, “Why you should use ADRs.”
• Wikipedia, “Architectural decision” এবং “Architecturally significant requirements.”