ਯੋਜਨਾ ਬਣਾਓ, ਡਿਜ਼ਾਈਨ ਕਰੋ ਅਤੇ OKR ਟਰੈਕਿੰਗ ਵੈੱਬ ਐਪ ਸ਼ਿਪ ਕਰੋ: ਡੇਟਾ ਮਾਡਲ, ਰੋਲ, ਚੈਕ-ਇਨ, ਡੈਸ਼ਬੋਰਡ, ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਅਤੇ ਵੀਜ਼਼ਾ-ਸੁਰੱਖਿਆ ਲਈ ਸਾਹਮਣਾ ਕਰੋ ਤਾਂ ਕਿ ਟੀਮਾਂ ਵਿਚਕਾਰ ਸੰਰੇਖਣ ਹੋ ਸਕੇ।
OKR ਟਰੈਕਿੰਗ ਐਪ ਡਿਜ਼ਾਈਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸੁਨਿਸ਼ਚਿਤ ਕਰੋ ਕਿ ਇਹ ਕਿਸ ਲਈ ਹੈ ਅਤੇ “ਸਫਲਤਾ” ਕੀ ਮੰਨੀ ਜਾਵੇਗੀ। ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਐਸਾ ਐਪ ਬਣਾਓਗੇ ਜੋ ਹਰ ਕਿਸੇ ਨੂੰ ਖੁਸ਼ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ—ਪਰ ਜ਼ਿਆਦातर ਲਈ ਗੁੰਝਲਦਾਰ ਬਣਕੇ ਰਹੇਗਾ।
OKR ਸਿਸਟਮ ਵੱਖ-ਵੱਖ ਲੋਕਾਂ ਵੱਲੋਂ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ:
v1 ਲਈ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਦਰਸ਼ਕ ਚੁਣੋ (ਅਕਸਰ ਟੀਮ ਅਤੇ ਡਿਪਾਰਟਮੈਂਟ ਲੀਡ) ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਹੋਰ ਰੋਲਾਂ ਵੀ ਬੁਨੀادي ਕੰਮ ਕਰ ਸਕਣ।
Objective ਅਤੇ Key Results ਸਾਫਟਵੇਅਰ ਲਈ ਮੂੜ-ਲੋੜੀਂਦੀਆਂ ਨੌਕਰੀਆਂ:
ਸਪਸ਼ਟ ਕਰੋ ਕਿਹੜੀ ਘੱਟੋ-ਘੱਟ ਸਕੇਲ ਸਮਰਥਨ ਦੀ ਲੋੜ ਹੈ: ਕਈ ਡਿਪਾਰਟਮੈਂਟ, ਕ੍ਰਾਸ-ਫੰਕਸ਼ਨਲ ਟੀਮਾਂ, ਸਾਂਝੇ Objectives ਅਤੇ ਟੀਮ/ਡਿਪਾਰਟਮੈਂਟ ਵਾਰ ਰੋਲਅਪਸ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਸ਼ੁਰੂ ਤੋਂ ਕ੍ਰਾਸ-ਟੀਮ ਐਲਾਈਨਮੈਂਟ ਲਿੰਕ ਨਹੀਂ ਹਨ, ਤਾਂ ਇਹ ਬਤਾਓ—ਅਤੇ ਦਾਇਰਾ ਟੀਮ-ਅੰਦਰ ਟਰੈਕਿੰਗ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ।
ਮਾਪੇ ਜਾ ਸਕਣ ਵਾਲੇ ਮੈਟ੍ਰਿਕ ਚੁਣੋ:
ਇਹਨਾਂ ਨੂੰ ਆਪਣੀਆਂ ਸ਼ਰਤਾਂ ਵਿੱਚ ਲਿਖੋ ਤਾਂ ਕਿ ਹਰ ਫੀਚਰ ਫੈਸਲਾ ਨਤੀਜਿਆਂ ਨਾਲ ਜੁੜਿਆ ਰਹੇ।
ਸਕਰੀਨ ਜਾਂ ਡੇਟਾਬੇਸ ਡਿਜ਼ਾਈਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਸੰਗਠਨ ਵਿੱਚ “OKR” ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਜੇ ਟੀਮਾਂ ਸ਼ਬਦਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਸਮਝਦੀਆਂ ਹਨ, ਤਾਂ ਤੁਹਾਡੀ OKR ਟਰੈਕਿੰਗ ਐਪ ਇਕ ਅਜਿਹੀ ਰਿਪੋਰਟਿੰਗ ਟੂਲ ਬਣ ਜਾਏਗੀ ਜਿਸ 'ਤੇ ਕੋਈ ਭਰੋਸਾ ਨਹੀਂ ਕਰੇਗਾ।
ਸੁਰੂਆਤ ਵਿੱਚ ਸਪਸ਼ਟ ਪਰਿਭਾਸ਼ਾਵਾਂ ਲਿਖੋ ਜੋ ਪ੍ਰੋਡਕਟ ਕਾਪੀ, ਹੈਲਪ ਟੈਕਸਟ ਅਤੇ ਆਨਬੋਰਡਿੰਗ ਵਿੱਚ ਦਿਖਾਈ ਜਾਣ ।
Objective: ਇੱਕ ਗੁਣਾਤਮਕ, ਨਤੀਜੇ-ਕੇਂਦ੍ਰਤ ਲਕਸ਼ (ਅਸੀਂ ਕੀ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ)।
Key Result: ਇੱਕ ਮਾਪਣ ਯੋਗ ਨਤੀਜਾ ਜੋ Objective ਵੱਲ ਤਰੱਕੀ ਦਿਖਾਉਂਦਾ ਹੈ (ਅਸੀਂ ਕਿਵੇਂ ਜਾਣਾਂ ਕਿ ਅਸੀਂ ਹਾਸਲ ਕੀਤਾ)।
Initiative (ਵਿਕਲਪਿਕ): ਉਹ ਕੰਮ ਜਾਂ ਪ੍ਰੋਜੈਕਟ ਜੋ Key Results ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਲਈ ਕੀਤੇ ਜਾਂਦੇ ਹਨ (ਅਸੀਂ ਕੀ ਕਰਦੇ ਹਾਂ)। ਪਹਲੇ ਹੀ ਫੈਸਲਾ ਕਰੋ ਕਿ initiatives ਤੁਹਾਡੇ ਐਪ ਦੇ ਦਾਇਰੇ ਵਿੱਚ ਹਨ ਜਾਂ ਨਹੀਂ।
ਜੇ ਤੁਸੀਂ initiatives ਸ਼ਾਮਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਉਹ KRs ਵਾਂਗਿ achievement ਨੂੰ "ਰੋਲ ਅਪ" ਨਹੀਂ ਕਰਨਗੇ। ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਸਰਗਰਮੀ ਨੂੰ ਨਤੀਜੇ ਸਮਝ ਬੈਠਦੀਆਂ ਹਨ; ਤੁਹਾਡੀਆਂ ਪਰਿਭਾਸ਼ਾਵਾਂ ਇਹ ਗ਼ਲਤੀ ਰੋਕਣਗੀਆਂ।
ਤੁਹਾਡੇ ਡੈਸ਼ਬੋਰਡ ਦੀ ਸਹੀਅਤ ਉਸ ਦੀ ਸਕੋਰਿੰਗ ਨੀਤੀ ਤੇ ਨਿਰਭਰ ਕਰੇਗੀ। ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਸਕੋਰਿੰਗ ਵਿਧੀ ਚੁਣੋ ਅਤੇ ਹਰ ਜਗ੍ਹਾ ਲਾਗੂ ਕਰੋ:
ਫਿਰ ਰੋਲਅਪ ਨਿਰਧਾਰਤ ਕਰੋ (ਕਿਸ ਤਰ੍ਹਾਂ ਸਕੋਰ ਇਕੱਠੇ ਹੁੰਦੇ ਹਨ):
ਇਹ ਨਿਯਮ ਉਤਪਾਦ ਦੀਆਂ ਲੋੜਾਂ ਵਿੱਚ ਲਿਖ ਕੇ ਰੱਖੋ ਤਾਂ ਜੋ analytics ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਵਿੱਚ ਇੱਕਸਾਰਤਾ ਬਣੀ ਰਹੇ।
ਆਪਣਾ ਸਮੇਂ ਦਾ cadence ਨਿਰਧਾਰਤ ਕਰੋ: ਤਿਮਾਹੀ, ਮਹੀਨਾਵਾਰ, ਜਾਂ ਕਸਟਮ ਸਾਈਕਲ। ਤੁਹਾਡਾ OKR check-in ਵਰਕਫਲੋ ਇਸ ਉੱਤੇ ਨਿਰਭਰ ਕਰੇਗਾ।
ਦਸਤਾਵੇਜ਼ ਬਣਾਓ:
ਇਹ ਫੈਸਲੇ ਫਿਲਟਰ, ਪਰਮਿਸ਼ਨ ਅਤੇ OKR ਵਿਸ਼ਲੇਸ਼ਣ ਵਿੱਚ ਇਤਿਹਾਸਕ ਤੁਲਨਾਵਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨਗੇ।
ਨਾਮਕਰਨ ਛੋਟੀ ਗੱਲ ਲੱਗਦੀ ਹੈ, ਪਰ ਇਹ “ਟੀਮ ਸਹਿਮਤੀ” ਅਤੇ ਅਸਪਸ਼ਟ ਸਿਰਲਖਾਂ ਵਿੱਚ ਫ਼ਰਕ ਪੈਦਾ ਕਰਦੀ ਹੈ।
ਕਨਵੰਸ਼ਨਾਂ ਦੀ ਸਥਾਪਨਾ ਕਰੋ ਜਿਵੇਂ:
ਇਹ ਕਨਵੰਸ਼ਨ UI ਵਿੱਚ ਦਿੱਖਣਗੀਆਂ ਹੋਣ (ਪਲੇਸਹੋਲਡਰ, ਉਦਾਹਰਣ, ਵੈਲਿਡੇਸ਼ਨ ਹਿੰਟ) ਤਾਂ ਜੋ OKRs ਟੀਮਾਂ ਅਤੇ ਡਿਪਾਰਟਮੈਂਟਾਂ ਵਿੱਚ ਪੜ੍ਹਨਯੋਗ ਰਹਿਣ।
IA ਉਹ ਸਥਾਨ ਹੈ ਜਿੱਥੇ OKR ਟਰੈਕਿੰਗ ਐਪ obvious ਲੱਗਦੀ ਹੈ—ਜਾਂ ਤੁਰੰਤ ਹੀ ਗੁੰਝਲਦਾਰ। ਤੁਹਾਡਾ ਲਕਸ਼ ਹੈ ਕਿ ਕਿਸੇ ਉਪਭੋਗਤਾ ਨੂੰ ਤੁਰੰਤ ਤਿੰਨ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਮਿਲ ਜਾਣ: “ਮੇਰੇ OKRs ਕੀ ਹਨ?”, “ਮੇਰੀ ਟੀਮ ਕਿਵੇਂ ਕਰ ਰਹੀ ਹੈ?”, ਅਤੇ “ਕੀ ਅਸੀਂ ਕੰਪਨੀ ਦੇ ਤੌਰ ਤੇ ਟਰੈਕ 'ਤੇ ਹਾਂ?”
ਛੋਟੀ ਤੇ ਕੇਂਦਰੀ ਸਕ੍ਰੀਨਾਂ ਦੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਮੇਨ ਨੈਵੀਗੇਸ਼ਨ ਤੋਂ ਇਕ ਕਲਿੱਕ 'ਤੇ ਪੁੱਜਣਯੋਗ ਰੱਖੋ:
ਸੈਕੰਡਰੀ ਕਰਵਾਈਆਂ (export, duplicate, archive) ਨੂੰ ਸੰਬੰਧਤ ਸਕ੍ਰੀਨ ਦੇ ਮੀਨੂ ਵਿੱਚ ਰੱਖੋ, ਗਲੋਬਲ ਨੈਵੀਗੇਸ਼ਨ ਵਿੱਚ ਨਹੀਂ।
ਜ਼ਿਆਦਾਤਰ ਉਪਭੋਗਤਾ ਇਹ ਤਿੰਨ ਲੈਂਸ ਵਿਚ ਸੋਚਦੇ ਹਨ। UI ਵਿੱਚ ਇਹਨਾਂ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਓ—ਟਾਪ-ਲੈਵਲ ਟੈਬਾਂ ਵਾਂਗ ਜਾਂ ਇਕ ਸਥਾਈ ਸਵਿਚਰ ਦੇ ਤੌਰ 'ਤੇ:
ਢਿੱਲ੍ਹਾ ਸੋਚ ਘਟਾਉਣ ਲਈ ਡਿਫਾਲਟ ਲੈਂਡਿੰਗ ਦ੍ਰਿਸ਼ "My OKRs" ਰੱਖੋ।
Objectives, Key Results ਅਤੇ ਲੋਕਾਂ 'ਤੇ ਕੰਮ ਕਰਨ ਵਾਲੀ ਗਲੋਬਲ ਸਰਚ ਜੋੜੋ। ਇਸਨੂੰ ਆਸਾਨ ਫਿਲਟਰਾਂ ਨਾਲ ਜੋੜੋ ਜੋ OKRs ਨੂੰ ਮੈਨੇਜ ਕਰਨ ਦੇ ਤਰੀਕੇ ਨਾਲ ਮਿਲਦੇ ਹਨ: cycle, owner, status, department, ਅਤੇ tags।
ਗੈਰ-ਟਕਨੀਕੀ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਫਲੋ ਛੋਟੇ ਰੱਖੋ: ਸਪਸ਼ਟ ਲੇਬਲ ("Create Objective", "Add Key Result"), ਮਜ਼ਬੂਤ ਡਿਫਾਲਟ (ਮੌਜੂਦਾ ਸਾਈਕਲ), ਅਤੇ ਘੱਟ ਜ਼ਰੂਰੀ ਫੀਲਡ। ਇੱਕ ਯੂਜ਼ਰ ਇੱਕ OKR ਬਣਾਉਣ ਅਤੇ ਚੈਕ-ਇਨ ਪੋਸਟ ਕਰਨ ਵਿੱਚ ਇੱਕ ਮਿੰਟ ਤੋਂ ਘੱਟ ਸਮੇਂ ਲੈ ਸਕਦਾ ਹੈ।
ਇੱਕ ਸਕੇਲਬਲ OKR ਐਪ ਇੱਕ ਸਾਫ਼, ਲਗਾਤਾਰ ਡੇਟਾ ਮਾਡਲ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਜੇ ਢਾਂਚਾ ਗੁੰਝਲਦਾਰ ਹੋਏ ਤਾਂ ਐਲਾਈਨਮੈਂਟ ਟੁੱਟੇਗਾ, ਰਿਪੋਰਟਿੰਗ ਧੀਮੀ ਹੋਵੇਗੀ, ਅਤੇ ਪਰਮਿਸ਼ਨ ਜਟਿਲ ਹੋ ਜਾਣਗੇ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਇੱਕ ਛੋਟੇ ਸੈੱਟ ਨਾਲ 80% ਲੋੜਾਂ ਕਵਰ ਕਰ ਸਕਦੀਆਂ ਹਨ:
ਆਪਲੀਕੇਸ਼ਨ ਨੂੰ ਭਰੋਸੇਯੋਗ ਅਤੇ ਸਹਿਯੋਗੀ ਬਣਾਉਣ ਲਈ OKRs ਦੇ ਇਤਿਹਾਸ ਨੂੰ ਸਟੋਰ ਕਰੋ:
ਜਦੋਂ ਵਧੇਰੇ ਟੀਮਾਂ ਮਿਲ ਕੇ ਕੰਮ ਕਰਦੀਆਂ ਹਨ ਤਾਂ OKRs ਜ਼ਿਆਦਾ ਜਟਿਲ ਹੋ ਜਾਂਦੇ ਹਨ। ਇਹ ਰਿਸ਼ਤੇ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਮਾਡਲ ਕਰੋ:
ਹਰ Key Result ਲਈ ਸਟੋਰ ਕਰੋ:
ਤੇਜ਼ ਡੈਸ਼ਬੋਰਡ ਲਈ latest “current value” ਨੂੰ KR ਰਿਕਾਰਡ 'ਤੇ ਰੱਖੋ, ਅਤੇ ਹਰ check-in ਨੂੰ ਟਾਈਮਲਾਈਨ ਅਤੇ ਰੋਲਅਪਸ ਲਈ ਸੱਚਾਈ ਦਾ ਸਰੋਤ ਬਣਾਓ।
ਛੰਗੀ OKR ਐਪ ਸਿਰਫ Objectives ਦੀ ਸੂਚੀ ਨਹੀਂ—ਇਹ ਤੁਹਾਡੇ ਕੰਪਨੀ ਦੇ ਅਸਲ ਤਰੀਕੇ ਦਾ ਪਰਿਚੇਕ ਹੈ। ਜੇ ਉਤਪਾਦ ਵਿੱਚ org chart ਬਹੁਤ ਕਠੋਰ (ਤਾਕਿ) ਜਾਂ ਬਹੁਤ ਢਿੱਲਾ ਹੋਵੇ ਤਾਂ ਐਲਾਈਨਮੈਂਟ ਟੁੱਟ ਸਕਦਾ ਹੈ ਅਤੇ ਲੋਕ ਜੋ ਉਹ ਦੇਖ ਰਹੇ ਹਨ ਉਤੇ ਭਰੋਸਾ ਘੱਟ ਹੋ ਜਾਵੇਗਾ।
ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਬੁਣਿਆਦੀ ਕੀਮਤਾਂ ਨਾਲ ਸਹੀ ਕਰੋ: departments ਅਤੇ teams। ਫਿਰ ਹਕੀਕਤੀ ਜਟਿਲਤਾ ਲਈ ਯੋਜਨਾ ਬਣਾਓ:
ਇਹ ਢਾਂਚਾ ਹਰ ਚੀਜ਼ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ: ਕੌਣ ਕਿਹੜੇ OKRs ਵੇਖ ਸਕਦਾ ਹੈ, ਰੋਲਅਪਸ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ, ਅਤੇ ਲੋਕ ਸਹੀ ਥਾਂ 'ਤੇ ਚੈਕ-ਇਨ ਕਿਵੇਂ ਕਰਦੇ ਹਨ।
Admin ਲਈ ਪ੍ਰਬੰਧਨ ਆਸਾਨ ਰਹਿਣ ਲਈ role-based access control ਸਧਾਰਨ ਰੱਖੋ, ਪਰ ਕਾਫੀ ਵਿਸਥਿਤ ਵੀ ਹੋਵੇ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਬੇਸਲਾਈਨ:
"ਸਭ ਨੂੰ ਹਰ ਚੀਜ਼ ਸੋਧਣ ਦੀ ਆਜ਼ਾਦੀ" ਤੋਂ ਬਚੋ — ਇਹ ਜਾਂ ਪਰੇਸ਼ਾਨੀ ਵਾਲੇ ਬਦਲਾਅ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜਾਂ ਲਗਾਤਾਰ "ਕਿਸ ਨੇ ਇਹ ਬਦਲਿਆ?" ਦੀ ਗੱਲ ਚੱਲਦੀ ਰਹੇਗੀ।
ਕੁਝ ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੇ ਐਕਸ਼ਨਾਂ ਬਾਰੇ ਸਪਸ਼ਟ ਹੋਵੋ:
ਇੱਕ ਆਮ ਪੈਟਰਨ: admins cycles ਬਣਾ ਦਿੰਦਿਆਂ ਹਨ, department editors ਉਹਨਾਂ ਦੇ ਖੇਤਰਾਂ ਵਿੱਚ publish ਕਰਦੇ ਹਨ, ਅਤੇ locking/archiving admins (ਜਾਂ ਛੋਟੀ ops ਟੀਮ) ਤੱਕ ਸੀਮਿਤ ਰਹਿੰਦਾ ਹੈ।
ਵਿਜ਼ਿਬਿਲਟੀ ਲਚਕੀਲਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
UI ਵਿੱਚ ਵਿਜ਼ਿਬਿਲਟੀ ਸਪਸ਼ਟ ਰੱਖੋ (ਬੈਜ + ਸ਼ੇਅਰਿੰਗ ਸਾਰਾਂਸ਼) ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਇਹ ਸਿਰਫ OKR ਪੇਜ਼ 'ਤੇ ਹੀ ਨਹੀਂ ਪਰ ਸਰਚ, ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਐਕਸਪੋਰਟ ਵਿੱਚ ਵੀ lagu ਕੀਤੀ ਜਾਂਦੀ ਹੈ।
ਇੱਕ ਸਪਸ਼ਟ ਲਾਈਫਸਾਇਕਲ ਤੁਹਾਡੀ OKR ਐਪ ਨੂੰ ਟੀਮਾਂ ਵਿੱਚ ਇੱਕਸਾਰ ਬਣਾਉਂਦੀ ਹੈ। ਬਿਨਾਂ ਇਸਦੇ ਲੋਕ ਵੱਖ-ਵੱਖ ਫਾਰਮੈਟਾਂ ਵਿੱਚ ਟੀਚੇ ਬਣਾਉਂਦੇ ਰਹਿਣਗੇ, ਅਪਡੇਟ ਆਕਸਮਿਕ ਤਰੀਕੇ ਨਾਲ ਹੋਣਗੇ, ਅਤੇ "ਮੁਕੰਮਲ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ ਇਸ 'ਤੇ ਵਿਵਾਦ ਹੋਵੇਗਾ। ਛੋਟੀ ਵਰਕਫਲੋ ਸਥਿਤੀਆਂ ਨਿਰਧਾਰਤ ਕਰੋ ਅਤੇ ਹਰ ਸਕ੍ਰੀਨ (creation, editing, check-ins, reports) ਵਿੱਚ ਉਹਨਾਂ ਦੀ ਪਾਲਣਾ ਕਰੋ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਡਿਫਾਲਟ ਲਾਈਫਸਾਇਕਲ ਹੈ:
Draft → Review → Published → In progress → Closed
ਹਰ ਸਥਿਤੀ ਨੂੰ ਤਿੰਨ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ:
ਉਦਾਹਰਨ ਵਜੋਂ, Draft ਨੂੰ ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਨਿੱਜੀ ਰੱਖੋ, ਫਿਰ Published ਨੂੰ ਰੋਲਅਪਸ ਅਤੇ OKR ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਦਿਖਾਓ ਤਾਂ ਕਿ ਲੀਡਰਸ਼ਿਪ ਦੇ ਨਜ਼ਰਾਂ 'ਚ ਅਧੂਰੇ ਕੰਮ ਪੈਰਾਓ ਨਾ ਕਰਨ।
ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਨੂੰ OKRs ਨੂੰ "ਅਸਲ" ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਹਲਕੇ ਗੇਟਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਸੰਰਚਨਾਤਮਕ ਸਮੀਖਿਆ ਕਦਮ ਜੋੜੋ ਜਿਵੇਂ:
ਐਪ ਵਿੱਚ ਸਮੀਖਿਆ ਇੱਕ ਸਪਸ਼ਟ ਕਾਰਵਾਈ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ (Approve / Request changes) ਇੱਕ ਟਿੱਪਣੀ ਬਾਕਸ ਨਾਲ, ਨਾ ਕਿ ਅਨੁਪਚਾਰੀ Slack ਸੁਨੇਹਿਆਂ ਵਰਗੇ। ਫੀਡਬੈਕ ਦੇ ਬਾਅਦ ਕੀ ਹੁੰਦਾ ਹੈ ਇਹ ਵੀ ਤੈਅ ਕਰੋ: ਆਮ ਤੌਰ 'ਤੇ Review → Draft (ਨੋਟਸ ਦੇ ਨਾਲ) ਜਦ ਤੱਕ ਦੁਬਾਰਾ ਸਬਮਿਟ ਨਾ ਕੀਤਾ ਜਾਵੇ।
ਤਿਮਾਹੀ ਦੇ ਅਖ਼ੀਰ 'ਤੇ, ਯੂਜ਼ਰ ਕੰਮ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤਾਉਣਾ ਚਾਹੁੰਦੇ ਹਨ ਬਿਨਾਂ ਇਤਿਹਾਸ ਗੁਆਏ। ਤਿੰਨ ਵੱਖ-ਵੱਖ ਐਕਸ਼ਨਾਂ ਦੀ ਸਹਾਇਤਾ ਕਰੋ:
ਇਹ ਕਾਰਵਾਈਆਂ ਸਾਈਕਲ ਬੰਦ ਕਰਨ ਵਾਲੇ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਦਿੱਖਣਗੀਆਂ ਹੋਣ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਰੋਲਅਪਸ clones ਨੂੰ double-count ਨਾ ਕਰਨ।
ਟਾਰਗਟ ਬਦਲ ਸਕਦੇ ਹਨ। ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਇਹ ਰਿਕਾਰਡ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿਸਨੇ ਕੀ ਬਦਲਿਆ, ਕਦੋਂ, ਅਤੇ ਕਿਉਂ—ਖਾਸ ਕਰਕੇ Key Result ਬੇਸਲਾਈਨ ਅਤੇ ਟਾਰਗਟ ਮੁੱਲਾਂ ਲਈ। ਫੀਲਡ-ਸਟੇਪ ਡਿਫਸ (old value → new value) ਅਤੇ ਵਿਕਲਪਿਕ ਨੋਟਸ ਰੱਖਣ ਵਾਲਾ ਆਡੀਟ ਟਰੇਲ ਰੱਖੋ।
ਇਹ ਆਡੀਟ ਇਤਿਹਾਸ ਭਰੋਸਾ ਬਣਾਉਂਦਾ ਹੈ: ਟੀਮਾਂ ਚਰਚਾ ਕਰ ਸਕਦੀਆਂ ਹਨ ਬਿਨਾਂ ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਰਿਹਾ ਕਿ ਲਕਸ਼ ਬਦਲੇ ਗਏ ਸਨ।
ਇੱਕ ਵਧੀਆ OKR ਐਪ ਇਸ ਗੱਲ 'ਤੇ ਟਿਕਦਾ/ਟਿਕਦੀ ਹੈ ਕਿ ਚੰਗਾ Objective ਲਿਖਣਾ, ਮਾਪਣਯੋਗ Key Results ਡਿਫਾਈਨ ਕਰਨਾ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਹੋਰ ਟੀਮਾਂ ਨਾਲ ਜੋੜਨਾ ਕਿੰਨਾ ਆਸਾਨ ਹੈ। UX ਨੂੰ ਇੱਕ ਗਾਈਡਡ ਲਿਖਤ ਵਾਂਗ ਮਹਿਸੂਸ ਕਰਵਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਨਾ ਕਿ "ਡੇਟਾਬੇਸ ਭਰੀਏ" ਜਿਹਾ।
ਇੱਕ ਸਾਫ, ਦੋ-ਭਾਗੀ ਫਾਰਮ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: Objective (ਸਪਸ਼ਟ ਨਤੀਜਾ) ਅਤੇ Key Results (ਮਾਪਣ ਯੋਗ ਸੰਕੇਤ)। ਸਧਾਰਨ ਲੇਬਲ ਵਰਤੋ ਅਤੇ ਛੋਟੇ, ਇੰਲਾਈਨ ਪ੍ਰਾਂਪਟ ਦਿਓ ਜਿਵੇਂ "ਬਦਲਾਅ ਦਾ ਵਰਣਨ ਕਰੋ" ਜਾਂ "ਇੱਕ ਨੰਬਰ + ਡੈਡਲਾਈਨ ਵਰਤੋ"।
ਬਣਾਉਣ ਦੌਰਾਨ ਰੀਅਲ-ਟਾਈਮ ਵੈਲਿਡੇਸ਼ਨ ਦਿਖਾਓ ਜੋ ਸਿੱਖਾਉਂਦਾ ਹੈ ਪਰ ਰੋਕਦਾ ਨਹੀਂ—ਉਦਾਹਰਨ ਲਈ agar Key Result ਕੋਲ ਕੋਈ ਮੈਟਰਿਕ ਨਾ ਹੋਵੇ ਤਾਂ ਚੇਤਾਵਨੀ ਦਿਖਾਓ ("ਕਿਹੜਾ ਮਾਪ, ਕਿੰਨਾ")। ਆਮ KR ਕਿਸਮਾਂ ਲਈ ਇਕ-ਕਲਿੱਕ ਟੌਗਲ (number, %, $) ਦਿਓ ਅਤੇ ਫੀਲਡ ਦੇ ਕੋਲ ਹੀ ਉਦਾਹਰਣ ਦਿਖਾਓ।
ਡਿਪਾਰਟਮੈਂਟ-ਵਾਰ (Sales, Product, HR) ਅਤੇ ਥੀਮ-ਵਾਰ (Growth, Reliability, Customer Satisfaction) ਟੈਮਪਲੇਟ ਦਿਓ। ਯੂਜ਼ਰ ਨੂੰ ਟੈਮਪਲੇਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਦਿਓ, ਫਿਰ ਸਭ ਕੁਝ ਸੋਧਣ ਦੀ ਛੋੜ। ਟੈਮਪਲੇਟ OKR ਸਾਫ਼ ਕਰਨ ਵਾਲੀਆਂ ਭਾਸ਼ਾਵਾਂ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਅਡਾਪਸ਼ਨ ਤੇਜ਼ ਕਰਦੇ ਹਨ।
ਪਿਛਲੇ ਤਿਮਾਹੀ ਦੇ OKRs ਨੂੰ searchable ਰੱਖੋ ਤਾਂ ਜੋ ਲੋਕ ਪੈਟਰਨ ਦੁਹਰਾਉਣ ਅਤੇ ਨਕਲ ਕਰਨ ਦੇ ਨਾਲ-ਨਾਲ ਸੁਝਾਅ ਵੀ ਲੈ ਸਕਣ।
ਐਲਾਈਨਮੈਂਟ ਨੂੰ ਵੱਖ-ਵੱਖ ਕਦਮ ਨਾ ਬਣਾ। OKR ਬਣਾਉਂਦੇ ਸਮੇਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਯੋਗ ਬਣਾਓ:
ਇਸ ਨਾਲ ਟੀਮ ਐਲਾਈਨਮੈਂਟ ਉਪਰ-ਸਿਰੇ ਤੇ ਰਹੇਗਾ ਅਤੇ ਆੱਗੇ ਚਲ ਕੇ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਰੋਲਅਪਸ ਸੁਧਰ ਜਾਣਗੇ।
ਸੋਧਾਂ ਨੂੰ ਸਧਾਰਨ ਮੰਨੋ। Autosave ਜੋੜੋ, ਅਤੇ "ਵਰਜ਼ਨ ਨੋਟਸ" (ਉਦਾਹਰਨ: "Pricing change ਤੋਂ ਬਾਅਦ ਟਾਰਗਟ ਥੋੜਾ ਘਟਾਇਆ") ਵਰਗੇ ਹਲਕੇ ਇਤਿਹਾਸ ਬਰਕਰਾਰ ਰੱਖੋ। ਇੱਕ ਸਾਫ਼ ਚੇਂਜ ਲੌਗ ਦਿਖਾਓ ਤਾਂ ਟੀਮਾਂ ਚੈੱਕ-ਇਨ ਵਰਕਫਲੋ ਦੌਰਾਨ ਬਦਲਾਅ 'ਤੇ ਭਰੋਸਾ ਰੱਖ ਸਕਣ।
ਐਪ ਸਿਰਫ਼ ਸੁੰਦਰ ਡੈਸ਼ਬੋਰਡ ਰੱਖ ਕੇ ਕੰਮ ਨਹੀਂ ਕਰੇਗੀ—ਇਹ ਤਾਂ ਵਰਤੀ ਜਾਵੇਗੀ ਜੇ ਟੀਮਾਂ ਆਸਾਨੀ ਨਾਲ ਅੱਪਡੇਟ ਕਰਨ। ਚੈਕ-ਇਨ ਦਾ ਉਦੇਸ਼ ਹੈ ਹਕੀਕਤ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਕੈਪਚਰ ਕਰਨਾ—ਤਾਂ ਜੋ ਤਰੱਕੀ, ਖ਼ਤਰੇ ਅਤੇ ਫੈਸਲੇ ਦਰਸ਼ਨੀ ਰਹਿਣ ਬਿਨਾਂ ਹਫਤਾਵਾਰੀ ਕਾਗਜ਼-ਕਰਵਾਈ ਵਿੱਚ ਫੱਸਣ ਦੇ।
ਹਰ Key Result ਲਈ ਇੱਕ ਇਕ-ਕੁਝ-ਅੰਕ ਚੱਕਰ ਡਿਜ਼ਾਈਨ ਕਰੋ:
ਫਾਰਮ ਛੋਟਾ ਰੱਖੋ, ਡ੍ਰਾਫਟ ਸੇਵਿੰਗ ਆਸਾਨ ਹੋਵੇ, ਅਤੇ ਪਿਛਲੇ ਹਫ਼ਤੇ ਦਾ ਸੰਦਰਭ ਅੱਗੇ ਭਰਿਆ ਹੋਇਆ ਹੋਵੇ ਤਾਂ ਲੋਕ ਸਿਫ਼ਰ ਤੋਂ ਸ਼ੁਰੂ ਨਾ ਕਰਣ।
Objectives, Key Results, ਅਤੇ ਵਿਅਕਤੀਗਤ check-ins 'ਤੇ comments ਸ਼ਾਮਲ ਕਰੋ। @mentions ਸਹਾਇਤਾ ਦਿਓ ਤਾਂ ਸਹੀ ਲੋਕਾਂ ਨੂੰ ਬਿਨਾਂ मीਟਿੰਗਾਂ ਦੇ ਖਿੱਚਿਆ ਜਾ ਸਕੇ, ਅਤੇ ਸਧਾਰਨ “decision log” ਪੈਟਰਨ ਦਿਓ: ਇੱਕ ਟਿੱਪਣੀ ਨੂੰ decision ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਮਿਤੀ ਅਤੇ ਮਾਲਕ ਦੇ ਨਾਲ, ਤਾਂ ਜੋ ਬਾਅਦ ਵਿੱਚ “ਅਸੀਂ ਦਿਸ਼ਾ ਕਿਉਂ ਬਦਲੀ?” ਨੂੰ ਜਵਾਬ ਮਿਲ ਜਾਵੇ।
ਯੂਜ਼ਰਾਂ ਨੂੰ evidence links (docs, tickets, dashboards) ਲਗਾਉਣ ਦਿਓ ਬਿਨਾਂ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਦੇ ਮੁਸ਼ਕਲਾਂ ਦੇ। ਇੱਕ URL ਫੀਲਡ ਅਤੇ ਵਿਕਲਪਿਕ ਲੇਬਲ ("Jira ticket", "Salesforce report", "Spreadsheet") ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ। ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਟਾਈਟਲ ਆਟੋ-ਫੈਚ ਕਰੋ ਪਰ ਮੈਟਾਡੇਟਾ ਫੇਲ ਹੋਣ 'ਤੇ ਸੇਵ ਕਰਨ ਤੋਂ ਰੋਕੋ ਨਾ।
ਵਿਆਸਤ ਟੀਮਾਂ ਕਾਲਾਂ ਦੇ ਵਿਚਕਾਰ ਚੈਕ-ਇਨ ਕਰਦੀਆਂ ਹਨ। ਫੋਨਾਂ ਲਈ optimize ਕਰੋ: ਵੱਡੇ ਟੈਪ ਟਾਰਗਟ, ਘੱਟ ਟਾਈਪਿੰਗ, ਅਤੇ ਇੱਕ-ਸਕ੍ਰੀਨ ਸਮਰਪਿਤ ਬਟਨ। ਇਕ quick-action ("Check in now") ਅਤੇ ਰੀਮਾਇੰਡਰ ਜੋ ਸਿੱਧਾ ਸਬੰਧਤ KR ਨੂੰ ਖੋਲ੍ਹਣ, ਡ੍ਰੌਪ-ਆਊਟ ਦੀ ਦਰ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਅਪਡੇਟ ਮਿਆਰੀ ਰੱਖਦੇ ਹਨ।
ਡੈਸ਼ਬੋਰਡਸ ਉਹ ਥਾਂ ਹਨ ਜਿੱਥੇ OKR ਐਪ ਰੋਜ਼ਾਨਾ ਕਾਮੀ ਆਉਂਦਾ ਹੈ। ਲਕਸ਼ ਦੋ ਸਵਾਲਾਂ ਦਾ ਤੇਜ਼ ਜਵਾਬ ਦੇਣਾ ਹੈ: "ਅਸੀਂ ਟਰੈਕ 'ਤੇ ਹਾਂ?" ਅਤੇ "ਮੈਨੂੰ ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ?"। ਇਸ ਲਈ, ਕੰਪਨੀ, ਡਿਪਾਰਟਮੈਂਟ, ਟੀਮ ਅਤੇ ਵਿਅਕਤੀਗਤ ਪੱਧਰਾਂ 'ਤੇ ਡੈਸ਼ਬੋਰਡ ਬਣਾਓ ਪਰ ਇੱਕੋ ਹੀ ਮਾਨਸਿਕ ਮਾਡਲ ਰੱਖੋ।
ਹਰ ਪੱਧਰ ਇੱਕ ਹੀ ਜਿਹੇ ਵਿਜ਼ੇਟ ਦਿਖਾਏ: ਕੁੱਲ ਸਥਿਤੀ ਵੰਡ, ਪ੍ਰਮੁੱਖ at-risk Objectives, ਆਉਣ ਵਾਲੀਆਂ ਸਮੀਖਿਆ ਮਿਤੀਆਂ, ਅਤੇ check-in ਹੇਲਥ। ਫ਼ਰਕ ਦਾਇਰਾ ਫਿਲਟਰ ਅਤੇ ਡਿਫਾਲਟ ਮਾਲਕ ਸੰਦਰਭ ਹੈ।
ਕੰਪਨੀ ਡੈਸ਼ਬੋਰਡ ਆਰਗ-ਵਾਈਡ ਰੋਲਅਪ ਤੋਂ ਸ਼ੁਰੂ ਹੋ ਸਕਦਾ ਹੈ; ਟੀਮ ਡੈਸ਼ਬੋਰਡ ਸਿਰਫ ਉਹ Objectives ਹਾਈਲਾਈਟ ਕਰੇ ਜੋ ਟੀਮ ਮਾਲਕ ਹੈ ਅਤੇ ਉਹ parent Objectives ਜੋ ਉਹਨਾਂ ਨੂੰ ਜੋੜਦੇ ਹਨ।
ਰੋਲਅਪ ਪਾਰਦਰਸ਼ੀ ਹੋਣ ਚਾਹੀਦੇ ਹਨ, ਨਾ ਕਿ "ਜਾਦੂ"। ਯੂਜ਼ਰਾਂ ਨੂੰ Objective ਤੋਂ KRs ਅਤੇ ਫਿਰ ਤਾਜ਼ਾ ਅੱਪਡੇਟਸ, ਟਿੱਪਣੀਆਂ ਅਤੇ ਸਬੂਤ ਵਿੱਚ ਡਿੱਲ-ਡਾਊਨ ਕਰਨ ਦਿਓ। ਇੱਕ ਚੰਗਾ ਪੈਟਰਨ:
ਬ੍ਰੈਡਕ੍ਰੰਬ ਟਰੇਲ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਸਭ ਵੇਲੇ ਪਤਾ ਰਹੇ ਕਿ ਉਹ ਕਿੱਥੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਜਦ ਉਹ ਸਾਂਝੇ ਲਿੰਕ ਤੋਂ ਆਏ ਹੋਣ।
ਇਹਨਾਂ ਵਿਊਜ਼ ਨੂੰ ਫਿਲਟਰਾਂ ਨਾ ਸਮਝੋ—ਉਹਨਾਂ ਨੂੰ ਅਲੱਗ ਵਿਊਜ਼ ਬਣਾਓ:
ਇਹ ਵਿਊਜ਼ "follow-up ਨਿਰਧਾਰਤ" ਕਾਰਵਾਈਆਂ ਸਹਾਇਤ ਕਰਣਗੀਆਂ ਤਾਂ ਕਿ ਮੈਨੇਜਰ ਤੁਰੰਤ ਅਗਲਾ ਕਦਮ ਲੈ ਸਕਣ।
ਤੀਮਾਂ ਨੂੰ ਤਿਮਾਹੀ ਰਿਵਿਊ ਲਈ ਸਕਰੀਨਸ਼ਾਟ ਖਿੱਚਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ। ਇਕ-ਕਲਿੱਕ ਐਕਸਪੋਰਟ ਦਿਓ:
ਜੇ ਤੁਸੀਂ scheduled exports ਸਮਰਥਨ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ email ਰਾਹੀਂ ਭੇਜੋ ਜਾਂ /reports ਹੇਠਾਂ ਸਟੋਰ ਕਰੋ ਤਾਂ ਕਿ ਰਿਵਿਊ ਮੀਟਿੰਗ ਦੌਰਾਨ ਆਸਾਨੀ ਹੋਵੇ।
ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਅਡਾਪਸ਼ਨ ਨੂੰ ਬਣਾ-ਜਾਂ ਟੋਟਲ ਬਰਬਾਦ ਕਰ ਸਕਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੀ ਐਪ ਟੀਮਾਂ ਨੂੰ ਡੂਬਲ-ਡਾਟਾ ਦਰਜ ਕਰਨ ਤੇ ਮਜ਼ਬੂਰ ਕਰੇਗੀ ਤਾਂ ਉਹ ਨਜ਼ਰਅੰਦਾਜ਼ ਹੋ ਜਾਏਗੀ। ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਸ਼ੁਰੂ ਵਿੱਚ ਯੋਜਨਾ ਬਣਾਓ, ਪਰ ਅਜਿਹੇ ਆਦੇਸ਼ ਵਿੱਚ ਸ਼ਿਪ ਕਰੋ ਜੋ ਕੋਰ ਪ੍ਰੋਡਕਟ ਨੂੰ ਰੋਕਣ ਨਾ ਪਾਵੇ।
ਉਹ ਟੂਲ ਪਹਿਲਾਂ ਜੋ ਡਬਲ ਐਨਟ੍ਰੀ ਘਟਾਉਂਦੇ ਅਤੇ ਵਿਜ਼ਿਬਿਲਟੀ ਵਧਾਉਂਦੇ:
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਨਿਯਮ: ਉਹ ਸਿਸਟਮ ਜੁੜੋ ਜੋ ਪਹਿਲਾਂ ਹੀ ਤੁਹਾਡੇ ਯੂਜ਼ਰਾਂ ਦੀ ਰੋਜ਼ਾਨਾ ਵਰਕਫਲੋ ਦਾ "ਸੋਰਸ ਆਫ਼ ਈਥ" ਹੈ, ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਹਨੇਰੀ ਸੁਪਰ ਵੀਜ਼ ਨਾਲ analytics ਕੰਨੈਕਟਰ ਜੋੜੋ।
ਜ਼ਿਆਦਾਤਰ ਰੋਲਆਉਟ spreadsheet ਜਾਂ slides ਵਿੱਚ ਮੌਜੂਦ OKRs ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ। ਇੱਕ CSV import ਸਮਰਥਨ ਕਰੋ ਜਿਸ ਵਿੱਚ:
ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ imports ਨੂੰ idempotent ਬਣਾਓ ਤਾਂ ਕਿ ਸੁਧਾਰੇ ਹੋਏ ਫਾਈਲ ਨੂੰ ਦੁਬਾਰਾ ਅਪਲੋਡ ਕਰਨ 'ਤੇ duplicates ਨਾ ਬਣਨ।
ਸਪਸ਼ਟ ਕੀਤਾ ਕਿ ਤੁਹਾਡੀਆਂ APIs read-only ਹਨ (reporting, embedding OKRs) ਜਾਂ write-enabled (OKRs ਬਣਾਉਣ/ਅਪਡੇਟ ਕਰਨ, check-ins ਪੋਸਟ ਕਰਨ)।
ਜੇ ਤੁਸੀਂ ਨਜ਼ਦੀਕੀ-ਵਾਸਤਵਿਕ-ਸਮੇਂ ਸਿੰਕ ਦੀ ਉਮੀਦ ਰੱਖਦੇ ਹੋ ਤਾਂ webhooks ਸ਼ਾਮਲ ਕਰੋ ਜਿਵੇਂ "KR updated", "check-in submitted" ਤਾਂ ਕਿ ਬਾਹਰੀ ਟੂਲ polling ਤੋਂ ਬਚ ਸਕਣ।
ਇੱਕ ਐਡਮਿਨ ਸਕ੍ਰੀਨ ਸ਼ਾਮਲ ਕਰੋ ਜਿਥੇ ਅਧਿਕਾਰਤ ਯੂਜ਼ਰ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਜੋੜ, ਟੈਸਟ ਅਤੇ ਮੈਨੇਜ ਕਰ ਸਕਣ: token ਸਥਿਤੀ, scopes, webhook health, last sync time, ਅਤੇ error logs। UX ਸਧਾਰਨ ਰੱਖੋ—ਇੱਕ ਸਕ੍ਰੀਨ ਜੋ ਇਹ ਉੱਤਰ ਦੇਵੇ: "ਕੀ ਇਹ ਜੁੜਿਆ ਹੈ, ਅਤੇ ਕੀ ਇਹ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ?"
ਜੇ ਤੁਸੀਂ ਆਪਣੀ OKR ਐਪ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ (ਖਾਸ ਕਰਕੇ OKR ਡੈਸ਼ਬੋਰਡ, ਚੈਕ-ਇਨ ਵਰਕਫਲੋ, ਅਤੇ ਪਰਮਿਸ਼ਨ ਮਾਡਲ), ਤਾਂ vibe-coding ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਤੁਹਾਨੂੰ ਰੋਜ਼ਮਰਰਾ ਵਰਕ ਕਰਨ ਯੋਗ ਇੱਕ ਇੰਟਰਨਲ ਵਰਜਨ ਤੇਜ਼ੀ ਨਾਲ ਲੈ ਕੇ ਜਾ ਸਕਦਾ ਹੈ—ਫਿਰ-still ਅਸਲ, ਐਕਸਪੋਰਟ ਕਰਨ ਯੋਗ ਸੋర్స్ ਕੋਡ ਤਿਆਰ ਕਰਦਾ ਹੈ। ਇਹ IA, ਰੋਲ, ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਨੂੰ ਸਟੇਕਹੋਲਡਰਾਂ ਨਾਲ ਵੈਰੀਫਾਈ ਕਰਨ ਲਈ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਭਾਰੀ ਇੰਜੀਨੀਅਰਿੰਗ ਵਿੱਚ ਲੱਗਣ ਤੋਂ ਪਹਿਲਾਂ।
ਨੋਟੀਫਿਕੇਸ਼ਨ ਇੱਕ ਸ਼ਾਨਦਾਰ ਡੈਮੋ ਵਾਲੀ ਐਪ ਅਤੇ ਇੱਕ ਐਸੀ ਐਪ ਵਿਚਕਾਰ ਫਰਕ ਬਣਾਉਂਦੇ ਹਨ ਜਿਸ ਨੂੰ ਟੀਮਾਂ ਅਸਲ ਵਿੱਚ ਵਰਤਦੀਆਂ ਹਨ। ਲਕਸ਼ "ਜ਼ਿਆਦਾ ਪਿੰਗ ਨਹੀਂ"—ਸਗੋਂ ਸਮੇਂ-ਸਿਰ ਨੁੱਡਜ ਜੋ ਚੈਕ-ਇਨ ਅਤੇ ਸਮੀਖਿਆਆਂ ਨਹੀਂ ਰੁਕਣ ਦਿੰਦੀਆਂ, ਬਿਨਾਂ ਲੋਕਾਂ ਨੂੰ ਸਿਸਟਮ ਨੂੰ ਅਣਦੇਖਾ ਕਰਨ ਦੀ ਆਦਤ ਪਾਉਣ।
ਕੁਝ ਸਪਸ਼ਟ, ਉਚ-ਸਿਗਨਲ ਰੀਮਾਇੰਡਰ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਰੂਲਾਂ workspace ਜਾਂ org ਪੱਧਰ 'ਤੇ ਕਸਟਮਾਈਜ਼ੇਬਲ ਰੱਖੋ, ਪਰ ਸਮਝਦਾਰ ਡਿਫਾਲਟਾਂ ਦੇ ਨਾਲ shipment ਕਰੋ (ဥਦਾਹਰਨ: ਮਿਸਡ ਚੈਕ-ਇਨ ਤੋਂ 24 ਘੰਟੇ ਬਾਅਦ ਇਕ ਰੀਮਾਇੰਡਰ, ਅਤੇ 48 ਘੰਟੇ ਬਾਅਦ ਦੂਜਾ)।
ਵੱਖ-ਵੱਖ ਟੀਮਾਂ ਵੱਖ-ਵੱਖ ਟੂਲਾਂ ਵਿੱਚ ਰਹਿੰਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਪ੍ਰਤੀ-ਯੂਜ਼ਰ ਨੋਟੀਫਿਕੇਸ਼ਨ ਚੈਨਲ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰੋ:
ਸ਼ਾਂਤ ਘੰਟਿਆਂ ਅਤੇ ਟਾਈਮਜ਼ੋਨ ਸ਼ਾਮਲ ਕਰੋ। 9am ਸਥਾਨਕ ਸਮੇਂ 'ਤੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਸਹਾਇਕ ਹੋਵੇਗੀ; 2am 'ਤੇ ਆਈ ਹੋਏ ਨੋਟੀਫਿਕੇਸ਼ਨ ਨੂੰ ਲੋਕ ਅਣਦੇਖਾ ਕਰ ਦੇਣਗੇ।
ਆਟੋਮੇਸ਼ਨ ਦੁਹਰਾਉਂਦੇ ਕੰਮ ਹਟਾਉਣ ਲਈ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਨੇ ਪਰ ਸਪਸ਼ਟ ਰੱਖੀਆਂ ਜਾਨ।
ਜਿੱਥੇ ਆਟੋਮੇਸ਼ਨ ਯੂਜ਼ਰਾਂ ਨੂੰ ਹੈਰਾਨ ਕਰ ਸਕਦੀ ਹੈ ਉਥੇ ਓਪਟ-ਇਨ ਰੱਖੋ, ਅਤੇ ਹਮੇਸ਼ਾ ਨੋਟੀਫਿਕੇਸ਼ਨ ਵਿੱਚ "ਤੁਹਾਨੂੰ ਇਹ ਕਿਉਂ ਮਿਲਿਆ" ਦਿਖਾਓ। ਇਹ ਭਰੋਸਾ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਅਡਾਪਸ਼ਨ ਨੂੰ ਉੱਚੀ ਰੱਖਦਾ ਹੈ।
ਸੁਰੱਖਿਆ ਅਤੇ ਪਰਦੇਦਾਰੀ ਫੈਸਲੇ ਬਾਅਦ ਵਿੱਚ "ਬੋਲਟ-ਆਨ" ਕਰਨਾ ਮੁਸ਼ਕਿਲ ਹੁੰਦਾ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਹਾਡੀ ਐਪ ਸੰਵੇਦਨਸ਼ੀਲ ਪ੍ਰਦਰਸ਼ਨਕ ਸੰਦਰਭ, ਰਣਨੀਤੀ ਨੋਟਸ, ਅਤੇ ਲੀਡਰਸ਼ਿਪ ਟਿੱਪਣੀਆਂ ਰੱਖਣ ਲੱਗੇ। ਇਹਨਾਂ ਨੂੰ ਉਤਪਾਦੀ ਲੋੜਾਂ ਵਜੋਂ ਲਓ, ਸਿਰਫ਼ ਇੰਜੀਨੀਅਰਿੰਗ ਕਾਰਜ ਵਜੋਂ ਨਹੀਂ।
ਟ੍ਰਾਂਜ਼ਿਟ ਵਿੱਚ ਐਨਕ੍ਰਿਪਸ਼ਨ (HTTPS/TLS) ਅਤੇ ਡੇਟਾਬੇਸ/ਫਾਈਲ ਸਟੋਰੇਜ ਲਈ ਐਨਕ੍ਰਿਪਸ਼ਨ। ਸੈਸ਼ਨ ਲੀਮੀਟ ਦੇ ਨਾਲ ਸੁਰੱਖਿਅਤ ਟੋਕਨ, secure cookies, ਅਤੇ ਸਾਫ਼ logout ਵਿਹਾਰ (ਸਾਹਮਣੇ "ਸਾਰੇ ਡਿਵਾਈਸਾਂ ਤੋਂ ਲੌਗਆਊਟ") ਰੱਖੋ। ਲੌਗਿਨ ਅਤੇ API endpoints ਲਈ rate limits ਲਗਾਓ ताकि brute force ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕੇ, ਅਤੇ ਮੁੱਖ ਘਟਨਾਵਾਂ ਦਾ audit log ਰੱਖੋ: ਸਾਇਨ-ਇਨ, ਪਰਮਿਸ਼ਨ ਬਦਲਾਅ, OKR ਸੋਧ, ਐਕਸਪੋਰਟ, ਅਤੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਅਦਾਨ-ਪ੍ਰਦਾਨ।
ਇੱਕ ਸਾਦਾ ਪਰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਨਿਯਮ: ਕੋਈ ਵੀ ਐਕਸ਼ਨ ਜੋ OKRs ਜਾਂ ਐਕਸੈਸ ਨੂੰ ਬਦਲਦਾ ਹੈ ਉਸਨੂੰ ਯੂਜ਼ਰ, ਸਮਾਂ ਅਤੇ ਸਰੋਤ ਨਾਲ ਜੋੜ ਕੇ ਟਰੇਬਲ ਕੀਤਾ ਜਾਏ।
ਜੇ ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਟ ਵਿੱਚ ਕਈ ਕੰਪਨੀਆਂ ਦਾ ਸਮਰਥਨ ਹੈ, ਤਾਂ tenant isolation ਪਹਿਲੇ ਹੀ ਸੋਚੋ। ਘੱਟੋ-ਘੱਟ:
ਉੱਚੀ ਯਕੀਨਦਾਰੀ ਲਈ ਵੱਖ-ਵੱਖ ਡੇਟਾਬੇਸ ਪ੍ਰਤੀ ਟੇਨੈਂਟ ਇੱਕ ਵਿਕਲਪ ਹੈ—ਜ਼ਿਆਦਾ ਕੰਮ, ਪਰ ਸਧਾਰਣ containment।
ਫੈਸਲਾ ਕਰੋ ਕਿ ਸਾਈਕਲ ਖ਼ਤਮ ਹੋਣ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ। ਚੈਕ-ਇਨ, ਟਿੱਪਣੀਆਂ ਅਤੇ ਟੀਚੇ ਲਈ ਰੀਟੇਨਸ਼ਨ ਨੀਤੀ ਰੱਖੋ (ਉਦਾਹਰਨ: 2–3 ਸਾਲ ਰੱਖੋ), ਅਤੇ ਯੂਜ਼ਰ ਖਾਤਿਆਂ ਅਤੇ ਨਿੱਜੀ ਡੇਟਾ ਲਈ ਮਿਟਾਉਣ ਦਾ ਸਹਾਇਤਾ ਦਿਓ ਜਿੱਥੇ ਲੋੜ ਹੋਵੇ। ਐਕਸਪੋਰਟ ਅਤੇ ਐਡਮਿਨ ਡਿਲੀਸ਼ਨ ਕਾਰਵਾਈਆਂ auditable ਹੋਣ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਯੂਜ਼ਰ ਹਟਾਉਂਦੇ ਹੋ ਤੇ ਪੁਰਾਣੀਆਂ ਟਿੱਪਣੀਆਂ anonymize ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਵਰਤਾਰਾ ਸਪਸ਼ਟ ਦਸਤਾਵੇਜ਼ ਕਰੋ।
ਵਾਤਾਵਰਣ (dev/staging/prod) ਸੈਟ ਕਰੋ ਜੋ ਕੰਟਰੋਲਡ ਐਕਸੈਸ ਅਤੇ configuration management ਨਾਲ ਹੋਵਣ। ਬੈਕਅੱਪ ਆਟੋਮੇਟ ਕਰੋ ਅਤੇ restore ਟੈਸਟ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਚਲਾਓ। uptime, error rates, ਅਤੇ slow queries ਲਈ ਮਾਨੀਟਰਿੰਗ ਸ਼ਾਮਲ ਕਰੋ, ਅਤੇ ਅਲਾਰਟਸ ਜੋ ਕਿਸੇ ਮਨੁੱਖ ਤੱਕ ਪਹੁੰਚਣ। ਆਖਿਰ ਵਿੱਚ, ਇਕ ਹਲਕੀ incident response runbook ਲਿਖੋ: tokens revoke, keys rotate, ਪ੍ਰਭਾਵ ਦੀ ਸੰਚਾਰ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਫਿਕਸ ਸ਼ਿਪ ਕਰਨ ਦੀ ਰਣਨੀਤੀ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਦਰਸ਼ਕ (v1 ਲਈ ਅਕਸਰ ਟੀਮ ਅਤੇ ਡਿਪਾਰਟਮੈਂਟ ਲੀਡ) ਚੁਣੋ ਅਤੇ ਕਰਨੇ ਵਾਲੀਆਂ ਮੁੱਖ ਜ਼ਰੂਰੀਆਂ ਨਿਰਧਾਰਿਤ ਕਰੋ:
ਫਿਰ ਮਾਪੇ ਜਾ ਸਕਣ ਵਾਲੇ ਸਫਲਤਾ ਮੈਟਰਿਕ ਲਿਖੋ (ਅਡਾਪਸ਼ਨ, ਚੈਕ-ਇਨ ਰੇਟ, ਰਿਪੋਰਟਿੰਗ ਦਾ ਸਮਾਂ ਬਚਿਆ, KR ਗੁਣਵੱਤਾ) ਤਾਂ ਜੋ ਹਰ ਫੀਚਰ ਫੈਸਲਾ ਨਤੀਜਿਆਂ ਨਾਲ ਜੁੜਿਆ ਰਹੇ।
ਇੱਕ ਸੁਰੱਖਿਅਤ ਡਿਫਾਲਟ v1 ਲਈ ਟੀਮ ਅਤੇ ਡਿਪਾਰਟਮੈਂਟ ਲੀਡ ਹਨ ਕਿਉਂਕਿ ਉਹ:
ਹਾਲਾਂਕਿ ਇਹ ਧਿਆਨ ਰੱਖੋ ਕਿ ਏਗਜ਼ੈਕਟਿਵਜ਼ ਡੈਸ਼ਬੋਰਡ ਨੂੰ ਸੋਖੇ ਨਾਲ ਸਕੈਨ ਕਰ ਸਕਣ ਅਤੇ ਯੋਗਦਾਨਕਾਰੀਆਂ KR ਤੇ ਤੇਜ਼ ਅੱਪਡੇਟ ਕਰ ਸਕਣ, ਪਰ ਸ਼ੁਰੂ ਵਿੱਚ UX ਨੂੰ ਉਹਨਾਂ ਲਈ ਢਾਲੋ ਜੋ ਵਰਕਫਲੋ ਚਲਾਉਂਦੇ ਹਨ।
ਮੁੱਢਲਾ "across teams and departments" ਸਮਰਥਨ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
ਜੇ ਤੁਸੀਂ ਪਹਿਲੇ ਵਰਜਨ ਵਿੱਚ ਕ੍ਰਾਸ-ਟੀਮ ਐਲਾਈਨਮੈਂਟ ਲਿੰਕ ਸਮਰਥਨ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ v1 ਨੂੰ ਟੀਮ-ਅੰਦਰ ਟਰੈਕਿੰਗ ਤਕ ਸੀਮਿਤ ਰੱਖੋ ਤਾਂ ਜੋ ਗਲਤ ਰਿਪੋਰਟਿੰਗ ਨਾ ਹੋਵੇ।
ਉਤਪਾਦ ਦੀ ਕਾਪੀ ਅਤੇ ਆਨਬੋਰਡਿੰਗ ਵਿੱਚ ਟਰਮਾਂ ਨੂੰ ਸਟੈਂਡਰਡ ਕਰੋ:
ਜੇ ਤੁਸੀਂ initiatives ਸ਼ਾਮਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਉਹ KRs ਵਾਂਗਿ ਐਚੀਵਮੈਂਟ ਨੂੰ "ਰੋਲ ਅਪ" ਨਹੀਂ ਕਰਦੇ, ਨਹੀਂ ਤਾਂ ਟੀਮਾਂ ਸਰਗਰਮੀ ਨੂੰ ਨਤੀਜੇ ਸਮਝ ਬੈਠਣਗੀਆਂ।
ਇੱਕ ਮੁੱਖ ਸਕੋਰਿੰਗ ਢੰਗ ਚੁਣੋ ਅਤੇ ਸਾਰੇ ਸਥਾਨਾਂ 'ਤੇ ਲਾਗੂ ਕਰੋ:
ਰੋਲਅਪ ਨਿਯਮ ਲਿਖੋ (ਉਦਾਹਰਨ:
ਛੋਟੀ ਪਰ ਸਪਸ਼ਟ ਵਰਕਫਲੋ ਸਥਿਤੀਆਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਉਨਾਂ ਨੂੰ ਸਾਰੀਆਂ ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਮਾਨਯਤਾ ਦਿਓ:
ਹਰ ਸਥਿਤੀ ਲਈ ਇਹ ਤੈਅ ਕਰੋ:
ਇਸ ਨਾਲ ਅਧੂਰੇ OKRs ਲੀਡਰਸ਼ਿਪ ਵਿਊਜ਼ ਵਿੱਚ ਨਹੀਂ ਆਉਣਗੇ ਅਤੇ ਗਵਰਨੈਂਸ ਪੈਟਰਨ ਸਪਸ਼ਟ ਰਹੇਗਾ।
ਇੱਕ ਵਿਹੰਗਮ ਸੈਟ ਜਿਸ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ ਰਿਕਾਰਡ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ:
ਸਧਾਰਨ ਰੋਲ-ਆਧਾਰਿਤ ਐਕਸੈਸ ਕੰਟਰੋਲ ਰੱਖੋ ਅਤੇ “ਸਭ ਨੂੰ ਹਰ ਚੀਜ਼ ਸੰਪਾਦਨ” ਤੋਂ ਬਚੋ। ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਬੇਸਲਾਈਨ:
ਗਵਰਨੈਂਸ ਐਕਸ਼ਨਾਂ (ਕੌਣ ਸਾਈਕਲ ਬਣਾਉਂਦਾ, ਕੌਣ ਪਬਲਿਸ਼ ਕਰਦਾ, ਕੌਣ ਲਾਕ ਕਰਦਾ) ਨੂੰ ਵੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਅਤੇ UI/ API ਵਿੱਚ ਲਾਗੂ ਕਰੋ।
ਇੱਕ ਸਾਫ਼, ਇੱਕ ਹੀ ਨਿਰਧਾਰਤ ਫਲੋ ਹਾਂ: ਇੱਕ ਸੋਧ-ਕੇਂਦਰਤ ਪ੍ਰਵਾਹ ਜੋ ਹਰ Key Result ਲਈ ਕਾਰਗਰ ਹੋਵੇ:
ਫਾਰਮ ਛੋਟਾ ਰੱਖੋ, ਡ੍ਰਾਫਟ ਸੇਵ ਕਰੋ ਅਤੇ ਪਿਛਲੇ ਹਫ਼ਤੇ ਦਾ ਸੰਦਰਭ ਅੱਗੇ ਭਰ ਦਿੱਤਾ ਜਾਵੇ ਤਾਂ ਕਿ ਵਰਤੋਂਕਰਤਾ ਜ਼ਿਆਦਾ ਸਮਾਂ ਨਾ ਲਗਾਏ।
ਡੈਸ਼ਬੋਰਡ ਲੋਕਾਂ ਨੂੰ ਦਿਨ-प्रतिदਿਨ ਕਾਮ ਵਿੱਚ ਮਦਦ ਕਰਨ ਲਈ ਲਾਜ਼ਮੀ ਹਨ। ਉਦੇਸ਼: “ਅਸੀਂ ਟਰੈਕ 'ਤੇ ਹਾਂ?” ਅਤੇ “ਮੈਂ ਅੱਗੇ ਕੀ ਵੇਖਾਂ?” ਨੂੰ ਜਲਦੀ ਜਵਾਬ ਦੇਣਾ। ਪੱਧਰਾਂ ਅਨੁਸਾਰ ਡੈਸ਼ਬੋਰਡ ਬਣਾਓ:
ਰੋਲਅਪਸ ਨੂੰ ਪਾਰਦਰਸ਼ੀ ਰੱਖੋ: Objective ਕਾਰਡ → KRs ਸੂਚੀ → ਅੱਪਡੇਟ ਟਾਈਮਲਾਈਨ। ਜੋਖਮ ਨੂੰ ਪਹਿਲਾਂ ਹੀ surfaced ਕਰੋ (At-risk, overdue check-ins), ਅਤੇ ਇੱਕ-ਕਲਿੱਕ ਰਿਪੋਰਟ ਐਕਸਪੋਰਟ ਦਿਓ (PDF/CSV) ਰਿਵਿਊ ਲਈ।
ਸੰਰਕਸ਼ਿਤ ਨੋਟ: /reports ਵਰਗੀਆਂ ਸਥਾਨਕ ਫਾਈਲ ਪਥਾਂ ਦੀ ਵਰਤੋਂ ਰਿਵਿਊ ਮੀਟਿੰਗਾਂ ਵਿੱਚ ਆਸਾਨੀ ਲਈ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।
ਇਹ ਨਿਯਮ ਲਿਖ ਕੇ ਰੱਖੋ ਤਾਂ ਕਿ analytics ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਵਿੱਚ ਇਕਸਾਰਤਾ ਰਹੇ।
KR ਦੇ ਰਿਕਾਰਡ 'ਤੇ ਨਵੀਂ current value ਰੱਖੋ ਤਾਂ ਕਿ ਡੈਸ਼ਬੋਰਡ ਤੇਜ਼ ਰਹਿਣ ਅਤੇ check-ins ਟਾਈਮਲਾਈਨ ਸਾਰਥਕ ਸੁਤਰ ਹੋਵੇ।
