কর্মস্থলে অ-প্রযুক্তিগত টিমদের জন্য ডেটা ডিকশনারি টেমপ্লেট

কেন টিমগুলোর মধ্যে ভাগ করা ডেটা নিয়ে বিভ্রান্তি হয়

ভাগ করা ডেটা এলোমেলো হয়ে যায় এক সরল কারণে: একই শব্দটি বিভিন্ন মানুষ ভিন্নভাবে ব্যবহার করে, বা বিভিন্ন শব্দ একই জিনিস বোঝায়। একজন সেলস ম্যানেজার বলতে পারেন "customer stage", একজন সাপোর্ট লিড বলেন "account status", আর একজন বিল্ডার অ্যাপে ফিল্ডটি লেবেল করতে পারেন state। এগুলো সম্পর্কিত হতে পারে, কিন্তু সব সময় একই নয়।

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

অধিকাংশ সমস্যা কয়েকটি পুনরাবৃত্ত নতুন নিদর্শন থেকে আসে:

• একটি ফিল্ড বিভিন্ন টুল বা স্ক্রিনে ভিন্নভাবে নামকরণ করা হয়।
• একটি স্ট্যাটাস সেলসের কাছে এক অর্থ, সাপোর্টের কাছে ভিন্ন অর্থ থাকে।
• একটি মেট্রিক সময়ের সাথে বদলে যায়, কিন্তু কেউ তার নিয়ম লিখে রাখে না।
• মানুষ বারবার সহকর্মীদের জিজ্ঞেস করে যে কোনো লেবেলের আসল মানে কী।

স্ট্যাটাসগুলো ভুল তৈরি করে কারণ এগুলো সহজ মনে হয়। "Open", "Active" বা "Resolved" এর মতো শব্দ প্রথমে স্পষ্ট শোনায়, কিন্তু হাতে-কলমে কাজ করলে teams এগুলো ভিন্নভাবে ব্যবহার করে। সাপোর্টের জন্য "Resolved" মানে সমস্যা ফিক্স হয়েছে। সেলসের জন্য এটা হতে পারে গ্রাহক উত্তর দিয়েছে। যদি উভয় টিম একই রিপোর্ট পড়ে, তাদের আলাদা উপসংহার আসতে পারে।

মেট্রিকগুলো অন্য ধরনের বিভ্রান্তি তৈরি করে। একটি ড্যাশবোর্ডে হতে পারে "new customers" বা "monthly revenue", কিন্তু যদি সঠিক নিয়ম না লেখা থাকে, মানুষ নিজেরাই খালি জায়গা পূরণ করে। "new customer" মানে কি প্রথম সাইনআপ, প্রথম পেমেন্ট, নাকি প্রথম সম্পন্ন অনবোর্ডিং? যখন কোনো রিপোর্ট থেকে আরেক রিপোর্টে উত্তরে পরিবর্তন আসে, বিশ্বাস তাড়াতাড়ি কমে যায়।

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

একটি হালকা ডেটা ডিকশনারিতে কী থাকা উচিত

একটি ব্যবহারযোগ্য ডেটা ডিকশনারি দীর্ঘ হওয়ার দরকার নেই। এটা শুধু সেই মৌলিক প্রশ্নগুলোর উত্তর দিতে হবে যা মানুষ কোনো ফিল্ড, স্ট্যাটাস বা মেট্রিক দেখলে জিজ্ঞেস করে—যখন তারা নিশ্চিত নয় এটা কী বোঝায়।

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

প্রতিটি ফিল্ডের জন্য এই মৌলিকগুলো নোট করুন:

• ফিল্ডের নাম, ঠিক যেমনটি অ্যাপ বা রিপোর্টে দেখা যায়
• একটি সাধারণ ভাষায় মানে যা বোঝায় vrijed
• কন্ট্রোল্ড ফিল্ডগুলোর জন্য অনুমোদিত মান, যেমন স্ট্যাটাস, ক্যাটাগরি, অথবা হ্যাঁ-কোনো পছন্দ
• ডেটার উৎস, যেমন ব্যবহারকারী ইনপুট, সিস্টেম-জেনারেটেড মান, বা ইম্পোর্ট করা রেকর্ড
• একটি পরিষ্কার মালিক যিনি পরিবর্তন অনুমোদন করেন এবং প্রশ্নের উত্তর দেন

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

