ਇੱਕ ਮੋਬਾਈਲ ਐਪ ਦੀ ਯੋਜਨਾ, ਡਿਜ਼ਾਈਨ ਅਤੇ ਬਣਾਉਟ ਕਰੋ ਜੋ ਸੇਵਾਦਾਰਾਂ ਨੂੰ ਸ਼ਿਫਟਾਂ ਵਿੱਚ ਵਿਵਸਥਿਤ ਕਰੇ, ਸਾਈਨਅਪ ਅਤੇ ਯਾਦਦਿਹਾਨੀਆਂ ਹਲ ਕਰੇ, ਹਾਜ਼ਰੀ ਟਰੈਕ ਕਰੇ, ਅਤੇ ਐਡਮਿਨ/ਕੋਆਰਡੀਨੇਟਰ ਨੂੰ ਸਹਿਯੋਗ ਦਵੇ।
ਸੇਵਾਦਾਰ ਸੰਯੋਜਨ ਅਕਸਰ ਪੂਰੇ ਤਰੀਕੇ ਨਾਲ ਟੁੱਟ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਆਮ ਤੌਰ 'ਤੇ ਨੋ-ਸ਼ੋ, ਆਖਰੀ-ਮਿੰਟ ਖਾਲੀ ਪਦ, ਅਤੇ “ਇਸ ਸ਼ਿਫਟ 'ਤੇ ਸਚਮੁਚ ਕੌਣ ਹੈ?” ਵਾਲੀ ਗੁੰਝਲਦਾਰ ਜਾਣਕਾਰੀ ਟੈਕਸਟ, ਈਮੇਲ ਤੰਤਰ ਅਤੇ ਗੰਦਲੇ spreadsheet ਜਾਦੇ ਫੈਲ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਚੰਗੀ ਐਪ ਸਿਰਫ਼ ਇੱਕ ਸੁੰਦਰ ਕੈਲੇੰਡਰ ਨਹੀਂ—ਇਹ ਅਣਛੁੱਟੇ ਬੇਹਰਤੀਨ ਸਕਰਮ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ, ਕਰੰਟ ਅਪਡੇਟ ਤੁਰੰਤ ਦਿਖਾਉਂਦੀ ਹੈ, ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀ ਸਪੱਸ਼ਟ ਕਰਦੀ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਕੁਝ ਆਮ ਮੁੱਦਿਆਂ ਨਾਲ ਜੂਝਦੀਆਂ ਹਨ:
ਇੱਕ ਸੇਵਾਦਾਰ ਸੰਯੋਜਨ ਐਪ ਮਦਦ ਕਰਦਾ ਹੈ:
ਸੇਵਾਦਾਰਾਂ ਲਈ ਵੀ ਫਾਇਦਾ: ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਵੇਖ ਸਕਦੇ ਹਨ ਕਿ ਉਹ ਕਿਸ ਲਈ ਸਾਈਨ ਅਪ ਕੀਤੇ ਹਨ, ਕੀ ਉਪਲਬਧ ਹੈ, ਅਤੇ ਕਿੱਥੇ ਹੋਣਾ ਹੈ—ਪੁਰਾਣੇ ਸੁਨੇਹਿਆਂ ਵਿਚੋਂ ਖੋਜ ਕਰਨ ਦੇ ਬਗੈਰ।
ਸਫ਼ਲਤਾ ਮਾਪਯੋਗ ਹੈ:
ਸ਼ੁਰੂ ਕਰੋ ਸਕੇਜੂਲਿੰਗ + ਸੰਚਾਰ ਨਾਲ: ਸ਼ਿਫਟ ਪੋਸਟ ਕਰਨਾ, ਉਹਨਾਂ ਨੂੰ ਕਲੈਮ ਕਰਨਾ, ਰਿਮਾਈਂਡਰ, ਅਤੇ ਜਦੋਂ ਯੋਜਨਾਵਾਂ ਬਦਲਦੀਆਂ ਹਨ ਤਾਂ ਛੇਤੀ ਅਪਡੇਟ। ਵਾਧੂਆਂ (ਦਾਨ ਟਰੈਕਿੰਗ, ਟਰੇਨਿੰਗ ਮੌਡਿਊਲ, ਡੀਪ ਰਿਪੋਰਟਿੰਗ) ਬਾਅਦ ਵਿੱਚ ਛੱਡੋ—ਜਦਕਿ ਕੋਰ ਵਰਕਫਲੋ ਭਰੋਸੇਯੋਗ ਅਤੇ ਲਗਾਤਾਰ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੋਵੇ।
ਫੀਚਰ ਅਤੇ ਸਕ੍ਰੀਨਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਕੌਣ ਐਪ ਵਰਤੇਗਾ ਅਤੇ ਹਰ ਵਿਅਕਤੀ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਕੀ ਹਾਸਲ ਕਰਨਾ ਹੈ—ਅਕਸਰ ਇਵੈਂਟ-ਦੇ ਦਿਨ ਦਬਾਅ ਹੇਠਾਂ।
ਜ਼ਿਆਦਾਤਰ ਸੰਸਥਾਵਾਂ ਇੱਕੋ ਮੁੱਖ ਰੋਲਾਂ ਨਾਲ ਖਤਮ ਹੁੰਦੀਆਂ ਹਨ:
ਸ਼ੁਰੂ ਵਿੱਚ ਰੋਲ ਸਧੇ ਬਣਾਓ। ਆਮ ਪੈਟਰਨ "ਸੇਵਾਦਾਰ" ਅਤੇ ਇੱਕ ਉੱਪਰ-ਲੈਵਲ ਰੋਲ ("ਕੋਆਰਡੀਨੇਟਰ") ਹੈ, ਫਿਰ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ "ਸ਼ਿਫਟ ਲੀਡਰ" ਜੋੜੋ।
ਸੇਵਾਦਾਰ ਆਮ ਤੌਰ 'ਤੇ ਚਾਹੁੰਦੇ ਹਨ: ਸਾਈਨਅਪ, ਕੈਲੇਂਡਰ ਵਿਊ, ਕੈਂਸਲ/ਸਵੈਪ, ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ ਅਤੇ ਹਦਾਇਤਾਂ, ਅਤੇ ਚੇਕ-ਇਨ।
ਕੋਆਰਡੀਨੇਟਰਾਂ ਨੂੰ ਚਾਹੀਦਾ ਹੈ: ਸ਼ਿਫਟ ਬਣਾਉਣ, ਮਨਜ਼ੂਰੀ/ਪ੍ਰਤਿਖੰਡ, ਇੱਕ ਉਪਸੈਟ ਸਬਸੈਟ ਨੂੰ ਬ੍ਰੌਡਕਾਸਟ (ਉਦਾਰਹਣ ਲਈ "ਕੱਲ੍ਹ ਦੀ ਰਸੋਈ ਟੀਮ"), ਅਤੇ ਰਿਪੋਰਟਿੰਗ (ਘੰਟੇ, ਹਾਜ਼ਰੀ, ਨੋ-ਸ਼ੋ)।
ਸ਼ਿਫਟ ਲੀਡਰਾਂ ਨੂੰ ਚਾਹੀਦਾ ਹੈ: ਰੋਸਟਰ, ਸੇਵਾਦਾਰ ਨਾਲ ਸੰਪਰਕ, ਹਾਜ਼ਰੀ ਨਿਸ਼ਚਿਤ ਕਰਨਾ, ਅਤੇ ਘਟਨਾਵਾਂ ਨੋਟ ਕਰਨਾ।
ਅਸਲੀ ਓਪਰੇਸ਼ਨ ਤੁਹਾਡੇ ਡਿਜ਼ਾਈਨ ਨੂੰ ਆਕਾਰ ਦਿੰਦੇ ਹਨ:
ਜੇ ਕੋਆਰਡੀਨੇਟਰ ਲੈਪਟਾਪ ਤੋਂ ਕੰਮ ਕਰਦੇ ਹਨ, ਤਾਂ ਵੈੱਬ ਐਡਮਿਨ ਪੋਰਟਲ ਇਨਪੁੱਟ ਰੱਖਣ, ਸੇਵਾਦਾਰ ਪ੍ਰਬੰਧਨ ਅਤੇ ਡੇਟਾ ਨਿਰਯਾਤ ਲਈ ਕਾਫ਼ੀ ਫਾਇਦੇਮੰਦ ਹੁੰਦਾ ਹੈ। ਸੇਵਾਦਾਰ ਆਮ ਤੌਰ 'ਤੇ iOS ਅਤੇ Android ਐਪ (ਜਾਂ ਇੱਕ ਉੱਚ-ਗੁਣਵੱਤਾ ਮੋਬਾਈਲ ਵੈੱਬ ਤਜ਼ਰਬਾ) ਪਸੰਦ ਕਰਦੇ ਹਨ ਸਾਈਨਅਪ ਅਤੇ ਰਿਮਾਈਂਡਰ ਲਈ।
ਇੱਕ ਸੇਵਾਦਾਰ ਸੰਯੋਜਨ ਐਪ ਲਈ MVP "ਹਰ ਚੀਜ਼ ਦਾ ਛੋਟਾ ਵਰਜਨ" ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਸਪੱਸ਼ਟ ਵਾਅਦਾ ਹੈ: ਆਯੋਜਕ ਸ਼ਿਫਟਾਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰ ਸਕਦੇ ਹਨ, ਸੇਵਾਦਾਰ ਉਹਨਾਂ ਨੂੰ ਕਲੇਮ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਸਭ ਨੂੰ ਸਹੀ ਸਮੇਂ ਰਿਮਾਈਂਡਰ ਮਿਲਦੇ ਹਨ।
ਪਹਿਲੀ ਰਿਲੀਜ਼ ਲਈ ਇੱਕ end-to-end ਲੂਪ ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ:
ਜੇ ਤੁਹਾਡਾ MVP ਸਿਰਫ ਇਹ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਅਸਲ ਇਵੈਂਟਸ ਲਈ ਵੀ ਫਾਇਦੇਮੰਦ ਹੈ।
ਆਮ ਨਿਯਮ: ਜੇ ਕੋਈ ਫੀਚਰ ਸ਼ਿਫਟ ਨੂੰ ਸਟਾਫ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਨਹੀਂ, ਤਾਂ ਇਹ ਸ਼ਾਇਦ v1 ਲਈ ਲਾਜ਼ਮੀ ਨਹੀਂ।
ਲਾਜ਼ਮੀ ਉਦਾਹਰਣਾਂ:
ਚੰਗੇ-ਹੋਣ ਵਾਲੇ (بعد ਵਿੱਚ ਮਿਲਾਉਣ ਯੋਗ, ਪਹਿਲਾਂ ਖ਼ਤਰਾ): ਵੈਟਲਿਸਟ, ਘੰਟਾ ਟਰੈਕਿੰਗ/ਵਾਲੰਟੀਅਰ ਘੰਟੇ, ਪਿਛੋਕੜ ਚੈੱਕ, ਇਨ-ਐਪ ਚੈਟ, ਉੱਨਤ ਰਿਪੋਰਟਿੰਗ, ਜਟਿਲ ਮਨਜ਼ੂਰੀ ਚੇਨ।
ਤੈਅ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਲਈ optimize ਕਰ ਰਹੇ ਹੋ:
ਬਹੁਤ جلد ਦੋਹਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਅਕਸਰ ਗੁੰਝਲਦਾਰ ਸਕਰੀਨਾਂ ਅਤੇ ਏਡਜ-ਕੇਸ ਬਣਾਉਂਦਾ ਹੈ।
5–10 ਸਪੱਸ਼ਟ-ਭਾਸ਼ਾ ਚੈੱਕ ਪਰਿਭਾਸ਼ਤ ਕਰੋ, ਜਿਵੇਂ:
ਇਹ ਮਾਪਦੰਡ ਤੁਹਾਡੇ MVP ਨੂੰ ਫੋਕਸ ਵਿੱਚ ਰੱਖਦੇ ਹਨ ਅਤੇ "ਕਿਆ ਹੋਇਆ ਹੈ" ਨੂੰ ਮਾਪਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
ਸਕੇਜੂਲਿੰਗ ਇੱਕ ਸੇਵਾਦਾਰ ਸੰਯੋਜਨ ਐਪ ਦੀ ਇੰਜਣ ਹੈ। ਜੇ ਨਿਯਮ ਅਸਪਸ਼ਟ ਹਨ, ਤਾਂ ਬਾਕੀ ਸਭ—ਨੋਟੀਫਿਕੇਸ਼ਨ, ਹਾਜ਼ਰੀ, ਰਿਪੋਰਟਿੰਗ—ਅਣਵਿੰਚਿਤ ਮਹਿਸੂਸ ਹੋਵੇਗਾ।
ਹਰ ਸ਼ਿਫਟ ਨੂੰ ਇੱਕ ਸਧਾਰਨ, ਸਪੱਸ਼ਟ ਲਾਈਫਸਾਇਕਲ ਵਿੱਚ ਅੱਗੇ ਵਧਦੇ ਹੋਏ ਤਰ੍ਹਾਂ ਸੋਚੋ:
ਇਹ ਸਥਿਤੀਆਂ ਨਿਯਮ ਲਾਗੂ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦੀਆਂ ਹਨ (ਉਦਾਹਰਣ ਲਈ, ਜਦੋਂ ਸ਼ਿਫਟ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿਸੇ ਕੱਟ-ਆਫ਼ ਵਿਚ ਹੋਵੇ ਤਾਂ ਸਮਾਂ ਬਦਲਣਾ ਰੋਕੋ)।
ਸੇਵਾਦਾਰਾਂ ਨੂੰ ਯੋਗਤਾ ਨਾਲ:
ਫਿਰ ਐਪ ਆਪਣੇ ਆਪ ਰਿਮਾਈਂਡਰ ਸੈਡਿਊਲ ਕਰਦਾ ਹੈ (ਜਿਵੇਂ 24 ਘੰਟੇ ਅਤੇ 2 ਘੰਟੇ ਪਹਿਲਾਂ), ਨਾਲ ਹੀ "ਕੈਲੰਡਰ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ" ਵਿਕਲਪ।
ਕੋਆਰਡੀਨੇਟਰਾਂ ਨੂੰ ਤੇਜ਼ੀ ਅਤੇ ਇੱਕਸਾਰਤਾ ਚਾਹੀਦੀ ਹੈ:
ਕੁਝ ਨਿਯਮ ਉਲਝਣ ਰੋਕਦੇ ਹਨ:
ਸਪੱਸ਼ਟ ਸਕੇਜੂਲਿੰਗ ਲੌਜਿਕ ਸਹਾਇਤਾ ਕਰਦੀ ਹੈ ਕਿ "ਕਲੇਮ ਕੀਤਾ" ਅਸਲ ਵਿੱਚ "ਤੁਸੀਂ ਆਉਣ ਦੀ ਉਮੀਦ ਰੱਖੋ" ਨੂੰ ਦਰਸਾਵੇ।
ਇੱਕ ਸੇਵਾਦਾਰ ਐਪ ਉਸ ਵੇਲੇ ਸਫ਼ਲ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਲੋਕ ਸੈਕਿੰਡਾਂ ਵਿੱਚ ਦੋ ਪ੍ਰਸ਼ਨਾਂ ਦੇ ਜਵਾਬ ਲੱਭ ਸਕਣ: "ਮੈਨੂੰ ਕਿੱਥੇ ਜਾਣਾ ਹੈ?" ਅਤੇ "ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ?" UI ਨੂੰ ਸ਼ਾਂਤ, ਪੇਸ਼ਗੀਤ ਅਤੇ ਦਿਆਲੂ ਰੱਖੋ—ਖਾਸ ਕਰਕੇ ਨਵੇਂ ਯੂਜ਼ਰਾਂ ਲਈ।
Home ਨੂੰ ਨਿੱਜੀ ਡੈਸ਼ਬੋਰਡ ਵਾਂਗ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ: ਅਗਲੀ ਸ਼ਿਫਟ, ਤੇਜ਼ ਕਾਰਵਾਈਆਂ (ਚੇਕ-ਇਨ, ਕੋਆਰਡੀਨੇਟਰ ਨੂੰ ਸੰਦੇਸ਼), ਅਤੇ ਕੋਈ ਤੁਰੰਤ ਅਲਰਟ (ਸ਼ਿਫਟ ਬਦਲ ਗਿਆ, ਨਵੀਂ ਨਿਯੁਕਤੀ)।
Shift List ਮੁੱਖ ਬ੍ਰਾਊਜ਼ਿੰਗ ਸਤਹ ਹੈ। ਤੇਜ਼ ਫਿਲਟਰ ਸ਼ਾਮਲ ਕਰੋ: ਤਾਰੀਖ, ਟਿਕਾਣਾ, ਭੂਮਿਕਾ, ਅਤੇ "ਮੇਰੀ ਉਪਲਬਧਤਾ ਲਈ ਫਿੱਟ"। ਮੁੱਖ ਜਾਣਕਾਰੀਆਂ ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ ਦਿਖਾਓ: ਸ਼ੁਰੂ/ਅੰਤ ਸਮਾਂ, ਭੂਮਿਕਾ, ਬਚੀਆਂ ਹੋਈਆਂ ਸਥਾਨ, ਅਤੇ ਦੂਰੀ ਜੇ ਲਾਗੂ ਹੁੰਦੀ ਹੈ।
Shift Detail ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਫੈਸਲੇ ਹੁੰਦੇ ਹਨ। ਇਸ ਵਿੱਚ ਜ਼ਿੰਮੇਵਾਰੀਆਂ, ਮਿਲਣ ਦਾ ਬਿੰਦੂ, ਸੰਪਰਕ ਵਿਅਕਤੀ, ਲਿਆਉਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ, ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਪ੍ਰਾਇਮਰੀ ਬਟਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਸਥਿਤੀ ਦੇ ਨਾਲ ਬਦਲਦਾ ਹੈ: Sign up → Cancel → Checked in.
Calendar ਸੇਵਾਦਾਰਾਂ ਨੂੰ ਹਫ਼ਤਾਵਾਰ ਪੈਟਰਨ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਇਸਨੂੰ ਉਸੇ ਸ਼ਿਫਟਸ ਦਾ ਵਿਰੋਧੀ ਦਰਸ਼ਨ ਬਣਾਓ (ਨਵਾਂ ਸ਼ਡਿਊਲਿੰਗ ਸਿਸਟਮ ਨਾ ਬਣਾਓ)।
Profile ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਸੇਵਾਦਾਰ ਉਪਲਬਧਤਾ, ਪREFERੰਸਾਂ, ਅਤੇ ਬੁਨਿਆਦੀ ਜਾਣਕਾਰੀ ਜਿਵੇਂ ਐਮਰਜੈਂਸੀ ਸੰਪਰਕ ਸੰਭਾਲਦੇ ਹਨ। ਸੋਧਾਂ ਸਧਾਰਨ ਰੱਖੋ ਅਤੇ ਬਦਲਾਵਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
Messages ਕੋਆਰਡੀਨੇਸ਼ਨ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹੋਣ ਚਾਹੀਦੇ ਹਨ: ਕੋਆਰਡੀਨੇਟਰ ਨਾਲ ਇਕ-ਉੱਤੇ-ਇੱਕ ਅਤੇ ਪ੍ਰਤੀ ਇਵੈਂਟ ਜਾਂ ਟੀਮ ਇੱਕ-ਗਰੁੱਪ ਥ੍ਰੈੱਡ।
ਉਪਲਬਧਤਾ ਇੰਪੁਟ ਟੈਕਸਟ ਕਰਨ ਨਾਲ ਵੀ ਤੇਜ਼ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ:
ਥੱਕੇ ਹੋਏ ਅੰਗੂਠਿਆਂ ਅਤੇ ਬਾਹਰਲੇ ਰੋਸ਼ਨੀ ਹਾਲਾਤ ਦੇ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ:
ਈਵੈਂਟਾਂ ਵਿੱਚ ਅਕਸਰ ਖਰਾਬ ਰਿਸੈਪਸ਼ਨ ਹੁੰਦੀ ਹੈ। ਚੇਕ-ਇਨ-ਸਬੰਧੀ ਕਾਰਵਾਈਆਂ ਲਈ ਇੱਕ ਅਫਲਾਈਨ ਰਾਹ ਯੋਜੋ: ਸਕੈਨਜ਼ ਜਾਂ ਟੈਪ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਸੇਵ ਕਰੋ, "queued to sync" ਸਥਿਤੀ ਦਿਖਾਓ, ਅਤੇ ਜਦੋਂ ਡਿਵਾਈਸ ਦੁਬਾਰਾ ਜੁੜੇ ਤਾਂ ਬਿਨਾਂ ਯੂਜ਼ਰ ਤੋਂ ਮੰਗੇ ਆਟੋ-ਸਿੰਕ ਕਰੋ।
ਇੱਕ ਸਪੱਸ਼ਟ ਡੇਟਾ ਮਾਡਲ ਸਕੇਜੂਲਿੰਗ ਨੂੰ ਸਹੀ, ਨੋਟੀਫਿਕੇਸ਼ਨ ਭਰੋਸੇਯੋਗ, ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਸੁਗਮ ਰੱਖਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਪਹਿਲੇ ਦਿਨ ਸੈਂਕੜੇ ਟੇਬਲਾਂ ਦੀ ਲੋੜ ਨਹੀਂ—ਪਰ ਤੁਹਾਨੂੰ ਕੁਝ ਮੁੱਖ ਰਿਕਾਰਡ ਅਤੇ ਕੁਝ ਖੇਤਰ ਚਾਹੀਦੇ ਹਨ ਜੋ ਅਸਲੀ-ਦੁਨੀਆ ਦੀਆਂ ਗਲਤੀਆਂ ਰੋਕਣ।
ਸ਼ੁਰੂਾਤ ਲਈ ਇਹ ਜ਼ਰੂਰੀ ਹਨ:
ਇਸ ਵੰਡ ਦਾ ਮਤਲਬ: ਇੱਕ Shift ਮੌਜੂਦ ਰਹਿ ਸਕਦਾ ਹੈ ਭਾਵੇਂ ਕਿਸੇ ਨੇ ਸਾਈਨਅਪ ਨਾ ਕੀਤਾ ਹੋਵੇ, ਅਤੇ ਇੱਕ Signup ਨੂੰ ਰੱਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਸ਼ਿਫਟ ਨੂੰ ਹਟਾਏ।
ਘੱਟੋ-ਘੱਟ, ਹਰ ਸ਼ਿਫਟ ਵਿੱਚ ਇਹ ਰੱਖੋ:
ਸਾਈਨਅਪ ਲਈ ਸ਼ਾਮਲ ਕਰੋ signup status (confirmed, waitlisted, canceled) ਅਤੇ ਟਾਈਮਸਟੈਂਪ।
Shifts ਅਤੇ Signups 'ਤੇ created_by, updated_by, canceled_by ਅਤੇ ਸਮੇਂ ਦੇ ਟਾਈਮਸਟੈਂਪ ਟਰੈਕ ਕਰੋ। ਇਹ ਜ਼ਿੰਮੇਵਾਰੀ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਅਤੇ ਵਿਵਾਦ ਸੁਲਝਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਪ੍ਰਭਾਵ-ਰਿਪੋਰਟ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂattendance ਵੇਰਵਿਆਂ ਨੂੰ ਪ੍ਰਤੀ-ਸਾਈਨਅਪ ਸਟੋਰ ਕਰੋ:
ਇਹ ਖੇਤਰ ਸਧਾਰਨ ਰਿਪੋਰਟਿੰਗ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
ਪ੍ਰਮਾਣੀਕਰਨ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਸਹੂਲਤ ਅਤੇ ਨਿਯੰਤਰਣ ਮਿਲਦੇ ਹਨ। ਸੇਵਾਦਾਰ ਇੱਕ ਤੇਜ਼ ਸਾਈਨ-ਇਨ ਚਾਹੁੰਦੇ ਹਨ; ਕੋਆਰਡੀਨੇਟਰ ਅਤੇ ਐਡਮਿਨ ਨੂੰ ਯਕੀਨ ਚਾਹੀਦਾ ਹੈ ਕਿ ਸਹੀ ਲੋਕ ਹੀ ਸਹੀ ਚੀਜ਼ ਵੇਖ/ਸੰਪਾਦਨ ਕਰ ਸਕਦੇ ਹਨ।
ਜ਼ਿਆਦਾਤਰ ਨਾਨਪ੍ਰਾਫਿਟ ਟੀਮਾਂ ਲਈ, ਸਧਾਰਨ ਰਾਹ ਚੁਣੋ ਅਤੇ friction ਘਟਾਓ:
ਇੱਕ ਹਿੱਕ-ਅਮਲ MVP ਦ੍ਰਿਸ਼ਟੀ: ਪਹਿਲਾਂ ਈਮੇਲ + ਕੋਡ ਸਹਾਇਤ ਕਰੋ, ਅਤੇ backend ਇੰਝ ਡਿਜ਼ਾਈਨ ਕਰੋ ਕਿ SSO ਬਾਅਦ ਵਿੱਚ ਜੋੜਿਆ ਜਾ ਸਕੇ।
ਸ਼ੁਰੂ ਵਿੱਚ ਅਧਿਕਾਰ ਪਰਿਭਾਸ਼ਤ ਕਰੋ ਤਾਂ ਕਿ ਬਾਅਦ ਵਿੱਚ ਏਡਜ-ਕੇਸ ਨਹੀਂ ਬਣਦੇ:
ਅਧਿਕਾਰ ਸਰਵਰ-ਪੱਖ ਤੇ ਲਾਗੂ ਕਰੋ (UI 'ਤੇ ਕੇਵਲ ਨਹੀਂ) ਤਾਂ ਜੋ ਕੋਈ ਕੌਤੁਕ ਯੂਜ਼ਰ ਐਪ ਨੂੰ ਹੱਕ ਨਾਲ ਟਵਿਕ ਕਰਕੇ ਕੋਆਰਡੀਨੇਟਰ ਟੂਲ ਨੂੰ ਨਾ ਵੇਖ ਸਕੇ।
ਜੇਕਰ ਤੁਸੀਂ ਹੁਣ ਇੱਕ ਆਰਗਨਾਈਜੇਸ਼ਨ ਲਈ ਲਾਂਚ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਫਿਰ ਵੀ ਡੇਟਾ ਨੂੰ ਇੱਕ Organization ID ਨਾਲ ਸਟੋਰ ਕਰੋ। ਇਹ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ:
ਅਸਲੀ ਦੁਨੀਆ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਲਈ ਯੋਜਨਾ ਬਣਾਓ: ਲੋਕ ਈਮੇਲ ਬਦਲਦੇ ਹਨ, ਉਪਨਾਮ ਵਰਤਦੇ ਹਨ, ਜਾਂ ਦੋ ਵਾਰੀ ਸਾਈਨ-ਅਪ ਕਰਦੇ ਹਨ।
ਸ਼ਾਮਲ ਕਰੋ:
ਨੋਟੀਫਿਕੇਸ਼ਨ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਐਪ ਭਰੋਸਾ ਬਣਾਉਂਦੀ ਹੈ—ਜਾਂ ਸ਼ੋਰ। ਲੱਛਣ ਸਾਧਾ ਹੈ: ਸੇਵਾਦਾਰਾਂ ਨੂੰ ਪ੍ਰਯਾਪਤ ਜਾਣਕਾਰੀ ਮਿਲੇ ਤਾਂ ਕਿ ਉਹ ਤਿਆਰ ਆਉਣ, ਬਿਨਾਂ ਐਪ ਨੂੰ ਲਗਾਤਾਰ ਪਾਂਗੇ ਵਾਲਾ ਬਣਾਏ।
ਛੋਟੀ ਸੋਚੀ ਗਈ ਸੁਚੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਮੋਬਾਈਲ ਐਪ MVP ਲਈ ਪ੍ਰਾਇਕਟਿਕ ਤਰੀਕਾ: ਪੁਸ਼ + ਈਮੇਲ ਪਹਿਲਾਂ, ਫਿਰ ਲੋੜ ਅਤੇ ਬਜਟ ਦੇ ਅਨੁਸਾਰ SMS ਸ਼ਾਮਲ ਕਰੋ।
ਮੂਲ ਰੱਖ-ਰਖਾਅ ਪਹਿਲਾਂ ਬਣਾਓ:
ਇਕ-ਤਰਫ਼ਾ ਅਲਰਟਾਂ ਕਾਫ਼ੀ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਸੇਵਾਦਾਰਾਂ ਨੂੰ ਸੁਨੇਹੇ ਤੋਂ ਕਾਰਵਾਈ ਕਰਨ ਦਿਓ:
ਗੱਲ-ਬਾਤ ਨੂੰ ਖਾਸ ਸ਼ਿਫਟ ਜਾਂ ਇਵੈਂਟ ਨਾਲ ਜੋੜ ਕੇ ਰੱਖੋ ਤਾਂ ਜੋ ਆਯੋਜਕਾਂ ਨੂੰ ਬੇਵਸਥਾ ਨਾ ਹੋਵੇ ਅਤੇ ਵੇਰਵੇ ਤਲਾਸ਼ਣਯੋਗ ਰਹਿਣ।
ਹਾਜ਼ਰੀ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਸੇਵਾਦਾਰ ਸੰਯੋਜਨ ਐਪ "ਸਿਰਫ਼ ਸਕੇਜੂਲਿੰਗ" ਤੋਂ ਅੱਗੇ ਚਲਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਸੱਚਾਈ ਬਣਦਾ ਹੈ: ਕਿਸ ਨੇ ਅਸਲ ਵਿੱਚ ਸ਼ਾਮਿਲ ਹੋ ਕੇ ਕਦੋਂ ਰਹਿਣਾ ਕੀਤਾ। ਕੁੰਜੀ ਗੱਲ ਹੈ ਸਹੀਤਾ ਅਤੇ ਤੇਜ਼ ਚੇਕ-ਇਨ ਫਲੋ ਜੋ ਇਵੈਂਟ 'ਤੇ ਕਿਸੇ ਨੂੰ ਰੋਕਦਾ ਨਾ ਹੋਵੇ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਵੱਧ ਤੋਂ ਵੱਧ ਇੱਕ ਤੋਂ ਵੱਧ ਚੇਕ-ਇਨ ਵਿਕਲਪ ਦੇਣਾ ਚਾਹੁੰਦੀਆਂ ਹਨ, ਕਿਉਂਕਿ ਅਸਲੀ ਈਵੈਂਟ ਗੜਬੜ ਵਾਲੇ ਹੋ ਸਕਦੇ ਹਨ—ਸਿਗਨਲ ਡ੍ਰਾਪ, ਫੋਨ ਮਰ ਜਾਣ, ਅਤੇ ਲੀਡਰਾਂ ਨੂੰ ਕਈ ਕੰਮ।
ਚੰਗਾ ਡਿਫਾਲਟ: ਸਵੈ-ਸੇਵਾ ਲਈ QR ਜਾਂ GPS, ਅਤੇ ਫੈਲਬੈਕ ਲਈ ਲੀਡਰ ਪੁਸ਼ਟੀ।
ਸਧਾਰਨ, ਪਾਰਦਰਸ਼ੀ ਨਿਯਮ ਪਰਿਭਾਸ਼ਤ ਕਰੋ ਤਾਂ ਜੋ ਸੇਵਾਦਾਰ ਅਤੇ ਕੋਆਰਡੀਨੇਟਰ ਉਸੇ ਨੰਬਰ ਦੇਖਣ:
ਇਹ ਨਿਯਮ UI ਵਿੱਚ ਦਿੱਸਣ ਚਾਹੀਦੇ ਹਨ ("Hours credited: 2h 15m") ਤਾਂ ਕਿ ਵਿਵਾਦ ਨਾ ਹੋਣ।
ਅਕਸਰ ਭਾਰੀ ਨਿਯੰਤਰਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਇਸ ਦੀ ਥਾਂ ਹਲਕੀ-ਫੈਲਟੀ ਜਾਂਚ 'ਤੇ ਧਿਆਨ ਦਿਓ ਜੋ ਸੇਵਾਦਾਰਾਂ ਦੇ ਸਮੇਂ ਦਾ ਸਤਕਾਰ ਕਰਦੀ ਹੈ:
ਇਹ ਦ੍ਰਿਸ਼ਟੀ ਦੁਰਵਰਤਨ ਨੂੰ ਰੋਕਦੀ ਹੈ, ਅਨੁਭਵ ਨੂੰ ਮਿੱਤਰਵਾਨ ਰੱਖਦੀ ਹੈ।
ਘੰਟਿਆਂ ਦਾ ਡੇਟਾ ਤਦ ਹੀ ਕੀਮਤੀ ਬਣਦਾ ਹੈ ਜਦੋਂ ਇਸਨੂੰ ਸਿਰਫ਼ ਅਸਾਨੀ ਨਾਲ ਸੰਖੇਪ ਕੀਤਾ ਅਤੇ ਸਾਂਝਾ ਕੀਤਾ ਜਾ ਸਕੇ। ਸਧਾਰਨ ਫਿਲਟਰ ਅਤੇ ਨਿਰਯਾਤ ਸ਼ਾਮਲ ਕਰੋ:
ਨਿਰਯਾਤ ਪਹਿਲਾਂ CSV ਹੋਣ (ਸਭ ਲਈ ਵਰਤੋਂਯੋਗ), ਪ੍ਰਿੰਟ ਕਰਨਯੋਗ ਸਾਰ ਜੋੜੋ। ਟੋਟਲ ਅਤੇ ਪ੍ਰਤੀ-ਸ਼ਿਫਟ ਵੇਰਵਾ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਕਿ ਪ੍ਰਸ਼ਾਸਕ ਜਲਦੀ ਆਡਿਟ ਕਰ ਸਕਣ।
ਸੇਵਾਦਾਰ ਸੰਯੋਜਨ ਐਪ ਅਕਸਰ ਸੰਵੇਦਨਸ਼ੀਲ ਵੇਰਵੇ (ਨਾਂ, ਫੋਨ ਨੰਬਰ, ਉਪਲਬਧਤਾ, ਅਤੇ ਕਿ ਕੋਈ ਫਿਰ ਡਿੱਠਾ ਜਾਵੇਗਾ) ਸੰਭਾਲਦਾ ਹੈ। ਨਿੱਜਤਾ ਅਤੇ ਸੁਰੱਖਿਆ early-stage 'ਤੇ ਠੀਕ ਕਰਨ ਨਾਲ ਭਰੋਸਾ ਬਣਦਾ ਹੈ—ਅਤੇ ਸੰਸਥਾ ਲਈ ਖ਼ਤਰਾ ਘਟਦਾ ਹੈ।
ਹਰ ਸੇਵਾਦਾਰ ਆਪਣਾ ਨੰਬਰ/ਈਮੇਲ ਸਾਰਿਆਂ ਨਾਲ ਸਾਂਝਾ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦਾ। ਸਧਾਰਣ ਕੰਟਰੋਲ ਜੋੜੋ:
ਹਰ ਫੀਲਡ ਨੂੰ ਇੱਕ ਜ਼ਿਮੇਵਾਰੀ ਸਮਝੋ। ਜੇ ਇਹ ਸੀਧਾ ਸਕੇਜੂਲਿੰਗ, ਰਿਮਾਈਂਡਰ, ਜਾਂ ਚੇਕ-ਇਨ ਵਿੱਚ ਸਹਾਇਕ ਨਹੀਂ, ਤਾਂ ਇਸਨੂੰ skip ਕਰੋ।
ਵਾਪਸੀ ਕੌਮਾਂਤਰੀ ਨਿਯਮ: ਸ਼ੁਰੂ ਵਿੱਚ ਨਾਂ, ਪREFERੰਡ ਸੰਪਰਕ ਪ੍ਰਣਾਲੀ, ਉਪਲਬਧਤਾ, ਅਤੇ ਐਮਰਜੈਂਸੀ ਸੰਪਰਕ (ਜੇ ਜ਼ਰੂਰੀ) ਰੱਖੋ। ਜਨਮ ਤਾਰੀਖ, ਘਰ ਪਤਾ, ਜਾਂ ਵਿਸਥਾਰਕ ਨੋਟਾਂ ਨਾ ਲਵੋ ਬਿਨਾਂ ਸਪਸ਼ਟ ਕਾਰਨ ਅਤੇ ਦੇਖਣ ਵਾਲੇ ਨੀਤੀ ਦੇ।
ਤੁਹਾਨੂੰ ਵੱਡੀਆਂ ਸਰਕਾਰੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਲੋੜ ਨਹੀਂ; ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਪ੍ਰਾਥਮਿਕਤਾ ਨਾਲ:
ਸੁਰੱਖਿਆ ਆਪਰੇਸ਼ਨਲ ਵੀ ਹੈ। ਪਹਿਲਾਂ ਹੀ ਫੈਸਲੇ ਕਰੋ:
ਤੁਹਾਡਾ ਟੈਕ ਸਟੈਕ ਦੋ ਚੀਜ਼ਾਂ ਨੂੰ ਸਮਰਥਨ ਕਰੇ: ਭਰੋਸੇਯੋਗ ਸਕੇਜੂਲਿੰਗ (ਕੋਈ ਮਿਸਡ ਸ਼ਿਫਟ ਨਾ ਹੋਵੇ) ਅਤੇ ਆਸਾਨ ਚੇਂਜ-ਮੈਨੇਜਮੈਂਟ (ਕਿੋਂਕਿ ਪ੍ਰੋਗਰਾਮ ਬਦਲਦੇ ਹਨ)। ਇੱਕ ਸਧਾਰਨ, ਮੋਢੇਇੰਟ ਮਾਡਿਊਲਰ ਆਰਕੀਟੈਕਚਰ MVP ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਅਤੇ ਫਿਰ ਫੀਚਰ ਜੋੜਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ।
ਨੈਟਿਵ (Swift iOS ਲਈ, Kotlin Android ਲਈ) ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਨਰਮ ਅਨੁਭਵ ਅਤੇ ਪਲੇਟਫਾਰਮ-ਕੁਦਰਤੀ ਮਹਿਸੂਸ ਦਿੰਦਾ—ਖਾਸ ਤੌਰ 'ਤੇ ਕੈਲੇਂਡਰ, ਪੁਸ਼ ਨੋਟੀਫਿਕੇਸ਼ਨ, ਬੈਕਗ੍ਰਾਊਂਡ ਟਾਸਕ, ਅਤੇ ਪਹੁੰਚਯੋਗਤਾ ਸੈਟਿੰਗਜ਼ ਲਈ। ਕਿੰਮਤ ਅਤੇ ਸਮਾਂ ਵੱਧ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਦੋ ਕੋਡਬੇਸ ਰੱਖਣੇ ਪੈਂਦੇ ਹਨ।
ਕ੍ਰਾਸ-ਪਲੇਟਫਾਰਮ (React Native ਜਾਂ Flutter) ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਾਂਝੇ ਕੋਡਬੇਸ ਨਾਲ ਮਾਰਕੀਟ ਤੱਕ ਤੇਜ਼ੀ ਲਿਆਉਂਦਾ ਹੈ। ਇਹ ਇੱਕ ਮਜ਼ਬੂਤ ਫਿਟ ਹੈ ਜਿੱਥੇ ਜ਼ਿਆਦਾਤਰ ਸਕ੍ਰੀਨ ਫਾਰਮ, ਲਿਸਟ, ਅਤੇ ਸਕੇਜੂਲ ਹਨ। ਘਟਕ ਸਮੱਸਿਆਵਾਂ (ਪੁਸ਼ ਵਿਵਹਾਰ, ਡੀਪ ਲਿੰਕ, OS ਅੱਪਡੇਟ) ਲਈ ਕਦੇ-ਕਦੇ ਪਲੇਟਫਾਰਮ-ਨਿਰਦੇਸ਼ ਕੋਡ ਲਗਦਾ ਹੈ।
ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ MVP ਦ੍ਰਿਸ਼ਟੀ: ਕ੍ਰਾਸ-ਪਲੇਟਫਾਰਮ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਪਰ ਜਦੋਂ OS ਇਕਲਪਤਾ ਆਏ ਤਾਂ ਛੋਟੀ ਬਜਟ ਨੈਟਿਵ ਬ੍ਰਿਜ ਲਈ ਰੱਖੋ।
ਜੇ ਤੁਸੀਂ ਵਰਕਫਲੋ (shifts → signups → reminders → check-in) ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਵੈਰੀਫਾਈ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਬਿਨਾਂ ਪੂਰੇ ਪਾਈਪਲਾਈਨ ਬਣਾਉਣ ਦੇ, ਤਾਂ ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਤੁਹਾਡੀ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ—ਆਮ ਤੌਰ 'ਤੇ React ਵੈੱਬ, Go ਬੈਕਐਂਡ, ਅਤੇ PostgreSQL ਲਈ। ਜਦੋਂ ਤੁਸੀਂ ਤਿਆਰ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸੋਰਸ ਕੋਡ ਨਿਰਯਾਤ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਆਪਣੀ ਟੀਮ ਨਾਲ ਅੱਗੇ ਵਧ ਸਕਦੇ ਹੋ।
ਬੈਕਐਂਡ ਲਈ surface area ਛੋਟੀ ਰੱਖੋ:
ਸਧਾਰਨ ਰੱਖੋ:
ਇਹ ਸੇਵਾਦਾਰਾਂ ਨੂੰ ਕਾਬੂ ਦਿੰਦਾ ਹੈ ਬਿਨਾਂ ਦੁਨੀਆਂ-ਪਾਸੇ ਦੁਆਰਾ ਦੋ-ਤਰਫ਼ਾ ਕੈਲੇਂਡਰ ਸਿੰਕਿੰਗ ਦੇ ਜਟਿਲਤਾਂ ਦੇ।
ਜੇ ਇਹ ਲੇਖ ਕਿਸੇ ਉਤਪਾਦ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਤਾਂ CTAs ਓਸਥਾਨਾਂ 'ਤੇ ਰੱਖੋ ਜਿੱਥੇ ਪਾਠਕ ਕੁਦਰਤੀ ਰੂਪ ਵਿੱਚ ਰੁਕਦੇ ਹਨ:
ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਕੁਦਰਤੀ ਨਕਸ਼ੇ ਵੀ ਹਨ—ਟਿਅਰ ਚੁਣੋ ਜਾਂ planning mode ਵਰਤ ਕੇ roles, permissions, ਅਤੇ shift lifecycle ਨਕਸ਼ਾ ਬਣਾਉਣਾ ਪਹਿਲਾਂ, ਫਿਰ ਐਪ ਜਨਰੇਟ ਕਰੋ।
ਇੱਕ ਸੇਵਾਦਾਰ ਸੰਯੋਜਨ ਐਪ ਭਰੋਸੇ 'ਤੇ ਜੀਉਂਦੀ/ਮਰਦੀ ਹੈ: ਲੋਕਾਂ ਨੂੰ ਯਕੀਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਸ਼ਡਿਊਲ ਸਹੀ ਹੈ, ਰਿਮਾਈਂਡਰ ਸਮੇਂ ਤੇ ਹਨ, ਅਤੇ ਆਖਰੀ-ਮਿੰਟ ਬਦਲਾਅ ਗੁੰਝਲ ਨਾ ਪੈਦਾ ਕਰਨ। ਟੈਸਟਿੰਗ ਅਤੇ ਰੋਲਆਊਟ ਨੂੰ ਪ੍ਰੋਡਕਟ ਦਾ ਹਿੱਸਾ ਸਮਝੋ—ਇਹ ਬਾਅਦ ਦੀ ਗੱਲ ਨਹੀਂ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ "ਗਣਿਤ" ਟੈਸਟ ਕਰੋ। ਕੁਝ ਟੈਸਟ ਸਿਨੇਰੀਓ ਬਣਾਓ ਅਤੇ ਹਰ ਵਾਰੀ ਸਕੇਜੂਲਿੰਗ ਲੌਜਿਕ ਬਦਲੋ ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਚਲਾਓ:
ਅਜੇਹੇ ਨਿਯਮਾਂ 'ਤੇ ਹਲਕੀ automated test suite ਹੋਵੇ ਤਾਂ regressions ਜ਼ਰੂਰ ਜਲਦੀ पकड़ੇ ਜਾ ਸਕਦੇ ਹਨ।
5–8 ਸੇਵਾਦਾਰ ਲਿਆਓ ਜੋ ਤੁਹਾਡੇ ਹਕੀਕਤੀ ਦਰਸ਼ਕ ਨੂੰ ਨਥਾ ਕਰਦੇ ਹਨ (ਘੱਟੋ-ਘੱਟ ਇੱਕ ਪਹਿਲੀ ਵਾਰ ਆਉਣ ਵਾਲਾ)। ਓਹਨਾਂ ਨੂੰ ਕਾਰਜ ਦਿਓ ਜਿਵੇਂ "ਅਗਲੇ ਸ਼ਨੀਵਾਰ ਲਈ ਸ਼ਿਫਟ ਲੱਭੋ" ਜਾਂ "ਇੱਕ ਸ਼ਿਫਟ ਰੱਦ ਕਰੋ ਅਤੇ ਕੋਆਰਡੀਨੇਟਰ ਨੂੰ ਸੁਨੇਹਾ ਭੇਜੋ"।
ਧਿਆਨ ਦੇਖੋ:
ਜਿੱਥੇ ਜਲੰਬਦਾਰੀ ਹੋ, ਉਹ ਅਕਸਰ ਅਸਲ ਵਰਤੋਂ ਵਿੱਚ ਡ੍ਰੌਪ-ਆਫ ਬਣਦਾ ਹੈ।
ਇੱਕ ਬੀਟਾ ਇੱਕ ਇਕ ਪ੍ਰੋਗਰਾਮ ਜਾਂ ਇਕ ਇਵੈਂਟ ਸਿਰੀਜ਼ ਨਾਲ شروع ਕਰੋ। ਟੀਮ ਐਨੀ ਹੋਵੇ ਕਿ ਤੁਸੀਂ ਨੇੜੇ ਨਾਲ ਸਮਰਥਨ ਕਰ ਸਕੋ, ਪਰ ਕਾਫੀ ਵੱਡੀ ਹੋ ਕਿ ਅਸਲੀ ਸਕੇਜੂਲਿੰਗ ਗਤੀਵਿਧੀ ਪੈਦਾ ਹੋਵੇ।
ਬੀਟਾ ਦੌਰਾਨ ਉਮੀਦਾਂ ਸੈੱਟ ਕਰੋ: ਫੀਚਰ ਬਦਲ ਸਕਦੇ ਹਨ ਅਤੇ ਫੀਡਬੈਕ ਭਾਗੀਦਾਰੀ ਦਾ ਹਿੱਸਾ ਹੈ। ਇੱਕ ਸਪੱਸ਼ਟ ਸਹਾਇਤਾ ਰਸਤਾ ਰੱਖੋ (ਹੈਲਪ ਈਮੇਲ ਜਾਂ ਇਨ-ਐਪ ਸੰਪਰਕ ਵਿਕਲਪ)।
ਕੁਝ ਮੈਟ੍ਰਿਕਸ ਚੁਣੋ ਜੋ ਨਤੀਜਿਆਂ ਨਾਲ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਜੁੜੇ ਹੋਣ:
ਹਫਤਾਵਾਰ ਸਮੀਖਿਆ ਕਰੋ, ਸਭ ਤੋਂ ਵੱਡੇ friction point ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ, ਅਤੇ ਨਿੱਕੇ increments ਵਿੱਚ ਸੁਧਾਰ ਸ਼ਿਪ ਕਰੋ। ਰੀਲੀਜ਼ ਨੋਟਸ ਜੋੜੋ ਤਾਂ ਕਿ ਸੇਵਾਦਾਰ ਸਮਝਣ ਕਿ ਕੀ ਬਦਲਿਆ ਅਤੇ ਕਿਉਂ।
ਕੇਂਦਰ ਇਹ workflow ਹੈ ਜੋ ਉਲਝਣ ਰੋਕਦਾ ਹੈ:
ਜੇ ਇਹ ਕਦਮ end-to-end ਸਹੀ ਕੰਮ ਕਰਦੇ ਹਨ, ਤਾਂ ਐਪ ਚੈਟ ਜਾਂ ਅਡਵਾਂਸ ਰਿਪੋਰਟਾਂ ਵਰਗੀਆਂ ਵਾਧੂਆਂ ਦੇ ਬਿਨਾਂ ਹੀ ਲਾਭਦਾਇਕ ਹੈ।
ਇੱਕ ਪ੍ਰਾਇਕਟਿਕਲ MVP ਹੈ ਸਕੇਜੂਲਿੰਗ + ਰਿਮਾਈਂਡਰ:
ਹੋਰ ਸਭ (ਵੈਟਲਿਸਟ, ਘੰਟੇ ਟਰੈੱਕਿੰਗ, ਪਿਛੋਕੜ ਚੈੱਕ) ਨੂੰ ਕੋਰ ਲੂਪ ਠੀਕ ਹੋਣ ਤੋਂ ਬਾਅਦ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਛੋਟਾ ਰੋਲ ਮਾਡਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਲੋੜ ਅਨੁਸਾਰ ਵਧਾਓ:
ਸਧਾਰਣ ਰੋਲ ਐਜ ਬਹੁਤਾਂ ਸਾਈਡ-ਕੇਸ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਵਧੀਆ ਓਨਬੋਰਡਿੰਗ ਦਿੰਦੇ ਹਨ।
ਇਹ ਕੰਮ ਤੇਜ਼ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ (ਘੱਟ ਟੈਪ, ਘੱਟ ਟਾਈਪਿੰਗ):
ਜੇ ਸੇਵਾਦਾਰ seconds ਵਿੱਚ "ਮੈਂ ਕਿੱਥੇ ਜਾਣਾ ਹੈ?" ਅਤੇ "ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ?" ਦੇ ਜਵਾਬ ਨਾ ਲੱਭ ਸਕਣ, ਤਾਂ ਹੋਰ ਫੀਚਰ ਵੀ ਮਦਦ ਨਹੀਂ ਕਰਨਗੇ।
UI ਤੋਂ ਪਹਿਲਾਂ ਨਿਯਮ ਪਰਿਭਾਸ਼ਤ ਕਰੋ:
ਸਪੱਸ਼ਟ ਨਿਯਮ ਨੋਟੀਫਿਕੇਸ਼ਨ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
ਘੱਟ ਤੋਂ ਘੱਟ, ਇਹ ਕੋਰ ਐਂਟਿਟੀ ਸਟੋਰ ਕਰੋ:
ਇਹਨਾਂ ਫ਼ੀਲਡز ਨਾਲ ਆਮ ਰੀਅਲ-ਵਰਲਡ ਗਲਤੀਆਂ ਰੋਕੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ:
ਤੁਰੰਤ ਅਤੇ ਵਿਤਤੀਆਂ ਦੀ ਸੂਚਨਾ ਦੇ ਅਨੁਸਾਰ ਚੈਨਲ ਚੁਣੋ:
ਗਾਰਡਰੇਲ:
ਕਈ ਤਰੀਕੇ ਦੀਆਂ ਚੋਣਾਂ ਦਿਓ:
ਅਫਲਾਈਨ-ਸਹਿਣਸ਼ੀਲਤਾ ਲਈ ਚੇਕ-ਇਨ ਲੋਕਲ ਰੂਪ ਵਿੱਚ ਕਯੂ (queued) ਕਰੋ ਅਤੇ ਜਦੋਂ ਡਿਵਾਈਸ ਕੰਨੈਕਟ ਹੋ ਜਾਵੇ ਤਾਂ ਆਟੋ-ਸਿੰਕ ਕਰੋ।
ਭਰੋਸੇਯੋਗ ਘੰਟਿਆਂ ਲਈ ਸਪੱਸ਼ਟ ਨਿਯਮ ਤੇ ਕੁਝ ਮੁੱਖ ਫ਼ੀਲਡਜ਼:
ਨਿਰਯਾਤ ਲਈ ਪਹਿਲਾਂ CSV ਮੁਹੱਈਆ ਕਰੋ, ਫਿਲਟਰਾਂ ਜਿਵੇਂ- ਵਿਅਕਤੀ-ਵਾਰ ਘੰਟੇ, ਪ੍ਰੋਗਰਾਮ/ਇਵੈਂਟ ਦੇ ਅਨੁਸਾਰ, ਅਤੇ ਮਿਆਦ-ਵਾਰ।
ਸਧਾਰਨ ਪਰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਨਿਯਮਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਸੁਰੱਖਿਆ ਮੂਲ-ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ:
ਇਹ ਮਾਡਲ ਰਿਪੋਰਟਿੰਗ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਸੁਨੇਹਿਆਂ ਤੋਂ ਐਕਸ਼ਨ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿਓ: ਕਨਫਰਮ, ਰੱਦ, ਜਾਂ ਸਵੈਪ ਬੇਨਤੀ ਐਪ ਦੇ ਅੰਦਰ।
ਆਪਰੇਸ਼ਨਲ ਪ੍ਰਕਿਰਿਆਵਾਂ ਜਿਵੇਂ ਅਕਾਊਂਟ ਮਿਟਾਅਨ ਦੀ ਬੇਨਤੀ ਅਤੇ ਪਹੁੰਚ ਸਮੀਖਿਆ ਦੀ ਅੰਕਿਤ ਨੀਤੀ ਵਧੀਆ ਰੱਖੋ।
