Amirali Yaghoutiمهندس ارشد نرم‌افزار

مطالعه موردی مهندسی

حضور و غیاب / دفتر اتوماسیون

داده‌ی حضور و غیاب همه‌جا جمع می‌شود و تقریباً هیچ‌جا استفاده نمی‌شود، چون رسیدن از یک لاگ خام به چیزی که یک مدیر بتواند روی‌ش اقدام کند چند مرحله‌ی دستی دارد که هیچ‌کس نمی‌خواهد مالکش باشد.

مسئله تجاری

سوابق حضور و عملیاتی وجود داشتند اما در فایل‌های ناسازگاری زندگی می‌کردند که کسی باید پیش از هر پرسشی تطبیقشان می‌داد. همین گزارش‌گیری مدیریتی روتین را آن‌قدر گران می‌کرد که به‌ندرت و ناهماهنگ اتفاق بیفتد، پس تصمیم‌ها بر اساس برداشت گرفته می‌شدند.

آنچه تحویل دادم

  • یک جریان اتوماسیون که داده‌ی حضور و عملیاتی را جمع می‌کند و بدون یک مرحله‌ی تطبیق دستی گزارش تولید می‌کند.
  • ورودی‌های نرمال‌شده، تا فایل‌هایی که با شکل‌های متفاوت از منابع متفاوت می‌رسند تبدیل به یک مجموعه‌داده‌ی یکدست شوند.
  • خروجی ساختاریافته برای یک خواننده‌ی کسب‌وکاری نه یک توسعه‌دهنده، چون کل نکته این است که مدیریت بتواند مستقیم استفاده‌اش کند.
  • اجراهای تکرارپذیر با لاگ، تا یک عدد در یک گزارش به اجرایی که تولیدش کرده ردیابی شود.

رویکرد فنی

  • نرمال‌سازی یک مرحله‌ی جدا و صریح است. بیشتر دشواری واقعی این نوع کار قالب‌های ورودی است، و قاطی‌کردنش با تحلیل هر دو را سخت‌تر می‌کند که تغییر کنند.
  • خروجی برای کسی طراحی شده که می‌خواندش، که معمولاً یعنی یک اسپردشیت نه یک داشبورد.
  • اجراها لاگ می‌شوند تا یک رقم مورد اختلاف بشود بررسی شود نه اینکه سرش بحث شود.
  • دامنه روی پرسش‌هایی که واقعاً پرسیده می‌شدند ماند، به‌جای ساختن زیرساخت گزارش‌گیری عمومی که نگهداری خودش را لازم داشت.

نتیجه و شواهد

گزارش‌گیری مدیریتی درباره‌ی حضور و عملیات تبدیل به خروجی روتین شد نه وظیفه‌ای که کسی باید به آن تخصیص داده می‌شد.

اهمیت برای کارفرما

گزارش‌گیری‌ای که تلاش می‌خواهد گزارش‌گیری‌ای است که متوقف می‌شود. حذف مراحل دستی همان چیزی است که باعث می‌شود در یک ماه شلوغ هم زنده بماند.

خلاصه-اجرایی-پروژه

خلاصه اجرایی خوانا

خلاصه_اجرایی {
  پروژه: "Attendance / Office Automation"
  پشته: "جریان داده‌ی پایتون"
  مراحل: "جمع‌آوری ← نرمال‌سازی ← گزارش، جداشده"
  خروجی: "شکل‌گرفته برای خواننده‌ی کسب‌وکاری، نه توسعه‌دهنده"
  ردیابی: "اجراها لاگ می‌شوند؛ یک رقم قابل ردیابی است"
  دامنه: "پرسش‌هایی که واقعاً پرسیده می‌شوند، نه یک پلتفرم"
}

ارزش حرفه‌ای این پروژه

قضاوت مفید اینجا محدودکردن دامنه به پرسش‌هایی بود که پرسیده می‌شدند. یک پلتفرم عمومی برای ساختن جذاب‌تر و برای استفاده‌شدن کم‌احتمال‌تر بود.

جداکردن نرمال‌سازی از تحلیل همان چیزی است که وقتی یک سیستم مبدأ قالب خروجی‌اش را عوض می‌کند — که همیشه می‌کند — آن را سرپا نگه می‌دارد.