ਟੀਮਾਂ ਅਤੇ ਡਿਪਾਰਟਮੈਂਟਾਂ ਵਿੱਚ OKR ਟਰੈਕ ਕਰਨ ਲਈ ਵੈੱਬ ਐਪ ਕਿਵੇਂ ਬਣਾਈਏ?

ਦਾਇਰਾ, ਦਰਸ਼ਕ ਅਤੇ ਸਫਲਤਾ ਮੈਟਰਿਕ ਨਿਰਧਾਰਤ ਕਰੋ

OKR ਟਰੈਕਿੰਗ ਐਪ ਡਿਜ਼ਾਈਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸੁਨਿਸ਼ਚਿਤ ਕਰੋ ਕਿ ਇਹ ਕਿਸ ਲਈ ਹੈ ਅਤੇ “ਸਫਲਤਾ” ਕੀ ਮੰਨੀ ਜਾਵੇਗੀ। ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਐਸਾ ਐਪ ਬਣਾਓਗੇ ਜੋ ਹਰ ਕਿਸੇ ਨੂੰ ਖੁਸ਼ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ—ਪਰ ਜ਼ਿਆਦातर ਲਈ ਗੁੰਝਲਦਾਰ ਬਣਕੇ ਰਹੇਗਾ।

ਮੁੱਖ ਦਰਸ਼ਕ ਨੂੰ ਸਪਸ਼ਟ ਕਰੋ (ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਤਰਜੀਹਾਂ)

OKR ਸਿਸਟਮ ਵੱਖ-ਵੱਖ ਲੋਕਾਂ ਵੱਲੋਂ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ:

• ਇਗਜ਼ੈਕਟਿਵਜ਼ ਨੂੰ ਸਾਫ਼ OKR ਡੈਸ਼ਬੋਰਡ ਚਾਹੀਦਾ ਹੈ ਜਿਸ 'ਚ ਰੋਲਅਪ, ਪ੍ਰੋਗਰੈੱਸ ਕਨਫਿਡੈਂਸ ਅਤੇ “ਕਿਸ 'ਤੇ ਧਿਆਨ ਦੇਣਾ ਹੈ” ਵੇਖਾਇਆ ਜਾਵੇ।
• ਡਿਪਾਰਟਮੈਂਟ ਲੀਡਸ ਨੂੰ ਟੀਮਾਂ 'ਚ ਮਿਲਾਪ, ਕੰਪਨੀ ਦੇ ਲਕਸ਼ਾਂ ਨਾਲ ਸੰਰੇਖਣ ਅਤੇ ਆਸਾਨ ਰਿਪੋਰਟਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
• ਟੀਮ ਲੀਡਸ Objectives ਅਤੇ Key Results ਤਿਆਰ ਕਰਨ, ਡਿਪੈਂਡੇਨਸੀ ਐਲਾਈਨ ਕਰਨ ਅਤੇ ਇਕ ਸਥਿਰ OKR ਚੈਕ-ਇਨ ਵਰਕਫਲੋ ਚਲਾਉਣ 'ਤੇ ਧਿਆਨ ਦਿੰਦੇ ਹਨ।
• ਯੋਗਦਾਨਕਾਰ ਸਪਸ਼ਟ ਅੱਪਡੇਟ, ਮਾਲਕੀ ਅਤੇ ਪ੍ਰਸੰਗ (ਇਹ KR ਕਿਉਂ ਮਹੱਤਵਪੂਰਣ ਹੈ) ਚਾਹੁੰਦੇ ਹਨ।

v1 ਲਈ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਦਰਸ਼ਕ ਚੁਣੋ (ਅਕਸਰ ਟੀਮ ਅਤੇ ਡਿਪਾਰਟਮੈਂਟ ਲੀਡ) ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਹੋਰ ਰੋਲਾਂ ਵੀ ਬੁਨੀادي ਕੰਮ ਕਰ ਸਕਣ।

ਮੁੱਖ ਨੌਕਰੀਆਂ ਨਿਰਧਾਰਤ ਕਰੋ

Objective ਅਤੇ Key Results ਸਾਫਟਵੇਅਰ ਲਈ ਮੂੜ-ਲੋੜੀਂਦੀਆਂ ਨੌਕਰੀਆਂ:

