ഷെഡ്യൂളിംഗ് ടൂളുകൾക്കായി ഷിഫ്റ്റ് സ്റ്റാറ്റസുകൾ രൂപകൽപ്പന ചെയ്യുമ്പോൾ
ഷിഫ്റ്റ് സ്റ്റാറ്റസുകൾ ലളിതമായിരിക്കുമെന്ന് ഞാൻ കരുതി. ഒരു ഷിഫ്റ്റ് കൺഫേംഡ് ആണ്. മറ്റൊന്ന് അല്ല. ഞാൻ തെറ്റിദ്ധരിച്ചു.
ഒരു സ്റ്റാറ്റസ് എന്നത് വെറുമൊരു കാർഡിലെ ലേബൽ മാത്രമല്ല. അത് പ്രോഡക്റ്റ് ലോജിക് നിയന്ത്രിക്കുന്നു. അടുത്തതായി സിസ്റ്റം എന്താണ് ചെയ്യേണ്ടതെന്ന് അത് തീരുമാനിക്കുന്നു.
'not confirmed' എന്ന പ്രയോഗത്തെക്കുറിച്ച് ചിന്തിച്ചുനോക്കൂ. അതിൽ ഒരുപാട് കാര്യങ്ങൾ ഒളിഞ്ഞിരിപ്പുണ്ട്. സ്റ്റാഫ് അംഗം ആ ഷിഫ്റ്റിനെക്കുറിച്ച് അറിയുന്നുണ്ടോ? അവർ 'ഇല്ല' എന്ന് പറഞ്ഞോ? നിങ്ങൾക്ക് പകരം ആരെങ്കിലും ആവശ്യമുണ്ടോ?
ആശയക്കുഴപ്പം ഒഴിവാക്കാൻ നിങ്ങൾക്ക് വ്യക്തമായ ഒരു മോഡൽ ആവശ്യമാണ്. ഈ അവസ്ഥകളെ (states) എങ്ങനെ വേർതിരിക്കാം എന്ന് താഴെ നൽകുന്നു:
- Assigned: ഒരാൾക്ക് ഷിഫ്റ്റ് നൽകിയിട്ടുണ്ട്.
- Waiting for confirmation: ആ വ്യക്തിക്ക് വിവരം അറിയാം, പക്ഷേ മറുപടി നൽകിയിട്ടില്ല.
- Confirmed: ആ വ്യക്തി സമ്മതിച്ചു.
- Needs cover: ആ വ്യക്തി നിരസിച്ചു (പകരം ആളെ ആവശ്യമുണ്ട്).
- Available to cover: മറ്റ് സ്റ്റാഫുകൾക്ക് ഈ ഒഴിവ് കാണാൻ സാധിക്കും.
- Cancelled: ആ ജോലി ഇല്ലാതായി.
'Assigned' എന്നത് 'Confirmed' എന്നതിൽ നിന്നും വ്യത്യസ്തമാണ്. എല്ലാവർക്കും ഷിഫ്റ്റുകൾ 'Assigned' ആകുമ്പോൾ ഷെഡ്യൂൾ പൂർണ്ണമാണെന്ന് തോന്നും. എന്നാൽ എല്ലാവരും 'Confirm' ചെയ്യുന്നത് വരെ അത് ഉറപ്പിക്കാൻ കഴിയില്ല. ഈ വ്യത്യാസം തിരിച്ചറിയുന്നത് അപ്രതീക്ഷിത ബുദ്ധിമുട്ടുകൾ ഒഴിവാക്കാൻ സഹായിക്കും.
'Needs cover' എന്നത് ഒരു പ്രത്യേക പ്രശ്നമാണ്. അത് 'unconfirmed' എന്നതിലല്ല. ഒന്ന് മറുപടിക്കായി കാത്തിരിക്കുക എന്നാണ് അർത്ഥമാക്കുന്നത്. മറ്റൊന്ന് പുതിയ ഒരാളെ കണ്ടെത്തുക എന്നാണ്. പ്രശ്നങ്ങൾ കൃത്യമായി നിർവചിച്ചാൽ അവയ്ക്ക് വേഗത്തിൽ പരിഹാരം കാണാൻ സാധിക്കും.
സ്റ്റാറ്റസ് ഡിസൈൻ എന്നത് പ്രോഡക്റ്റ് ഡിസൈൻ തന്നെയാണ്. അത് വർക്ക്ഫ്ലോയെ രൂപപ്പെടുത്തുന്നു. ഉപയോക്താക്കൾ എന്താണ് കാണേണ്ടതെന്ന് അത് തീരുമാനിക്കുന്നു. ഏതാണ് അടിയന്തിരം എന്ന് അത് നിങ്ങളെ അറിയിക്കുന്നു.
നിങ്ങളുടെ സ്റ്റാറ്റസുകൾ വ്യക്തമായി സൂക്ഷിക്കുക. നല്ലൊരു സ്റ്റാറ്റസ് അടുത്തതായി എന്ത് ചെയ്യണം എന്നത് വ്യക്തമാക്കുന്നു.
Source: https://dev.to/miran969/designing-shift-statuses-for-a-small-team-scheduling-tool-3bk5