একটি সহজ এন্ট্রি দেখতে এমন হতে পারে:

Field: ticket_status
Meaning: Current stage of a support ticket
Allowed values: New, In Progress, Waiting on Customer, Resolved, Closed
Source: Updated by support staff or automation rules
Owner: Support operations manager
Change frequency: Changes during the life of the ticket

ডিকশনারি হালকা রাখুন, কিন্তু অস্পষ্ট নয়। যদি নতুন সহকর্মী এখনও জিজ্ঞেস না করে বুঝতে না পারেন কোনো ফিল্ডের মানে কী, তাহলে সংজ্ঞা সম্পূর্ণ নয়।

নামে নিয়ম যা পুনরায় কাজ হওয়া প্রতিরোধ করে

ফিল্ড নামগুলো সবচেয়ে ভালোভাবে বিরক্তিকর হওয়া উচিত। যখন মানুষ একটি ফিল্ড দেখে, তাদের সাহায্য ছাড়া বুঝতে হবে কী বোঝায়।

প্রথমে একটি নামকরণ ফরম্যাট বেছে নিন এবং সারা জায়গায় ব্যবহার করুন। যদি আপনার টিম customer_name ব্যবহার করে, তাহলে এক স্ক্রিনে CustomerName এবং আরেকটায় clientName এ বদলাবেন না। একটি একক প্যাটার্ন ফর্ম, রিপোর্ট, এবং API লেবেলগুলো পড়া সহজ করে তোলে, এমনকি অ-প্রযুক্তিগত টিমের জন্যও।

সংক্ষিপ্ত রূপ প্রায়ই সমস্যা তৈরি করে। addr, amt, বা lvl টাইপ করা দ্রুত মনে হতে পারে, কিন্তু পরে সবাইকে ধীরে করে। যদি কোনো সংক্ষিপ্ত রূপ আপনার কোম্পানির মধ্যে সত্যিই প্রচলিত হয়, সেটি রাখুন। না হলে পুরো শব্দ লিখুন।

নামগুলো বাস্তব ব্যবসায়িক প্রক্রিয়ার সাথে মিলতে হবে, কোনো অভ্যন্তরীণ শর্টকাটের সাথে নয়। একটি কাস্টমার সাপোর্ট অ্যাপে, যদি আপনার টিম সবসময় "ticket" বলে, তাহলে ticket_status হবে case_state থেকে বেশি পরিষ্কার। সিস্টেমে থাকা শব্দগুলো মিটিং, ডকুমেন্ট, এবং দৈনন্দিন কাজে ব্যবহৃত শব্দগুলোর মতো হওয়া উচিত।

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

যখন একটি নাম দুইভাবে পড়া যেতে পারে, ডিকশনারিতে উদাহরণ মান যোগ করুন। ছোট এই বিষয়টা সময় সেভ করে। উদাহরণস্বরূপ:

• customer_type - Example: business, individual
• order_total - Example: 149.99
• first_response_at - Example: 2026-03-08 09:30 UTC

একটি সাধারণ ফিল্ড নামকরণ স্ট্যান্ডার্ড সাধারণত যথেষ্ট:

• সম্ভব হলে পূর্ণ শব্দ ব্যবহার করুন।
• একই জিনিসের জন্য একই শব্দ সারাবিশ্বে ব্যবহার করুন।
• অভ্যন্তরীণ জার্গন এর থেকে ব্যবসায়িক শব্দ খুঁজুন।
• সময় এবং তারিখ ফিল্ডগুলো স্পষ্ট রাখুন, যেমন created_at বা closed_date।
• একটি ফিল্ড ভুল বোঝার সম্ভাবনা থাকলে উদাহরণ মান যোগ করুন।

