शेड्यूलिंग टूल्स के लिए शिफ्ट स्टेटस डिज़ाइन करना

मुझे लगा था कि शिफ्ट स्टेटस सरल होंगे। एक शिफ्ट कन्फर्म है। एक शिफ्ट नहीं है। मैं गलत था।

स्टेटस केवल कार्ड पर लगा एक लेबल नहीं है। यह प्रोडक्ट लॉजिक (product logic) को संचालित करता है। यह सिस्टम को बताता है कि आगे क्या करना है।

"not confirmed" वाक्यांश के बारे में सोचें। यह बहुत सारी बारीकियों को छिपा देता है। क्या स्टाफ सदस्य को शिफ्ट के बारे में पता है? क्या उन्होंने मना कर दिया? क्या आपको किसी रिप्लेसमेंट की ज़रूरत है?

भ्रम से बचने के लिए आपको एक स्पष्ट मॉडल की आवश्यकता है। इन स्थितियों (states) को अलग करने का तरीका यहाँ दिया गया है:

  • Assigned: एक व्यक्ति को शिफ्ट दे दी गई है।
  • Waiting for confirmation: व्यक्ति को पता है लेकिन उसने जवाब नहीं दिया है।
  • Confirmed: व्यक्ति ने हाँ कह दिया है।
  • Needs cover: व्यक्ति ने मना कर दिया है।
  • Available to cover: अन्य स्टाफ खाली जगह देख सकते हैं।
  • Cancelled: काम रद्द हो गया है।

Assigned, Confirmed से अलग है। जब सभी को Assigned कर दिया जाता है, तो शेड्यूल भरा हुआ लगता है। जब तक हर कोई कन्फर्म नहीं कर देता, तब तक यह तय नहीं होता। यह अंतर आपको अनपेक्षित स्थितियों से बचाता है।

Needs cover एक विशिष्ट समस्या है। यह unconfirmed के समान नहीं है। एक का अर्थ है जवाब का इंतज़ार करना। दूसरे का अर्थ है एक नए व्यक्ति को ढूँढना। विशिष्ट समस्याओं के समाधान तेज़ी से मिलते हैं।

स्टेटस डिज़ाइन ही प्रोडक्ट डिज़ाइन है। यह वर्कफ़्लो (workflow) को आकार देता है। यह तय करता है कि यूज़र्स क्या देखते हैं। यह आपको बताता है कि क्या ज़रूरी है।

अपने स्टेटस को स्पष्ट रखें। एक अच्छा स्टेटस अगले कदम को स्पष्ट बना देता है।

स्रोत: https://dev.to/miran969/designing-shift-statuses-for-a-small-team-scheduling-tool-3bk5