ثبت ساعات کاری و درآمد از کجا به یک مشکل تبدیل شد؟
ماجرا از دوران دانشگاه شروع شد، وقتی در یک داروخانه مشغول به کار شدم. تا آن موقع دیده بودم بعضیها ساعت کاریشان را جایی برای خودشان ثبت میکنند، ولی هیچوقت فکر نمیکردم من هم روزی به چنین کاری نیاز پیدا کنم. شیفتها مشخص بود، محل کار سیستم حضور و غیاب داشت و هر وقت لازم میشد میتوانستم اطلاعاتش را در فیش حقوقیام ببینم. اما گاهی صاحب داروخانه از من میپرسید هفتهی قبل دقیقاً چه ساعتهایی کار کردهام. همان سؤال ساده، ثبت ساعات کاری را برایم به مسئله تبدیل کرد: وقتی همهچیز در سیستم ثبت میشود، چرا باز هم باید از خودم بپرسد؟
یکی از اینترنهای داروسازی که آنجا کار میکرد میگفت خودش همیشه شیفتهایش را جداگانه یک جایی یادداشت میکند. حرفش منطقی بود. سیستم محل کار برای نیاز کارفرما ساخته شده بود، نه برای اینکه من هر لحظه سابقهی خودم را ببینم، اشتباه احتمالی در حسابداری را پیدا کنم یا بفهمم تا اینجای دورهی پرداخت چند ساعت کار کردهام. اول کار مسئله خیلی ساده بود؛ فقط نمیخواستم ساعت شروع و پایان شیفتهایم یادم برود.
اگر فقط دنبال راهی برای ثبت ساعات کاری باشید، ابزارهای آماده کم نیستند؛ تقویم، اکسل و اپلیکیشنهای تایمشیت هرکدام بخش بزرگی از این نیاز را پوشش میدهند. مسئلهی من هم از همانجا شروع شد، اما کمکم به محاسبهی درآمد بر اساس نرخهای مختلف و نگهداشتن تاریخچهی محاسبات رسید و نهایتاً به ساخت WorkLog ختم شد.
راهحل اول: Google Calendar
اولین چیزی که امتحان کردم Google Calendar بود. انتخاب بدی هم نبود. روی کامپیوتر و موبایل در دسترس بود و بهراحتی میشد شیفتها را همانجا ثبت کرد. مزیتش هم این بود که شیفتها کنار بقیهی برنامههای روزانهام دیده میشدند و تصویر کلیتری از زمانم داشتم.
برای پاسخ به این سؤال که هفتهی گذشته چه روزهایی کار کردهام، تقویم کافی بود؛ فقط باید به روزهای قبل برمیگشتم و رویدادها را میدیدم. اما کمکم سؤالهای دیگری هم پیش آمد:
- این هفته چند ساعت کار کردهام؟
- در یک ماه گذشته چند ساعت کار کردهام؟
- درآمدم بر اساس این ساعات چقدر بوده؟
تقویم برای نشان دادن زمان و رویدادها خوب است، اما برای محاسبهی درآمد و ثبت دقیق ساعات کاری ابزار کارآمدی نیست. میشد هر بار شیفتها را دستی جمع بزنم و درآمد را حساب کنم، ولی نه سریع بود و نه بهینه.
وقتی ثبت ساعات کاری بهتنهایی کافی نبود: ورود Excel
قدم بعدی که منطقی به نظر میرسید، Microsoft Excel بود. هر ردیف نمایانگر یک شیفت شد: تاریخ، ساعت شروع، ساعت پایان، مدت استراحت، مجموع ساعت کار و درآمد تخمینی. با چند فرمول ساده توانستم این محاسبات را خودکار کنم و به سؤالهایی برسم که تقویم جوابشان را نمیداد. نسبت به تقویم پیشرفت بزرگی بود. حالا هم شیفتها ثبت میشدند، هم هر وقت میخواستم میدیدمشان و هم نمایی کلی از درآمدم در بازههای مختلف داشتم.
برای مدتی اکسل دقیقاً همان چیزی بود که نیاز داشتم. اما با گذشت زمان، انتظاراتم بیشتر شد و نگهداری فایل سختتر. هر قابلیت جدید یا تغییر در ساختار، ممکن بود دادههای قبلی را به خطر بیندازد. برخلاف تقویم گوگل، ثبت شیفت از موبایل هم چندان راحت نبود. کمکم فایل اکسلم شکل یک برنامه را به خودش گرفته بود، بدون اینکه تجربهی کاربری، اعتبارسنجی ورودی یا فرم درستوحسابی داشته باشد. طبیعی بود که به فکر راهحل بعدی بیفتم.
راهحل دوم برای ثبت ساعات کاری: نرمافزارهای آمادهی تایمشیت
بعد از کمی جستوجو، فهمیدم برای ثبت شیفت و ساعات کاری ابزارهای زیادی وجود دارد. اپلیکیشنهایی مثل Work Log و Salarybook مخصوص ثبت شیفت و تخمین حقوق هستند. این برنامهها امکاناتی مثل ثبت شروع و پایان شیفت، زمان استراحت، دورهی پرداخت و اضافهکاری را پوشش میدهند؛ بعضی از قابلیتهای خروجی، چندشغله بودن یا پشتیبانگیری نیز به نسخه و طرح انتخابی بستگی دارند.
ابزارهایی مثل Clockify و My Hours گستردهترند و ثبت زمان روی وب و موبایل، نرخ ساعتی و گزارشگیری را پوشش میدهند. هرچند منطق اصلی آنها بیشتر حول پروژه، مشتری و تیم کاری شکل گرفته است تا شیفتکاری فردی. سامانههایی مثل Deputy هم برنامهریزی شیفت، تایمشیت، استراحت و ارتباط با فرایند حقوق و دستمزد را پوشش میدهند، حتی وقتی قواعد پرداخت پیچیدهتر میشوند.
ابزار برای حل مسئله وجود داشت؛ فقط هیچکدام کاملاً با چیزی که میخواستم جور درنمیآمد. نمیتوانم بگویم ابزار مناسبی وجود نداشت. مسئله این بود که هیچکدام دقیقاً با نیاز و ترجیحهای من همخوانی نداشت.
چرا ابزارهای موجود پاسخ مناسبی نبودند؟
مدتی از Work Log روی موبایل استفاده کردم و برای نیازهایم نسبتاً خوب بود. اما برای ثبت بیش از چند شغل به اشتراک پرمیوم نیاز داشت و آن زمان فقط روی موبایل در دسترس بود. برایم مهم بود که از دستگاههای مختلف به اطلاعاتم دسترسی داشته باشم.
سرویسهایی مثل Clockify تحت وب هستند و از دستگاههای مختلف میتوان به آنها دسترسی داشت، اما دسترسی به داده تنها چیزی نبود که میخواستم. دلم میخواست روی نحوهی محاسبهی درآمد و تاریخچهاش کنترل بیشتری داشته باشم. نمیخواستم فقط عدد نهایی یک شیفت را ببینم؛ میخواستم بدانم آن عدد چطور به دست آمده است. همچنین نمیخواستم تغییر نرخ ساعتی امروز، درآمد شیفتهای قبلی را بیسروصدا عوض کند.
ابزارهایی مثل Clockify برای تغییر نرخ و تأثیرش روی رکوردهای قبلی رفتار مشخصی دارند، ولی ترجیح میدادم منطق این رفتار دست خودم باشد. گزارشهایی هم که میخواستم پیچیده نبودند:
- در یک بازهی زمانی چند شیفت کار کردهام؟
- مجموع ساعات کاری چقدر بوده؟
- درآمد ناخالص چقدر بوده؟
- اگر چند شغل داشته باشم، سهم هرکدام از ساعت و درآمد چقدر است؟
بیشتر ابزارهای آماده چنین گزارشهایی دارند، اما برخی برای پروژه و مشتری ساخته شدهاند و برخی برای تایمشیت سازمانی. من چیزی میخواستم که مستقیماً حول شغل و شیفتهای خودم شکل گرفته باشد.
نیاز واقعی یا ترجیح شخصی؟
کمکم ایدههایی برای آینده هم داشتم؛ مثل برنامهریزی شیفت و مقایسهی درآمد محاسبهشده با فیش حقوقی یا تراکنش بانکی. اینها هنوز در WorkLog کامل نشدهاند و نمیشود آنها را برتری نسخهی فعلی دانست، اما امکان توسعه در آینده برایم مهم بود.
همهی خواستههایم هم نیاز واقعی نبودند. بعضی صرفاً ترجیح شخصی بودند، مثل اینکه نام فیلدها یا شکل گزارشها دقیقاً مطابق سلیقهام باشد. این تفاوت مهم است، چون چیزی که برای من ضروری به نظر میرسد ممکن است برای بیشتر کاربران اهمیتی نداشته باشد.
چندکاربره بودن هم برای استفادهی شخصی ضروری نبود، ولی از ابتدا در معماری در نظرش گرفتم تا اگر روزی کاربر دیگری اضافه شد، مجبور به تغییر ساختار نباشم. فعلاً خودم تنها کاربر جدی WorkLogام و چند نفر از دوستانم فقط برای آزمایش چند شیفت در آن ثبت کردهاند.
در نهایت، ابزارهای آماده بخش بزرگی از مسئله را حل میکردند. دلیل ساخت WorkLog این نبود که هیچ نرمافزاری توانایی ثبت ساعات کاری یا محاسبهی درآمد را نداشت. دلیلش ترکیبی بود از دسترسی تحت وب، کنترل بیشتر روی محاسبات و تاریخچه، گزارشهای متناسب با نیاز خودم و امکان توسعه در آینده.
آیا ساخت نرمافزار اختصاصی منطقی بود؟
اگر WorkLog را فقط ابزاری برای ثبت ساعات کاری در نظر بگیرم، جواب احتمالاً «نه» است. یک اپلیکیشن آماده یا حتی همان اکسل میتوانست بخش اصلی نیازم را برطرف کند. ساختن یک وباپلیکیشن فقط چند فرم و جدول نیست؛ احراز هویت، جداسازی دادهی کاربران، اعتبارسنجی ورودی، منطق زمان و استراحت، محاسبهی نرخها، تست، استقرار، بکاپ و نگهداری هم همراهش میآید. وقتی نرمافزار را خودت ساختهای، اگر چیزی خراب شود یا محاسبهای اشتباه باشد، خودت باید مشکل را پیدا کنی. ادامه دادن با اکسل یا خرید اشتراک یک سرویس آماده تقریباً همیشه ارزانتر و سریعتر است.
اما WorkLog برایم کمکم فقط یک ابزار مصرفی نبود؛ به یک پروژهی مهندسی با مسئله، داده و استفادهی واقعی تبدیل شد. میخواستم قواعد پرداخت را مدل کنم، بفهمم هر عدد دقیقاً از کجا آمده و با استفادهی روزمره سیستم را بهتر کنم. اگر فرم ثبت شیفت آزاردهنده بود، خودم فردا دوباره مجبور بودم از همان فرم استفاده کنم. اگر محاسبهی درآمد اشتباه بود، عددی که خودم به آن تکیه میکردم هم اشتباه میشد. مشکلات پروژه خیلی زود از یک باگ فرضی به چیزی تبدیل میشدند که واقعاً روی زندگی روزمرهام اثر داشت.
پس اگر فقط ثبت شیفت، استراحت و تخمین حقوق را میخواستم، ابزار آماده انتخاب منطقیتری بود. اما اگر WorkLog را هم ابزار شخصی و هم یک پروژهی مهندسی واقعی در نظر بگیرم، ساختنش برایم منطقیتر میشد.
تولد WorkLog: از ثبت شخصی تا وباپلیکیشن
دامنهی نسخهی اول عمداً محدود بود: تعریف شغل، ثبت شیفت و محاسبهی درآمد. اما حتی پشت همین سه قابلیت هم چند تصمیم مهم بود. دردسر واردکردن اطلاعات در سلولهای اکسل جای خودش را به یک فرم مخصوص ثبت شیفت داد. هر شیفت ساعت شروع و پایان، شغل و استراحت با حقوق یا بدون حقوق دارد. برنامه ورودیها را بررسی میکند و نتیجهی محاسبه را کنار همان شیفت نگه میدارد؛ دیگر لازم نبود بین سلولها و فرمولها بگردم تا بفهمم چه چیزی ثبت کردهام.
چند شغل با نرخهای مختلف هم به بخشی جداگانه برای تعریف «شغل» تبدیل شد. هر شغل نام، نرخ پایه و دورهی پرداخت خودش را دارد. در گزارشها میتوانم برای یک بازهی زمانی و یک یا چند شغل ببینم چند شیفت کار کردهام، مجموع ساعات چقدر بوده و درآمد ناخالص محاسبهشده چقدر است؛ همان سؤالهایی که Google Calendar در ابتدا مستقیماً جوابشان را نمیداد.
طراحی محاسبهی درآمد
در سادهترین حالت: ساعت کار × نرخ ساعتی = درآمد. اما دنیای واقعی همیشه اینقدر ساده نیست. بخشی از یک شیفت ممکن است با نرخ پایه و بخش دیگر با ضریبی متفاوت حساب شود. یک قاعده شاید فقط در روزها و ساعتهای خاص فعال باشد، یا چند قاعده در یک بازه همپوشانی داشته باشند.
در WorkLog میتوان برای هر شغل مشخص کرد یک قاعده در چه روزها و ساعتهایی فعال باشد، چه ضریبی اعمال کند و اگر چند قاعده همزمان فعال شدند کدامیک اولویت دارد. اگر یک شیفت از چند بازه عبور کند، سرور آن را به چند قطعهی محاسباتی تقسیم میکند و مبلغ هر قسمت را جداگانه حساب میکند.
سؤال دیگری هم بود: اگر امروز نرخ یک شغل را تغییر بدهم، چه اتفاقی برای شیفتهای قبلی میافتد؟ نمیخواستم با تغییر نرخ امروز، درآمد شیفتی که ماهها قبل کار کرده بودم بیسروصدا عوض شود. برای همین سرور محاسبه را انجام میدهد و برای هر بخش، نرخ پایه، ضریب، نرخ نهایی، مبلغ، زمان محاسبه و نسخهی الگوریتم را ذخیره میکند. اگر امروز نرخ را تغییر بدهم، درآمد شیفتهای قبلی همان چیزی میماند که در همان لحظه محاسبه شده بود. اگر خود شیفت را ویرایش کنم، برنامه محاسبهی جدیدی میسازد و سابقهی قبلی را هم نگه میدارد. ساختن چنین رفتاری در اکسل غیرممکن نیست، اما دیگر با چند فرمول ساده حل نمیشود.
انتخاب فناوری
نیاز به دسترسی از چند دستگاه، WorkLog را به یک وباپلیکیشن تبدیل کرد. بخش سرور را با PHP و CodeIgniter ساختم، چون هم با آنها آشنا بودم و هم هاست PHP داشتم. رابط کاربری را با Vue ساختم و دادهها را در MySQL نگه داشتم. جزئیات معماری میتواند موضوع مقالهای جداگانه باشد. چیزی که اینجا اهمیت دارد این است که این انتخابها از نیاز و محدودیت واقعی پروژه آمدند، نه از میل به امتحان یک تکنولوژی جدید.
اگر خود سازوکار وب برایتان مبهم است، مطلب «وب چیست و چطور کار میکند؟» مقدمهی سادهتری برای آشنایی با وب، مرورگر و سرور است.
چندکاربره بودن هم از همان ابتدا وارد معماری شد؛ نه چون WorkLog کاربر زیادی داشت، بلکه چون فکر میکردم اضافه کردن هویت کاربران و مالکیت داده در آینده ممکن است ساختار را به هم بریزد. این تصمیم هزینهی خودش را داشت: ثبتنام، ورود، توکن و کنترل دسترسی همه وارد پروژه شدند. هنوز هم میتوانم از خودم بپرسم آیا این پیچیدگی از همان اول واقعاً ارزشش را داشت یا نه.
بهبود تجربهی کاربری
با آماده شدن قابلیتهای اصلی، ماجرا تمام نشد. رابط اولیه از نظر فنی کار میکرد، اما برای ثبت سریع شیفت چندان راحت نبود. یکی از تغییرهای کوچک اما مؤثر این بود که تاریخ پایان شیفت بهطور پیشفرض همان تاریخ شروع باشد، مگر اینکه خودم عوضش کنم. روی کاغذ تغییر کوچکی است، ولی وقتی مرتب از یک برنامه استفاده میکنید، همین چند کلیک اضافه خیلی زود آزاردهنده میشود. این دقیقاً یکی از مزیتهای ساختن ابزاری بود که خودم واقعاً از آن استفاده میکردم. مشکلاتی که در طراحی اولیه دیده نمیشدند، در استفادهی روزمره خیلی سریع خودشان را نشان میدادند.
قابلیتهایی مثل برنامهریزی شیفتهای آینده، تطبیق محاسبات با فیش حقوقی، تطبیق با تراکنشهای بانکی، بازیابی رمز عبور، بهبودهای امنیتی و بهبود رابط کاربری هنوز در فهرست کارهای آیندهی WorkLog هستند. قابلگسترش بودن معماری به این معنی نیست که همهی این قابلیتها همین حالا وجود دارند.
بعد از ساخت WorkLog چه یاد گرفتم؟
مهمترین چیزی که یاد گرفتم این بود که هر مسئلهی واقعی به نرمافزار اختصاصی نیاز ندارد. Google Calendar برای نگهداشتن سابقهی شیفتها خوب بود، اکسل محاسبات و گزارش اولیه را انجام میداد و Work Log هم بخش بزرگی از نیازم را بدون دردسر ساخت نرمافزار پوشش میداد. اینکه در نهایت WorkLog را ساختم به این معنی نیست که راهحلهای قبلی اشتباه بودند؛ هرکدام تا یک مرحله دقیقاً همان چیزی بودند که نیاز داشتم.
اکسل هم هیچوقت ابزار بدی نبود؛ فقط ممکن است مسئلهی شما کمکم از محدودهای که یک صفحهگسترده برایش مناسب است خارج شود. یک جدول با چند فرمول برای خیلی از کارها کاملاً کافی است. اما وقتی تاریخچهی محاسبات، چند نرخ مختلف، اعتبارسنجی ورودی، دسترسی از چند دستگاه و کنترل دسترسی به آن اضافه شود، دیگر با یک فایل ساده طرف نیستید.
چرا ثبت ساعات کاری از یک فرمول ساده پیچیدهتر میشود؟
قواعد دنیای واقعی خیلی زود جملهی سادهی «ساعت را در نرخ ساعتی ضرب کن» را پیچیده میکنند. استراحت، تغییر نرخ، بازههای زمانی مختلف، شیفت شب و ویرایش اطلاعات قدیمی، هرکدام باید به رفتاری مشخص در برنامه تبدیل شوند. حتی سؤالی به سادگی «اگر نرخ را امروز عوض کنم، شیفت ماه قبل چه میشود؟» دیگر فقط یک فرمول ریاضی نیست؛ تصمیمی دربارهی رفتار نرمافزار است.
صحت محاسبه هم فقط این نیست که عدد نهایی امروز درست باشد. باید بتوانی بفهمی هر عدد از کجا آمده و مطمئن باشی فردا با تغییر یک تنظیم خودبهخود عوض نمیشود. برای همین نگهداشتن جزئیات محاسبه، نرخهای همان لحظه و نسخهی الگوریتم اهمیت پیدا کرد.
و شاید مهمتر از همه، تفاوت یک MVP که فقط «کار میکند» با ابزاری که هر روز واقعاً از آن استفاده میکنید، دقیقاً همینجا مشخص میشود. یک MVP میتواند شیفت را ثبت کند، مبلغ را حساب کند و از نظر فنی درست کار کند. اما استفادهی مداوم چیزهای دیگری هم میخواهد: وارد کردن سریع اطلاعات، خطای قابلفهم، تاریخچهی روشن، تست، بکاپ و استقرار قابلتکرار. حتی چیزی به کوچکی پیشفرض بودن تاریخ پایان شیفت، از دل استفادهی روزمره بیرون آمد، نه از فهرست اولیهی قابلیتها.
اگر دوباره از اول شروع میکردم
قبل از نوشتن کد، نیازهایم را به سه دسته تقسیم میکردم: چیزهایی که واقعاً ضروریاند، چیزهایی که داشتنشان خوب است و چیزهایی که صرفاً ترجیح شخصی هستند. بعد دو سه ابزار آماده را با دادهی واقعی خودم امتحان میکردم تا دقیقاً بفهمم کجا به محدودیت میرسم. احتمالاً MVP را هم کوچکتر نگه میداشتم. قابلیتهایی مثل برنامهریزی شیفت و تطبیق بانکی را تا وقتی دربارهشان تحقیق نکرده بودم، وارد برنامهی توسعه نمیکردم. چون یکی از چیزهایی که WorkLog به من یاد داد این بود: «میتوانم این را بسازم» هنوز جواب سؤال «آیا باید این را بسازم؟» نیست.
جمعبندی: آیا ساخت WorkLog ارزشش را داشت؟
WorkLog از یک ایدهی بزرگ شروع نشد؛ از یک سؤال ساده شروع شد: هفتهی قبل دقیقاً چه ساعتهایی کار کردم؟ Google Calendar جواب اولیه را داد. بعد سؤال به مجموع ساعات کاری و درآمد رسید و اکسل وارد شد. وقتی نیازها و محاسبات بیشتر شدند، همان فایل اکسل هم کمکم شکل یک نرمافزار دستساز را به خودش گرفت. بعد سراغ ابزارهای آماده رفتم و فهمیدم بیشتر چیزی که میخواهم از قبل وجود دارد. بااینحال، ترکیبی از دسترسی تحت وب، کنترل روی دادهها و محاسبات، نگهداشتن تاریخچه و آزادی برای توسعهی آینده باعث شد مسیر دیگری را امتحان کنم.
اگر ساخت WorkLog را فقط برای صرفهجویی در زمان در نظر بگیرم، جواب «نه» است. اگر فقط میخواستم ثبت ساعات کاری و تخمین درآمد را انجام بدهم، یک برنامهی آماده احتمالاً انتخاب بهتری بود. ارزش WorkLog برای من جای دیگری بود: این پروژه مسئلهای واقعی به من داد که باید دقیق مدلش میکردم و نتیجهی تصمیمهایم را در استفادهی روزمره میدیدم. در کنارش ابزاری هم ساختم که واقعاً از آن استفاده میکنم و میدانم عددهایی که نشانم میدهد چطور به دست آمدهاند.
پس اگر WorkLog را فقط جایگزین ارزانتر یک تایمشیت آماده در نظر بگیرم، احتمالاً ساختنش ارزش زمانی را که برایش گذاشتم نداشت. اما بهعنوان ترکیبی از یک ابزار شخصی و یک پروژهی مهندسی واقعی، برایم ارزشش را داشت. مهم این است که این دو دلیل را با هم اشتباه نگیریم.