تسجيل الوقت في تطبيق الأعمال: ماذا يعني البدء والإيقاف والاعتماد؟
قبل طلب تطوير ميزة لتسجيل الوقت، افصلوا بين ثلاثة قرارات: متى سُجل الوقت، وهل راجع أحد السجلات، وهل يمكن احتسابه على العميل. إيقاف المؤقت يجيب عن السؤال الأول فقط. ولا ينبغي أن يعني تلقائيًا اعتماد العمل أو السماح بإصدار فاتورة.
لفريق صغير، يمكن البدء بمؤقت وإدخال يدوي وحالة واضحة للسجل الجاري وطريقة لتصحيح الأخطاء. أضيفوا الإرسال للمراجعة والاعتماد حين يحتاجهما سير العمل فعلًا. ما يلي متطلبات تناقشونها مع المطور، وليس قواعد لحساب الرواتب أو وعدًا بأن منتجًا محددًا يوفر هذا المسار كاملًا.
ما الذي يمثله سجل الوقت؟
حددوا صاحب العمل والمهمة أو الطلب الذي يتعلق به السجل. قرروا إن كان الوصف إلزاميًا، وهل تكون فترات الاستراحة خارج السجل أم تظهر كخصومات صريحة منه. من دون ذلك، قد يسجل شخصان عملًا متشابهًا وفق قاعدتين مختلفتين.
افصلوا بين المدة المنقضية والمبلغ الذي سيُطلب من العميل. فقد يكون الاتفاق على سعر ثابت أو حد أدنى للفوترة أو ترتيب آخر. هذه الشروط التجارية لا تُستنتج من ساعة توقيت.
تقدم وثائق Toggl Track مثالًا موثقًا على هذا الفصل: تصف واجهة سجلات الوقت مدةً وحقولًا للبداية والتوقف، وحقلًا مستقلًا يبين إن كان السجل معلّمًا بأنه قابل للفوترة. هذا وصف لبنية البيانات، وليس دليلًا على أن السجل راجعه مسؤول أو وافق عليه العميل أو أُدرج في فاتورة.
المؤقت الجاري حالة محفوظة، وليس حركة على الشاشة فقط
ماذا يحدث إذا بدأ الموظف المؤقت على الهاتف ثم فتح الحساب نفسه على الحاسوب؟ ينبغي أن تعرض الشاشتان الحالة المحفوظة المتفق عليها. ولا يُفترض أن يعني إغلاق التطبيق إيقاف المؤقت، إلا إذا كان هذا السلوك غير المعتاد مقصودًا ومشروحًا بوضوح.
اختاروا قاعدة للتداخل بين السجلات. السماح بمؤقت واحد جارٍ لكل شخص خيار بسيط للنقاش، لكنه ليس شرطًا صالحًا لكل الأعمال. إذا سُمح بمؤقتات متزامنة، فاتفقوا على كيفية التمييز في التقارير بين الفترات المسجلة وإجمالي وقت عمل الشخص. لا تجمعوا الفترات المتداخلة ثم تسموا الناتج ساعات عمل فعلية من دون قاعدة واضحة لهذا الحساب.
بالنسبة إلى واجهة Toggl تحديدًا، تصف الوثائق السجلات الجارية بمدة سالبة. وتذكر أن حقل التوقف قد يكون خاليًا لسجل جارٍ، أو لسجل أُنشئ باستخدام حقلي duration وduronly. لذلك لا يكفي غياب وقت التوقف وحده لاستنتاج حالة العمل في جميع الحالات. على المطور تحويل تمثيل المزود الموثق إلى حالات واضحة داخل تطبيقكم.
عالجوا المؤقت المنسي من دون اختراع وقت نهاية
إذا استمر المؤقت طوال الليل، فالمطلوب تنبيه للمراجعة، لا تخمين موعد انتهاء العمل. حددوا متى يُعلّم السجل الطويل، ومن يتلقى التنبيه، وهل يُستبعد من الاعتماد حتى يُصحح. هذه العتبة قرار تشغيلي، وليست إثباتًا على أن كل عمل يتجاوزها غير صحيح.
إذا اقترح التطبيق تصحيحًا، فليظهر بصفته اقتراحًا. احتفظوا بالفترة المسجلة أصلًا وسبب التعديل المقبول وفق سياسة السجل التاريخي والاحتفاظ المتفق عليها. يجب أن يكون الفرق واضحًا بين ما التقطه المؤقت وما قبله المراجع لاحقًا.
ويحتاج الإدخال اليدوي إلى مسار واضح أيضًا. اسمحوا بتسجيل عمل أُنجز فعلًا حين ينسى الموظف تشغيل المؤقت، مع توضيح أن المدة أُدخلت يدويًا، لا الإيحاء بأنها قياس صادر عن مؤقت جارٍ.
صمموا المراجعة قبل إضافة زر الاعتماد
قد يتكون المسار البسيط من سجلات قابلة للتعديل، ثم فترة تُرسل للمراجعة، ثم نتيجة معتمدة. حددوا الانتقالات بين هذه الحالات بدل الاكتفاء بأسمائها:
- هل يمكن إرسال سجل ما زال جاريًا؟ إن لم يكن ذلك مسموحًا، فكيف يعالجه المستخدم؟
- هل يحق للمراجع تعديل السجل أم إعادته لصاحبه للتصحيح فقط؟
- هل يؤدي تعديل سجل أُرسل بالفعل إلى إعادة مراجعته؟
- هل يمكن إضافة سجل متأخر إلى فترة أُغلقت، ومن يقرر؟
- ماذا يحدث إذا أُغلق طلب العمل المرتبط بالسجل أو عُطل حساب الموظف؟
ينبغي أن يرتبط الاعتماد بمجموعة محددة من السجلات أو نسخها. وإلا فقد يتغير الإجمالي لاحقًا مع استمرار ظهور الاعتماد القديم. وعند الحاجة إلى تصحيح بعد التصدير أو إصدار الفاتورة، اتفقوا على طريقة لمطابقة التصحيح مع النظام المستقبِل بدل استبدال القيم التي تلقاها بصمت.
هذه ضوابط مقترحة للتطبيق المطلوب، وليست وصفًا لميزات المراجعة أو الفوترة في Toggl.
اختبروا قصة عمل صغيرة من البداية إلى النهاية
استخدموا موظفين وطلبات وهمية. شغلوا المؤقت على جهاز، وافتحوه من جهاز آخر، ثم أوقفوه وأجروا تصحيحًا يدويًا. أرسلوا الفترة للمراجعة، وأعيدوا سجلًا واحدًا للتعديل، ثم راجعوا النتيجة المصححة. تحققوا من توحيد أساس الوقت بين الشاشات، ومن أن منتصف الليل أو تغيير المنطقة الزمنية لا ينقل العمل إلى فترة تقرير غير متوقعة من دون توضيح.
لا تحتاجون إلى قاعدة بيانات اختبار ضخمة، بل إلى نتائج متوقعة وصريحة. أدرجوا الحالات التالية ضمن معايير قبول المشروع:
- يتبع بدء مؤقت ثانٍ قاعدة التداخل المختارة.
- لا يؤدي تكرار طلب الإيقاف إلى إنشاء سجل آخر أو زيادة المدة المسجلة.
- يظهر تنبيه للمؤقت المنسي من دون اختلاق ساعات عمل.
- تبقى السجلات اليدوية والمقاسة بالمؤقت قابلة للتمييز حيث يلزم.
- يمر تعديل العمل الذي روجع سابقًا بمسار التصحيح والمراجعة المتفق عليه.
- تبقى قابلية الفوترة والاعتماد والتصدير السابق مفاهيم منفصلة.
عند مناقشة تطبيق أعمال مخصص، أحضروا نموذجًا فارغًا لتقرير الوقت الذي تحتاجونه فعلًا. من يستخدم كل عمود، وما القرار الذي يتخذه بناءً عليه؟ هذه نقطة بداية أفضل من طلب مؤقت ثم اكتشاف قواعد الفوترة بعد تطويره.
المصدر وحدود الدليل
Toggl Track Engineering، سجلات الوقت: https://developers.track.toggl.com/docs/track/api/time_entries/
يدعم المصدر وصف الحقول وتمثيل السجل الجاري. أما اتساق الأجهزة والتداخل والتصحيحات وحدود الاعتماد فهي توصيات عملية لكتابة المتطلبات. تعتمد التزامات العمل والرواتب والاحتفاظ بالسجلات والفوترة التعاقدية على ظروف النشاط، وتحتاج إلى مشورة مختصة مناسبة. هذا المقال لا يثبت الامتثال القانوني.