পরিষ্কার নামকরণ আশ্চর্যজনক পরিমাণে পুনরায় কাজ কমিয়ে দেয়। এটি ব্যবসা ব্যবহারকারী এবং বিল্ডারদের একই ভাষায় কথা বলার জন্য সাহায্য করে, রিপোর্ট এবং ড্যাশবোর্ডে বিভ্রান্তি পৌঁছার আগেই।

বাস্তব কাজ দিয়ে স্ট্যাটাসগুলো সংজ্ঞায়িত করুন

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

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

প্রতিটি স্ট্যাটাসের জন্য তার মানে সহজ ভাষায় লিখুন—কখন ব্যবহার করা উচিত, কী ঘটতে হবে আগে সেটি নির্বাচিত করার জন্য, এটি কি একটি চূড়ান্ত স্ট্যাটাস, এবং কে এটি পরিবর্তন করতে পারে।

সর্ববৃহৎ চেক হচ্ছে ওভারল্যাপ। যদি "In Review" এবং "Pending Approval" একই সময়ে একই রেকর্ড বর্ণনা করতে পারে, লোকেরা র‍্যান্ডমভাবে চয়েস করবে। এর ফলে রিপোর্ট অনবিশ্বস্ত হয়ে যায়। প্রতিটি স্ট্যাটাস প্রক্রিয়ার একটি আলাদা পয়েন্ট চিহ্নিত করা উচিত।

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

মালিকানা অর্থ যতটা যে মানে ততটাই গুরুত্বপূর্ণ। কিছু স্ট্যাটাস কেবল ম্যানেজার, সাপোর্ট লিড, বা সিস্টেম রুল দ্বারা পরিবর্তন করা উচিত। যদি কেউই যেকেউ যেকোনো স্ট্যাটাস বদলে দিতে পারে, প্রক্রিয়াটি দ্রুত বিচ্যুত হবে।

একটি ছোট উদাহরণ সহায়ক। একটি সাপোর্ট অ্যাপে, "Waiting for Customer" এর মানে হওয়া উচিত দল ইতিমধ্যেই উত্তর দিয়েছে এবং গ্রাহকের প্রতিক্রিয়ার অপেক্ষায় আছে—এবং এগিয়ে যাওয়ার আগে গ্রাহকের উত্তর দরকার। এটা তখন ব্যবহার করা উচিত নয় যখন দল এখনো অভ্যন্তরীণ তদন্ত করছে। সেই ক্ষেত্রে আলাদা স্ট্যাটাস লাগবে, যেমন "In Progress"।

যদি মানুষ একটি স্ট্যাটাস সংজ্ঞা পড়ে প্রতিবার একই সিদ্ধান্ত নিতে পারে, আপনার স্ট্যাটাস নামকরণ উদাহরণ কাজ করছে।

প্রতিটি মেট্রিককে একটি স্থায়ী সংজ্ঞা দিন

একটি মেট্রিক তখনই ব্যবহারযোগ্য যখন দুই ব্যক্তি সেটি পড়ে একই অর্থ পায়। যদি সেলস, সাপোর্ট, এবং ড্যাশবোর্ড বানানো ব্যক্তি—তিনজনই আলাদা ভাবে সংজ্ঞা দেয়, সংখ্যা নির্ভরযোগ্য থাকে না।

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

একটি সহজ মেট্রিক কার্ড ব্যবহার করুন

প্রতিটি মেট্রিকের জন্য প্রতিবার একই কাঠামো ব্যবহার করুন:

• Metric name
• Plain-language formula
• Included records
• Excluded records
• Time period
• Refresh timing
• Sample calculation

ফর্মুলাকে পড়তে সহজ রাখুন। কেবল Resolved tickets / Total tickets লিখার বদলে লিখুন: "Resolution rate is the number of resolved tickets divided by the total number of tickets created in the same period."