• OKRs ਸੈਟ ਕਰੋ (Objectives ਬਣਾਓ, Key Results ਡਿਫਾਈਨ ਕਰੋ, ਮਾਲਕ ਨਿਯੁਕਤ ਕਰੋ, ਤਾਰੀਖਾਂ ਅਤੇ ਬੇਸਲਾਈਨਸ ਦਿਓ)
• OKRs ਐਲਾਈਨ ਕਰੋ (ਟੀਮ KRs ਨੂੰ ਉੱਚ-سطح Objectives ਨਾਲ ਲਿੰਕ ਕਰੋ; ਸੰਬੰਧ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਦਿੱਖਾਓ)
• ਚੈਕ-ਇਨ (ਤੇਜ਼ ਅੱਪਡੇਟ, ਟਿੱਪਣੀਆਂ, ਕਨਫਿਡੈਂਸ ਅਤੇ ਬਲਾਕਰ)
• ਰਿਪੋਰਟ (ਟTeam/Department ਲਈ ਸਥਿਤੀ ਵੇਖਣ ਵਾਲੇ ਵਿਊਜ਼)
• ਸਿੱਖੋ (ਸਾਈਕਲ ਖਤਮ ਹੋਣ 'ਤੇ ਰਿਫਲੈਕਸ਼ਨ ਅਤੇ ਅਗਲੇ ਸਾਈਕਲ ਲਈ ਸੁਝਾਅ)

"ਟੀਮਾਂ ਅਤੇ ਡਿਪਾਰਟਮੈਂਟਾਂ 'ਤੇ" ਦਾ ਅਰਥ ਪਹਿਲੇ ਦਿਨ ਤੇ ਕਿਆ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ

ਸਪਸ਼ਟ ਕਰੋ ਕਿਹੜੀ ਘੱਟੋ-ਘੱਟ ਸਕੇਲ ਸਮਰਥਨ ਦੀ ਲੋੜ ਹੈ: ਕਈ ਡਿਪਾਰਟਮੈਂਟ, ਕ੍ਰਾਸ-ਫੰਕਸ਼ਨਲ ਟੀਮਾਂ, ਸਾਂਝੇ Objectives ਅਤੇ ਟੀਮ/ਡਿਪਾਰਟਮੈਂਟ ਵਾਰ ਰੋਲਅਪਸ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਸ਼ੁਰੂ ਤੋਂ ਕ੍ਰਾਸ-ਟੀਮ ਐਲਾਈਨਮੈਂਟ ਲਿੰਕ ਨਹੀਂ ਹਨ, ਤਾਂ ਇਹ ਬਤਾਓ—ਅਤੇ ਦਾਇਰਾ ਟੀਮ-ਅੰਦਰ ਟਰੈਕਿੰਗ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ।

ਪ੍ਰੋਡਕਟ ਸਫਲਤਾ ਮੈਟ੍ਰਿਕ ਨਿਰਧਾਰਤ ਕਰੋ

ਮਾਪੇ ਜਾ ਸਕਣ ਵਾਲੇ ਮੈਟ੍ਰਿਕ ਚੁਣੋ:

• ਅਡਾਪਸ਼ਨ: ਨਿਸ਼ਾਨਿਤ ਟੀਮਾਂ ਵਿੱਚੋਂ ਕਿੰਨੀਆਂ % ਐਪ ਵਰਤ ਰਹੀਆਂ ਹਨ
• ਚੈਕ-ਇਨ ਦਰ: KRs ਦੀ % ਜੋ ਹਫ਼ਤੇਵਾਰ (ਜਾਂ cadence ਮੁਤਾਬਕ) ਅਪਡੇਟ ਹੁੰਦੀ ਹੈ
• ਰਿਪੋਰਟਿੰਗ ਸਮਾਂ ਘਟਿਆ: ਸাপ্তਾਹਿਕ/ਮਾਸਿਕ ਡੈਸ਼ਬੋਰਡ ਬਣਾਉਣ ਦਾ ਸਮਾਂ
• ਗੁਣਵੱਤਾ ਸੰਕੇਤ: KRs ਦੀ % ਜਿਨ੍ਹਾਂ ਕੋਲ ਸਾਫ਼ ਮਾਪ, ਮਾਲਕ ਅਤੇ ਡਿਊ датੇ ਹਨ

ਇਹਨਾਂ ਨੂੰ ਆਪਣੀਆਂ ਸ਼ਰਤਾਂ ਵਿੱਚ ਲਿਖੋ ਤਾਂ ਕਿ ਹਰ ਫੀਚਰ ਫੈਸਲਾ ਨਤੀਜਿਆਂ ਨਾਲ ਜੁੜਿਆ ਰਹੇ।

OKR ਸੰਕਲਪ ਅਤੇ ਨਿਯਮ ਸਟੈਂਡਰਡ ਕਰੋ

ਸਕਰੀਨ ਜਾਂ ਡੇਟਾਬੇਸ ਡਿਜ਼ਾਈਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਸੰਗਠਨ ਵਿੱਚ “OKR” ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਜੇ ਟੀਮਾਂ ਸ਼ਬਦਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਸਮਝਦੀਆਂ ਹਨ, ਤਾਂ ਤੁਹਾਡੀ OKR ਟਰੈਕਿੰਗ ਐਪ ਇਕ ਅਜਿਹੀ ਰਿਪੋਰਟਿੰਗ ਟੂਲ ਬਣ ਜਾਏਗੀ ਜਿਸ 'ਤੇ ਕੋਈ ਭਰੋਸਾ ਨਹੀਂ ਕਰੇਗਾ।

ਮੁੱਖ ਏਂਟੀਟੀਆਂ นิਰਧਾਰਤ ਕਰੋ

ਸੁਰੂਆਤ ਵਿੱਚ ਸਪਸ਼ਟ ਪਰਿਭਾਸ਼ਾਵਾਂ ਲਿਖੋ ਜੋ ਪ੍ਰੋਡਕਟ ਕਾਪੀ, ਹੈਲਪ ਟੈਕਸਟ ਅਤੇ ਆਨਬੋਰਡਿੰਗ ਵਿੱਚ ਦਿਖਾਈ ਜਾਣ ।

Objective: ਇੱਕ ਗੁਣਾਤਮਕ, ਨਤੀਜੇ-ਕੇਂਦ੍ਰਤ ਲਕਸ਼ (ਅਸੀਂ ਕੀ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ)।

Key Result: ਇੱਕ ਮਾਪਣ ਯੋਗ ਨਤੀਜਾ ਜੋ Objective ਵੱਲ ਤਰੱਕੀ ਦਿਖਾਉਂਦਾ ਹੈ (ਅਸੀਂ ਕਿਵੇਂ ਜਾਣਾਂ ਕਿ ਅਸੀਂ ਹਾਸਲ ਕੀਤਾ)।

Initiative (ਵਿਕਲਪਿਕ): ਉਹ ਕੰਮ ਜਾਂ ਪ੍ਰੋਜੈਕਟ ਜੋ Key Results ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਲਈ ਕੀਤੇ ਜਾਂਦੇ ਹਨ (ਅਸੀਂ ਕੀ ਕਰਦੇ ਹਾਂ)। ਪਹਲੇ ਹੀ ਫੈਸਲਾ ਕਰੋ ਕਿ initiatives ਤੁਹਾਡੇ ਐਪ ਦੇ ਦਾਇਰੇ ਵਿੱਚ ਹਨ ਜਾਂ ਨਹੀਂ।

ਜੇ ਤੁਸੀਂ initiatives ਸ਼ਾਮਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਉਹ KRs ਵਾਂਗਿ achievement ਨੂੰ "ਰੋਲ ਅਪ" ਨਹੀਂ ਕਰਨਗੇ। ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਸਰਗਰਮੀ ਨੂੰ ਨਤੀਜੇ ਸਮਝ ਬੈਠਦੀਆਂ ਹਨ; ਤੁਹਾਡੀਆਂ ਪਰਿਭਾਸ਼ਾਵਾਂ ਇਹ ਗ਼ਲਤੀ ਰੋਕਣਗੀਆਂ।

ਸਕੋਰਿੰਗ ਅਤੇ ਰੋਲਅਪ ਨਿਯਮ ਚੁਣੋ

ਤੁਹਾਡੇ ਡੈਸ਼ਬੋਰਡ ਦੀ ਸਹੀਅਤ ਉਸ ਦੀ ਸਕੋਰਿੰਗ ਨੀਤੀ ਤੇ ਨਿਰਭਰ ਕਰੇਗੀ। ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਸਕੋਰਿੰਗ ਵਿਧੀ ਚੁਣੋ ਅਤੇ ਹਰ ਜਗ੍ਹਾ ਲਾਗੂ ਕਰੋ:

• 0–1 (ਜਿਵੇਂ 0.0 ਤੋਂ 1.0)
• 0–100 (ਪ੍ਰਤੀਸ਼ਤ)
• Red/Amber/Green ਸਥਿਤੀ (ਅਕਸਰ ਨੰਬਰਾਤਮਕ ਸਕੋਰ ਨਾਲ)

ਫਿਰ ਰੋਲਅਪ ਨਿਰਧਾਰਤ ਕਰੋ (ਕਿਸ ਤਰ੍ਹਾਂ ਸਕੋਰ ਇਕੱਠੇ ਹੁੰਦੇ ਹਨ):

• ਇਕ Objective ਸਕੋਰ ਉਸਦੇ Key Results ਤੋਂ ਕਿਵੇਂ ਬਣਦਾ ਹੈ (ਸਧਾਰਨ ਮੀਨ, weighted average, lowest KR, ਮੈਨੂਅਲ ਓਵਰਰਾਈਡ)?
• ਕੀ Key Result ਲਈ weights ਦੀ ਆਗਿਆ ਹੋਵੇਗੀ, ਅਤੇ ਜੇ ਹਾਂ ਤਾਂ ਕੀ ਉਹ 100% ਤੇ ਜੋੜਨੇ ਲਾਜ਼ਮੀ ਨੇ?
• ਗੈਰ-ਨੰਬਰਾਤਮਕ KRs (ਉਦਾਹਰਣ: ਮਾਇਲਸਟੋਨ-ਆਧਾਰਤ) ਨੂੰ ਤਰੱਕੀ ਦੇ ਨੰਬਰਾਤਮਕ ਰੂਪ ਵਿੱਚ ਕਿਵੇਂ ਮੈਪ ਕੀਤਾ ਜਾਵੇ?

ਇਹ ਨਿਯਮ ਉਤਪਾਦ ਦੀਆਂ ਲੋੜਾਂ ਵਿੱਚ ਲਿਖ ਕੇ ਰੱਖੋ ਤਾਂ ਜੋ analytics ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਵਿੱਚ ਇੱਕਸਾਰਤਾ ਬਣੀ ਰਹੇ।

cadence ਅਤੇ ਸਾਈਕਲ ਬਾਊਂਡਰੀਜ਼ ਨਿਰਧਾਰਤ ਕਰੋ

ਆਪਣਾ ਸਮੇਂ ਦਾ cadence ਨਿਰਧਾਰਤ ਕਰੋ: ਤਿਮਾਹੀ, ਮਹੀਨਾਵਾਰ, ਜਾਂ ਕਸਟਮ ਸਾਈਕਲ। ਤੁਹਾਡਾ OKR check-in ਵਰਕਫਲੋ ਇਸ ਉੱਤੇ ਨਿਰਭਰ ਕਰੇਗਾ।

ਦਸਤਾਵੇਜ਼ ਬਣਾਓ:

• ਸਾਈਕਲ ਕਦੋਂ ਸ਼ੁਰੂ/ਖਤਮ ਹੁੰਦੇ ਹਨ (calendar quarters vs fiscal)
• ਕੀ OKRs ਸਾਈਕਲਾਂ 'ਚ overlap ਕਰ ਸਕਦੇ ਹਨ
• “active”, “completed”, ਅਤੇ “carried over” ਦਾ ਕੀ ਮਤਲਬ ਹੈ

ਇਹ ਫੈਸਲੇ ਫਿਲਟਰ, ਪਰਮਿਸ਼ਨ ਅਤੇ OKR ਵਿਸ਼ਲੇਸ਼ਣ ਵਿੱਚ ਇਤਿਹਾਸਕ ਤੁਲਨਾਵਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨਗੇ।

ਨਾਂ ਰੱਖਣ ਦੀ ਸਾਂਝ

ਨਾਮਕਰਨ ਛੋਟੀ ਗੱਲ ਲੱਗਦੀ ਹੈ, ਪਰ ਇਹ “ਟੀਮ ਸਹਿਮਤੀ” ਅਤੇ ਅਸਪਸ਼ਟ ਸਿਰਲਖਾਂ ਵਿੱਚ ਫ਼ਰਕ ਪੈਦਾ ਕਰਦੀ ਹੈ।

ਕਨਵੰਸ਼ਨਾਂ ਦੀ ਸਥਾਪਨਾ ਕਰੋ ਜਿਵੇਂ:

• Objectives ਕ੍ਰਿਆ ਨਾਲ ਸ਼ੁਰੂ ਹੋਣ ("Improve onboarding conversion…")
• Key Results ਇੱਕ ਮਿਟਰਿਕ ਅਤੇ ਟਾਰਗਟ ਸ਼ਾਮਲ ਕਰਨ ("Increase activation rate from X to Y")
• ਜੇ ਜ਼ਰੂਰੀ ਹੋਵੇ ਤਾਂ ਟੀਮ ਜਾਂ ਸਕੋਪ ਲਈ ਓਪਸ਼ਨਲ ਪ੍ਰੀਫਿਕਸ ("[Sales] …", "[Platform] …")

ਇਹ ਕਨਵੰਸ਼ਨ UI ਵਿੱਚ ਦਿੱਖਣਗੀਆਂ ਹੋਣ (ਪਲੇਸਹੋਲਡਰ, ਉਦਾਹਰਣ, ਵੈਲਿਡੇਸ਼ਨ ਹਿੰਟ) ਤਾਂ ਜੋ OKRs ਟੀਮਾਂ ਅਤੇ ਡਿਪਾਰਟਮੈਂਟਾਂ ਵਿੱਚ ਪੜ੍ਹਨਯੋਗ ਰਹਿਣ।

ਜਾਣਕਾਰੀ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਨੈਵੀਗੇਸ਼ਨ ਯੋਜਨਾ ਬਣਾਓ

IA ਉਹ ਸਥਾਨ ਹੈ ਜਿੱਥੇ OKR ਟਰੈਕਿੰਗ ਐਪ obvious ਲੱਗਦੀ ਹੈ—ਜਾਂ ਤੁਰੰਤ ਹੀ ਗੁੰਝਲਦਾਰ। ਤੁਹਾਡਾ ਲਕਸ਼ ਹੈ ਕਿ ਕਿਸੇ ਉਪਭੋਗਤਾ ਨੂੰ ਤੁਰੰਤ ਤਿੰਨ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਮਿਲ ਜਾਣ: “ਮੇਰੇ OKRs ਕੀ ਹਨ?”, “ਮੇਰੀ ਟੀਮ ਕਿਵੇਂ ਕਰ ਰਹੀ ਹੈ?”, ਅਤੇ “ਕੀ ਅਸੀਂ ਕੰਪਨੀ ਦੇ ਤੌਰ ਤੇ ਟਰੈਕ 'ਤੇ ਹਾਂ?”

ਮੁੱਖ ਸਕ੍ਰੀਨਾਂ ਦਾ ਨਕਸ਼ਾ

ਛੋਟੀ ਤੇ ਕੇਂਦਰੀ ਸਕ੍ਰੀਨਾਂ ਦੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਮੇਨ ਨੈਵੀਗੇਸ਼ਨ ਤੋਂ ਇਕ ਕਲਿੱਕ 'ਤੇ ਪੁੱਜਣਯੋਗ ਰੱਖੋ:

• OKR ਲਿਸਟ: ਮੌਜੂਦਾ ਸਾਈਕਲ (ਅਤੇ ਪੁਰਾਣੀਆਂ ਸਾਈਕਲਾਂ) ਲਈ Objectives ਅਤੇ Key Results ਦਾ ਕੈਟਲੌਗ
• OKR ਡੀਟੇਲ: ਇੱਕ ਸਿੰਗਲ ਸੋഴ്ਸ ਆਫ਼ ਤਥ—ਵੇਰਵਾ, ਮਾਲਕ, ਐਲਾਈਨਮੈਂਟ, ਪ੍ਰੋਗਰੈੱਸ, ਇਤਿਹਾਸ ਅਤੇ ਟਿੱਪਣੀਆਂ
• ਚੈਕ-ਇਨਸ: ਅੱਪਡੇਟ ਪੋਸਟ ਕਰਨ ਲਈ ਕੇਂਦਰੀ ਥਾਂ ਬਿਨਾਂ ਸਹੀ ਪੇਜ਼ ਦੀ ਭਾਲ ਕੀਤੇ
• ਡੈਸ਼ਬੋਰਡਸ: Individuals, teams ਅਤੇ ਕੰਪਨੀ ਲਈ ਰੋਲਅਪਸ ਅਤੇ ਤਰੰਗਾਂ
• ਐਡਮਿਨ: cycles, org structure, permissions, templates, ਅਤੇ integrations

ਸੈਕੰਡਰੀ ਕਰਵਾਈਆਂ (export, duplicate, archive) ਨੂੰ ਸੰਬੰਧਤ ਸਕ੍ਰੀਨ ਦੇ ਮੀਨੂ ਵਿੱਚ ਰੱਖੋ, ਗਲੋਬਲ ਨੈਵੀਗੇਸ਼ਨ ਵਿੱਚ ਨਹੀਂ।

“ਮੇਰਾ / ਟੀਮ / ਕੰਪਨੀ” ਆਲੇ-ਦੁਆਲੇ ਨੈਵੀਗੇਸ਼ਨ ਡਿਜ਼ਾਈਨ ਕਰੋ

ਜ਼ਿਆਦਾਤਰ ਉਪਭੋਗਤਾ ਇਹ ਤਿੰਨ ਲੈਂਸ ਵਿਚ ਸੋਚਦੇ ਹਨ। UI ਵਿੱਚ ਇਹਨਾਂ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਓ—ਟਾਪ-ਲੈਵਲ ਟੈਬਾਂ ਵਾਂਗ ਜਾਂ ਇਕ ਸਥਾਈ ਸਵਿਚਰ ਦੇ ਤੌਰ 'ਤੇ:

• My OKRs: ਡੀਫਾਲਟ ਉਹ ਆਈਟਮ ਜੋ ਯੂਜ਼ਰ ਮਾਲਕ ਹੈ ਜਾਂ ਯੋਗਦਾਨਕਾਰ ਹੈ
• Team OKRs: ਯੂਜ਼ਰ ਦੀ ਟੀਮ(ਆਂ) ਦਿਖਾਓ ਸਾਫ਼ ਮਾਲਕੀ ਅਤੇ ਐਲਾਈਨਮੈਂਟ ਨਾਲ
• Company OKRs: ਉੱਚ-ਸਤਰ Objectives ਅਤੇ ਕੁੱਲ ਪ੍ਰਗਤੀ ਨੂੰ ਰੋਸ਼ਨ ਕਰਦਾ

ਢਿੱਲ੍ਹਾ ਸੋਚ ਘਟਾਉਣ ਲਈ ਡਿਫਾਲਟ ਲੈਂਡਿੰਗ ਦ੍ਰਿਸ਼ "My OKRs" ਰੱਖੋ।

ਗਲੋਬਲ ਸਰਚ, ਫਿਲਟਰ ਅਤੇ ਤੇਜ਼ ਵਰਕਫਲੋ

Objectives, Key Results ਅਤੇ ਲੋਕਾਂ 'ਤੇ ਕੰਮ ਕਰਨ ਵਾਲੀ ਗਲੋਬਲ ਸਰਚ ਜੋੜੋ। ਇਸਨੂੰ ਆਸਾਨ ਫਿਲਟਰਾਂ ਨਾਲ ਜੋੜੋ ਜੋ OKRs ਨੂੰ ਮੈਨੇਜ ਕਰਨ ਦੇ ਤਰੀਕੇ ਨਾਲ ਮਿਲਦੇ ਹਨ: cycle, owner, status, department, ਅਤੇ tags।

ਗੈਰ-ਟਕਨੀਕੀ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਫਲੋ ਛੋਟੇ ਰੱਖੋ: ਸਪਸ਼ਟ ਲੇਬਲ ("Create Objective", "Add Key Result"), ਮਜ਼ਬੂਤ ਡਿਫਾਲਟ (ਮੌਜੂਦਾ ਸਾਈਕਲ), ਅਤੇ ਘੱਟ ਜ਼ਰੂਰੀ ਫੀਲਡ। ਇੱਕ ਯੂਜ਼ਰ ਇੱਕ OKR ਬਣਾਉਣ ਅਤੇ ਚੈਕ-ਇਨ ਪੋਸਟ ਕਰਨ ਵਿੱਚ ਇੱਕ ਮਿੰਟ ਤੋਂ ਘੱਟ ਸਮੇਂ ਲੈ ਸਕਦਾ ਹੈ।

OKRs ਲਈ ਡੇਟਾ ਮਾਡਲ ਡਿਜ਼ਾਈਨ ਕਰੋ (ਸਕੇਲ ਲਈ)

ਇੱਕ ਸਕੇਲਬਲ OKR ਐਪ ਇੱਕ ਸਾਫ਼, ਲਗਾਤਾਰ ਡੇਟਾ ਮਾਡਲ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਜੇ ਢਾਂਚਾ ਗੁੰਝਲਦਾਰ ਹੋਏ ਤਾਂ ਐਲਾਈਨਮੈਂਟ ਟੁੱਟੇਗਾ, ਰਿਪੋਰਟਿੰਗ ਧੀਮੀ ਹੋਵੇਗੀ, ਅਤੇ ਪਰਮਿਸ਼ਨ ਜਟਿਲ ਹੋ ਜਾਣਗੇ।

ਕੋਰ ਏਂਟੀਟੀਆਂ (ਜੋ ਲਾਜ਼ਮੀ ਹਨ)

ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਇੱਕ ਛੋਟੇ ਸੈੱਟ ਨਾਲ 80% ਲੋੜਾਂ ਕਵਰ ਕਰ ਸਕਦੀਆਂ ਹਨ:

• User: ਪ੍ਰੋਫ਼ਾਈਲ, ਟਾਈਟਲ, ਟਾਈਮਜ਼ੋਨ, ਐਕਟਿਵ ਸਥਿਤੀ
• Team ਅਤੇ Department: ਦੋ ਵੱਖ-ਵੱਖ ਧਾਰਨाएँ ਤਾਂ ਜੋ ਕ੍ਰਾਸ-ਫੰਕਸ਼ਨਲ ਟੀਮਾਂ ਨੂੰ org chart ਵਿੱਚ ਬੰਨ੍ਹਿਆ ਨਾ ਜਾਵੇ
• OKR Cycle: ਉਦਾਹਰਣ: “Q1 2026”, ਡੇਟਸ, ਸਥਿਤੀ (draft/active/closed) ਅਤੇ ਵਿਜ਼ਿਬਿਲਟੀ ਨਿਯਮ
• Objective: ਗੁਣਾਤਮਕ ਲਕਸ਼; ਮਾਲਕ, cycle, ਸਥਿਤੀ, ਅਤੇ ਵਿਜ਼ਿਬਿਲਟੀ ਸ਼ਾਮਲ
• Key Result: ਮਾਪਣ ਯੋਗ ਨਤੀਜਾ; metric type, starting value, target, ਅਤੇ current value

ਸਹਾਇਕ ਏਂਟੀਟੀਆਂ (ਜੋ ਇਸਨੂੰ ਵਰਤਣਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ)

ਆਪਲੀਕੇਸ਼ਨ ਨੂੰ ਭਰੋਸੇਯੋਗ ਅਤੇ ਸਹਿਯੋਗੀ ਬਣਾਉਣ ਲਈ OKRs ਦੇ ਇਤਿਹਾਸ ਨੂੰ ਸਟੋਰ ਕਰੋ:

• Check-in: ਟਾਈਮਸਟੈਂਪਡ ਪ੍ਰਗਤੀ ਅੱਪਡੇਟ (value, confidence, note)
• Comment: ਹਰ Objective ਜਾਂ Key Result ਲਈ ਚਰਚਾ ਥ੍ਰੇਡ
• Update history / audit log: ਕਿਸਨੇ ਕੀ ਬਦਲਿਆ ਅਤੇ ਕਦੋਂ (ਖਾਸ ਕਰਕੇ ਟਾਰਗਟ ਅਤੇ ਮਾਲਕੀ ਲਈ)
• Attachment / link: ਦਸਤਾਵੇਜ਼ਾਂ, ਡੈਸ਼ਬੋਰਡ, ਟਿਕਟਾਂ ਜਾਂ ਸਪੇਸਿਫਿਕੇਸ਼ਨਾਂ ਦੇ ਰੈਫਰੰਸ

ਰਿਸ਼ਤੇ: ਐਲਾਈਨਮੈਂਟ ਅਤੇ ਮਾਲਕੀ

ਜਦੋਂ ਵਧੇਰੇ ਟੀਮਾਂ ਮਿਲ ਕੇ ਕੰਮ ਕਰਦੀਆਂ ਹਨ ਤਾਂ OKRs ਜ਼ਿਆਦਾ ਜਟਿਲ ਹੋ ਜਾਂਦੇ ਹਨ। ਇਹ ਰਿਸ਼ਤੇ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਮਾਡਲ ਕਰੋ:

• Ownership: ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਮਾਲਕ (ਯੂਜ਼ਰ ਜਾਂ ਟੀਮ) ਅਤੇ ਵਿਕਲਪਿਕ ਕੋ-ਓਨਰ
• Contributors: KRs ਅਤੇ ਯੂਜ਼ਰ/ਟੀਮਾਂ ਵਿਚਕਾਰ many-to-many ਲਿੰਕ
• Alignment / parent-child links: ਇੱਕ Objective (ਜਾਂ KR) ਨੂੰ parent objective ਨਾਲ ਲਿੰਕ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿਓ। ਜੇਕਰ ਤੁਸੀਂ multiple parents ਸਹਾਇਤਾ ਕਰਨ ਦੀ ਸੋਚ ਰਹੇ ਹੋ ਤਾਂ ਕੇਵਲ ਅਗਰ ਲੋੜ ਸੱਚਮੁੱਚ ਹੋਵੇ ਤਦ ਹੀ ਕਰੋ—ਨਹੀਂ ਤਾਂ ਰਿਪੋਰਟਿੰਗ ਗੁੰਝਲਦਾਰ ਹੋ ਸਕਦੀ ਹੈ।

ਪ੍ਰਗਤੀ ਕਿਵੇਂ ਸਟੋਰ ਕਰੋ (ਤਾਂ ਜੋ ਰਿਪੋਰਟਿੰਗ ਤੇਜ਼ ਰਹੇ)

ਹਰ Key Result ਲਈ ਸਟੋਰ ਕਰੋ:

• Start value, current value, target value (ਅਤੇ unit: %, $, #, yes/no)
• Confidence (ਜਿਵੇਂ red/yellow/green) ਅਤੇ ਵਿਕਲਪਿਕ trend (up/flat/down)

ਤੇਜ਼ ਡੈਸ਼ਬੋਰਡ ਲਈ latest “current value” ਨੂੰ KR ਰਿਕਾਰਡ 'ਤੇ ਰੱਖੋ, ਅਤੇ ਹਰ check-in ਨੂੰ ਟਾਈਮਲਾਈਨ ਅਤੇ ਰੋਲਅਪਸ ਲਈ ਸੱਚਾਈ ਦਾ ਸਰੋਤ ਬਣਾਓ।

ਰੋਲ, ਪਰਮਿਸ਼ਨ, ਅਤੇ ਆਰਗ ਸਟ੍ਰੱਕਚਰ ਸੈਟ ਕਰੋ

ਛੰਗੀ OKR ਐਪ ਸਿਰਫ Objectives ਦੀ ਸੂਚੀ ਨਹੀਂ—ਇਹ ਤੁਹਾਡੇ ਕੰਪਨੀ ਦੇ ਅਸਲ ਤਰੀਕੇ ਦਾ ਪਰਿਚੇਕ ਹੈ। ਜੇ ਉਤਪਾਦ ਵਿੱਚ org chart ਬਹੁਤ ਕਠੋਰ (ਤਾਕਿ) ਜਾਂ ਬਹੁਤ ਢਿੱਲਾ ਹੋਵੇ ਤਾਂ ਐਲਾਈਨਮੈਂਟ ਟੁੱਟ ਸਕਦਾ ਹੈ ਅਤੇ ਲੋਕ ਜੋ ਉਹ ਦੇਖ ਰਹੇ ਹਨ ਉਤੇ ਭਰੋਸਾ ਘੱਟ ਹੋ ਜਾਵੇਗਾ।

ਟੀਮਾਂ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਅਨੁਸਾਰ org ਮਾਡਲਿੰਗ ਕਰੋ

ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਬੁਣਿਆਦੀ ਕੀਮਤਾਂ ਨਾਲ ਸਹੀ ਕਰੋ: departments ਅਤੇ teams। ਫਿਰ ਹਕੀਕਤੀ ਜਟਿਲਤਾ ਲਈ ਯੋਜਨਾ ਬਣਾਓ:

• Matrix teams (ਉਦਾਹਰਣ: ਇਕ ਡਿਜ਼ਾਇਨਰ “Design” ਨੂੰ ਹੁੰਦਾ ਹੈ ਪਰ “Product Squad A” ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ)
• Shared ownership ਜਿੱਥੇ ਇੱਕ Objective ਇੱਕ ਟੀਮ ਦਾ ਮਾਲਕ ਹੋਵੇ ਪਰ Key Results ਕਈ ਟੀਮਾਂ ਨਾਲ ਕੋ-ਓਨਰਡ ਹੋ ਸਕਦੇ ਹਨ
• ਅਸਥਾਈ ਗਰੁੱਪ ਜਿਵੇਂ ਟਾਸਕ ਫੋਰਸਜ਼ ਜਾਂ ਤਿਮਾਹੀ ਉਪਰਾਲੇ

ਇਹ ਢਾਂਚਾ ਹਰ ਚੀਜ਼ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ: ਕੌਣ ਕਿਹੜੇ OKRs ਵੇਖ ਸਕਦਾ ਹੈ, ਰੋਲਅਪਸ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ, ਅਤੇ ਲੋਕ ਸਹੀ ਥਾਂ 'ਤੇ ਚੈਕ-ਇਨ ਕਿਵੇਂ ਕਰਦੇ ਹਨ।

ਰੋਲ ਨਿਰਧਾਰਤ ਕਰੋ ਅਤੇ ਹਰ ਰੋਲ ਕੀ ਕਰ ਸਕਦਾ ਹੈ

Admin ਲਈ ਪ੍ਰਬੰਧਨ ਆਸਾਨ ਰਹਿਣ ਲਈ role-based access control ਸਧਾਰਨ ਰੱਖੋ, ਪਰ ਕਾਫੀ ਵਿਸਥਿਤ ਵੀ ਹੋਵੇ।

ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਬੇਸਲਾਈਨ:

• Viewer: ਡੇਖ ਸਕਦਾ ਹੈ ਜੋ ਉਹ ਦੇਖਣ ਲਈ ਅਧਿਕਾਰ ਰੱਖਦਾ ਹੈ, (ਚਿੱਠੀ) ਟਿੱਪਣੀ ਕਰ ਸਕਦਾ ਹੈ
• Contributor: ਡ੍ਰਾਫਟ OKRs ਬਣਾ ਸਕਦਾ ਹੈ (ਆਪਣੇ ਖੇਤਰ ਵਿੱਚ), ਚੈਕ-ਇਨ ਪੋਸਟ ਕਰ ਸਕਦਾ ਹੈ, ਸੁਝਾਅ ਦੇ ਸਕਦਾ ਹੈ
• Editor: OKRs ਨੂੰ ਸੋਧ ਅਤੇ ਐਲਾਈਨ ਕਰ ਸਕਦਾ ਹੈ, ਮਾਲਕਾਂ ਨੂੰ ਮੈਨੇਜ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਸਥਿਤੀਆਂ ਅੱਪਡੇਟ ਕਰ ਸਕਦਾ ਹੈ
• Admin: org structure, cycles, permissions, ਅਤੇ global settings ਮੈਨੇਜ ਕਰਦਾ ਹੈ

"ਸਭ ਨੂੰ ਹਰ ਚੀਜ਼ ਸੋਧਣ ਦੀ ਆਜ਼ਾਦੀ" ਤੋਂ ਬਚੋ — ਇਹ ਜਾਂ ਪਰੇਸ਼ਾਨੀ ਵਾਲੇ ਬਦਲਾਅ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜਾਂ ਲਗਾਤਾਰ "ਕਿਸ ਨੇ ਇਹ ਬਦਲਿਆ?" ਦੀ ਗੱਲ ਚੱਲਦੀ ਰਹੇਗੀ।

ਸਾਈਕਲ ਅਤੇ ਗਵਰਨੈਂਸ ਐਕਸ਼ਨਾਂ 'ਤੇ ਕੌਣ ਨਿਆੰਤਰਣ ਕਰਦਾ ਹੈ

ਕੁਝ ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੇ ਐਕਸ਼ਨਾਂ ਬਾਰੇ ਸਪਸ਼ਟ ਹੋਵੋ:

• ਕੌਣ cycles ਬਣਾ ਸਕਦਾ ਹੈ (quarters, half-years) ਅਤੇ ਤਾਰੀਖਾਂ ਲਗਾ ਸਕਦਾ ਹੈ?
• ਕੌਣ publish ਕਰ ਸਕਦਾ ਹੈ ਤਾਂ ਜੋ OKRs drafts ਤੋਂ ਬਾਹਰ ਦਿਖਾਈ ਦੇਣ?
• ਕੌਣ lock edits ਕਰ ਸਕਦਾ ਹੈ ਇਕ ਸਾਈਕਲ ਸ਼ੁਰੂ ਹੋਣ 'ਤੇ (ਜਾਂ ਸਮੀਖਿਆ ਮਿਆਦ ਦੇ ਬਾਅਦ)?
• ਕੌਣ archive ਕਰ ਸਕਦਾ ਹੈ ਪੁਰਾਣੇ cycles ਅਤੇ ਉਹਨਾਂ ਨੂੰ restore ਕਰ ਸਕਦਾ ਹੈ?

ਇੱਕ ਆਮ ਪੈਟਰਨ: admins cycles ਬਣਾ ਦਿੰਦਿਆਂ ਹਨ, department editors ਉਹਨਾਂ ਦੇ ਖੇਤਰਾਂ ਵਿੱਚ publish ਕਰਦੇ ਹਨ, ਅਤੇ locking/archiving admins (ਜਾਂ ਛੋਟੀ ops ਟੀਮ) ਤੱਕ ਸੀਮਿਤ ਰਹਿੰਦਾ ਹੈ।

ਵਿਜ਼ਿਬਿਲਟੀ ਸੈਟਿੰਗਜ਼ ਜੋ ਸੰਸਕ੍ਰਿਤੀ ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ

ਵਿਜ਼ਿਬਿਲਟੀ ਲਚਕੀਲਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:

• Company-wide: ਬਹੁਤ ਸਾਰੇ departmental OKRs ਲਈ ਡਿਫਾਲਟ
• Department-only: ਸੰਵੇਦਨਸ਼ੀਲ ਯੋਜਨਾਂ ਜਾਂ ਤੇਜ਼-ਪਹਿਲੇ ਕੰਮਾਂ ਲਈ
• Private drafts: ਵਿਅਕਤੀਗਤ ਜਾਂ ਟੀਮ ਦੇ ਨਿੱਜੀ ਡਰਾਫਟ ਲਈ

UI ਵਿੱਚ ਵਿਜ਼ਿਬਿਲਟੀ ਸਪਸ਼ਟ ਰੱਖੋ (ਬੈਜ + ਸ਼ੇਅਰਿੰਗ ਸਾਰਾਂਸ਼) ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਇਹ ਸਿਰਫ OKR ਪੇਜ਼ 'ਤੇ ਹੀ ਨਹੀਂ ਪਰ ਸਰਚ, ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਐਕਸਪੋਰਟ ਵਿੱਚ ਵੀ lagu ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

OKR ਲਾਈਫਸਾਇਕਲ ਅਤੇ ਵਰਕਫਲੋ ਸੂਚੀਬੱਧ ਕਰੋ

ਇੱਕ ਸਪਸ਼ਟ ਲਾਈਫਸਾਇਕਲ ਤੁਹਾਡੀ OKR ਐਪ ਨੂੰ ਟੀਮਾਂ ਵਿੱਚ ਇੱਕਸਾਰ ਬਣਾਉਂਦੀ ਹੈ। ਬਿਨਾਂ ਇਸਦੇ ਲੋਕ ਵੱਖ-ਵੱਖ ਫਾਰਮੈਟਾਂ ਵਿੱਚ ਟੀਚੇ ਬਣਾਉਂਦੇ ਰਹਿਣਗੇ, ਅਪਡੇਟ ਆਕਸਮਿਕ ਤਰੀਕੇ ਨਾਲ ਹੋਣਗੇ, ਅਤੇ "ਮੁਕੰਮਲ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ ਇਸ 'ਤੇ ਵਿਵਾਦ ਹੋਵੇਗਾ। ਛੋਟੀ ਵਰਕਫਲੋ ਸਥਿਤੀਆਂ ਨਿਰਧਾਰਤ ਕਰੋ ਅਤੇ ਹਰ ਸਕ੍ਰੀਨ (creation, editing, check-ins, reports) ਵਿੱਚ ਉਹਨਾਂ ਦੀ ਪਾਲਣਾ ਕਰੋ।

ਕੋਰ ਵਰਕਫਲੋ ਸਟੇਟਸ

ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਡਿਫਾਲਟ ਲਾਈਫਸਾਇਕਲ ਹੈ:

Draft → Review → Published → In progress → Closed

ਹਰ ਸਥਿਤੀ ਨੂੰ ਤਿੰਨ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ:

• ਕੌਣ ਸੋਧ ਸਕਦਾ ਹੈ? (ਉਦਾਹਰਨ: ਮਾਲਕ ਹੀ ਜਾਂ ਸਹਿਯੋਗੀ ਵੀ)
• ਕੀ ਬਦਲ ਸਕਦਾ ਹੈ? (Objective ਟੈਕਸਟ, KR ਟਾਰਗਟ, ਮਾਲਕ, ਮਿਆਦ)
• ਇਹ ਕਿੱਥੇ ਦਿਖਾਈ ਦੇਵੇਗਾ? (ਮਾਲਕ ਲਈ ਨਿੱਜੀ vs ਟੀਮ ਡੈਸ਼ਬੋਰਡ)

ਉਦਾਹਰਨ ਵਜੋਂ, Draft ਨੂੰ ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਨਿੱਜੀ ਰੱਖੋ, ਫਿਰ Published ਨੂੰ ਰੋਲਅਪਸ ਅਤੇ OKR ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਦਿਖਾਓ ਤਾਂ ਕਿ ਲੀਡਰਸ਼ਿਪ ਦੇ ਨਜ਼ਰਾਂ 'ਚ ਅਧੂਰੇ ਕੰਮ ਪੈਰਾਓ ਨਾ ਕਰਨ।

ਸਮੀਖਿਆ ਕਦਮ ਜੋ ਮਿਸਐਲਾਈਨਮੈਂਟ ਰੋਕਦੇ ਹਨ

ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਨੂੰ OKRs ਨੂੰ "ਅਸਲ" ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਹਲਕੇ ਗੇਟਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਸੰਰਚਨਾਤਮਕ ਸਮੀਖਿਆ ਕਦਮ ਜੋੜੋ ਜਿਵੇਂ:

• ਮੈਨੇਜਰ ਮਨਜ਼ੂਰੀ ਵਿਅਕਤੀਗਤ OKRs ਲਈ
• ਲੀਡਰਸ਼ਿਪ ਸਮੀਖਿਆ departmental OKRs ਲਈ
• ਐਲਾਈਨਮੈਂਟ ਚੈਕ ਜੋ ਹਰ OKR ਦੀ ਪੁਸ਼ਟੀ ਕਰੇ ਕਿ ਇਹ ਕਿਸੇ parent ਨਾਲ ਲਿੰਕ ਕੀਤਾ ਗਿਆ ਹੈ (ਜਾਂ ਖੁੱਲ੍ਹੇ ਤੌਰ 'ਤੇ "top-level" ਦੇ ਤੌਰ 'ਤੇ ਦਰਸਾਇਆ ਗਿਆ ਹੈ)

ਐਪ ਵਿੱਚ ਸਮੀਖਿਆ ਇੱਕ ਸਪਸ਼ਟ ਕਾਰਵਾਈ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ (Approve / Request changes) ਇੱਕ ਟਿੱਪਣੀ ਬਾਕਸ ਨਾਲ, ਨਾ ਕਿ ਅਨੁਪਚਾਰੀ Slack ਸੁਨੇਹਿਆਂ ਵਰਗੇ। ਫੀਡਬੈਕ ਦੇ ਬਾਅਦ ਕੀ ਹੁੰਦਾ ਹੈ ਇਹ ਵੀ ਤੈਅ ਕਰੋ: ਆਮ ਤੌਰ 'ਤੇ Review → Draft (ਨੋਟਸ ਦੇ ਨਾਲ) ਜਦ ਤੱਕ ਦੁਬਾਰਾ ਸਬਮਿਟ ਨਾ ਕੀਤਾ ਜਾਵੇ।

ਸਾਈਕਲ ਬਦਲਾਅ: carry over, archive, clone

ਤਿਮਾਹੀ ਦੇ ਅਖ਼ੀਰ 'ਤੇ, ਯੂਜ਼ਰ ਕੰਮ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤਾਉਣਾ ਚਾਹੁੰਦੇ ਹਨ ਬਿਨਾਂ ਇਤਿਹਾਸ ਗੁਆਏ। ਤਿੰਨ ਵੱਖ-ਵੱਖ ਐਕਸ਼ਨਾਂ ਦੀ ਸਹਾਇਤਾ ਕਰੋ:

• Close & archive: OKR ਨੂੰ ਲਾਕ ਕਰੋ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਲਈ ਉਪਲਬਧ ਰੱਖੋ
• Clone to next cycle: ਸਾਂਚਾ ਨਕਲ ਕਰੋ, ਤਰੱਕੀ ਰੀਸੈਟ ਕਰੋ, ਲਿੰਕ ਰੱਖਣ ਦੀ ਚੋਣ ਦਿਓ
• Carry over: ਇੱਕੋ OKR ਨੂੰ ਅਗਲੇ ਸਾਈਕਲ ਵਿੱਚ ਲਿਜਾਓ (ਸਾਵਧਾਨੀ ਨਾਲ ਵਰਤੋ; ਇਹ ਗੱਲ ਛੁਪੀ ਹੋਈ ਯੋਜਨਾ ਨੂੰ ਛੁਪਾ ਸਕਦੀ ਹੈ)

ਇਹ ਕਾਰਵਾਈਆਂ ਸਾਈਕਲ ਬੰਦ ਕਰਨ ਵਾਲੇ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਦਿੱਖਣਗੀਆਂ ਹੋਣ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਰੋਲਅਪਸ clones ਨੂੰ double-count ਨਾ ਕਰਨ।

ਲਕਸ਼ ਅਤੇ ਟਾਰਗਟ ਬਦਲਾਅ ਲਈ ਆਡੀਟ ਟਰੇਲ

ਟਾਰਗਟ ਬਦਲ ਸਕਦੇ ਹਨ। ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਇਹ ਰਿਕਾਰਡ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿਸਨੇ ਕੀ ਬਦਲਿਆ, ਕਦੋਂ, ਅਤੇ ਕਿਉਂ—ਖਾਸ ਕਰਕੇ Key Result ਬੇਸਲਾਈਨ ਅਤੇ ਟਾਰਗਟ ਮੁੱਲਾਂ ਲਈ। ਫੀਲਡ-ਸਟੇਪ ਡਿਫਸ (old value → new value) ਅਤੇ ਵਿਕਲਪਿਕ ਨੋਟਸ ਰੱਖਣ ਵਾਲਾ ਆਡੀਟ ਟਰੇਲ ਰੱਖੋ।

ਇਹ ਆਡੀਟ ਇਤਿਹਾਸ ਭਰੋਸਾ ਬਣਾਉਂਦਾ ਹੈ: ਟੀਮਾਂ ਚਰਚਾ ਕਰ ਸਕਦੀਆਂ ਹਨ ਬਿਨਾਂ ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਰਿਹਾ ਕਿ ਲਕਸ਼ ਬਦਲੇ ਗਏ ਸਨ।

OKRs ਬਣਾਉਣ ਅਤੇ ਐਲਾਈਨ ਕਰਨ ਲਈ UX ਬਣਾਓ

ਇੱਕ ਵਧੀਆ OKR ਐਪ ਇਸ ਗੱਲ 'ਤੇ ਟਿਕਦਾ/ਟਿਕਦੀ ਹੈ ਕਿ ਚੰਗਾ Objective ਲਿਖਣਾ, ਮਾਪਣਯੋਗ Key Results ਡਿਫਾਈਨ ਕਰਨਾ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਹੋਰ ਟੀਮਾਂ ਨਾਲ ਜੋੜਨਾ ਕਿੰਨਾ ਆਸਾਨ ਹੈ। UX ਨੂੰ ਇੱਕ ਗਾਈਡਡ ਲਿਖਤ ਵਾਂਗ ਮਹਿਸੂਸ ਕਰਵਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਨਾ ਕਿ "ਡੇਟਾਬੇਸ ਭਰੀਏ" ਜਿਹਾ।

ਇੰਲਾਈਨ ਗਾਈਡੰਸ ਨਾਲ ਸਧਾਰਨ ਬਣਾਉਣ ਪ੍ਰਕਿਰਿਆ

ਇੱਕ ਸਾਫ, ਦੋ-ਭਾਗੀ ਫਾਰਮ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: Objective (ਸਪਸ਼ਟ ਨਤੀਜਾ) ਅਤੇ Key Results (ਮਾਪਣ ਯੋਗ ਸੰਕੇਤ)। ਸਧਾਰਨ ਲੇਬਲ ਵਰਤੋ ਅਤੇ ਛੋਟੇ, ਇੰਲਾਈਨ ਪ੍ਰਾਂਪਟ ਦਿਓ ਜਿਵੇਂ "ਬਦਲਾਅ ਦਾ ਵਰਣਨ ਕਰੋ" ਜਾਂ "ਇੱਕ ਨੰਬਰ + ਡੈਡਲਾਈਨ ਵਰਤੋ"।

ਬਣਾਉਣ ਦੌਰਾਨ ਰੀਅਲ-ਟਾਈਮ ਵੈਲਿਡੇਸ਼ਨ ਦਿਖਾਓ ਜੋ ਸਿੱਖਾਉਂਦਾ ਹੈ ਪਰ ਰੋਕਦਾ ਨਹੀਂ—ਉਦਾਹਰਨ ਲਈ agar Key Result ਕੋਲ ਕੋਈ ਮੈਟਰਿਕ ਨਾ ਹੋਵੇ ਤਾਂ ਚੇਤਾਵਨੀ ਦਿਖਾਓ ("ਕਿਹੜਾ ਮਾਪ, ਕਿੰਨਾ")। ਆਮ KR ਕਿਸਮਾਂ ਲਈ ਇਕ-ਕਲਿੱਕ ਟੌਗਲ (number, %, $) ਦਿਓ ਅਤੇ ਫੀਲਡ ਦੇ ਕੋਲ ਹੀ ਉਦਾਹਰਣ ਦਿਖਾਓ।

ਟੈਮਪਲੇਟ ਅਤੇ ਉਦਾਹਰਣ ਤਾਂ ਜੋ ਖਾਲੀ ਪੇਜ਼ ਦਾ ਝਟਕਾ ਘਟੇ

ਡਿਪਾਰਟਮੈਂਟ-ਵਾਰ (Sales, Product, HR) ਅਤੇ ਥੀਮ-ਵਾਰ (Growth, Reliability, Customer Satisfaction) ਟੈਮਪਲੇਟ ਦਿਓ। ਯੂਜ਼ਰ ਨੂੰ ਟੈਮਪਲੇਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਦਿਓ, ਫਿਰ ਸਭ ਕੁਝ ਸੋਧਣ ਦੀ ਛੋੜ। ਟੈਮਪਲੇਟ OKR ਸਾਫ਼ ਕਰਨ ਵਾਲੀਆਂ ਭਾਸ਼ਾਵਾਂ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਅਡਾਪਸ਼ਨ ਤੇਜ਼ ਕਰਦੇ ਹਨ।

ਪਿਛਲੇ ਤਿਮਾਹੀ ਦੇ OKRs ਨੂੰ searchable ਰੱਖੋ ਤਾਂ ਜੋ ਲੋਕ ਪੈਟਰਨ ਦੁਹਰਾਉਣ ਅਤੇ ਨਕਲ ਕਰਨ ਦੇ ਨਾਲ-ਨਾਲ ਸੁਝਾਅ ਵੀ ਲੈ ਸਕਣ।

ਐਲਾਈਨਮੈਂਟ ਸਹਾਇਕ ਜੋ ਪ੍ਰਸੰਗ ਦਿਖਾਓ

ਐਲਾਈਨਮੈਂਟ ਨੂੰ ਵੱਖ-ਵੱਖ ਕਦਮ ਨਾ ਬਣਾ। OKR ਬਣਾਉਂਦੇ ਸਮੇਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਯੋਗ ਬਣਾਓ:

• ਇੱਕ parent OKR ਚੁਣੋ (ਕੰਪਨੀ ਜਾਂ ਡਿਪਾਰਟਮੈਂਟ)
• ਸਾਈਡ ਪੈਨਲ ਵਿੱਚ ਸਬੰਧਤ OKRs ਦਿਖਾਓ (ਉਹੀ ਟੀਮ, ਉਹੀ ਇਨੀਸ਼ੀਏਟਿਵ, ਮਿਲਦੇ ਜੁਲਦੇ ਕੀਵਰਡ)
• ਐਲਾਈਨਮੈਂਟ ਪ੍ਰਭਾਵ ਦਾ ਪ੍ਰੀਵਿਊ ਦਿਖਾਓ (ਕੌਣ ਹੋਰ ਇਸਤੇ ਨਿਰਭਰ ਹੈ)

ਇਸ ਨਾਲ ਟੀਮ ਐਲਾਈਨਮੈਂਟ ਉਪਰ-ਸਿਰੇ ਤੇ ਰਹੇਗਾ ਅਤੇ ਆੱਗੇ ਚਲ ਕੇ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਰੋਲਅਪਸ ਸੁਧਰ ਜਾਣਗੇ।

ਤੇਜ਼ ਸੋਧਾਂ ਬਿਨਾਂ ਇਤਿਹਾਸ ਗੁਆਉਣ ਦੇ

ਸੋਧਾਂ ਨੂੰ ਸਧਾਰਨ ਮੰਨੋ। Autosave ਜੋੜੋ, ਅਤੇ "ਵਰਜ਼ਨ ਨੋਟਸ" (ਉਦਾਹਰਨ: "Pricing change ਤੋਂ ਬਾਅਦ ਟਾਰਗਟ ਥੋੜਾ ਘਟਾਇਆ") ਵਰਗੇ ਹਲਕੇ ਇਤਿਹਾਸ ਬਰਕਰਾਰ ਰੱਖੋ। ਇੱਕ ਸਾਫ਼ ਚੇਂਜ ਲੌਗ ਦਿਖਾਓ ਤਾਂ ਟੀਮਾਂ ਚੈੱਕ-ਇਨ ਵਰਕਫਲੋ ਦੌਰਾਨ ਬਦਲਾਅ 'ਤੇ ਭਰੋਸਾ ਰੱਖ ਸਕਣ।

ਚੈਕ-ਇਨ, ਅੱਪਡੇਟ ਅਤੇ ਟੀਮ ਸਹਿਯੋਗ ਲਾਗੂ ਕਰੋ

ਐਪ ਸਿਰਫ਼ ਸੁੰਦਰ ਡੈਸ਼ਬੋਰਡ ਰੱਖ ਕੇ ਕੰਮ ਨਹੀਂ ਕਰੇਗੀ—ਇਹ ਤਾਂ ਵਰਤੀ ਜਾਵੇਗੀ ਜੇ ਟੀਮਾਂ ਆਸਾਨੀ ਨਾਲ ਅੱਪਡੇਟ ਕਰਨ। ਚੈਕ-ਇਨ ਦਾ ਉਦੇਸ਼ ਹੈ ਹਕੀਕਤ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਕੈਪਚਰ ਕਰਨਾ—ਤਾਂ ਜੋ ਤਰੱਕੀ, ਖ਼ਤਰੇ ਅਤੇ ਫੈਸਲੇ ਦਰਸ਼ਨੀ ਰਹਿਣ ਬਿਨਾਂ ਹਫਤਾਵਾਰੀ ਕਾਗਜ਼-ਕਰਵਾਈ ਵਿੱਚ ਫੱਸਣ ਦੇ।

ਇੱਕ ਹਫਤਾਵਾਰ ਚੈਕ-ਇਨ ਫਲੋ ਜੋ ਲੋਕ ਖ਼ਤਮ ਕਰਨ

ਹਰ Key Result ਲਈ ਇੱਕ ਇਕ-ਕੁਝ-ਅੰਕ ਚੱਕਰ ਡਿਜ਼ਾਈਨ ਕਰੋ:

• ਮੈਟਰਿਕ ਅੱਪਡੇਟ ਕਰੋ (current value, ਪਿਛਲੇ check-in ਤੋਂ delta, ਜਾਂ % complete)
• ਕਨਫਿਡੈਂਸ ਸੈੱਟ ਕਰੋ (On track / At risk / Off track) ਤਾਂ ਜੋ ਲੀਡਰਜ਼ ਛੇਤੀ ਸਥਿਤੀ ਸਕੈਨ ਕਰ ਸਕਣ
• ਨੋਟਸ ਜੋੜੋ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ: ਕੀ ਬਦਲਿਆ, ਕੀ Sikhਿਆ, ਅਤੇ ਅਗਲੇ ਕਦਮ
• ਬਲਾਕਰ ਇੱਕ ਸਟ੍ਰੱਕਚਰਡ ਫੀਲਡ ਵਜੋਂ ਰੱਖੋ (ਵਿਕਲਪਿਕ) ਤਾਂ ਜੋ ਉਹ ਉਪਰ ਚੜ੍ਹ ਕੇ ਹੱਲ ਕੀਤੇ ਜਾ ਸਕਣ

ਫਾਰਮ ਛੋਟਾ ਰੱਖੋ, ਡ੍ਰਾਫਟ ਸੇਵਿੰਗ ਆਸਾਨ ਹੋਵੇ, ਅਤੇ ਪਿਛਲੇ ਹਫ਼ਤੇ ਦਾ ਸੰਦਰਭ ਅੱਗੇ ਭਰਿਆ ਹੋਇਆ ਹੋਵੇ ਤਾਂ ਲੋਕ ਸਿਫ਼ਰ ਤੋਂ ਸ਼ੁਰੂ ਨਾ ਕਰਣ।

ਹਲਕਾ-ਫੁਲਕਾ ਸਹਿਯੋਗ

Objectives, Key Results, ਅਤੇ ਵਿਅਕਤੀਗਤ check-ins 'ਤੇ comments ਸ਼ਾਮਲ ਕਰੋ। @mentions ਸਹਾਇਤਾ ਦਿਓ ਤਾਂ ਸਹੀ ਲੋਕਾਂ ਨੂੰ ਬਿਨਾਂ मीਟਿੰਗਾਂ ਦੇ ਖਿੱਚਿਆ ਜਾ ਸਕੇ, ਅਤੇ ਸਧਾਰਨ “decision log” ਪੈਟਰਨ ਦਿਓ: ਇੱਕ ਟਿੱਪਣੀ ਨੂੰ decision ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਮਿਤੀ ਅਤੇ ਮਾਲਕ ਦੇ ਨਾਲ, ਤਾਂ ਜੋ ਬਾਅਦ ਵਿੱਚ “ਅਸੀਂ ਦਿਸ਼ਾ ਕਿਉਂ ਬਦਲੀ?” ਨੂੰ ਜਵਾਬ ਮਿਲ ਜਾਵੇ।

ਸਬੂਤ ਲਿੰਕ ਬਿਨਾਂ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਦਰਦ ਦੇ

ਯੂਜ਼ਰਾਂ ਨੂੰ evidence links (docs, tickets, dashboards) ਲਗਾਉਣ ਦਿਓ ਬਿਨਾਂ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਦੇ ਮੁਸ਼ਕਲਾਂ ਦੇ। ਇੱਕ URL ਫੀਲਡ ਅਤੇ ਵਿਕਲਪਿਕ ਲੇਬਲ ("Jira ticket", "Salesforce report", "Spreadsheet") ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ। ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਟਾਈਟਲ ਆਟੋ-ਫੈਚ ਕਰੋ ਪਰ ਮੈਟਾਡੇਟਾ ਫੇਲ ਹੋਣ 'ਤੇ ਸੇਵ ਕਰਨ ਤੋਂ ਰੋਕੋ ਨਾ।

ਮੋਬਾਈਲ-ਪਹਿਲਾ ਅਤੇ ਘੱਟ friction

ਵਿਆਸਤ ਟੀਮਾਂ ਕਾਲਾਂ ਦੇ ਵਿਚਕਾਰ ਚੈਕ-ਇਨ ਕਰਦੀਆਂ ਹਨ। ਫੋਨਾਂ ਲਈ optimize ਕਰੋ: ਵੱਡੇ ਟੈਪ ਟਾਰਗਟ, ਘੱਟ ਟਾਈਪਿੰਗ, ਅਤੇ ਇੱਕ-ਸਕ੍ਰੀਨ ਸਮਰਪਿਤ ਬਟਨ। ਇਕ quick-action ("Check in now") ਅਤੇ ਰੀਮਾਇੰਡਰ ਜੋ ਸਿੱਧਾ ਸਬੰਧਤ KR ਨੂੰ ਖੋਲ੍ਹਣ, ਡ੍ਰੌਪ-ਆਊਟ ਦੀ ਦਰ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਅਪਡੇਟ ਮਿਆਰੀ ਰੱਖਦੇ ਹਨ।

ਡੈਸ਼ਬੋਰਡ, ਰਿਪੋਰਟਿੰਗ ਅਤੇ ਰੋਲਅਪਸ ਬਣਾਓ

ਡੈਸ਼ਬੋਰਡਸ ਉਹ ਥਾਂ ਹਨ ਜਿੱਥੇ OKR ਐਪ ਰੋਜ਼ਾਨਾ ਕਾਮੀ ਆਉਂਦਾ ਹੈ। ਲਕਸ਼ ਦੋ ਸਵਾਲਾਂ ਦਾ ਤੇਜ਼ ਜਵਾਬ ਦੇਣਾ ਹੈ: "ਅਸੀਂ ਟਰੈਕ 'ਤੇ ਹਾਂ?" ਅਤੇ "ਮੈਨੂੰ ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ?"। ਇਸ ਲਈ, ਕੰਪਨੀ, ਡਿਪਾਰਟਮੈਂਟ, ਟੀਮ ਅਤੇ ਵਿਅਕਤੀਗਤ ਪੱਧਰਾਂ 'ਤੇ ਡੈਸ਼ਬੋਰਡ ਬਣਾਓ ਪਰ ਇੱਕੋ ਹੀ ਮਾਨਸਿਕ ਮਾਡਲ ਰੱਖੋ।

ਪੱਧਰ ਅਨੁਸਾਰ ਡੈਸ਼ਬੋਰਡ (ਕੰਪਨੀ → ਵਿਅਕਤੀ)

ਹਰ ਪੱਧਰ ਇੱਕ ਹੀ ਜਿਹੇ ਵਿਜ਼ੇਟ ਦਿਖਾਏ: ਕੁੱਲ ਸਥਿਤੀ ਵੰਡ, ਪ੍ਰਮੁੱਖ at-risk Objectives, ਆਉਣ ਵਾਲੀਆਂ ਸਮੀਖਿਆ ਮਿਤੀਆਂ, ਅਤੇ check-in ਹੇਲਥ। ਫ਼ਰਕ ਦਾਇਰਾ ਫਿਲਟਰ ਅਤੇ ਡਿਫਾਲਟ ਮਾਲਕ ਸੰਦਰਭ ਹੈ।

ਕੰਪਨੀ ਡੈਸ਼ਬੋਰਡ ਆਰਗ-ਵਾਈਡ ਰੋਲਅਪ ਤੋਂ ਸ਼ੁਰੂ ਹੋ ਸਕਦਾ ਹੈ; ਟੀਮ ਡੈਸ਼ਬੋਰਡ ਸਿਰਫ ਉਹ Objectives ਹਾਈਲਾਈਟ ਕਰੇ ਜੋ ਟੀਮ ਮਾਲਕ ਹੈ ਅਤੇ ਉਹ parent Objectives ਜੋ ਉਹਨਾਂ ਨੂੰ ਜੋੜਦੇ ਹਨ।

ਰੋਲਅਪਸ ਅਤੇ ਡ੍ਰਿਲ-ਡਾਊਨ ਜ਼ਾਹਿਰ

ਰੋਲਅਪ ਪਾਰਦਰਸ਼ੀ ਹੋਣ ਚਾਹੀਦੇ ਹਨ, ਨਾ ਕਿ "ਜਾਦੂ"। ਯੂਜ਼ਰਾਂ ਨੂੰ Objective ਤੋਂ KRs ਅਤੇ ਫਿਰ ਤਾਜ਼ਾ ਅੱਪਡੇਟਸ, ਟਿੱਪਣੀਆਂ ਅਤੇ ਸਬੂਤ ਵਿੱਚ ਡਿੱਲ-ਡਾਊਨ ਕਰਨ ਦਿਓ। ਇੱਕ ਚੰਗਾ ਪੈਟਰਨ:

• Objective ਕਾਰਡ → KRs ਸੂਚੀ (ਪ੍ਰੋਗਰੈੱਸ + ਕਨਫਿਡੈਂਸ)
• Key result ਰੋ → ਅਪਡੇਟ ਟਾਈਮਲਾਈਨ (ਨਵੀਨਤਮ ਪਹਿਲਾਂ)
• ਅਪਡੇਟ ਟਾਈਮਲਾਈਨ → ਜੁੜੇ ਲਿੰਕ, ਬਲਾਕਰ, ਫੈਸਲੇ

ਬ੍ਰੈਡਕ੍ਰੰਬ ਟਰੇਲ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਸਭ ਵੇਲੇ ਪਤਾ ਰਹੇ ਕਿ ਉਹ ਕਿੱਥੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਜਦ ਉਹ ਸਾਂਝੇ ਲਿੰਕ ਤੋਂ ਆਏ ਹੋਣ।

ਜੋਖਮ ਨੂੰ ਮੁੱਢੇ ਤੋਂ surface ਕਰਨ ਵਾਲੇ ਵਿਊਜ਼

ਇਹਨਾਂ ਵਿਊਜ਼ ਨੂੰ ਫਿਲਟਰਾਂ ਨਾ ਸਮਝੋ—ਉਹਨਾਂ ਨੂੰ ਅਲੱਗ ਵਿਊਜ਼ ਬਣਾਓ:

• ਸਥਿਤੀ ਅਤੇ ਕਨਫਿਡੈਂਸ (ਉਦਾਹਰਨ: On track / Off track + High/Medium/Low)
• ਅਧੂਰੇ ਚੈਕ-ਇਨ (ਕੌਣ ਅੱਪਡੇਟ ਨਹੀਂ ਕੀਤਾ ਅਤੇ ਕਿੰਨੇ ਦਿਨ ਹੋਏ)
• At-risk goals (ਘੱਟ ਕਨਫਿਡੈਂਸ, ਰੁਕੇ ਹੋਏ ਪ੍ਰਗਤੀ, ਜਾਂ ਨਿਰੰਤਰ ਬਲਾਕਰ)

ਇਹ ਵਿਊਜ਼ "follow-up ਨਿਰਧਾਰਤ" ਕਾਰਵਾਈਆਂ ਸਹਾਇਤ ਕਰਣਗੀਆਂ ਤਾਂ ਕਿ ਮੈਨੇਜਰ ਤੁਰੰਤ ਅਗਲਾ ਕਦਮ ਲੈ ਸਕਣ।

ਰਿਵਿਊ ਲਈ ਐਕਸਪੋਰਟੇਬਲ ਰਿਪੋਰਟਸ (PDF/CSV)

ਤੀਮਾਂ ਨੂੰ ਤਿਮਾਹੀ ਰਿਵਿਊ ਲਈ ਸਕਰੀਨਸ਼ਾਟ ਖਿੱਚਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ। ਇਕ-ਕਲਿੱਕ ਐਕਸਪੋਰਟ ਦਿਓ:

• PDF: ਇੱਕ ਸਾਫ਼ ਛਾਪਯੋਗ ਸਾਰਾਂਸ਼ ਪੱਧਰ ਅਨੁਸਾਰ, ਹਾਈਲਾਈਟਸ, ਜੋਖਮ, ਅਤੇ ਤਾਜ਼ਾ ਅੱਪਡੇਟ
• CSV: Objectives, Key Results, ਮਾਲਕ, ਸਥਿਤੀ, ਕਨਫਿਡੈਂਸ, ਆਖਰੀ ਚੈਕ-ਇਨ ਮਿਤੀ

ਜੇ ਤੁਸੀਂ scheduled exports ਸਮਰਥਨ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ email ਰਾਹੀਂ ਭੇਜੋ ਜਾਂ /reports ਹੇਠਾਂ ਸਟੋਰ ਕਰੋ ਤਾਂ ਕਿ ਰਿਵਿਊ ਮੀਟਿੰਗ ਦੌਰਾਨ ਆਸਾਨੀ ਹੋਵੇ।

ਇੰਟੀਗ੍ਰੇਸ਼ਨ, ਇੰਪੋਰਟ ਅਤੇ APIs ਦੀ ਯੋਜਨਾ

ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਅਡਾਪਸ਼ਨ ਨੂੰ ਬਣਾ-ਜਾਂ ਟੋਟਲ ਬਰਬਾਦ ਕਰ ਸਕਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੀ ਐਪ ਟੀਮਾਂ ਨੂੰ ਡੂਬਲ-ਡਾਟਾ ਦਰਜ ਕਰਨ ਤੇ ਮਜ਼ਬੂਰ ਕਰੇਗੀ ਤਾਂ ਉਹ ਨਜ਼ਰਅੰਦਾਜ਼ ਹੋ ਜਾਏਗੀ। ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਸ਼ੁਰੂ ਵਿੱਚ ਯੋਜਨਾ ਬਣਾਓ, ਪਰ ਅਜਿਹੇ ਆਦੇਸ਼ ਵਿੱਚ ਸ਼ਿਪ ਕਰੋ ਜੋ ਕੋਰ ਪ੍ਰੋਡਕਟ ਨੂੰ ਰੋਕਣ ਨਾ ਪਾਵੇ।

ਪਹਿਲਾਂ ਕੀ ਇੰਟੀਗ੍ਰੇਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ

ਉਹ ਟੂਲ ਪਹਿਲਾਂ ਜੋ ਡਬਲ ਐਨਟ੍ਰੀ ਘਟਾਉਂਦੇ ਅਤੇ ਵਿਜ਼ਿਬਿਲਟੀ ਵਧਾਉਂਦੇ:

• Slack / Microsoft Teams: ਚੈਕ-ਇਨ ਪ੍ਰੋਮਪਟ, ਤੇਜ਼ ਅੱਪਡੇਟ ਅਤੇ ਪ੍ਰਗਤੀ ਲਿੰਕ ਸਾਂਝਾ ਕਰਨ ਲਈ
• Jira (ਜਾਂ ਸਮਾਨ): Key Results ਨੂੰ delivery ਕੰਮ ਨਾਲ ਜੋੜਨ ਲਈ, ਪਰ ਇਹ ਧਿਆਨ ਰੱਖੋ ਕਿ "tickets = outcomes" ਨਹੀਂ ਹੁੰਦਾ
• Asana: ਟੀਮਾਂ ਜੋ task boards ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ ਉਨ੍ਹਾਂ ਲਈ ਲਾਇਟਵੇட் ਰੋਲਅਪਸ
• Google Sheets: ਤੇਜ਼ੇਨੋ imports/exports ਅਤੇ ਆਖਰੀ-ਕਦਮ ਵਾਲੇ ਵਰਕਫਲੋਜ਼ ਲਈ
• SSO (Google Workspace, Microsoft Entra ID/AD): ਲੌਗਿਨ ਤਕਲੀਫ਼ ਘਟਾਉਣ ਅਤੇ ਯੂਜ਼ਰ ਪ੍ਰੋਵਿਜ਼ਨ ਸਾਦਾ ਕਰਨ ਲਈ

ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਨਿਯਮ: ਉਹ ਸਿਸਟਮ ਜੁੜੋ ਜੋ ਪਹਿਲਾਂ ਹੀ ਤੁਹਾਡੇ ਯੂਜ਼ਰਾਂ ਦੀ ਰੋਜ਼ਾਨਾ ਵਰਕਫਲੋ ਦਾ "ਸੋਰਸ ਆਫ਼ ਈਥ" ਹੈ, ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਹਨੇਰੀ ਸੁਪਰ ਵੀਜ਼ ਨਾਲ analytics ਕੰਨੈਕਟਰ ਜੋੜੋ।

ਸ਼ੁਰੂਆਤੀ ਡੇਟਾ ਇੰਪੋਰਟ ਯੋਜਨਾ

ਜ਼ਿਆਦਾਤਰ ਰੋਲਆਉਟ spreadsheet ਜਾਂ slides ਵਿੱਚ ਮੌਜੂਦ OKRs ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ। ਇੱਕ CSV import ਸਮਰਥਨ ਕਰੋ ਜਿਸ ਵਿੱਚ:

• ਕਾਲਮ ਮੈਪਿੰਗ (Objective title, KR, owner, team, start/end dates, baseline/target, status)
• ਵੈਲਿਡੇਸ਼ਨ (ਗੁੰਮ ਮਾਲਕ, ਅਵੈਧ ਡੇਟਸ, ਡੁਪਲੀਕੇਟ IDs)
• ਡੁਪਲੀਕੇਸ਼ਨ ਰਣਨੀਤੀਆਂ (external ID ਨਾਲ match, normalized titles, ਜਾਂ user-confirmed merge step)

ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ imports ਨੂੰ idempotent ਬਣਾਓ ਤਾਂ ਕਿ ਸੁਧਾਰੇ ਹੋਏ ਫਾਈਲ ਨੂੰ ਦੁਬਾਰਾ ਅਪਲੋਡ ਕਰਨ 'ਤੇ duplicates ਨਾ ਬਣਨ।

API ਦੀਆਂ ਲੋੜਾਂ ਨਿਰਧਾਰਤ ਕਰੋ

ਸਪਸ਼ਟ ਕੀਤਾ ਕਿ ਤੁਹਾਡੀਆਂ 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, ਰੋਲ, ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਨੂੰ ਸਟੇਕਹੋਲਡਰਾਂ ਨਾਲ ਵੈਰੀਫਾਈ ਕਰਨ ਲਈ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਭਾਰੀ ਇੰਜੀਨੀਅਰਿੰਗ ਵਿੱਚ ਲੱਗਣ ਤੋਂ ਪਹਿਲਾਂ।

ਸੂਚਨਾਵਾਂ, ਰੀਮਾਇੰਡਰ ਅਤੇ ਆਟੋਮੇਸ਼ਨ ਜੋੜੋ

ਨੋਟੀਫਿਕੇਸ਼ਨ ਇੱਕ ਸ਼ਾਨਦਾਰ ਡੈਮੋ ਵਾਲੀ ਐਪ ਅਤੇ ਇੱਕ ਐਸੀ ਐਪ ਵਿਚਕਾਰ ਫਰਕ ਬਣਾਉਂਦੇ ਹਨ ਜਿਸ ਨੂੰ ਟੀਮਾਂ ਅਸਲ ਵਿੱਚ ਵਰਤਦੀਆਂ ਹਨ। ਲਕਸ਼ "ਜ਼ਿਆਦਾ ਪਿੰਗ ਨਹੀਂ"—ਸਗੋਂ ਸਮੇਂ-ਸਿਰ ਨੁੱਡਜ ਜੋ ਚੈਕ-ਇਨ ਅਤੇ ਸਮੀਖਿਆਆਂ ਨਹੀਂ ਰੁਕਣ ਦਿੰਦੀਆਂ, ਬਿਨਾਂ ਲੋਕਾਂ ਨੂੰ ਸਿਸਟਮ ਨੂੰ ਅਣਦੇਖਾ ਕਰਨ ਦੀ ਆਦਤ ਪਾਉਣ।

ਯਾਦ ਦਿਵਾਉਣ ਦੇ ਨਿਯਮ ਜੋ ਅਸਲ OKR ਕੰਮ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ

ਕੁਝ ਸਪਸ਼ਟ, ਉਚ-ਸਿਗਨਲ ਰੀਮਾਇੰਡਰ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:

• ਅਧੂਰੇ ਚੈਕ-ਇਨ: ਜੇ KR ਨੇ ਚੁਣੀ cadence (ਹਫ਼ਤੇਵਾਰ/ਦੋ-ਹਫ਼ਤੇ) ਤੱਕ ਅੱਪਡੇਟ ਨਹੀਂ ਪਾਈ ਤਾਂ ਮਾਲਕ ਨੂੰ ਰੀਮਾਇੰਡਰ ਭੇਜੋ
• ਸਾਈਕਲ ਨੇੜੇ ਆਉਂਦਾ ਹੈ: ਅੰਤ ਤਰੀਖ ਤੋਂ ਪਹਿਲਾਂ ਮਾਲਕਾਂ ਨੂੰ ਅਪਡੇਟ ਅਤੇ ਕਨਫਿਡੈਂਸ ਫਾਈਨਲ ਕਰਨ ਲਈ ਨੱਜ਼ਦਿ
• ਸਮੀਖਿਆ ਡੈਡਲਾਈਨ: ਜਦੋਂ ਜ਼ਿੰਮੇਵਾਰਾਂ/ਰੀਵਿਊਅਰਾਂ ਨੂੰ ਸਮੀਖਿਆ ਨਿਰਧਾਰਿਤ ਹੋਏ ਤੇ ਉਹ ਪੈਂਡਿੰਗ ਹਨ ਤਾਂ ਯਾਦ ਦਿਵਾਉਣਾ

ਰੂਲਾਂ workspace ਜਾਂ org ਪੱਧਰ 'ਤੇ ਕਸਟਮਾਈਜ਼ੇਬਲ ਰੱਖੋ, ਪਰ ਸਮਝਦਾਰ ਡਿਫਾਲਟਾਂ ਦੇ ਨਾਲ shipment ਕਰੋ (ဥਦਾਹਰਨ: ਮਿਸਡ ਚੈਕ-ਇਨ ਤੋਂ 24 ਘੰਟੇ ਬਾਅਦ ਇਕ ਰੀਮਾਇੰਡਰ, ਅਤੇ 48 ਘੰਟੇ ਬਾਅਦ ਦੂਜਾ)।

ਯੂਜ਼ਰ ਪ੍ਰੈਫਰੰਸ: ਕਿਥੇ ਅਤੇ ਕਦੋਂ ਨੋਟੀਫਾਈ ਹੋਣਾ

ਵੱਖ-ਵੱਖ ਟੀਮਾਂ ਵੱਖ-ਵੱਖ ਟੂਲਾਂ ਵਿੱਚ ਰਹਿੰਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਪ੍ਰਤੀ-ਯੂਜ਼ਰ ਨੋਟੀਫਿਕੇਸ਼ਨ ਚੈਨਲ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰੋ:

• In-app ਨੋਟੀਫਿਕੇਸ਼ਨ ਹਲਕੇ, ਗੈਰ-ਤੁਰੰਤ ਘਟਨਾਵਾਂ ਲਈ
• Email ਸੰਖੇਪ ਅਤੇ ਸਮੇਂ-ਅਧਾਰਿਤ ਰੀਮਾਇੰਡਰ ਲਈ
• Slack/Teams “ਅੱਜ” ਕਾਰਵਾਈਆਂ ਲਈ ਜਿਵੇਂ overdue check-ins

ਸ਼ਾਂਤ ਘੰਟਿਆਂ ਅਤੇ ਟਾਈਮਜ਼ੋਨ ਸ਼ਾਮਲ ਕਰੋ। 9am ਸਥਾਨਕ ਸਮੇਂ 'ਤੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਸਹਾਇਕ ਹੋਵੇਗੀ; 2am 'ਤੇ ਆਈ ਹੋਏ ਨੋਟੀਫਿਕੇਸ਼ਨ ਨੂੰ ਲੋਕ ਅਣਦੇਖਾ ਕਰ ਦੇਣਗੇ।

ਹਲਕੀ ਆਟੋਮੇਸ਼ਨ ਜੋ ਮਿਹਨਤ ਬਚਾਉਂਦੀ ਹੈ

ਆਟੋਮੇਸ਼ਨ ਦੁਹਰਾਉਂਦੇ ਕੰਮ ਹਟਾਉਣ ਲਈ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਨੇ ਪਰ ਸਪਸ਼ਟ ਰੱਖੀਆਂ ਜਾਨ।

• Recurring check-in prompts ਹਰ OKR ਦੀ cadence ਦੇ ਅਨੁਸਾਰ
• Digest summaries (ਹਫ਼ਤਾਵਾਰ) ਮਾਲਕਾਂ ਅਤੇ ਮੈਨੇਜਰਾਂ ਲਈ: ਕੀ ਬਦਲਿਆ, ਕੀ overdue, ਕਿਥੇ confidence ਘੱਟ ਹੋਈ
• Auto-create review tasks ਜਦੋਂ OKR "Ready for review" ਵਿੱਚ ਆ ਜਾਵੇ

ਜਿੱਥੇ ਆਟੋਮੇਸ਼ਨ ਯੂਜ਼ਰਾਂ ਨੂੰ ਹੈਰਾਨ ਕਰ ਸਕਦੀ ਹੈ ਉਥੇ ਓਪਟ-ਇਨ ਰੱਖੋ, ਅਤੇ ਹਮੇਸ਼ਾ ਨੋਟੀਫਿਕੇਸ਼ਨ ਵਿੱਚ "ਤੁਹਾਨੂੰ ਇਹ ਕਿਉਂ ਮਿਲਿਆ" ਦਿਖਾਓ। ਇਹ ਭਰੋਸਾ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਅਡਾਪਸ਼ਨ ਨੂੰ ਉੱਚੀ ਰੱਖਦਾ ਹੈ।

ਸੁਰੱਖਿਆ, ਪਰਦੇਦਾਰੀ ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ ਦਾ ਧਿਆਨ ਰੱਖੋ

ਸੁਰੱਖਿਆ ਅਤੇ ਪਰਦੇਦਾਰੀ ਫੈਸਲੇ ਬਾਅਦ ਵਿੱਚ "ਬੋਲਟ-ਆਨ" ਕਰਨਾ ਮੁਸ਼ਕਿਲ ਹੁੰਦਾ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਹਾਡੀ ਐਪ ਸੰਵੇਦਨਸ਼ੀਲ ਪ੍ਰਦਰਸ਼ਨਕ ਸੰਦਰਭ, ਰਣਨੀਤੀ ਨੋਟਸ, ਅਤੇ ਲੀਡਰਸ਼ਿਪ ਟਿੱਪਣੀਆਂ ਰੱਖਣ ਲੱਗੇ। ਇਹਨਾਂ ਨੂੰ ਉਤਪਾਦੀ ਲੋੜਾਂ ਵਜੋਂ ਲਓ, ਸਿਰਫ਼ ਇੰਜੀਨੀਅਰਿੰਗ ਕਾਰਜ ਵਜੋਂ ਨਹੀਂ।

ਬੇਸਿਕ ਸੁਰੱਖਿਆ ਜਿਹੜੀਆਂ ਪਹਿਲੋਂ ਹੀ ਸ਼ਾਮਲ ਕਰੋ

ਟ੍ਰਾਂਜ਼ਿਟ ਵਿੱਚ ਐਨਕ੍ਰਿਪਸ਼ਨ (HTTPS/TLS) ਅਤੇ ਡੇਟਾਬੇਸ/ਫਾਈਲ ਸਟੋਰੇਜ ਲਈ ਐਨਕ੍ਰਿਪਸ਼ਨ। ਸੈਸ਼ਨ ਲੀਮੀਟ ਦੇ ਨਾਲ ਸੁਰੱਖਿਅਤ ਟੋਕਨ, secure cookies, ਅਤੇ ਸਾਫ਼ logout ਵਿਹਾਰ (ਸਾਹਮਣੇ "ਸਾਰੇ ਡਿਵਾਈਸਾਂ ਤੋਂ ਲੌਗਆਊਟ") ਰੱਖੋ। ਲੌਗਿਨ ਅਤੇ API endpoints ਲਈ rate limits ਲਗਾਓ ताकि brute force ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕੇ, ਅਤੇ ਮੁੱਖ ਘਟਨਾਵਾਂ ਦਾ audit log ਰੱਖੋ: ਸਾਇਨ-ਇਨ, ਪਰਮਿਸ਼ਨ ਬਦਲਾਅ, OKR ਸੋਧ, ਐਕਸਪੋਰਟ, ਅਤੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਅਦਾਨ-ਪ੍ਰਦਾਨ।

ਇੱਕ ਸਾਦਾ ਪਰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਨਿਯਮ: ਕੋਈ ਵੀ ਐਕਸ਼ਨ ਜੋ OKRs ਜਾਂ ਐਕਸੈਸ ਨੂੰ ਬਦਲਦਾ ਹੈ ਉਸਨੂੰ ਯੂਜ਼ਰ, ਸਮਾਂ ਅਤੇ ਸਰੋਤ ਨਾਲ ਜੋੜ ਕੇ ਟਰੇਬਲ ਕੀਤਾ ਜਾਏ।

ਮਲਟੀ-ਟੇਨੈਂਟ ਅਲੱਗ-ਅਲੱਗ (ਜੇ ਤੁਸੀਂ ਕਈ ਅੰਗਠਨ ਸਮਰਥਨ ਕਰਦੇ ਹੋ)

ਜੇ ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਟ ਵਿੱਚ ਕਈ ਕੰਪਨੀਆਂ ਦਾ ਸਮਰਥਨ ਹੈ, ਤਾਂ tenant isolation ਪਹਿਲੇ ਹੀ ਸੋਚੋ। ਘੱਟੋ-ਘੱਟ:

• ਹਰ ਕਵੈਰੀ ਦੇਣ ਵਿੱਤ tenant-scoped ਹੋਵੇ (ਵਿਕਲਪਿਕ ਨਾ ਹੋਵੇ)
• ਕੋਰ ਟੇਬਲਾਂ 'ਤੇ ਵਿਲੱਖਣ tenant identifiers
• ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਅਲੱਗ encryption keys ਅਤੇ storage buckets

ਉੱਚੀ ਯਕੀਨਦਾਰੀ ਲਈ ਵੱਖ-ਵੱਖ ਡੇਟਾਬੇਸ ਪ੍ਰਤੀ ਟੇਨੈਂਟ ਇੱਕ ਵਿਕਲਪ ਹੈ—ਜ਼ਿਆਦਾ ਕੰਮ, ਪਰ ਸਧਾਰਣ containment।

ਪਰਦੇਦਾਰੀ, ਰੀਟੇਨਸ਼ਨ ਅਤੇ ਮਿਟਾਓ

ਫੈਸਲਾ ਕਰੋ ਕਿ ਸਾਈਕਲ ਖ਼ਤਮ ਹੋਣ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ। ਚੈਕ-ਇਨ, ਟਿੱਪਣੀਆਂ ਅਤੇ ਟੀਚੇ ਲਈ ਰੀਟੇਨਸ਼ਨ ਨੀਤੀ ਰੱਖੋ (ਉਦਾਹਰਨ: 2–3 ਸਾਲ ਰੱਖੋ), ਅਤੇ ਯੂਜ਼ਰ ਖਾਤਿਆਂ ਅਤੇ ਨਿੱਜੀ ਡੇਟਾ ਲਈ ਮਿਟਾਉਣ ਦਾ ਸਹਾਇਤਾ ਦਿਓ ਜਿੱਥੇ ਲੋੜ ਹੋਵੇ। ਐਕਸਪੋਰਟ ਅਤੇ ਐਡਮਿਨ ਡਿਲੀਸ਼ਨ ਕਾਰਵਾਈਆਂ auditable ਹੋਣ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਯੂਜ਼ਰ ਹਟਾਉਂਦੇ ਹੋ ਤੇ ਪੁਰਾਣੀਆਂ ਟਿੱਪਣੀਆਂ anonymize ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਵਰਤਾਰਾ ਸਪਸ਼ਟ ਦਸਤਾਵੇਜ਼ ਕਰੋ।

ਡਿਪਲੋਇਮੈਂਟ ਅਤੇ ਓਪਰੇਸ਼ਨ

ਵਾਤਾਵਰਣ (dev/staging/prod) ਸੈਟ ਕਰੋ ਜੋ ਕੰਟਰੋਲਡ ਐਕਸੈਸ ਅਤੇ configuration management ਨਾਲ ਹੋਵਣ। ਬੈਕਅੱਪ ਆਟੋਮੇਟ ਕਰੋ ਅਤੇ restore ਟੈਸਟ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਚਲਾਓ। uptime, error rates, ਅਤੇ slow queries ਲਈ ਮਾਨੀਟਰਿੰਗ ਸ਼ਾਮਲ ਕਰੋ, ਅਤੇ ਅਲਾਰਟਸ ਜੋ ਕਿਸੇ ਮਨੁੱਖ ਤੱਕ ਪਹੁੰਚਣ। ਆਖਿਰ ਵਿੱਚ, ਇਕ ਹਲਕੀ incident response runbook ਲਿਖੋ: tokens revoke, keys rotate, ਪ੍ਰਭਾਵ ਦੀ ਸੰਚਾਰ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਫਿਕਸ ਸ਼ਿਪ ਕਰਨ ਦੀ ਰਣਨੀਤੀ।