اگر در جلسهٔ سفارش نرم‌افزار، فروش، مالی و عملیات هر سه از «مشتری فعال» حرف می‌زنند ولی منظورشان یکی نیست، طراحی جدول و فرم را نباید شروع کرد. ابتدا باید تعریف مشترک داده‌ها روشن شود: هر اصطلاح به چه موجودیتی اشاره می‌کند، چه زمانی مقدار می‌گیرد، چه کسی آن را ثبت یا اصلاح می‌کند و کدام تصمیم به آن وابسته است. واژه‌نامهٔ داده برای نرم‌افزار سفارشی همین توافق قابل بازبینی را ثبت می‌کند. این سند جای تحلیل فرایند یا طراحی پایگاه داده را نمی‌گیرد؛ میان زبان کسب‌وکار و پیاده‌سازی فنی پل می‌زند.
نتیجهٔ عملی آن، یک فهرست بلند از نام فیلدها نیست. خروجی خوب به تیم اجازه می‌دهد دربارهٔ یک درخواست واقعی اختلاف‌ها را کشف کند، قواعد ورود داده را بنویسد، گزارش‌ها را قابل مقایسه کند و هنگام تغییر فرایند بداند کدام فرم یا اتصال باید بازنگری شود. در این راهنما، یک روش کوچک و اجرایی برای ساخت این واژه‌نامه پیش از توسعهٔ نرم‌افزار ارائه می‌شود.
واژه‌نامهٔ کسب‌وکار و فرهنگ فنی داده چه تفاوتی دارند؟
«مشتری» در زبان کسب‌وکار ممکن است شخص، سازمان طرف قرارداد، خریدار یک سفارش یا دریافت‌کنندهٔ خدمت باشد. واژه‌نامهٔ کسب‌وکار باید این مفاهیم و مرز آن‌ها را روشن کند. فرهنگ فنی داده، در مرحلهٔ بعد، نام ستون، نوع داده، ساختار و ارتباط اجزای ذخیره‌شده را توصیف می‌کند. در واژه‌نامهٔ رسمی Microsoft Purview، data dictionary به نام‌های استاندارد ستون‌ها و نوع آن‌ها اشاره دارد و business glossary فهرست اصطلاحات تخصصی سازمان است. این تمایز برای سفارش نرم‌افزار مهم است: انتخاب نوع ستون، اختلاف بر سر معنای «مشتری فعال» را حل نمی‌کند.
برای پروژهٔ سفارشی معمولاً بهتر است از تعریف کسب‌وکاری شروع کنید و سپس نگاشت فنی را به آن متصل کنید. ممکن است یک مفهوم در چند جدول یا چند سامانه حضور داشته باشد؛ ممکن است دو اصطلاح ظاهراً مشابه، به دلیل قانون کاری متفاوت، نباید در یک فیلد ادغام شوند. این تصمیم را توسعه‌دهنده نباید از روی نام ستون حدس بزند. مالک فرایند و مالک داده باید آن را تأیید کنند.
چه زمانی این کار ارزش دارد؟
وقتی چند واحد از یک داده استفاده می‌کنند، احتمال اختلاف معنا زیاد می‌شود. نشانه‌های عملی عبارت‌اند از گزارش‌هایی با عددهای ناسازگار، ورود دوبارهٔ اطلاعات در فرم‌های مختلف، اختلاف بر سر «آخرین وضعیت»، فیلدهای آزاد که هر کاربر شکل دیگری پر می‌کند و اتصال‌هایی که مدام نیاز به اصلاح نگاشت دارند. اگر نرم‌افزار قرار است فقط یک کار محدود و ساده را انجام دهد، واژه‌نامه هم می‌تواند کوچک باشد. هدف، ساخت سند حجیم برای همهٔ داده‌های سازمان نیست؛ هدف، رفع ابهام‌های مؤثر بر دامنهٔ همین پروژه است.
کار را روی موجودیت‌ها و تصمیم‌های اصلی شروع کنید: چه چیزی ثبت می‌شود، چه کسی دربارهٔ آن تصمیم می‌گیرد، چه خروجی یا گزارشی از آن ساخته می‌شود و چه سیستم دیگری باید آن را بفهمد. اگر درخواست توسعه هنوز در مرحلهٔ مقایسهٔ پیشنهادهاست، واژه‌نامهٔ اولیه را کنار چک‌لیست RFP نرم‌افزار سفارشی قرار دهید. به این ترتیب پیشنهاددهندگان دربارهٔ «همان» داده و قاعده قیمت و زمان می‌دهند، نه برداشت‌های متفاوت از یک عنوان مبهم.
از اصطلاحات تصمیم‌ساز شروع کنید، نه تمام فیلدها
یک فهرست اولیه از واژه‌هایی بسازید که تغییر تعریفشان نتیجهٔ کار را عوض می‌کند: وضعیت درخواست، مالک پرونده، تاریخ تعهد، مبلغ قابل پرداخت، کالای تحویل‌شده یا مشتری فعال. در جلسهٔ مشترک، برای هر اصطلاح یک نمونهٔ واقعی و یک مورد مرزی بیاورید. بپرسید آیا این مفهوم در همهٔ واحدها یکسان است؟ چه چیزی باعث ورود یا خروج یک رکورد از این دسته می‌شود؟ اگر پاسخ دو واحد متفاوت است، اختلاف را در سند نگه دارید تا تصمیم گرفته شود؛ با انتخاب یک نام زیبا آن را پنهان نکنید.
ترتیب مناسب چنین است: ابتدا اصطلاح و تعریف کسب‌وکاری، سپس رویدادی که مقدار را ایجاد یا تغییر می‌دهد، بعد منبع معتبر و مسئول تأیید، و سرانجام نمایش آن در فرم، گزارش و API. اگر از همان ابتدا با نام جدول شروع کنید، تیم ممکن است ساختار سامانهٔ قدیمی را بی‌دلیل به محصول جدید منتقل کند. گاهی یک ستون قدیمی چند معنا داشته و همان مسئله علت نیاز به نرم‌افزار جدید است.
برای هر داده چه چیزهایی ثبت کنیم؟
قالب ساده‌ای بسازید که هر سطر آن یک مفهوم قابل تصمیم‌گیری باشد. فیلدهای مفید شامل نام ترجیحی و نام‌های رایج دیگر، تعریف و موارد خارج از تعریف، مثال مثبت و منفی، مالک کسب‌وکار، منبع ثبت، لحظهٔ ایجاد و تغییر، قاعدهٔ اعتبارسنجی، حساسیت داده، مدت نگهداری موردنیاز و مصرف‌کننده‌های اصلی است. لازم نیست همهٔ ستون‌ها برای همهٔ اصطلاحات پر شوند؛ اما هر چیزی که بر مجوز، محاسبه یا گزارش اثر دارد باید صریح باشد.
برای «تاریخ تحویل»، تنها تعیین نوع date کافی نیست. روشن کنید منظور تاریخ وعده‌داده‌شده، تاریخ تحویل واقعی یا تاریخ تأیید دریافت است. اگر هر سه لازم‌اند، سه مفهوم جدا با رابطهٔ روشن تعریف کنید. مشخص کنید تقویم و منطقهٔ زمانی در ذخیره‌سازی و نمایش چگونه مدیریت می‌شوند و چه کسی مجاز به اصلاح تاریخ واقعی است. این دقت جلوی بحث‌های بعدی دربارهٔ «گزارش اشتباه» را می‌گیرد؛ بدون آنکه در این مرحله مجبور به تعیین نام نهایی ستون پایگاه داده باشید.
مثال عملی: «درخواست تکمیل‌شده» در یک سامانهٔ خدماتی
فرض کنید واحد عملیات، درخواست را وقتی کارشناس اقدام کرده «تکمیل‌شده» می‌داند؛ واحد پشتیبانی، وقتی مشتری نتیجه را تأیید کرده؛ و مدیر مالی، وقتی هزینهٔ مربوط ثبت شده است. یک فیلد بولی به نام completed نمی‌تواند بی‌دردسر هر سه تعریف را نمایندگی کند. در کارگاه واژه‌نامه، تیم باید سه رویداد مستقل را مشخص کند: پایان اقدام، تأیید نتیجه و تکمیل ثبت مالی. سپس می‌تواند تصمیم بگیرد چه وضعیتی به کاربر نمایش داده شود و هر گزارش بر کدام رویداد استوار باشد.
برای نمونه، گزارش زمان رسیدگی شاید از ثبت درخواست تا پایان اقدام را بسنجد، در حالی که گزارش رضایت به زمان تأیید مشتری مربوط باشد. اگر «تکمیل‌شده» بدون قاعده در همه‌جا به کار رود، دو گزارش ظاهراً دربارهٔ یک موضوع با اعداد مختلف تولید می‌شوند. واژه‌نامه به جای تحمیل یک تعریف به همه، تفاوت‌های واقعی فرایند را آشکار می‌کند. تصمیم دربارهٔ نام و تعداد وضعیت‌ها باید با صاحب فرایند گرفته شود؛ مثال حاضر نسخهٔ آماده برای همهٔ سازمان‌ها نیست.
منبع حقیقت و مالک تغییر را مشخص کنید
هر مفهوم مهم باید منبع معتبر داشته باشد. اگر اطلاعات مشتری هم در CRM و هم در نرم‌افزار جدید و هم در فایل اکسل اصلاح می‌شود، باید روشن باشد کدام سامانه صاحب هر فیلد است و اختلاف چگونه حل می‌شود. «همگام‌سازی دوطرفه» بدون قواعد مالکیت، مسئلهٔ ناسازگاری را به آینده منتقل می‌کند. در واژه‌نامه، برای هر دادهٔ مشترک بنویسید منبع اولیه کجاست، چه سامانه‌هایی نسخهٔ خواندنی دارند، چه زمانی تغییر مجاز است و چه رخدادی انتشار تغییر را آغاز می‌کند.
همچنین مالک تعریف را از اپراتور ثبت جدا کنید. کاربر ممکن است مقدار یک درخواست را وارد کند، اما حق تغییر معنای «درخواست فوری» را نداشته باشد. تغییر تعریف باید بررسی اثر داشته باشد: فرم، اعتبارسنجی، گزارش، اتصال و دادهٔ تاریخی چه می‌شوند؟ اگر برای دادهٔ قدیمی معنای جدیدی اعمال می‌کنید، باید آن را صریح و قابل آزمون کنید؛ نباید فقط برچسب گزارش را عوض کرد و وانمود کرد تاریخچه یکسان مانده است.
ارتباط واژه‌نامه با مهاجرت و اتصال سامانه‌ها
در مهاجرت، نگاشت «ستون قدیم به ستون جدید» کافی نیست. باید بدانید مقدار قدیمی در زمان ثبت چه معنایی داشته و آیا با تعریف تازه سازگار است. اگر نبود، سه گزینه دارید: تبدیل با قاعدهٔ قابل دفاع، نگه‌داشتن مقدار به‌عنوان تاریخچه با برچسب روشن، یا ارسال پرونده برای بازبینی انسانی. راهنمای اعتبارسنجی مهاجرت داده به کنترل صحت انتقال می‌پردازد؛ واژه‌نامه پیش‌نیاز فهمیدن این است که «صحت» دقیقاً به چه معناست.
در اتصال API نیز نام یکسان الزاماً معنای یکسان ندارد. دو سامانه شاید هر دو status داشته باشند ولی یکی «در انتظار بررسی» را شامل پروندهٔ ناقص بداند و دیگری نه. قرارداد اتصال باید جدول نگاشت وضعیت، مقدار نامعلوم، ترتیب رخدادها و رفتار هنگام خطا را مشخص کند. واژه‌نامه مرجع این قرارداد است، اما جای تست یکپارچگی را نمی‌گیرد.
از سند ثابت به قرارداد زنده برسید
واژه‌نامه اگر فقط در روز شروع پروژه نوشته شود، پس از نخستین تغییر فرایند کهنه می‌شود. برای هر اصطلاح شناسهٔ پایدار، نسخه، تاریخ تصمیم و مالک بررسی نگه دارید. تغییرات مهم باید همراه با اثرشان بر فرم‌ها، گزارش‌ها و دادهٔ موجود تصویب شوند. در خود نرم‌افزار، متن راهنمای فیلد و پیام اعتبارسنجی می‌توانند از همان تعریف مصوب الهام بگیرند؛ لازم نیست کاربر برای فهم اصطلاح به سند جداگانه مراجعه کند.
یک بازبینی کوتاه در پایان هر مرحلهٔ تحویل مفید است: آیا اصطلاح جدیدی وارد شده؟ آیا دو تیم هنوز برداشت متفاوت دارند؟ آیا داده‌ای در سیستم هست که مالک مشخصی ندارد؟ آیا گزارش تازه از تعریف مصوب استفاده می‌کند؟ اگر پاسخ مبهم است، آن را به عنوان تصمیم باز ثبت کنید. موفقیت واژه‌نامه به تعداد سطرهای آن نیست؛ به کم‌شدن تصمیم‌های حدسی در طراحی و بهره‌برداری است.
چک‌لیست پیش از شروع طراحی نرم‌افزار
پیش از تصویب مدل داده و رابط‌ها، مطمئن شوید برای مفاهیم کلیدی این پرسش‌ها پاسخ دارند: نام و تعریف واحد چیست؟ مورد مرزی کدام است؟ منبع معتبر کجاست؟ چه کسی مقدار را می‌نویسد و چه کسی تعریف را تغییر می‌دهد؟ کدام نقش‌ها می‌توانند آن را ببینند؟ حذف یا اصلاح آن چه اثری بر سابقه دارد؟ گزارش‌ها و اتصال‌ها کدام تعریف را مصرف می‌کنند؟ برای هر پرسش بی‌پاسخ، یک مالک و زمان تصمیم مشخص کنید. نبود پاسخ، مجوز حدس‌زدن پیمانکار نیست.
در پروژه‌های کوچک، یک جدول مشترک و چند نمونهٔ واقعی ممکن است کافی باشد. در پروژهٔ چندسامانه‌ای، نگاشت مفاهیم به فیلدها، نسخه‌ها و قوانین مالکیت نیز لازم می‌شود. اندازهٔ سند را از ریسک و پیچیدگی تعیین کنید، نه از قالب آماده. خدمت طراحی نرم‌افزار سفارشی ایزی‌ساز زمانی ارزشمندتر است که این تصمیم‌های دامنه‌ای پیش از ساخت فرم و API روشن شوند.
جمع‌بندی و اقدام بعدی
واژه‌نامهٔ داده، توافقی قابل آزمون دربارهٔ معنای اطلاعات پروژه است. از اصطلاحات اثرگذار بر تصمیم شروع کنید، موارد مرزی را با صاحب فرایند بررسی کنید، منبع حقیقت و مالک تغییر را مشخص کنید و سپس آن‌ها را به طراحی فنی نگاشت دهید. این کار هزینهٔ کشف اختلاف را به ابتدای پروژه منتقل می‌کند، جایی که اصلاح تعریف از اصلاح داده و گزارش پس از بهره‌برداری ساده‌تر است.
اگر در سفارش نرم‌افزار سفارشی هنوز چند واحد دربارهٔ وضعیت‌ها، نقش‌ها یا گزارش‌ها تعریف مشترک ندارند، نمونه‌ای از یک فرایند و سه اصطلاح مبهم را آماده کنید. برای بررسی دامنه و طراحی مسیر اجرا، از صفحهٔ تماس ایزی‌ساز درخواست گفت‌وگو ثبت کنید.