তারপর নির্দিষ্টভাবে লিখুন কী গণনা করা হবে। বলুন কোন রেকর্ডগুলো সংখ্যায় থাকবে এবং কোনগুলো থাকবে না। যদি পুনরায় খোলা টিকিটগুলো রেজলভড হিসেবে বিবেচিত না হয়, সেটা স্পষ্টভাবে বলুন। যদি স্প্যাম টিকিট, টেস্ট টিকিট, বা মার্জ করা ডুপ্লিকেট বাদ দেওয়া হয়, তাও নোট করুন।

সময়কাল ফর্মুলির মতোই গুরুত্বপূর্ণ। "Monthly resolution rate" বলতে বোঝায় কি ক্যালেন্ডার মাস, গত ৩০ দিন, নাকি কাস্টম রিপোর্টিং উইন্ডো? এগুলো সব আলাদা।

রিফ্রেশ সময়ও সাধারণ ভাষায় উল্লেখ করতে হবে। প্রতি ঘন্টায় আপডেট হওয়া একটি ড্যাশবোর্ড লাইভ কাউন্টার হিসেবে পড়া উচিত নয়। একটি ছোট লাইন যেমন "Refreshes every 60 minutes" খারাপ সিদ্ধান্ত ঠেকায়।

এখানে একটি সাপোর্ট অ্যাপের সরল উদাহরণ:

Metric name: First response rate
Formula: Number of new tickets that received a first reply within 4 business hours, divided by total new tickets in the period
Included: New customer tickets
Excluded: Spam, internal test tickets, and tickets created outside the support inbox
Time period: Previous calendar week, Monday to Sunday
Refresh timing: Every day at 8:00 AM
Sample calculation: 180 tickets received, 135 answered within 4 business hours. First response rate = 135 / 180 = 75%

যখন প্রতিটি মেট্রিক একই প্যাটার্ন অনুসরণ করে, বিশ্বাস দ্রুত বাড়ে। মানুষ সংখ্যার উপর তর্ক করা ছেড়ে ব্যবহার করতে শুরু করে।

প্রথম সংস্করণটি কিভাবে বানাবেন

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

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

একটি সহজ রোলআউট সাধারণত এমন দেখতে পারে:

1. ফর্ম, টেবিল, ফিল্টার, ড্যাশবোর্ড, এবং এক্সপোর্টেড রিপোর্ট থেকে সবচেয়ে বেশি ব্যবহৃত ফিল্ডগুলো টানুন।
2. সেলস, সাপোর্ট, অপারেশনস, এবং অ্যাপ বানানো লোকদের মধ্যে যে নামগুলো ব্যবহৃত হচ্ছে সেগুলো সংগ্রহ করুন।
3. সব ভার্সন এক ড্রাফটে রাখুন যাতে পার্থক্যগুলো দৃশ্যমান হয়।
4. একটি সংক্ষিপ্ত রিভিউ মিটিং করুন এবং প্রতিটি আইটেমের জন্য এক অনুমোদিত নাম, এক সাধারণ ভাষার সংজ্ঞা, এবং এক উদাহরণ নিয়ে বের হোন।
5. প্রতিটি এলাকার জন্য একটি মালিক নির্ধারণ করুন, যেমন কাস্টমার ডেটা, সাপোর্ট স্ট্যাটাস, বা ফাইন্যান্স মেট্রিক্স।

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

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

আপনার টিম যদি AppMaster-এ তৈরি করে, এসব নাম আগে থেকে স্থির করুন। AppMaster ব্যাকএন্ড, ওয়েব, এবং মোবাইল অংশ গজারেট করতে পারে, তাই একটি অস্পষ্ট টার্ম এক সময়েই ফর্ম, ব্যবসায়িক প্রক্রিয়া, এবং ড্যাশবোর্ডে ছড়িয়ে পড়তে পারে।

উদাহরণ: একটি সরল কাস্টমার সাপোর্ট ডিকশনারি

একটি ছোট ব্যবসায়িক শব্দকোষ টিমগুলোর অনেক বিভ্রান্তি দূর করতে পারে, বিশেষ করে সাপোর্ট কাজে যেখানে একই ফিল্ড সব জায়গায় দেখা যায়।

একটি ক্ষেত্র দিয়ে শুরু করুন যা পুরো অ্যাপে দেখা যায়: ticket_status. এই সঠিক নামটি ডাটাবেস, ফর্ম, ফিল্টার, ড্যাশবোর্ড, এবং হ্যান্ডঅফ নোটগুলোতে একরকম থাকা উচিত। যদি একটি স্ক্রিনে "Resolved" এবং অন্যটায় "Done" লেখা থাকে, মানুষ অনুমান করতে শুরু করবে।

একটি পরিষ্কার স্ট্যাটাস সেট এমন হতে পারে:

• Open: একটি নতুন টিকিট যা এখনও সাপোর্ট টিমের কাজ প্রয়োজন
• Waiting: দল উত্তর দিয়েছে বা কোনো কিছু দরকার যাতে তারা এগোতে পারে না
• Resolved: দল বিশ্বাস করে সমস্যা সমাধান করা হয়েছে এবং এই মুহূর্তে আর কোনো কাজ লাগবে না
• Closed: টিকিট শেষ হয়েছে এবং দৈনন্দিন কাজ থেকে সরানো হয়েছে

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

এখন একটি মেট্রিক যোগ করুন যা মানুষ প্রায়ই বিরোধ করে: first_response_time. এটিকে সংজ্ঞায়িত করুন টিকিট তৈরি হওয়া এবং সাপোর্ট টিমের প্রথম মানবিক উত্তর দেয়ার মধ্যে সময় হিসেবে। বিশ্বাসযোগ্য রাখার জন্য স্প্যাম, ডুপ্লিকেট, এবং টেস্ট টিকিট বাদ দিন। এছাড়াও নির্ধারণ করুন অটোমেটেড মেসেজ গণনায় ধরা হবে কিনা—অধিকাংশ টিমে এগুলো ধরা হয় না।

প্রায়রিটি এমনভাবে সহজ হওয়া উচিত যে কেউ একইভাবে নির্বাচন করতে পারে:

• High: গ্রাহক একটি গুরুত্বপূর্ণ ফিচার ব্যবহার করতে পারছে না
• Medium: কাজ ব্লক রয়েছে, কিন্তু একটি ওয়ার্কঅ্যারাউন্ড আছে
• Low: সাধারণ প্রশ্ন, ছোটখাটো সমস্যা, অথবা অনুরোধ

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

ড্রিফট ঘটায় সাধারণ ভুলগুলো

ভালো ডেটা ডিকশনারি হলেও টিমের প্রত্যাশার চেয়ে দ্রুত পুরনো হয়ে যেতে পারে। ড্রিফট সাধারণত ছোট পরিবর্তন দিয়ে শুরু হয় যা অনায়াস মনে হয়, তারপর দৈনন্দিন বিভ্রান্তিতে পরিণত হয়।

একটি সাধারণ সমস্যা হলো এমন লেবেল ব্যবহার করা যা কাছাকাছি শোনা যায় কিন্তু ভিন্ন অর্থ বহন করে। একটি সাপোর্ট টিম "Closed" ব্যবহার করতে পারে টিকিট শেষ বোঝাতে, আর অন্যজন একই ধারণার জন্য "Resolved" ব্যবহার করে। যদি উভয় রিপোর্টে দেখা যায়, মানুষ যে দেখছে তার উপর বিশ্বাস হারায়।

আরেকটি সমস্যা হল অর্ধেকভাবে সংজ্ঞায়িত ফর্মুলা রাখা। "active customers" মতো একটি মেট্রিক পরিষ্কার শোনায় যতক্ষণ না কেউ জিজ্ঞেস করে, "সদ্য ৭ দিনের, ৩০ দিনের, নাকি এই মাসে?" যদি ফর্মুলা, টাইম উইন্ডো, এবং বাদ দেওয়া বিষয় লেখা না থাকে, প্রতিটি ড্যাশবোর্ড মালিক হয়ত একরকমভাবে এটি হিসাব করবে।

এজ কেসগুলো সাধারণত বাদ পড়ে কারণ সেগুলো বিরল মনে হয়, কিন্তু বিরল কেসগুলোই প্রথমে মতামতভিন্নতার জন্ম দেয়। যদি বিক্রয়ের পরে ফেরত হয়, তাহলে সেটা মূল মাসের রাজস্ব মেট্রিক পরিবর্তন করে কি করে, কি বর্তমান মাসে গণ্য হবে? ডিকশনারিতে এক ছোট উদাহরণ দীর্ঘ তর্কবিতর্ক ঠেকায়।

একটি বাস্তব ভুল হলো অ্যাপে একটি নাম পরিবর্তন করা কিন্তু ডকুমেন্টে তা আপডেট না করা। যদি একজন বিল্ডার একটি ফিল্ডকে "Client Type" থেকে "Account Segment" এ আপডেট করে, ডিকশনারিতেও একই আপডেট অবশ্যই করা উচিত।

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

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

শেয়ার করার আগে রিভিউ করুন

ডকুমেন্টটি শেয়ার করার আগে একটি দ্রুত রিভিউ করুন। একটি ভাগ করা রেফারেন্স তখনই সাহায্য করে যখন মানুষ এটিকে একইভাবে পড়ে এবং সেটি থেকে একই সিদ্ধান্ত নিতে পারে।

শেয়ারের আগে এই পয়েন্টগুলো চেক করুন:

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

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

একটি সহজ নিয়ম সাহায্য করে: যদি একজন সহকর্মী ডকুমেন্ট খুলে সেটি মিটিং ছাড়াই ঠিকভাবে ব্যবহার করতে পারে, তাহলে এটি শেয়ার করার জন্য প্রস্তুত। না হলে অস্পষ্ট অংশগুলো আগে ঠিক করুন।

রোলআউটের পর এটি ব্যবহারযোগ্য রাখুন

একটি ডেটা ডিকশনারি টেমপ্লেট তখনই সহায়ক যখন মানুষ প্রথম খসড়ার পরে এটিকে ব্যবহার চালিয়ে দেয়। এটি করার সহজ পথ হল এটিকে একটি কাজের দলীয় ডকুমেন্ট হিসেবে বিবেচনা করা, এককালীন কাজ হিসেবে নয়।

প্রক্রিয়া পরিবর্তিত হলে এটি রিভিউ করুন। যদি আপনার সাপোর্ট টিম নতুন একটি টিকিট ধাপ যোগ করে, বা আপনার সেলস টিম যোগ্য লিড গণনার নিয়ম বদলে দেয়, সংজ্ঞা তাৎক্ষণিকভাবে আপডেট করুন। ছোট প্রক্রিয়া পরিবর্তনগুলি প্রায়ই পরে বড় রিপোর্টিং সমস্যা তৈরি করে।

নতুন প্রকল্পের প্রতিটো ক্ষেত্রে ডিকশনারি শুরু থেকেই অংশ করে নিন। যখন একটি টিম নতুন অ্যাপ, ড্যাশবোর্ড, বা রিপোর্ট শুরু করে, প্রথম কয়েকটি ফিল্ড নাম, স্ট্যাটাস, এবং মেট্রিকগুলো ডকুমেন্টে রাখুন যত দ্রুত সম্ভব।

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

যদি মানুষ বারবার জিজ্ঞেস করে, "এই ফিল্ডের মানে কী?" বা "কেন এই সংখ্যা ভিন্ন দেখায়?" তাহলে ডিকশনারিতে আপডেট দরকার। AppMaster-এ টিমগুলো দ্রুত তৈরির কারণে এটি বিশেষভাবে সত্য। পরিষ্কার নাম এবং সংজ্ঞা সেই গতি বিভ্রান্তিতে পরিণত হওয়া থেকে রক্ষা করে।